Written by: Pranav Garimidi, Joachim Neu, Max Resnick

Translated by: Luffy, Foresight News

Blockchain can now confidently claim to have the capability to compete with existing financial infrastructure. Current production systems can process tens of thousands of transactions per second, and future performance will see an order-of-magnitude improvement.

However, beyond mere throughput, financial applications also require predictability. When a transaction is initiated, whether it is a trade, an auction bid, or an options exercise, having a reliable guarantee on the timing of the transaction being recorded on-chain is a necessary condition for the normal operation of the financial system. If transactions face unpredictable delays, a significant number of applications will be rendered unusable. To make on-chain financial applications competitive, blockchain must provide short-term guarantees for on-chain transactions: as long as a valid transaction is submitted to the network, it must be guaranteed to be packaged into a block as quickly as possible.

For example, this is the case with an on-chain order book. An efficient order book requires market makers to continuously provide liquidity by placing buy and sell orders. The core issue facing market makers is: how to minimize the bid-ask spread while avoiding adverse selection due to disconnection from the market. Therefore, market makers must constantly update orders to reflect the latest market status. For instance, if an announcement from the Federal Reserve causes a significant fluctuation in asset prices, market makers need to respond immediately and update their orders to the new prices. If market makers are unable to immediately record the trades used to update their orders on-chain, arbitrageurs will execute trades at outdated prices, causing losses to market makers. At that point, market makers can only widen the spread to reduce risk, which in turn leads to a decline in the competitiveness of on-chain trading platforms.

A predictable on-chain transaction mechanism can provide reliable guarantees for market makers, enabling them to respond quickly to off-chain events and maintain the efficient operation of the on-chain market.

The gap between the current situation and the goal

Current mainstream blockchains can only provide a final on-chain guarantee, and the effective period is often measured in seconds. This type of guarantee is sufficient for applications like payments but cannot support most financial applications that require market participants to respond to information in real-time.

Returning to the example of the order book: for market makers, a guarantee of "on-chain within a few seconds" is meaningless as long as an arbitrageur's transaction can be packed into an earlier block. Without strong on-chain guarantees, market makers can only hedge risks by widening the spread and offering worse quotes to users. This will make on-chain trading less attractive compared to other platforms that offer stronger guarantees.

If blockchain wants to truly realize its vision of becoming modern capital market infrastructure, developers must solve these issues to allow high-value applications like order books to thrive.

Where does the challenge of achieving predictability lie?

Strengthening the guarantee for on-chain transactions on existing blockchains to support such scenarios is highly challenging. Some protocols rely on a single node (the block-producing node) to determine the transaction packaging order within specific time frames. While this simplifies the engineering design of high-performance public chains, it also creates potential economic monopolies, where the block-producing node can extract value.

Typically, during the window period when nodes are elected as block-producing nodes, they have complete control over which transactions are included in the block.

For a blockchain that hosts significant financial activity, the block-producing node occupies a privileged position. If that node refuses to package a certain transaction, users can only wait for the next block-producing node willing to package it. In a permissionless network, block-producing nodes naturally have incentives to extract value, often referred to as MEV (Miner Extractable Value).

MEV is much more than just sandwich attacks. Even if the block-producing node merely delays a transaction by a few tens of milliseconds, it can earn substantial profits while reducing the operational efficiency of underlying applications. An order book that prioritizes only certain traders' orders will leave everyone else in an unfair environment. In the worst-case scenario, malicious actions by the block-producing node could lead to traders completely abandoning the platform.

Assume an interest rate hike announcement causes ETH prices to drop by 5% instantly. All market makers on the order book are eager to cancel existing orders and re-submit them at the new prices. Meanwhile, all arbitrageurs submit orders selling ETH at outdated prices.

If the order book runs on a single block-producing node protocol, that node will have significant power. It can choose to censor the cancellation trades from all market makers, allowing arbitrageurs to reap enormous profits; or, without directly censoring, delay the cancellation trades, allowing arbitrage trades to execute first; or even directly insert its own arbitrage trades, making profits from the price discrepancies.

Two core demands: anti-censorship and information hiding

In the face of such advantages, the active participation of market makers becomes uneconomical; as long as there is a price fluctuation, they may be exploited. The essence of the problem stems from two major privileges of the block-producing node:

• The ability to censor others' transactions;
• The ability to see others' transactions and submit their own based on that information.

Any one of these two issues can lead to catastrophic consequences.

An example

