For millennia, auctions have been humanity’s go-to tool to answer a timeless question: “What’s this worth?”. Hundreds of thousands of auctions occur every split second across the Internet, fuelling the digital ad economy.
Similarly, auctions are everywhere in the blockchain world:
- Flashbots' MEV-Boost conducts auctions between block builders and proposers, constituting over 90% of all Ethereum blocks.
- CowSwap, UniswapX, dYdX, and other intent-based systems use order flow auctions to optimize transaction settlements.
- MakerDAO, Aave, and other on-chain lending protocols rely on auctions for liquidation.
- Espresso auctions shared sequencing rights for multiple L2s.
- RollupBoost and TimeBoost use auctions to order L2 blocks.
- Proof markets, oracles, NFT marketplaces, and other on-chain marketplaces use auctions to price the resource.
Auctions dynamically price internal (storage, compute, data availability, sequencing) and external (order flow, proofs, collateral positions) blockchain resources.
Blockchains rely on consensus to establish a global order of transactions. In our previous blog post, we showed that this global ordering is not only slow but also unnecessary for payments. For auctions, the situation is even more problematic—blockchain systems simply cannot run fast auctions.
Blockchains Are Not A Good Fit For Auctions
Meet Bob. Bob wants to sell a family heirloom—a rare gemstone he recently found in his grandmother’s closet. To do so, he uses a blockchain. Bids are collected in a smart contract until a specific deadline. Once the deadline passes, the highest bid wins, and the rare gem finds its new owner. Bob expects collectors worldwide to flock to his auction. Yet, lurking in the background is evil Eve, who has other plans:
1. Eve bribes the underlying blockchain's block proposers to censor all bids from other participants until the deadline. She then submits a bid of zero and walks away with the gem for free:
2. Alternatively, Eve waits until all other bids are in. Just before the deadline, she pays off the block proposer to slip in her bid that is a tiny bit higher than the highest offer, ensuring she wins. This is referred to as the last-look attack:
Both tactics—censorship and last-look—allow Eve to manipulate the outcome for her profit.
The root of these vulnerabilities lies in the leader-based architecture of blockchains. For each slot, blockchains elect a leader—a validator with sole authority to propose the next block. This leader has considerable power, capable of censoring, reordering, or selectively adding transactions. The risk intensifies in Layer 2s (L2), where a single sequencer is the block proposer for extended periods.
To make matters worse, unlike other faults, censorship is not accountable. A leader can censor transactions with no punishment (e.g., slashing).
Wouldn’t censoring break the liveness of the blockchain? Not necessarily! On Layer 1 (L1), the system guarantees that an honest leader who won’t censor transactions will eventually be elected. However, this could take multiple blocks—or worse, it may never happen if leaders act rationally, as they can be bribed to censor without being held accountable. Similarly, for L2s, forced inclusion mechanisms exist, but they can take up to 24 hours to kick in.
For most of the interesting use cases mentioned above, such as MEV and order-flow auctions, the auction protocol needs to be at least as fast as block creation since auction results influence the ordering within the block. Therefore, the blockchain's liveness guarantee is not sufficient.
For an in-depth comparison of several state-of-the-art consensus protocols (such as Hotstuff-2 and DAG-based protocols) regarding censorship resistance and liveness guarantees, check out our collaborative work with Flashbots and Common Prefix.
Set of Bids is All You Need
Let’s think of a perfect auction system as a black-box. Such a system would allow two operations: (i) submit bid and (ii) get auction result. We would like all bids submitted before the deadline to be considered. The set of bids submitted before the deadline suffices to determine the auction result. Anyone interested in the auction result can then take this set and compute the outcome independently.
For example:
- Alice bids 10 BTC, Charlie bids 15 BTC, and Dave bids 12 BTC.
- The system would output
{(Alice, 10), (Charlie, 15), (Dave, 12)}. - Bob can then take the bid set and locally compute the winner
(Charlie, 15 BTC).
Note that the auction result remains the same, regardless of the order in which bids arrive. We only care about the bid set itself, not the sequence of bids.
This observation makes existing blockchains and consensus protocols a bad fit for auction systems. In our previous post, we explained that consensus protocols' sole purpose is to take transactions and output them in a globally agreed-upon order. Achieving this order requires several network round trips of communication among validators—a slow and expensive process. For auctions, we don't need this ordering, so why incur the cost?
We can simplify the operations needed for the auction system further: (i) submit bid and (ii) get the set of bids. We would like such a system to have the following properties:
- Liveness: All bids submitted before the deadline must be included in the bid set.
- Safety: Any bids submitted after the deadline must be excluded from the bid set.
Such a system can be easily built using a trusted third party that collects bids until a deadline and then returns the set of all bids it has seen so far. However, achieving this in a decentralized system is far more challenging. How can we fairly determine when the deadline has been reached and which bids were submitted before the deadline? Two honest servers in different parts of the world might see a transaction at different times or have slightly misaligned clocks. There's no universally agreed-upon global clock!
Let’s slightly relax our requirements:
- Liveness: All bids submitted before the deadline $t_0$ must be included in the bid set.
- Safety: Any bids submitted after the deadline $t_1$ must be excluded from the bid set.
- $t_1 - t_0$ is small (comparable to network delay)
Allowing for a small wiggle room in the deadline makes it feasible to realize such a decentralized system.
In our subsequent posts, we will explore how pod can be used to implement such a system. pod is leaderless, consensusless, and blockless—avoiding the pitfalls of traditional blockchains while achieving Byzantine resilience similar to other Proof-of-Stake chains.
With auctions built on pod, users can submit their bids in a single network round trip, and auctions can be completed in under a second. The auction logic is programmable at the smart contract layer. Moreover, any Byzantine behavior, including censorship, is accountable and subject to slashing.
Get ready for light-speed auctions on pod; you are about to travel through time.
By the way, if this sounds interesting to you, we are hiring.
Acknowledgments
We thank Noah Citron, Guy Wuollet, and Wei Dai for their valuable feedback.