Skip to content

Update EIP-7916: Address review feedback #9565

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 13, 2025
Merged

Update EIP-7916: Address review feedback #9565

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions EIPS/eip-7916.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -67,7 +67,7 @@ ProgressiveList[T]
\/
ROOT

V1: Vector[T, 1]
V1: Vector[T, 1] # Assuming `T` with a 32-byte chunk size; otherwise vectors are scaled accordingly
V2: Vector[T, 4]
V3: Vector[T, 16]
V4: Vector[T, 64]
Expand Down Expand Up @@ -167,7 +167,7 @@ Mixing in successor subtrees ensures predictable gindices and proof sizes.

## Security Considerations

- Resource limits: The `uint32` length-prefix caps serialization of variable-length subsections at 4GB, but practical limits (e.g., 10MB libp2p messages) apply. Implementations SHOULD enforce context-specific bounds.
- Resource limits: The `uint32` limit for variable-length offsets essentially introduces a ~4GB cap when including a `ProgressiveList[T]` within another complex type, but practical limits (e.g., 10MB libp2p messages) apply. Implementations SHOULD enforce context-specific bounds.
- Variable proof size: Recursive traversal may increase proof sizes for large indices, though logarithmic in list size due to scaling.

## Copyright
Expand Down