HackMD
    • Options
    • Versions and GitHub Sync
    • Transfer ownership
    • Delete this note
    • Template
    • Save as template
    • Insert from template
    • Export
    • Dropbox
    • Google Drive
    • Gist
    • Import
    • Dropbox
    • Google Drive
    • Gist
    • Clipboard
    • Download
    • Markdown
    • HTML
    • Raw HTML
    • ODF (Beta)
    • PDF (Beta)
    • Sharing Link copied
    • /edit
    • View mode
      • Edit mode
      • View mode
      • Book mode
      • Slide mode
      Edit mode View mode Book mode Slide mode
    • Note Permission
    • Read
      • Owners
      • Signed-in users
      • Everyone
      Owners Signed-in users Everyone
    • Write
      • Owners
      • Signed-in users
      • Everyone
      Owners Signed-in users Everyone
    • More (Comment, Invitee)
    • Publishing
      Everyone on the web can find and read all notes of this public team.
      After the note is published, everyone on the web can find and read this note.
      See all published notes on profile page.
    • Commenting Enable
      Disabled Forbidden Owners Signed-in users Everyone
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
      • Everyone
    • Invitee
    • No invitee
Menu Sharing Help
Menu
Options
Versions and GitHub Sync Transfer ownership Delete this note
Export
Dropbox Google Drive Gist
Import
Dropbox Google Drive Gist Clipboard
Download
Markdown HTML Raw HTML ODF (Beta) PDF (Beta)
Back
Sharing
Sharing Link copied
/edit
View mode
  • Edit mode
  • View mode
  • Book mode
  • Slide mode
Edit mode View mode Book mode Slide mode
Note Permission
Read
Owners
  • Owners
  • Signed-in users
  • Everyone
Owners Signed-in users Everyone
Write
Owners
  • Owners
  • Signed-in users
  • Everyone
Owners Signed-in users Everyone
More (Comment, Invitee)
Publishing
Everyone on the web can find and read all notes of this public team.
After the note is published, everyone on the web can find and read this note.
See all published notes on profile page.
More (Comment, Invitee)
Commenting Enable
Disabled Forbidden Owners Signed-in users Everyone
Permission
Owners
  • Forbidden
  • Owners
  • Signed-in users
  • Everyone
Invitee
No invitee
   owned this note    owned this note      
Published Linked with GitHub
Like BookmarkBookmarked
Subscribed
  • Any changes
    Be notified of any changes
  • Mention me
    Be notified of mention me
  • Unsubscribe
