The Life of EIP
The lengthy introduction below, full of definitions and categorizations, is meant to lead to an answer to the question of how we can get EIP-1559 into the Ethereum mainnet faster. Actually this is not just about EIP-1559 — it extends to any EIP which the Ethereum community has been awaiting the implementation of.
To begin, let’s take a look at why we introduce EIPs in the first place. The main goals of EIPs are to increase Ethereum adoption, improve Ethereum scalability, and improve Ethereum security
If we go one level deeper, then we can see what types of EIPs we can introduce, keeping the main goals mentioned above in mind:
● Protocol bug fix (EIP-7 fixing CALLCODE with DELEGATECALL)
● Security improvements (EIP-155 replay attacks defence)
● Adjust gas costs to better reflect the cost of opcodes (MODEXP precompile repricing)
● Decrease the gas cost via optimization (precompile gas cost changes, algorithm improvements) (BLS-281 algorithm improvements)
● Introduce new features (BLS-281, REVERT, SHL, SHR, SA, etc)
There are also some EIPs that affect the economy of Ethereum blockchain. These include:
● Block reward adjustments
● ProgPoW
● EIP-1559 base fee in gas prices
EIPs are proposed/created when people submit PRs to the EIP list. These ideas can stem from other ideas from ethresear.ch, Twitter, or even an individual’s own ideas.
The process itself of inclusion of an EIP is a result of multiple processes coming together:
● EIP process (state transition of an EIP from the first PR all the way to the mainnet deployment)
● Discussions Discord, Telegram, Gitter, etc.
● ethresear.ch discussions
● Ethereum Magicians discussions (set of Eth 1.x changes)
● Workgroup calls and workshops
● EIP specific discussions (e.g. EIP-1559 calls)
In general, we expect that any informal/private discussions on EIPs happen in the early stages and are all formalized and publicized by the time an EIP is deployed on the mainnet.
Moreover, we expect that there are multiple safety features in the process that prevent strictly political EIPs to make it to the mainnet. What kind of EIPs would fall into this category?
● EIPs which provide an advantage to a particular product or group of people without bringing net positive benefits to all network users.
● Damaging / trojan horse EIPs (advertised as an improvement by those who wish for Ethereum to fail).
We also want to ensure that any smoke bomb/distraction EIPs are discarded as early in the process as possible. These are the kind of EIPs where the proposer does not expect it to be damaging, nor even expect them to ever make it to the mainnet, but suggests them in order to keep the discussion contentious and make participants (All Core Devs) polarized, busy and tired.
Recently, we also raised an issue of ‘rejected by default’ vs ‘accepted by default’ for EIPs making their way to the mainnet. Are the silent AllCoreDevs meaning they approve the EIP or disapprove? Is it enough to have one vocal proponent to let EIPs in? Is it enough to have one vocal opponent to reject an EIP?
Finally, what are the components necessary for the EIP to be properly triaged and tested? Those components include:
● Spec needs to be written
● Clients need to have EIP implementations ready
● Test teams have to prepare the consensus tests (and other types of tests as necessary)
● Security teams need to verify all potential EIP interactions, attacks and risks taking into account various hardware and programming languages and cryptographical techniques.
● Community needs to approve the change
Now, after we have all these bullet lists above, we can think of how the current network upgrades are prepared (explained in another list):
1. We announce the next network upgrade (Berlin, London, Shanghai, Cancun, etc.). The expectation usually is for the upgrade to go live within the next 6 months or so
2. We look at the list of EIPs that made it reasonably far (have you played Fall Guys?)
3. Next, something like an old-style stock exchange auction happens — people gather in the pit and start shouting their EIP numbers
Some of the EIPs do not make it here (again, have you played Fall Guys?)
4. There is a debate where all the previously mentioned things happen — smoke bombs, political EIPs, tests, security, economics, etc.
5. A group of EIPs make it together into some kind of pre-testnet
This is where we encounter a problem. If we have, say, a bundle of 12 EIPs at this stage then as a core developer you:
● think some of them are smoke bombs
● think some of them are political
● think some of them are critical for security
● think some of them are great for adoption and community
● think some of them are not specified / tested enough
That said, it only makes sense to try and make sure that only the valid ones make it further. Let us say that ACDs manage to get rid of the stinkers. We are then left with, say, 6 EIPs. Another problem arises — some of them are very easy to implement (5 minutes gas cost change for an opcode) and others are huge (BLS-371). You could introduce the former ones to the mainnet within a few weeks with proper testing, but you cannot introduce the latter ones without 3 months of tests + fuzzing.
Once we start implementing a testnet and we end up with something like the below:
There is one thing in the table above that is particularly interesting — EIP-A may be an easy security improvement or an easy but massive adoption/usability improvement, but it waits for a range of other EIPs that go through a difficult and lengthy process.
Let me suggest an improvement which is based on multiple previous discussions around the EIP oriented process.
Let each EIP has the following table:
The only clients on the list would be clients that are capable of syncing Ethereum Mainnet (whichever way that allows to verify the following blocks).
Then let us say that after > 33% (2 out 5, 2 out of 4, 2 out of 3, 3 out of 6) clients have the EIP implemented then an EIP-testnet is created. For the EIP testnet to appear we need the following things:
- a genesis file / chainspec for the network
a. chain id
b. genesis block details
c. initial state
2. set of transactions to execute or a transactions generator to fill the tx pool
Now we can arrive at this stage in one of the following ways:
● multiple client implementers believe that the EIP is beneficial
● EIP champions / proposers sponsored implementation of the EIP in two of the major clients
After the EIP-testnet is established, the security and network economics researchers can start analysing the behaviour of the EIP. The community now has an opportunity to access the network by recreating it with one of the clients with the implementation. This is also the time when the EIP should be discussed further at ACD calls.
After there is enough interest in the EIP, the remaining clients need to be able to successfully sync the EIP-testnet network before the EIP is accepted for the test teams.
After the EIP-testnet is synced with by at least 66% of the clients (4 out 5, 3 out of 4, 2 out of 3, 4 out of 6) the test teams start to use the synced network as a battleground for analysis of the network behaviour and prepare official consensus and security or fuzz tests for all of the clients to pass. This is also the time when the final gas costs can be decided (estimates are used by the early implementing clients which is especially important in the EIPs that deal with the gas costs themselves).
Now, based on all of the above — what are the benefits?
● For any EIP that is implemented by all the clients we can upgrade it to a major testnet (Rinkeby, Goerli, Ropsten) without having to wait for other EIPs
● For any EIP that has a strong opposition — it can be rejected without affecting the whole bundle
● Community sponsorship of EIP implementations can be much more predictable and targeted
● Any dependencies between EIPs can be resolved so that:
● If we have dependencies A<-B (A is required before B can go in), A<-C
■ We can create all of the A-testnet, AB-testnet, AC-testnet separately
■ A can be deployed separately when ready and when there is reasonable expectation that A has a value on its own.
■ Any potential A<-D dependency is more likely to be introduced
All said, I believe that EIP-1559, thanks to much support from the community, can be soon more mature (pending economic analysis of EIP-1559) than the bundle of EIP-s going into Berlin that is debated during each ACD call. However, without changing the process to more EIP oriented we will not be able to deliver it until after Berlin is deployed and probably with multiple other EIPs delaying London even further.
