The Merge in DAppNode — Everything you need to know as a DAppNode Validator

If you are a staker and have not been unconscious for the most part of the year, it is likely you know that The Merge Is Coming.

You are probably using DAppNode because it makes things easy for you, and The Merge will not be an exception. Here’s what to expect!

This document is with the information from today — but we will publish further updates to keep you informed ;)

1. Timeline

There are currently 3 beacon chains that will merge in the near future in DAppNode. You will be able to perform the merge in all of them. Keep an eye open for the expected Merge dates!

1. Prater — will merge with Göerli. The biggest CL testnet with the most popular EL testnet! We recommend you set up a Prater Validator to practise in advance ;) The expected Merge date is estimated between the 8th and the 10th of August.
2. Gnosis Chain — will merge with the Gnosis Beacon Chain
3. Ethereum — will merge CL with EL!

Other testnets like Sepolia, Kiln and Ropsten have already merged. There are Sepolia packages in the explorer, but not in the main DAppStore. Feel free to download them from the IPFS hash in the explorer, but we recommend focusing your efforts on going through the motions in Prater and performing a live merge.

2. What needs to happen

1. You need to run an Execution Layer Client. If you are NOT running your Execution Layer Client (Geth, Nethermind) PLEASE START RUNNING IT NOW or you will not be able to validate. Most DAppNode users already run it as we recommended it from the beginning, but if you’ve been testing other configs with a remote EL node, you need the main node to go back to the mothership.
2. You will need to be in the latest version. We have not decided yet whether you will need to do a manual upgrade or the automatic updates will suffice. We recommend keeping an eye on your DAppNode and in the DAppNode community to make sure you are in the right version when we are closer to the merge.
3. If you were using your EL node without running a validator, you will now need to also run a CL node as the EL alone won’t know where’s the head of the chain.

… and that’s it. Really, from your part, that’s all you will need to do.

3. What we are doing to get you ready

If you’d like to get deep on what changes are coming to the packages you are running, here’s a brief list of what we’re changing.

1. Execution clients:

• We will publish an update that will override the Terminal Total Difficulty or TTD (this is the metric that determines the exact block when The Merge happens)
• Enable Engine API — the new API to connect EL with CL
• Implement JWT authentication for the Engine API

2. Consensus clients

• Enable Engine API on the CL side
• Implement JWT authentication for the Engine API

4. I wanna go deeper

Alright, let’s jump into it.

4.1 Ethereum now

On Ethereum there are two chains:

• Execution chain or Execution Layer (EL): this chain contains all the information relative to transactions, EVM(Ethereum virtual machine, state of the ethereum chain), and it’s secured by the Proof Of Work consensus protocol.
• Beacon chain or Consensus Layer (CL): This chain contains the Proof of Stake consensus mechanism. After The Merge it will dictate which blocks are accepted as ethereum blocks and hence what is the Ethereum chain.

The next image is a representation of these two chains.

4.2 The merge transition

For The Merge to take place, it is very important that there is coordination between the execution chain and consensus chain.. To get this coordination in both chains there will be 2 hard fork upgrades, one on each layer:

• Bellatrix (Consensus Layer)
• Paris (Execution Layer)

4.2.1 Bellatrix

Bellatrix upgrade happens on the consensus chain and prepares it for the merge. After this upgrade, the beacon will build blocks which contain a placeholder for the execution payload. This execution payload is information related to the transactions, EVM, etc which it will be sent by the execution client. This upgrade will enable a new communication channel between the execution client and the beacon client. This new channel is called Engine API. The Bellatrix hard fork happens when we reach a specific moment in the chain, the BELLATRIX_FORK_EPOCH.

4.2.2 Paris

The Paris fork changes the consensus from PoW to PoS! Paris-ready clients also implement the Engine API to communicate with the Beacon Chain. The Paris fork is activated when the TTD is reached.

How do we put everything together?

1. Nodes are upgraded to be compliant with Bellatrix (CL part) and Paris (EL part).
2. We wait for the Bellatrix fork epoch to happen.
3. After the epoch is hit, CL clients wait for a terminal PoW block. Once a terminal PoW block reaches TTD…
4. …the Beacon chain proposer builds the first PoS block on top of a terminal PoW block, and Paris is activated on the Execution Layer.
5. Congratulations, we have Merged!

For more info, get into this extensive internal document. Careful, it’s a work-in-progress and things change!

Have you got more questions? Head over to DAppNode’s Discord and drop your Qs in the #eth2-stakers channel!

We will also regularly publish updates leading up to the following Merges (Göerli/Prater, Gnosis Chain and Mainnet) with specific instructions for each, so stay tuned.

If what you want is to know how to run a validator with dappnode and start staking, visit our website!

Happy Merging!