Original title: "Another state-friendly bound address scheme"
Written by: Vitalik Buterin, Co-founder of Ethereum
secondary title

Review: State Size Management Techniques

In order to prevent the state capacity of Ethereum from expanding endlessly, we need to use some method to "deactivate" the old state, so that nodes joining the network no longer need to store the old state. Even if the majority of clients become stateless, it seems reasonably foreseeable that eventually the system will scale to the point where the network cannot guarantee that all state is always available. There are two ways to deactivate the old state:

• Delete it directly, and then move it to another Merkle tree, so that those who care about the state object can obtain the corresponding Merkle branch and use it to activate the state at some point in the future.

• The object is not moved out of the tree structure; instead, it is just marked "deactivated" at that point in the tree so nodes don't store it (and the protocol doesn't require them to). Deactivated objects can be re-accessed by sending a transaction providing a Merkle proof (i.e. witness data) to access the state.

Approach (1) corresponds to the "classic storage rent scheme", and approach (2) corresponds to the simplest extension of the traditional "stateless client" - a model in which old states can be forgotten. Both of these approaches allow individuals who care about specific state objects to track Merkle branches so that they can be used to activate those state objects later if they become deactivated. However, both of these approaches have obvious problems.

Method (1) has some edge cases when a contract needs to be recreated on the same address as an expired contract. That is, if a contract is created at address A and then expires, the transaction that created the contract at address A will be re-executed, which will create a new object at address A, which will affect the original object. activation. Another situation is when an object is created at address A, then undergoes deactivation, is activated, is modified (for example, sending funds on the contract to another account), deactivates again, and then uses the first deactivation Where the Merkle branch is activated. This violates the reservation rule and could be used for minting; additional Merkle proofs need to be added to prove that a contract has not been activated by another specific state that is also trying to be activated.

proposal

proposal

I propose a modification of method (2) that can solve the above problems. As presented by many proposed implementations of method (2), accounts have two states: "active" and "inactive", with inactive accounts being those that have not been accessed for more than a year. To access a deactivated account, you need to provide witness data; when a deactivated account is accessed, the account will automatically be deactivated (touching any account will reset its one-year deactivation period calculation). The modification is as follows:

We add a 32-byte "epoch prefix" (which will be interpreted as an integer) to each address. For example, an address with an epoch prefix of 9 would look like this: 0x00000009de0b295669a9fd93d5f28d9ec85e40f4cb697bae, prefixed with 00000009.

Merkle paths will depend directly on the epoch's prefix rather than its hash (thus merkle_path_key = address[:4] + hash(address[4:]) instead of merkle_path_key = hash(address) as is currently used. This ensures that The "unused" address space is contiguous.

Addresses cannot be used unless their epoch prefix is ​​less than or equal to the number of years the blockchain has been running

A CREATE3 opcode is added that takes the epoch prefix as an argument and creates a contract at an address with that epoch prefix.

It is recommended that users and contracts always create accounts with the most recent epoch prefix possible, even by default, since there will definitely be full state with the latest epoch prefix still accessible. In order to also preserve "counterfactual addresses" (i.e. addresses that users interact with on-chain [e.g. by sending ETH or ERC20 tokens] or off-chain [by interacting in a channel] before the contract code is released ), it is still possible to create contracts with the old epoch prefix. However, for users who want to create counterfactual addresses, they are responsible for storing a fork of the old state for the account if they do not do so for a long time.

After many years of operation, it is expected that the active state will consist of two parts: (i) the entire address space prefixed with the latest epoch, and (ii) specific old states corresponding to accounts that have been actively used recently

Source link:

Source link:ethresear.ch