Skip to content

Update EIP-8288: Define bounded complete mempool wrappers - #12473

Closed
Marchhill wants to merge 63 commits into
ethereum:masterfrom
Marchhill:eip8288-bounded-batches
Closed

Marchhill wants to merge 63 commits into
ethereum:masterfrom
Marchhill:eip8288-bounded-batches

Conversation

@Marchhill

@Marchhill Marchhill commented Oct 9, 2026 •

Copy link
Copy Markdown
Contributor

Superseded by #12590 for wrapper encoding and validation. Proof-in-body changes are covered by #12479; FOCIL interaction remains in #12475 and networking in #12423.

@github-actions github-actions Bot added c-update Modifies an existing proposal s-draft This EIP is a Draft t-core labels Oct 9, 2026
@eth-bot

eth-bot commented Oct 9, 2026 •

Copy link
Copy Markdown
Collaborator

File EIPS/eip-8288.md

Requires 1 more review from Authors: @tcoratger, @vbuterin

Comment thread EIPS/eip-8288.md Resolved
Comment thread EIPS/eip-8288.md Outdated
- `proofs` = list of individual proof byte strings corresponding to each dependency in `deps`, in order
- `stark_proof` = a single recursive STARK proving validity of all deps, with public input `get_deps_hash(deps)`

A wrapper whose `deps` is empty must use mode 0, with an empty `proofs` list.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can deps be empty here? A dependency frame needs at least one triple.

Comment thread EIPS/eip-8288.md Outdated
4. The total number of deps is `<= MAX_DEPS_PER_AGGREGATE`, and the number with `LEANSTARK_SCHEME` is `<= MAX_LEANSTARK_DEPS_PER_AGGREGATE`

Each wrapper contains exactly one STARK in mode 1, and one STARK per leanSTARK dependency in mode 0. Per `AGGREGATION_INTERVAL`, a mempool node broadcasts exactly one wrapper containing all currently active transactions, with exactly one STARK covering all their dependencies.
Full wrapper validation in either mode requires resolving transaction hashes. After validation, admission is evaluated per transaction: rejection for current state, fees or local pool policy does not invalidate the proof or require rejecting other transactions.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does a node do when a hash entry doesn't resolve?

@Marchhill
Marchhill force-pushed the eip8288-bounded-batches branch from 25f340f to cd84517 Compare October 14, 2026 20:12
@Marchhill Marchhill changed the title Update EIP-8288: Define bounded mempool aggregation Update EIP-8288: Define bounded hash-only mempool wrappers Oct 15, 2026

@manusw7 manusw7 left a comment •

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The hash-only wrapper and the 96-byte scheme-bound digest read much cleaner. A few things:

  1. Unresolved hashes are free. An unresolved hash leaves the wrapper "incomplete, not invalid", and running out of budget abandons recovery without a penalty. A peer can send wrappers with self-signed sigs and random tx hashes and fill the recovery budget at almost no cost. Can we make non-delivery of listed envelopes a peer fault (or point normatively to EIP-8437 if that's where it lives), and cap incomplete wrappers per peer?
  2. No canonical leanSPHINCS witness length. Padded witnesses could be accepted by one verifier and rejected by another, and they also miss the keccak256(witness) cache. Fixing the length and rejecting others before verification closes both.
  3. Missing slot_number. The target fork estimate has no rule for a parent or head without slot_number (EIP-7843 activating in the same fork). Falling back to the head's fork in that case seems enough.
  4. "The transport's grace window" isn't defined or referenced anywhere.
  5. FOCIL section still has the proof inline (recursive_stark = [stark_proof, deps_hash]), which clashes with the header commitment and can't fit the 8 KiB IL limit. Mark it superseded by #12475?
  6. Zero data_hash. This branch dropped "an all-zero data_hash is reserved", which #12475 still has. I think it should stay.

@Marchhill Marchhill changed the title Update EIP-8288: Define bounded hash-only mempool wrappers Update EIP-8288: Define bounded complete mempool wrappers Oct 26, 2026
@Marchhill Marchhill closed this Oct 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

a-review Waiting on author to review c-update Modifies an existing proposal s-draft This EIP is a Draft t-core

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants