QBFT Consensus

QBFT, Quorum Byzantine Fault Tolerance, is a consensus protocol for networks with a known set of validators rather than open mining. Validators take turns proposing blocks. Each proposal passes through a prepare phase and a commit phase, and a block joins the chain only once a quorum of validators has signed it. Quorums are sized to overlap in honest validators, so conflicting blocks can never both collect enough signatures. The result, for a validator, is immediate finality: no forks, no reorganizations, no waiting for confirmations. From block 25,080,000 (AIP-22 stage 5) a node that does not take part in consensus, such as the public RPC endpoints, admits a header between anchors on the Falcon-512 seal of its proposer alone, so until the next anchor the blocks above its finalized block, including blocks it has already shown, can be replaced by a branch that the key of a single validator builds (such a node keeps the total-difficulty fork choice of the upstream client; the rule that never leaves a decided block runs on the validators only); for settlement, read the finalized or safe block, which moves only on an anchor certificate that the key of one validator cannot produce (derived from the code; measured on the rehearsal network 28099 with a classical-only fork, AIP-22 record of 2026-09-27: such a node followed the fork up to the block before the next anchor and moved to the anchored chain once linked to an honest validator; not measured: the same with a post-quantum key from stage 5, and whether a node started from the published package, with its seal ceiling at 1, answers these tags the same way). The protocol keeps working as long as the honest validators can still form a quorum, even if the rest are faulty, offline, or malicious.

Chain 2800 runs QBFT with ten validators and a quorum of seven, producing one block roughly every 0.62 s against a 500 ms target (0.620 s measured on 2026-10-15). Since 2026-09-11 every validator also refuses a commit message that does not carry a post-quantum seal; since block 24,300,000 (AIP-22 stage 4) every validator attributes a consensus vote only through its verified post-quantum seal. Since block 25,080,000 (AIP-22 stage 5) the block header records no ECDSA commit seals: it carries the Falcon-512 seal of its proposer instead, which admits the header while the commit quorum of one round decides the block, and, since block 24,300,000 (AIP-22 stage 4), every vote counts only with the verified post-quantum seal of its author, and a commit still carries the ECDSA commit seal of its validator as an additional check. Aere calls that post-quantum consensus, with three limits: the transport between nodes is still authenticated by secp256k1, the ten validators are run by one operator, and no third party has audited it yet. A node that does not take part in consensus admits a header between anchors on the Falcon-512 seal of its proposer alone, so the post-quantum key of one validator can serve such a node a branch up to the block before the next anchor (below block 25,080,000 that took the ECDSA keys of a quorum), and the next anchor ends it for a node that requires the seals of a quorum in its certificate (the published follower, with its seal ceiling at 1, is not such a node: for it one leaked or misused post-quantum key of a validator makes the rewrite depth unbounded, section 6.4 of the aere-node SPEC). What the chain adds is a distinct layer on top: since block 13,014,000, every 32nd header carries a seal certificate of post-quantum signatures (Falcon-512 at every anchor and, since 2026-09-04, SLH-DSA-SHA2-128s as a second, hash-based scheme, every 128th block since 2026-09-29) from the validators over the parent block, and a 32-byte digest of that certificate sits inside the data covered by the block hash. That mechanism is the post-quantum anchor.

A second, independently implemented client validates every block alongside the first, Besu-derived client, and since 2026-09-11 it also proposes and seals blocks as the tenth validator (nine of the ten run the first client; corrected 2026-10-28: this sentence called the first client the producing client), so a consensus defect in either implementation surfaces as a disagreement between them instead of a silent failure. See client diversity.