Author: Pranav Garimidi, Joachim Neu, Max Resnick Compiler: Luffy, Foresight News

Blockchain can now confidently claim that it has the ability to compete with existing financial infrastructure. The current production system can handle tens of thousands of transactions per second, and performance will improve by orders of magnitude in the future.

But beyond pure throughput, financial applications require predictability. When a transaction is initiated, whether it is a transaction, an auction bid, or an option exercise, having a reliable guarantee of the timing of the transaction being on-chain is a necessary condition for the normal operation of the financial system. If transactions face unpredictable delays, a large number of applications will become unusable. For on-chain financial applications to be competitive, the blockchain must provide short-term on-chain guarantees: as long as a valid transaction is submitted to the network, it is guaranteed to be packaged into a block as soon as possible.

For example, this is the case with the on-chain order book. An efficient order book requires market makers to continuously provide liquidity and place buy and sell orders at the market. The core issue facing market makers is to avoid adverse selection due to quotations being out of touch with the market while narrowing the bid-ask spread as much as possible. To do this, market makers must constantly update orders to reflect the latest market conditions. For example, when an announcement by the Federal Reserve causes sharp fluctuations in asset prices, market makers need to respond immediately and update orders to the new price. If the transaction used by the market maker to update the order cannot be uploaded to the chain immediately, arbitrageurs will complete the transaction at the outdated price, causing the market maker to suffer losses. By then, market makers can only expand the price difference to reduce risks, which will lead to a decrease in the competitiveness of the on-chain trading platform.

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

The gap between current status and goals

The current mainstream blockchain can only provide final on-chain guarantee, and the validity period is often measured in seconds. This type of protection is sufficient for applications such as payment, but it cannot support the vast majority of financial applications that require market participants to respond to information in real time.

Back to the order book example: For market makers, the guarantee of "on-chain within seconds" is meaningless, as long as the arbitrageur's transactions can be packaged into earlier blocks. Without strong on-chain guarantees, market makers can only hedge risks by widening price differences and providing users with worse quotes. This would make on-chain transactions less attractive than other platforms with stronger guarantees.

For blockchain to truly realize its vision of becoming a modern infrastructure for capital markets, developers must address these issues so that high-value applications such as order books can flourish.

What is difficult about achieving predictability?

It is extremely challenging to strengthen transaction on-chain guarantees on existing blockchains to support such scenarios. Some protocols rely on a single node (block producing node) to determine the order of transaction packaging during a specific period of time. Although this simplifies the engineering design of high-performance public chains, it also creates potential economic monopoly points through which block-producing nodes can capture value.

Typically, during the window during which a node is elected as a block node, it has full control over which transactions are included in the block.

For blockchains that carry a large amount of financial activities, block-producing nodes are in a privileged position. If the node refuses to package a transaction, the user can only wait for the next block-producing node that is willing to package it. In a permissionless network, block-producing nodes naturally have an incentive to extract value, which is what we often call MEV.

MEV is much more than a sandwich attack. Even if the block-producing node only delays transactions by tens of milliseconds, it can still make huge profits and reduce the operating efficiency of the underlying applications. An order book that prioritizes only the orders of some traders puts everyone else on an unfair footing. In the worst case, malicious behavior by block producers can cause traders to leave the platform completely.

Suppose the interest rate hike news is announced and the price of ETH drops by 5% instantly. All market makers on the order book are eager to cancel existing orders and re-place them at the new price. At the same time, all arbitrageurs will submit orders to sell ETH at the outdated price.

If the order book runs on a single block producer protocol, this node will have huge power. It can choose to review the cancellation transactions of all market makers, allowing arbitrageurs to make huge profits; or it can not directly review, but delay the cancellation transactions, allowing arbitrage transactions to be completed first; it can even directly insert its own arbitrage transactions to profit from price deviations.

Two core demands: resistance to censorship and information hiding

In the face of this advantage, the active participation of market makers will become uneconomical, and they may be exploited as long as prices fluctuate. The problem essentially stems from the two major privileges of the block producing node:

• Can review other people’s transactions;

• You can see other people's transactions and submit your own transactions accordingly.

Either of these two problems could have catastrophic consequences.

An example

We use an auction to illustrate this issue accurately. Suppose there are two bidders, Alice and Bob, and Bob happens to be the block producer of the block where the auction is located. (Only two bidders are used as an example, the logic can be extended to any number of people.)

