By restarting Ethereum, can the burden on nodes be reduced?
Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Ethereum enthusiasts (ID: ethfans)
Ethereum enthusiasts (ID: ethfans)
, Author: Alexey Akhunov, translation & proofreading: Min Min & A Jian, reprinted with authorization by Odaily.
Experience from the Cosmos Hub
If you have watched how the Cosmos Hub was upgraded from version 1.0 to version 2.0 to version 3.0, you will know that the upgrade of the Cosmos Hub is essentially achieved by restarting the blockchain with a new genesis block. When upgrading, the node operator needs to shut down the node, then generate a snapshot of the Cosmos Hub state, and then package this snapshot into a new genesis block to create a new blockchain.
secondary title
Can we "reboot" ETH 1.0?
Let's imagine if the same method can be applied to Ethereum. The Ethereum blockchain is huge (150-160 Gb) and the state is huge (40-100 Gb, depending on how you store state). An obvious advantage of "rebooting" the Ethereum blockchain is that newly joining nodes need to download the 40Gb genesis state instead of a 150Gb blockchain. However, downloading the 40 Gb genesis state is not a great experience either.
Store the state of Ethereum off-chain, only the Merkle root hash is visible on-chain
Assuming we can store this 40 Gb "off-chain" and only pack the root hash into the genesis block, we can start from an empty state. But how do we give transactions access to this implicit state?
secondary title
Isn't this stateless ethereum?
secondary title
Proofs in Blocks vs Proofs in Transactions
secondary title
Disadvantages of Proof of Transactions
Suppose we want the sender of a transaction to add a proof of every relevant state to the transaction. The benefit of doing this is that it will simplify the work we need to do to charge extra gas for witnesses. The main disadvantage of this is that this usually needs to be achieved with Dynamic State Access (DSA, as opposed to Static State Access (SSA)). If a transaction involves a particularly complex smart contract, say, with a large number of nested calls to other contracts, it may be difficult to precompute the state items that the transaction will involve. Attackers can even use DSA to "set up" users, that is, to preempt their transactions (send transactions with the same content but higher gas fees, so as to be packaged in front of them) so that users' transactions fail due to insufficient proof.
Mitigations provided by ReGenesis
Although it is difficult to completely solve the hidden dangers of DSA, its risks can be reduced as much as possible, so that users will not feel inconvenienced, and will not be forever limited to a situation where the expected state transition cannot be achieved. This mitigation requires the introduction of the additional rule that any proof provided with a transaction (which has been verified against the state root, but which is not sufficient to guarantee a successful transaction) becomes part of the implicit state. Thus, as the user repeatedly tries to execute the transaction, the implicit state grows and eventually the transaction succeeds. Attackers who try to "hack" the user must find more sophisticated ways to redirect the user's state access outside of the existing implicit state, and ultimately fail.
As the implicit state grows from none (just restarted) to one that includes more and more actively accessed state, transactions need to provide fewer proofs. After a while, most transactions don't even need to have any proofs attached to them, except for those that involve states from a long time ago.
We can perform ReGenesis on a regular basis
I call this "restart" reGenesis , which can be performed periodically so that the load on non-mining nodes is lightened. ReGenesis also represents a less radical version of stateless Ethereum.
Implementing ReGenesis repeatedly will simplify the architecture of Ethereum client implementations, almost eliminating the need for higher-level snapshot synchronization algorithms. If we do ReGenesis every 1 million blocks (roughly 6 months), state snapshots and blockchain files can be made public on BitTorrent, Swarm, and IPFS. Currently we can't do this (storage as generated) because the state transitions every 15 seconds instead of 6 months. If client implementations can replay 6 months worth of blocks, we don't need very complex snapshot algorithms. Therefore, the complexity of Ethereum implementation will be reduced.
secondary title
Disadvantages of ReGenesis
I haven't explored this in depth, but the three drawbacks I've seen are:
