Author: Pranav Garimidi, Joachim Neu, Max Resnick, a16z crypto researchers; Source: a16z crypto; Translated by: Shaw Jinse Finance

Today’s blockchain can confidently claim to possess the processing power necessary to compete with existing financial infrastructure. Current production environment systems can handle tens of thousands of transactions per second, and future performance will see order-of-magnitude improvements.

However, beyond sheer throughput, financial applications also require predictability. When a transaction is initiated—whether it is a trade, a bid, or an options exercise—reliably ensuring the time for transaction confirmation on-chain is crucial for the normal operation of the financial system. If transactions face unpredictable delays (whether due to malicious interference or incidental circumstances), many applications will be rendered unusable. For on-chain financial applications to be competitive, blockchains must provide short-term guarantees for transaction confirmation: once a valid transaction is submitted to the network, it must be guaranteed to be included in a block as quickly as possible.

Take on-chain order books as an example. An efficient order book requires market makers to provide liquidity by continuously placing orders to buy and sell assets. The core challenge facing market makers is to minimize the bid-ask spread (the difference between buying and selling prices) while avoiding adverse selection risks due to disconnection from market prices. To achieve this, market makers must constantly update orders to reflect the latest market conditions. For instance, when the Federal Reserve announces a change that causes significant price fluctuations, market makers need to immediately update orders to new prices. In this case, if the transaction used by the market maker to update the order cannot be confirmed on-chain immediately, arbitrageurs will execute trades at outdated prices, causing them to incur losses. Market makers would then be forced to widen the spread to mitigate such risks, which in turn diminishes the competitiveness of on-chain trading platforms.

Predictable transaction confirmation mechanisms can provide reliable guarantees to market makers, enabling them to respond quickly to off-chain events and maintain the efficient operation of on-chain markets.

The Gap Between Current Status and Demand

Currently, existing public chains can only provide relatively reliable finality guarantees on the scale of seconds. This level of assurance is sufficient for payment applications, but it falls far short for many financial applications that require real-time responses from market participants. In the aforementioned order book scenario: for market makers, if an arbitrageur’s transaction can be prioritized into an earlier block, then the guarantee of “finality within seconds” is meaningless. Lacking strong guarantees for on-chain confirmation, market makers can only hedge higher adverse selection risks by widening the spread and offering worse quotes to users. This decreases the attractiveness of on-chain trading compared to other venues with stronger guarantees.

If blockchains are to truly realize their vision of becoming modern infrastructure for capital markets, developers must address these issues to allow high-value applications like order books to flourish on-chain.

Where Does Predictability Become Difficult?

Strengthening transaction confirmation guarantees on existing public chains to support such financial scenarios is extremely challenging. Currently, some protocols rely on a single node (the “block-producing node”) that decides which transactions can be included within a specified time. While this design reduces the engineering difficulty of building high-performance public chains, it also creates potential economic monopolies—block-producing nodes can capture value. Generally, during the window in which a node is selected as the block producer, it has absolute control over which transactions are included in the block.

For public chains that support various financial activities, the block-producing node holds a privileged position. If that node refuses to include a certain transaction, the user’s only option is to wait for the next block-producing node willing to include that transaction. In permissionless networks, block-producing nodes inherently have the incentive to extract value, commonly referred to as miner extractable value (MEV). MEV is far more complex than simply performing sandwich attacks on AMM trades. Even if a block-producing node merely delays including a transaction by a few tens of milliseconds, it can reap enormous profits and significantly reduce the operational efficiency of the underlying applications. If the order book prioritizes only certain traders’ transactions, it is unfair to all other participants. In extreme cases, malicious behavior by the block-producing node could even lead traders to entirely abandon the platform.

For example: when the Federal Reserve announces an interest rate hike, the price of ETH drops 5% in an instant. All market makers on the order book hurriedly cancel existing orders and submit new orders at the updated prices. Meanwhile, all arbitrageurs submit transactions attempting to sell ETH at outdated orders. If this order book operates on a protocol that employs a single block-producing node design, that node wields significant power. It can directly choose to censor all market makers’ cancellation transactions, allowing arbitrageurs to earn substantial profits; or it could opt to only partially censor cancellations, delaying processing until the arbitrageurs’ transactions are confirmed on-chain before releasing them; the block-producing node could even insert its own arbitrage transactions, profiting fully from price discrepancies.

Two Core Demands: Censorship Resistance and Transaction Privacy

Faced with this privileged position, market makers will find participation unprofitable—any price fluctuation makes them vulnerable to exploitation. The problem essentially arises from the excessive privileges held by the block-producing node in two areas: the block-producing node can censor any trader’s transactions; and the block-producing node can view others’ transactions and use that information to submit its own counter transactions. Either of these issues can lead to disastrous consequences.

Example Explanation

We can clearly illustrate the problem with a case. Assume there are two bidders in an auction: Alice and Bob, and Bob happens to be the block-producing node for the auction’s block. (The choice of only two bidders is for simplicity; this logic applies to any number of bidders.)

