Popular Science | ReGenesis: Can we “reboot” Ethereum?

Lessons from the Cosmos Hub

If you have observed how the Cosmos Hub was upgraded from version 1.0 to version 2.0 and then 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.

Now, anyone who wants to join the Cosmos Hub needs to obtain the genesis block of CosmosHub-3, download all the blocks of CosmosHub-3 and replay them (it is no longer necessary to download the blocks of CosmosHub-1 or CosmosHub-2).

Can we “reboot” ETH 1.0?

Let's imagine if the same approach could be applied to Ethereum. The Ethereum blockchain is very large (150-160 Gb) and the state is also very large (40-100 Gb, depending on how you store the state). An obvious advantage of "restarting" the Ethereum blockchain is that new nodes joining the chain need to download a 40Gb genesis state instead of a 150Gb blockchain. However, downloading a 40Gb genesis state is not a very good experience either.

Store Ethereum’s state off-chain, with only the Merkle root hash visible on-chain

Assuming we can store this 40 Gb “off-chain” and only include the root hash in the genesis block, we can start from an empty state. But how do we give transactions access to this implicit state?

Keep in mind that although this 40 Gb of state is implicit, and how to get this state is an implementation detail, you can run all 10 million blocks to calculate this state, or download its snapshot through fast sync, warp sync, or copy it from someone else's external disk and verify it. Although the state is implicit, we assume that the block proposer (usually a mining pool) has access to this implicit data and is able to process all transactions. But we have to give up one assumption: all other validating nodes can access the implicit state to verify that the transactions in the block are valid and that the state root hash in the block header conforms to the execution result of the block (Translator's note: In the current Ethereum protocol, because all states are explicit, this assumption is reasonable).

Isn't this stateless Ethereum?

If you know about Stateless Ethereum, you might realize that this is exactly what we are working on - keeping the assumption that the block proposer has access to the implicit state and removing the assumption that all validators have access to the implicit state. The solution we propose is to have the block proposer add an additional proof to the block. We call this proof a "block witness".

Proofs in Blocks vs Proofs in Transactions

People who are learning about this scheme for the first time will think that the additional proof is actually provided by the sender of the transaction and is part of the transaction payload. We had to explain that this is not the case. The proof is provided by the block proposer. However, we later discovered that transactions must also include additional proofs. In other words, the sender of the transaction needs to prove that the sender address has enough ETH to pay the gas fee, as well as all other transactions with smaller nonce values ​​initiated by this account. In addition, the sender of the transaction needs to prove the nonce value of the sender's account so that nodes can figure out if there are gaps between nonce values, so that someone can't use this opportunity to send a series of infeasible transactions to perform a DDOS attack. We can also perform more stringent checks, but for most anti-DDOS attack schemes, ETH balance and sender account nonce value are necessary information (if not sufficient).

Disadvantages of Proof of Transactions

Suppose we want the sender of a transaction to include proofs of every relevant state in the transaction. The benefit of this is that it would simplify the amount of work we have to do to charge extra gas for witnesses. The main drawback is that this is usually done via dynamic state access (DSA, as opposed to static state access (SSA)). If the smart contract involved in a transaction is particularly complex, for example, there are a lot of nested calls to other contracts, it may be difficult to pre-compute the state items that the transaction will involve. Attackers can even use DSA to "set up" users, that is, front-run their transactions (sending transactions with the same content but higher gas fees to be packaged first) so that the user's transaction fails due to insufficient proof.

Mitigations provided by ReGenesis

While it is difficult to completely address the vulnerabilities of DSA, it is possible to minimize the risk so that users are not inconvenienced or permanently locked into a situation where they cannot achieve the expected state transition. This mitigation requires the introduction of an additional rule, namely that any proof provided with a transaction (which has been verified against the state root, but is not sufficient to guarantee that the transaction will succeed) will become part of the implicit state. Therefore, as users repeatedly try to execute transactions, the implicit state will continue to grow, and eventually the transaction will succeed. Attackers who try to "set up" users must find more complex ways to redirect users' state access outside of the existing implicit state, and ultimately fail.

As the implicit state grows from nothing (at the restart) to include more and more actively accessed state, the proofs that transactions need to provide will decrease. After a while, most transactions will not even need to be accompanied by any proofs, except for those involving state that was very far away.

We can perform ReGenesis regularly

I call this a “restart” reGenesis, which can be performed periodically to relieve the burden on non-mining nodes. ReGenesis also represents a less radical version of stateless Ethereum.

Repeatedly performing ReGenesis will simplify the architecture of Ethereum client implementations and almost eliminate the need for more advanced snapshot synchronization algorithms. If we perform ReGenesis every 1 million blocks (about 6 months), we can make state snapshots and blockchain files public on BitTorrent, Swarm, and IPFS. We cannot do this (store as it is generated) currently because the state is transitioned every 15 seconds instead of every 6 months. If the client implementation can replay 6 months of blocks, we don't need a very complex snapshot algorithm. Therefore, the complexity of Ethereum implementation will be reduced.

Disadvantages of ReGenesis

I haven't explored this in depth, but three drawbacks I've seen are:

1. Users may need access to the full implicit state to create transactions. In practice, I think this is a fair compromise.

2. (Due to DSA) users may need to execute transactions repeatedly until the desired state transition is finally achieved.

3. Some rollup techniques (which use blockchain data to achieve data availability) may be affected

(over)

Original link: https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582 Author: Alexey Akhunov Translation & Proofreading: Min Min & A Jian