Learn how to improve the Ethereum network with ReGenesis

Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from

Ethereum enthusiasts (ID: ethfans)

Ethereum enthusiasts (ID: ethfans)

The amount of funds locked in DeFi applications has exceeded $1.5 billion; new dApps are announced almost every day. At this rate, Ethereum may die from being too successful. As far as the infrastructure layer is concerned, the infinite state growth is a big problem.

A few days ago, Alexey posted an article on the EthResearch forum, proposing an interesting idea, which he named ReGenesis.

The idea is relatively simple, and may seem radical at first glance: periodically (e.g., every 1 million blocks) delete all state stored locally, keep the root hash of the latest block, and start building the state again , after another 1 million blocks, the next status reset will be performed.

image description

-ReGenesis : Reset state every N blocks. As the state grows, fewer proofs are needed until the next ReGenesis starts -

To understand why this idea is feasible and worth investigating, you need some background and explanation.

That's what this article is about.

current situation

1. Centralized state storage

Sending transactions on Ethereum is very easy, you don't need any state data yourself. Transaction senders have no incentive to save any state.

If you (miner or exchange) are running an infrastructure node, you need to make sure you have all the state needed to validate and broadcast transactions. If you are a miner, you need more state.

Therefore, current state storage is concentrated in infrastructure nodes run by large entities (Infura, big miners, exchanges, etc.).

2. The state continues to grow infinitely

At press time (June 29th), the "current state" in the Turbo-Geth client is about 40 GB and growing.

The problem here is not the state size itself, but the unlimited state growth. Of course, we can also pray that SSD capacity grows faster than blockchain state.

We've been lucky so far, but luck alone isn't a long-term solution.

3. Stateless Ethereum is difficult to re-price Gas

Pricing block witnesses is very difficult for stateless ethereum projects. These witnesses are generated by miners, and it is difficult for the transaction sender to predict the size of the block witness when sending the transaction.

Therefore, we need to find a way to speculate on the witness price through smart contract behavior without affecting the existing smart contract.

There are already some proposals, such as Oil, but this is really a tricky problem.

How to run transactions after ReGenesis

Ok, now we all know that to zero out all current state, only the root hash is kept. The amount of data is reduced from 40 GB to 32 bytes.

At this time, stateless Ethereum comes in handy. In order to be able to run a transaction, you need to provide a witness. The witness contains the account used, the code and contract storage content, and a Merkle proof that can be used to verify the root hash (click here to learn more about witnesses and stateless Ethereum).

However, there is one difference between ReGenesis and Stateless Ethereum. Before explaining the difference, I want to introduce two terms: explicit state and implicit state.

Suppose you are running a geth node. Whenever your peer node sends you a new block N, the node assumes that you already have the state data necessary to verify all transactions within that block, and that you have synced block N-1.

- Current Ethereum: Assuming both nodes have all required states -

This is 100% implicit state. Peers assume you already have state, and therefore don't add any state to the block.

In stateless ethereum, when you run a node, the peer node sends you a new block N and thinks you have no implicit state under any circumstances. They pack everything you need to run block N into block N. This is block witness.

image description

Your peers send you explicit status.

Let's say ReGenesis starts at block 10.000.000. Currently, at the top of the blockchain is block 10.001.000. We can think of any ReGenesis node as having an implicit state of all data between block 10.000.000 and block 10.001.000. Every account, every storage entry, and every contract used in these blocks is already stored on every node, so block witnesses are not required. This allows for drastic reductions in the size of witnesses, as we have seen in our experiments with quasi-stateless synchronization.

image description

- ReGenesis: Block 1 provides information that Node 1 lacks -

• image description

• - ReGenesis: merge the state from block 1 into the implicit state of node 1 -

• If you (as a transaction sender) need to send a new transaction to the network whose current block height is 10.001.000, you need to perform the following steps:

• Create the transaction you want;

Create explicit state for entries not included in the implicit state, packaged as transaction witnesses (discussed in detail below);

