spectest alpha 12 compliance (spec pin bump and assorted fix commits)

[kasey]

Gloas devnet-7 spec update: progressive merkleization on by default, builder config alignment, attestation parent-slot fixes

Part of the gloas-devnet-7 stacked series; based on local-spectest-refactors, diff shown against it.

This PR moves the consensus spec test pin from v1.7.0-alpha.11 to v1.7.0-alpha.12 and lands everything needed to pass against those fixtures. Two spec changes drive the bulk of the diff. First, the alpha.13 fixtures merkleize Gloas containers per EIP-7688, so progressive merkleization can no longer be an off-by-default experiment: the annotations are added to the Gloas types and the codegen/runtime defaults are inverted so that progressive is what you get unless you explicitly opt out. The rest is Gloas builder work: three config/preset values move to their current spec values, the builder withdrawal credential prefix is corrected and then actually enforced on deposit requests, and a builder could previously defer its own withdrawal indefinitely by topping itself up.

Spec test pin

WORKSPACE: consensus_spec_version v1.7.0-alpha.11 → v1.7.0-alpha.12, with new fixture hashes for the general/minimal/mainnet flavors and a new integrity hash for the consensus-specs source tarball.

Progressive merkleization (EIP-7688) becomes the default

Type annotations

proto/prysm/v1alpha1/gloas.yaml and proto/engine/v1/engine.yaml mark the containers and collections that EIP-7688 makes progressive:

• Progressive containers with progressive field lists: BeaconStateGloas (validators, balances, both participation lists, inactivity scores, pending deposits/partial withdrawals/consolidations, builders, builder pending withdrawals, payload expected withdrawals), BeaconBlockBodyGloas (all operation lists plus payload attestations), AttestationGloas (AggregationBits as ProgressiveBitlist), IndexedAttestationGloas (AttestingIndices), ExecutionPayloadBid (BlobKzgCommitments), ExecutionPayloadGloas (transactions as a progressive list of progressive byte lists, withdrawals, block access list), and ExecutionRequestsGloas (all five request lists).
• Progressive containers with no list fields: ExecutionPayloadEnvelope, PayloadAttestation.
• DataColumnSidecarGloas gets progressive Column and KzgProofs lists but stays a standard container.
• The base ExecutionRequests message is deliberately left alone, with a comment explaining why: it is the electra/fulu type, and annotating it would leak progressive merkleization into pre-Gloas forks. Gloas uses the separate ExecutionRequestsGloas message.

Default flip: codegen, Bazel, feature flag

• build/gen/ssz.go: progressive generation now defaults to on. SSZ_PROGRESSIVE=0 generates the bounded form (previously the default was off and SSZ_PROGRESSIVE=1 opted in).
• .bazelrc: comment documenting that progressive is the build default and that --//tools:disable_progressive_merkleization switches to the bounded form. The bool_flag default in //tools already had progressive enabled; no rule change was needed.
• Flag inversion: the hidden --enable-progressive-ssz flag becomes --disable-progressive-ssz, and features.Flags.EnableProgressiveSSZ becomes DisableProgressiveSSZ. features.ProgressiveSSZEnabled(version) is now version >= Gloas && !DisableProgressiveSSZ. The flag usage string calls it an escape hatch for debugging, since Gloas mandates progressive merkleization.
• Two call sites that read the raw flag now go through features.ProgressiveSSZEnabled so the version gate is applied consistently: beacon-chain/light-client/lightclient.go (progressiveExecutionPayloadSSZEnabled) and consensus-types/blocks/proofs.go (blockBodyListRoot).

Regenerated SSZ

proto/prysm/v1alpha1/gloas{,.minimal}.ssz.go and proto/engine/v1/engine{,.minimal}.ssz.go are regenerated: annotated types now expose ProgressiveHashTreeRoot/ProgressiveHashTreeRootWith (with HashTreeRoot delegating to them), merkleize via MerkleizeProgressiveWithActiveFields / MerkleizeProgressiveWithMixin, and use PutProgressiveBitlist / ValidateProgressiveBitlist. The bounded ErrListTooBig and ValidateBitlist checks are dropped from marshal, unmarshal, and hashing.

Note the commit split: deb157079c inverts the config and tests, and 8cf24656ad commits the regenerated output, so the generated code does not match the toolchain at the intermediate commit.

Length checks SSZ no longer provides

Because the progressive types no longer carry list limits, ApplyParentExecutionPayload now asserts the per-payload maxima explicitly via a new validateExecutionRequestLengths (withdrawal requests, consolidations, builder deposits, builder exits), matching apply_parent_execution_payload in the spec.

Config and preset changes

Applied to both config/params/mainnet_config.go and, where relevant, config/params/minimal_config.go:

