Interpretation of Wanxiang Blockchain Research Group: Viewing the Eccentric Development of Ethereum and Blockchain from Devcon5 Conference

Author: Universal Block Chain Group

Source: Universal Blockchain

Editor's Note: The original title is: [Million-way blockchain research team produced] From the Devcon5 conference to see the Ethereum and blockchain ecological development (on)

This article is a compilation of the contents of the conference after the team of the research team of the Wanxiang blockchain R&D department participated in Devcon5. The Wanxiang Blockchain R&D Research Group is a team that Wanxiang internally focuses on the research and development of the underlying technology of the blockchain.

• Speed ​​Reading | USV Li Li, Ethereum Developers Conference 6 years speech full collection summary
• US lawmakers: If Facebook can use Bitcoin directly, there will not be so much trouble.
• Competing for "5G+ blockchain"! The relevant person in charge of China's three major telecom operators confirmed to attend the World Blockchain Conference·Wuzhen

From October 8th to 11th, the highly anticipated Ethereum Annual Developers Conference Devcon5 (fifth) was held in Osaka, Japan. The article combines the content of the conference with community information to help you better understand the Ethereum ecosystem and some of the latest developments in the blockchain ecosystem. Regarding the development of Ethereum, the conference mainly exchanged the current progress of Ethereum 2.0, the accumulated development experience, the next step of planning, and how to switch between versions 1.0 and 2.0. In addition, the conference also focused on decentralized application user experience upgrades, encryption economy and cryptography, DeFi and other content. The article will be divided into two parts, this article is mainly for the development of the Ethereum ecology, the next part will be released some of the discussion on the current hot topics.

text

To understand the ecology of Ethereum, we must first understand the development path of Ethereum.

Ethereum1.X

At Devcon4 last year, a group of Ethereum core developers and enthusiasts discussed the current Ethereum challenges, they all have a similar view: due to the increasingly serious performance bottlenecks, and the storage space continues to increase, if the Ethereum main network Without seeking change, the availability of Ethereum will be very poor. The performance degradation is mainly due to excessive (and increasing) state data. Increasingly large storage requirements are mainly due to the need to retain blocks, event logs, and state history (which can currently be removed in most clients).

Finally, they came to a consensus: improvement, Ethereum main network must be improved!

They also gave the improvement plan a codename "Ethereum1.x". The major upgrades that Ethereum's main network plans to adopt in the near future are included.

The plan codenamed "Ethereum1.x" includes:

