What is The Merge?
The Merge represents the change from proof-of-work (PoW) mining to proof-of-stake (PoS) validating on Ethereum.
Currently, all transactions performed on Ethereum are handled by the Proof-of-work (PoW) execution layer (EL). While the Proof-of-stake (PoS) Beacon chain, or consensus layer (CL), has been coming to consensus on “empty blocks(1)” which contain information such as attestations, the deposit contract root, and validator slashings/exits. One way to think about the Beacon chain is that it is currently ‘practicing’ some of its post-merge tasks, but the ‘real’ activity continues to happen on EL.
There are many things that will remain largely unchanged post-merge. For example, right now there is client software for EL (e.g., Geth, Nethermind, Erigon, etc) and there is client software for CL (e.g., Prysm, Lighthouse, Nimbus, Teku, etc). If someone is currently running a validator they need to run an EL node, a CL node, and a validator client. Nothing about this changes post-merge.
What is going on behind the scenes?
From a high level, developers are trying to break things – by simulating the merge, i.e., the event, and the post-merge environment, developers are discovering how their software needs to be modified. The vast majority of changes needed on EL and CL clients have already happened. The changes currently taking place are minor and are in response to, typically, non-breaking errors and issues discovered during testing.
Kintsugi and Kiln are two merge testnets. Both function in similar ways – they begin as PoW networks, they simulate the merge, and then continue to operate as PoS networks. Client software (as well as other stakeholders such as developers and users) test their programs (and functions) on these testnets to surface any errors that may need fixing before the merge (see here for more on Kintsugi and here for more on Kiln).
Shadow forks are created by having a small number of nodes fork off an existing network. In many cases newer testnets don’t have realistic sizes and transaction histories that truly simulate mainnet – shadow forks can be created from networks, either longer running testnets or mainnet, to get a more realistic view of what the merge could look like (for more on shadow forks see here).
What’s left to do?
Client teams continue to fix any of the issues discovered during testing. Once clients run without issues on the shadow forks, the Ethereum testnets will run through the merge. The merge on Ethereum mainnet will be scheduled once all clients are running smoothly on the merged testnets(2).
For a detailed list of tasks see here.
Wen?
The quick answer from Tim Beiko:
The above tweet caused quite a reaction on Twitter and beyond, with people trying to interpret whether this meant September or sometime during the third quarter.
Adrian Sutton (another well respected Ethereum voice) had this to say:
This last point: “It ships when it’s ready and not a moment before” is superlative. It’s tempting to focus on timing of the merge, but it is vastly more important to focus on doing it right.
Going back to Tim Beiko’s tweet, it’s hard to imagine anyone coming up with a better answer than someone who is so directly involved. And the correct interpretation of the tweet is likely during the third quarter. Yes, this is a range and not a point estimate, but it’s currently the best estimate.
What are the risks?
Having multiple clients for both EL and CL builds resilience into Ethereum, but it also means that upgrades take longer. Each client team must fix problems and progress is only as fast as the slowest team – no client left behind!
Although this does slow things down, it adds redundancy. If a minority client experiences a bug post-merge the rest of the clients ensure that Ethereum carries on.
In addition to both CL and EL, any malfunction to the engine API – the communication interface between CL and EL, among other things – could cause significant network issues. Risks to any of these three components come down to pushing ahead with the merge before everyone is ready and there is no appetite for that from anyone that is serious about Ethereum.
There are other risks that will continue for some period post-merge. These are largely due to changes in the way Ethereum will operate. For example, currently, no one knows who the block proposer is ahead of time, but that will change post-merge, opening the potential for DDoS attacks on proposers. Bias in the random number generation process is potentially another attack vector, and Maximal Extractable Value (MEV) could potentially provide the motivation to attack the network.
These risks are important but they are known risks and are being worked on. The key risk is pushing this upgrade before its time. Instead of asking ‘wen?’ anyone caring about Ethereum should be asking ‘What are we missing?’ and ‘How confident are all the client teams at this point?’ The rest follows from there.
Staying up to date:
Some helpful resources to follow along (in no particular order):
Twitter accounts:
@TimBeiko
@ajsutton
@parithosh
@superphiz
@benjamin_xyz
@drakefjustin
@peter_szilagyi
@VitalikButerin
@mkalinin2
@dankrad
@terencechain
@vdWijden
@sproulM_
@paulhauner
@dapplion
@dannyryan
@prylabs
@trent_vanepps
@sigp_io
@go_ethereum
Twitter hashtags:
#TestingTheMerge
Discord:
Blogs:
More technical resources:
- Execution Specs
- Consensus Specs
- devP2P
- Engine API
- AllCoreDevs Updates
- Validator withdrawals meta-spec
Calls:
- All Core Devs (typically every two weeks on Friday – see here and check in Eth R&D Discord > allcoredevs)
- Consensus Layer calls (typically every two weeks on Thursday – see here and check in Eth R&D Discord > consensus-dev)
Footnotes:
1) ‘Empty’ here is from the perspective of end users (see here for a good explanation)
2) The testnets referred to here are the longer running Ethereum testnets (i.e., Görli, Rinkeby, Ropsten, etc). That is to say, they are distinguishable from Kiln and Kintsugi by their history and that they are not PoS networks currently.
