Ethereum Beacon Chain Explained
Ethereum 2.0, also known as Serenity, is a term that is used to describe a series of planned upgrades, with the Ethereum beacon chain being the first, that will be implemented on the Ethereum platform. These changes will be rolled out incrementally over the course of the next few years. Once implemented, it is hoped that these upgrades will produce a more efficient and scalable Ethereum platform that is able to handle thousands of transactions per second.
The objectives of Ethereum 2.0 extend beyond being able to process transactions at scale, they also include other design goals, such as:
- Simplicity: to minimize complexity, even at the cost of some losses in efficiency.
- Resilience: to remain live through major network partitions and when a very large portion of nodes go offline.
- Longevity: to select all components such that they are either quantum secure or can be easily swapped out for quantum secure counterparts when they become available.
- Security: to utilize crypto and design techniques that allow for a large participation of validators in total and per unit time.
- Decentralization: to allow for a typical consumer laptop to process and validate shards.
As the image above demonstrates, the core upgrades expected to be implemented on Ethereum include:
- Phase 0: Beacon Chain
- Phase 1: Shard Chains
- Phase 2: Execution Engine
The Ethereum beacon chain is a proof of stake based blockchain that will be at the heart of the Ethereum 2.0 system. Intended to be the first component that will be delivered on the Ethereum 2.0 roadmap, the primary responsibilities of the Ethereum beacon chain include:
- Store and maintain the registry of validators.
- Process crosslinks.
- Process its block-by-block consensus and the finality gadget.
Validators and Consensus
The Ethereum beacon chain is a proof of stake based blockchain, thus, there are no miners to participate in proof of work mining. Instead, participants in the beacon chain’s proof of stake consensus process are known as validators. A validator is a registered participant that can create and propose new blocks for the beacon chain. A validator is also responsible for validating the block proposal of another validator. A validator who creates and proposes a beacon chain block is known as a proposer, while a validator who validates the proposal is called an attestor.
Validators validate a block by confirming that the block has been formed correctly, and agree to it being included in the Ethereum beacon chain by voting for it. Validators who validate block proposals can also be said to ‘attest to block proposals’ (an attestation can also be regarded as being a vote for a block proposal), in other words, attestors sign off on a beacon block before it is included in the beacon chain.
It is only validators that are marked as ‘active’ that can propose and attest to beacon blocks. Proposers and attestors are randomly selected from a pool of active validators using a randomizer known as RANDAO+VDF. All randomly selected attestors are grouped together to form a committee. This committee of attestors are responsible for validating block proposals. The minimum number of attestors needed in a committee, for the purposes of validating a block proposal, is at the time of writing, 111. The time-frame taken to propose and validate a block is known as a slot, and a set of slots during which all randomly selected attestors have had the opportunity to make an attestation is called an epoch.
During the initial stages of Ethereum 2.0 the only way to become a validator is to initiate a one-way transaction of 32 ether to a deposit contract on Ethereum 1.0 (which is the current proof of work Ethereum mainnet). Activation as a validator occurs when: a deposit receipt (an event readable by blockchain clients) is generated and processed by the Ethereum beacon chain, the activation balance of 32 ether is reached, and after the conclusion of a queuing process.
It is possible for a validator to lose part of their staked 32 ether over time if they go offline. A loss of staked ether will increase dramatically as time passes, meaning that shorter periods spent offline will be more forgiving than longer ones. However, a validator will not lose all of their staked ether, instead, the validator will lose ether until a certain threshold is reached, and then be ejected from the pool of validators. Currently this threshold is 16 ether, thus, if a validator’s stake falls below 16 ether, that validator will be ejected from the pool of validators.
A validator can remain a participant in the proof of stake consensus mechanism process indefinitely, provided that they do not misbehave, by for example, claiming that a transaction is valid when it is not. This behaviour will result in a loss of staked ether called slashing, and the algorithm carrying out these punitive measures is known as ‘Slasher’. The Ethereum beacon chain is responsible for tracking and updating validators’ deposits as they earn rewards for good behaviour, and have rewards slashed for bad behaviour. It is also important to note that once 32 ether has been sent to the deposit contract, there is no way of withdrawing that ether back onto the current Ethereum proof of work chain. The funds can only be utilized in the context of the new proof of stake system.
Crosslinks
As mentioned above, phase 1 of Ethereum 2.0 is the deployment of so called ‘shard chains’. Shard chains represent a sharding scaling technique that originates from traditional database sharding, where a given database is separated into several pieces and placed in different severs to improve performance and manageability. In the context of Ethereum, transactions that are executed on the Ethereum platform will take place and be split into numerous shard chains. The rationale behind having multiple shard chains is to prevent every single node from having to process every single transaction on the network. By splitting transactions across multiple shard chains, it is hoped that the Ethereum platform will be able to process significantly more transactions per second.
Once shard chains have been deployed, each shard will be assigned a randomly selected active validator who will form a block of transactions from the transactions that have been executed on that shard. The validator will then propose a shard block that will be voted on (or attested to) by a randomly selected sharding committee. A sufficient number of attestations for the proposed shard block will create a ‘crosslink’, which confirms that shard block to be included into the Ethereum beacon chain. Crosslinks are the primary means by which the beacon chain can pick up the updated state of shard chains.
Casper FFG (Friendly Finality Gadget)
Settlement finality, or simply finality, is the notion that once an operation has been completed, that operation is completed for good and cannot be reverted. Finality in the context of decentralized systems such as Bitcoin, is understood as being block confirmations. For example, with Bitcoin, a transaction is largely considered to be final when it has received at least 6 block confirmations, as the likelihood of the transaction being attacked in some way, by for example a double-spend, is considerably low.
Casper FFG is an overlay protocol atop a proposal mechanism (as can be found with the Ethereum beacon chain), that is intended to provide stronger finality guarantees than proof of work. Primarily, Casper is responsible for finalizing blocks that are proposed for inclusion in the beacon chain.
Casper is argued to provide stronger finality guarantees than proof of work because there is firstly a standard definition of finality. Finality, in the context of Casper, takes place when 2/3 of validators make maximum-odds bets that a given block will be finalized. This 2/3 majority is a strong incentive that discourages validators from colluding to revert a given block. This is because validators who attempt to collude will stand to lose their deposits for misbehaving.
Another way that Casper provides stronger finality guarantees than proof of work is that validators are pre-registered. Thus, there is no possibility that there is another group of validators making a longer blockchain to try and disrupt the existing one.
Conclusion
To conclude, the implementation of the beacon chain is the first step in a series of changes that are designed to significantly improve the functionality of the Ethereum platform. When the Ethereum beacon chain is deployed, it is intended that the proof of stake chain operate alongside the existing proof of work chain until the latter is retired sometime in the future.
