Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request implements support for the Gloas fork (EIP-7688) by transitioning core consensus structures like BeaconState and BeaconBlockBody to progressive SSZ types. Key changes include updating dependencies to @chainsafe/ssz v1.6.0, implementing Gloas-specific light client proof logic, and establishing P2P size limits for progressive gossip objects. Review feedback identifies a potential vulnerability where getGossipSSZMaxSize lacks explicit limits for attestations and points out a performance regression in the participation flag update logic due to O(N) array allocations. Further suggestions include using Gloas-native default headers in the light client server and simplifying fork-specific witness validation logic to ensure consistency and efficiency.
Contributor
Performance Report✔️ no performance regression detected Full benchmark results
|
Brings the EIP-7688 (progressive SSZ) branch up to the v1.7.0-alpha.11 spec baseline. Conflict resolutions of note: - @chainsafe/ssz bumped to ^1.6.0 (progressive types) across workspace; dropped unused deps (utils ssz, cli pubkey-index-map, st persistent-ts) to match unstable's #9462 cleanup. - gloas sszTypes: kept branch's progressive types, re-applied unstable's alpha.9-11 changes it predated: EIP-8282 builder deposits/exits (as ProgressiveList), BuilderPendingPayment.proposerIndex, and ExecutionPayloadBid.gasLimit UintBn64 -> UintNum64. - processParentExecutionPayload: kept #4630 length asserts, extended to builder deposits/exits, used unstable's 5-field empty-requests check. - processOperations: kept assertGloasOperationLimits + unstable's fulu zero-deposit rule. - specTestIterator: kept branch's narrower gloas light-client skips. Build, check-types, lint, and types/state-transition unit tests green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
https://discord.com/channels/595666850260713488/1295427781722898505/1520371177036709949 we need couple more progressive containers in gloas. --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Member
|
Current code passes all spec tests in ethereum/consensus-specs#4630 . Waiting for alpha.12 to be released before marking the PR ready for review. |
**Motivation** - improve upgradeStateToGloas() by reusing nodes of pre-gloas BeaconState - bump `@chainsafe/ssz` version to v1.6.1 **Description** with mainnet state 14707840 - before ``` [bench] upgradeStateToGloas: 3205.5ms [bench] gloas hashTreeRoot: 32196.4ms ``` - this PR ``` [bench] upgradeStateToGloas: 1178.3ms [bench] gloas hashTreeRoot: 4899.3ms ``` **AI Assistance Disclosure** - created with the help of Claude --------- Co-authored-by: Tuyen Nguyen <twoeths@users.noreply.github.com> Co-authored-by: NC <17676176+ensi321@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ensi321
added a commit
that referenced
this pull request
Jul 7, 2026
Squashed eip7688 implementation from the eip-7688 branch (lodestar #9390) @ 06b588d: converts Gloas containers to ProgressiveContainer/ProgressiveList (incl. additional containers #9586 and BlockAccessList -> ProgressiveByteList), bumps @chainsafe/ssz, updates light-client gindices and gossip size bounds, and reuses container nodes in upgradeStateToGloas for perf (#9601). Verified against #4630-generated spec vectors.
…nsensus-specs #4630) apply_parent_execution_payload performs no length checks in the spec. With EIP-7688 the ExecutionRequests lists are progressive (no SSZ max length), so the Electra-cap assertion (assertExecutionRequestsWithinLimits) is invalid -- requests exceeding the Electra caps are valid. Removes the assertion and its now-unused imports. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Reverts 0395641. consensus-specs master still asserts the 5 execution request length limits in apply_parent_execution_payload (beacon-chain.md L1284-1290, tip a62bc326c) through the #4630 merge and all followups; the "drop the cap" idea was never adopted (#5420 instead tightened MAX_BUILDER_DEPOSIT_REQUESTS_PER_PAYLOAD 256->64). Keep parity with spec. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The value shipped in the merged #4630 (and master, tip a62bc326c) is lower than the pre-merge PR snapshot this branch used: - mainnet 4082504 -> 4027336 - minimal 1993180 -> 1938012 (MAX_BUILDER_DEPOSIT_REQUESTS_PER_PAYLOAD 256->64 and PAYLOAD_DUE_BPS 7500->5000 are handled on nc/alpha.12-constants, not here.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… gossip consensus-specs #4630 (gloas p2p-interface) requires beacon_block gossip to REJECT when parent_execution_requests counts or block body operation counts exceed their per-block limits. EIP-7688 made these lists progressive (no SSZ type-level cap), so the bounds are enforced here at the gossip layer (they are also asserted in the state transition). deposits must be empty (limit 0) post-Fulu. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ensi321
added a commit
that referenced
this pull request
Jul 7, 2026
Squashed eip7688 implementation from the eip-7688 branch (#9390): progressive containers/lists for Gloas, @chainsafe/ssz ^1.6.1, light-client gindices, apply_parent_execution_payload length asserts, MAX_SIGNED_BEACON_BLOCK_SIZE synced to alpha.12 (4027336/1938012), and block-gossip count REJECTs.
twoeths
reviewed
Jul 8, 2026
twoeths
left a comment
twoeths
left a comment
Member
There was a problem hiding this comment.
right now we have
function activeFields(count: number): boolean[] {
return Array.from({length: count}, () => true);
}to mark all active fields active, and we have no way to represent an inactive fields in the future. May want to refactor it to allActiveFields(number), so that in the future we can have a real activeFields(0b1001) or activeFields("0b1001") (if it's too many fields) to represent inactive fields also
Bring EIP-7688 progressive-containers branch current (36 commits behind). Conflicts resolved: - beacon-node/package.json: keep quic ^2.1.1 (unstable), ssz ^1.6.1 + persistent-merkle-tree ^1.3.0 (eip-7688, needed for progressive containers) - topic.test.ts: union of both test suites (gossip SSZ size limits + getAllowedTopics) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Do the alpha.12 bump in eip-7688 branch. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ensi321
marked this pull request as ready for review
July 16, 2026 16:44
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ef8b555e4e
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| typeName: "BLSToExecutionChanges", | ||
| }); | ||
|
|
||
| export const Validators = new ProgressiveListCompositeType(phase0Ssz.Validator, {typeName: "Validators"}); |
There was a problem hiding this comment.
With Validators now using progressive-list merkleization, a post-Gloas state cannot safely reuse a pre-Gloas list view. loadState() still overwrites the deserialized field with migratedState.validators = seedState.validators.clone(true) (and similarly transfers inactivity scores whenever both forks are Altair+), so loading Gloas state bytes from a Fulu/Electra seed state during restart/regen before finalization crosses the fork keeps old list nodes inside a Gloas state and produces incorrect roots. Please gate those cache transfers on matching fork/list types or migrate them like upgradeStateToGloas.
Useful? React with 👍 / 👎.
Member
There was a problem hiding this comment.
Will be addressed in a follow-up PR
| ); | ||
|
|
||
| export const ExecutionPayloadEnvelope = new ContainerType( | ||
| export const ExecutionPayloadEnvelope = new ProgressiveContainerType( |
There was a problem hiding this comment.
After this switches the envelope to progressive containers/lists, ssz.gloas.SignedExecutionPayloadEnvelope.maxSize is no longer the preset P2P bound. The gossip path compensates via getGossipSSZMaxSize, but req/resp still passes ssz.gloas.SignedExecutionPayloadEnvelope directly to the SSZ-snappy decoder, which validates the length prefix only against type.maxSize; on ExecutionPayloadEnvelopesByRoot/Range, a peer can therefore advertise an oversized SSZ length and make us read/decompress far beyond the intended limit instead of rejecting it up front. Please add bounded TypeSizes for these progressive req/resp responses too.
Useful? React with 👍 / 👎.
Member
There was a problem hiding this comment.
Will be addressed in a follow-up PR
Root package.json was left at ^1.6.1 when packages/* were bumped to 1.6.2, leaving the lockfile pointing at a dropped 1.6.1 block and breaking frozen install in CI. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
twoeths
reviewed
Jul 17, 2026
**Description** - more progressive ssz utils to reuse nodes, this improves: - gloas fork transition to migrate basic list - progressParticipationFlagUpdates, which happens at epoch transition - also do not check deposit length as found in #9390 (comment) **AI Assistance Disclosure** - created with the help of Claude --------- Co-authored-by: Tuyen Nguyen <twoeths@users.noreply.github.com>
twoeths
previously approved these changes
Jul 17, 2026
ensi321
approved these changes
Jul 21, 2026
ensi321
left a comment
ensi321
left a comment
Member
There was a problem hiding this comment.
Will have to do a follow up PR to address codex's comments
This was referenced Jul 21, 2026
ensi321
added a commit
that referenced
this pull request
Jul 24, 2026
Depends on #9390 --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: Nico Flaig <nflaig@protonmail.com>
wemeetagain
pushed a commit
that referenced
this pull request
Aug 4, 2026
Follow up on unaddressed comments from #9390 --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Member
Author
|
🎉 This PR is included in v1.46.0 🎉 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Description
AI Assistance Disclosure