The auction accepts bids during the block generation period, set from t=0 to t=1. Alice submits her bid bA at time tA, and Bob submits his bid bB at time tB (tB > tA). Since Bob is the block-producing node for that block, he can always ensure that his bid is the last one placed. Both Alice and Bob can read the continuously updated true asset price (for example, the mid-price of a centralized exchange). Let’s assume at time t, the price is pt, and we assume that at any time t, both parties expect the asset price at the end of the auction (t=1) to equal the current pt. The auction rules are simple: the higher bid wins and is executed at that bid.

The Necessity of Censorship Resistance

Now let’s see what happens when Bob exploits his advantage as the block-producing node. If Bob can censor Alice’s bid, the auction mechanism will fail directly. He only needs to bid an extremely low price to secure victory, as all other bids are blocked. This would lead the auction’s final yield to be nearly zero.

The Necessity of Transaction Privacy

A more complex scenario arises when Bob cannot directly censor Alice’s bid, but can see her bid before placing his own. In this case, Bob will adopt a simple strategy: when bidding, he will check whether the current price ptB is higher than bA. If it is, he will bid slightly higher than bA; if not, he will refrain from bidding.

Through this strategy, Bob will continuously expose Alice to adverse selection. Alice can only win if her bid exceeds the expected value of the asset after the price updates. Each time she wins the auction, she expects to incur a loss, ultimately resulting in her opting out of future bidding. Once all competitors have exited, Bob can bid an extremely low price to win the auction, making the auction’s yield zero.

The core conclusion of this case is: the duration of the auction is irrelevant. As long as Bob can censor Alice’s bid, or see her bid before placing his own, the auction is bound to fail.

This logic applies equally to all scenarios of high-frequency asset trading, including spot trading, perpetual contracts, and derivatives exchanges: if there exists a block-producing node with the same power as Bob in the example, the entire market mechanism will collapse. To make on-chain products serving such scenarios viable, we must not grant block-producing nodes such privileges.

How Do These Issues Arise in Practice?

The above description paints a grim picture for any on-chain trading that adopts a permissionless single block-producing node protocol. However, many decentralized exchanges (DEXs) operating on such protocols still perform well; what is the reason behind this?

In practice, two forces have countered the aforementioned issues:

• Block-producing nodes have not fully abused their economic privileges, as they typically have significant stakes in the success of the underlying public chain;

• Various applications have constructed workaround solutions to reduce their vulnerability to such issues.

Although these two factors have thus far allowed decentralized finance (DeFi) to function, they are not enough to enable on-chain markets to truly compete with traditional off-chain markets in the long term.

On a public chain with significant economic activity, obtaining block-producing qualifications requires staking a large number of tokens. Thus, block-producing nodes either hold substantial collateral themselves or possess enough reputation to have other token holders delegate their staking rights to them. In either case, large node operators are typically public entities, facing reputational risks. Beyond reputation, the collateral they hold also means they have economic incentives to promote the public chain’s positive development. This is why we have not seen block-producing nodes abuse market power as described above—however, this does not mean these issues do not exist.

On one hand, relying on social pressure and long-term interests to constrain the goodwill of node operators is not a reliable foundation for the future financial system. As on-chain financial activities scale up, the potential profit space for block-producing nodes will also grow. The greater this potential, the more difficult it becomes to constrain block-producing nodes through social means and compel them to act against short-term interests.

On the other hand, the extent of block-producing nodes abusing market power varies continuously, from mild behaviors to complete market destruction. Node operators can gradually test the waters unilaterally, using their power to gain higher returns. When certain operators consistently push beyond acceptable behavioral boundaries, other nodes will quickly follow suit. While the behavior of a single node may seem limited in its impact, the consequences become significant when everyone begins to imitate.

The most illustrative example of this phenomenon may be the timing game: block-producing nodes will delay announcing blocks as much as possible while ensuring that the block remains valid within the protocol to earn higher rewards. This will lead to extended block times, and if nodes are overly aggressive, blocks may even be skipped. Although the profitability of such strategies is well-known, block-producing nodes initially chose not to participate in such games mainly to maintain the image of good governance for the public chain. However, this social balance is very fragile. Once a node operator begins to adopt such strategies to gain higher returns without facing punishment, other nodes will quickly follow.

The timing game is just one example of how block-producing nodes can increase returns without fully abusing their power. They can also employ many other methods to enhance their returns at the expense of applications. Viewed in isolation, these measures may still fall within acceptable limits for applications, but they will eventually reach a critical point where on-chain operating costs exceed gains.

Another factor sustaining the normal operation of DeFi is that applications move core logic off-chain, only submitting results on-chain. For example, all protocols that require rapid auction execution opt to perform them off-chain. Such applications typically run on a set of permissioned nodes to avoid issues posed by malicious block-producing nodes. For instance, UniswapX executes its Dutch auctions for trade matching off-chain on the Ethereum mainnet, and Cowswap likewise runs batch auctions off-chain.

