build(genesis)!: generate keys for leanVM's internalized XMSS

[MegaRedHand]

What

Moves genesis key generation to the XMSS implementation leanVM internalized when the standalone leanSig crate was retired, and moves the ethlambda client image in step.

Public keys are now SSZ and 32 bytes (they were 52 under leanSig) and secret keys are postcard-encoded. File names and the manifest schema are unchanged, so parse-vc.sh, the ansible roles and the client --hash-sig-keys-dir flags need no adjustment.

Changes

	Before	After
Keygen image	blockblaz/hash-sig-cli:latest	ghcr.io/lambdaclass/hash-sig-cli:0.5.0
ethlambda image	ghcr.io/lambdaclass/ethlambda:devnet4	ghcr.io/lambdaclass/ethlambda:devnet5-leanvm-main
Manifest check	pubkeys are hex	plus: reports key_scheme and pubkey size, warns on a pre-0.5.0 key set, fails on a pubkey_bytes mismatch
Keygen log	hardcoded SIGTopLevelTargetSumLifetime32Dim64Base8	scheme comes from the manifest

The keygen image is a lambdaclass GHCR build because no published blockblaz/hash-sig-cli tag generates this format: upstream's auto-release.yml fires only on a merged release PR, and hash-sig-cli#39 is still open. It is multi-arch (amd64 + arm64) and built from that branch. Once upstream tags a release this is a one-line switch back to Docker Hub.

The two image pins have to move together: a leanSig-era client cannot read these keys, and vice versa.

Why the extra manifest checks

Key file names did not change across the migration, so a hash-sig-keys/ directory left from an older image still satisfies the existing "keys already exist" check and its 52-byte pubkeys would be written into config.yaml with nothing flagging it. The generator now prints what it found and says how to regenerate:

   Key scheme: SchemeAbortingTargetSumLifetime32Dim46Base8
   Public key size: 52 bytes
   ⚠️  Manifest reports no 'pubkey_bytes' - these keys predate hash-sig-cli 0.5.0
      and are in the retired leanSig format. ...
      Regenerate: ./generate-genesis.sh <dir> --forceKeyGen

The pubkey_bytes mismatch case is a hard error: it means the manifest was edited or merged incorrectly, which has silently corrupted a key set before (a YAML 1.1 loader coerces unquoted 0x pubkeys to integers).

Verification

• generate-genesis.sh run end to end from an empty genesis dir with --forceKeyGen against the new image: keys generated, manifest verified as XmssTargetSumLifetime32Dim42Base8 / 32 bytes, and config.yaml, validators.yaml, nodes.yaml, genesis.json, genesis.ssz, annotated_validators.yaml plus node keys all produced. All four pubkeys in config.yaml are 32 bytes.
• Re-run against an existing 32-byte key directory: passes silently.
• Re-run against a 52-byte key directory: warns with the regeneration command, as above.
• bash -n clean on the touched shell scripts; the ansible files parse.

⚠️ Breaking

Existing hash-sig key sets cannot be migrated. Regenerate with --forceKeyGen, and run a leanVM-XMSS client build (devnet5-leanvm-main for ethlambda). Other clients need their own leanVM-XMSS images before they can join such a devnet.

[Copilot]

Pull request overview

This PR updates genesis hash-signature key generation and client/automation pins to match leanVM’s internalized XMSS key format (post-leanSig), including stronger manifest validation to prevent silently reusing incompatible legacy key directories.

Changes:

