1

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!

2 Answers 2

1

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.

0

In a permission-less system, you must always assume that some participants will misbehave either because of incomplete informations (network delay, etc..) or pure adversarial strategy for example.

In GASPER (LMD GHOST + CASPER FFG) when a validator is selected as block proposer, it may propose more than one block for the current slot. Thus creating a fork.

Now, from the specs you can see that this is a slashable offense, but it is possible nonetheless and therefore must be handled.

That's why the LMD-GHOST algorithm is required : to achieve a consensual view of which block is considered the head of the chain in case of forks.

There are more elaborated attacks such as the ones shown in this paper if you are curious about other adversarial ways of forking / triggering reorgs in the Ethereum consensus layer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.