This article is a post published by Vitalik on the Ethereum Researcher Forum on October 19, 2020. It proposes the process of how Eth1 converts the subsystems of the fragmented beacon chain as he envisioned, and explains how developers and users feel about this What is the perception of the process. To be precise, this is not a proposal for Eth1, because the content of the proposal has nothing to do with how the Eth1 chain and ecology form a broad social consensus to complete this conversion. On the contrary, it only involves the fragmented beacon chain. A subsystem ("Eth1 EE") should select which state on Eth1 as its initial state according to what procedure. In addition, readers can also take this to get a glimpse of what infrastructure a fragmented beacon chain in the author's mind should have, such as statelessness and EE; this can reverse the development of fragmented beacon chains Direction and progress.
The roadmap introduced in this article is used to complete the transition from eth1 to eth2. If you are an application developer or user, the changes and even subversions you can feel are actually very limited. Existing applications will continue to run without any changes. All account balances, contract codes and contract storage (including ERC20 balances, pledged debt warehouses, etc.) will continue to exist.
You need to deal with the following situations:
- The gas cost of IO access opcodes (SLOAD, BALANCE, EXT*, CALL*) will increase. The gas cost of CALL (call) is about 1 gas per access to 1 byte of code.
- You need to download the code to implement the network upgrade. This is fundamentally no different from other upgrades such as Byzantium and Constantinople. But the download volume is larger, because if you don't have an eth2 client yet, you need to download one.
- The Ethereum blockchain may be suspended for approximately 1 hour. One hour later, "Ethereum" appeared to be online again, but in fact eth1 is no longer an independent system, but a subsystem running in eth2.
That's it. If you are a developer, as long as you ensure that the scale of witness required by your application is not too high (which can be measured by the number of all storage slots accessed by a single transaction + contract + contract code), your application consumes gas The possibility of collapse due to changes in volume is very small.
How the conversion will happen
Assume that phase 0-2 has been completed and the eth2 chain is running stably. The eth1 chain is also in stable operation. The phase 0 specification has arranged a mechanism called eth1_data voting. In this mechanism, validators will vote to reach a consensus on the latest block hash value of the eth1 main chain; this mechanism is currently used to process deposits. We will change the purpose of this mechanism again and use it to transfer the complete state (root) of eth1 to eth2.
Currently, the mechanism has a delay of about 6 hours (4 hours of delay is due to the ETH1_FOLLOW_DISTANCE "Eth1 main chain following distance", and the other 2 hours is due to the voting period), but these parameters will change over time before the conversion is completed Decrease over time, reducing the delay to about 1 hour.
The basic mechanism affecting the conversion from eth1 to eth2 is shown in the following figure:
- Specify a height (of the eth1 chain) TRANSITION_HEIGHT. The eth1 block with a height of TRANSITION_HEIGHT will be regarded as the "final" block of the eth1 chain. From this block onwards, (originally "of the orthodox chain") eth1 will run as a subsystem of eth2.
- The code of "honest verifier" of eth2 will be adjusted according to (1), and verifiers are not allowed to vote for the eth1 block with block number> TRANSITION_HEIGHT. If the voting algorithm has selected an eth1 block with a block number> TRANSITION_HEIGHT, it will be voted for the eth1 block of TRANSITION_HEIGHT.
- In addition, when (2) has been triggered, the verifier will set the deposit_count to be 2**63 higher than the actual value (that is, use the top bit of deposit_count as a mark of "eth1 completed")
- When eth2 accepts eth1data with the "eth1 completed" flag turned on, eth2 will perform an "unconventional state transition" and place the state root of the eth1 block in the "eth1 execution environment" (a type on eth2) System-level smart contract). The ETH equivalent to the total ETH supply on the eth1 chain will be added to the balance of this eth1 execution environment.
After this, the conversion is complete. From a technical perspective, the eth1 chain will continue to operate, but it has become a valueless chain; when the ice age arrives, this eth1 chain will completely disappear.
The eth1 system is now inside the eth2 system. Therefore, by submitting a transaction for the eth1 execution environment (that is, the eth2 subsystem described above) on eth2, eth1 is further transformed into the eth2 subsystem. The eth1 execution environment has the code that can implement the entire eth1 EVM and transaction processing logic; it has an update(state_root, transaction, witness) -> new_state_root function, which can follow the rules of the eth1 chain to trade and witness messages (the Merck in the state part) Evidence) as input to process the transaction and determine the updated eth1 state root. For the working principle of witness messages and state roots, please read " Stateless Client Concept ".
The eth1 execution environment code can add additional functions, that is, extract ETH and messages from the eth1 execution environment to other parts of eth2, as well as copies of the eth1 execution environment on other shards. By default, all eth1 accounts/contracts will be placed on the same shard, so in order to take advantage of the larger capacity of eth2, you need to actively use this function to transfer your ETH or other applications to other shards, but it is not difficult . We need to extend the ERC20 standard to support cross-shard token transfers.
How the user client works
Before switching to the two code paths, we need to modify the user-facing part of the client. The client will check eth2 to see if the conversion has occurred. If the conversion has not occurred, the client will use eth1 to send transactions, check the balance, etc., as before. The difference is that the client will pretend that all eth1 blocks with block number> TRANSITION_HEIGHT do not exist. If the conversion has occurred, the client will view the eth1 execution environment on eth2. The complete client will process all transactions on eth2 for the execution environment of eth1 in order to continue to update the complete eth1 state tree. This allows complete clients to generate witness messages for the transactions they want to send and "package" them in the eth2 format. Light clients (and wallets such as metamask) will broadcast their transactions to the complete client, who will add witness data to it.
From the user's point of view, Ethereum can "feel" before and after conversion (due to PoS and EIP 1559, Ethereum feels the latter more smoothly). Although the code paths used by packaging and broadcasting exchanges are very different, the functions they provide are the same.
We can even design this conversion so that the wallet can communicate with the client via RPC without any modification.
User case
Suppose you create a pledged debt warehouse on MakerDAO and then go to sleep. When you wake up, you find that the conversion has occurred. You can send a transaction to interact with your pledged debt warehouse and liquidate it as before, but your client will see that the conversion has been sent, so it will add the witness data to your transaction and send it to the eth2 network Not on the eth1 network.
Potential optimization
During the period from the time the eth1 chain reaches TRANSITION_HEIGHT to when the eth1 execution environment on eth2 obtains the state, we will perform some preprocessing on the eth1 state. In particular, we can:
- Replace the hexadecimal Patricia tree with a binary sparse Merkel tree and a special hash function to ensure that the hash overhead of the branch is kept at O(log(n)). This can reduce the size of Merkel tree branches by about 4 times.
- Replace RLP with SSZ hash tree
- Add data fields related to state rent to the account
- Clear "dust" account
- Modify the account structure according to the abstract proposal
We will not copy and use the state root generation method of Eth1 in EE, but apply the above modified method to calculate the state root (Instead of including the actual eth1 state root into the EE, we would include the root of the state tree generated by performing all of these modifications). This is a deterministic calculation, so all verifiers can perform calculations at the same time. This one-time computing expenditure can greatly improve the efficiency and availability of eth1 conversion.
Source link: ethresear.ch