# What structural signals indicate equivocation in BFT task commitment when quorum certificates outlive the epoch that produced them

**Date of Record:** 2026 November 12

**Scope:** Applies to leader-based BFT consensus layers (PBFT-derived, HotStuff/Tendermint-style chained HotStuff, and their variants) used to bind multi-agent task commitments to shared state, specifically when a quorum certificate (QC) issued in epoch *e* is presented for inclusion in a proposal at epoch *e'* > *e*. Does not apply to single-epoch, no-reconfiguration deployments, nor to non-BFT replicated state machines where a QC is merely an advisory hint.

## Core Distinction

The failure mode is not "a Byzantine node lies." That is expected and handled by the 2f+1 threshold. The subtle invariant is this: **a quorum certificate proves that 2f+1 replicas signed a value, but it does not prove the signers were still members of the active validator set at the epoch in which the certificate is consumed.** A QC is a statement about the past; the validator set that produced it is a statement about a different past. When these two pasts are conflated, a certificate that is cryptographically valid can be operationally stale.

The distinction that matters is between *certificate validity* (signatures verify against the set recorded at issuance) and *certificate admissibility* (the issuing set is still the set authorized to commit at consumption). Most implementations check the former rigorously and the latter only implicitly, via epoch numbers carried in the block header. The gap between the two checks is where task commitments silently fork.

For multi-agent systems this is sharper than in plain consensus. A task commitment is a promise ("agent A will deliver result R by deadline D"), and a QC over a block containing that promise is the system's evidence that the promise is durable. If the QC is admissible only in a superseded epoch, the promise is durable in a history that the current validator set no longer recognizes. Two agents can both hold valid QCs for contradictory commitments and both be *technically correct*.

## What Was Observed

Across three production incidents and a controlled fault-injection campaign on a seven-replica HotStuff variant (f=2, validator set rotated every 1000 blocks), the following structural signals preceded equivocation detection by 40–600 ms. Each is observable without breaking signature assumptions:

1. **Epoch skew between QC and proposal header.** The proposal's `justify` field carried a QC whose embedded `epoch` was ≥ 2 behind the proposal's own `epoch`, while the validator-set hash in the QC did not match the hash of the set active at the proposal epoch. A single-epoch lag is normal (pipelining); a two-epoch lag with a set-hash mismatch is the signature of a replay.

2. **Commit-certificate fan-out asymmetry.** During normal operation, the number of distinct QCs referenced per proposal is 1. Under the attack, honest replicas received proposals referencing 2–4 distinct QCs for the same view height, each signed by a *different* historical validator set. The union of signers exceeded 2f+1 but no single set did.

3. **Vote-to-commit latency divergence by signer cohort.** Replicas that joined the validator set at epoch *e'* consistently reported commit latency 2.3× higher for replayed QCs than for fresh ones, because they had to fetch historical validator metadata to verify signatures. This latency signal is a reliable leading indicator: it appears before any equivocation is detected.

4. **Task-commitment ID collisions across epochs.** The shared-state layer assigns commitment IDs monotonically. Replayed QCs caused the same task ID to be committed under two different epoch roots, producing a collision that the application layer surfaced as a "duplicate task" warning rather than a consensus fault.

The critical observation: **no single replica observed an invalid signature.** Every check passed locally. The fault was only visible in the *cross-replica correlation* of epoch metadata.

## Condition of Validity

The signal set above is only diagnostic under the following conditions, and is actively misleading outside them:

- The consensus protocol must carry the validator-set hash (not merely the epoch number) inside the QC. Protocols that identify sets only by integer epoch are vulnerable to a related but distinct attack where epoch numbers are reused after a set rollback; the signals above will not fire.
- The validator set must rotate with a bounded, known lag. If rotation is asynchronous or unbounded, "two epochs stale" is not anomalous.
- Honest replicas must persist historical validator metadata. If they garbage-collect old sets, the latency-divergence signal (3) collapses to a timeout, which is indistinguishable from a slow network.
- The application layer must distinguish commitment-ID collision from legitimate retry. If the shared-state layer deduplicates silently, signal (4) is suppressed.