• Pin hash-sig keygen to ghcr.io/lambdaclass/hash-sig-cli:0.5.0 and update docs to reflect 32-byte SSZ public keys.
• Add manifest cross-checks in generate-genesis.sh to report key_scheme, validate pubkey_bytes, and warn/fail on legacy or inconsistent key sets.
• Bump ethlambda client image pin (and ansible defaults) to devnet5-leanvm-main to stay compatible with the new key format.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
README.md	Updates user-facing docs for the new keygen image and manifest fields (key_scheme, pubkey_bytes).
generate-genesis.sh	Pins the new keygen image and adds manifest-based validation/reporting to detect legacy or inconsistent key directories.
client-cmds/ethlambda-cmd.sh	Updates the default docker image tag for ethlambda to the leanVM-XMSS-compatible build.
ansible/roles/ethlambda/tasks/main.yml	Updates fallback default ethlambda docker image to match the new client tag.
ansible/roles/ethlambda/defaults/main.yml	Updates role default ethlambda docker image tag for consistency with tasks/client script.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

generate-genesis.sh:383

• In dual-key mode the new pubkey_bytes consistency check only derives the byte length from the attester pubkey. If the manifest is corrupted such that attester/proposer pubkeys differ in length, this won’t be detected (and the printed “Public key size” may be misleading). Consider computing and validating both lengths, and fail if they differ or if either mismatches pubkey_bytes.

    # Cross-check the pubkey length the manifest declares against the pubkeys it holds.
    # Key file names did not change when the format moved to leanVM's XMSS, so a key
    # directory left over from an older image passes the "keys already exist" check
    # above and would otherwise be baked into config.yaml unnoticed.
    MANIFEST_KEY_SCHEME=$(yq eval '.key_scheme // ""' "$MANIFEST_FILE" 2>/dev/null)
    MANIFEST_PUBKEY_BYTES=$(yq eval '.pubkey_bytes // ""' "$MANIFEST_FILE" 2>/dev/null)
    ATTEST_PUB_BYTES=$(( (${#ATTEST_PUB} - 2) / 2 ))
    echo "   Key scheme: ${MANIFEST_KEY_SCHEME:-<unreported>}"
    echo "   Public key size: ${ATTEST_PUB_BYTES} bytes"
    if [ -z "$MANIFEST_PUBKEY_BYTES" ]; then
        echo "   ⚠️  Manifest reports no 'pubkey_bytes' - these keys predate hash-sig-cli 0.5.0"
        echo "      and are in the retired leanSig format. Clients built against leanVM's XMSS"
        echo "      cannot read them; the genesis below will not start such a devnet."
        echo "      Regenerate: ./generate-genesis.sh \"$GENESIS_DIR\" --forceKeyGen"
    elif [[ ! "$MANIFEST_PUBKEY_BYTES" =~ ^[0-9]+$ ]]; then
        # Guard the arithmetic comparison below: a non-numeric value makes `[ -ne ]` fail
        # as a condition, which would skip the check instead of reporting anything.
        echo "   ❌ Error: manifest 'pubkey_bytes' is not a number: $MANIFEST_PUBKEY_BYTES"
        echo "   The manifest is inconsistent - regenerate it rather than editing it by hand"
        exit 1
    elif [ "$ATTEST_PUB_BYTES" -ne "$MANIFEST_PUBKEY_BYTES" ]; then
        echo "   ❌ Error: manifest declares pubkey_bytes=$MANIFEST_PUBKEY_BYTES but its pubkeys are $ATTEST_PUB_BYTES bytes"
        echo "   The manifest is inconsistent - regenerate it rather than editing it by hand"
        exit 1
    fi

README.md:738

• The README now states (correctly) that key_scheme is derived from the pinned image/leanVM XMSS constants, but the earlier “Signature Scheme” section still says the system uses a fixed SIGTopLevelTargetSumLifetime32Dim64Base8 scheme. With the updated generator/image, that fixed-scheme statement is now misleading; consider updating that section to reflect that consumers should trust validator-keys-manifest.yaml:key_scheme (and potentially pubkey_bytes) rather than a hardcoded scheme name.

`key_scheme` and `pubkey_bytes` are derived from the constants of the XMSS revision the image was
built against, so they report the actual format on disk instead of a fixed label. `generate-genesis.sh`
reads `pubkey_bytes` back to detect a key directory left over from an older image.