Project overview


Solve quests


Build your own narrative


🧗 Find out number of block proposals by a validator

Let's look at how the beacon chain achieves consensus.

Consensus is all about agreeing on the order of blocks(transactions).

In PoS, time is divided into 12 seconds(aka slot) and 6.4 minutes(aka epoch).

A random validator is chosen by a process called RANDAO to propose the block at every slot.

Once the validator proposes the block, other validators can verify and add the proposed block to their view of blockchain.

What happens when some nodes disagree?

Let's say due to network delay, the proposer at slot#4(see below) did not receive the previous block. They assume that no one proposed the previous block (which can happen if the chosen validator is offline) and built theirs on top of the last observed block. This results in a fork.

Fork Choice

Fork choice

When the next proposer has to build their block, Should they choose block at slot#3 or slot#4 as their parent?

This can be solved by asking all other nodes about their view of the blockchain. If majority of them said they have seen block at slot#3, then the current proposer could consider that as a valid(aka canonical) chain and can build on top of block at slot #3.

Instead of the proposer asking every node about their view, this is achieved by asking the nodes to vote for the head block at every slot. By aggregating the votes for every fork path, the validators can agree on the chain that has the majority votes.

Fork Choice

Fork choice - Attestation

Since there are so many validators, it would overwhelm the network if everyone has to vote on every slot. To better handle this, validators are grouped into 32 committees and will be randomly assigned to vote for one slot every epoch.

Further, the votes are aggregated at subnets and then forwarded to the block proposer.

The block proposer is responsible for including the attestations(votes) as part of their block.

In addition to the head block votes(aka LMD GHOST vote), the validators also vote on checkpoints(aka CASPER FFG vote):

  • source checkpoint: first block of last epoch
  • target checkpoint: first block of current epoch

Validator Attestation

Once 2/3 validators vote on a checkpoint twice i.e once as source and once as target, it is finalized. The blocks are confirmed and cannot be reversed. This is called finality.



Note: The blocks could still be reversed after finality. Let's say a new path has been voted by 2/3rd of validators. This can happen only when 1/3 of validators voted for both paths. As part of slashing, they will lose their entire stake. With currently ~14M ETH staked, the slashed validators would lose approximately ~4.7M ETH(=6B USD as of Oct'22). We could say the finality is guaranteed with $6B USD in stake

In essence, the validator has to

  • propose blocks during their turn
  • attest(vote) on head block once per epoch
  • attest(vote) on source and target checkpoints once per epoch

The validators will be rewarded for timely block proposal and attestations. They will be penalized for missing their duties.

How do we get the validator data?

The validator state is stored in the beacon chain. Since beacon chain is not accessible in Dune yet, let us investigate from block explorers.

🕵️ Number of block proposals by validator 10467

Click here to solve the quest.

💡 Choose your option below 💡