# EIP-4488 Mining Strategy & Stipend Analysis

## Summary

This is an auxiliary analysis for [EIP-4488](https://eips.ethereum.org/EIPS/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](https://gist.github.com/adietrichs/9837f96d44603a76349fd98525c7cb43)).

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 + 32 * \text{word_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](https://github.com/ethereum/go-ethereum/pull/23983).
- 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:

| 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.