This EIP defines a slashing condition for malicious sync committee messages.
A dishonest supermajority of sync committee members is able to convince applications relying on Ethereum's light client sync protocol to assume a non-canonical finalized header, and to potentially take over the sync authority for future SyncCommitteePeriod. By signing a malicious beacon block root, a malicious (but valid!) LightClientUpdate message can be formed and subsequently used to, for example, exploit a trust-minimized bridge contract based on the light client sync protocol.
An additional type of slashing is introduced to deter against signing non-canonical beacon block roots as a sync committee member. As is the case with ProposerSlashing and AttesterSlashing, only malicious behaviour is slashable. This includes simultaneous contradictory participation across multiple chain branches, but a validator that is simply tricked into syncing to an incorrect checkpoint should not be slashable even though it is participating on a non-canonical chain. Note that a slashing must be verifiable even without access to history, e.g., by a checkpoint synced beacon node.
Note that regardless of the slashing mechanism, a slashing can only be applied retroactively after an attack has already occurred. Use cases that secure a larger amount than SYNC_COMMITTEE_SIZE * MAX_EFFECTIVE_BALANCE = 512 * 32 ETH = 16384 ETH (on mainnet) should combine the light client sync protocol with other established methods such as a multisig, or may want to require posting additional collateral to be eligible for submitting updates. Other methods are out of scope for this EIP.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Note: This still allows having contradictions between attestations/proposals and sync committee messages. This also, by design, allows a validator to not participate at all in honest sync committee messages but solely participate in dishonest sync committee messages.
| Name | Value |
|---|---|
BLOCK_STATE_ROOT_INDEX | get_generalized_index(BeaconBlock, 'state_root') (= 11) |
STATE_BLOCK_ROOTS_INDEX | get_generalized_index(BeaconState, 'block_roots') (= 37) |
STATE_HISTORICAL_ROOTS_INDEX | get_generalized_index(BeaconState, 'historical_roots') (= 39) |
HISTORICAL_BATCH_BLOCK_ROOTS_INDEX | get_generalized_index(HistoricalBatch, 'block_roots') (= 2) |
MAX_SYNC_COMMITTEE_SLASHINGS | 2**0 (= 1) |
Without a slashing, the light client sync protocol is somewhat limited. While wallet applications may benefit from it (the risk being, that incorrect data is displayed) and new beacon nodes may use it for accelerating chain synchronization, other interesting use cases such as bridges, token distributions or other systems requiring proofs depend on the mechanism providing higher security guarantees.
By making attacks by sync committee members slashable, a sufficiently high deterrent could be provided. A majority of the sync committee would have to be bribed to succeed in an attack even in the most simple cases, representing a sizable slashable balance.
This EIP requires a hard fork as it introduces new consensus validation rules.
Supporting infrastructure may be introduced separately once the consensus validation rules are in place, including but not limited to:
TBD
TBD
TBD
Copyright and related rights waived via CC0.