The term Ethereum 2.0 describes a new and improved Ethereum blockchain that is more scalable, faster and a better blockchain. As Ethereum core researcher Danny Ryan said, the main design goals for Ethereum 2.0 are:
- System resilience: the goal is to keep the system running in the face of massive node outages or network fragmentation.
- Security: the goal is to use encryption and design mechanisms to enable as many authentication nodes as possible to fully participate in verification for each unit of time.
- Simplicity: the lower the system complexity, the better. Efficiency can even be sacrificed to lower the complexity.
- Persistence: choosing components for the system that guarantees quantum security. If the component cannot be quantum-safe for the time being, then choosing a component that can be easily replaced. In the future, when there are quantum-safe components, these temporary components can be easily replaced.
- Decentralization: the goal is to allow an ordinary laptop to process/validate O(1) sharding tasks (including any system-level validation such as validation in the beacon chain) using O(C) complexity resources. This will allow more low-end devices to participate in the network.
To understand how all this works, let’s look at the details of each Serenity phase:
Since Ethereum’s launch, four phases of development have been planned: Frontier, Homestead, Metropolis, and Serenity. As of now, Ethereum has already gone through the first three phases. As Ethereum has progressed through each phase, it has ushered in the era of smart contracts and helped kick off the blockchain 2.0 era.
Ethereum 2.0 itself is a radical overhaul, a complete revision, and redesign, that will take a number of years to fully launch. But before Ethereum enters its second iteration, known as Serenity, the original Ethereum chain, or Ethereum 1.0 will go through its own changes — Istanbul and Ethereum 1.x. Ethereum 1.x will continue to be refined to ensure the continuity of the original PoW chain as Ethereum moves towards Serenity. But in terms of Serenity, what will it really change?
Perhaps the biggest change is the complete transition from PoW (Proof-of-Work) to PoS (Proof-of-Stake). To do this and other changes, Serenity upgrades will be implemented in four phases:
- Phase 0: Beacon Chains
- Phase 1: Shard Chains
- Phase 2: eWASM replaces the Ethereum Virtual Machine (EVM)
- Phase 3: Continued improvements
The first thing that needs to be implemented is the establishment of the beacon chain.
Preston Van Loon, the co-founder of Prysmatic Labs, announced the launch of the Ethereum 2.0 beacon chain test network in a May 2019 post on Medium, marking the completion of the phase 0 test network.
The beacon chain is the chain using the POS consensus algorithm, which is the infrastructure of Ethereum 2.0. In the second phase of Ethereum 2.0, shard chains will be operated with the help of the beacon chain.
The beacon chain works by randomly assigning different validators to each shard in order to issue blocks, while also assigning a committee to each shard chain. The committee’s role is to vote on the blocks generated by validators of the shard chain.
The middle block of the shard chain needs to be agreed upon by more than half of the committee members. Shard chains can also use beacon chains to complete operations across shards. For now, the beacon chain will run in parallel with the Ethereum 1.0 chain and will continue to depend on the state of that chain.
How Does The Beacon Chain Work?
The beacon chain uses the PoS algorithm. In the PoS algorithm, the probability of each miner producing a block is proportional to the equity of the miner. However, every miner in the beacon chain actually has the same rights.
Each miner can only pledge 32ETH to the beacon chain. To be a beacon chain validator, you need to send a transaction to Deposit Contracts on Ethereum 1.0, which requires you to carry 32ETH. There are two parameters in the public method of Deposit Contracts on Ethereum 1.0:
- Pubkey, the signing public key for validators in the beacon chain
- Withdrawal_credentials, which is used to later retrieve the mortgaged ETH
When the deposit contract is successfully called, the contract returns a log event, and the beacon chain will automatically be informed of events on the Ethereum 1.0 chain.
The beacon chain will mark newly added validators as Pending Validators. After a while, they will become Active Validators, which means they can participate in block generation.
The beacon chain will penalize long periods of inactivity or bad validators. When the rights of validators’ equity are reduced to 16ETH, they will not be able to participate in the operation of the POS protocol. Finally, beacons will exclude validators with equity lower than 16ETH.
The following information is maintained in the beacon chain block:
- Registered validators
- Pending Validators, accounts that will be added to the list of validators
- Active Validators, accounts that have been added to the validator list
- Exit Validators, accounts leaving the validator list
- Polling information
- The votes of the validators
- Random Number, which is used to randomly select the proposer and the committee
Validators need to be selected as a proposer before a block can be submitted. The right to submit the next block in Ethereum 1.0 is determined by the computing power of the miner. If the processing power of the miner is large, the miner has a great probability of being selected as the producer of the next block.
In Ethereum 2.0, the selection of outgoing block nodes is based on a random number; it is difficult to generate a high-quality random number in a blockchain system. However, the POS protocol requires that the source of a random number be distributed, verifiable, unpredictable, and irreplaceable.
Using a random number to select a proposer from a group of validators makes it impossible for the validator to know who was selected. This can prevent them from colluding to launch attacks.
A block is generated every 6 seconds in the beacon chain. These 6 seconds are also called slot gaps. During each gap, the selected proposer collects all the votes from the beacon chain’s previous block’s validators and uses them to form a new block.
The block proposed by the proposer needs to be voted before it can be entered into the main chain of the beacon chain.
The committee may vote on the block proposed by the proposer, and the block that has passed the vote may receive a final confirmation. Ideally, if votes can be collected quickly, members in the committee would all be active validators in the system.
Fork Choice Rule
In Ethereum, the longest chain is determined by computing power, whereas Ethereum 2.0’s beacon chain uses the POS algorithm instead. Therefore a different set of rules will be needed to determine which fork chain everyone needs to follow. Beacon chains resolve this by using LMD GHOST (Latest Message Driven GHOST). This method involves an algorithm that runs based on messages, or in other words, by voting. In general, the fork chain with the most votes will be considered the main chain.
The smiley face represents voting information. The number in each block represents the total number of votes, which is the weight of the block.
In the image above, although the top chain is the longest chain, the green chain is the main chain.
Sharding chains are the core feature of the future scalability of the Ethereum 2.0 network.
Fragmentation refers to the separation of data processing responsibilities of multiple nodes in a database (e.g. a decentralized database or other types of databases), allowing simultaneous transactions, storage, and information processing.
The sharding concept is very different from the current Ethereum 1.0 model, which requires every full node to process and verify each transaction.
Phase 1 will deal with the final certainty and consensus of the sharding chain. It’s best to keep in mind that the sharding chain at this stage is more of a “test run” rather than an immediate solution to blockchain’s scaling problem.
The beacon chain will monitor the implementation of the sharding chain.
After a verifier pledges 32 ETH, it will be randomly assigned to a specific sharding chain for verification (randomness here ensures that the allocation path of the verifier is unpredictable, otherwise it will face the risk of manipulation).
According to the Ethereum 2.0 specification, the beacon chain will support 1024 shard chains, with 128 nodes per shard chain for validation.
In phase two, and with the introduction of the new virtual machine eWASM (Ethereum-flavored WebAssembly), the sharding chain will evolve from a fairly basic data markup form into a fully functional transaction chain, thus taking on the responsibility of the expansion of the Ethereum network.
To maintain the normal operation of the blockchain ecosystem, nodes must execute transactions and smart contracts in virtual machines.
The virtual machine for Ethereum 1.0 is called EVM. After switching to Ethereum 2.0, the Ethereum network’s virtual machine will be upgraded to eWASM, a WebAssembly-based virtual machine defined as an open-source standard by the World Wide Web Consortium (W3C).
Since WASM supports multiple coding languages, eWASM enables smart contracts written in any language to run on Ethereum. Contrast that with EVM for Ethereum 1.0 which only allows smart contracts written in the Solidity programming language.
ETH 1.x is a code name for a series of upgrades for Ethereum 1.0 as it will first take 2–3 years for Ethereum 2.0 to be fully launched, which means the current Ethereum will still be regularly used. The beacon chain in phase 0 and the fragment chain in phase 1 will be completed within 1–2 years. eWASM, which will be implemented in phase 2, will be completed sometime in 2022.
Ethereum 2.0 is deployed as a standalone blockchain, so it will not replace Ethereum 1.0, which means that the Ethereum 1.0 chain needs to be sustainable for the next 5–10 years.
The team behind Ethereum 1.x is still in the early stages of establishing a roadmap, but they have decided on the three primary goals for the Ethereum 1.x upgrade:
- Increase the throughput per second to increase the scalability of the main network (by optimizing the client so that the network can continuously increase the Gas limit of the block)
- Ensure that the full node can run for a long time (through “state rent” reduction and by limiting full node disk space requirements)
- Optimize the developer experience through virtual machine upgrades including eWASM, and stabilize the overall transaction cost by using different transaction cost models
Vitalik Buterin once said: “Ethereum 1.0 is a couple of peoples’ scrappy attempt to build the world computer; Ethereum 2.0 will actually be the world computer”
If Ethereum really fulfills their goals, then we will usher in a real world computer with a fully scalable universal blockchain. We can’t wait to see it!