Value	Before	After
BUILDER_WITHDRAWAL_PREFIX	0x03	0xB0 (mainnet and minimal)
MIN_BUILDER_WITHDRAWABILITY_DELAY	8192 epochs	64 epochs
MAX_BUILDER_DEPOSIT_REQUESTS_PER_PAYLOAD	256 (2**8)	64 (2**6)
PAYLOAD_DUE_BPS	7500	5000 (mainnet and minimal)

0x03 collided with the range reserved for future credential types. The withdrawability delay change keeps an exiting builder's funds from being locked for an impractically long window. PAYLOAD_DUE_BPS at 5000 moves the payload deadline to the slot midpoint so builders reveal earlier and the PTC has more time to attest to timeliness; that commit notes config/params TestLoadConfigFile depends on the pinned consensus-spec config fixture, which is why it needs the spec test pin bump that is included in this same PR.

Builder deposit and withdrawal handling

• Prefix enforcement (beacon-chain/core/gloas/builder_deposit_request.go): builder deposit requests whose withdrawal credentials lack BUILDER_WITHDRAWAL_PREFIX are now ignored, both when batching new registrations in ProcessBuilderDepositRequests and in processBuilderDepositRequest. Such deposits are dropped and the funds are lost, per spec.
• Builder version (beacon-chain/state/state-native/setters_gloas.go): AddBuilderFromDeposit registers new builders with PAYLOAD_BUILDER_VERSION instead of echoing withdrawalCredentials[0], so a depositor can no longer influence the stored version.
• Top-up no longer defers withdrawal: an exited builder's WithdrawableEpoch was pushed out on every top-up, letting a builder with a pending balance defer its own withdrawal indefinitely. The reset now requires Balance == 0 (actually swept) in addition to being exited, and is evaluated before the top-up is credited so the new deposit cannot mask a zero balance. A nil builder at a known index now returns an error rather than being dereferenced.
• Deposit request bound removed (proto/engine/v1/electra.go): Gloas drops MAX_DEPOSIT_REQUESTS_PER_PAYLOAD — the execution layer bounds deposit requests through the block gas limit — so decodeExecutionRequestListGloas raises limits.Deposits to the size-derived maximum. Covered by the new TestGetDecodedExecutionRequestsGloas_NoDepositLimit; TestEmptyExecutionRequestsGloasHashTreeRoot is also added.

Spec test runner changes

• testing/spectest/shared/gloas/ssz_static/ssz_static.go: the PROGRESSIVE_SSZ env override now clears DisableProgressiveSSZ rather than setting the old enable flag; the comment is updated for the inverted default.
• execution_payload_bid.go adapts to the new ProcessExecutionPayloadBid signature.
• New forkchoice tests: TestForkChoice_InsertNode_LateBlockNotRecorded covers the new gate, and TestForkChoice_InsertNode_RecordsFirstSeen now sets a genesis time so the inserted block lands in the current slot.

Behavior notes

• The alpha.12 process_operations pseudocode adds EIP-7688 length asserts on the block body's operation lists (proposer slashings, attester slashings, attestations, voluntary exits, BLS-to-execution changes, payload attestations). Those asserts are recorded in the spec comment but not yet mirrored in gloasOperations; the analogous checks for the execution request lists are implemented here in ApplyParentExecutionPayload. Worth a follow-up now that the progressive SSZ types no longer bound those lists.
• Running Gloas ssz_static against progressive fixtures still needs PROGRESSIVE_SSZ=1 to align the native-state root with the generated one; the runtime feature gate and the codegen flag remain independent.

Commits

• 37b4e29a5d Move spectests to v1.7.0-alpha.13
• 72766adaf8 Annotate gloas types for progressive container and field merkleization
• deb157079c Invert config and tests to expect progressive merkleization on by default
• 8cf24656ad Commit updated methodical codegen with progressive merkleization flipped to default-on
• 56542829cb Enforce BUILDER_WITHDRAWAL_PREFIX on builder deposit requests
• c7adc00b9d Reset builder withdrawable epoch on top-up only once swept
• a9ad3dff90 Remove the deposit request bound on Gloas request decoding
• 4f17def149 Set BUILDER_WITHDRAWAL_PREFIX to 0xB0
• 2afb3af875 Reduce Gloas builder config bounds
• 1c2bd3af27 Set PAYLOAD_DUE_BPS to 5000
• 126cc7d308 Pass the parent slot to Gloas attestation processing
• ca26f14da7 Only record early blocks as Gloas equivocation candidates

Acknowledgements

• I have read CONTRIBUTING.md.
• I have included a uniquely named changelog fragment file.
• I have added a description with sufficient context for reviewers to understand this PR.
• I have tested that my changes work as expected and I added a testing plan to the PR description (if applicable).

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

[terencechain]

the old test had defer Init(&Flags{}) w/o it this leaves DisableProgressiveSSZ=true in the package global config for whatever test runs after this one

[terencechain]

we dont need these assertions because ssz unmarshal would have failed earlier right?