Explain the alternative scheme of the beacon chain in detail: the final certainty model based on the cumulative committee

This is an alternative design proposal proposed for the beacon chain. The beacon chain can switch to this model in the far future (instead of the CBC currently planned). It attempts to provide the following key features:

Under normal circumstances, provide meaningful economic certainty of a single slot (ie similar to the characteristics of Tendermint)

  • Even if most validators participate in the conspiracy to reorganize a single slot, the cost of execution is much higher than it is now, thereby reducing the consensus-extractable value (CEV)

Get rid of the high dependence on LMD GHOST bifurcation selection, avoid those known defects, and need to introduce complex hybrid bifurcation selection rules to repair these defects.

May make lower minimum deposit size (deposit size) and higher number of validators possible

Keep the economic finality (economic finality) finally close to a very large value (millions of ETH ) this feature


Let CONSENSUS be an asynchronous and secure consensus algorithm (for example, Tendermint, Casper FFG, etc.). We assume that the design of the consensus algorithm involves slots and views, that is, when it tries to reach a consensus at each fixed time period. We also assume that it takes a weighted set of validators (existing Byzantine fault-tolerant consensus algorithms can easily add this feature) as input.

In the following design, we modify CONSENSUS so that the set of verifiers required to be finalized is different in each review. In other words, CONSENSUS is used as the input to the function get_validator_set(view_number: int) -> Map[Validator, int] (where int represents the balance of the validator) instead of the validator set. This function can generate a new view of the validator set . get_validator_set should have the characteristic that the validator set changes at most 1/r from one view to the next, where r (r=65536) is the length of the restoration period. More formally, we hope this is the case:

Explain the alternative scheme of the beacon chain in detail: the final certainty model based on the cumulative committee

Among them, |x| returns the sum of the absolute values ​​of x, and diff returns the value after subtracting each key value (for example, diff({a: 0.1, b:0.2}, {b:0.1, c:0.3}) = {a: 0.1, b: 0.1, c: -0.3}).

In practice, the difference between two adjacent verifier sets will include the deducted balance of the existing verifier, and the ratio of the newly added verifier is equal to the deducted balance.

Please note that the 1/r maximum validator set difference function is only available when the previous validator has not finalized it. If the previous validator set has been finalized, the CONSENSUS instance will change, so the internal randomness of the get_validator_set function will also be completely changed; in this case, the two adjacent validator sets will become completely different.

Please note that this means that if the difference between the values ​​on the two finalized views is large enough, the CONSENSUS function may now be finalized together without penalty; this is deliberately designed this way, and the protocol’s processing method is Casper FFG handles sabotage penalties the same as today.


We use two-level bifurcation options:

S select LATEST_FINALIZED_BLOCK (the latest finalized block)

Starting from LATEST_FINALIZED_BLOCK, use other fork options (such as LMD GHOST) to select the block header

The CONSENSUS algorithm can be viewed once in each slot, and the validator set generation function based on the data generated by get_post_state(LATEST_FINALIZED_BLOCK) is used as an input. A valid proposal must contain a valid descendant block of LATEST_FINALIZED_BLOCK. Only when the part wins the fork selection and becomes part of the blockchain, the validator will prepare and vote for the block proposal.

If CONSENSUS wins in a certain view, the block proposed in that view will become the new LATEST_FINALIZED_BLOCK, changing the set of validators in the next few rounds. If it fails, it needs to make the next attempt in the next slot or view.

Explain the alternative scheme of the beacon chain in detail: the final certainty model based on the cumulative committee

Note: The slot should always be equal to the current view number plus the sum of the view numbers of each previously successfully finalized verifier set.

We have the following penalties:

Conventional penalties determined by the consensus algorithm

Sabotage penalty: If the blockchain cannot be finalized, every validator who did not participate in the finalization will be punished. The penalty is to halve the balance after r/2 slots.

FFG alternative: single-slot-epoch Casper FFG

An alternative to the above design is to use Casper FFG, but make the length of the epoch equal to the slot. The working mechanism of Casper FFG is different because it does not try to prevent the same committee from finalizing a block and its descendants. In order to adapt to this difference, we need to implement (i) a safety threshold of 1/4 instead of 1/3, and (ii) a rule: if a slot is finalized, the verifier set replaces at most 1/4 instead of completely. .

Please note that in such a design, the reorganization of one slot (but not more than one slot) is theoretically costless. In addition, the number of “slots up to the maximum final certainty” at the end of the chart needs to be increased by 4 times.


If a block is finalized, if its competing block is to be finalized, one of the following needs to happen:

A certain committee (committee) has a problem, and ≥1/3 of the validators are fined for double-finalizing another block

The latest committee is offline. After r/3 slots, the committee can finally finalize another block without being fined after being fully shuffled. However, this brings severe sabotage penalties (≥1/3 of the attacker’s balance)

In either case, even if you want to roll back a finalized block, at least DEPOSIT_SIZE * COMMITTEE_SIZE / 3 (deposit amount * number of committee members / 3) ETH must be burned. If we set COMMITTEE_SIZE = 131,072 (the number of validators in each slot of the Eth2 committee, the theoretical maximum is 4 million), then this value is 1,398,101 ETH.

Some other important features in the plan include:

No matter how many validators have deposited, the load of validators is stable when processing COMMITTEE_SIZE (committee size) transactions for each slot

The load of validators will become lower because they can sleep when they are not required to join the committee

The dormant verifier can quickly exit and withdraw money without sacrificing security.

Extension: Use small committees for chain confirmation

If we have to reduce COMMITTEE_SIZE in order to improve efficiency, we can make the following adjustments:

We renamed “finalization” to “confirmation” to reflect that a single confirmation no longer represents true finality

Different from selecting the latest confirmed block, we select the confirmed block with the longest chain head of the confirmed block (but refuse to roll back the block other than confirmed by COMMITTEE_LOOKAHEAD, so the confirmation of COMMITTEE_LOOKAHEAD represents the real final Certainty)

get_validator_set should only use status information, not COMMITTEE_LOOKAHEAD to confirm the previous information

The number of the view should be the number of the slot (this makes it easier to deduce the situation where the same set of validators try to reach a consensus on different chains, which can only happen when some confirmations are broken)

This scheme retains all the above features, but it also introduces a new feature: if a block gets multiple confirmations (for example, the block is finally finalized, and the descendants of a chain get k-1 Confirmation, because a total of k consecutive confirmations will affect the block), then rolling back the block requires violating consensus guarantees in multiple committees. This will allow the security levels from multiple committees to pile up: rolling back k confirmations requires COMMITTEE_SIZE * DEPOSIT_SIZE * k / 3 ETH, and k = COMMITTEE_LOOKAHEAD will the committees disagree.

It should also be noted that, in any case, for the safety of p2p subnets, the lookahead mechanism is worth using, so it is a good idea to design with it, and if necessary, it can be left to the client to decide them. How to deal with the confirmation rollback problem.

Examples of specific values

Explain the alternative scheme of the beacon chain in detail: the final certainty model based on the cumulative committee

Please note that the number of “ETH needed to break finality” assumes that the number of validators controlled by the attacker is equivalent to controlling more than half of the total pledged ETH (ie millions of ETH); this number is that the attacker will lose ETH. But this does not mean that anyone with 2,730, 174,762 ETH can roll back the confirmation of a single slot by burning these ETH casually.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/explain-the-alternative-scheme-of-the-beacon-chain-in-detail-the-final-certainty-model-based-on-the-cumulative-committee/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Leave a Reply