Why 1559? - HackMD

--- tags: 1559 --- # Why 1559? *EIP-1559 is fairly complex. This post is an attempt to explain its benefits as simply as possible. Note: the drawbacks of 1559 are not in scope for this post. These are left to the "Security Considerations" section of the EIP.* Since originally writting this post, the official terms in the EIP have changed. For reference, `baseFeePerGas` == `BASE FEE`, `maxFeePerGas` == `maxFee` == `FEE CAP`, `maxPriorityFeePerGas` == `priorityFee` == `tip/miner tip/etc.`. ## EIP-1559 Benefits [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) is a proposed change to Ethereum's fee market. The proposal would provide UX, economic and security benefits to Ethereum. ### UX Benefits #### Generally Quicker Transaction Inclusion Under the current fee market, transactions on Ethereum often end up pending for a long time. Because blocks are always full, each new block is filled with the highest paying transactions since the last block. If a transaction is not immediately included (usually requiring a very high gas price), it is hard to estimate when it will be included. Under EIP-1559, blocks can be up to "200% full", meaning that if the gas limit is set to, say, 15m gas, blocks up to 30m gas will be valid. Blocks will also include the minimum price required for transactions to be included in them, the `BASE FEE`. When blocks are >100% full, the `BASE FEE`, goes up. When blocks are <100% full, it goes down. This implies that most of the time, blocks will have an "extra" 100% of their capacity that they can fill with transactions. So, as long as a transaction is sent with a fee higher than the `BASE FEE` and includes a tip for the miner, it will be included in the next handful of blocks. The `BASE FEE` could obviously go up between the time a transaction is sent and it is included. To help with this, transactions specify the maximum they are willing to pay for inclusion, the `FEE CAP`. The transaction sender is refunded the difference between their `FEE CAP` and the `BASE FEE` (which is burnt) and the `TIP` (which goes to miners). Another way of looking at this is that 1559 makes the inclusion price of transactions _explicit in the protocol_, rather than implicit, as it is right now. For example, if the "market price" for inclusion is 100 gwei and a user wanted to be sure of rapid inclusion, today their incentive would be to pay >100 gwei (which is hard to estimate given that this value is not part of the protocol) and their full bid is what would be used to calculate the transaction price. Under 1559, if the `BASE FEE` was 100 gwei, a user could put a `FEE CAP` of, say, 200 gwei, a tip of, say, 3 gwei, and they would only pay their inclusion block's `BASE FEE` and `TIP`. The difference between that and the 200 gwei `FEE CAP` would be refunded to the sender. For a longer example about the impact of this on (especially new) end users, see [this](https://medium.com/@MicahZoltu/a-tale-of-two-pricing-schemes-dc9c8717906). One caveat to this is the case where blocks are already "200% full". In those cases, the fee market will revert to an auction based on transactions with the highest tips, a.k.a. our current system. Given the speed at which the `BASE FEE` increases (~10x every ~5 mins), these periods are expected to be short-lived. In other words, today's "average case" becomes the "worst case" scenario under 1559. #### Better Transaction Fee Estimation Another notable UX improvement under 1559 is making transaction fee estimation easier, both for 1559-style and legacy-style transactions. As mentioned earlier, estimating the right price for a 1559-style transaction is trivial: set the `FEE CAP` high above the `BASE FEE`, or at one's maximum willingness to pay for the transaction, set the `TIP` to an amount high enough to compensate miners for their computation cost and risk of uncle blocks (wallets can set this value by default and update it over time, so end users don't necessarily need to set it manually). Interestingly, easy fee estimation for 1559-style estimations will also lead to better fee estimation for legacy transactions (which will still be supported). By looking at the historical `BASE FEE` and `TIP` values, transaction estimating services will be able to provide better estimates than they currently do. For a technical explanation of why that is, see [this](https://github.com/barnabemonnot/abm1559/blob/master/notebooks/transition1559.ipynb). ### Economic Benefits #### Requiring Transaction Fees to be Paid in ETH Otherwise known as "preventing economic abstraction of ETH". EIP-1559 would require that all transactions pay a `BASE FEE` in protocol, using ETH. While this may sound trivial, under the current fee market, there is no guarantee that transaction fees be paid to miners in ETH, or paid by miners at all when including their own transactions on-chain. In other words, today, one can pay a miner off-chain (or on-chain with another asset such as DAI, USDC, etc.) to have them include their transaction at a cost of 0 gas price ([example](https://etherscan.io/tx/0x77c7d9e5427749fb1379cb02ec8e5117fa3277e743e5556c134de812605a6dde)). This could lead to ETH not being the primary currency of the Ethereum network. Under 1559, because the `BASE FEE` is burnt during the transaction execution and has to be paid in ETH, transaction fees would need to be paid on-chain. Miners would obviously be free to receive payments for transactions otherwise, but they would then need to acquire ETH to pay the `BASE FEE` for the transactions paid in another fashion, which is economically equivalent to users paying their transaction fees in ETH directly. #### Higher Block Space Demand Creating a Deflationary Pressure Given that the `BASE FEE` is burnt as part of every transaction and that as there is more demand for block space on Ethereum, the `BASE FEE` rises, sustained high demand for Ethereum block space will create a deflationary pressure on the supply of ETH. In other words, the more people want to use Ethereum, the higher the `BASE FEE`, the more ETH gets burnt both in aggregate and _per transaction_. This is in line with the philosophy of ["minimum viable issuance"](https://docs.ethhub.io/ethereum-basics/monetary-policy/) and creates a positive feedback loop between network usage and network value. ### Security Benefits #### Mitigating Risks of Near-Head Re-Orgs As the sum of transaction fees in block rises, miners have an increasing incentive to perform small re-orgs of the chain near head to capture high-paying transactions into one of their blocks rather than let a competing miner pocket the fees. A proper analysis of this phenomenon is available [here](https://www.cs.princeton.edu/research/techreps/TR-983-16). Under 1559, because the vast majority of the transaction fees are burnt, miners have a much weaker incentive to perform near-head re-orgs. #### Making DoS/Spam Attacks Exponentially Costly Over Time Today, if an attacker wants to DoS or spam the network, they can do so at constant cost, and potentially below market cost if collaborating with miners. An attacker wanting to DoS or spam the network simply needs to pay a gas price sufficent for miners to include their transactions, and this gas price is independent of other transactions being included in the chain. If collaborating with the miner, they could pay a below-market rate for their transactions, as the miners could include them on chain for a low or zero gas price. Under 1559, because blocks can grow to be up to 200% full, if an attacker wants to spam the network using significant blockspace, it will cause the `BASE FEE` to increase. This implies that the attack gets costlier over time (i.e. non-attacking miners could keep including other users' transactions), and that the attacker _cannot_ include their transactions on chain for less than the `BASE FEE`.