Interpretation of Ethereum Merger Leaders: Kiln Merger, Shadow Fork, Withdrawal, Sharding
Author: Tim Beiko
Author: Tim Beiko
merge
merge
In the end what happened?In the end what happened?
Like the mainnet, Kiln launches with separate PoW and PoS chains. With the merger, it now runs entirely under PoS.
Is Kiln really following the current norms for mainnet mergers? I.e. is it equivalent to the situation after the mainnet merger? That is, does it follow the Bellatrix fork specification?
herehere。
We do not anticipate major specification changes at this time, and tool/infrastructure/application developers are strongly encouraged to test on Kiln to ensure their products work as expected in the merged Ethereum environment.
The beacon chain of the Kiln testnet appears to have state and smart contracts, contrary to the suggestion in ethereum.org for the beacon chain. Am I being misled by block explorers?
After merging, the beacon block contains the transaction payload contained in the current PoW block. We call it ExecutionPayload in the specification. Here's a diagram explaining how it works.
long textlong text。
Once a PoW block is generated, subsequent beacon chain blocks will contain transaction data.
What is the merged block processing process?
1. A validator is elected to propose a block.
2. The verifier passesEngine APIAsk its execution layer (EL) to send him an ExecutionPayload.
3. EL returns a payload containing the most profitable set of valid transactions to the Consensus Layer (CL).
4. CL proposes a block containing the payload and propagates it on the beacon chain p2p network.
Note: a. A single transaction is 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. b. Validators specify in the execution layer the addresses where they want to receive fees. Transaction fees are not “locked” on the Beacon Chain like validator staking and incentives.
5. Other verifiers verify the block, and if it is valid, it will be propagated on the beacon chain p2p network.
What was the testing process for the merge?
herehereshadow fork
shadow fork
What is a shadow fork?
A shadow fork is when a small number of nodes are configured to fork away from the Ethereum network at some point. In the case of merging, we do this by starting nodes that are set to run merging 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 an upgrade has occurred. After the shadow fork, valid transactions on the main chain can also be mapped to the forked chain, thereby simulating the throughput of the original network. @parithosh_j tweeted aboutmore details。
The image below, from his tweet, shows what the network would look like after the shadow fork:
The top line 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 forked chain with a modified configuration indicating that it will fork once it reaches TTD (Total Terminal Difficulty).
The bottom row shows a beacon chain that is only used for shadow forks: when TTD is reached, it will provide consensus for the entire chain.
After the TTD is reached, the nodes on the Canonical chain continue to produce blocks normally: nothing happens "to them".
After TTD is reached, the node whose configuration was modified is forked and a merge is run. The first block after the merge is produced by the next validator on the beacon chain. While this block can contain any transaction on the Canonchain, it does not necessarily include the exact transactions or their order as on the Canonchain.
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 breaking the canonical chain. The shadow fork gives us a more realistic test environment than launching a new testnet, because the existing testnet has transactions that have already occurred, and has a large amount of state and history, compared to the new testnet, which will make the node suffer. More stress. Thus, we are able to obtain "real world" performance metrics of nodes without affecting the operation of the standard network.
Can you shadow fork the mainnet?
Yes, and we do now. The shadow fork 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 main network shadow fork, we can also test the stability of the nodes when they try to join the forked network, how well they are synchronized, and so on. This not only provides data about the transition itself, but also the behavior of new nodes joining the network in the post-merge state.
At what stage in the process is the shadow fork?
The shadow fork gave us the confidence that the upgrade would work as intended. We are confident we can run the existing testnets through the merge once they are smooth through all the upgrades. It’s worth noting that nodes in shadow forks are controlled by a small set of operators: some public testnets have broader sets of validators. Once the testnet is upgraded and stabilized, we can plan to merge it on the mainnet.
withdraw money
How will pledge withdrawals be done? I found several specifications, but none of them produced a particularly clear consensus. After checking the pledge contract, I found that there is only one writeable method, and that is deposit. At present, there is basically no explanation about the withdrawal logic.
The ethereum merge will not enable staking withdrawals, they will be live in a later fork (herecurrent specification）。
Note: The current method for introducing withdrawals into the execution layer is determined asEIP-4895。
Withdrawals don't actually "go through" the deposit contract, they are pushed back from the beacon chain to the execution layer and are done in the same distribution as miner rewards. This means that calculating the circulating supply is slightly more complicated, since the balance in the deposit contract does not "decrease" with withdrawals.
exist
existEIP-2334This is explained in .
If you use an eth1 withdrawal key, can you only withdraw to the address corresponding to that key? Or is the withdrawal key just used to sign the withdrawal transaction 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 don't need to sign anything with this account, because if you just look at the execution layer, you will find that the withdrawal happens automatically, just like the target account suddenly has extra ETH after the withdrawal block.
Where does the ETH go if you withdraw using a BLS key? My understanding is that there will be no state or accounts in the consensus layer. So, is it only necessary to specify an execution layer address to accept proposed ETH? Or will there be state in the future consensus layer?
specificationspecificationFragmentation
Fragmentation
Is there any consensus on what the future of sharding will look like? It seems that performing sharding has been completely abandoned in favor of Rollups.
Execution sharding has been "deprecated" in favor of Rollups-centric execution layer expansion solutions. Data sharding is the main sharding currently being researched and implemented.
How does Rollups actually work post-merge? Are they still on top of the eth1/execution layer? Or will they be built directly on top of the consensus layer?
They continue to work as they do today, deployed on the execution layer, but can take advantage of the finality of the consensus layer.
Where are the data shards currently? What is data sharding? As Rollups become more popular, will data sharding just be a solution to data availability?
The current plan is to first expose it via a new transaction type, such asEIP-4844are detailed in .
herehereOriginal link
