Vitalik: Ethereum 1.0 will become the subsystem of Ethereum 2.0, PoW will lose its meaning

Translator's Note: According to the Eth1->eth2 transition scheme proposed by Ethereum co-founder Vitalik Buterin, Ethereum uses very different code paths to package and broadcast transactions before and after conversion, and after completing the transition. Ethereum 1.0 will be the subsystem of Ethereum 2.0, and the changes experienced by users will be very limited.

The following is the translation of the program:

user experience

If you are an app developer or app user and the roadmap described in this article is used to complete the transition of Ethereum 1.0 -> Ethereum 2.0, then the changes and problems you experience will be very limited. Existing applications will continue to run without change. All account balances, contract codes and contract storage (including ERC20 balances, valid CDP, etc.) will continue to exist.

And what you need to face and deal with are the following:

• Token Watch | Ponzi Finance, Negative Interest Rate and Bitcoin
• Devcon's first day of editing: State Rent, Uniswap and Plasma's second floor DEX
• Monthly Report | In September, 70 global blockchain application projects were disclosed, and the Chinese market cooled.

1. The cost of the IO access opcode ( SLOAD , BALANCE , EXT* , CALL* ) will increase. The cost of CALL (call) may increase by 1 Gas per access to one byte of code;
2. At some point, you must download the code that implements the network upgrade. This is not intrinsically different from any other upgrades (such as Byzantine, Constantinople upgrades), but this time the downloads are larger, because you also need to download an Ethereum 2.0 client.
3. The blockchain may be suspended for approximately 1 hour. After 1 hour, “Ethereum” will be back online, but at this time Ethereum 1.0 will be a subsystem of Ethereum 2.0, not a stand-alone system.

That's it, if you're a developer, you can eliminate the cost of gas by proactively writing applications with smaller footprints (that is, measuring the total storage slot + contract + contract code accessed in a transaction). The biggest disruption caused by change.

( Translator's Note: The following eth1 stands for Ethereum 1.0 chain, eth2 stands for Ethereum 2.0 chain )

How to achieve a smooth transition?

Assuming that Phase 0 – Phase 2 has been implemented and the eth2 chain is running steadily, our goal is to keep the eth1 blockchain stable. In the specification of stage 0, there is already a mechanism called eth1_data voting , in which the verifier votes to agree with the most recent specification eth1 hash, which is used to process deposits. We only need to modify it slightly and then use it to feed the full state (root) of eth1 to eth2.

Currently, there is a delay of about 6 hours for this mechanism (4 hours for ETH1_FOLLOW_DISTANCE and 2 hours for the voting period), but these parameters can be reduced over time before the transition, eventually turning the delay into about 1 hour.

The basic mechanisms affecting the transition are as follows:

1. Specify an (eth1) transition block height TRANSITION_HEIGHT : The eth1 block specified by TRANSITION_HEIGHT will be treated as the "final" block on the eth1 side. From then on, this eth1 chain will run as the subsystem of eth2;
2. At the same point in time as (1), add a change to the eth2 "honest certifier" code that does not allow voting number > TRANSITION_HEIGHT的eth1区块 of number > TRANSITION_HEIGHT的eth1区块 . If the voting algorithm previously selected some blocks with number > TRANSITION_HEIGHT , vote TRANSITION_HEIGHT高度的祖先 block of the TRANSITION_HEIGHT高度的祖先 ;
3. In addition, in the case of trigger (2), the verifier should set the deposit_count to be 2**63 higher than its true value (this basically uses the top bit of the deposit_count as a signal indicating that "eth1 is complete" );
4. When the "eth1 has completed" signal is sent and the eth2 chain receives the eth1 data, it performs a one-time "irregular state transition", placing the post-state root of the eth1 block into the "eth1 execution environment". Status (a system-level smart contract on eth2). This is equal to the total ETH supply of the eth1 chain being added to the balance of this eth1 EE (execution environment);

After this point, the transition is complete. The eth1 chain still continues to exist technically, but it is worthless . When the ice age comes, it will eventually die out. ( Translator's Note: Vitalik means that PoW will lose meaning, not eth1. No value ) .

At this point, the eth1 system is located inside eth2, so by submitting a transaction targeting eth1 EE (execution environment) on eth2 (as described above, it is a subsystem of eth2), it can be further transferred to the eth1 system. . Eth1 EE (execution environment) has code that implements the entire eth1 EVM (virtual machine) and transaction processing logic with a function upgrade ( state_root, transaction, witness) -> new_state_root ), which accepts a transaction and verification content (partial The merkle proof of the state), the transaction is processed according to the same rules on the eth1 chain and the updated eth1 state root is determined. See the stateless client concept to see how validation content and state roots work.

Additional functionality is added to the eth1 EE (Execution Environment) code, which allows ETH and messages to be withdrawn from eth1 EE (execution environment) back to other parts of eth2 and back to other copies of snippet eth1 EE. By default, all eth1 accounts/contracts will be placed on the same shard, so to take advantage of the increased capacity of eth2, you need to actively use this feature to move ETH or other applications to other shards, but this is not difficult . In addition, we need to extend the ERC20 token standard to support cross-segment transfer of tokens.

How the user client will work

Prior to the transition, the client-facing client would be modified to have two code paths. The client will check eth2 to see if a conversion has taken place. If it hasn't happened yet, it will use the eth1 chain to send transactions, check balances, etc., as before, unless it believes that all eth1 blocks with number > TRANSITION_HEIGHT do not exist. And if a conversion occurs, it will check eth1 EE on eth2. The full client will process all transactions on eth2 that target eth1 EE in order to continue updating the full eth1 state tree. This will allow the client to generate authentication content for any transaction they want to send and "package" it in eth2 format. Light clients (and wallets such as metamask) broadcast their transactions to a full client, which can add authentication content to them.

From the user's point of view, there is no big change before and after the Ethereum conversion (except for PoS and EIP 1559 after the conversion, the experience will be smoother). In fact, very different code paths are used to package and broadcast transactions before and after the conversion, but the functionality provided will be the same.

If possible, this conversion can be modified so that the wallet communicates with the client via RPC without having to change anything.

An example of an app user

For example, if you have CDP (debt-backed position) on MakerDAO, you can sleep well during the conversion process from eth1 to eth2. When you wake up, the transition is complete. You can interact with CDP and clear CDP by sending a transaction as before, but in fact your client code will think you are converting and add validation data to your transaction and send it to eth2 Network, not eth1 network.

Possible optimization

During the period when the eth1 chain reaches TRANSITION_HEIGHT and the eth1 EE on eth2 is accepted, we can perform some preprocessing on the eth1 state. For example, we can:

1. Replace the hexadecimal Patricia tree with a binary sparse Merkle tree , and a dedicated hash function to ensure that the branch's hash overhead remains O(log(n)), which reduces the size of the Merkle branch by a factor of about four;
2. Replace RLP with SSZ hash tree;
3. Add a data field related to the status lease to the account;
4. Clear the “dust” account;
5. Modify the account structure according to the "abstract" proposal;

Instead of including the actual eth1 state root into the EE (execution environment), we can choose to include the state tree root generated by performing all of these modifications. This is a deterministic calculation, so all certifiers can do it in parallel. This one-time calculation saves overhead and greatly improves efficiency and availability after eth1 conversion.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!