Subscribe
# EIP 1559 FAQ ## What is EIP 1559 [EIP 1559](https://eips.ethereum.org/EIPS/eip-1559) is a proposal to reform the Ethereum fee market, with the following key changes: * The current gas limit is replaced by two values: a "long-term average target" (equal to the current gas limit), and a "hard per-block cap" (twice the current gas limit) * There is a BASEFEE (which is burned) which transactions are required to pay, which gets adjusted on a block-by-block basis with the goal of targeting a value so that average block gas usage remains at a level close to the current gas limit. Essentially, instead of all of the short-term volatility in demand for transaction space within a block translating into volatility in transaction fees, some of the volatility instead translates into volatility in block size. ## Why is EIP 1559 good? Copying from [an older post](https://github.com/zcash/zcash/issues/3473): ----------------------- There are three major problems with the status quo of transaction fee markets: * **Mismatch between volatility of transaction fee levels and social cost of transactions**: transaction fees on mature public blockchains, that have enough usage so that blocks are full, tend to be extremely volatile. On Ethereum, minimum fees are typically around 2 gwei (10^9 gwei = 1 ETH), but sometimes go up to 20-50 gwei and have even on one occasion gone up to over 200 gwei: https://etherscan.io/chart/gasprice. This clearly creates many inefficiencies, because it's absurd to suggest that the cost incurred by the network from accepting one more transaction into a block actually is 100x more when gas prices are 200 gwei than when they are 2 gwei; in both cases, it's a difference between 8 million gas and 8.02 million gas. * **Inefficiencies of first price auctions**: see https://ethresear.ch/t/first-and-second-price-auctions-and-improved-transaction-fee-markets/2410 for a detailed writeup. In short, the current approach, where transaction senders publish a transaction with a fee, miners choose the highest-paying transactions, and everyone pays what they bid, is well-known in mechanism design literature to be highly inefficient, and so complex fee estimation algorithms are required, and even these algorithms often end up not working very well, leading to frequent fee overpayment. See also https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72 for a Bitcoin core developer's description of the challenges involved in fee estimation in the status quo. * **Instability of blockchains with no block reward**: in the long run, blockchains where there is no issuance (including Bitcoin and Zcash) at present intend to switch to rewarding miners entirely through transaction fees. However, there are [known results](http://randomwalker.info/publications/mining_CCS.pdf) showing that this likely leads to a lot of instability, incentivizing mining "sister blocks" that steal transaction fees, opening up much stronger selfish mining attack vectors, and more. There is at present no good mitigation for this. EIP 1559 has these benefits: * It mitigates the economic inefficiencies from social cost mismatch due to fee volatility. There is a fairly nuanced economic argument here; see particularly pages 16-20 of the paper linked in https://ethresear.ch/t/draft-position-paper-on-resource-pricing/2838 (though I recommend reading the whole paper) for a detailed argument of why this is the case. Intuitively, the adjusting fee mechanism works like a fixed fee in the short run and a cap in the long run, and it turns out that because of [arguments from Martin Weitzman's 1974 paper](https://scholar.harvard.edu/weitzman/files/prices_vs_quantities.pdf) fixed fees are likely better than a cap in the circumstances that basically all public blockchains are in today and will likely continue to be in. * It replaces the auction with a fixed price sale (except during short periods where blocks fill up completely until fees catch up), eliminating first-price-auction inefficiencies and making fee estimation extremely simple: calculate the fee `f` for the next block, if you can afford it pay it, otherwise don't. * It creates a mechanism similar to a permanent block reward (the 1/N coming from the pot), mitigating many of the instability issues with fee-only blockchains without requiring actual permanent issuance. ----------------------- Another underrated benefit of EIP 1559 is that it makes gas prices _securely measurable_. Today, just looking at gas prices on chain and using them as an index is exploitable, because miners could include either very-low-fee or very-high-fee dummy transactions where the fee would go to themselves. But under EIP 1559, the BASEFEE can only be manipulated at high cost, as dummy transactions would requre even the miner to pay fees (that get burned). ## Are current fee markets really that inefficient? Yes. The difference between average gasprice and 10th percentile gasprice in a regular block is something like 3x for median and 5-8x for mean. People needlessly overpay massively. Everyone who does not overpay suffers a delay of 1-2 minutes or even longer, and this delay does not actually benefit anyone; the total load to the chain is the same regardless of whether a given unit of load hits the chain at time N or time N + 60. **There is no actual social benefit from participants "expressing a low time preference"** in the fee market mechanism, at least under normal conditions; it is pure deadweight loss. We would all be better off if more transactions were just included immediately, which EIP 1559 allows. ## Why not just use a second price(or kth price auction) to solve the first-price-auction inefficiencies? Kth-price auctions (where everyone pays a gasprice equal to the lowest gasprice that was included in the block) are indeed "efficient" in a traditional economic analysis*, but have the flaw that they are vulnerable to collusion. <small> \* Yes of course technically you want to use the _highest gasprice not included_ in the block; but in practice given that most ethereum blocks have hundreds of transactions the difference would be negligible.</small> ## Might EIP 1559 run the risk of over-stressing nodes and miners during periods of high usage? EIP 1559 can at most increase block size by 2x, even in the short term. Each "full block" (ie. a block whose gas is 2x the TARGET) increases the BASEFEE by 1.125x, so a series of constant full blocks will increase the gas price by a factor of 10 every ~20 blocks (~4.3 min on average). Hence, periods of heavy on-chain load will not realistically last longer than ~5 minutes. Note that currently, periods of double load that last 5 minutes already happen by random chance roughly once per ~63888 blocks (~10 days) because of variance in the rate of block production. So the introduction of EIP 1559 would not bring in any unprecedented level of load to the system. Additionally, the gas limit being only 12.5 million and not higher is justified to a large extent not by hard network limits (uncle rates are [near historic lows](https://etherscan.io/chart/uncles), though risks to non-miner nodes such as bootstrap nodes, may be higher), but by concerns that are fundamentally long-term in character: * Centralization risk of somewhat higher uncle rates: if uncle rates shoot up to 20%, that would disproportionately benefit well-connected large pools * Limits to state size * Difficulty of syncing after a short period offline In all three of these cases, what matters is not the upper bound on capacity within a very short window of time, but rather the long-term average capacity. Uncle rates being 2% during odd hours and 18% during even hours would have the same effect on all three of the above, as uncle rates always being 10%. Because EIP 1559 still bounds the long-run gas usage to a ~12.5 million per block average, it does not affect the long-term average. ## How would a spike of high usage look like under EIP 1559 compared to the status quo? Consider a "mathematically ideal spike" (eg. this could happen in real life because of a sudden market event leading to many arbitrage opportunities on DEXes, bidding on liquidated CDPs, etc), where N * 12.5 million gas worth of transactions, each with a very very high gasprice, are all broadcasted. Currently, this would lead to the following situation: * The next N blocks are filled exclusively with new spiky transactions * After that other transactions, as well as transactions that people send after the spike, get included in descending order of gasprice An average "normal user" would have to wait more than N blocks. Now, consider the situation under EIP 1559: * The next N/2 blocks are filled exclusively with new spiky transactions, each with twice the normal amount of gas * If all other transactions get sent with a gas price cap equal to the old gasprice, then the next N/2 blocks would be empty, and after that things would revert to normal. But realistically, higher-priority transactions would set higher gas price caps and get included first, and other transactions later. An average "normal user" would have to wait somewhere between N/2 and more than N blocks. Hence, even including the post-spike "recovery period" during which block capacity would be smaller than normal, most transactions get included sooner. Here's a very rough simulation (there are lots of strange assumptions here, but modeling a full system that covers both supply/demand curves *and* waiting times is hard); spreadsheet source [here](https://docs.google.com/spreadsheets/d/1iid0PnO5UTMECW2RylVwEOECFbW5iWsJSHmP4zj7Lr4/edit?usp=sharing). ### Status quo: ![](https://storage.googleapis.com/ethereum-hackmd/upload_3275cf10d6874f0837b08b17160231ee.png) ### EIP 1559: ![](https://storage.googleapis.com/ethereum-hackmd/upload_a5b82e76e3e6820dbd6e1d117f034e17.png) ## What would EIP 1559 do under larger and more prolonged spikes (eg. day-long spikes) Not much. The BASEFEE would rise and there would be a short period at the beginning where a few transactions get in faster, but after that the fee market would function just as it would under "ordinary" conditions, just at a higher fee level. The main benefit of EIP 1559 in spikes is that the harms from inefficiency of regular fee markets are magnified when fees are high, so having a functioning fee market becomes more important. ## If the chain _can_ handle 2x block size spikes, doesn't that mean the chain can handle just making _all_ blocks 2x larger? No. See this post for why: https://notes.ethereum.org/@vbuterin/eip_1559_spikes ## Why limit = target * 2? Why not 4? Or 8? It could easily be higher than 2. The higher the limit/target ratio the greater the fee market efficiency benefits of EIP 1559. It depends on how severe the short term spikes are that we are willing to accept; 2x is fairly conservative. We could even launch EIP 1559 with a limit/target of 2 to start off, and increase it over time as we see the network functioning okay even under short-term spikes. ## Why would miners include transactions at all? The EIP includes a "tip" that transaction senders can include, that goes to the miner. The tip has two functions: first, if there are suddenly far more transactions than expected, miners will include transactions with higher tips first, so the fee-based prioritization mechanism exists as a backup. Second, it compensates miners for uncle risk (the increased risk their block will not be included in the main chain because adding one more transaction will slow it down). The tip level that compensates for uncle risk has been calculated to be about 0.8 gwei (uncle blocks get on average a 1.67 ETH reward instead of the 2 ETH base, so that's a ~0.33 ETH = 330m gwei loss, 12.5 million gas blocks add ~0.031 to the uncle rate ckompared to empty blocks, so the expected cost of 1 gas is = 330m / 12.5m * 0.031 = 0.825 gwei) and miners do actually set about this value when the chain is empty. This tip level is independent of the BASEFEE, so client implementations can confidently set 1-1.5 gwei and expect their transactions to be accepted. ## How might wallets choose tips? Is there a risk of bidding wars for tips? Wallets could simply choose tips by looking at what tips have been accepted on chain historically, and increasing their tip if they see that a transaction they send was not accepted immediately. Note that in "normal conditions" there is no incentive to set a tip higher than the bare minimum. In cases of sudden congestion, tips _do_ degrade into a bidding war; wallets can detect congestion, and in this case they could offer users the option of setting low or high priority for their transaction. ## What is the escalator mechanism? How might the escalator mechanism be combined with EIP 1559? The escalator mechanism is a different proposed transaction fee reform, where instead of specifying a single fee, users specify their fee as a function, usually with a beginning, an increase-per-block and a maximum, for example "5 gwei if this transaction is included in block 10123456, add 1 gwei for every block after that (eg. 8 gwei if included in block 10123459), up to a maximum of 100 gwei". This would be four parameters: beginning fee, beginning block, per-block increment, max fee. The goal is to be "safer" against mistakes in fee estimation, as if the fee turns out to be too low it would naturally rise over time until the transaction is included. In an EIP 1559 context, this could be used to set the tip. The fact that the tip would generally be in a constant range means that even a wallet using fixed parameters for the escalator would deliver reasonably good outcomes to users. ## Won't miners have the incentive to collude to push down the BASEFEE by making all their blocks less than half full? In general, the effectiveness of such strategies is limited, because unless truly almost everyone colludes, a transaction not included in one block will get included will just get included in the next block and so the effect of this action on the long-run BASEFEE will be negligible. However, what miners _can_ do is a kind of "monopoly pricing". Suppose transaction senders are willing to pay some extra fee to avoid getting delayed one block. Miners can refuse to include transactions that do not include some minimum tip `T`; they lose out on some fee revenue, but gain from senders increasing their fees if they value the extra probability you will be the next miner and include their transaction highly enough. This strategy is heavily tilted against the miner: they suffer the full cost of lost fee revenue, but gain only a small portion of the increased transaction fees that others send. Note that even if a miner using such a strategy is successful, they will increase other miners' revenue more than it will increase their own revenue (as other miners free-ride on the higher tips due to your actions), so it is not a centralization vector. This will _not_ reduce BASEFEEs down to zero; rather, it will hit an equilibrium where BASEFEEs remain the bulk of the fee and tips take up the remainder. This is because unless miners are all colluding (in which case we have bigger problems), miners suffer the entire cost of not including transactions but gain only some of the benefit of tips being higher. **If the risk of miners deploying such a strategy is _still_ deemed unacceptably high, we can direct some (eg. 50%) of the revenue from EIP 1559 into a pool from which a small percentage is drained every block to be added to the miners' block reward**; this ensures miners benefit from the BASEFEE being high, further reducing the gains from such an attack. Here is a proposed sketch of a change to the EIP to do this: * Define the account 0x35 as `FEE_SMOOTHING_BUFFER`, and define `FEE_SMOOTHING_CONSTANT = 8192` * Add an additional term to the block reward (added at the same time as the base block reward and uncle+nephew rewards). Let `smoothing_reward = FEE_SMOOTHING_BUFFER.balance // FEE_SMOOTHING_CONSTANT`. Transfer `smoothing_reward` wei from `FEE_SMOOTHING_BUFFER` to `block.coinbase` * After applying the block rewards, 1/2 of EIP-1559 fees from that block (rounding down) get added to `FEE_SMOOTHING_BUFFER`'s balance. The remainder (ie. 1/2 rounding up) gets burned. Note that in a proof of stake context, it would be desirable to implement secret leader elections along with penalties for early revelation, to prevent validators from acquiring reputations as only accepting high tips and gaining the entire benefit of this themselves as transaction senders would know which validators are creating blocks soon. ### Other resources * The original paper: https://ethresear.ch/t/first-and-second-price-auctions-and-improved-transaction-fee-markets/2410 * ethresear.ch thread on Barnabe's simulations: https://ethresear.ch/t/eip-1559-simulations/7280 * Tim Roughgarden's report: http://timroughgarden.org/papers/eip1559.pdf

