The remaining hot-path gap, stated precisely because the imprecise version oversells: with
PREPARE enforcement armed, an ECDSA-breaking adversary cannot finalize anything, since
"prepared" needs a full quorum of PREPAREs. What forged proposals could still do is OPEN
rounds and waste them. With proposal enforcement armed, a proposal without a valid Falcon
seal from its own proposer does not open a round.
Same pattern as the PREPARE layer, deliberately: an optional fifth payload element that
leaves the unsealed encoding byte-identical to upstream; a third, separate emission gate;
enforcement self-wired in the payload validator so no refactor can drop it silently; its
own domain over (chainId, height, round, digest), tested in both directions so an honest
offer seal cannot be replayed as a vote nor a vote seal as an offer.
Nothing is armed anywhere: the properties are unset, and unset means never. The armed-
layers table in the README says so, and says what stays classical: the ROUND-CHANGE
message itself and node-level devp2p authentication.
1,042 tests, 0 failures, counted from the XML. The enforcement's negative control ran at
5 of 5: four planted defects each turned the suite red, the untouched source stayed green.
The first publication of this directory, on 11 August 2026, was staged by hand and was
never refreshed. Measured on 29 August: of the 78 files published here, only 14 were still
identical to the tree we run, 63 had changed, and 50 files had never been published at all.
Nobody was hiding anything; there was simply no tool that could redo the selection, so
nobody redid it. There is one now, and it derives this directory from the authoritative
overlay rather than from anyone's memory.
Two things in here contradicted themselves, and both are fixed rather than trimmed.
The README withdrew, in one section, a claim that the source next to it still made: that
from block 14,050,000 a per-block 2f+1 Falcon quorum was required for a block to finalize.
The rule that property arms is retired at the anchor block, so it was inert on arrival.
Three places in the code said otherwise and now carry the correction with its date. The
old text is kept, not deleted: the rule is real code and can be armed on a chain that never
reached an anchor block. What was missing was that on chain 2800 it does not apply.
The terminology section said the certificate is signed by f+1 validators and "not by a
quorum", and invited the reader to count. Since 14,961,456 the enforced minimum is six of
nine, which is a quorum, and the paragraph had not been revised. It now says so, with the
date it changed, and adds the two things that make the claim defensible: the word applies
only at anchor heights, and the higher threshold costs liveness margin.
New in this directory: the post-quantum seal on PREPARE, the hybrid Falcon + SLH-DSA scheme
layer, and the test suites for both. Neither is armed on any network, and the README now
carries a table saying which layers are armed on chain 2800 and which are only present.
They are disarmed by absence rather than by a flag: the properties that arm them are unset,
and unset means never.
Not published, and it is the same three files every time: the negative-control harnesses.
They plant a defect on purpose to prove a guard can fail, which makes them a recipe for
disabling a guard rather than a description of one. What they prove is stated in the README.
Per-file SHA-256 in MANIFEST-sha256.txt. 1,012 tests, 0 failures, counted from the XML.
Line 23 stated the enforced minimum is six of nine, a full 2f+1 quorum. Line 192 stated
the certificate is signed by f+1 validators, not by a quorum, and that we do not call it
one - inviting the reader to count. The terminology paragraph was written when the
threshold was three, where it was true, and was not revised when the threshold was raised
on 21 August 2026. A document that asks to be counted and does not survive the count loses
more than the paragraph.
Corrected without deleting the distinction, and with the two things that were missing and
without which the claim is not defensible: the word quorum applies only at anchor heights,
about every 32nd block, and the blocks between them carry no Falcon seals at all; and the
higher threshold costs liveness margin, since at six of nine three late validators stall an
anchor block where three of nine tolerated six.
Not pushed. Publishing is the founder's decision.
We went and read the field instead of asserting into it, and two things in the
README were saying more than the literature supports.
The attack has a name we were not using. It is posterior corruption, also called
the founders' attack, long-range attack, history revision or costless simulation.
Tas, Tse, Gai, Kannan, Maddah-Ali and Yu (arXiv 2207.08392) survey the four known
mitigations: social consensus, key-evolving signatures, verifiable delay
functions, and timestamping onto a proof-of-work chain.
That paper proves an impossibility, and the previous wording here would have read
as if we had stepped around it. We had not, because it says something narrower
than it first appears: slashable safety, which is safety plus the ability to
punish the attacker, needs an external trusted source. Plain safety against
posterior corruption does not, and key-evolving signatures are shown to give it
under an honest majority. This anchor does not claim slashable safety and the
README now says so.
What it does claim is now stated where it is actually strong. Key-evolving
signatures rest on an old key being gone once deleted. A quantum adversary does
not need it to have been kept: QBFT headers carry addresses, but every seal is an
ECDSA signature from which the public key is recoverable, and from that the
private one. Deleting the key buys nothing when the chain reconstructs it. The
certificate under the block hash still has to be forged, and that needs a secret
no amount of computation derives from the chain.
So this is the post-quantum analogue of what key-evolving signatures give
classically, in the setting where their central assumption is void. Narrower than
checkpointing, and borrowing nothing from another chain. Both true at once.
Sources opened and checked, not recalled: arXiv 2207.08392, eprint 2019/1440,
arXiv 2208.05408.
We cite Azouvi, Danezis and Nikolaenko's "Winkle" for the threat this anchor
addresses. Today we opened the paper instead of repeating the citation, and two
things need saying, because a reader who opens it will notice both.
Winkle does not mention quantum adversaries anywhere. It treats old validator
keys becoming compromised, by any means. The quantum framing is ours.
And Winkle's defence is not this one. It adds a secondary layer of client-based
validation in which clients sign a hash of the previously sequenced block. The
same authors' later work, Pikachu, checkpoints into Bitcoin instead. Both are
established answers to this threat, and a reader weighing our design deserves to
be pointed at them rather than left to find them.
So the README now says it plainly: the threat has peer-reviewed grounding, the
defence in this repository is ours, and the honest difference from checkpointing
is that checkpointing borrows security from another chain while this borrows
nothing.
Citations verified at source, not from memory: eprint.iacr.org/2019/1440, AFT
2020 pp. 189-201; arXiv 2208.05408, 2022.
Caught by our own licence gate the minute the anchor went up, which is the only
reason this is a same-day correction rather than something a reader finds first.
Two separate requirements, both real:
- section 4(b): the twenty upstream files this overlay modifies must carry a
prominent notice that we changed them. They did not. They do now, placed after
the upstream copyright header rather than over it, because 4(c) requires that
header to survive untouched. It does: eighteen still read "Copyright ConsenSys
AG.", two "Copyright contributors to Besu."
- section 4(d): NOTICE must carry the attribution notices of the work this
derives from. It named Hyperledger Besu only, while the files themselves carry
three distinct notices. All three are now reproduced. Naming one of three was a
smaller truth than the files tell.
The patch is regenerated from the corrected files and re-verified end to end, not
assumed: git apply --check and git apply both 0 on a pristine d2032017 checkout,
the resulting tree byte-identical to anchor/ (75 files compared, 0 differences),
and 605 tests with 0 failures across consensus:common and consensus:qbft.
This repository argues, in its own README, that a patch against a named upstream
commit is the honest way to publish a contribution to a million-line project: the
diff is the contribution, the reader fetches the rest from upstream, and a patch
fails loudly when upstream moves while a whole file overwrites in silence.
The anchor was published as whole files only, which contradicted that argument.
It is now both: patches/0003 to apply, anchor/ to read.
Verified on a pristine d2032017 checkout rather than assumed:
- git apply --check and git apply both returned 0
- the resulting tree is byte-identical to anchor/: 75 files compared, 0 differences
- :consensus:common:test and :consensus:qbft:test returned 605 tests, 0 failures,
the same count class by class as the same tree built from the files
The README also said "no build file changes are required" in a place that now
reads as if it covered all three patches. It covered the first two. Patch 0003
changes one build file by one line, and that line is named.
This is the code that puts a post-quantum validator certificate under the block
hash. It is the thing this project exists to do, and it is published so that the
claim can be checked rather than believed.
What it is. In QBFT the block hash is computed over a re-encoding of the decoded
extraData with the seals removed, so anything the decoder does not know about is
dropped before hashing. Appending a certificate as a new element gives you a
certificate that is stored, gossiped, and entirely absent from the hash. The
design that works instead puts a 32-byte digest of the certificate into
vanityData, which is already under keccak. anchor/README.md sets out the four
designs that died before this one and why.
Scope, stated in the README and repeated here because it matters: consensus on
chain 2800 is classical secp256k1 ECDSA. This binds a post-quantum certificate to
the block hash. It does not make consensus post-quantum and is never described as
such.
What is here: the anchor, the validation rules, the wiring, and the tests,
including the negative controls. Applied to upstream d2032017bb, the pinned base
named in anchor/BASE.txt. One build file changes, by one line, and the README says
which and why. No cryptography is implemented here; Falcon verification calls
Bouncy Castle.
What is not here: no keys, no fleet configuration, and nothing about what is armed
on any running network.
Measured before publishing, on upstream d2032017bb with this overlay applied:
consensus:common and consensus:qbft, 605 tests, 0 failures, identical to the same
tree before this work, class by class.
Three things were found while preparing it, and all three are fixed here:
- the code spoke Romanian in 134 comment lines and 43 strings, 37 of them on
production paths, which is to say in the messages a node prints when it refuses
to start. An auditor given the code to check the guards could not read the
guards.
- ten test classes carried internal issue numbers in their names. They now say
what they test.
- the suite was green partly by ordering luck. One class cleared its system
properties but not the configuration PqAnchorProducer remembers, so it left the
anchor armed for whichever class ran next. Renaming the classes changed the
order and four tests began failing on a guard that was firing correctly. Fixed
where it leaks, with the negative control measured: remove the line and the
pair goes red, restore it and it goes green.