While this approach ensures the operation of applications, it places the core value proposition of the underlying public chain and its on-chain constructs in a precarious situation. If the execution logic of applications is entirely off-chain, the underlying public chain will merely become a settlement layer. One of DeFi’s core advantages is composability, and in a world where all execution occurs off-chain, these applications will naturally exist in a fragmented environment. Relying on off-chain execution also introduces new prerequisites to the trust model of these applications: they not only need the underlying public chain to function properly, but must also depend on the availability of off-chain infrastructure to work correctly.

How to Achieve Predictability

To address these problems, protocols need to meet two key characteristics: stable transaction confirmation and sorting rules, as well as privacy protection prior to transaction confirmation.

Core Requirement One: Censorship Resistance

We summarize the first characteristic as short-term censorship resistance. If a protocol possesses short-term censorship resistance, then any transaction that reaches an honest node can be guaranteed to be included in the next available block.

Short-term Censorship Resistance: Any valid transaction delivered on time to any honest node must be included in the next block.

More precisely, we assume the protocol operates on a fixed clock, with blocks generated at fixed intervals, for example, every 100 milliseconds. Therefore, we need the following guarantee: if a transaction arrives at an honest node at 250 milliseconds, it must be included in the block generated at 300 milliseconds. Attackers should not have the power to arbitrarily filter transactions, selectively include or exclude certain transactions. The core idea of this definition is that users and applications should have a highly reliable means of ensuring that transactions can smoothly get confirmed on-chain at any moment. A transaction should not fail to be confirmed due to a single node dropping it—whether due to malice or operational failure.

Although this definition requires providing confirmation guarantees for transactions delivered to any honest node, the cost of achieving this in practice may be prohibitively high. The core significance lies in: the protocol should possess sufficient stability to make the entry for transaction confirmation exhibit strong predictability and be simple and understandable. Permissionless single block-producing node protocols clearly do not meet this characteristic, as if the only block-producing node at a given moment acts maliciously, there are no alternative routes for transaction confirmation. However, even if only a set of four nodes can guarantee packaging transactions during each time period, this would greatly increase the options for users and applications for transaction confirmation. To allow applications to develop stably and prosperously, sacrificing some performance for reliability is worth it. Finding the right balance between robustness and performance still requires further research, but the guarantees currently provided by existing protocols are far from sufficient.

Once the protocol can guarantee transaction confirmation, sorting issues will be easily resolved. The protocol can adopt any deterministic sorting rule to ensure consistent sorting results. The simplest solution is to sort by priority fee or allow applications to flexibly sort transactions that interact with their state. The optimal sorting method for transactions remains an active area of research, but regardless, sorting rules only make sense when transactions can successfully get confirmed on-chain.

Core Requirement Two: Information Privacy

After achieving short-term censorship resistance, another key characteristic the protocol needs to meet is a privacy protection capability we refer to as concealment.

Concealment: Before a transaction is finally confirmed on-chain by the protocol, no party other than the receiving node can obtain any information about that transaction.

Protocols that meet the concealment requirement can allow receiving nodes to view all transactions submitted to them in plaintext, but require that the rest of the protocol remains unaware of the transaction content until consensus is reached and the order of the transaction in the final log is determined. For example, the protocol could use time-lock encryption to make the contents of the entire block invisible until a certain cutoff time; or it could employ threshold encryption, where the block is only decrypted once a committee confirms it is irreversible.

This means that while nodes may misuse the transaction information submitted to them, no other nodes in the network can know the content pending confirmation until consensus is complete. When transaction information is disclosed to the rest of the network, that transaction has already been sorted and confirmed, so no other participants can engage in front-running. To make this definition practical, it requires that multiple nodes can complete the transaction confirmation at any given time.

The reason we do not adopt a stronger definition of privacy—which would mean only the user knows the transaction content prior to confirmation (e.g., encrypted transaction pool solutions)—is that the protocol needs a mechanism to act as a filter for junk transactions. If the transaction content is entirely hidden from the network, it cannot differentiate between junk transactions and valid ones. The only solution is to retain some non-concealed metadata in the transaction, such as the fee address, which will incur fees regardless of whether the transaction is valid. However, this metadata still has the potential to leak enough information, giving attackers an opportunity. Therefore, we prefer to design it so that a single node can see the complete transaction, while other nodes in the network cannot. However, this also means that to make this feature effective, users must have at least one honest node available as an entry point for transaction confirmation during each time period.

Conclusion

Protocols that simultaneously possess short-term censorship resistance and information concealment are the ideal foundational basis for building financial applications. Returning to our example of running an auction on-chain, these two characteristics directly address the issues that Bob could cause for market collapse. Bob can neither censor Alice’s bid nor use it to inform his own bidding, effectively resolving the earlier example’s problems 1) and 2).

With the assurance of short-term censorship resistance, any user submitting a transaction—whether for trading or bidding in an auction—can ensure that their transaction is immediately confirmed on-chain. Market makers can update orders, bidders can quickly place bids, and settlement operations can be executed efficiently. Users can be confident that any actions they initiate will be executed immediately. This will enable a new generation of low-latency real-world financial applications to be built entirely on-chain. If blockchains are to truly compete with existing financial infrastructure, or even surpass its performance, we need to address far more than just throughput issues.