Try   HackMD

1559 Cheatsheet for Implementers

  • This document is an introduction to some of the concepts that may be important to you when adding support for EIP-1559. Assumes familiarity with the EIP and its mechanisms.
  • If you are completely new to EIP-1559, you can find a curated link-list in this 1559 Resources guide.
  • Join the ETHR&D Discord for discussion on everything related to this change.

Reference Implementations

Additional resources

Previous Coordination Calls

BaseFee burn interfaces

Implementation Info

Note: transactions seed a maxPriorityFee & maxFee > 0. Miners may not sort the txn pool directly by maxPriorityFee because in cases when maxFee - maxPriorityFee < baseFee, the maxPriorityFee will be reduced for the transaction to remain valid. If maxFee < baseFee, the transaction is invalid.

1559 Variables and their functions

Variable Definition
baseFeePerGas Generated by the protocol, recorded in each block header. Represents the minimum gasUsed multiplier required for a tx to be included in a block. This is the part of the tx fee that is burnt: baseFeePerGas * gasUsed.
maxPriorityFeePerGas Users set this. Added to transactions, represent the part of the tx fee that goes to the miner. see ⭐ below
maxFeePerGas Users set this. Represents the maximum amount that a user is willing to pay for their tx (inclusive of baseFeePerGas and maxPriorityFeePerGas). The difference between maxFeePerGas and baseFeePerGas + maxPriorityFeePerGas is "refunded" to the user.

Variable Mechanics

  • Each block's baseFeePerGas can increase/decrease by up to 12.5% depending on how full the block is relative to the previous one: e.g. 100% full -> +12.5%, 50% full -> same, 0% full -> -12.5%.
  • When 1559 is activated, the gasLimit of blocks will double (e.g. 15m to 30m), so "50% full" blocks post-1559 are equivalent to 100% full blocks pre-1559.
  • Note: on the 1559 fork block, the baseFeePerGas will be set to 1 gwei. Due to integer math, it cannot go below 7 wei (0.000000007 gwei).

⭐ maxPriorityFeePerGas in-depth

maxPriorityFeePerGas serves three purposes:

  1. 🔀 Compensates miners for the uncle/ommer risk + fixed costs of including transaction in a block;
  2. 💰 Allows users with high opportunity costs to pay a premium to miners;
  3. 📈 In times where demand exceeds the available block space (i.e. 100% full, 30mm gas), this component allows first price auctions (i.e. the pre-1559 fee model) to happen on the priority fee.

Here's how to think about suggesting user defaults for maxPriorityFeePerGas.

  1. 🔀 Compensates miners for the uncle/ommer risk + fixed costs of including transaction in a block;

The rationale behind this is that if the priority fee was 0, miners would simply mine empty blocks. Therefore, in order for it to be in their economic interest to add transactions to blocks, they must be compensated beyond the marginal uncling risk that adding transactions to their block creates (and for the fixed costs of actually running the transactions, but those are negligible compared to uncle risk).

Uncle risk has two main components: the difference in block reward between being a canonical vs. uncle block and the lost MEV in the block.

This analysis calculates the right maxPriorityFeePerGas to set (assuming 15m gas) based on how much MEV there is on average in a block (note: p=0, the last graph, uses the most accurate numbers). Flashbots has a dashboard showing the average MEV per block.

Example Values for 20-05-21

Looking at the dashboard today, we see this:

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 →

This implies a ballpark 0.2ETH/block in MEV over the last few days.

Looking at Barnabé's diagram we see:

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 →

At 0.2ETH/block, the right maxPriorityFee to compensate for the uncle risk is 1 gwei. Given this will compensate the median MEV block, we should probably raise it slightly so that it is profitable to include transactions even when MEV is higher than average.

Looking at the MEV distribution on Flashbots, the vast majority of blocks have <1 ETH in MEV, which would represent a 2.5 gwei fee. 2 gwei is probably a very good default "you will get in the next handful of blocks" value. 1 gwei is likely a good "slow" value.

  1. 💰 Allows users with high opportunity costs to pay a premium to miners;

For this, it should suffice to have an "Advanced" option where users can manually set their maxPriorityFee to whatever they want.

  1. 📈 In times where demand exceeds the available block space, allows first price auctions (i.e. the pre-1559 fee model) to happen on the tip.

In this case, estimating the maxPriorityFee becomes the same as estimating the current gasPrice. A "smart" implementation could look at how full the last N blocks are to determine whether we are in a high congestion regime.

