What is a shadow fork? Ethereum merger leader explains related questions

merge

What happened with the Kiln merger?

Like the mainnet, Kiln was launched with separate PoW and PoS chains. With the merger, it now runs entirely under PoS.

Does Kiln actually follow the current mainnet merge spec? Is it equivalent to the post-mainnet merge? Does it follow the Bellatrix fork spec?

Yes. We did make some minor changes to the spec after Kiln went live, but they are backwards compatible. The current web spec is here.

We do not anticipate breaking specification changes at this time, and strongly encourage tool/infrastructure/application developers to test on Kiln to ensure their products work as expected in the merged Ethereum environment.

The Kiln testnet's beacon chain appears to have state and smart contracts. This is contrary to what is suggested about the beacon chain on ethereum.org. Is this just because I was misled by the block explorer?

After merging, the beacon block contains the transaction payload contained in the current PoW block. We call it ExecutionPayload in the specification. Here is a diagram explaining how it works.

In the above figure, the first two blocks on the PoW and Beacon chains are before the merger, and the last two are after the merger. Please refer to the long article for details.

Once a PoW block is generated, the subsequent beacon chain blocks will contain transaction data.

What is the process for processing merged blocks?

• A validator is elected to propose a block.

• The validator asks its execution layer (EL) to send him an ExecutionPayload through the Engine API.

• The EL returns a payload containing the most profitable set of valid transactions to the Consensus Layer (CL).

• CL proposes a block containing this payload and propagates it on the beacon chain p2p network.

Notice:

1. Individual transactions are still propagated on the EL p2p network, and EL is only responsible for maintaining the transaction pool. Complete blocks are propagated on the CL p2p network.

2. Validators specify in the execution layer the addresses they want to receive fees. Transaction fees are not "locked" on the beacon chain like validators' stake and incentives are.

• Other validators verify the block, and if valid, it is propagated on the beacon chain p2p network.

What is the testing process for the merger?

We have several tests in progress at the same time. Here is a list.

Shadow Fork

What is a shadow fork?

A shadow fork is when a small number of nodes are configured to fork from the Ethereum network at a certain point. In the case of a merge, we do this by starting nodes that are set to run the merge earlier than the entire network. This allows us to test how the upgrade works under similar conditions to the shadow fork network. But the vast majority of nodes will not be aware that the upgrade has occurred. After the shadow fork, valid transactions on the main chain can also be mapped to the forked chain, thus emulating the throughput of the original network. @parithosh_j described more details on Twitter.

The following image from his tweet shows what the network will look like after the shadow fork:

The top row of the Goerli block shows a node on the canonical chain that is unaware of the shadow fork.

The middle row of the Goeli block shows a node on the shadow fork chain with a modified configuration that instructs it to fork once it reaches TTD (Total Terminal Difficulty).

The bottom row shows a beacon chain that is used only for shadow forks: when TTD is reached, it will provide consensus for the entire chain.

After reaching TTD, nodes on the CanonChain continue to produce blocks normally: nothing happens “for them”.

After reaching TTD, the node with the modified configuration forks and runs a merge. The first block after the merge is generated by the next validator on the beacon chain. Although this block can contain any transaction on the standard chain, the specific transactions included or their order may not be the same as on the standard chain.

Why is Shadow Fork Useful?

Shadow forks allow us to use only a small number of nodes to see how nodes react when a merge occurs without disrupting the standard chain. Shadow forks give us a more realistic testing environment than launching a new testnet, because the existing testnet already has transactions happening and has a lot of state and history, which puts more pressure on the nodes than a new testnet. Therefore, we are able to get "real world" performance metrics for the nodes without affecting the operation of the standard network.

Can you shadow fork the mainnet?

Yes, and we do now. Shadow forking the mainnet is very useful because it shows us how nodes react under harsh conditions with huge state and history and the most complex transactions. After the mainnet shadow forks, we can also test the stability of nodes when trying to join the forked network, how well they are synchronized, etc. This provides data not only about the transition itself, but also the behavior of new nodes joining the network in the post-merge state.

Which stage of the process is a shadow fork?

Shadow forks give us confidence that the upgrades are working as expected. Once they are running smoothly across all upgrades, we feel confident running existing testnets through a merge. It is worth noting that the nodes in the shadow fork are controlled by a small group of operators: some public testnets have a wider set of validators. Once the testnets are upgraded and stable, we can plan to merge on the mainnet.

Withdrawals

How will staking withdrawals be accomplished? I found several specifications, but none of them generated particularly clear consensus. After inspecting the staking contract, I found that there is only one method that can be written, which is deposit. There is currently little explanation of the withdrawal logic.

The Ethereum merge will not enable staking withdrawals, they will be available in a later fork (current spec here).

Note: The current method for introducing withdrawals into the execution layer is identified as EIP-4895.

Withdrawals do not actually "go through" the deposit contract, they are pushed back from the beacon chain to the execution layer and are completed in the same way as miner rewards are distributed. This means that calculating the circulating supply is slightly more complicated because the balance in the deposit contract does not "decrease" with withdrawals.

How do withdrawal keys work? The eth2-deposit-cli tool does not automatically generate BLS withdrawal keys by default. How do the keys work exactly? Is only the 0th index of the derivation path used?

This is described in EIP-2334.

If you use an eth1 withdrawal key, can you only withdraw to the address associated with that key? Or is the withdrawal key just used to sign withdrawal transactions, and you can withdraw ETH to any address?

To withdraw ETH from the beacon chain, you must specify an eth1 address as the "target" recipient. You do not need to sign anything with this account, because if you only look at it from the execution layer, you will find that the withdrawal happens automatically, just like the target account suddenly has additional ETH after the withdrawal block.

If you withdraw using a BLS key, where does the ETH go? My understanding is that there will be no state or accounts in the consensus layer. So, is it just a matter of specifying an execution layer address to accept the withdrawn ETH? Or will there be state in the consensus layer in the future?

When withdrawing, you specify an execution layer address and the amount to withdraw in Gwei (see the spec). To be clear, you cannot use a BLS withdrawal key to withdraw. In the merged fork, we will perform an operation to change your deposit credentials on the consensus layer.

Sharding

Is there any consensus on what future sharding will look like? It seems that execution sharding has been completely abandoned in favor of Rollups.

Execution sharding has been "deprecated" in favor of an execution layer scaling solution centered around Rollups. Data sharding is the primary sharding currently being researched and implemented.

How will Rollups actually work post-merger? Will they still sit on top of eth1/execution layer? Or will they be built directly on top of consensus layer?

They continue to work as they do today, deployed on the execution layer, but can leverage the determinism of the consensus layer.

Where is data sharding today? What is data sharding? As Rollups become more popular, will data sharding only be a way to solve data availability?

The current plan is to first expose it through a new transaction type, as detailed in EIP-4844.

Original title: Ethereum Roadmap FAQ

Original author: Tim Beiko

Original translation: 0x9F, 0x22D, rhythmic BlockBeats