Try   HackMD

EIP-4488 Mining Strategy & Stipend Analysis

Summary

This is an auxiliary analysis for EIP-4488. It looks at the impact of different stipend sizes and mining algorithms on miner profits. It shows that even for moderate stipend sizes, both an optimal miner packing algorithm and a simple backlog-based algorithm are able to include almost all available transactions, leading to very similar profitability. Fully naive mining is a bit less profitable and requires a higher stipend to start converging with the other two.

Data & Method

The data is a sample (10%) of Ethereum mainnet blocks of the 1 week period between November 30 and December 6 2021. It has been collected via Google BigQuery (sql queries here).

To reduce complexity of the analysis, several simplifications are made:

  • Even for full blocks, there are no additional available transactions besides those in the block
  • Miner profitability is only determined by direct fee payments (not e.g. taking into account manual payments to the coinbase address)
  • Each transaction is treated as coming from a separate account
  • Gas consumption per transaction is considered static, independent of ordering

For each block, the post-4488 situation is simulated by assuming the block contains additional high-calldata transactions at the beginning, consuming all of the static 1MB calldata limit and leaving only the per-transaction stipend.

For the stipend, all sizes of the form

4+32word_count bytes for a word count of up to 20 are considered, as well as the original 300 byte value from the EIP. This accounts for the sizes of real world calldata when calling Solidity functions (4 bytes for the initial function selector + arguments structured as full EVM words).

For each stipend value, three different mining strategies are compared:

  • The naive strategy iterates through all includable transactions sorted by effective tip, as is the case pre-4488. Whenever a transaction is encountered that is not includable due to its calldata size, it is simply skipped. This is the approach currently implemented in the geth prototype implementation.
  • The backlog strategy follows the same approach as the naive one. However, when skipping a transaction with too large calldata, it adds the transaction to a backlog, implemented as a min-heap (partially) sorted by calldata size. Any time the available calldata in the block goes back up, the backlog is scanned for newly includable transactions.
  • The optimal strategy uses a knapsack solver to find the ideal combination of transactions to include in the block.

Note: Analysis code can be made available on request.

Results

The following graph and accompanying table display the fraction of available profit (from all transactions in the pre-4488 dataset) that the miner is able to capture with each of the three discussed strategies:

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

Stipend Profits Naive Profits Backlog Profits Optimal
4 bytes 17.29% 22.96% 38.64%
36 bytes 46.21% 68.11% 82.18%
68 bytes 64.70% 88.23% 92.88%
100 bytes 75.06% 94.08% 96.53%
132 bytes 79.50% 96.38% 97.92%
164 bytes 82.97% 97.58% 98.55%
196 bytes 86.26% 98.34% 98.90%
228 bytes 91.44% 98.71% 99.30%
260 bytes 93.24% 99.14% 99.46%
292 bytes 94.07% 99.32% 99.57%
300 bytes 94.25% 99.35% 99.59%
324 bytes 94.84% 99.44% 99.64%
356 bytes 95.31% 99.56% 99.68%
388 bytes 96.25% 99.61% 99.72%
420 bytes 96.54% 99.68% 99.74%
452 bytes 96.74% 99.70% 99.76%
484 bytes 96.93% 99.73% 99.78%
516 bytes 97.23% 99.75% 99.79%
548 bytes 97.42% 99.77% 99.80%
580 bytes 97.60% 99.88% 99.91%
612 bytes 97.77% 99.90% 99.92%
644 bytes 98.04% 99.91% 99.93%

Conclusion

It can be seen that the backlog mining strategy is able to capture profits close to the theoretical optimum (within 1% for all stipends >= 164 bytes). The naive strategy only captures a smaller fraction of profits for small stipends, but reduces this gap for higher stipends. The backlog strategy thus seems preferable, but even clients with the naive approach would remain competitive.

This analysis can also help with the optimal choice for the stipend. In particular, the miner profitability can be seen as a metric of overall transaction inclusion. Importantly, even at moderate stipend sizes, inclusion rate of the backlog method is close to 100% (>99% for all stipends >= 260 bytes). Taking into account that the dataset already includes a significant number of (mostly rollup) "big calldata" transactions, this implies that for all "normal-sized" transactions, the calldata limit would not impede their inclusion into the next available block.