2

i'm doing some research about Ethereum 2.0 for university. I think i understand the way it works, but i have a perplexity about the proposer selection in a slot, especially after reading the codes here: https://github.com/ethereum/eth2.0-specs

From what i understand, at the beginning of a slot a validator check whether he's a proposer or not by using the compute_proposer_index, which takes as parameter the beacon state, a sequence of validator and the seed. In general all informations come from the beacon state: slot, epoch, randao_mixes, list of active validators...

My question is: assuming that the state change only with a block (like eth 1), if a proposer doesn't send a block during its slot, maintaining the same state, how is the next proposer selected? Shouldn't the random variables remain the same, causing the election of the same proposer over and over until he sends out a block?

Example: i'm at slot 500 and so the state is set at Slot: 500; from the informations i got in the state the next proposer should be X, but at slot 501 X goes offline and the state is unchanged: if at slot 502 i run again the code i should get X again, since nothing changed, and the blockchain gets stuck until X comes back online.

Ofc is not like this, i'm missing something, i just can't see what. Can you help me? Many thanks in advance.

2

if a proposer doesn't send a block during its slot, maintaining the same state, how is the next proposer selected?

The same state isn't maintained, each slot has a different state. The get_beacon_proposer_index function uses state.slot to seed the proposer shuffling.

If a proposer fails to publish a block at slot n, then the proposer for the next slot will build their block upon a state with slot n + 1.

Example: i'm at slot 500 and so the state is set at Slot: 500; from the informations i got in the state the next proposer should be X, but at slot 501 X goes offline and the state is unchanged: if at slot 502 i run again the code i should get X again, since nothing changed, and the blockchain gets stuck until X comes back online.

In your example, your head block has block.slot == 500. This means the state represented by block.state_root will also have state.slot == 500.

Before the proposer for slot == 502 produces a block they will call process_slots(state, 502), increasing state.slot from 500 to 502.

If the proposer for slot == 501 had produced a block, they would have called process_slots(state, 501), which would result in a different result when calling get_beacon_proposer_index(state).

0

The specification says:

The parent selected must satisfy that parent.slot < block.slot.

There is no requirement that parent.slot must be block.slot - 1. So the validator will simply choose newest block which was produced in an earlier slot.

Then it's explicitly stated:

Note: There might be "skipped" slots between the parent and block

1
  • Your explaining that slots can be "skipped", but not how the next proposer is selected. – eth May 23 '20 at 5:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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