What is ethereum?
What is Ethereum? While thousand answers you may get, this article wants to explore the most consistent one, namely what is ethereum protocol? More technically - if I want to develop an Ethereum client (PoW chain/ ETH1), which rules should I to follow
It’s difficult to find a spec describing the current consensus rules for ethereum, because it is defined by incremental updates. The ethereum yellow paper describes the full protocol in genesis, and each protocol change is called a hardfork (though some guys would love to use 'network upgrade' instead), requiring mandatory update for all clients. In short, ethereum protocol layer changes through a hard fork, the smallest unit of change is called an EIP (Ethereum Improvement Proposal), and a hardfork contains a bunch of EIPs.
Introduction of Past Hardforks
Overview
All past hardforks of ethereum can be found in this page. Since its launch in 30 July, 14 hardforks has been activated with 39 EIPs included. The two closest hardforks were 26 days apart while the two furthest apart were 490 days apart.
These hardforks are divided into 'active' and 'passive'. Active hardforks refer to improvements made to ethereum on the initiative of core developers, while passive ones are actions that "have to be" taken to address potential security risks. The passive hardforks include at least "DAO Fork", "Tangerine Whistle", "Spurious Dragon", "Muir Glacier", "Arrow Glacier", "Gray Glacier", which either dispose of hacker theft (DAO Fork), or respond to DDOS attacks (Tangerine Whistle, Spurious Dragon), or just deal with difficulty bombs (Muir Glacier, Arrow Glacier, Gray Glacier). The active hardforks are broadly in line with the whitepaper's roadmap (at least in terms of naming) for Frontier (Frontier, Frontier Thawing), Homestead, Metropolis (Byzantium, Constantinople/Petersburg, Istanbul), while Berlin and London are transitional upgrades following changes to the roadmap change. In addition, multiple active hardforks include the option to delay the difficulty bomb.
How did the core devs reach consensus on each hardfork? Although the formal process of a hardfork is not written down, but rather follows a certain convention, the process has changed once with "EIP-centric upgrade" proposed by Martin Holst Swende. This new hardfork negotiation mechanism was first used in Berlin hardfork and avoided a huge disaster, details of which will be described later.
Representative Hardforks
Behind some hardforks lie some rather dramatic events, including the DAO fork, the Shanghai DOS, a tale of two “burgs” and “The Hurt Locker”.
DAO Fork
The DAO fork was an event that had a huge impact on the development of ethereum. Due to the hacking of the DAO's smart contract, about 3.6 million ether was stolen by hackers, however thanks to the the 28-day freeze period. During this period, with the help of Carbonvote, ether holders expressed their will and the Ethereum Foundation decided to transfer hacked asset to a new smart contract, allowing investors to withdraw. This fork gave birth to Ethereum Classic, which also sparked a great deal of social controversy.
Shanghai DOS
During Devcon2, ethereum core developers gathered in Shanghai, while the ethereum network was hit by a massive network traffic attack that caused a denial of service (DOS).
Due to the EXTCODESIZE opcode, which has a fairly low gasprice but which requires nodes to read state information from disk, the attacker repeatedly invokes the opcode, causing most full nodes to fail to catch up with the latest blocks. EF coordinated with the mining pools and the full node to switch to Parity mining which is less affected , while negotiating a reduction in block gas limit (from 5 M to 1.5 M).
Eventually, the impact of the DOS attack was mitigated by adjusting the price of the relevant opcodes and doing a state clearing with the help of Tangerine Whistle and Spurious Dragon. The hardfork also had a follow-on effect, causing a consensus fork due to a poor implementation of EIP-161 (included in Spurious Dragon) (Go-ethereum and Parity did their own implementation incorrectly respectively).
A Tale of Two “burgs”
You may wonder why there are two hardforks, "Constantinople" and "Petersburg", at the same height of 7280000, while the only difference is that EIP-1283 has been removed from "Peterborough".
According to ChainSecurity's report, EIP-1283 introduces the risk of re-entry attacks for some smart contracts. Trail Of Bits gives a more detailed analysis and provides a list of contracts that could be affected. 32 hours before the hard fork activation, the Ethereum Foundation sent a message reminding nodes to upgrade or downgrade to postpone the Constantinople upgrade. A new release containing the Peterborough hardfork was published, where clients need to configure the "two burgs" on the same height or disable Constantinople.
“The Hurt Locker”
The reason why there were only 26 days between the Muir Glacier and Istanbul is because the core developers miscalculated the time for the difficulty bomb to explode, resulting in a proposal to delay the difficulty bomb not being included in Istanbul. By the time it was discovered that the difficulty bomb was about to have an impact, EIP-2384 was quickly accepted at ACD 76 and inclueded into the Muir Glacier.
Hardfork Decision Process Changes
How was a hardfork decided? In fact, Ethereum has long lacked written specs, relying more on "social consensus" (correct me if wrong.) EIP-233 attempted to standardize the formal process of the fork, but it was stagnant.
While this article cannot show the discussion of the hard fork decision process in the community, it is clear that the hard fork process of ethereum has changed. Prior to the Berlin hard fork, developers first determined the timing of the hard fork, then decided which EIPs to include, and then implemented and tested them after that. Each pre-Berlin hard fork was described as a Meta EIP, such as the Istanbul hard fork defined through EIP-1679 (HFM-1679 for short).
Martin Holst Swende proposed EIP-centric forking process. The core idea is to divorce EIP acceptance from the hardfork, with core developers focusing on the blessing, implementation, and testing of individual EIPs, which subsequent hardforks can choose to include once an individual EIP is accepted. Although it has not been found at the time of writing how and when this process was accepted by the core developers, the Berlin hard fork abandoned HFM-2070 and instead adopted the process proposed by Martin.
This quickly had a positive effect, as the developers debated and eventually removed EIP-2315 two weeks before the Berlin test network was activated. Due to the adoption of the new process, the last-minute change did not affect the hardfork too much and it eventually went ahead as scheduled. For more details, please refer to my article "Removing EIP-2315: The Emergency Brake Before the Ethererum Berlin Hardfork(in Mandarin)".
A non-change change
It is worth mentioning that the block gas limit of ethereum is not part of the consensus. Miners have the right to change the block space limit, which varies by up to 0.1% per block. This value is not hard-coded mainly to avoid the risk of potential attacks. The history of this value change can be found in the report written by MyCrypto.
A Deep Dive into EIP
What impact do these EIPs actually have on ethereum, and who contributes to these decisions? This article collates all the EIPs (excluding meta-proposals) included in all hardforks, see the link below for details.
What do these EIP do?
The types of EIPs included into hardforks mainly contain gas metering adjust, new opcodes, difficulty bombs, economic models, pre-compilation, security considerations, etc.
Gas Metering Adjust
The amount gas metering adjust related EIPs is 10, hit the most, accounting for 25.6%.
By increasing or decreasing the unit price of opcodes to balance the mismatch between gas consumption and actual system resources consumed, it can eliminate the potential for DOS attacks on the system or facilitate the deployment of specific types of applications. Some of the DOS pitfalls are caused by the wrong estimation of system resources, and EIP-150 and EIP-160 solve this problem; while some other DOS pitfalls are inherent to the system, and the actual resource consumption for accessing state data grows with the growth of state of ethereum, so the unit price of the corresponding opcode needs to be adjusted periodically, typically EIP-1884 (most convincing EIP imo).
Gas metering must be adjusted periodically due to ethereum state model, which is a feature, not a bug.
New Opcode
A total of 9 EIPs have introduced new opcodes for EVM (excluding EIP-1884), accounting for 23.08%. Some of the more influential ones include EIP-7 (DELEGATECALL), EIP-1014 (CREATE2), EIP-3198 (BASEFEE), etc.
Difficulty Bomb
A total of 6 EIPs, or 15.4%, are delaying the difficulty bomb. Two hardforks were accompanied by adjustments to the economic model, i.e. lower mining rewards for new blocks. Three of them were implemented only to delay difficulty bombs, i.e. hardforks with Glacier in their name. The history of the difficulty bombs can be found in the report “A Brief History of Difficulty Bomb” written by Primitives Lane.
Economic Models
Four EIPs had an impact on the economic model, two reduced the reward for new blocks, one adjusted the difficulty calculation model (EIP-100), and the more controversial EIP-1559 adjusted the fee market.
Pre-compilation
There are 4 EIPs that pre-compile some cryptographic operations so that they do not need to be executed in EVM, improving operational efficiency and reducing gas cost. These include EIP-152, EIP-196, EIP-197, EIP-198.
Security Consideration
There are 3 EIPs for security reasons, including replay attack protection (EIP-155), state trie cleaning (EIP-161), and contract code size limit (EIP-170).
Others
Other EIPs include network protocol improvements (EIP-8), the addition of a transaction execution status interface (EIP-658), the addition of a new transaction type (EIP-2718). In addition, EIP-2 contains all the updates to Homestead and is quite complex.
Who contribute to EIPs
A total of 43 people, 77 times, have contributed to these EIPs, with 11 authors contributing to at least 2 EIPs. Vitalik Buterin has contributed the most, with 17, or 43.6%. Martin Swende and Christian Reitwiessner have contributed 5 each, Alex Beregszaszi and James Hancock have contributed 3 each, and the rest have contributed no more than 2.
Martin Swende is the head of security at the Ether Foundation, a Go-ethereum engineer, and the author of the EIP-centric hard fork process; Christian Reitwiessner is the inventor of the Solidity language.
It is also interesting to note that the number of EIP authors changed significantly after the implementation of the new hard fork process, which may indicate that the new process has increased EIP participation. Pre-Berlin, 28 EIPs with 43 authors(person-times), an average of 1.54 authors per EIP; post-Berlin, 11 EIPs with 34 authors(person-times), an average of 3.09 authors per EIP, a doubling of the number of authors per EIP.
Another interesting finding is that all 43 authors are not anonymous or pseudonymous.
Conclusion
This article introduces all past hardforks during ethereum history, explains the representative events behind several hardforks and describes in detail the shift to an EIP-centric decision process for the ethereum hardfork. The article also provides an in-depth analysis of the role played by the EIPs in each hard fork and the contributors behind them.
As a new era of ethereum is about to dawn, the past comes to mind, when the ship comes in, my friend, how does it feel?
Extended Reading
https://github.com/ethereum/execution-specs https://github.com/ethereum/go-ethereum/blob/d10c28030944d1c32febba3f45ae8c175ab34063/params/config.go https://www.ethereum.cn/the-history-of-ethereum-hard-forks https://etherscan.io/chart/gaslimit https://github.com/ethereum/go-ethereum/pull/3341/files#r89548312 https://blog.ethereum.org/2019/01/15/security-alert-ethereum-constantinople-postponement https://ethereum-magicians.org/t/hardfork-meta-eip-2070-berlin-discussion/3561 https://notes.ethereum.org/@holiman/S1ELAYY7S?type=view