Un-confirming “Pre-confirmations”

On this episode of myth busters...

If you’ve followed Ethereum scaling conversations recently, you’ve probably noticed an uptick in discussions about “pre-confirmations”. This is the oft-proposed solution to Ethereum’s latency dilemma - reducing latency generally requires an increase in hardware requirements and so lighter weight solutions are desirable.

It’s proponents argue that validators will commit to including transactions before consensus is global consensus is reached on them - allowing for low latency guarantees in only one round of communication. If the validator commits, but does not include these transactions than the commitments can be used to slash their collateral. As such validators can give lighter-weight, lower-latency inclusion guarantees backed by economic stake.

But what it’s proponents typically fail to do is present a good mechanism that actually accomplishes this functionality. If you haven’t been able to tell yet, this post will argue that there is none !

Problem Setting

Much of the time the topic of pre-confirmations is paired with conversations around based sequencing - rollups which are permissionlessly sequenced by Ethereum validators - but there is actually no reason for the conversation to be restricted to just this. Blocks of rollup transactions are just normal transactions from the perspective of the Ethereum Virtual Machine. Because of this we will focus on a model that considers pre-confirmations for arbitrary transaction types, since clearly this generalizes to rollup blocks.

Suppose there is a user and a validator.

In an ideal pre-confirmation system, the user would immediately know the resulting state from their transactions. To show why this is useful, consider a market maker who is thinking of establishing shop on your newly pre-confirming chain. The market maker cares about pre-confirmations because reducing latency allows them to better manage risk - one such example is inventory risk. The sooner market makers know the state from recent transactions, the sooner they know their resulting inventory - allowing them to quickly update their quote sizes, spread and hedging positions in response.

Hint for later : We also know this property is holds in sequencing via global-consensus as it’s roughly the definition of ‘safety’ - every honest party agrees on the state of the blockchain.

But let’s say this desirable property was impossible and we are happy to settle for a weaker, but still useful property - as soon as the validator receives a transaction they commit to the ordering. In the context of the market maker story, the market maker might not know the state, but they can feel comfortable that a first-come-first-serve system is in play. This is particularly useful when it comes to the risk of adverse selection since shorter gaps between transactions means less time for price to drift and thus smaller bounties for arbitrageurs when their cancel orders can’t make it in time.

Clearly both of these properties require the validator to immediately commit to a strict-ordering for pre-confirmed transactions. With the ideal scenario having the added requirement that the transaction contents and orderings are broadcasted right away.

Unfortunately neither of these is possible in the single validator model.

Proof Sketch

Assume a validator has committed stake to some pre-confirmation system.

They can make strictly more value by delaying the confirmations until the last possible moment but staying true to them afterwards.

This delay is an undetectable fault since latency isn’t deterministic.

And so the rational behavior is to not immediately confirm transaction orderings.

Discussion

And… wah lah… we have a “proof” (however informal it might be).

I see this as pretty devastating to any useful notion of single-validator, pre-confirmations since it basically says the incentivized behavior is the default behavior of network - order at the last second - but with the added psyop that something special is going on (“pre-confirmations”).

Now you might be asking yourself :

“Ha Elijah, I caught you slacking! You forgot about the scenario where the pre-confirmation system wasn’t reliant on a single validator who had unilateral power over the ordering.”

Well I’d respond :

“So reader, you want a system where multiple parties contribute-to the pre-confirmed transaction ordering? In that case they’d probably have to agree on that ordering to avoid giving conflicting confirmations.”

And you respond :

“Yes exactly.”

…

Well that’s exactly what consensus is - a bunch of participants coming to agreement over the transaction ordering. And so we’re back to square 1.

Disclaimer and Final Notes

I’m often wrong. So if you have any thoughts or comments feel free to reach out and continue the discussion !