Let’s illustrate this problem precisely with an auction. Suppose there are two bidders, Alice and Bob, and Bob happens to be the block-producing node for the auction's block. (We use only two bidders as an example, but the logic is extendable to any number of participants.)

The auction accepts bids during the block production period, for example, from time 0 to time 1. Alice submits a bid bA at time tA, while Bob submits a bid bB at a later time tB. Since Bob is the block-producing node, he can always ensure that he acts last.

Both can get asset prices from a continuously updating price source (like the midpoint from a centralized exchange), with the current price at time t denoted as pₜ. 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 price pₜ. The auction rule is simple: the highest bidder wins and pays their bid.

The necessity of anti-censorship

If Bob can utilize his position as the block-producing node to censor Alice's bids, the auction mechanism would become completely invalid. Bob only needs to bid any low price to ensure victory, resulting in nearly zero auction revenue.

The necessity of information hiding

A more complex situation arises if Bob cannot directly censor Alice's bids but can see Alice's bid before making his own. At this point, Bob has a simple strategy:

• If the current price pₜ_B > bA, bid slightly above bA;
• Otherwise, simply refrain from bidding.

Through this strategy, Bob puts Alice in a position of adverse selection: Alice can win only if she bids above the expected asset value, and winning means incurring a loss, ultimately leading her to choose to exit the auction. Once all competitors have left, Bob can bid a significantly low price to win the auction, with nearly zero profit.

The core conclusion is that the auction's duration is irrelevant. As long as Bob can censor Alice's bid or see her bid before making his own, the auction is doomed to fail.

This logic also applies to high-frequency trading scenarios, including spot, perpetual contracts, and derivatives exchanges: if the block-producing node has the authority of Bob in the example, the market will completely break down. On-chain products supporting such scenarios cannot afford to grant block-producing nodes such privileges.

Why haven't these issues exploded in reality?

The above analysis paints a bleak picture of transactions on a blockchain with a single block-producing node in a permissionless protocol, yet many such protocols have still seen considerable trading volume on decentralized exchanges (DEX). What accounts for this?

In reality, two forces counterbalance the aforementioned problems:

• Block-producing nodes generally hold a significant amount of native tokens, deeply tied to the success or failure of the public chain, so they do not completely abuse their economic power;
• Application layers have developed alternative solutions to reduce their vulnerabilities to such issues.

Though these two factors have allowed DeFi to function normally thus far, they are not sufficient in the long term to enable on-chain markets to compete with off-chain counterparts.

On economically active public chains, becoming a block-producing node requires a substantial amount of staking. Thus, nodes must either hold a large amount of tokens themselves or have enough reputation to obtain delegation from other holders. In both cases, large node operators are reputable, well-known entities. Furthermore, their staked assets give them motivation to maintain the public chain's development. Because of this, we have not yet seen nodes fully abuse their power, but that does not mean the problems do not exist.

First, relying on the goodwill, social pressure, and long-term incentives of node operators is not a reliable foundation for the finance of the future. As on-chain finance scales, the potential profits for nodes will increase correspondingly. The greater the temptation, the weaker the social pressure constraining nodes from acting against short-term interests.

Second, the degree of power abuse by nodes exists on a continuous spectrum, from mild behaviors to complete market destruction. Node operators may gradually expand their power unilaterally to obtain higher profits; once someone crosses the line, others will quickly follow suit. The behavior of a single node may seem to have limited impact, but a collective shift can have evident consequences.

The most typical example is the timing game: block-producing nodes delay the announcement of blocks as much as possible, maximizing profits within the protocol's permissible range. This can lead to extended block times or even block omissions. Although the profitability of such strategies is well known, nodes initially choose restraint out of responsibility for maintaining the public chain. However, this social balance is very fragile, and once a node arbitrages without consequences, others will quickly follow.

The timing game is just one example of how nodes can enhance their profits without fully abusing their power. Nodes have many ways to increase returns at the expense of applications. Although looking at these behaviors individually may be tolerable, ultimately, they will cross the critical point, causing the cost of on-chain operations to exceed the benefits.

Another reason why DeFi can still function is that applications move their core logic off-chain, only putting the results on-chain. For example, protocols that need to execute auctions quickly generally complete processes off-chain, often using permissioned node groups to operate mechanisms that avoid malicious node issues. UniswapX's Dutch-style auctions on the Ethereum mainnet and Cowswap's batch auctions all utilize off-chain execution.

