Science | Ether Square 2.0's future blueprint and challenges

-Danny Ryan (Source: Crosslink 2019 Taiwan)-

Crosslink 2019 Taiwan , held at the Taipei Shibuya Convention Center in late October, attracted blockchain enthusiasts from all over the world. On the first day of the agenda, Danny Ryan, the core researcher of the Etherium Foundation (EF) , was invited to share the current research direction and challenges of Ethereum 2.0. The Ethereum 2.0 architecture, new sharding proposals, Execution Environments (EE), and Two-Way Bridge issues.

I. Architecture of Ethereum 2.0

• Wuzhen·Policy is coming. Are you waiting to be acquired by BAT or become the blockchain native BAT?
• "Bitcoin Revolution" report: Bitcoin economy is similar to Europe in the 16th century, optimistic about the derivatives market
• The world's first CBDC, Tunisia's counterattack

– Ethereum 2.0 architecture (Source: Crosslink 2019 Taiwan) –

Phase 0 (Phase 0)

In Ethereum 1.0 , Proof of Work (PoW) is used as a consensus mechanism to generate new blocks. In order to reduce the amount of computational power required to generate new blocks, and the problem of taking too long, Ethereum 2.0 will be replaced by Proof of Stake (PoS) as a consensus mechanism for generating new blocks.

In the zeroth phase , a Beacon Chain is established. The beacon chain is the Ethereum 2.0 system-level chain. When moving from Ethereum 1.0 to Ethereum 2.0, the beacon chain plays a very important role. The basis of the entire system.

Once the zeroth phase is completed, there will be two Ethereum chains in use. The Ethereum 1.0 chain (the current PoW main chain used) and the Ethereum 2.0 chain (new beacon chain). At this stage, the user locks the Ethercoin to the contract in the 1.0 chain to register the public key, and the 2.0 chain recognizes the public key registered in the contract. However, they cannot migrate the Ethereum back to the Ethereum 1.0 chain. In order to execute the beacon chain, you will need a beacon chain client. Currently, many teams are developing these clients.

Phase 1 (Phase 1)

In the first phase , Shard Chains will be added. At this stage, the data structure of the slice chain will be mainly focused on, as well as its validity and Consensus. The segmentation chain is only used as data at this stage. Chain does not specify a state chain execution (State Execution) or account balance (Account Balances). This is more like testing the slice structure instead of trying to use slice to extend the beacon chain. At this stage, the beacon chain treats the block of the slice chain as a collection of features or meanings (Collections Of Bits). Ethereum 1.0 and Ethereum 2.0 will still exist and will be tested and migrated on the Ethereum 2.0 chain.

At this stage, the fragmentation chain will be cross-linked with the beacon chain (Crosslinks) , and the current state of each fragment, " Combined Data Root ", will be periodically recorded in the "Beacon Chain" block as cross-linking. . After the beacon chain block is completed, the corresponding shard block will be considered completed, and the other shards will know that they can rely on these blocks for cross-slicing transactions.

Cross-linking is a set of signatures (Signatures) of the committee that proves that a block in the slice chain can be included in the beacon chain. Cross-linking is the primary way in which the beacon chain "understands" the status of the slice chain update. Cross-linking is also used as the infrastructure for asynchronous cross-sliced ​​communication.

The beacon chain randomly selects Shard Validators for each shard in each time slot . The shard verifier is only used to agree on the content of each block. They cross-link. It is irrelevant to prove the content and status of the fragment, and what is included in the fragment, as long as all committees reach a consensus and regularly update the beacon chain on the fragment.

Phase 2 (Phase 2)

The second phase will start with all the functions. In the second phase, the fragmentation will be completed. The fragmentation chain will transition from a simple data container to a structured chain state and will be reintroduced into the smart contract. Each shard will manage virtual machines based on eWASM (Ethereum flavored WebAssembly) . It supports accounts (Accounts), Contracts, States, and other abstractions we are familiar with in Solidity. It is expected that tools that are familiar to you before the second or second phase (eg Truffle, Solc) , Ganache) needs to be converted to support eWASM version, Ethereum 1.0 and Ethereum 2.0 can be interoperable by two-way bridging, there will be scalable Layer 1 execution, by stateless execution to improve execution speed.

