Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA
Discussion topic for EIP-8369: VOPS Profiles for FOCIL Eligibility · Pull Request #12110 · ethereum/EIPs · GitHub
Abstract
This EIP describes two validity-only partial statelessness (VOPS) profiles for fork-choice enforced inclusion list (FOCIL) eligibility. Profile 1 covers regular transactions, every non-frame type without blobs, and keeps EIP-7805’s end-of-payload omission check. Profile 2 covers EIP-8141 frame transactions whose validation stays within a fixed account abstraction VOPS (AA-VOPS) state surface, including privacy transactions based on keyed nonces and recent roots. Profile 2 omission is checked at a builder-claimed transaction index in the payload, so it protects a transaction only if the transaction remains valid at every index the builder could claim. Transactions outside both profiles may still appear in inclusion lists (ILs), but FOCIL does not enforce them. Public mempool admission and FOCIL eligibility remain separate. This EIP is Informational; consensus enforcement belongs in an extension to EIP-7805.
Motivation
FOCIL (EIP-7805) requires builders to include IL transactions unless a missing transaction is invalid when appended to the payload or the payload does not have enough remaining gas to append it. That rule is cheap for regular transactions because the omission check depends mainly on gas, nonce, and balance. Frame transactions have programmable validation, so validity may also depend on keyed nonces, payer state, recent roots, or bounded account storage.
This EIP defines which transactions remain cheap enough to enforce. Profile 1 keeps EIP-7805’s end-of-payload rule. Profile 2 evaluates an omitted frame transaction at a builder-claimed index against a fixed validation state surface. Because the builder chooses the index, Profile 2 is weaker when another transaction can move a validation dependency within the block; Security Considerations defines that boundary.
FOCIL eligibility is not mempool policy. An includer may receive an eligible transaction through the public mempool, a custom mempool, or direct submission. The submission path affects whether a transaction reaches an IL, not whether its omission is enforceable.
1 post - 1 participant
Read full topic
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | EIP-8361: Transaction Validity Proofs | 0 | 19.28 | 04-08-2026 |
| 2 | EIP-8372: Normalized state gas limit | 0 | 10.94 | 06-08-2026 |
| 3 | EIP-0000 Preferential Gas Costs for Native ETH Operations – Draft for feedback | 0 | 13.65 | 05-08-2026 |
| 4 | EIP-8374: Persist Warm Access Sets Across Reverts | 0 | 9.96 | 07-08-2026 |
| 5 | EIP-8358 Net Gas Metering for Account Changes | 0 | 10.47 | 05-08-2026 |
| 6 | [Idea / Meta EIP] Protocol Maturity and Ossification Framework | 0 | 6.5 | 10-08-2026 |
| 7 | EIP-8037: State Creation Gas Cost Increase | 0 | 19.67 | 28-07-2026 |
| 8 | EIPIP Meeting #128, July 08, 2026 | 0 | 7 | 08-07-2026 |
| 9 | ERC-8100: Representable Contract State | 0 | 5 | 08-07-2026 |
| 10 | EIP-7906: Transaction Assertions via State Diff Opcode | 0 | 3 | 08-07-2026 |