Legacy Transaction Support

  • Legacy pre-London transactions will still work under 1559: the gas price will be interpreted as both the maxFeePerGas and maxPriorityFeePerGas, meaning that the baseFeePerGas is burnt, and any extra goes to the miner. Here are some examples, assuming baseFeePerGas is 100 gwei:

1559-style tx: User sends a tx with a maxFeePerGas of 250 gwei and maxPriorityFeePerGas of 5 gwei. The user will pay 100+5=105 gwei, 100 of which will be burnt and 5 going to the miner.

Legacy (Pre-1559) tx: If the user had a legacy tx with gasPrice of 250 gwei, then maxPriorityFeePerGas would also have been set to 250 gwei and the user would have paid 250 gwei/gas for their transaction, 100 of which would have been burnt and 250-100=150 going to the miner.

  • However, supporting EIP-1559-style txns will be more gas-efficient for users. With 1559 txns, only your priority fee goes to the miner, and the difference between the maxFeePerGas and baseFeePerGas + maxPriorityFeePerGas is refunded to the user.
  • 1559-style transactions have Transaction Type set to 0x2

London Activation Process

When EIP-1559 goes live in the London upgrade (scheduled for August 4), the baseFeePerGas will be set to 1 gwei. This means that, at first, transactions will be competing via a first-price auction on the tip, as the baseFeePerGas reaches the rate where there is ~15m gas /100% demand at that price.

If you assume the market price is 250 gwei on the fork date, this means that baseFeePerGas needs to go through ~50 blocks to get there, or slightly less than 15 minutes.

Because of this, it is probably simplest to not make 1559-style transactions the default for at least 15-30 minutes post fork, in order for the baseFeePerGas to stabilize.

When to default to 1559 txns in a UI

  1. gasUsed is closer to gasTarget (currently 15m) than gasLimit (30m post fork): this means that we've found a price for the baseFeePerGas that's close to the market price;
  2. baseFeePerGas of parent +/- 5% from last block's baseFeePerGas: this means the baseFeePerGas has stopped increasing and is somewhat stable;
  3. Ballpark: look at average gasPrice right before fork, calculate how many blocks need to be full for the baseFeePerGas to reach that amount (+12.5% each full block), add a little buffer

Can perhaps use a combination of the 3, i.e.: 12.5m <gasUsed < 17.5m AND parentBaseFee +/- 5% from baseFeePerGas AND blocksSinceFork > 100

Mockup Resources

We will be adding UI resources as they are worked on by wallet teams:

Supporting Imagery

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 →

Last changed by 
 
tvanepps
8
15
26475

Read more

Homepage

Protocol Guild is a collective funding mechanism for Ethereum Layer 1 R&amp;D. It has three components:

May 7, 2024
kzg special contributions

The Cryptosat team kicked off the Special Contribution period with a contribution from space aboard their Crypto 2 satellite. Read about what they did and how on their blog.

Jul 26, 2023
KZG Ceremony - Final Verification options

This is basically a question of where the boundary between individuals verifying and client teams implementing lies. How much work should be required to verify that client teams correctly put the output of the ceremony into the clients? Do we need everyone to verify the exact file gets included in clients, or are we ok having only some people do it and anyone can check at any time.

Jun 30, 2023
Announcing the KZG Ceremony

High fees have made life difficult for travelers through these Dark Forests. The Pools of Mem once clouded, now clarified by the filter of 1559, reveal that they are not deep enough to sustain. Legends tell of a society flourishing under the abundance brought about by DankShard, of giant Roll-Ups subsisting on fields of nourishing Data Blobs, each supporting their own fractal nutrient layers. To summon DankShard, our guides point us to a Ceremony. All members of the Lands of Ether and abroad are encouraged to contribute. Each will add their unique contribution to the collective and in doing so, illuminate the path forward. Overview The KZG Ceremony is a coordinated public ritual which will provide a cryptographic foundation for Ethereum scaling efforts like EIP-4844 (aka proto-danksharding). These types of events are also known as &quot;Trusted Setups,&quot; famously used by Zcash to bootstrap the chain&apos;s privacy features. However, they can also be used to support scaling mechanisms, as Ethereum plans to do. Proto-danksharding requires a new cryptographic scheme: KZG Commitments. will generate a structured reference string (SRS) which is needed for the commitments to work. An SRS is secure as long as one participant in the ceremony successfully conceals their secret.

Apr 16, 2023
Read more from tvanepps
Published on HackMD