While this approach allows applications to run, it places the underlying public chain and its value proposition in an awkward position: off-chain execution logic reduces the underlying public chain to a mere settlement layer. One of DeFi's core advantages is composability, and in a world where all execution occurs off-chain, applications will be inherently isolated on islands. Relying on off-chain execution also adds new assumptions to the trust model of applications: beyond the underlying public chain's availability, off-chain infrastructure must also function normally.

How to achieve predictability?

To solve these problems, the protocol needs to fulfill two major characteristics: stable on-chain transaction guarantees and ordering rules, along with privacy protection before transaction confirmation.

Primary Condition: Anti-Censorship

We can summarize the first characteristic as short-term anti-censorship: if a transaction reaches an honest node, it is guaranteed to be packaged into the next available block.

Short-term anti-censorship: any valid transaction that arrives on time at any honest node must be packaged into the next block.

More precisely, assuming the protocol runs with a fixed clock—for example, producing a block every 100 milliseconds—if a transaction arrives at an honest node after 250 milliseconds, it should be packaged in the 300-millisecond block. Attackers have no right to selectively package or ignore transactions. The core spirit of this definition is that users and applications should have highly reliable paths for on-chain transactions, and cannot fail due to a single node's malicious packet loss or operational failure.

Although this definition demands that transactions arriving at any honest node can be packaged, the actual implementation costs may be too high. The key is that the protocol must be robust enough that transaction entry points exhibit strong predictability and be straightforward to understand.

A permissionless single block-producing node protocol clearly does not meet this characteristic: if the current block-producing node behaves maliciously, there will be no alternative paths for transactions to be recorded. Conversely, even if only a group of four nodes can guarantee transaction packaging for every time period, it would greatly enhance the on-chain options available to users and applications. To allow applications to prosper robustly, sacrificing some performance is worthwhile. Finding an optimal balance between robustness and performance still requires more research, but clearly, the current protocols do not provide enough guarantees.

Once the protocol can guarantee on-chain transactions, the ordering issue will be readily resolved. The protocol can adopt any deterministic ordering rules; the simplest method is to order by priority fee or allow applications to flexibly order transactions that interact with their state. The optimal way to order transactions remains an active research field, but in any case, only when transactions can be successfully recorded on-chain will ordering rules be meaningful.

The Second Condition: Information Hiding

After short-term anti-censorship, another important characteristic that the protocol must meet is what we call hiding privacy protection.

Hiding: No participating party other than the transaction submitting node can obtain any information about the transaction before it is confirmed and ordered by the protocol.

Protocols that satisfy the hiding condition allow nodes receiving transactions to view the transaction content in plaintext, but require the rest of the network to remain unaware until consensus is reached and transaction ordering is determined. For example, the protocol could use delayed encryption to make the block's content invisible before the deadline; or use threshold encryption, where a committee confirms the block's irreversibility before decrypting it.

This means that while nodes may abuse the transaction information submitted to themselves, other nodes in the network will only learn of the transaction content afterward. When transaction information is made public to the entire network, its ordering and confirmation have been completed, and others cannot front-run the transaction. The effectiveness of this definition depends on having multiple nodes available to package transactions in each time period.

We did not adopt a stronger privacy definition (such as encrypted memory pools)—where only the user knows the transaction information—because protocols need to filter out spam transactions. If the transaction content is completely hidden from the entire network, it will not be able to distinguish spam transactions from valid ones. The only solution is to leak some unencrypted metadata, such as a fee address that incurs charges regardless of whether the transaction is valid. However, these metadata may disclose enough information to give attackers an opportunity. Therefore, we choose a compromise: only a single node can see the transaction content, while the rest of the network remains blind. This also means that users must have at least one honest node as an entry point for on-chain transactions in each time period.

Protocols that possess both short-term anti-censorship and hiding characteristics form the ideal foundation for building financial applications. Returning to the auction example, these two characteristics directly eliminate Bob's methods of disrupting the market: he cannot censor Alice's bid nor can he utilize Alice's bid to guide his behavior, perfectly solving the two major issues mentioned earlier.

Under the guarantee of short-term anti-censorship, any transaction (be it an order or an auction bid) can be ensured to be recorded immediately on-chain. Market makers can modify orders, bidders can quickly respond with bids, and settlements can be executed efficiently. Users can be assured that their operations will be executed immediately, enabling the next generation of low-latency, real-world financial applications to be fully built on-chain.

For blockchain to truly compete with existing financial infrastructure and achieve superiority, it must resolve far more issues than just throughput.