The auction accepts bids during the block production cycle, say from time 0 to time 1. Alice submits bid bA at time tA, and Bob submits bid bB at a later time tB. Since Bob is the block producer, he can always ensure that he acts last.

Both people can obtain the asset price from a continuously updated price source (such as the central price of a centralized exchange), recording the price at time t as pₜ. We assume that at any time t, both parties’ expected price of the asset at the end of the auction (t=1) is equal to the current price pₜ. The rules of the auction are simple: the highest bidder wins and pays his or her bid.

The need to resist censorship

If Bob can use the identity of the block producer to review Alice's bid, the auction mechanism will be completely ineffective. Bob only needs to quote an arbitrarily low price to ensure victory, and the final revenue from the auction is close to zero.

The necessity of information hiding

A more complicated situation is: Bob cannot directly review Alice's bid, but he can see Alice's bid before he bids. At this point Bob has a simple strategy:

• If the current price pₜ_B > bA, quote a price slightly higher than bA;

• Otherwise, give up the bid directly.

Through this strategy, Bob will expose Alice to adverse selection: Alice can only win if her bid is higher than the expected value of the asset, and winning means losing money, and she will eventually choose to withdraw from the auction. When all competitors leave, Bob can bid a very low price to win the auction, and the income is also almost zero.

The core conclusion is: auction length does not matter. As long as Bob can review Alice's bid, or see Alice's bid before he bids, 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 power of Bob in the case, the market will completely fail. If on-chain products that support such scenarios are to be feasible, they must not grant such privileges to block-producing nodes.

Why do these problems not break out in reality?

The above analysis paints a bleak prospect for single block-producing nodes to trade on the chain without permission protocols. However, the trading volume of decentralized exchanges (DEX) on many such protocols is still considerable. Why?

In reality, there are two forces that offset the above problems:

• Block-producing nodes usually hold a large number of native tokens and are deeply bound to the success or failure of the public chain, so they will not completely abuse their economic power;

• The application layer has developed workarounds to reduce its vulnerability to this type of problem.

Although these two factors have allowed DeFi to operate normally so far, in the long term, they are not enough to allow the on-chain market to truly compete with off-chain opponents.

On a public chain with active economic activities, becoming a block producing node requires a large amount of pledges. Therefore, nodes either hold a large number of tokens themselves or have enough reputation to gain delegation from other holders. In either case, large node operators are well-known entities with strong reputations. In addition, the pledged assets also give them an incentive to maintain the development of the public chain. Because of this, we haven’t seen nodes completely abusing their power yet, but that doesn’t mean the problem doesn’t exist.

First of all, relying on the goodwill, social pressure and long-term incentives of node operators is not a reliable cornerstone of future finance. As the scale of on-chain finance expands, the potential profits of nodes will also increase simultaneously. The greater this temptation, the more fragile the social-level pressure that restrains nodes from going against short-term interests will become.

Second, the extent to which nodes abuse their power is on a continuum, from benign behavior to outright market destruction. Node operators may unilaterally and gradually expand their power to obtain higher profits, and once someone breaks the bottom line, others will quickly follow suit. The actions of a single node may seem to have limited impact, but a collective turn can have obvious consequences.

The most typical example is the timing game: the block-producing node publishes the block as late as possible to maximize profits within the scope allowed by the protocol. This can lead to extended block times and even missing blocks. Although the profitability of such strategies is well known, nodes initially chose to exercise restraint out of their responsibility to maintain the public chain. However, this social balance is very fragile. Once a node starts arbitrage without any cost, other nodes will quickly follow.

The timing game is just one example of how nodes can increase their profits without completely abusing their power. There are also many ways for nodes to increase returns at the expense of applications. These behaviors may be tolerable in isolation, but eventually a tipping point is reached where the costs of running on-chain outweigh the benefits.

Another reason why DeFi still works is that applications move their core logic off-chain and only put the results on-chain. For example, protocols that require fast execution of auctions generally complete the process off-chain, often operating mechanisms through permissioned node groups to avoid the problem of malicious nodes. UniswapX's Dutch auction on the Ethereum main network and Cowswap's batch auction are all executed off-chain.

