Solutions to the Preconf Fair Exchange Problem


Solutions for dealing with the fair exchange problem in leader-based preconfirmation setups.

Reputation can incentivize preconfers to act honestly.

Alternatively, use order to dictate who gets the PER tip. One can invalidate a PER by sending it to a preconfer with higher priority.

Fair Exchange?

The fair exchange problem can be summarized as two untrusted players blindly giving up something in hopes that the other party will do the same. The goal is to try to find a method to ensure that both will cooperate. In the context of preconfirmations, the requesting party (gateway) has no guarantee that their preconfirmation enforcement request (PER) will receive a signed commitment. The preconfer has every right to not return a commitment, hold onto the PER until the last second, and include it if profitable (pocketing the tip for free).

Solution 1: Reputation

One solution to this is by tracking reputation. More specifically, leveraging the promise of future PERs to incentivize preconfers to respond promptly via either commitments or non-commitments (slash-able promises to NOT include). The gateway can throttle or simply ignore preconfers if they misbehave.

Reputation is a tried method and exists today in mev-boost relays (see Switchboard’s Sauna Appendix). While this might work, it still requires certain economic conditions for security. If for whatever reason it becomes really profitable to behave dishonestly, the guarantees fall apart.

Can we do better?

In an ideal scenario, without any limitations of technology, one would simply invalidate the PER if the preconfer takes too long to respond. With blockchains, this is complicated, and time-based approaches require some sort of additional consensus, breaking the based paradigm. However, we can indirectly access “time” by using order. Blocks are ordered, so preconfers can be as well. If we take advantage of this, we arrive at a new solution that avoids the Fair Exchange problem altogether.

Solution 2: Last Right

Determine an order for preconfers. This can be done per block (or even intra-block). Send the PER optimistically to the first preconfer. If they commit, then great. If they return a non-commitment, or do not respond, then send the PER to the next preconfer.

But wait, they can still include my PER and pocket my tip! Yes, they can but they won’t be able to keep the tip. This is due to the central idea of this solution: the last preconfer to include the PER has the right to the tips. If two preconfers attempt to include the PER, the second preconfer has the right to the preconf tip. For example, the last preconfer submits a proof and transfers the PER tip to their balance. Other mechanisms are also possible and should be explored.

One consideration here is the cost. If claiming the tip is more expensive than the tip itself, then the model falls apart. The good news is this cost is directly tied to the technology and should decrease exponentially (e.g. zk proof). Preconfirmation tips on the other hand are tied to the value of the transaction itself, which is not as dependent on the tech. So perhaps this mechanism will become more and more economically favorable.

One great side effect of this method is that it preserves the possibility of execution promises. If the first preconfer acts honestly, then it can guarantee the execution state for the PER. Execution guarantees fall apart if there’s any dishonesty (same as Solution 1).

Solution 3: First Right

If we are willing to forgo execution promises, then the gateway can instead request commitments from preconfers in reverse order. Forward the PER to a preconfer down the list, and then move up until one commits. The first preconfer to include the PER gets the tip. In the case where L1 proposers are preconfers, this is enforced by the L1 replay protection. This is a much simpler version of Solution 2.

One downside is the “real” latency before the transaction is actually included since the default preconfer is not the current one. But one could argue that for important transactions where L1 settlement is important (e.g. buying a house), preconfirmations in general are probably not a priority.

Note that execution promises are technically still possible if all the state transitions up to the point of inclusion has already been determined. (e.g. All block space has already been filled by PERs or similar.)

Final Thoughts

We can even perhaps use these Solutions in tandem. For smaller preconf tips, we can rely on Solution 1, let the first preconfer pocket it and “slash” their reputation. For larger preconf tips, we can fallback to Solution 2 and let the next preconfer steal it back. Or just use them at the same time.

Thanks to @mteam for getting me up to speed and providing feedback. We at Spire Labs are actively researching preconfirmations and related topics, and building towards a better, unified Ethereum.