Import from clipboard

Advanced permission required

Your current role can only read. Ask the system administrator to acquire write and comment permission.

This team is disabled

Sorry, this team is disabled. You can't edit this note.

This note is locked

Sorry, only owner can edit this note.

Reach the limit

Sorry, you've reached the max length this note can be.
Please reduce the content or divide it to more notes, thank you!

Import from Gist

Import from Snippet

or

Export to Snippet

Are you sure?

Do you really want to delete this note?
All users will lost their connection.

Create a note from template

Create a note from template

Oops...
This template is not available.


Upgrade

All
  • All
  • Team
No template found.

Create custom template


Upgrade

Delete template

Do you really want to delete this template?

This page need refresh

You have an incompatible client version.
Refresh to update.
New version available!
See releases notes here
Refresh to enjoy new features.
Your user state has changed.
Refresh to load new user state.

Sign in

Sign in via SAML

or

Sign in via GitHub

Help

  • English
  • 中文
  • Français
  • Deutsch
  • 日本語
  • Español
  • Català
  • Ελληνικά
  • Português
  • italiano
  • Türkçe
  • Русский
  • Nederlands
  • hrvatski jezik
  • język polski
  • Українська
  • हिन्दी
  • svenska
  • Esperanto
  • dansk

Documents

Tutorials

