Skip to main content

Fault Attribution & Slashing

As mentioned in the architecture section, Bolt operates in an optimistic failure mode. This means that the system assumes that all participants are operating honestly and only falls back to a challenge mechanism when a fault is detected and a dispute is opened. This section describes the different types of fault attribution and the slashing mechanism that is used to penalize actors that breach their commitments.

Types of faults​

We define two types of faults in the Bolt protocol: liveness and safety. These faults are detected through the dispute resolution process and are attributed to the proposer that breached their commitment.

Liveness faults​

A liveness fault occurs when a proposer fails to propose a block within their assigned slot. This can happen due to network issues, hardware failures, or malicious intent. In any case, the proposer is responsible for their commitments and will be penalized if they breach them. The penalty for a liveness fault is a temporary suspension from providing further commitments in Bolt. The proposer will be able to rejoin the network after a certain period of time.

Initially, there will not be further penalties for liveness faults 1, because we recognize that failing to propose a block does not signify certain malicious intent - which is also why the Ethereum protocol doesn't penalize validators for this.

How can we attribute a liveness fault (missed slot) on-chain?​

We can leverage EIP-4788 (Beacon Roots in the EVM) to verify that the proposer's slot has the same beacon_root as the one before it. This means that the beacon chain didn't progress in that slot, which signifies a missed slot by the target proposer.

Safety faults​

A safety fault occurs when a proposer proposes a block that doesn't fulfill the commitments they made. These faults are typically due to software bugs or malicious intent. The protocol aims to minimize the impact of software bugs, potentially using a reimbursement and insurance fund to protect affected proposers.

Malicious faults are more severe. In Bolt, proposers found guilty of a safety fault will have their stake slashed to cover the cost of the missed commitment.

Safety faults are attributed by verifying the proposer’s commitment against the provided proofs in the challenge resolution process outlined below.

Fault Proof Challenge and Slashing: BoltChallenger​

The BoltChallenger contract is the key component responsible for handling fault attribution when a validator fails to meet their commitments. It verifies proofs submitted by arbitrators and determines the outcome of disputes based on the validity of these proofs.

Opening a Dispute​

When a breach is detected by anyone in the network, they can open a dispute by calling the permissionless openChallenge function on the BoltChallenger contract. The required inputs are:

  • Signed Commitment: The commitment made by the validator.
  • ETH Bond: An ETH bond to cover the cost of the dispute and disincentivize frivolous challenges.

The checks performed in the openChallenge function include:

  1. Sufficient Bond: There must be a sufficient bond attached to prevent spam.
  2. Challenge Window: The challenge must be opened within the allowed time frame after the target block was proposed.
  3. Validator Opt-In: The proposer must be opted-in to Bolt.
  4. Valid Commitment: The challenged commitment must have been signed by the targeted proposer.

If all conditions are met, the challenge is opened, and a ChallengeOpened event is emitted. Any arbitrator has a time window to submit a valid response to settle the dispute.

Resolving a Dispute​

The dispute resolution process is one-shot and requires the arbitrator to submit all necessary evidence of the validator’s correct behavior within the challenge time window.

Arbitrators​

An arbitrator is anyone who can submit a valid response to the challenge; it doesn’t have to be the validator themselves. However, the response must be submitted within a specific time window:

  • Start: The target block must be justified by LMD-GHOST, meaning a minimum of 32 slots must have passed to ensure finality.
  • End: Depends on the EVM block hash oracle used:
    • BLOCKHASH Opcode: Window limited to 256 blocks (approximately 1 hour).
    • EIP-2935 Historical Oracle: Window limited to 8192 blocks (approximately 1 day).

Required Inputs for Resolution​

To resolve a dispute, the arbitrator must provide:

  • Challenge ID: The unique identifier of the challenge (emitted in the ChallengeOpened event).
  • Inclusion Proofs: Consisting of:
    • Block Number: Of the block containing the included transaction.
    • RLP-Encoded Block Header: Of the block containing the included transaction.
    • Account Merkle Proof: Of the sender of the included transaction.
    • Transaction Merkle Proof: Of the included transaction against the header’s transaction root.
    • Transaction Index: In the block of the included transaction.

If the arbitrator submits a valid response that satisfies the challenge requirements, the challenge is considered DEFENDED, and the challenger’s bond is slashed to cover the cost of the dispute, incentivizing speedy resolution.

If no arbitrator responds successfully within the challenge time window, the challenge is considered LOST, and the BoltChallenger contract records this information for future reference.

Slashing of Validators​

If a challenge is LOST, the validator’s stake is slashed to cover the cost of the missed commitment. This is executed by calling the slash function on the appropriate staking adapter, which references the BoltChallenger contract to verify that the challenge was indeed lost.

In practice, slashing behavior is abstracted behind any staking adapter. For example, Symbiotic’s VetoSlasher receives a request to slash a validator’s stake and has a final opportunity to veto the slashing request before it is executed on-chain.

Subscribing to lost challenges from the BoltChallenger contract provides a trustless method to determine if a slashing request is valid according to Bolt Protocol rules.

Limitations​

  • Bond Requirement: Opening a challenge requires an ETH bond to prevent spam and denial-of-service attacks.
  • Time Constraints: The challenge time window for opening and resolving disputes is limited by the availability of the block hash oracle.
  • Arbitrator Participation: Any arbitrator can respond to a challenge, not just the challenged proposer. However, they must submit a valid response within the specified time window.

Footnotes​

  1. Slashing for liveness faults is an open question that needs further discussion. The current proposal is not to impose economic penalties because missing a slot can occur by chance and may not indicate malicious intent. However, data suggests that proposing early in the slot is crucial to avoid missing a slot. ↩