Chain 2800 runs QBFT, the Byzantine fault tolerant engine from Hyperledger Besu, with nine validators.
Parameters
| Parameter | Value |
|---|---|
| Engine | QBFT |
| Validators | 9 |
| Quorum | 6 of 9 |
| Fault tolerance | f = 2 |
| Block period | 0.5 s configured |
| Finality | Deterministic. A committed block is not reorganised. |
| Proposer selection | Round-robin, deterministic |
Six of nine must agree for a block to commit, so the chain tolerates two faulty or offline validators and stops at three. There is no probabilistic settlement: one confirmation is final.
What header validation checks
A node validating a header on chain 2800 checks the ordinary Ethereum rules, the QBFT seal rules, the AERE base fee floor from block 10,141,734, and, at anchor heights, the post-quantum certificate.
Two behaviours are worth knowing because they surprise client authors:
The block hash is not keccak over the raw header. Seals are stripped and the round is set to zero before hashing. An exporter that compares a re-encoded header hash with the one the node reports will disagree from block 1 if it hashes the header as it stands.
Each node assembles the final header locally, and the hash does not cover the seals. Two honest neighbours can therefore store different extraData for the same block, legally. If you are measuring the effect of a configuration change, read it from the node you changed, not from a public endpoint.
Consensus messages under post-quantum seal
Beyond the anchor, the QBFT message layers themselves are moving under post-quantum seals, one layer at a time, each armed at a block height. See Enforcement heights for which layers are in force.
The reason it is one layer at a time, rather than all at once, is cost: a hash-based signature costing seconds cannot go on every message of a half-second chain. Measured, putting SLH-DSA-SHA2-128s on every commit took a test network from 0.5 to 4 seconds per block. The seal therefore rides only on the messages that the next anchor's certificate actually needs.
Two properties an operator should know
- A node's store of post-quantum seals is in memory, so a node that has just started has nothing to
contribute to the next certificate until it has taken part in a commit.
- The anchor rules are delivered as node options, and a node judging headers with a different build
can interpret the same option differently. A rule change therefore ships as the same build to every node that validates headers, and the check compares the build stamp rather than the options.