What are EIPs, how do they work, and what is it about EIP-1559 that has attracted such attention?
In this post, we’ll give an overview of EIP’s purpose, structure, process and outcomes as well as looking under the hood of the Ethereum gas fee debate.
If you want a real grounding in the subject, start here.
If you just want to know about EIP-1559 and EIP-3368, skip the first part of this post and jump straight to them.
Let’s begin at the beginning:
What is an EIP?
EIP stands for Ethereum Improvement Proposal. These are design documents that inform the Ethereum community, and particularly its core developers, about new features on Ethereum or changes to the ecosystem’s structure, processes, or environment.
EIPs are designed to provide both precise technical specifications of a new feature and rationale for adopting it. They’re a little like technical white papers, a little like design specs and a little like a legislative proposal in a Parliament. Just like a proposed new law, the person who brings up an EIP is responsible for persuading and convincing others in the community and building consensus around the new proposal.
What are EIPs used for and how do they work?
EIPs follow a structure and there is a defined EIP workflow.
EIP structure
Most successful EIPs are laid out like this:
- Preamble
- Simple Summary
- Abstract
- Motivation
- Specification
- Rationale
- Backwards Compatibility
- Test Cases
- Implementations
- Copyright Waiver
The EIP workflow
EIPs follow a defined workflow, with every stage except the first tracked in the EIP repository.
Idea: An idea for an EIP, with no draft or other materials yet assembled.
Draft: This is the first formally-tracked stage of an EIP. It’s merged by an EIP Editor into the EIP when it’s properly formatted.
Review: An EIP Author (many EIPs have more than one Author) marks the EIP as ready and requests Peer Review.
Last Call: The final review window for an EIP before it’s moved on to Final. An EIP Editor assigns Last Call status and set a review end date, typically 14 days later.
Final: An EIP that has been adopted and integrated into the Ethereum codebase or protocols. It’s updated only to correct any errors or to add clarification.
Stagnant: Any EIP in Draft or Review stages that has been inactive for six months or more is moved to Stagnant, though EIPs can be resurrected by Authors or EIP Editors by moving it back to the Draft stage.
Withdrawn: EIPs that have been withdrawn by their Authors. Withdrawn EIPs can’t be resurrected, and if the same idea is pursued at a later date, it is considered a new proposal.
Living: A special status for EIPs that are designed to be continually updated and never reach a state of finality, notably including EIP-1. Changes to these EIPs move between Review and Living as they are reviewed and approved.
EIP types
EIPs come in three types:
- Standards Track
- Meta
- Informational
Standards Track
Standards Track EIPs describe any change that affects most or all Ethereum implementations; accepting the EIP means establishing a new Ethereum-wide standard, hence the name. This includes changes to the network protocol, block or transaction validity rules, or application standards and conventions. If a proposal would alter the way the whole Ethereum chain works, it’s a Standards Track proposal.
Standards Track proposals come in three parts:
- Design document for the proposed changes.
- Implementation
- Update to the formal specification
Standards Track EIPs break down into four subcategories:
Core
Improvements that require a fork, are relevant to “core dev” discussions, or touch on miner/node strategy changes.
Examples:
Networking
Improvements to networking like devp2p Wire, the Light Ethereum Subprotocol, and network protocol specifications.
Examples:
Interface
Improvements to client API/RPC specifications, language-level standards like method names, and contract ABIs. These EIPs are initially discussed in the Interface repository before being submitted to the EIP repository. Examples:
ERC (Ethereum Request for Comments) Application-level standards like token standards, name registries, library/package formats, URI schemes and wallet formats.
Examples:
Meta
Meta EIPs describe processes surrounding Ethereum or propose changes to those processes. They’re like Standards Track EIP, but they apply to other areas than the core Ethereum protocol itself. They may propose an implementation, but to something other than Ethereum’s codebase. Meta EIPs include improvements to procedures, guidelines, the decision-making process, or the tools and environments used in Ethereum development. Meta EIPs are also considered Process EIPs.
Examples:
Informational
If Standards Track EIPs are like legislative proposals, Informational EIPs are more like journalism: they don’t represent community consensus or recommendations. Users are free to ignore Informational EIPs.
Examples:
Most important EIPs
These are some of the most important EIPs, showing how EIPs made Ethereum what it is today and how they are still being used to effect changes that have the backing of developers and the Ethereum community.
EIP-1: Purpose and guidelines
Lays out how all other EIPs are to function. Includes a style and citation guide as well as stage and type classifications and structure recommendations.
EIP-2: Homestead Hard Fork changes
Creates a hard fork and changes gas fees to incentivise contracts as well as transactions. It also created the out-of-gas effect for contract and adjusted block minting difficulty to incentivize miners to target mean rather than median block creation time.
EIP-5: Gas usage for Return and Call
Changes gas usage rules or contracts so that gas is only charged for memory that is actually written to in Ethereum Virtual Machine and unused gas is returned.
EIP-20: ERC-20 token standard
Standard for the popular ERC-20 token, which underlies many modern Ethereum applications.
EIP-2718: backward compatibility through transaction envelopes
Until EIP-2718, all Ethereum transaction types had to be defined and backward-compatible. They could be differentiated only through their encoded payload and though many did important work (such as letting someone other than msg.sender pay the gas for a transaction), they also entailed unnecessary complexity. EIP-2718 wrapped all transactions in a single envelope to make compatibility easier and simplify the process.
Though this list is selective it does illustrate how EIPs have allowed the Ethereum community to shape it into a business-friendly blockchain one step at a time, altering its functionality to deliver better results without ever having to take it offline and without the intervention of a central authority (which would be impossible in a blockchain like Ethereum).
Now let’s look at two of the most important EIPs of recent months, EIP-1559 and EIP-3368.
EIP-1559: Radical change in gas fee structure
Building on EIP-2718, EIP-1559 (co-Authored by Vitalik Buterin) suggests restructuring the way Ethereum charges for gas on transactions.
Currently, gas fees are an auction. Miners control which transactions are included in a block, are paid in gas, and pay for inclusion with computational power. Thus they’re incentivised to seek the most gas for the least computation, preferring high bids from large transactions or transaction blocks.
This has its problems anyway, exacerbating congestion on the already-congested Ethereum mainchain, but as DeFi becomes more important in the digital assets space a fee system that disincentivizes small or complex transactions also disenfranchises smaller-scale users and many DeFi applications.
EIP-1559 identifies four issues with the current gas fee structure:
- Mismatched transaction fee volatility and transaction social costs. Bids to include transactions on full blocks are extremely volatile and don’t reflect the real cost to the network.
- Slower user experience. Hard per-block gas limits and transaction volume volatility mean transactions often wait for several blocks before being included even though there’s no need for this to happen and no-one gains from it.
- Inefficiency of first-price auctions. Currently, transaction senders publish their transaction with a bid that represents the maximum fee they’re willing to pay, often several times the fee they expect to pay. Miners choose the highest-paying transactions. This process is highly inefficient and even complex fee estimation algorithms do not make up for it, meaning, among other things, frequent fee overpayment.
- Technical issues around blockchains with no block reward. Where there’s no issuance reward, blockchains tend to reward miners entirely through transaction fees. But there are issues with this, like incentivizing “sister blocks” that steal transaction fees, opening selfish mining attack vectors, and more, that make it a source of instability for which there is currently no good solution.
In other words the current fee system is unstable, inefficient and unfair.
The solution EIP-1559 proposes is to split gas fees in two. There will be a base fee amount, adjusted to reflect the congestion on the network but constrained and therefore predictable within limits. On top of this, an inclusion fee will be paid to miners. The result should be much more predictable fees but it will sharply reduce miners’ incomes. In large part this is because miners will be paid only the inclusion fee. The base fee will be burned each time, meaning ETH could become deflationary and miners are disincentivised from gas fee manipulation.
Understandably, this solution has not been popular with Ethereum miners, which brings us to EIP-3368.
EIP-3368
EIP-3368 is in some ways a counter-offer to EIP-1559. It’s occasioned by the concern that “A sudden drop in PoW mining rewards could result in a sudden precipitous decrease in mining profitability that may drive miners to auction off their hashrate to the highest bidder while they figure out what to do with their now ‘worthless’ hardware.”
The fix for this is a set fee of 3 ETH per block, decaying gradually to 1 ETH per block over two years. Essentially the purpose is to allow miners time to transition out of ETH mining, which will become unprofitable with the proposed advent of Eth2 anyway as the mainchain moves over to PoS.
It’s worth noting that EIP-1559 is in Review stage, meaning it’s quite likely to be implemented, especially since it solves a current major problem for Ethereum — spiralling transaction costs that are making off-chain, Layer 2 or even non-Ethereum chain solutions look more attractive.
By contrast, EIP-3368 is still in Draft; although responses to both have been merged on the Ethereum repository, its Authors state:
“This proposal should ONLY be considered as a last resort as something we have in our pocket should the ‘network need to attract hashing power quickly and then bleed it off over time’ rather than ‘something that is scheduled to be included in X hard fork’ ; Recommendation to have in a fast track state, but NOT deployed to mainnet unless needed.”
In short, then, we should all be preparing for big changes in Ethereum’s gas fee structure.