# 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:
![](https://i.imgur.com/imSus3P.png)
| 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.

query via Ethereum public data on Google BigQuery: SELECT address, BYTE_LENGTH(bytecode) / 2 - 1 AS code_size FROM `bigquery-public-data.crypto_ethereum.contracts` ORDER BY BYTE_LENGTH(bytecode) DESC LIMIT 100;

11/29/2021Motivation current EIP-1559 base fee adjustment: based on block gas usage in effect, control loop that targets stable throughput per block not ideal under PoW under two aspects: block time variability: block gas usage tries to measure demand at current base fee level, but gas usage is proportional to block time, introducing noise to the used signal block time variability => "incorrect" demand signals => "incorrect" base fee adjustments => increased base fee volatility

10/27/2021Aufgabe 1: "Das Seil tickt" Die entscheidende Idee ist, dass ein Seil an beiden Enden angezündet werden kann, und ab diesem Moment doppelt so schnell abbrennt. MoRo kann dies nutzen, indem er das erste Seil direkt an beiden Enden anzündet, das zweite aber nur an einem Ende. Nach 30 Minuten ist das erste Seil vollständig abgebrannt. Er zündet nun auch das andere Ende vom zweiten Seil an. Dieses hatte noch 30 Minuten Brennzeit übrig, die sich damit dann auf 15 Minuten halbiert. Sobald das zweite Seil also auch abgebrannt ist, sind insgesamt 45 Minuten vergangen. Aufgabe 2: "Din-A-Knick" ![](https://i.imgur.com/ZuhyXwA.png =441x590) Abgebildet ist ein KoRo-Etikett im Format DIN A7, also mit $\overline{AB} = 74$ und $\overline{BC} = 105$. Gesucht ist die Länge des Knicks $\overline{FG}$, der sich ergibt, wenn man $A$ auf $C$ faltet. Wichtig zur Lösung ist dabei, zu erkennen, dass der Knick $\overline{FG}$ die Diagonale $\overline{AC}$ im rechten Winkel schneidet (im Punkt $E$). Mit dieser Einsicht lässt sich die Knicklänge mit etwas Pythagoras und ähnlichen Dreiecken berechnen: Die Dreiecke $A,B,C$ und $C,E,F$ haben beide jeweils einen Winkel $\gamma$ und einen rechten Winkel, sind also ähnliche Dreiecke. Entsprechend lassen sich ihre Seitenlängen ins Verhältnis setzen als $\frac{\overline{AB}}{\overline{BC}} = \frac{\overline{EF}}{\overline{CE}}$. Mit Pythagoras können wir $\overline{CE}$ berechnen: $\overline{CE} = \frac{1}{2}\overline{AC} = \frac{1}{2}\sqrt{\overline{AB}^2 + \overline{BC}^2}$.

10/7/2021With all the activity this week around the Ethereum London hard fork, I have noticed people having a wide range of ways to think about EIP-1559, the hard fork's main protocol change. So I thought I would try to outline my own perspective on the EIP here, to ideally help integrate these different lines of thinking. If you strongly disagree with any point made here, come find me over on twitter at @adietrichs - I would love to hear from you! [TOC] See Conclusion for a tl;dr. The Status Quo In order to understand the motivation and implications of EIP-1559, we first have to look at the current-day situation in Ethereum. The parts of the overall blockchain mechanism relevant to us are those of transaction pricing and inclusion, as these are where the main changes of the EIP take place. In the first section we will formalize this as the market for transaction inclusion, and distinguish it from the recently emerged separate market of transaction ordering (à la flashbots). We will then have a look at this market, developing a simple model for it as a fixed-supply iterated first-price auction.

8/11/2021
Published on ** HackMD**

or

By clicking below, you agree to our terms of service.

Sign in via Facebook
Sign in via Twitter
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet

Wallet
(
)

Connect another wallet
New to HackMD? Sign up