Epoch change - Determine epoch leader

How can I determine the leader of the epoch at the start of the epoch? ( I don´t mean the blockproducer)

I would prefer a solution via my own Node API.

1 Like

Hey @CryptoJaeger ! :waving_hand:
There is no specific epoch leader in the Klever Blockchain consensus model. Instead, the first block of a new epoch is produced by one of the validators from the previous epoch’s validator set . So if you’re trying to figure out who will produce that first block, you should look at the validator list from the previous epoch, right before the epoch transition.

1 Like

@Pedro_Henrique @fbsobreira

Okay. There are some inconsistencies here that I would like to understand technically. If certain validators are jailed at the beginning of the epoch or in the epoch, then from time to time there is the phenomenon that all validators build up masses of ‘missed blocks’. Several words have already been provided, such as ‘epoch leader’ or ‘block production round leader’.

I would like to understand it and of course be able to determine it for Klever-Radar.

Many thanks in advance.

1 Like

Hey @CryptoJaeger, sorry for the late response — thanks for your patience!

So first of all i would like to clarify how the consensus structure works in Klever Blockchain. The time hierarchy is organized as follows:

EpochSlotSubslot

  • Epoch: A longer period where validator sets are defined
  • Slot: The basic time unit for block production
  • Subslot: Divisions within each slot for different consensus jobs

At the epoch level, we select which validators will participate in consensus. At the slot level, we determine who will be the leader from those selected validators. There is no Epoch Leader, but there is the Slot Leader - the function of that validator is to produce the block and sign it, while the other validators’ function is to sign the block for consensus.

Each slot is divided into subslots where different phases of consensus happen:

  • Subslot 1: Block proposal by the Slot Leader
  • Subslot 2: Validation and signature collection
  • Subslot 3: Block finalization and commitment

Regarding the “Mass Missed Blocks” issue :

Sometimes, a validator selected as a Slot Leader starts failing to perform its duties — either due to being offline, malfunctioning, or other issues. As a result, the consensus jails this validator. However, since the validator set only changes at the epoch level, the jailed validator remains part of the validator pool for the entire epoch.

If that validator recovers and manages to successfully produce a valid block when selected again as Slot Leader, they can return to active participation in the consensus.
But if they do not recover, they may still be selected again — and continue failing to produce blocks, while accumulating missing signatures throughout the epoch.

What we suspect is happening is this:
KleverRadar might be counting every instance of a missing signature as a “missed block”, even in cases where the jailed validator was not the Slot Leader, but simply failed to sign the block.

This could lead to an inflated count of missed blocks, since only Slot Leaders can actually “miss” a block.

To confirm that and help us better understand what’s being reported, could you please clarify how KleverRadar is retrieving the “missed blocks” information?

3 Likes

@Pedro_Henrique

Hi and thank you very much for your detailed information.

Klever-Radar removes the jailed validator from the consensus list (as does the validator peerslist: https://node.mainnet.klever.org/validator/peers ). Radar determines the ‘Missed Blocks’ based on missing signatures for a block.

Just to understand:

  • A validator that has been jailed can no longer start working in the same epoch, right? It changes to the status → Eligible at the epoch change

This phenomenon only occurs with some actively selected validators that have been jailed, i.e. all validators have missing signatures.

Now the question would be, does the jails validator remain in the consensus list or does it have to be removed? (so far it has been removed from the list)