QBFT Consensus

​

Why Consensus Matters

1. What data to sign - The specific attestation, block, or sync committee message
2. When to sign it - Ensuring duties execute in the correct slot
3. That enough operators agree - Meeting the threshold for valid signatures

​

QBFT Fundamentals

​

Byzantine Fault Tolerance

• Safety: Never produces conflicting decisions (prevents slashing)
• Liveness: Eventually makes progress (duties execute)
• Byzantine Resilience: Tolerates up to f faulty operators out of n total

​

Consensus Terminology

​

Consensus Phases

​

Phase 1: PROPOSAL

• Deterministic: leader = (λ + r) mod n
• All operators know who should lead each round
• Invalid proposals from non-leaders are rejected

<PROPOSAL, λ, r, inputValue>

• λ (lambda): Instance height
• r: Current round
• inputValue: Beacon chain duty data (attestation, block, etc.)

1. Verify the sender is the correct leader for this round
2. Validate the duty data against beacon chain state
3. Check for slashing conditions (no conflicting signatures)
4. Verify the proposal is for the expected slot and role

​

Phase 2: PREPARE

<PREPARE, λ, r, value>

• Operators broadcast their acceptance of the proposal
• Acts as a “pre-vote” before final commitment
• Prevents premature commitment to unvalidated data

​

Phase 3: COMMIT

<COMMIT, λ, r, value>

1. The operator stops the round timer
2. Marks the instance as decided
3. Proceeds to post-consensus (partial signature exchange)
4. The decided value becomes immutable for this instance

• Operators don’t re-run consensus for the same duty
• Historical decisions can be retrieved for sync protocols
• Slashing protection databases are updated

​

Phase 4: ROUND-CHANGE

• Leader failure or network partition
• Slow or faulty leader
• Insufficient quorum in current round

<ROUND-CHANGE, λ, r+1, pr, pv>

• pr: Highest round where this operator received Qprepare (null if never)
• pv: The value from round pr (null if pr is null)

1. Timeout: Round timer expires without reaching Qcommit
2. F+1 Round Changes: Receiving f+1 ROUND-CHANGE messages for higher rounds
3. Leader Failure: Detected through lack of valid PROPOSAL

1. Operators broadcast ROUND-CHANGE messages
2. Wait for Qrc (quorum of 2f+1 ROUND-CHANGE messages)
3. New leader justifies the PROPOSAL:
   • If any operator has pr ≠ null, propose the pv from the highest pr
   • Otherwise, propose fresh duty data from the beacon node
4. New leader broadcasts justified PROPOSAL
5. Consensus proceeds normally in the new round

• Proves that the new proposal is based on valid prior agreement
• Operators verify the justification before accepting the proposal
• Ensures safety across round transitions

​

Consensus Flow Diagrams

​

Normal Case (Single Round)

1. Leader proposes valid data
2. All honest operators prepare
3. All honest operators commit
4. Consensus decided in round 1

​

Round Change Scenario

1. Round timeout triggers ROUND-CHANGE
2. Operators achieve Qrc
3. New leader elected
4. Justified proposal in round 2
5. Consensus decided

​

Implementation Details

​

QBFT Controller

type Controller struct {
    Identifier      []byte                    // Validator or committee ID
    Height          specqbft.Height           // Current consensus height
    StoredInstances InstanceContainer         // Recent instance history
    CommitteeMember *spectypes.CommitteeMember // Operator info
    OperatorSigner  ssvtypes.OperatorSigner   // For signing messages
}

• Starting new consensus instances for each duty
• Managing instance lifecycle (active, decided, historical)
• Processing incoming consensus messages
• Triggering timeouts and round changes

​

Instance Management

type Instance struct {
    State *State                 // Current round, accepted proposals
    config qbft.IConfig          // Quorum thresholds, timeouts
    committeeMember *CommitteeMember
}

• Height: Beacon slot / consensus instance number
• Round: Current round within the instance
• ProposalAcceptedForCurrentRound: Accepted proposal (if any)
• LastPreparedRound & LastPreparedValue: Highest round with Qprepare

​

Message Processing

1. P2P Layer (network/p2p/p2p_pubsub.go): Receives messages on GossipSub topics
2. Message Router: Routes to appropriate validator/committee
3. Runner (protocol/v2/ssv/runner/runner.go): Decodes and validates structure
4. QBFT Controller: Delivers to the correct instance
5. Instance: Processes according to current state and message type

​

Timing and Timeouts

• Base Timeout: Configurable per network (e.g., 2 seconds for mainnet)
• Exponential Backoff: timeout(r) = base_timeout * 2^(r-1)
• Round 1: 2s
• Round 2: 4s
• Round 3: 8s
• Round 4: 16s

​

Security Properties

​

Slashing Prevention

• Byzantine operators cannot cause conflicting commitments
• Double-signing is impossible when 2f+1 operators are honest
• Slashing protection databases provide additional safety

• Each operator independently validates against slashing conditions
• Pre-consensus checks prevent conflicting partial signatures
• Consensus ensures all operators sign the same data

​

Network Resilience

​

Liveness Guarantees

1. At most f operators are Byzantine
2. Network eventually delivers messages (asynchronous model)
3. There exists a synchronous period long enough for message exchange

• Liveness holds even with changing network conditions
• Round changes ensure eventual leader rotation
• No deadlock scenarios with honest majority

​

Performance Characteristics

​

Message Complexity

• PROPOSAL: O(n) messages (1 leader to n operators)
• PREPARE: O(n²) messages (n operators broadcast to n)
• COMMIT: O(n²) messages (n operators broadcast to n)

​

Latency

• Best case: 1-2 seconds (single round, low network latency)
• Average case: 2-4 seconds (including network jitter)
• Worst case: Scales with round changes (exponential backoff)

​

Optimizations

• PREPARE and COMMIT messages can be aggregated (multiple signers)
• Reduces message count in implementations (not yet in SSV)

• New instances can start before previous ones finish
• Duty queue processes multiple duties concurrently

​

Research Foundations

• EIP-650: Istanbul Byzantine Fault Tolerance - Original Ethereum proposal
• PBFT Paper - Castro & Liskov’s Practical Byzantine Fault Tolerance
• HotStuff - Linear consensus protocol

​

Next Steps