Block Header

A block header is the compact record at the top of every block: the hash of the parent block, the roots that commit to state and transactions, a timestamp, and a field called extraData that consensus protocols use for their own bookkeeping. The block hash is computed from the header, so whatever sits inside the hashed portion is fixed for good: change one byte and every later block stops matching.

On AERE Network (chain id 2800), a new header is produced roughly every 0.62 s (500 ms target, 0.620 s measured on 2026-10-15) under QBFT consensus by ten validators with a quorum of seven. Since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA secp256k1 commit seals, and each carries the Falcon-512 seal of its proposer instead (the headers below that block keep theirs), while a commit still carries the ECDSA commit seal of its validator as an additional check; since block 24,300,000 (AIP-22 stage 4) every validator attributes a consensus vote only through its verified post-quantum seal.

On chain 2800, the header is also where the post-quantum anchor lives. Since block 13,014,000, every 32nd header carries a 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. At least 7 signatures of each required scheme are required per anchor block, as many as the quorum of the ten validators, since block 20,715,632 (2026-09-29; 3 from 2026-08-14, 6 from 2026-08-21; below block 24,148,752 the seals proved those validators signed the block, not that it was decided, per the AIP-22 erratum of 2026-10-01, and from that block a certificate that carries the quorum of one round proves the decision); in practice certificates carry 8 to 10. The keys that may sign are the 10 entries (9 until 2026-09-11) of the signer registry, committed on chain for the epochs up to the one of block 18,082,816 and, for the epoch in force since block 20,836,228 (post-quantum ids, the same keys), pinned by its hash in the node configuration; anyone can read both.

Every header is checked twice: the first, Besu-derived client and a second, independently implemented client validate the chain side by side, and both produce blocks, the second since 2026-09-11 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), which is what client diversity means in practice.