Looking at the ecological development of Ethereum and blockchain from the Devcon5 conference
Editor's Note: This article is from Wanxiang Blockchain (ID: gh_1b8639a25429), author: Wanxiang Blockchain Research Group, and is published with authorization.
This article is some interpretation of the content of the conference after the research team of Wanxiang Blockchain R&D Department participated in Devcon5. The research group of Wanxiang Blockchain R&D Department is a team within Wanxiang that focuses on the research and implementation of the underlying blockchain technology.
text
text
secondary title
Ethereum1.X
At last year's Devcon4, a group of Ethereum core developers and enthusiasts discussed the current challenges of Ethereum. They all had a similar view: due to the increasingly serious performance bottlenecks and the continuous increase in occupied storage space, if the Ethereum mainnet Without seeking change, the usability of Ethereum will become very poor. The performance degradation is mainly due to the large (and growing) state data. Increasing storage requirements, mainly due to the need to persist blocks, event logs (receipts), and state history (currently deletable in most clients).
In the end, they came to a consensus: Improve, the Ethereum mainnet must be improved!
They also gave the improvement plan a code name "Ethereum1.x". Various major upgrades and updates that the Ethereum mainnet plans to adopt in the near future are included.
The initiative 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 gas limit of the block);
2. Through "storage rent" to reduce and limit the demand for disk space, so as to ensure the sustainable operation of the entire node. The specific approach is to design a rent model that requires contract developers and users to pay for EVM2 storage over time, rather than storing code and data indefinitely.
3. Improved developer experience through VM upgrades (including eWASM).
To achieve these goals and plans, the Ethereum core development team established several working groups:
1. State rent: design the cost model of storage occupancy to limit the storage occupancy on the chain;
2. eWASM: Ethereum Wasm virtual machine;
3. Storage pruning: optimize the storage space occupied by the client;
4. Simulation/simulation.
At this year's Devcon5, the Ethereum Foundation introduced several working groups established in the past year:
1. EVM evolution: optimize performance, security and interoperability;
2. EIP 1559: Cost model optimization to make transaction costs more stable and predictable;
3. Testing/Infrastructure: Use new tools to help test clients to be more compatible with each other;
4. Finality components: use the Ethereum2.0 beacon chain to finalize the blocks produced by Ethereum1.0.
Hey, how come there are Ethereum 1.0 and 2.0? How do they relate to Ethereum 1.x?
To put it simply, the current main network of Ethereum is Ethereum1.0, Ethereum1.x is an improvement plan for the current main network, and Ethereum2.0 is a chain developed independently of Ethereum1.0. Ethereum1.0 will switch to 2.0.
secondary title
Ethereum2.0
Ethereum 2.0 is the Serenity version of Ethereum. As I said just now, it is a chain developed independently of Ethereum 1.0. And at the Devcon4 conference last year, it was made clear that Ethereum 2.0 will not replace Ethereum 1.0 functionally within 3-5 years.
Ethereum 2.0 will include a series of upgrades such as Sharding (sharding), Proof of Stake consensus, and a new VM (ie eWASM).
It has five main goals:
☆ Decentralization: Allows ordinary consumer-grade notebook computers to use O(C) resources to process and verify O(1) fragments (including system-level verification such as beacon chains, etc.).
☆ Resilience: The system is still available when the main network is partitioned or a large number of nodes are offline.
☆ Security (Security): Use cryptography and design techniques to ensure that a large number of verification nodes can participate in the system (in the short and long term).
☆ Simplicity (Simplicity): Minimize complexity, even if there is some loss in performance.
☆ Longevity: Select quantum-safe components, or easily replace them with corresponding quantum-safe components when available.
This is a big project, so it will not be completed at a single point in time, but will be developed in stages. Here is a brief description of each phase and what it plans to accomplish.
Phase0 Beacon Chain
Phase0 is the start of the beacon chain. The beacon chain is the foundation of the entire system, and is used to manage itself and the Casper Proof of Stake protocol of each shardchain:
1. Manage verification nodes and their stakes;
2. Appoint a block producer for each shard at each step;
3. Organize the verification nodes into a verification committee (committee), which is used to vote on the proposed block;
4. Run the consensus protocol;
5. Reward and punish verification nodes;
6. As an anchor point, each shard registers its status with it, thus facilitating the execution of transactions across shards.
The main data load on the beacon chain is attestation, including availability votes for shard blocks and PoS votes for beacon blocks.
Phase0 will use Casper the Friendly Finality Gadget (FFG) to achieve finality.
During Phase0, all user transactions and smart contract calculations are performed on Ethereum1.0. After Phase0 is completed, there will be two chains at the same time: Ethereum1.0 chain and Ethereum2.0 chain.
Phase1 Shard Chain (Shard Chain)
Sharded blockchains are the key to future scalability because they allow transactions to be executed in parallel. Phase 1 mainly focuses on the construction, validity and consistency of data in the sharded blockchain, but does not implement state execution and account balances. Phase 1 is more of a trial run of the sharding structure than an attempt to scale using sharding. For the beacon chain, it treats sharded blocks as collections of bits rather than structured or meaningful data.
The crosslink is used in the beacon chain block to represent the current state of the shard (that is, the combined data root) over a period of time.
Crosslink is the set of effective signatures of the block by the verification node committee on the shard chain, which represents the latest state of the shard blockchain and is also the basis for asynchronous communication across shards.
Phase2 state execution (State Execution)
In Phase2, all relevant functions will be aggregated. The data of the fragmented blockchain will no longer be a simple data container, but re-introduced structured chain data and smart contracts. Each shard manages eWASM-based VMs, supporting accounts, contracts, state data, etc.
It is very likely that State Rent will be introduced in Phase 2, and contract developers and users will pay for eWASM storage.
Phase3 and subsequent stages are constantly being updated
Relevant plans are constantly being updated, for details, please refer to:
secondary title
Randomness in Ethereum 2.0
In this Devcon5 meeting, there are some discussion topics about randomness in Ethereum 2.0.
In today's blockchain system, the problem of system randomness is receiving more and more attention.
Ethereum 2.0 adopts a consensus protocol combining PoS (Proof of Stake) and sharding mechanism, and the selection of the consensus committee depends on the random value generated by the system. Therefore, the security of the scheme is highly related to the randomness of the random values generated by the system. Once malicious attackers can manipulate or influence the generation of random values, they can take advantage of this advantage to increase their chances of being selected into the committee during the consensus process, reduce the cost of attacking the system, and threaten the security of the protocol.
Blockchain is the underlying platform for carrying distributed applications, and the secure random numbers provided on the chain are also an important guarantee for the security of many applications.
Random numbers are mainly used in the following three links in Ethereum2.0:
Selection of Block Proposers
Selection of Consensus Committee
Chain application
A secure randomness algorithm needs to guarantee:
1. Fairness (unbiased): Any participant cannot affect the result of random number generation.
2. Unpredictable: Before the random number is generated, no participant can predict the output result in advance.
In addition, in order to meet the fault tolerance of the distributed system, a reliable randomness algorithm should also ensure that the algorithm continues to run even when several nodes in the system stop working.
Therefore, a secure randomness algorithm such that:
1. Ensure the fairness of block proposer selection, and prevent attackers from predicting the identity of the proposer in advance and launching DOS attacks;
2. In the committee selection stage, reduce the possibility of an attacker controlling a certain committee;
secondary title
Distributed Randomness Algorithm RANDAO
RANDAO is a simple distributed randomness algorithm that enables multiple nodes to negotiate interactively to generate consistent secure random numbers.
The algorithm consists of two stages:
Commitment phase (commit)
Reveal stage (reveal)
In the commitment phase, all nodes in the system select a certain random number offline, and then submit a commitment to the random number to RANDAO.
In the revealing phase, each participant opens a commitment to publish its random value, and the result of XOR operation of all public random numbers is the random number generated by this round of agreement.
But RANDAO is also flawed:
1. The random numbers generated by the RANDAO protocol are unpredictable and have the same fault tolerance as the underlying consensus protocol, but there are still flaws in fairness.
2. In the protocol, in the revealing phase, the node that finally announces its random value can affect the final generated random value.
3. Specifically, after the malicious attacker sees that all other nodes in the network publish their selected random numbers, they can perform XOR operations based on their own random numbers, and decide whether to publish their own random numbers according to the pros and cons of the results for themselves. number.
4. This allows a single attacker to have a certain impact on the output. At the same time, as the number of participants controlled by the attacker increases, the destructiveness of this type of attack also increases.
5. For the blockchain system, if the attacker takes advantage of the advantage obtained in the random number generation process, it will reduce the cost required to attack the system. Specifically, if a blockchain system adopts RANDAO and the longest chain principle as the consensus protocol, an attacker only needs to own 36% of the pledge (stake) to control the entire system. (Note: This analysis comes from the big guy Vitalik).
secondary title
VDF function
VDF is a kind of mathematical function (Verifable Delay Function), which is characterized by:
1. The calculation requires at least a known period of time.
2. Through the proof, the correctness of the output result of the function can be quickly verified.
Utilizing the calculation delay of the VDF function, the node that finally announces its random value in the RANDAO protocol can lose its influence on the final result.
Specifically, in the revealing phase of the RANDAO protocol, the random value announced by all participants is no longer a simple XOR operation, but the final random value is obtained through the VDF function. Expect. Then, the attacker cannot calculate the final random value in advance, and cannot determine the benefits to himself of publishing his own random value, thus ensuring the fairness of the randomness algorithm.
secondary title
Switch from Ethereum 1.0 to 2.0
Migrating from the Ethereum1.0 chain to the Ethereum2.0 chain needs to consider two important factors. First, existing ether needs to be migrated, and second, state needs to be migrated.
Phase0 Ethereum Migration (Beacon Chain)
In Phase 0, users on the Ethereum 1.0 chain will be able to lock their Ether in a contract and receive an equivalent amount of Ether on the Beacon Chain in Ethereum 2.0. After that, they can stake ETH (32 ETH) to become validators, and start to receive validation rewards on the Ethereum2.0 chain.
Phase1 state transition (sharding)
In Phase 1, the state of the current Ethereum1.0 chain is transferred to a shard on the Ethereum2.0 chain. It is guaranteed that all information from the Ethereum1.0 chain will be available on the Ethereum2.0 chain. Phase 1 and beyond are currently not in active development.
Phase2 Smart Contract
This phase plans to reintroduce smart contracts and replace the current EVM with eWASM. In addition, the concept of state rent, which was mentioned in Ethereum1.x, may be implemented at this stage.
Phase3 off-chain state storage
Phase 3 will try to transfer the state on the chain to the off-chain as much as possible, thereby minimizing the state on the chain. Maintaining and retrieving off-chain state in Phase 3 will be a critical design constraint for dApps.
Phase4 Fragmentation Contract
Realize the interaction between contracts on different shards. Among the various current proposals on the interoperability of sharding contracts, it seems that none of them can solve the contradictory issues of synchronization and expansion, which is also one of the most challenging stages.
