Proof-of-Stake – How Can There Be a Fork if Only One Validator Proposes a Block per Slot?

beacon-chaineth-2.0ghost-protocolproof-of-stakevalidators

As I understand it, one and only one validator get selected to propose the next block on the beacon chain. This means that the other validator attesting can only attest to one block right? (since there are no other validators selected to propose a block)

So I am thinking, perhaps the attesting process is just to reach a threshold of "validity" before a proposed block gets added?

But reading Validated, staking on eth2: #2 – Two ghosts in a trench coat

But I recollect from glancing through the article here https://blog.ethereum.org/2015/08/01/introducing-casper-friendly-ghost/

it has a portion in its description of the consensus where it states:

Eth2 uses Greedy Heaviest Observed Subtree (GHOST) as its fork-choice rule. GHOST selects the head of the chain by choosing the fork which has the most votes (it does this by considering all of the votes for each fork block and their respective child blocks).

I am failing to see how there can be a fork, if only one validator is selected during a slot to propose a block. Anyone care to explain how this works and what I am missing?

Thanks!

Best Answer

I am failing to see how there can be a fork, if only one validator is selected during a slot to propose a block.

Ignoring slashable offenses (i.e., producing two conflicting blocks at the same slot), each slot can have either zero or one block.

On the Ethereum Beacon Chain (a.k.a "eth2"), we call any slot without a block a "skip slot". Skip slots will happen if the elected block proposer fails to disseminate a valid block for whatever reason (offline, eclipsed, etc).

When a block producer produces a block for some slot s, they get to choose the value for the block.parent_root. Generally, the proposer will choose the block at s - 1. However, if s - 1 is a skip slot, the proposer will select the latest non-skipped slot.

So, let us imagine the following scenario:

  • There is a block at slot 1
  • The block at slot 2 was published to only a small subset of the network.
  • The block producer for slot 3 did not see the block at slot 2, therefore it uses the block at slot 1 for the block.parent_root.

A node on the network which observed all of the blocks will have the following block tree:

  1
 / \
2   |
    3

The blocks at slots 2 and 3 both reference the block at slot 1 as their parent and are therefore conflicting. There is a fork.

Related Topic