Skip to content

test(ceremony): pin the Chain ID to the EVM Chain Profile vectors - #25

Merged
xgreenx merged 2 commits into
mainfrom
test/evm-chain-profile
Sep 7, 2026
Merged

xgreenx merged 2 commits into
mainfrom
test/evm-chain-profile

Conversation

@xgreenx

@xgreenx xgreenx commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

Companion to libid#30, which
writes the Chain Profile REQ-COMMON-01C requires and no document supplied.
This pins TEST-CHAIN-02 here.

CeremonyAuthorization.chainId() is keccak256(abi.encode(block.chainid)),
and until #30 nothing said so outside this repository. chainId is the one
Authorization Digest input the two sides derive independently — the Platform
Verifier from its own environment, the Canonical Runtime from a value the
composition hands it — so a composition that guesses the preimage wrong
produces a digest this chain rebuilds differently. That surfaces as
CodeVerifierMismatch on X and GitHub, the same failure
#24 fixes one field
over.

What was already covered, and what was not

CeremonyProofVerifier.t.sol has test_theVerifierBuildsTheDigestFromThisChain
and test_theDigestFollowsTheChainAndNotTheCaller — between them TEST-CHAIN-03,
that the recomputation reads the chain itself and takes no identifier from the
caller. Both hold under any preimage, including one no runtime could
reproduce. Nothing pinned the bytes.

ChainProfile.t.sol adds four:

  • test_chainIdMatchesTheProfileVectors — chains 1, 8453 and 11155111
    against the values published in specs/chain-profiles.md §3.1, transcribed
    and not recomputed here (REQ-CHAIN-04).
  • test_theProofVerifierExposesThePublishedChainId — REQ-CHAIN-04B, this
    profile's answer to REQ-CHAIN-03: what a composition reads from the
    destination is the published value, so trusting that reading is safe.
  • test_theWidthIsTwoHundredAndFiftySixBits — the one-byte and eight-byte
    big-endian forms of the same identifier hash elsewhere. That is the actual
    ambiguity a runtime author faces; the vectors settle it, this names what
    they rule out.
  • test_everyChainGetsItsOwnChainId — the EIP-155 uniqueness REQ-CHAIN-04
    rests on.

408 tests pass; forge fmt --check clean. Test-only, no contract change.

`chainId()` was consistent with itself and with nothing else. Two tests in
CeremonyProofVerifier.t.sol already say the digest follows the chain and
not the caller, and that the value the Proof Verifier exposes is the one
it commits -- but both would hold just as well under a preimage no
Canonical Runtime could guess, which is what a composition has to
reproduce to build a digest this chain rebuilds.

TEST-EVM-01, transcribed from the profile rather than derived here: the
Chain ID of chains 1, 8453 and 11155111, the reading a composition takes
from the Proof Verifier, and the two shorter big-endian forms of the same
identifier that the published width rules out.

Assisted-by: Claude Opus 5
Signed-off-by: xgreenx <xgreenx9999@gmail.com>
The profile carries one REQ-CHAIN- prefix across every chain family
rather than a per-family one, so the citations here move with it:
TEST-EVM-01 is TEST-CHAIN-02, and the vector, reading and width
requirements are REQ-CHAIN-04, -04B and -04. The distinctness test cited
the cross-profile separation rule, which is about two profiles sharing a
preimage shape; what it actually shows is EIP-155 uniqueness inside this
one.

Assisted-by: Claude Opus 5
Signed-off-by: xgreenx <xgreenx9999@gmail.com>
@xgreenx
xgreenx marked this pull request as ready for review September 7, 2026 16:46
@xgreenx
xgreenx merged commit e28c621 into main Sep 7, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant