Repository navigation
Conversation
github-actions
Bot
added
c-update
File
|
|
|
||
| ### Profile 2 inclusion claims and per IL budgets | ||
|
|
||
| This section extends the rules above for the eligibility profiles of [EIP-8369](./eip-8369.md), and applies only when [EIP-8141](./eip-8141.md) is active. Otherwise the verdict is decided by the rules above alone. The membership bits and the claim list are carried in either case; without EIP-8141 there are no Profile 2 candidates, so neither changes the verdict. Profile 1, Profile 2, Profile 2 candidate, the static budget fill, `MAX_VERIFY_GAS_PER_IL` and the attester replay are as defined in EIP-8369. Omission of a Profile 1 transaction is decided by the end of payload check above, with the Profile 1 conditions of EIP-8369. Omission of a transaction outside both profiles is excused. |
There was a problem hiding this comment.
eip-8369 is informational and leaves MAX_VERIFY_GAS_PER_TX and AA_VOPS_SLOT_COUNT unset, and MAX_VERIFY_GAS_PER_IL is a candidate value there. should this section fix the values and restate the profile 2 predicates, so clients classify the same transactions?
There was a problem hiding this comment.
Done in 5f2193d: constants table (2**20 per IL, 2**18 per tx, 4 slots, 2**12 claims) and the Profile 2 candidate/eligibility checks and replay restated as named predicates; one-line rationale per value.
|
|
||
| #### VERIFY budget | ||
|
|
||
| The execution layer applies the EIP-8369 static budget fill to each committee position independently, with a budget of `MAX_VERIFY_GAS_PER_IL` per position, over the transactions whose bit is set at that position, in the fill order of EIP-8369. Each transaction is charged once per position. There is no budget shared across positions, so an IL whose candidates exceed the budget affects only the fill of its own position. |
There was a problem hiding this comment.
get_inclusion_list_committee can give one validator several positions on a small validator set, so its one il gets a budget per position. is that intended, or should the budget be per il as in eip-8369?
There was a problem hiding this comment.
Duplicate positions have identical bits, so identical fills; the IL is effectively budgeted once. Noted in c4d5f90.
|
|
||
| The execution layer applies the EIP-8369 static budget fill to each committee position independently, with a budget of `MAX_VERIFY_GAS_PER_IL` per position, over the transactions whose bit is set at that position, in the fill order of EIP-8369. Each transaction is charged once per position. There is no budget shared across positions, so an IL whose candidates exceed the budget affects only the fill of its own position. | ||
|
|
||
| Omission of a Profile 2 candidate `T` is excused under a position whose bit is set for `T` unless that position's fill admits `T` and `T` passes the EIP-8369 attester replay at its evaluation index. Omission of `T` is excused if and only if it is excused under every position whose bit is set for `T`. Since the replay does not depend on the position, omission of `T` is unjustified if and only if some position admits `T` and `T` passes the replay at its evaluation index. |
There was a problem hiding this comment.
the eip-8369 replay uses one number for the gas remaining (block gas limit minus cumulative gas used before the index). with eip-8037 the fit check is per dimension, execution and state. which totals at the evaluation index should clients use here?
There was a problem hiding this comment.
Agreed. "Fits" is now the EIP-8037 per-dimension check (EIP-8141's for frame txs) against execution and state gas used before the index, for both the base end-of-payload check and the Profile 2 replay (5f2193d).
|
|
||
| ### Profile 2 claims and budgets | ||
|
|
||
| A claim only changes the verdict on the committing builder's own payload. The cap on claims only limits the builder: an unclaimed candidate is evaluated at the end of the payload, which is its verdict without claims. The builder chooses the index, so a Profile 2 transaction is protected only if it stays valid at every index the builder can claim, as described in EIP-8369. |
There was a problem hiding this comment.
each distinct claimed index may need its own state rebuild on the attester side. was 2**10 sized against replay time before the attestation deadline, or only against envelope size?
There was a problem hiding this comment.
Replay cost is independent of the cap: each admitted omitted candidate is replayed once, claimed or not, and indices read from the BAL without per-index rebuilds. Cap is now 2**12 so a builder can always claim every candidate 16 × 8 KiB ILs can hold (≥48 B each ⇒ <2,730); ≤160 KiB of envelope (5f2193d).
…n and claim guidance
Marchhill
changed the title
…nclusion checks Brings Profile 2 and the Bogota engine API to ethereum/EIPs#12394 and #12396, ethereum/execution-apis#911, ethereum/consensus-specs#5698 and ethereum/execution-specs#3777. - engine_newPayloadV6 and engine_newPayloadWithWitnessV6 take one inclusion list per committee position and omissionClaims {transactionHash, evaluationIndex}, replacing the flat list and its membership bitvectors. Each list is checked against its byte cap before deduplication; malformed lists or claims answer -32602. - Inclusion is checked apart from execution. A VALID payload is answered at once with inclusionCheckId and the check's verdict, null while it is pending; engine_getInclusionListVerdictV1 polls it and answers -38007 for an unknown check. A check that cannot be decided is forgotten, not completed. - engine_forkchoiceUpdatedV5 takes PayloadAttributesV5.inclusionLists and returns PayloadStatusV1. The retained-list answers and the queued-copy tracking kept for per-call lists are removed. - engine_getPayloadV7 returns omissionClaims; the builder fills each list's VERIFY budget separately. - The VERIFY fill runs per committee position over the separate lists. - The pipeline records the gas used before each transaction whenever Profile 2 is active, for claims judged after execution. - MAX_INCLUSION_LIST_CLAIMS is renamed MAX_OMISSION_CLAIMS.
Replace the original append-at-end steps with the Profile 1 and 2 rules, keep checks pending when local data is missing, rename IL constants to match the specs, define the IL byte limit by envelope bytes and fix a typo.
|
Rule 2 rejects a later frame only when its mode is |
Defines Profile 2 omission claims, independent per-IL VERIFY budgets and indexed prefix replay alongside Profile 1, with joint FOCIL/frame activation. EIP-7805 owns the binding rules.
A VALID newPayload response includes a completed inclusion verdict; no context ID or polling endpoint is needed. Unavailable verdicts cannot authorize extending the payload. Clarifies replay code bounds, recent-root limits and re-execution costs; full-pipeline latency benchmarks remain an activation prerequisite.
Companions: #12396, ethereum/execution-apis#911, ethereum/consensus-specs#5698, ethereum/execution-specs#3777.
EIP-8288 coordination (#12475): signed ILs must authenticate their dependency proof, and versioned Engine interfaces must carry a nullable proof per list with committee-wide bounds. This additional change needs CL agreement and is not implemented by the current frames/FOCIL companion APIs.