Original Article Translated By: 0x9F, 0x22D, BlockBeats

What happened with the merge of Kiln? Like the mainnet, Kiln was launched with separate PoW and PoS chains, and through the merge, it is now fully running on PoS.

Does Kiln follow the specifications of the current mainnet merge? In other words, is it equivalent to the mainnet after the merge? Does it follow the Bellatrix fork specifications? Yes. We made some minor changes to the specifications after Kiln was launched, but they are backward compatible. The current network specifications can be found here. We do not expect any major specification changes at this point, and we strongly encourage tool/infrastructure/application developers to test their products on Kiln to ensure they work as expected in the post-merge Ethereum environment.

The beacon chain on the Kiln testnet seems to have state and smart contracts, contrary to what is recommended in ethereum.org about the beacon chain. Am I mistaken? After the merge, the beacon blocks contain the transaction payload from the current PoW blocks. We refer to this as the Execution Payload in the specifications. There is a diagram here that explains how it works. In the diagram, the first two blocks on both the PoW and beacon chains are from before the merge, while the last two blocks are from after the merge. More details can be found in the full post. Once a PoW block is produced, subsequent beacon chain blocks will include transaction data.

What is the block processing flow after the merge? 1. A validator is selected to propose a block. 2. The validator requests an Execution Payload from the Execution Layer (EL) through the EngineAPI. 3. The EL returns a payload containing the most profitable subset of valid transactions to the Consensus Layer (CL). 4. The CL proposes a block with the payload and propagates it on the beacon chain p2p network.

Note: a. Individual transactions are still propagated on the EL p2p network, and the EL is responsible for maintaining the transaction pool. The full blocks are propagated on the CL p2p network. b. Validators specify the address they want to receive fees in the EL. The transaction fees are not "locked" on the beacon chain like the validator's stake and incentives.

5. Other validators validate the block and propagate it on the beacon chain p2p network.

What is the testing process for the merge? We are currently conducting several testing efforts simultaneously. Here is a list.

What is a shadow fork? A shadow fork refers to a few nodes being configured to split off from the Ethereum network at some point. In the case of the merge, we achieve this by launching nodes set to run the merge earlier than the rest of the network. This allows us to test how the upgrade works under conditions similar to a shadow fork network. However, the majority of the nodes are not aware that the upgrade has occurred. After the shadow fork, valid transactions on the main chain can also be mapped to the forked chain, simulating the throughput of the original network. More details are described by @parithosh_j on Twitter. The following image, from their tweet, shows how the network looks after the shadow fork: The top row of Goerli blocks shows a node on the standard chain that is unaware of the shadow fork. The middle row of Goerli blocks shows a node on the shadow forked chain that has a modified configuration indicating that it forks once the Total Terminal Difficulty (TTD) is reached. The bottom row shows a beacon chain used only for the shadow fork, which provides consensus across the whole chain once TTD is reached. After TTD, the nodes on the standard chain continue to produce blocks as usual as if nothing happened to them. After TTD, the configured nodes with modifications fork and run the merge. The first post-merge block is produced by the next validator on the beacon chain. While this block can include any transactions from the standard chain, the specific transactions or their order may not be the same as on the standard chain.

Why is a "shadow fork" useful? A shadow fork allows us to see how nodes react to the upgrade under conditions of significant state and transaction complexity without disrupting the standard chain. Shadow forks provide a more realistic testing environment compared to launching a completely new testnet, as there have already been transactions and a significant amount of state and history on an existing testnet, putting more load on the nodes compared to a new network. This allows us to get performance metrics of nodes in a "real-world" scenario without impacting the operation of the main network.

Can you do a shadow fork of the mainnet? Yes, and we are currently doing it. Shadow forking the mainnet is valuable as it shows us how nodes react under extreme conditions with large state and history and complex transactions. After the shadow fork on the mainnet, we can also test the stability and synchronization of nodes when attempting to join the forked network. This provides data not only on the transition itself but also on the behavior of new nodes joining the network post-merge.

At which stage of the process is the shadow fork? Shadow forks give us confidence that the upgrade works as expected. Once they consistently work through all upgrade processes, we are confident in running the existing testnets through the merge. It is worth noting that the nodes in the shadow fork are controlled by a small set of operators, while some public testnets have a broader set of validators. Once the testnet upgrades and stabilizes, we can start planning the merge on the mainnet.

How will withdrawals from staking be done? I found several specifications, but none of them seem to have a clear consensus on that. Looking at the staking contract, I found only one writable method, which is the deposit. There is hardly any information on the withdrawal logic. The Ethereum merge will not

熱點：ETH 以太 以太坊 太坊