An Alternative to the Beacon Chain: A Cumulative Committee-Based Finality Model

Source | ethresear.ch

Author | Vitalik Buterin

This is an alternative design proposed for the beacon chain, which can be switched to this model in the far future (replacing the currently planned CBC), and it attempts to provide the following key features:

➤ Under normal circumstances, provide meaningful single-slot economic certainty (i.e. Tendermint-like properties)

• Even if the majority of validators participate in collusion 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 fork choice, avoid those known defects, and need to introduceComplex hybrid fork selection rules, to fix these defects.

➤ Potential to enable lower minimum deposit size and higher number of validators

Preliminary knowledge

Preliminary knowledge

Let CONSENSUS be an async-safe consensus algorithm (eg, Tendermint, Casper FFG, etc.). We assume that the consensus algorithm is designed to involve slots and views (view views), i.e. it tries to reach consensus every fixed period of time. We also assume that it takes as input a weighted set of validators (a property that is easy to add to existing BFT consensus algorithms).

In the design below, we modify CONSENSUS so that the set of validators required to finalize is different for each lookup. That is, CONSENSUS is used instead of the validator set as the input of the function get_validator_set(view_number: int) -> Map[Validator, int] (where int represents the validator balance), which can generate a new view view of the validator set . get_validator_set should have the property that the validator set varies by at most 1/r from one view to the next, where r (r=65536 ) is the recovery period length. More formally, we hope that:

Among them, |x| returns the sum of the absolute values ​​of x values, and diff returns the value after subtraction of 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 validator sets will include the deducted balance of existing validators, and the ratio of newly added validators is equal to the ratio of deducted balances.

Note that the max validator set delta function of 1/r is only available if previous validators have not yet finalized. If the previous validator set has been finalized, the instance of CONSENSUS will change, so the internal randomness of the get_validator_set function will also change completely; in this case, two adjacent validator sets will become completely different.

mechanism

mechanism

We use two levels of fork selection:

➤ Select LATEST_FINALIZED_BLOCK (latest finalized block)

➤ Starting with LATEST_FINALIZED_BLOCK, use other fork choices (e.g. LMD GHOST) to choose block headers

The CONSENSUS algorithm can be viewed once per slot, taking as input a validator set generation function based on data generated by get_post_state(LATEST_FINALIZED_BLOCK). A valid proposal must contain a valid descendant block of LATEST_FINALIZED_BLOCK. Validators prepare and vote on block proposals only if that part wins the fork choice and becomes part of the blockchain.

image description

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

We have the following penalties:

➤ Regular slashing penalties determined by the consensus algorithm

first level title

FFG Alternative: Single-slot-epoch Casper FFG

An alternative to the above design is to use Casper FFG, but make the epochs equal to the slot length. Casper FFG works differently because it does not try to prevent the same committee from finalizing a block and its descendants. To accommodate this difference, we need to enforce (i) a safety threshold of 1/4 instead of 1/3, (ii) a rule that if a slot does finalize, the validator set replaces at most 1/4 instead of completely .

Note that in such a design, it is theoretically cost-free to implement a reorganization of one slot (but no more than one slot). Also, at the end of the graph "up to the slot for maximum finality"characteristic

characteristic

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

➤ Something went wrong with a committee and ≥1/3 of the validators were slashed for double finalizing another block

➤ The most recent committee is offline, and after r/3 slots, the committee has shuffled enough to finalize another block without being slashed. However, this comes with a heavy sabotage penalty (≥1/3 of the attacker's balance)

In either case, even rolling back a finalized block requires at least DEPOSIT_SIZE * COMMITTEE_SIZE / 3 (deposit amount * committee size / 3) ETH burned. If we set COMMITTEE_SIZE = 131,072 (the number of validators per 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 solution include:

➤ No matter how many validators have deposited, the validator load is stable when processing COMMITTEE_SIZE (committee size) transactions per slot

➤ Validator load will be lower as they can sleep when they are not required to join the committee

first level title

Scaling: Chain Confirmation with Small Committees

If we had to reduce the COMMITTEE_SIZE for efficiency, we could 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 choose the confirmed block with the longest chain head of the confirmed block (but refuse to roll back the blocks confirmed by COMMITTEE_LOOKAHEAD, so the confirmation of COMMITTEE_LOOKAHEAD represents the real finality)

➤ get_validator_set should only use status information, not COMMITTEE_LOOKAHEAD before confirmation

➤ The number of the view should be the number of the slot (this makes it easier to deduce that the same validator set is trying to reach 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 finalized, and a chain's descendant blocks get k-1 Confirmation, because a total of k consecutive confirmations will affect the block), then rolling back the block needs to violate the consensus guarantee in multiple committees. This allows security levels from multiple committees to pile up: rolling back k confirmations requires COMMITTEE_SIZE * DEPOSIT_SIZE * k / 3 ETH, and it takes k = COMMITTEE_LOOKAHEAD for committees to diverge.

first level title

Examples of specific values

Note that "ETH required to break finality"The number assumes that the attacker controls the number of validators equivalent to controlling more than half of the total staked ETH (i.e. millions of ETH); this number is the ETH that the attacker will lose. But this does not mean that anyone with 2,730, 174,762 ETH can roll back a single slot by randomly burning these ETH.

Original link: https://ethresear.ch/t/a-model-for-cumulative-committee-based-finality/10259