mirror of
https://github.com/luxfi/consensus.git
synced 2026-09-24 00:26:58 +00:00
zeekayandHanzo Dev
b0f6a338e7
The seed preimage was be64(epoch) || chain_id || prev_block_hash, written end
to end. Nothing recorded where one field stopped and the next began, so the
boundary slid: DeriveEpochSeed(1, "chain-A", "") and DeriveEpochSeed(1,
"chain-", "A") are one seed. Machine-checked, both are
c89a52... under the old encoding.
That is not only untidy. The seed decides alpha, the count of votes a round
accepts on, and the input that makes it unpredictable is the parent hash --
the one value nobody holds until the previous epoch finalizes. Under a
concatenated preimage a chain that names itself lux-mainnet||H binds no parent
at all and still derives the seed lux-mainnet derives at parent H. The chain id
is a name the chain picks for itself; the parent is not. Trading one for the
other gives away the whole reason the parent is an input.
So every variable-length field is now written at its length, and the digest is
taken under a label of its own:
domain || be64(epoch) || be64(len(chain_id)) || chain_id
|| be64(len(prev_block_hash)) || prev_block_hash
with domain = "lux.consensus.fpc.seed". Lengths make the preimage read back
apart into exactly the triple that produced it, which is injectivity stated as
something a machine checks rather than something a comment claims:
TestOneTripleReachesOnePreimage parses each preimage back and compares. The
domain keeps this digest from colliding with any other the protocol takes over
similar bytes.
EpochSeedPreimage is exported because the corpus records the bytes, not only
the digest. Two implementations can agree on every digest in a corpus and still
disagree on the first case that is not in it; they cannot, if they agree on
what they hashed. The oracle asks the package for the preimage rather than
rebuilding it, so a vector is never a second copy of the encoding it records.
pkg/rust carries the same change, and the same reason: it is the crate the
Rust conformance harness holds against these vectors.
Co-authored-by: Hanzo Dev <[email protected]>