Second, the new fragment proposal

– New shard proposal (Source: Crosslink 2019 Taiwan) –

The mechanism under which Ethereum 2.0's original proposal operates is to perform cross-linking operations in each period (Epoch) , with 1024 slices (Shards) per chain, when cross-chain trading (Tx) is required. Because there is a long delay time for cross-linking in each period; the new proposal is updated to cross-link every time period, and the number of Shards is reduced to 32 to reduce cross-sharding ( Cross-Shard) The delay in trading, with cross-segment trading at each time.

Advantages of the new proposal

For the advantages of the new Ethereum 2.0 proposal, the number of new proposals (Shards) was reduced from 1024 to 32, which reduced the complexity of the operation, because the time between fragments was reduced from one epoch to one slot, and the time was shortened. The benefit is a better experience for DApp developers and users. In the original Ethereum 2.0 design, a complex fee market model and an optimistic solution were required to achieve Cross-Shard Transaction Fee. But the new proposal changed the design of the execution environment, making the original complex model greatly simplified.

New proposal transaction

The new proposal only needs fewer pieces (Shards) than the previous proposal , and the transaction can be started. There may be a longer slice time (12s), a larger slice block (Shard Block) , which is currently updated to the zeroth. At the stage, the test of the Zeroth Phase Test Network (Testnets) may be delayed, and the new proposal reduces the time required for the release of the zeroth phase.

Current idea

I hope to give developers and users a better experience, using larger Shard Blocks to improve data availability and reduce development delays and time spent in the zeroth phase release.

Third, the implementation environment

– Ethereum 1.0 Simple Architecture Diagram (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 the states at any time, regardless of the concept of execution, the concept of transaction, the concept of account. The concept of a tree structure and all the concepts in the data structure are deeply integrated into the consensus.

Above is a simplified architecture diagram of Ethereum 1.0. In the figure we can see the consensus mechanism and a chain. The consensus mechanism contains the state and an execution engine. The state contains the state tree, where the execution engine is hardcoded. The rules, which include the execution of the transaction, the account model and the account structure, we can see that there is a chain on the right side of the diagram, and there is transaction data on the chain. In Ethereum 1.0, we will implement a consensus mechanism on the transaction data to modify and update status.

The execution environment is a separate virtual machine. In Ethereum 1.0, there is a specific account model (Account Model) , as well as pre-defined Opcodes , Gas Mechanisms, and State Roots. ) , Ethereum Virtual Machine (EVM) is a specific execution environment.

