Validator Attestations and Voting Protocols
How the beacon blockchain remains alive and eventually achieves finality
Assuming a Validator is online and actively participating in the protocol, then they will consider the blockchain fork with the most “accumulated votes” as the canonical chain (the one true blockchain).
We use speech marks for “votes” as not all votes are equal. A vote is a proxy to determine a Validator’s weight. The voting weight is measured according to their effective balance at the time of voting:
Initial deposit of 32 ETH
Rewards earned over time (+yield)
Penalties suffered (-punishment)
So, the canonical blockchain is not the one with the most votes, but the most accumulated staked ETH that has voted for it.
Two voting protocols
Before we dive into the voting protocols, let’s take a look at the fields recorded in a Validator’s attestation (vote):
beacon_block_root. The newly proposed beacon block a Validator is voting for in their slot. It is also called the head vote.
Source. A justified block that is a potential candidate to become the next finalised checkpoint.
Target. The next block that Validators are voting, in this epoch, to justify.
You may notice that an attestation is not as straight-forward as voting for a single block or blockchain fork. In fact, a single attestation cast by a Validator is voting in two different voting protocols:
There are two voting protocols:
Fork-choice. A block that represents the new tip (or head) of the canonical chain. It is implemented using the LMD GHOST rule.
Checkpoint candidate. Whether a previously accepted block will become the next candidate to be finalised as a global checkpoint. It is implemented by Casper’s Finality Gadget (FFG).
The fork-choice rule guarantees liveness of the system — all active Validators will keep trying to make a decision by proposing and voting for blocks. The checkpoint voting protocol focuses on safety — all active Validators will try and converge on a single blockchain fork. As we will see, the checkpoint voting protocol is an overlay on top of the fork-choice voting protocol.
The separation of liveness and safety has led to a two-tier system for considering whether a block is final and irreversible:
Weight-based finality. All Validators continuously apply the fork-choice rule to decide which blockchain fork should be considered the canonical chain. The likelihood of the blockchain fork being replaced decreases as votes accumulate for it.
Absolute finality. All Validators collectively agree to a checkpoint and all blocks prior to it are considered irreversible.
The fork-choice serves as a boost in confidence that a blockchain fork will likely not be replaced as votes accumulate for it over time. It works in a similar manner to most blockchain protocols that follow the longest (or heaviest) rule. The overlay of picking a checkpoint enables the proof of stake protocol to verify whether a supermajority of Validators, over the course of a few epochs, all agree to the same consistent view of the canonical chain’s tip.
Put another way, both voting protocols provide evidence that a supermajority of the Validators are all on the same page both in the short-term and long-term view of the blockchain. It provides a strong guarantee that all blocks and attestations are widely propagated in a timely manner.
Put simply, all network participants and the proof of stake protocol itself can verify that a supermajority Validators are in agreement before a block is finalised forever.
Blockchain forks
A blockchain fork involves a parent and a set of child blocks. All child blocks extend the same parent block. Only one child block will eventually be considered part of the canonical chain and the other blocks will be rejected — as such all blockchain forks are in competition with each other.
Blockchain forks are common. Blockchain forks are less common in proof of stake Ethereum, but they do emerge when a synchrony assumption is violated. For example, if a slot’s block proposer fails to deliver their proposed block on time, then the next slot’s block proposer will extend the same parent block. If both blocks extend the same parent block, then this represents a fork at the chain’s tip.
Pick one blockchain fork. In regards to voting, there is a single golden rule that all Validators must follow:
No double-voting. A Validator is only allowed to cast a single vote in an epoch and only for one of the competing blockchain forks.
The constraint to only cast a single vote helps push the Validators towards resolving the blockchain fork. At the same time, breaking this rule is one of two cases when a Validator can trigger a slashing event. This will eject them from the proof of stake protocol and forcefully forfeit a portion of their staked ETH.
Fork-choice
The fork-choice voting protocol is used by all Validators to help resolve blockchain forks that may arise and aid them to converge on a single blockchain fork. It follows the heaviest-chain rule known as LMD-GHOST, where heaviness is determined by the total staked ETH that has voted for a blockchain fork.
Fork-choice rule. All Validators decide which blockchain fork to vote for according to a set of pre-defined rule. It takes as input:
All competing blockchain forks,
All known attestations (both on-chain and off-chain),
It outputs a single blockchain fork with the most accumulated votes. If all Validators have access to the same set of data, then they should all pick the same blockchain fork in a deterministic manner.
There is a subtle detail around what is meant by all known attestations and its impact on the fork-choice rule. It needs to consider:
In-band and out-of-band votes. All votes recorded in the beacon blockchain or received via the gossip protocol will be counted.
Restriction on late votes. A late vote for a proposed block is only counted if the block was proposed in the last 32 slots.
Only votes prior to this slot. A Validator will count all votes from the checkpoint up to the parent block picked by the proposed block. It will not count votes for the block proposed in this slot.
Put another way, the Validator will count the votes for all ancestor blocks from the checkpoint up to the parent block. Votes are counted regardless if it is recorded on beacon blockchain or received out-of-band — the main restriction is that votes will expire if not included in the blockchain after 32 slots. The blockchain fork with the most accumulated votes (in terms of effective balances) is chosen.
Block proposer boost. A special boost is included in the fork-choice rule and it is only used by the slot’s committee members. An additional 40% votes (based on committee size) are added if the slot’s proposed block is received within the first 4 seconds. This special boost was added to help fend against sway attacks.
Checkpoint candidate
Casper’s Friendly Finality Gadget (FFG) is a sub-protocol that checks whether Validators have converged on the same consistent view of the blockchain and to enable them to pick a candidate block to become the next checkpoint.
Overlay voting protocol. All votes must be recorded in the beacon blockchain before it is counted by the Validators. A good mental model is to consider it an overlay protocol that runs on top of the longest canonical chain. It must respect all the synchronous communication assumptions for deciding the canonical chain via the fork-choice rule voting protocol, but it runs in a partially synchronous manner on top of it. Put another way, the canonical chain acts as a public bulletin board for the checkpoint voting protocol’s messages.
Two-phase commit. It resembles a two-phase commit protocol. The voting protocol is always attempting to pick a candidate block to justify (prepared). If the voting protocol is run successfully for two epochs in a row, then the last justified block is finalised as a checkpoint (committed). If a voting protocol fails, then the process has failed and the last justified block will not become the checkpoint.
By success, the voting protocol requires a supermajority of votes by Validators that represents 2/3+ of all staked ETH. As the voting protocol must succeed two epochs in a row, then it implies that a supermajority Validators have had a consistent view of the proof of stake protocol and can collectively agree that the justified block should become the next checkpoint.
Phase 1 — Justification per epoch. The voting protocol is run on a per-epoch basis. The candidate block to be voted on by the Validators is called the epoch boundary block and in the attestation meta-data it is called Target:
Epoch boundary block (EBB). The first block of an epoch and generally it is the block voted on by the first slot. For example, if the first slot proposes a block and its committee votes for it, then it is the EBB. On the other hand, if the first slot votes for its parent block (from the previous epoch), then the parent block is the EBB.
The process of picking the candidate block to become the next checkpoint is called Justification. All Validators are attempting to justify that the first slot’s block should indeed become the next checkpoint. It is only considered justified if a supermajority of Validators in this epoch vote for it.
Phase 2 — Finalising last justified block. Once a block is justified and it is considered a candidate to become the next checkpoint — then the second phase is to reach agreement that it should be considered final. It is called Source in the attestation data.
A justified block can only become a checkpoint if the voting protocol is run successfully for two consecutive and adjacent epochs.
If a block is justified in epoch N, but the next epoch N+1 fails to justify a new block, then the justified block from epoch N will not become the next checkpoint. Put another way, if the subsequent run of the voting protocol fails, then the current justified block can never become the next checkpoint.
The motivation for the adjacent rule is to verify whether all Validators have the same consistent view of the canonical chain. If the voting protocol failed on its second run, then it is evident that Validators are split on which blockchain fork has accumulated the most votes.
Attestation data. Just to clarify the meta-data. When a Validator casts a vote, they specify the last justified block as the source which is the most recently justified block and the target is their vote for the next candidate block. Another way to view a vote is that a Validator is signalling which candidate block they have recognised as justified in the source and they are now casting their vote for the next justified block.
Special rule for block proposers. An attestation can only be included in a beacon block if the source has picked an ancestor block in this fork and it was indeed recognised as the justified block. If Validators are split on which block should be specified in source, then the conflicting attestations cannot be included in the beacon blockchain.
Voting commandments and strategies
There are two golden rules in regards to voting for a Validator. The first is the no double-voting rule. A Validator cannot cast more than one vote for a single epoch. It is easy to verify as the evidence is simply two assigned attestations with the same epoch number.
The second voting rule, and perhaps the more interesting one, is how a Validator participates in the checkpoint candidate voting protocol. There are approximately three voting strategies that are allowed:
Happy case. The voting protocol is successful in every epoch. The newly justified block (target) replaces the previous justified block (source).
No majority. The voting protocol failed for an epoch. The previous justified block (source) remains the same and there is a new candidate block to justify (target).
Missing vote. The Validator may have been offline and missed their opportunity to vote in multiple epochs. When the Validator returns online, they can cast a new vote with the last justified block and the candidate block to justify. Their voting record will have a gap.
The above voting strategies are allowed by the voting protocol and the attestations can be included in the blockchain. There is a special restriction that the ‘source’ vote must be the same as the block proposer’s before it can be included, but it is not necessarily breaking the rules (it is simply ignored).
There is a single voting strategy that is strictly not allowed and it will result in a slashing event:
Long range attack. The Validator has cast a vote for blockchain fork A, but they later cast a second vote for another competing blockchain fork B that fully encompasses blockchain A.
It is called a long range attack as the Validator has cast a vote for a second blockchain fork with the intent to fully replace the previous blockchain fork. If it is successful, then it results in a large blockchain re-organisation that can re-order and drop transactions. There is no known scenario, except for when a Validator is acting byzantine, for an honest Validator to vote for an encompassing blockchain fork.
Weak subjectivity
A subtle detail in FFG is that it only works for Validators that are online and it must assume a supermajority of Validators are online.
It leads to an interesting question:
If a Validator returns online after being offline for a period of time and they are sent multiple competing blockchain forks of equal voting weight, then can they distinguish which blockchain fork is the globally recognised canonical chain?
The answer is no.
Weak subjectivity. Fundamentally, the issue is that a new Validator cannot independently distinguish the globally accepted membership of the Validator set from the proof of stake protocol transcript alone. They must rely on a trusted source to retrieve the Validator set and ideally it is from an agent who has remained online while they were offline. By working out who are the Validators and a globally agreed checkpoint, they can then count the votes and apply the fork-choice rule.
There are two theoretical problems that necessitates weak subjectivity:
Nothing at stake problem. A malicious validating can propose a block for every competing blockchain fork as there is no financial or operational cost to produce a block. Put another way, it is free to produce new blocks and a mechanism is required to rate-limit block production. If not resolved, then Validators have no incentive to converge on a single blockchain fork.
Long-range attacks. An attacker can bribe historical Validators to sell their old private keys and allow the attacker to reconstruct an alternative history of the blockchain. Any proof of stake system that follows the longest chain rule is vulnerable.
Thwarting theoretical problems. The purpose of block finality and necessity of weak subjectivity is to thwart long-range attack. It empowers online Validators to reject mammoth blockchain re-organisations as they have already globally agreed to a recent checkpoint. On the other hand, the nothing of stake problem is resolved by the prevent of double-voting which is discussed shortly. It makes it financially expensive for a registered Validator to propose an alternative blockchain fork as they will be discovered, slashed and ejected from the proof of stake protocol.
Cool! For supermajority, to be precise, is that 2/3 of the validators? And what is the supermajority out of ? Is that all the validators who randomly selected to be on the voting committee for each epoch? (including those on-line and those off-line?) Thanks!