That's right.

Send the transaction with the witness to the network;

Wait, does this mean that the transaction sender must have some pre-ReGensis state? !

That's right.

If you want to send transactions after ReGenesis starts, you may need to have some pre-ReGenesis state information in order to generate witnesses.

transaction witness

You may have noticed that I mentioned the term transaction witness above.

- Combined block witness -

- Transaction Witness -

- Block witnesses are generated by miners. We need to compensate them through a complex Gas pricing mechanism -

Transaction witnesses have an important advantage. They are generated by the transaction sender and sent with the transaction. Therefore, we can immediately know the size of the transaction witness and how to price it. We don't need to reprice through EVM.

image description

- Transaction witnesses are generated by the transaction sender and are much easier to compensate -

A potential pitfall of using transaction witnesses is data duplication. Assuming that all transactions in a block are made by the same two accounts, the transaction witness will contain duplicate data.

Block witnesses are generated by miners. Miners know the exact order of transactions in a block, so block witnesses always contain the latest data.

The transaction witness comes from the transaction sender. Therefore, there should be a smart merge mechanism that merges the transaction witness with the implicit state generated by earlier transactions in the block.

However, the whole ReGenesis concept requires the use of transaction witnesses, so it's not a big deal.

first level title

Why can't we use transaction witnesses yet?

In simple terms, because of Dynamic State Access (DSA) and the potential risk of frontrunning transactions by malicious actors.

Specifically, in stateless Ethereum, you need to provide the complete state of this transaction, and we assume that the receiver does not have any state. If your transaction uses DSA, then which parts of storage your code reads depends on values ​​in other parts of your code.

In theory, this could invite a DoS attack.

If Alice provides a proof that includes A, Bob can change K before Alice's transaction is packaged, causing Alice's transaction to fail. If Alice provides a proof that includes B, Bob can repeat the trick.

Of course, Alice can provide a proof that includes A and B, but if the storage address is determined by uint64, Alice must include the complete state in the proof to prevent attacks, but it is simply not feasible to include the complete state.

Of course, this attack is theoretical. However, more similar attacks are likely to emerge. Given the large amount of funds held by dApps, we need to be very careful not to break anything.

first level title

How does ReGenesis alleviate this problem?

The determinism of ReGenesis can help us determine how much state a node has. For those states that we are sure a node has, we don't need proofs.

To alleviate this problem, whether a transaction succeeds or fails due to insufficient state, we make sure that the proof we provide is included in the state.

Although Alice's transaction failed, the transaction added all the proofs needed for path A to the node's implicit state.

in conclusion

Now, Alice can resend this transaction, providing the required proof for path B. Bob can no longer block Alice's transaction by changing K. Even if he changes K to make the transaction choose path A, it will be too late. The proof required by path A is already included in the node's implicit state, so the transaction does not need to Any proof can be sent to the nodes. If a transaction is directed to path B, then it has exactly the proof B needs.

• first level title

• in conclusion

• Finally, let's quickly recap the vision and gist of ReGenesis:

• Every time N blocks are generated, we will clear all states and only keep the root hash;

• The frequency of ReGenesis startup should not be too high, it can be set to every 1 million blocks, every 10 million blocks, etc.;

• The transaction sender needs to provide an explicit state (as a transaction witness);

• The transaction sender pays the gas fee based on the size of the transaction witness;

To do this, the transaction sender must preserve the pre-ReGenesis state of the contract/account it is interested in;

• If the transaction fails due to insufficient explicit state, we will add the proof provided by the transaction to the implicit state, so that we do not need to provide the same proof when sending the transaction next time;

• The explicit state from transaction proofs is merged with the implicit state generated by transactions run earlier in the block through a smart merging mechanism.

• From a macro perspective, the ReGenesis solution has the following advantages:

Change the incentive balance between transaction senders and infrastructure nodes, thereby improving the decentralization of state storage;