Future Blueprint and Challenges of Ethereum 2.0
Editor's Note: This article comes fromEthereum enthusiastEditor's Note: This article comes frommedium, translated by A Jian; the original text comes from
, author Frank Lee, reprinted with authorization by Odaily.
image descriptionCrosslink 2019 TaiwanDanny Ryan (Source: Crosslink 2019 Taiwan) -
1. Architecture of Ethereum 2.0
1. Architecture of Ethereum 2.0
Ethereum 2.0 Architecture (Source: Crosslink 2019 Taiwan)-
Phase 0 (Phase 0)
Phase 0 (Phase 0)
In Ethereum 1.0 (Ethereum 1.0), Proof of Work (PoW) is used as the consensus mechanism (Consensus) to generate new blocks. In order to reduce the large amount of computing power required to generate new blocks and the problem of taking too long, Ethereum 2.0 will change to Proof of Stake (PoS) as the consensus mechanism for generating new blocks.
Once phase zero is complete, there will be two Ethereum chains in use. Ethereum 1.0 chain (currently used PoW main chain) and Ethereum 2.0 chain (new beacon chain). At this stage, the user locks the Ethereum into the contract in the 1.0 chain to register the public key, and the 2.0 chain will recognize the public key registered in the contract. However, they cannot migrate that ether back to the Ethereum 1.0 chain, and in order to implement the beacon chain, you will need a beacon chain client. Currently, many teams are developing these clients.
Phase 1 (Phase 1)
Phase 1 (Phase 1)
In the first stage, shard chains will be added. At this stage, the main focus is on the data structure of the shard chain, as well as its validity (Validity) and consensus (Consensus). The shard chain is only used as data at this stage chain, and does not specify the state execution (State Execution) or account balance (Account Balances) of the shard chain. This is more like testing the sharding structure than trying to use sharding to scale the beacon chain. At this stage, the beacon chain will treat the block of the shard chain (Block) as a collection of bits (Collections Of Bits) without structure or meaning. Ethereum 1.0 and Ethereum 2.0 will still exist side-by-side, with testing and migration on the Ethereum 2.0 chain.
At this stage, the shard chain will be crosslinked with the beacon chain (Crosslinks), and the current state of each shard - "Combined Data Root (Combined Data Root)", will be regularly recorded in the "Beacon Chain" block as a crosslink . After the beacon chain block is completed, the corresponding shard block will be considered complete, and other shards know that they can rely on these blocks for cross-shard transactions.
For each shard in each slot of the beacon chain, shard validators are randomly selected, and the shard validators are only used to reach agreement on the content of each block. They pass the cross-link Proving the content and state of a shard, it doesn't matter what is contained in a shard, as long as all committees agree and regularly update the beacon chain on the shard.
The second phase (Phase 2)
2. New Fragmentation Proposal
2. New Fragmentation Proposal
image description
The mechanism operated by the original proposal of Ethereum 2.0 is to perform the cross-linking action in units of each period (Epoch). There are 1024 pieces (Shards) on each chain. When cross-shard chain transactions (Tx) are required , due to the cross-linking in each period, there will be a large delay; the new proposal is updated to perform cross-linking in each period, and reduce the number of shards (Shards) to 32 to reduce cross-sharding ( Cross-Shard) transaction delay time, cross-shard transactions are performed every time period.
Advantages of the new proposal
Regarding the advantages of the new proposal of Ethereum 2.0, first of all, the number of slices (Shards) of the new proposal is reduced from 1024 to 32, which reduces the complexity of the operation, because the cross-shard time is reduced from one epoch to one slot, and the time is shortened. The advantage is to give DApp developers and users a better experience. In the original design of Ethereum 2.0, a complex fee market model and an Optimistic solution were required to realize Cross-Shard Transaction Fee. But the new proposal changes the design of the execution environment, so that the original complex model can be greatly simplified.
New Proposed Transactions
The new proposal only needs fewer shards (Shards) than the previous proposal to start the transaction, there may be a longer sharding period (12s), a larger shard block (Shard Block), currently updated to the zeroth Phase 0, the testing of the Phase 0 Testnets (Testnets), may be delayed, and the new proposal reduces the time required for the Phase 0 release.
current thoughts
3. Execution environment
3. Execution environment
image description
Simple Architecture Diagram of Ethereum 1.0 (Source: Crosslink 2019 Taiwan)-
In the previously designed Ethereum 2.0 and Ethereum 1.0, the state plays a very important role in the consensus mechanism. The consensus mechanism will read and write all states at any time, regardless of the concept of execution, transaction, or account. , the concept of tree structures, and all of the concepts in data structures, are deeply embedded in the consensus.
The above picture is a simple architecture diagram of Ethereum 1.0. In the picture, we can see the consensus mechanism and a chain. The consensus mechanism includes a state and an execution engine. The state includes a state tree. The execution engine here is hard-coded Rules, which include execution transactions, account models, and account structures. We can see that there is a chain on the right side of the figure, and there is transaction data on the chain. In Ethereum 1.0, we will implement a consensus mechanism on transaction data to modify and update status.
If you follow the recommendations of EIP (Ethereum Improvement Proposals), developers are always asking for new opcodes, or changing the cost of miners (Gas Cost) to support their applications. There are many examples like Plasma and Zkrollup, so It will be necessary to modify the execution environment of EVM 1.0 to support their applications (DApp).
But in the second phase of Ethereum 2.0, we can support multiple execution environments. There can also be multiple state roots, different account models, etc. For example, you can define a Facebook Coin Execution Environment (Libra EE) to run Libra on Ethereum 2.0. Alternatively, you can define a Bitcoin Execution Environment (BitCoin EE) so that you can run Bitcoin on Ethereum 2.0.
image description
Simple Architecture Diagram of Ethereum 2.0 (Source: Crosslink 2019 Taiwan)-
In the simple architecture diagram of Ethereum 2.0, we can see the state root, which may be a 32 Bytes blob with WASM execution code (Execution Code) on it, which can be set in detail at the user level. There is a chain on the right side of the picture. There are general transaction data and witnesses on the chain. The witness is actually displayed in the block of the database. You need to execute the transaction against the state instead of the database, and you also need to prove that the data is for the current The status root is valid. For example, if we want to transfer values between account A and account B, suppose we move 5 ETH from account A to account B, we cannot directly say that the account and balance (Balance) are indeed available, in the process, we Witness Data needs to be added to prove the current state of the two accounts. When the execution code is executing transaction data, the state root can modify and update the state tree.
In the original proposal, state and consensus are closely related, and the execution account and consensus include a state tree structure; in the new proposal, the execution environment is a stateless model (Stateless Model), which is highly abstract, and its The scalability is much higher than the original proposal.
Advantages of the execution environment
Advantages of the execution environment
The design of the execution environment is completed, so that the migration from Ethereum 1.0 to Ethereum 2.0 has a clearer direction. Using the execution environment will not cause the problem of technology becoming obsolete over time.
Execute ambient transactions
Execute ambient transactions
Virtual machines may have potential fragmentation problems, which will affect transaction speed.
current thoughts
All current research is developing positively, and there is still plenty of time to try and better understand the design space. In the future, we will spend more time on establishing a better execution environment communication mechanism. Overall, the current progress is an important milestone for the future.
Four, two-way bridge
The last topic, mainly discusses whether it is worthwhile to develop a two-way bridge? At what point in time might the team be able to do a two-way bridge?
image description
In the proposal that the speaker mentioned earlier, Ethereum 2.0 originally had a one-way bridge, so you could switch from Ethereum 1.0 to Ethereum 2.0, but the original architecture did not allow backhaul, mainly for several reasons, This requires us to closely combine the development of Ethereum 1.0 with the hard fork of Ethereum 1.0 and Ethereum 2.0, and put the two systems at risk of mutual influence. Therefore, the team believes that before Ethereum 2.0 is released and stable, It is unwise to tightly couple the two sides.
The problem with one-way bridging
The problem with one-way bridging
bidirectional bridging
image description
There are currently two possible routes for two-way bridging. One is to build a light node of Ethereum 2.0 on top of Ethereum 1.0; the other is to operate a full node of Ethereum 2.0 on top of Ethereum 1.0.
Route A: On Ethereum 1.0, build an Ethereum 2.0 light node
Route A: On Ethereum 1.0, build an Ethereum 2.0 light node
image description
Route B: On Ethereum 1.0, run the full node of Ethereum 2.0
Route B: On Ethereum 1.0, run the full node of Ethereum 2.0
image description
Schematic diagram of Path B (Source: Crosslink 2019 Taiwan)-
The second route will run the full node of Ethereum 2.0 on the node of Ethereum 1.0. This route allows us to use the finalization mechanism. Therefore, we can not only use this mechanism to promote Ethereum 1.0 and Ethereum 2.0 We can also use validator security to protect the Ethereum 1.0 chain, and I think people are very excited about this, which is often referred to as the "Finality Gadget Proposal".
Another advantage of outputting the state root of Ethereum 2.0 is that Ethereum 1.0 has a solid mechanism to realize it, and at the same time has the high scalability and data availability of Ethereum 2.0, which can make some interesting applications, such as ZK Rollup and Optimistic Rollup.
Advantages of bidirectional bridging
If you're on an exchange, listing Ethereum 1.0 Ether and Ethereum 2.0 Ether, they should be priced the same. If not, you can buy one ether at a lower price, send it to the bridge, get another ether at a higher price, and sell it. This arbitrage keeps their prices constant, which confuses users, validators, and developers, and the two-way bridge prevents the currencies on both sides from being converted into each other by means of arbitrage.
two-way bridging transaction
two-way bridging transaction
But there are some trade-offs here, and while very confident in the design of Ethereum 2.0, the team wants to validate it in production before impacting the security and risk profile of Ethereum 1.0.
So, if we link these things together sooner, it may slow down the development and fork cycle of Ethereum 2.0, and this adds some additional overhead, in other words, the overhead of verifying that we can link clients is relatively of.
We should enable the bridge before adding validator liquidity, but wait until the first phase of the product is stable; again, there are many related researches going on at the same time, which may affect when to complete this operation .
Glossary:
Glossary:
Glossary:
EIP (Ethereum Improvement Proposals): EIP is the standard of the Ethereum platform, and its content includes the specification of the core protocol, client API and contract standards.
Epoch: In Ethereum 2.0, epoch refers to a time unit that lasts 6.4 minutes, and each epoch contains 32 slots.
Slot (period): Each period is 12 seconds, and blocks may not be generated in every period, and the last slot in the epoch is called the boundary period (Boundary Slot), or called the checkpoint (C checkpoint).
Solidity: Solidity is a contract-oriented language, mainly used to develop smart contracts.
Consensus (consensus mechanism): The consensus mechanism is an algorithm developed by the blockchain in order to reach a consensus among nodes.
Validator: The node that verifies the block is randomly generated by the beacon chain for each Shards in each slot.
Gas: The fee required for the transaction. When the Gas is exhausted, the smart contract will be terminated and Rollback will be performed.
EVM (Ethereum Virtual Machine): EVM is the Ethereum Virtual Machine in Chinese, which is a lightweight virtual machine environment. The operating environment of smart contracts in Eth 1.0 is EVM.
Dapp (Decentralized App): In Ethereum, applications based on smart contracts are called decentralized applications, namely Dapp (Decentralized App).
ether (Ether currency): The name of the currency of Ethereum.
Finality: "Finality" is a concept in Casper, and it is a mechanism to generate irreversible (Rollback) checkpoints on the chain through validator votes.
Libra: The cryptocurrency proposed by Facebook, which is expected to be released in 2020.Ethereum Improvement Proposals
Merkle Tree: Merkle Tree was proposed by computer scientist Ralph Merkle. It is translated as Merkle tree in Chinese because it is a tree formed by a hash function.Two-way bridges between eth1 and eth2
refer to:Ethereum 2.0 （Serenity） Phases
refer to:ethfans
refer to:eth2 quick update
refer to:
