For the past couple of weeks, I and a couple of my team members have been diving into all things required to build a POC of based preconfirmations (EigenLayer, PBS, Based rollups & more). I guess it is obvious from this thread that based preconfirmations are a complex matter. We’d like to share our thoughts and further research avenues we ended up with.
Obstacle 1: How do you even talk with preconfirmers
Preconfirmations require the users to be able to discover upcoming preconfirmers and ask them to commit to a preconfirmation. As preconfirmers are validators: “You dont talk to them. They talk to you.”. Think of mev-boost and relays. Builders dont talk directly to validators, they tell their blocks to relayers and the relayers get asked by the validators for blocks. This adds security & privacy properties to the validator that [I guess] they would not want to lose.
So if users are to talk with validators for preconfirmations, a pull mechanism needs to be designed (similar to relays) for validators to pull preconfirmation requests and possibly honour them.
Obstacle 2: Who do you even talk to
Lets ignore the previous obstacle for a while. While the general thought process is one where the user connects to a preconfirmer - which preconfirmer exactly? One idea would be to talk with the next pre-confirmer available, but you are at the mercy of their response. What if this preconfirmer censors you or it is down? You can wait for a certain timeout and try the next one. And the next one. You get the idea. With every subsequent timeout you are getting worse UX.
Another approach would be to talk to the next X (lets say 16) preconfirmers in parallel and wait for the first commitment. This approach however is wasteful as all but one of these commitments will be used - and waste drives prices up.
Obstacle 3: Preconfirmations validity rules
Spoiler - we looked at PEPC for some inspiration and ideas for solutions. Preconfirmations look like a really good fit for the “generalized mev-boost” - PEPC. However, PEPC doc briefly mention something called payload template. While payload template likely makes sense in many use cases its details are going to be crucial for preconfirmations.
While many generalised use cases might require for a certain types of transactions to be a part of the transactions list, with based preconfirmation it is quite trickier. You need to enforce/validate that an L2 transaction is included in the sequencing transaction. This means a subsection of the calldata of a single transaction contains the pre-confirmed transaction.
Add to this:
- Data compression - so the payload is even harder to enforce
- Danksharding - what data… its not even here
- Unknown permissionless sequencer - “I dont even know who to expect the sequence transaction from”
- Complex sequencing pipeline through multiple contracts - “I need to look into the trace”
- More than one preconfirmation per sequence - order matters
In PBS world where the preconfirmers are separate from the block builders, the proposers would need a mechanism to pass very complex templates for builders to honour.
Some of our thoughts
These are just some of the nasty edge cases of the current state of preconfirmation and the hardship of their implementation in the current state of Ethereum.
Obstacle #1 lead us to think of an architecture looking like a generalized mev-boost. Fortunately EF researchers are some months (years? 
) ahead and PEPC is a generalized ePBS architecture. With PEPC architecture one can have a communication channel and validity rules in the protocol itself. Without PEPC numerous trust assumptions need to be introduced even if you are building a simple PoC.
Obstacle #2 leads us to think about the efficiency of talking to preconfirmers. Is it even viable to have preconfirmers? Various practical issues can lead to a worse UX for the user.
Obstacle #3 lead us to think about the complexity of enforcing sub-section of a transaction. A responsibility that will likely be passed to builders.
Research avenues
We believe that the following are research avenues that need to be further looked at to explore possible preconfirmations solutions.
- Intersection of pre-PEPC state of PBS (optimistic relay) and preconfirmations. Is optimistic preconfirmations-enabled relay feasible? Intersaction of pre-PEPC state of PBS with EigenLayer
- Current state of research for Inclusion lists and its ability to enforce transactions based on complex template - required for forcing inclusion of sequence transaction including one or multiple preconfirmations.
- How can a complex template be designed and implemented
- Based on the previous findings - how does one design based-preconfirmations