simulators/lean: correctly decode devnet5 blocks

[MegaRedHand]

Problem

The lean simulator decodes every SignedBlock with the devnet4 wire shape:

LeanSignedBlock { block, signature: LeanBlockSignatures { attestation_signatures, proposer_signature } }

Devnet5 (leanSpec main, since leanEthereum/leanSpec#717) replaced the per-attestation signature list with a single merged multi-message aggregate proof:

class SignedBlock(Container):
    block: Block
    proof: MultiMessageAggregate  # { proof: ByteList512KiB }

Against a devnet5 client the reqresp/blocks_by_root/* tests therefore fail with:

returned block should decode from SSZ: OffsetIntoFixedPortion(4)

The fingerprint is exact: the merged-proof container opens with SSZ offset 4 (its only field is variable), which lands inside the devnet4 signatures container's fixed portion (4-byte offset + 2536-byte proposer signature). Observed against ethlambda_devnet5 in this run (reqresp/blocks_by_root/multiple_known_blocks). The rpc-compat finalized-block decoder (/lean/v0/blocks/finalized) has the same mismatch.

Note the simulator was internally inconsistent: its own devnet5 helper builds leanSpec from main, which already produces the merged-proof shape the mock types could not decode.

Fix

Keep both envelope shapes as wire-only types and select between them from the devnet under test, mirroring the existing devnet4/devnet5 split for states (LeanStateDevnet4):

• LeanSignedBlock is the merged-proof envelope; the devnet4 envelope moves to LeanSignedBlockDevnet4
• Scenario code works with the inner LeanBlock only. LeanBlock::from_signed_wire_ssz_bytes decodes the devnet-appropriate envelope (validating the signature payload structurally) and returns the block; no placeholder signature or proof values are stored, since no test inspects them
• LeanBlock::to_signed_wire_ssz_bytes / encode_gossip_block wrap a block in the devnet-appropriate envelope for gossip publishes (encode_gossip_data was only ever used for blocks, so it became encode_gossip_block)
• rpc-compat gets the same split (LeanRpcSignedBlockDevnet4 / LeanRpcSignedBlock) and decode_finalized_block returns the inner LeanRpcBlock

Working with the inner block is sound because the decode and encode paths never meet. Decode sites (reqresp, rpc-compat) only assert on block fields and never re-send what they received. Encode sites (gossip, validation) publish synthetic blocks built from scratch: the mock has no validator keys, so it has always published default (unverifiable) signatures, and the empty envelope produces the same bytes as before. There is no decode-then-re-encode path that would lose signature data; if a future test needs to relay a received signed block verbatim, both envelope types stay pub for decoding in full (or the raw payload bytes can be forwarded unchanged).

Devnet4 runs are unaffected: they keep encoding and decoding the old shape, bit-identical to before.

Testing

• cargo test in simulators/lean passes (client_interop::two_subnet_node_builder_accepts_all_devnet4_lean_clients fails identically on master in my environment)
• cargo clippy introduces no new warnings; cargo fmt clean

Related: leanEthereum/leanSpec#974 restores the /lean/v0/blocks/finalized helper endpoint this suite's checkpoint-sync setup probes; the two fixes are independent.

Second commit: helper crashes against leanSpec main

While verifying the fix locally, a second devnet5 breakage surfaced: the lean-spec helper is built from leanSpec main, but leanSpec restructured its packages (subspecs/types → node/spec, leanEthereum/leanSpec#788 and follow-ups). A freshly built devnet5 helper now crashes on startup with ModuleNotFoundError: No module named 'lean_spec.subspecs', taking down every helper-dependent devnet5 test at setup. (Production results on hive.leanroadmap.org still show the helper running, which means the deployed sim image carries a pre-restructure leanSpec snapshot; a genuine rebuild would hit this.)

The second commit makes the helper runner work with both layouts: new import locations are tried first, the old ones remain as fallbacks for the pinned devnet4 helper. Verified by importing the runner in venvs of both leanSpec main (1b02fd1) and the devnet4 pin (db21cc24).

Verification

Ran hive --sim lean --sim.limit 'reqresp/blocks_by_root/multiple_known_blocks$' locally against an ethlambda devnet5 client with the helper built from leanSpec main (1b02fd1): the previously failing test passes. The devnet4 helper path is covered by import smoke tests against the pinned checkout (db21cc24).

One caveat surfaced during verification: the currently published ghcr.io/lambdaclass/ethlambda:devnet5 image (built from ethlambda's devnet5-bump-leanmultisig branch) serves the genesis anchor block with a zero-byte proof, which is invalid SSZ under MultiMessageAggregate (its offset alone needs 4 bytes). The simulator now correctly rejects that with InvalidLengthPrefix { len: 0, expected: 4 }. ethlambda main already encodes the genesis proof correctly (verified passing with an image built from ethlambda main), so this resolves itself when the published devnet5 image is rebuilt.

Not addressed here: the simulator Dockerfile's metadata ADD lines hit GitHub's unauthenticated API rate limit on local builds; worked around locally, left untouched since the hosted builder presumably authenticates.

[KolbyML]

looks good