Summary

The goals of this session are twofold:

1. Increase the understanding of the Fork-Choice enforced Inclusion Lists (FOCIL) design, especially given the new EIP-7805.
2. Surface initial thoughts from developers regarding the implementation of FOCIL in clients.

Facilitators: Julian Ma, Terence Tsao, and Barnabé Monnot. Note taker: Barnabé Monnot.

Agenda

• State of FOCIL (Julian; 30 minutes; slides)
  • What are FOCIL's design goals, and how does the mechanism work? How do the mechanism’s design parameters contribute to the design goals? These questions will be answered during the first presentation, where we will introduce FOCIL and explain what it does (and does not do).
• Development of FOCIL (Terence; 15 minutes; slides)
  • This presentation explores the implementation space of FOCIL. What changes need to be made to support FOCIL?
• Open Discussion (30 minutes)
  • Time is allocated to discuss the parts of FOCIL that the audience is most interested in. These subjects could include but are not limited to, deep-diving specific FOCIL design considerations, better understanding how FOCIL may be implemented, and exploring the design space of extensions that FOCIL unlocks.
• Closing Out (15 minutes)
  • We will summarize the session and aim to agree on the most important topics to focus on.

Session notes

Part 1: Julian presentation

• Potuz question on fork choice
  • Something missing from EIP (ask Fradamt)
• Does FOCIL enforce ordering?
  • No, if it enforces some ordering, then IL committee members have sway over ordering, and they get sophisticated, which we don’t want
• Interaction of equivocation and free DA
  • Attack: send IL to everyone, send another one to the block builder, so the builder ignores the IL and gets screwed
  • Defense: there is some time for the builder to distribute equivocating ILs
• What if you craft a transaction which invalidates another transaction?
  • Such a tx would have to come from the same account, and if there are reverts, it’s fine, it’s invalid transactions we care about
  • See also tx stuffing attack defenses.
  • In MEV-Boost context, builder knows they are the winning builder at the end of the slot, may need to prepare the attack much earlier than this…
• If there are only 16 proposers, couldn’t a large staking pool capture all 16 slots?
  • Probabilistically unlikely, but if it happens, you have some sort of power but can’t do much with it (see also tweet)
• Are ILs unattributable? Do we know who put what in which ILs?
  • There are other designs that have such properties, see anon-ILs.