After deploying The Merge upgrade, Ethereum blockchain hot swapped it's consensus mechanism from Proof of Work to Proof of Stake. While the client development team is engaged working on the next planned upgrade - Shanghai, the blockchain may require a minor yet important upgrade on EL clients (former PoW clients).
This blogpost will explain what what probably could be the first Post Merge Execution Layer Upgrade and why it is important.
A little Background
In Ethereum's All Core Devs Meeting #147, client developers discussed the PoW Side of Fork. This was the first post-Merge ACD meeting. On the day of the upgrade, i.e., on 15th September 2022, ~25 blocks were observed to be mined using pre-merge Geth releases. The Merge Geth release was optional for miners, but if used, it would have stopped mining once TTD was hit. However, the number of mined blocks dropped significantly.
It appeared that miners kept mining past the first TTD block until finalization with a hope that there's still a chance a validator would pick theirs over another one, as it's an uncle block. This led to a discussion on the Fork ID of the chain and EIP-2124.
With each network upgrade, clients' nodes update their Fork ID to choose which peer to connect to. If a peer is on a different fork, then disconnection takes place. This is specified in EIP-2124.
Post-merge Fork ID update for EL clients was also discussed on Ethereum's ACD Meeting #142. At that time, Sepolia Testnet Merge and Ropsten Testnet Merge were successfully deployed. The next needed step was forking the testnets to disconnect pre and post-merge nodes.
What is EIP-2124?
EIP-2124 a.k.a Fork identifier for chain compatibility checks is a Standard Track Networking Proposal created on 3rd May 2019 by Péter Szilágyi and Felix Lange.
An overview of Proposal
According to the proposal, nodes on the blockchain network try to find each other by establishing a random connection to remote machines that look like Ethereum nodes hoping they find a useful peer. As a result, much time and resources are wasted, especially for smaller networks.
The EIP-2124 introduced a new identity scheme to precisely summarize the chain's current status with genesis and all applied forks by providing a fork identifier.
In the past, this EIP helped new Ethereum node operators to identify the upgraded chain and join the Ethereum Main Network (Proof of Work chain) at any point of time.
To understand the importance of a fork identifier on Ethereum network, let's understand a few other key terms which are frequently used by client developers, specially during the network upgrade.
What is Network ID?
Network ID is basically an integer that identifies the blockchain on networking layer. It is used to establish Peer-to-peer communication between nodes on a particular blockchain network.
Network ID (Ethereum Mainnet) is 1.
The DAO Hack
For people new to Ethereum, Ethereum decentralized autonomous organization (DAO) was launched in 2016, which raised over $150 million USD worth of Ether (ETH) through a token sale. Due to a vulnerabilities in its code base, the DAO was hacked. The maintaners of Ethereum blockchain at the time weren't able to acheive consensus to restore the stolen funds.
The blockchain was hard forked 20 July 2016 which resulted in the network splitting into two distinct blockchains: Ethereum (ETH) and Ethereum Classic (ETC).
Ethereum Classic maintains the original, unaltered history of the Ethereum network.
If a network is forked, it has the same network id as the previous one. So at this point, the network id for Ethereum became useless for distinguishing between Ethereum (ETH)network and Ethereum Classic (ETC) as both of them were having the same id. So, there was a need for a dynamic network id that could uniquely identify the network without having to configure it explicitly.
What is Chain ID?
Chain ID was introduced with EIP-155 on 14th October 2016 by Vitalik Buterin after Spurious Dragon Hard Fork as part of the transaction signing process to protect against transaction replay attacks.
Network IDs are used for peer-to-peer communication between nodes communication and Chain IDs are for signing transactions.
Although, the Network ID and the Chain ID are the same for most networks, including Mainnet and the public testnets, defaulting to the chain ID, as specified in the genesis file; they have different uses.
In the table below, we can see the common Chain IDs, Network IDs and their corresponding networks.
| Network | Chain | Chain ID | Network ID | Type |
|---|---|---|---|---|
mainnet |
ETH | 1 | 1 | Production |
goerli |
ETH | 5 | 5 | Test |
sepolia |
ETH | 1115511 | 11155111 | Test |
dev |
ETH | 2018 | 2018 | Development |
classic |
ETC | 61 | 1 | Production |
mordor |
ETC | 63 | 7 | Test |
kotti |
ETC | 6 | 6 | Test |
astor |
ETC | 212 | 212 | Test |
Readers can get a complete Chain ID and Network ID list on chainlist.org.
What is Fork Identifier (Fork ID)?
The Fork identifier is defined as RLP([FORK_HASH, FORK_NEXT]) searlization. It contains the genesis block hash and the block numbers of all of the scheduled hard forks that have occurred in the network and block number of the next upcoming fork. This forkid is cross validated (NOT natively compared) to assess a remote chain’s compatibility. Clients' implementing this EIP, enables each node to maintains the values for FORK_HASH and FORK_NEXT. Let's understand both of these parts one by one.
FORK_HASH
It uses the IEEE CRC32 checksum ([4]byte) function of the genesis hash and the block numbers of all of the scheduled hard forks that have already occurred in the chain. Let's take example of how FORK_HASH on the mainnet will look like:
Case 1: No Hard Forks
forkhash₀ = 0xfc64ec04 (Genesis) = CRC32(<genesis-hash>)
Case 2: Homestead Hard Fork occurred at block number 1,150,000
forkhash₁ = 0x97c2c34c (Homestead) = CRC32(<genesis-hash> || uint64(1150000))
Case 3: DAO fork Hard Fork occurred at block number 1,920,000
forkhash₂ = 0x91d1f948 (DAO fork) = CRC32(<genesis-hash> || uint64(1150000) || uint64(1920000))
FORK_NEXT
It is the block number of the next fork. So, if the node is currently in the homestead state, then the next fork be the DAO fork. So, whenever two peers connect, they can immediately determine if they are compatible or not based on the forkid.
Why do Ethereum clients' implement EIP-2124?
EIP-2124 provided a way to send transactions that work on Ethereum without working on Ethereum Classic (ETC) or the Morden testnet. It simplifies the discovery of good nodes without going through an expensive process of establishing a TCP/IP connection, and then execute an eth handshake,
EIP-2124 defines the identity scheme and validation rules.
This EIP provides a new identity scheme to summarize the chain’s current status precisely. The conciseness is particularly important to make the identity useful across datagram protocols too.
EIP-2124 enabled client nodes
- avoid connecting two nodes on different networks.
- At the time of the hardfork, the upgraded nodes reject non-upgraded ones.
- Clients' node reject each other if two chains share the same genesis but not forks (eg. ETH/ETC).
Why EIP-2124 was not included in The Merge upgrade?
Ethereum network upgrade includes only Core EIPs to be deployed on the mainnet with a planned network upgrade. EIP-2124 is a Networking proposal and that wasn't supposed to be deployed with The Merge EIPs - EIP-3675 & EIP-4399. However, this could have been added to clients' specs async but considering the complexity of the upgrade, it wasn't added to clients'.
Moreover, The Merge wasn't triggered at a block height (as earlier planned hardfork) but by the TTD value, instead. To learn more about the Merge activation, check out the video below.
But, developers now can specify a block to update the Fork ID for merged nodes. They have already done this on Sepolia Testnet.
Sepolia Post-Merge Upgrade
As we know, The Merge was one of the biggest Ethereum upgrade. It was tested on multiple public testnets. Sepolia and Goerli are two testnets which are expected to be around for some time. Read Ethereum Testnets after The Merge for details.
After a few days of running on PoS, Sepolia testnet underwent the first post-merge execution layer (EL) upgrade at block 1735371 on 22nd August 2022 enabling EIP-2124 to disconnect the EL clients on the Sepolia network from peers who have not transitioned to Proof of Stake. It did not add any additional functionality beyond this.
According to the Paris Specifications, This upgrade is referred to as FORK NEXT Upgrade.
It is anticipated that Ethereum developers will plan similar upgrades on Goerli Testnet and the Ethereum mainnet close to or during the Shanghai Upgrade.
Resources
- PEEPanEIP #30: EIP-2124: Fork Identifier for Chain Compatibility Checks with Felix Lange
- EIPS/eip-2124
- EIPS/eip-2364
- Sepolia Post-Merge Upgrade Announcement
Related Videos
- The Merge Transition
- Ethereum: The Great Renaming
- Proof of Work
- Proof of Stake
- How to Join Kintsugi testnet?
- Kintsugi Fuzzer Issue
- What is Kiln Testnet?
- How to Join Kiln Testnet?
Related Articles
- An overview of expected changes with the Ethereum Merge upgrade
- MEV in DeFi
- Ethereum Mainnet Shadow Forking: An Overview
- What do Bellatrix, Paris & TTD mean in Ethereum Merge Upgrade?
- Ethereum's roadmap for 2022 and beyond!
Disclaimer: The information contained on this web page is for education purposes only. Readers are suggested to conduct their own research, review, analyze and verify the content before relying on them.
To publish press releases, project updates and guest posts with us, please email at contact@etherworld.co.
Subscribe to EtherWorld YouTube channel for ELI5 content.
Support us at Gitcoin
You've something to share with the blockchain community, join us on Discord!