Quick follow-up note
It looks like the index-based solution would probably be the best way forward to:
- Avoid O(k²) verification costs for builders
- Keep FOCIL eligibility rules minimal and based only on VERIFY costs
As mentioned in the post, the index-based validation approach works like this: “The builder provides a tx hash and claimed index; attesters reconstruct state at that index using BAL (EIP-7928) or similar block-level access data and re-execute the validation prefix.”
The attack surface is bounded by the limited (VOPS) state that VERIFY frames can access: a builder would need to control accounts whose VOPS storage slots are read during VERIFY execution, which becomes increasingly impractical the more accounts the VERIFY frame depends on. The most realistic instance is when a builder is also the sponsor and drains the sponsor’s balance to invalidate a dependent transaction, only to refill it later in the same slot. But even then, the builder (being the payer) would lose reputation from doing this and wouldn’t be selected as a payer in the future.
Since builder-side verification cost is no longer the bottleneck, we could increase MAX_VERIFY_GAS_PER_INCLUSION_LIST to something like 2²⁰ gas. The worst case (16 ILs full of independent frame txs, each filling MAX_VERIFY_GAS_PER_INCLUSION_LIST) would then be 16 × 2²⁰ = 2²⁴, around 28% of the 60M total block gas limit.
Importantly, a 2²⁰ MAX_VERIFY_GAS_PER_INCLUSION_LIST limit would be high enough for transactions from privacy protocols to benefit from FOCIL’s censorship resistance guarantees. More generally, this opens up a separation between FOCIL inclusion eligibility and mempool admission rules: includer nodes could individually choose to join custom mempools (e.g., ones carrying privacy protocol transactions) and include those transactions in their ILs, even if the default public mempool does not carry them. This also means future mempool rules can evolve independently without requiring matching changes to FOCIL eligibility.
Thanks to @Nerolation and @vbuterin for helpful discussions and ideas on this!