If you follow the EIP (Ethereum Improvement Proposals) recommendation, developers are always asking for new opcodes, or changing the cost of the mine to support their applications. There are many examples like Plasma and Zkrollup. You will need to modify the execution environment of EVM 1.0 to support their application (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, and so on. For example, you can define a Facebook vocabulary execution environment (Libra EE) to run Libra on Ethereum 2.0. Alternatively, you can define a Bitcoin execution environment (BitCoin EE) so that Bitcoin can be run on Ethereum 2.0.

– Ethereum 2.0 Simple Architecture Diagram (Source: Crosslink 2019 Taiwan) –

In the Ethereum 2.0 simple architecture diagram we can see the state root, which may be a 32 Bytes blob with the WASM Execution Code , which can be used to make detailed settings in the user hierarchy. There is a chain to the right of the picture. There is general transaction data and Witnesses on the chain. The witness is actually displayed in the database block. You need to execute the transaction for this status instead of the database, and you need to prove the data for the current The status root is valid. For example, if we want to pass a value between Account A and Account B, assuming we move 5 Ethereum from Account A to Account B, we can't directly say that the account and Balance are actually available. In the process, we Witness Data is required to prove the current status of the two accounts. The status root can modify and update the status tree when the execution code is executing transaction data.

The execution environment is not pre-defined by the consensus mechanism. It can be added at the user level. We can also copy Ethereum 1.0 to the Ethereum 2.0 execution environment and put the existing state root into the EVM. The interpreter uses the Merkle Witness Verifier as his execution code.

In the original proposal, the state and the consensus were closely related, and the execution account and consensus contained the state tree structure; in the new proposal, the execution environment was a stateless model, highly abstracted, and its Extensibility is much higher than the original proposal.

Execution environment advantages

The execution environment has many advantages. Compared to the old system, it may be able to bring products to market faster, because we don't have to wait until the core consensus is introduced before we can research and develop this concept. There will be fewer obstacles in Layer 1. It can use an execution engine with high scalability and data availability in a variety of applications, so this core infrastructure layer will be used for a long time in the future.

The design of the execution environment is completed, and the migration from Ethereum 1.0 to Ethereum 2.0 has a clearer direction. The use of the execution environment will not cause problems with the outdated technology migration over time.

Executive environmental trading

Developers and users may feel too abstract about executing environment transactions, and are confused about what is the execution environment. What does this layer add? What should I do at this level? Who should write the execution environment? And related development specifications will tend to be more rigorous.

Virtual machines can have potential fragmentation issues that can affect transaction speed.

Current idea

All current research is developing positively, and there is plenty of time to try and better understand the design space. In the future, it will take more time to build a better execution environment communication mechanism. Overall, the current stage of progress is an important milestone for the future.

Four-way bridging

The last topic, mainly discussing whether it is worthwhile to develop two-way bridging? At what point in time can the team do two-way bridging?

– One-way bridge diagram (Source: Crosslink 2019 Taiwan) –

In the proposal that the speaker mentioned earlier, Ethereum 2.0 originally had a one-way bridge, so you can switch from Ethereum 1.0 to Ethereum 2.0, but the original architecture does not allow for return, mainly for several reasons. This requires us to closely integrate the development of Ethereum 1.0 with the hard forks of Ethereum 1.0 and Ethereum 2.0, and put the two systems at risk of mutual influence, so the team believes that Ethereum 2.0 is released and stable before It is not wise to tightly couple the two sides.

One-way bridging problem

At the beginning of the month at Devcon 5 in Osaka, Japan, the issue of bridging was widely discussed. The original One-Way Bridge model had the problem of verifier liquidity and, more importantly, it might Will trigger an alternative issue between Ethereum 1.0 and Ethereum 2.0. If we allow liquidity on Ethereum 2.0, then some form of transfer mechanism will fork Ethereum 1.0 to Ethereum 2.0. Or, it is generated before the two-way bridge. It is likely that there will be two coins at the same time. The team and the entire certifier community are worried about this problem. Currently, we are looking for ways to alleviate this problem.

I also hope to encourage everyone to verify at these early stages, but to verify at an early stage, there will be high risks, because there is an unknown lock-up period, so I also hope to find ways to mitigate this risk.

Two-way bridge

– Two-way bridge diagram (Source: Crosslink 2019 Taiwan) –

There are two possible routes for two-way bridging. One is to build the Ethereum 2.0 light node above Ethereum 1.0, and the other is to run the Ethereum 2.0 full node on Ethereum 1.0.

Route A: Establish Ethereum 2.0 Light Node on Ethereum 1.0

– Path A schematic (Source: Crosslink 2019 Taiwan) –

This route requires BLS-12–381 in the actual EVM, which takes a lot of development time and it only provides lightweight client- level (Light-Client) level security. When the verifier generates a receipt for the withdrawal transaction on the 2.0 chain, we will get the Ethereum 2.0 lightweight client certificate. Once the receipt block is finalized on Ethereum 2.0, you can do it at Ethereum. Withdrawal on the contract of 1.0. However, this may not be the route the team ultimately chose.

Route B: Run Ethereum 2.0 on the Ethereum 1.0

– Path B schematic (Source: Crosslink 2019 Taiwan) –

The second route will run the full node of Ethereum 2.0 on the Ethereum 1.0 node. This route allows us to use the finalization mechanism, so we can not only use this mechanism to promote Ethereum 1.0 and Ethereum 2.0. The transfer between us, we can also use the security of the verifier to protect the Ethereum 1.0 chain, I think everyone is very excited about this, which is often called the "Finality Gadget Proposal".

But there is still a need for a mechanism to export the Ethereum 2.0 state root to Ethereum 1.0, so there are some discussions in the Ethereum 2.0 community that studying how to implement it may include a miner mechanism.

Another advantage of exporting the Ethereum 2.0 state root is that Ethereum 1.0 has a solid mechanism to achieve it, and with the high scalability and data availability of Ethereum 2.0, you can do some interesting applications like ZK Rollup and Optimistic. Rollup.

Advantages of two-way bridging

If you are on the exchange, list Ethereum 1.0 Ethereum and Ethereum 2.0 Ethereum, they should be the same price. If it is not the same, you can buy an Ethereum at a lower price, send him to the bridge, then get another Ethereum at a higher price and sell it. This arbitrage keeps their prices constant, which can be confusing for users, verifiers and developers. Two-way bridging prevents both sides of the currency from interchanging by arbitrage.

Two-way bridged transaction

However, there are still some trade-offs here. Despite the confidence in the design of Ethereum 2.0, the team hopes to be validated in the production environment before it affects the safety and risk profile of Ethereum 1.0.

Two-way bridging is a tightly coupled consensus mechanism. The attack on both sides of the chain and the problems that arise will affect the other side of the chain. The development of the agreement is bound to be very cumbersome. We need to consider the security of each agreement if we The sooner the protocol is developed, the less progress we actually have. As each obstacle develops over time, they will block each other, which makes Ethereum 1.0 develop much slower than Ethereum 2.0 at this point. Because the actual user community has a lot of concerns and requires a lot of coordination, we can get hard forks on our production network.

So, if we put these things together, the slower the development and forking cycle of Ethereum 2.0, and this adds some extra overhead. In other words, the overhead of verifying that we can link the client is relative. of.

Current idea

We should enable the bridge before adding the verifier's liquidity, but will wait until the first stage of the product is stable and then open; similarly, there are many related studies at the same time, which may affect when and complete the operation. .

Glossary:

1. EIP (Ethereum Improvement Proposals) : EIP is the standard of the Ethereum platform, which contains the specifications of the core protocol, client API and contract standards.
2. Epoch : In Ethereum 2.0, epoch refers to a time unit of 6.4 minutes, and each epoch contains 32 slots.
3. Slot : Each time period is 12 seconds, not necessarily every time period, and the last slot in epoch is called Boundary Slot , or C heckpoint .
4. Solidity : Solidity is a contract-oriented language used primarily to develop smart contracts.
5. Consensus : Consensus mechanism is an algorithm developed by blockchains to achieve consensus among nodes.
6. Validator : A node that verifies a block, randomly generated by a beacon chain for each slice (Shards) at each time slot (Slot).
7. Gas : The cost of the transaction, when the Gas is exhausted, the Smart Contract will terminate and Rollback.
8. EVM (Ethereum Virtual Machine) : EVM Chinese is an Ethereum virtual machine, which is a lightweight virtual machine environment. The operating environment of Eth 1.0 is EVM.
9. Dapp (Decentralized App) : In Ethereum , smart contract-based applications are called decentralized apps, Dapp (Decentralized App).
10. Ether (Ethernet) : The currency name of Ethereum.
11. Finality: " Knockdown " is a concept in Casper that is a mechanism for generating a checkback on a chain by a verifier vote.
12. Libra: The cryptocurrency proposed by Facebook is expected to be released in 2020.
13. Merkle Tree: Merkle Tree was proposed by computer scientist Ralph Merkle, which translates into a Merkel tree because it is a tree formed by a hash function.

Reference: Ethereum Improvement Proposals

Reference: Two-way bridges between eth1 and eth2

Reference: Ethereum 2.0 (Serenity) Phases

Reference: ethfans

Reference: eth2 quick update

Thanks to Danny Ryan, Chih Cheng Liang, Juin Chiu, Hsiao-Wei Wang, Yahsin Huang, and Jerry Ho.

(Finish)

Original link: https://medium.com/taipei-ethereum-meetup/eth2-0-roadmap-70e1c23f139f Author: Frank Lee

This article was first published in the Medium station of the Taipei Ethereum Meetup. EthFans was authorized to reprint. In order to comply with the habits of mainland readers, the simplified and traditional conversion was carried out and some terms were changed to idioms.

(This article is from the EthFans of Ethereum fans, and it is strictly forbidden to reprint without the permission of the author.

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