1. Improve the scalability of the main network by increasing the tps throughput (through client optimization, which will greatly increase the block's gas limit);

2. Reduce and limit disk space requirements through “storage rents” to ensure that the entire node is a sustainable operation. The specific approach is to design a rental model that requires contract developers and users to pay for EVM2 storage over time rather than storing code and data indefinitely.

3. Improve the developer experience with VM upgrades (including eWASM).

To achieve these goals and plans, Ethereine's core development team has established several working groups:

1. State rent: design a cost model for storage usage to limit storage occupancy on the chain;

2. eWASM: Ethereum Wasm virtual machine;

3, storage and cropping: optimize the storage space occupied by the client;

4. Simulation/simulation.

At this year's Devcon5, the Ethereum Foundation introduced several working groups that were established in the past year:

1. EVM evolution: optimizing performance, security, and interoperability;

2, EIP 1559: cost model optimization, making trading transaction costs more stable and predictable;

3. Testing/Infrastructure: Use new tools to help test clients to be more compatible with each other;

4. Final component: Use the Ethereum 2.0 beacon chain to finalize the blocks produced by Ethereum 1.0.

Hey, how come Ethereum 1.0 and 2.0? What does it have to do with Ethereum1.x?

To put it simply, the current main network of Ethereum is Ethereum 1.0, Ethereum 1.x is an improvement plan for the current main network, and Ethereum 2.0 is a chain developed independently of Ethereum 1.0. Ethereum 1.0 will switch to 2.0.

Next, we will focus on the Ethereum 2.0.

Ethereum2.0

Ethereum 2.0, the Serenity version of Ethereum, has just said that it is a chain developed independently of Ethereum 1.0. And at the Devcon4 conference last year, it was clear that Ethereum 2.0 would not replace Ethereum 1.0 functionally in 3-5 years.

Ethereum 2.0 will include a series of upgrades including Sharding, Proof of Stake Consensus and a new VM (ie eWASM).

Its main objectives are the following five:

☆   Decentralization: Allows a general consumer notebook computer to process and verify O(1) fragments (including system level such as beacon chain verification, etc.) using O(C) resources.

☆ Resilience: The system is still available when the main network partition or a large number of nodes are dropped.

☆ Security: Use cryptography and design techniques to ensure that a large number of verification nodes can participate in the system (both short-term and long-term).

☆ Simplicity: Minimize complexity even if there is some loss in performance.

☆ Longevity: Select quantum security components or easily replace them with corresponding quantum security components when available.

This is a big project, so it won't be done at a single point in time, but in stages. Here is a brief overview of the various phases and the goals they plan to accomplish.

Phase0

Beacon Chain

The Phase 0 phase is the start of the beacon chain. The beacon chain is the basis of the entire system for managing its own and the Casper Proof of Stake protocol for each shardchain:

1. Manage the verification node and its Stake;

2. Appoint the shard for each shard at each step;

3. Organizing the verification node as a verification committee for voting on the proposed block;

4. Run a consensus agreement;

5. Reward and punish the verification node;

6. As an anchor point, each shard registers its status, which facilitates the execution of cross-sliced ​​transactions.

The main data payload on the beacon chain is attestation, including the availability of a fragmented block and the PoS voting of a beacon block.

Phase0 will use Casper the Friendly Finality Gadget (FFG) to achieve final finality.

During Phase0, all user transactions and smart contract calculations were performed on Ethereum 1.0. After Phase0 is completed, there will be two chains at the same time: Ethereum 1.0 chain and Ethereum 2.0 chain.

Phase1 fragment blockchain (Shard Chain)

The fragmented blockchain is the key to future scalability because it allows for parallel execution of transactions. Phase1 focuses on the construction, validity, and consistency of the data in the fragmented blockchain, and does not implement state execution and account balances. Phase1 is more of a trial run of the sharded structure, rather than trying to implement extensions using shards. For the beacon chain, it treats the fragmented blocks as a set of bits rather than structured or meaningful data.

The crosslink is used in the beacon chain block to indicate the current state of the fragment (that is, the combined data root) over a period of time.

Crosslink is the effective signature set of the block node on the segment chain, which represents the latest state of the fragment blockchain and is also the basis for asynchronous communication across slices.

Phase2 state execution (State Execution)

In Phase 2, each related function will be aggregated. The data of the fragmented blockchain will no longer be a simple data container, but a reintroduced structured chain data and smart contract. Each shard manages eWASM-based VMs, supports accounts, contracts, status data, and more.

Phase 2 will most likely introduce State Rent, and contract developers and users will pay for eWASM storage.

Phase3 and later phases are constantly updated

Related plans are constantly being updated, see:

https://github.com/ethereum/wiki/wiki/Sharding-roadmap#phase-3-light-client-state-protocol

Among them, Phase0 is expected to go online in the first quarter of 2020, while Phase 1 and 2 are expected to go online at the end of 2020.

Randomness in Ethereum 2.0

At this Devcon5 conference, there are some discussion topics about randomness in Ethereum 2.0.

In today's blockchain systems, system randomness issues are receiving increasing attention.

Ethereum 2.0 uses a consensus protocol that combines PoS (Proof of Stake) and sharding mechanisms. The choice of consensus committee depends on the random values ​​generated by the system. Therefore, the security of the scheme is highly correlated with the randomness of the system to generate random values. Once a malicious attacker can manipulate or influence the generation of random values, they can take advantage of this, increase their chances of being elected to the committee during the consensus process, and reduce the cost of attacking the system, thereby threatening the security of the protocol.

Blockchain is the underlying platform for distributed applications. The secure random number provided on the chain is also an important guarantee for many applications.

Random numbers are mainly used in Ethereum 2.0 in the following three links:

Selection of block proposer

Selection of consensus committee

Chain application

A secure randomness algorithm needs to guarantee:

1. Unbiased: Any participant cannot influence the results of random number generation.

2. Unpredictable: Before the random number is generated, no participant can predict the outcome of the output in advance.

In addition, in order to meet the fault tolerance of distributed systems, the reliable randomness algorithm should also ensure that the algorithm continues to operate even when several nodes in the system stop working.

Therefore, a secure randomness algorithm can make:

1. Ensure the fairness of the block proposer selection, and prevent the attacker from predicting the identity of the proposer in advance and initiate a DOS attack;

2. Reduce the possibility of an attacker controlling a committee during the committee selection phase;

3. Ensure the security of the application on the chain that depends on random numbers.

Distributed randomness algorithm RANDAO

RANDAO is a simple distributed randomness algorithm that allows multiple nodes to negotiate interactively to produce consistent secure random numbers.

The algorithm consists of two phases:

Commitment stage (commit)

Revealing stage

In the commitment phase, all nodes in the system select a random number under each line and then submit a commitment to the random number to RANDAO.

In the revealing phase, each participant opens a promise to publish its random value, and the result of XORing all public random numbers is the random number generated by the round of the protocol.

But RANDAO is also flawed:

1. The random number generated by the RANDAO protocol satisfies the unpredictability and has the same fault tolerance as the underlying consensus protocol, but it still has defects in fairness.

2. In the protocol, in the revealing phase, the node that finally publishes its random value can affect the last generated random value.

3. Specifically, after seeing all the other nodes in the network publish the selected random numbers, the malicious attacker can perform an exclusive OR operation according to its own random number, and decide whether to publish its own random according to the pros and cons of the result. number.

4. This allows a single attacker to have a certain impact on the output, and as the number of participants controlled by the attacker increases, the destructiveness of such attacks increases.

5. For blockchain systems, if an attacker exploits the advantages gained in the random number generation process, it will reduce the cost of the attack system. Specifically, if a blockchain system uses RANDAO and the longest chain principle as a consensus protocol, the attacker only needs to have 36% of the stake to control the entire system. (Note: This analysis comes from Dalat Vitalik).

The method is always more difficult than the difficulties, and these defects are not without a solution. The VDF function is a "small pill" that addresses these RANDAO defects.

VDF function

VDF is a type of mathematical function (Verifable Delay Function), which is characterized by:

1. The calculation requires at least a known period of time.

2. Prove that the correctness of the function output can be verified quickly.

Using the computational delay of the VDF function, the node that finally published its random value in the RANDAO protocol can lose its effect on the final result.

Specifically, in the RANDAO protocol disclosure phase, the random values ​​published by all participants no longer pass a simple XOR operation, but the final random value is obtained through the VDF function, and the execution time of the VDF function is set to be greater than the waiting time of the disclosure phase. period. Then, the attacker cannot calculate the final random value in advance, and cannot determine the benefit of publishing his own random value to himself, thus ensuring the fairness of the randomness algorithm.

As we mentioned earlier, Ethereum 1.0 will switch to 2.0. This is another big project. How can this transition be smooth?

Ethereum1.0 to 2.0 switch

There are two important factors to consider when moving from the Ethereum 1.0 chain to the Ethereum 2.0 chain. First, you need to migrate existing Ethereum, and second, you need to migrate.

Phase0 Ethereum migration (beacon chain)

In phase 0, users on the Ethereum 1.0 chain will be able to lock their Ethereum in the contract and get the same amount of Ethereum on the beacon chain in Ethereum 2.0. They can then mortgage the Ethereum (32 ETHs) as a verifier and begin to receive a verification award on the Ethereum 2.0 chain.

Phase1 state migration (sharding)

In Phase 1, the state of the current Ethereum 1.0 chain is transferred to a slice on the Ethereum 2.0 chain. All information from the Ethereum 1.0 chain will be available on the Ethereum 2.0 chain. The current phase 1 and beyond have not yet entered a positive development phase.

Phase2 smart contract

This phase plans to reintroduce smart contracts and replace the current EVM with eWASM. In addition, the state rent, which is mentioned in Ethereum 1.x, may be implemented at this stage.

Phase3 chain state storage

Phase 3 will shift the state of the chain to the chain as much as possible to minimize the state of the chain. Maintaining and retrieving the state under the chain in Phase 3 will be a key design constraint for dApp.

Phase4 segmentation contract

Implement interaction between contracts on different shards. At present, various proposals for interoperability of fragmentation contracts do not seem to solve the contradiction problem of synchronization and expansion, which is one of the most challenging stages.

Today's sharing is here. Have you got a deeper understanding of the Ethereum ecological development? Tomorrow will continue to share the research group of the Universal Blockchain R&D Department, and more about the Devcon5 conference. Clicking to watch or share to a circle of friends is the biggest encouragement for our research group partners!

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