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)

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;

Motivation 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

Aufgabe 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"  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}$.

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

For now only consists of those that I was personally involved with and that are missing by cmichel's impressive writeup. BABYREV This was the problem we spent by far the most time on. It consists of a Challenge contract without source code, with an internal flag that has to be set to true. We ended up manually annotating the entire opcode-level path from contract start to the only contract SSTORE. You can find our annotated version here. In total, we annotated 521 opcodes with 5078 stack items. At the end, we were able to reconstruct the logic of the solve(uint256) function responsible for setting the contract flag: // permutation array, constisting of all 256 bytes 0x00 - 0xff in scrambled order a_arr = hex"637c777bf26b6fc53001672bfed7ab76ca82c97dfa5947f0add4a2af9ca472c0b7fd9326363ff7cc34a5e5f171d8311504c723c31896059a071280e2eb27b27509832c1a1b6e5aa0523bd6b329e32f8453d100ed20fcb15b6acbbe394a4c58cfd0efaafb434d338545f9027f503c9fa851a3408f929d38f5bcb6da2110fff3d2cd0c13ec5f974417c4a77e3d645d197360814fdc222a908846eeb814de5e0bdbe0323a0a4906245cc2d3ac629195e479e7c8376d8dd54ea96c56f4ea657aae08ba78252e1ca6b4c6e8dd741f4bbd8b8a703eb5664803f60e613557b986c11d9ee1f8981169d98e949b1e87e9ce5528df8ca1890dbfe6426841992d0fb054bb16"

tl;dr Transaction comparison and sorting in the mempool is used for two main problems: On the upper end, finding the most attractive transactions during mining; and on the lower end, identifying the least promising transactions for eviction. For legacy transactions, both problems use the gas_price as the relevant decision metric and max-/min-heaps as efficient partially sorted data structures. For EIP-1559, these problems require different metrics. For mining, a (somewhat more complex) explicit solution seems feasible. For eviction, heuristics are needed that are both efficiently implementable and robust under many different base fee paradigms. As a proposal for a new transaction pricing model, EIP-1559 will change many aspects of Ethereum clients' behavior. One of the areas most impacted is the mempool, i.e. the part of a client responsible for handling in-flight transactions on their way from users to miners. Tim Beiko recently listed 4 open questions around mempool handling of EIP-1559 transactions, with three of them closely tied to the problem of transaction sorting. Here we aim to give a brief overview of different aspects of mempool transaction sorting and how they are impacted by EIP-1559. This document is mainly intended to serve as a basis of discussion for the upcoming implementers' call. It will be followed up by a more comprehensive writeup. As the Quilt team has only recently joined the EIP-1559 effort, it is very possible that we made incorrect assumption or overlooked relevant existing work. Feedback in these cases and in general is much appreciated! Mempool Sorting There are two main distinct sorting problems: Miners, when picking transactions for a new block, want to get the currently most profitable transactions. And all nodes, when reaching the maximum mempool capacity, want to get the transactions with the lowest inclusion chance, that they can evict to make room for more promising transactions. Both of these problems consist of two sub-problems: The choice of a comparison metric and the choice of an efficient data structure for transactions, based on that metric.