Although this solution allows applications to run, it puts the underlying public chain and its value proposition in an embarrassing situation: the application execution logic is decentralized, reducing the underlying public chain to a simple settlement layer. One of the core advantages of DeFi is composability, and in a world where all execution is off-chain, applications will be naturally isolated in islands. Relying on off-chain execution also adds new assumptions to the application's trust model: in addition to the availability of the underlying public chain, the off-chain infrastructure must also function properly.

How to achieve predictability?

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

Primary condition: censorship resistance

We summarize the first feature as short-term censorship resistance: if a transaction reaches an honest node, it is guaranteed to be included in the next available block.

Short-term censorship resistance: Any valid transaction that reaches any honest node on time must be packaged into the next block.

To be more precise, assume that the protocol runs with a fixed clock, say one block every 100 milliseconds. If a transaction reaches an honest node within 250 milliseconds, it should be included in a 300 millisecond block. An attacker does not have the ability to selectively package or ignore transactions. The core spirit of this definition is: users and applications should have a highly reliable way for transactions to be uploaded to the chain, and transactions will not fail due to malicious packet loss or operational failure of a single node.

Although this definition requires that transactions arriving at any honest node can be packaged, the actual implementation overhead may be too high. The key is that the protocol must be robust enough to make the transaction entry point highly predictable and the logic simple and easy to understand.

The permissionless single block-producing node protocol obviously does not meet this feature: if the current block-producing node does evil, there will be no other way for transactions to be uploaded to the chain. On the contrary, even if only a group of four nodes can guarantee packaged transactions every time period, it will greatly increase the on-chain options for users and applications. It's worth sacrificing some performance in order for your application to be robust and prosperous. Finding the optimal balance between robustness and performance still requires more research, but the protection of existing protocols is clearly insufficient.

Once the protocol can guarantee on-chain, the ordering problem will be solved. A protocol can adopt any deterministic ordering rule, the simplest being ordering by priority fee, or allowing applications to flexibly order transactions that interact with its own state. The optimal way to order transactions is still an area of ​​active research, but in any case, ordering rules only make sense if transactions can be successfully uploaded to the chain.

The second condition: information hiding

After short-term censorship resistance, another important feature that the protocol needs to meet is the privacy guarantee we call concealment.

Hiddenness: Except for the transaction submission node, no party can obtain any information about the transaction before the transaction is finally confirmed and sorted by the protocol.

A protocol that satisfies concealment allows the node receiving the transaction to view the transaction content in plain text, but requires the rest of the network to remain agnostic until consensus is completed and transaction ordering is determined. For example, the protocol can use delayed encryption to make the block content invisible before the deadline; or use threshold encryption to have the committee confirm that the block is irreversible before decrypting it.

This means that a node may abuse transaction information submitted to itself, but other nodes in the network will only learn about the transaction content after the fact. When the transaction information is disclosed to the entire network, its sorting and confirmation have been completed, and other parties cannot preempt the transaction. The premise for this definition to take effect is that there are multiple nodes that can package transactions in each period.

We did not adopt a stronger privacy definition (such as an encrypted memory pool) - that is, only the user knows the transaction information - because the protocol needs to filter spam transactions. If the transaction content is completely hidden from the entire network, the network will not be able to distinguish spam transactions from valid transactions. The only solution is to leak some unencrypted metadata, such as the payment address from which fees are deducted regardless of whether the transaction is valid or not. But this kind of metadata can reveal enough information to give an attacker an opportunity to take advantage. Therefore, we choose a compromise: only a single node can see the transaction content, and the rest of the network cannot. This also means that users must have at least one honest node as the on-chain entry point in each period.

A protocol with both short-term censorship resistance and concealment is an ideal base for building financial applications. Going back to the example of on-chain auctions, these two features directly eliminate the two ways Bob can destroy the market: he can neither review Alice’s bid nor use Alice’s bid to guide his own behavior, which perfectly solves the two major problems mentioned above.

Under the guarantee of short-term censorship resistance, any transaction (whether it is a pending order or an auction bid) is guaranteed to be uploaded to the chain immediately. Market makers can modify orders, bidders can bid quickly, and liquidations can be executed efficiently. Users can be confident that their operations will be executed immediately, allowing a new generation of low-latency, real-world financial applications to be built entirely on-chain.

For blockchain to truly compete with and surpass existing financial infrastructure, it will need to solve much more than throughput issues.