Spec specifies Poseidon XMSS (52-byte pubkey) while every client runs leanVM's BLAKE2s (32-byte); fixtures are unusable

[dimka90]

Summary

leanSpec specifies XMSS over Poseidon, with a public key of root + parameter. Every client on the shared devnet now runs leanVM's BLAKE2s XMSS, whose public key is the bare 32-byte root. The two are not interchangeable, and the spec's generated fixtures cannot be consumed by a client built against leanVM.

I am not reporting this as a defect so much as asking what the intended sequencing is, because three clients have already moved and the spec is the stated source of truth.

What the spec has

At the revision gean pins (eca701efeb5931010fe63925cd203c9ee55b2dbc) and at current main (0b7d33ec):

• src/lean_spec/spec/crypto/xmss/ contains poseidon.py and no other hash engine.

• xmss/interface.py:12 imports POSEIDON, PoseidonXmss; the scheme is built on it throughout.

• grep -rli blake2 src/lean_spec/ returns nothing.

• xmss/containers.py:32 defines the public key as a container:

  class PublicKey(HexSerializedContainer):
      root: HashDigestVector
      parameter: Parameter

  With PARAMETER_LENGTH = 5 field elements, that serialises to 52 bytes.

--scheme accepts test or prod (packages/testing/.../keys_cli.py:29). Both are Poseidon configurations differing in parameter sizes, so there is no scheme selector that produces a BLAKE2s key set.

What the clients run

leanVM 48a904208d682848dac0e18ef8b01ebfc40df9ad — BLAKE2s over a binary field, public key PUB_KEY_SIZE = 32, the bare root with no parameter.

As of today, on one shared devnet:

client	leanVM pin
gean	48a90420
ethlambda	48a90420 (build/leanvm-unified-aggregate-api, image 006453f4)
lantern	48a90420 (devnet-5-leanvm-b, image 9ce166c4)

gean and ethlambda have been interoperating on it for eight hours: 7,000 slots, finality tracking on both clients, zero restarts.

The concrete failure

gean's spec fixture tests panic on every run since it migrated to leanVM:

panic: parseHexPubkey: pubkey too long: got 52 bytes, want 32
  internal/spectests/fixture.go:132
  forkchoice_test.go:220  (fcState.toState)

52 is the spec's root + parameter; 32 is leanVM's root. Neither bumping the pinned spec revision nor changing --scheme resolves it, because current main has the same container and neither scheme value is BLAKE2s.

What I am asking

1. Is a BLAKE2s XMSS scheme planned for leanSpec, and is there an issue or branch tracking it? I could not find one; eca701ef ("make equivocation head assertions scheme-independent") suggests some preparation for more than one scheme.
2. Until then, what should a client that has migrated do about the fixtures? The options a client has are to skip the affected tests, carry a local shim between the two key formats, or stay on the Poseidon line and lose devnet interop with everyone else. None of those is obviously right.
3. Is the divergence intended as a temporary state while leanVM stabilises, or has the scheme decision moved to leanVM with leanSpec to follow?

Happy to help with fixture generation or cross-checking against a client if that is useful.

Related

• Can an XMSS aggregate carry two messages at one epoch? (claims keyed (epoch, key), unlike SPHINCS) leanVM#278 — the change that moved claim grouping to (epoch, message), which is what put all three clients on 48a90420 this week
• Blocks may carry two AttestationData for one slot, which no leanVM proof can express #1209 — a separate silence in the spec, still open: whether a block may carry two AttestationData for one slot. Two clients implemented opposite readings of it and a mixed devnet split permanently until one was fixed.

[gopikannappan]

If it helps with question 1: I'd be happy to write the BLAKE2s XMSS scheme in leanSpec, next to poseidon.py, matching leanVM 48a90420's crates/xmss (W = 3, 42 chains of length 8, target sum 195, 16-byte digests, 24-byte randomness, 2^32 lifetime, 32-byte bare-root public key). I'd cross-check it against leanVM with known-answer vectors from its Rust implementation, so fixtures generated from the spec load in gean, ethlambda and lantern as they are.

Before starting I'd want to know two things from the maintainers:

• Should BLAKE2s replace Poseidon as the scheme behind --scheme prod, or live alongside it as a third option?
• Is the PublicKey container expected to become a bare root for every scheme, or only for BLAKE2s?

I don't want to open a PR that fixes the direction before that's decided.