Book Mode Tutorial

Slide Mode Tutorial

YAML Metadata

Resources

Releases

Blog

Policy

Terms

Privacy

Cheatsheet

Syntax Example Reference
# Header Header 基本排版
- Unordered List
  • Unordered List
1. Ordered List
  1. Ordered List
- [ ] Todo List
  • Todo List
> Blockquote
Blockquote
**Bold font** Bold font
*Italics font* Italics font
~~Strikethrough~~ Strikethrough
19^th^ 19th
H~2~O H2O
++Inserted text++ Inserted text
==Marked text== Marked text
[link text](https:// "title") Link
![image alt](https:// "title") Image
`Code` Code 在筆記中貼入程式碼
```javascript
var i = 0;
```
var i = 0;
:smile: :smile: Emoji list
{%youtube youtube_id %} Externals
$L^aT_eX$ LaTeX
:::info
This is a alert area.
:::

This is a alert area.

Versions

Versions and GitHub Sync

Sign in to link this note to GitHub Learn more
This note is not linked with GitHub Learn more
 
Add badge Pull Push GitHub Link Settings
Upgrade now

Version named by    

More Less
  • Edit
  • Delete

Note content is identical to the latest version.
Compare with
    Choose a version
    No search result
    Version not found

Feedback

Submission failed, please try again

Thanks for your support.

On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

Please give us some advice and help us improve HackMD.

 

Thanks for your feedback

Remove version name

Do you want to remove this version name and description?

Transfer ownership

Transfer to
    Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

      Link with GitHub

      Please authorize HackMD on GitHub

      Please sign in to GitHub and install the HackMD app on your GitHub repo. Learn more

       Sign in to GitHub

      HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.

      Push the note to GitHub Push to GitHub Pull a file from GitHub

        Authorize again
       

      Choose which file to push to

      Select repo
      Refresh Authorize more repos
      Select branch
      Select file
      Select branch
      Choose version(s) to push
      • Save a new version and push
      • Choose from existing versions
      Available push count

      Upgrade

      Pull from GitHub

       
      File from GitHub
      File from HackMD

      GitHub Link Settings

      File linked

      Linked by
      File path
      Last synced branch
      Available push count

      Upgrade

      Danger Zone

      Unlink
      You will no longer receive notification when GitHub file changes after unlink.

      Syncing

      Push failed

      Push successfully