# EIP-1559 Time-Based Base Fee Adjustments ## 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 - reduced throughput during consensus issues: - if chain forks, block times go up for a while, before difficulty is adjusted - gas limit elasticity would give us the capability to compensate for this throughput reduction to some extent - also not ideal under PoS: - missed slots: - while general block times become regular, occasionally slots are missed, doubling the block time for the next block (or more, if that slot is also missed) - missed slots still send incorrect signal (demand looks 2x as high as it is), leading to base fee spikes after missed slots - incentive to attack network via block proposer DOS, as each missed slot directly reduces network throughput - consensus issues: - worse than under PoW, as longer time for self-healing (several weeks for inactivity leaks as opposed to several hours for difficulty adjustments) - gas limit elasticity would again give us the capability to compensate for this throughput reduction to some extent ## Proposal - include block time in base fee adjustment: make "block gas target" proportional to block time - results in control loop that targets stable throughput per time - addresses problems listed above: - reduces / removes base fee volatility inroduced by PoW block time variability - reduces / removes base fee volatility inroduced by PoS missed slots - reduces incentive to DOS block proposers - reduces / removes impact of chain forks on throughput - drawback: during demand spikes under PoS, missed slots can delay base fee increase #### Current EIP-1559 Update Rule $b_{n+1} = b_n * (1 + \frac{1}{8}\frac{g_n-G_n}{G_n})$, where: $b_n$ : base fee at block $n$ $\frac{1}{8}$ : maximum base fee change rate $g_n$ : gas used by block $n$ $G_n$ : gas target for block $n$ #### Block Time Based Update Rule $b_{n+1} = b_n * (1 + \frac{1}{8}\frac{g_n-G_n\frac{t_n}{T_n}}{G_n})$, where: $t_n$ : block time for block $n$, i.e. `block.timestamp - parent.timestamp` $T_n$ : block time target #### Capped Block Time Based Update Rule In practice it is sensible to introduce an upper limit to the block time used by the update rule: - during chain forks, block gas targets above 50% reduce the ability to pick up on demand increases - in the extreme, with 50%+ of proposers offline, the base fee could not increase at all - fee market would revert to a first-price auction on top of the current base fee level - base fee would even leak downwards due to small residual fee block space (<21k) - alternative: bound block gas target to below elasticity limit $b_{n+1} = b_n * (1 + \frac{1}{8}\frac{g_n-G_n\frac{\text{min}(t_n, T_{\text{max}})}{T_n}}{G_n})$, where: $T_{\text{max}}$ : maximum block time to consider (e.g. 23s or 24s for PoS) ### Specification The relevant part of the pseudocode specification of EIP-1559 is: ```python= BASE_FEE_MAX_CHANGE_DENOMINATOR = 8 parent_gas_target = self.parent(block).gas_limit // ELASTICITY_MULTIPLIER parent_gas_limit = self.parent(block).gas_limit parent_base_fee_per_gas = self.parent(block).base_fee_per_gas parent_gas_used = self.parent(block).gas_used if parent_gas_used == parent_gas_target: expected_base_fee_per_gas = parent_base_fee_per_gas elif parent_gas_used > parent_gas_target: gas_used_delta = parent_gas_used - parent_gas_target base_fee_per_gas_delta = max(parent_base_fee_per_gas * gas_used_delta // parent_gas_target // BASE_FEE_MAX_CHANGE_DENOMINATOR, 1) expected_base_fee_per_gas = parent_base_fee_per_gas + base_fee_per_gas_delta else: gas_used_delta = parent_gas_target - parent_gas_used base_fee_per_gas_delta = parent_base_fee_per_gas * gas_used_delta // parent_gas_target // BASE_FEE_MAX_CHANGE_DENOMINATOR expected_base_fee_per_gas = parent_base_fee_per_gas - base_fee_per_gas_delta ``` This update would only require changes to lines (2, 3, 5), 6, 15, 19: ```python= BASE_FEE_MAX_CHANGE_DENOMINATOR = 8 BLOCK_TIME_TARGET = 12 BLOCK_TIME_CONSIDERATION_CAP = 23 parent_considered_block_time = min(self.parent(block).timestamp - self.parent(self.parent(block)).timestamp, BLOCK_TIME_CONSIDERATION_CAP) parent_gas_target = self.parent(block).gas_limit * parent_considered_block_time // ELASTICITY_MULTIPLIER // BLOCK_TIME_TARGET parent_gas_limit = self.parent(block).gas_limit parent_base_fee_per_gas = self.parent(block).base_fee_per_gas parent_gas_used = self.parent(block).gas_used if parent_gas_used == parent_gas_target: expected_base_fee_per_gas = parent_base_fee_per_gas elif parent_gas_used > parent_gas_target: gas_used_delta = parent_gas_used - parent_gas_target base_fee_per_gas_delta = max(parent_base_fee_per_gas * gas_used_delta * ELASTICITY_MULTIPLIER // parent_gas_limit // BASE_FEE_MAX_CHANGE_DENOMINATOR, 1) expected_base_fee_per_gas = parent_base_fee_per_gas + base_fee_per_gas_delta else: gas_used_delta = parent_gas_target - parent_gas_used base_fee_per_gas_delta = parent_base_fee_per_gas * gas_used_delta * ELASTICITY_MULTIPLIER // parent_gas_limit // BASE_FEE_MAX_CHANGE_DENOMINATOR expected_base_fee_per_gas = parent_base_fee_per_gas - base_fee_per_gas_delta ``` ## Future Changes - exponential base fee update - more elegant properties - slightly more involved change to include efficient deterministic exponentiation - variable block gas limits (dependent on block times) - feasible to the extent the bottleneck for block gas limits is state growth, not networking / computation
Last changed by  
 
Ansgar Dietrichs
415

Read more

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)

12/10/2021
Largest Contracts on Ethereum Mainnet

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/2021
Koro Lösungen

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" ![](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/2021
How I Think About EIP-1559

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.

8/11/2021
Read more from Ansgar Dietrichs
Published on HackMD