Repository navigation
Conversation
github-actions
Bot
added
c-update
File
|
Marchhill
changed the title
|
|
||
| To enforce this per list, the activating fork must define Engine API versions for payload validation and building that carry each counted inclusion list's `[transactions, recursive_stark]`, preserving its authenticated committee-position association and EIP-7805's membership and committed claims. Existing method versions retain their encodings. The execution layer checks each list's dependency proof and derives obligations per list. The consensus layer cannot instead drop lists with failed proofs: checking `deps_hash` requires parsing transactions, and dropping a whole list would remove obligations for its dependency-free transactions. | ||
|
|
||
| For a transaction imposing an inclusion obligation, omission is permitted only when EIP-7805 excuses it or `dependencies_fit_block(dependencies(block) + dependencies(tx))` is false. Capacity is evaluated against the complete final block dependency union, including when EIP-7805 evaluates transaction validity at an earlier index. Dependencies already present in the block consume no additional capacity. Local mempool limits, proving time, proof retention or aggregation scheduling are not additional omission grounds. |
There was a problem hiding this comment.
Can 16 list proofs plus one wrapper proof be merged in time, given leanVM takes at most 16 children per step?
2050668 to
5a4206f
Compare
|
|
||
| The weights and unit budget are provisional, pending worst-case circuit benchmarks for the activated verification profiles, memory use and slot deadlines, including recursive merges and discards needed for IL obligations. The activating fork must fix them together with gas pricing; clients must not choose weights or capacity from local measurements. They are consensus capacity units, not an additional gas charge. | ||
|
|
||
| The circuit identified by `AGGREGATED_VK` must support every valid block dependency set within both bounds. Its separate private-input and verification-work limits still apply. Local proving budgets and mempool policy do not reduce block capacity and are not grounds for omitting an inclusion-list transaction. |
There was a problem hiding this comment.
Should the private-input bounds be required to cover the discards from pruning one IL's proof? Otherwise a builder could be obliged to include a tx it can't prove.
Marchhill
changed the title
Marchhill
changed the title
Co-authored-by: Stefano De Angelis <29693466+deanstef@users.noreply.github.com>
| Inclusion-list creators SHOULD reserve a share of the transaction-byte allowance for dependency-bearing transactions. | ||
|
|
||
| The recursive STARK scheme is compatible with the consensus layer's use of Lean Ethereum tooling. The same STARK backend and verification infrastructure can be used for both consensus layer signature aggregation and execution layer dependency verification. Inclusion lists (ILs) are just a different kind of package of transactions (like blocks) and use the same signature schemes as other components; no new signature scheme is required specifically for ILs. | ||
| Inclusion-list Engine API inputs and results carry `recursiveStark: {starkProof: DATA, proofDeps: DATA[]}` per list. Each dependency is 96 bytes; an empty proof is `"0x"` with `[]`. The CL passes the signed proof bytes unchanged, including invalid proofs, for EL evaluation. No additional methods are introduced. Signing, gossip, deadlines and equivocation otherwise follow EIP-7805. |
There was a problem hiding this comment.
[MEDIUM] Per-list Engine fields need new method versions
EIP-7805's Engine API passes ILs flattened: newPayload takes inclusionListTransactions: DATA[], payload attributes carry the same flat list, and getInclusionList returns transactions only. A per-list recursiveStark has nowhere to go in those shapes, so "No additional methods are introduced" cannot hold. Nethermind's prototype had to add engine_newPayloadV7, PayloadAttributesV6 and engine_getInclusionListV2 with an InclusionListV1 {transactions, recursiveStark} array. Please specify the replacement parameter (array of per-list objects in place of the flat list), which method versions carry it, list order, and that equivocators' lists are excluded by the CL before the call.
| ```python | ||
| class InclusionListProof(Container): | ||
| stark_proof: ByteList[MAX_IL_PROOF_BYTES] | ||
| proof_deps: List[ByteVector[96], MAX_IL_PROOF_BYTES // 96] |
There was a problem hiding this comment.
[MEDIUM] Dependency capacity of an IL proof is unspecified
The SSZ bound allows ~13.6k proof_deps, but the statement size a proof under AGGREGATED_VK can carry is set by the circuit, which the EIP does not state. Obligations depend on it: Nethermind treats a list with more than 256 proof_deps (its pinned guest limit) as having no verified proof, so its dependency-bearing entries do not bind. Two clients with different assumptions disagree on INCLUSION_LIST_UNSATISFIED. It also leaves builder cost for surplus dependencies unbounded in practice (in-circuit hashing and discards of up to 1.25 MiB of deps per list, paid by nobody who signed it). Suggest a protocol constant for the max dependencies per recursive statement, applied to proof_deps.
| - Mempool nodes can recursively aggregate proofs without understanding transaction semantics. | ||
| - The scheme does not introduce new centralization pressures beyond those already present in FOCIL. | ||
| - The bandwidth overhead of recursive STARKs is constant per peer, regardless of the number of transactions. | ||
| For hypothetical inclusion checks, covered dependencies are treated as satisfied without requiring them in the existing block proof. Inclusion-list proofs may cover surplus dependencies; wrapper and block proofs MUST cover their exact transaction dependency unions. Builders discard surplus input dependencies during aggregation. |
There was a problem hiding this comment.
[LOW] Undefined terms
- "hypothetical inclusion checks": EIP-7805 calls this the check that a missing transaction is invalid when appended to the payload. Use that wording.
- "noncanonical dependencies" (line 322): define it (96-byte encoding, padding, sorted strictly ascending).
- "invalid entry" (line 331): name the predicate (EIP-8141 static validity under the target fork).
- Line 324 distinguishes EIP-7805's "list size limit" from the "transaction-byte limit", but EIP-7805 has one constant,
MAX_BYTES_PER_INCLUSION_LIST, over the RLP transactions. Name the constant and say which bound the extraMAX_IL_PROOF_BYTESapplies to.
# Conflicts: # EIPS/eip-8288.md
# Conflicts: # EIPS/eip-8288.md
Keeps proofs inside signed inclusion lists. Defines per-entry obligations, empty/invalid proof handling, superset reuse, a provisional 1.25 MiB proof-extension bound and per-list Engine fields. Transaction bytes retain EIP-7805's existing limit; the proof bound requires dissemination, verification and aggregation benchmarks.
Builds on #12590 and #12479. FOCIL-only diff: 29 added lines, 39 removed. The previous commitment design remains separate.
Validation: EIP/Markdown lint passes. Cryptographic execution, CL/Engine integration and performance benchmarks remain outstanding.