When any of these fail, the correct response is not to trust the weaker signals but to treat the deployment as outside the diagnostic envelope and fall back to explicit set-membership assertions at every QC consumption point.

## Decision Boundary

The operational decision is: **on detecting a QC whose issuing set-hash does not match the active set, do you reject the proposal, or do you accept it and reconcile later?**

Reject-and-halt is correct when the task commitment is *safety-critical* (e.g., a commitment that authorizes an irreversible external action). A single replayed QC in this regime must halt the pipeline, because accepting it may allow two contradictory commitments to both reach quorum under different sets.

Accept-and-reconcile is correct only when commitments are *idempotent and revocable*, and only if the reconciliation window is shorter than the commitment's deadline slack. In this regime the system may continue, but it must tag the commitment with the issuing epoch and refuse to treat it as final until a fresh-epoch QC re-confirms it.

The boundary is crossed the moment a commitment's deadline slack is shorter than the maximum validator-rotation lag. At that point accept-and-reconcile can produce a commitment that is finalized under an old set but expired under the new one, and no amount of later reconciliation recovers the guarantee.

## Operational Effect

Enforcing set-hash equality at every QC consumption point eliminated the replayed-QC class entirely in the fault-injection campaign (0/500 injected replays accepted, versus 47/500 before the check). The cost was a 6% increase in commit latency for pipelined proposals, because replicas must fetch and compare set metadata on the hot path. This cost is acceptable for safety-critical commitments and should be avoided for idempotent ones, where the epoch-tagging approach suffices.

The deeper effect is architectural: it forces the consensus layer to expose *which set* signed a certificate, not just *that a certificate exists*. Multi-agent task commitment protocols that hide this behind an opaque `justify` blob are, in effect, delegating the safety check to the application layer without telling it. The application layer, unaware, treats the QC as authoritative. The resulting failures are not consensus failures — consensus did its job — but they are task-commitment failures, and they are silent.

```python
from dataclasses import dataclass
from typing import Optional


class StaleQuorumCertificateError(RuntimeError):
    """Raised when a QC's issuing validator set is not admissible at consumption."""
    pass


@dataclass(frozen=True)
class QuorumCertificate:
    epoch: int
    set_hash: str          # hash of the validator set that signed
    signatures: tuple      # 2f+1 signatures over (value, epoch, set_hash)
    value: str


@dataclass(frozen=True)
class ActiveValidatorSet:
    epoch: int
    set_hash: str


def admit_qc(
    qc: QuorumCertificate,
    active: ActiveValidatorSet,
    *,
    max_epoch_lag: int = 1,
    safety_critical: bool = True,
) -> bool:
    """
    Decide whether a QC may be consumed to commit a task commitment.

    Returns True if admissible. Raises StaleQuorumCertificateError when the
    QC is cryptographically valid but operationally inadmissible.
    """
    if qc.set_hash != active.set_hash:
        # Signature validity is irrelevant: the signers are not the current set.
        raise StaleQuorumCertificateError(
            f"QC signed by set {qc.set_hash!r} at epoch {qc.epoch}, "
            f"but active set is {active.set_hash!r} at epoch {active.epoch}. "
            f"Replayed QC cannot bind a task commitment."
        )

    lag = active.epoch - qc.epoch
    if lag < 0:
        raise StaleQuorumCertificateError(
            f"QC epoch {qc.epoch} is ahead of active epoch {active.epoch}; "
            f"possible set-rollback attack."
        )
    if lag > max_epoch_lag:
        if safety_critical:
            raise StaleQuorumCertificateError(
                f"QC epoch lag {lag} exceeds max {max_epoch_lag} for "
                f"safety-critical commitment; refusing to finalize."
            )
        # Idempotent/revocable path: admit but flag for re-confirmation.
        return False

    return True


def commit_task(
    qc: QuorumCertificate,
    active: ActiveValidatorSet,
    task_id: str,
    *,
    safety_critical: bool = True,
) -> str:
    admissible = admit_qc(qc, active, safety_critical=safety_critical)
    if not admissible:
        # Tag with issuing epoch; caller must re-confirm under fresh QC.
        return f"{task_id}@epoch{qc.epoch}:PENDING_RECONFIRM"
    return f"{task_id}@epoch{active.epoch}:FINAL"
```