Original Title: Enabling the future of onchain markets: The role of predictability
Original Authors: @PGarimidi, @jneu_net, @MaxResnick, a16z
Translation: Peggy, BlockBeats
Editor's Note: As blockchain performance continues to improve, the focus of industry discussions is shifting from "how many transactions can be processed" to "when transactions are confirmed." For a long time, performance has been simplified to throughput (TPS), but for financial systems, the more critical factor is the predictability of transactions, that is, whether a submitted transaction can be incorporated into a block in a timely and certain manner.
This article points out that most blockchains currently provide only the assurance of "it will eventually be onchain," with timing being uncontrollable. This level of uncertainty in seconds is acceptable in payment scenarios but presents direct issues of price degradation, arbitrage opportunities, and unfairness in financial transactions that require millisecond responses, thereby weakening the competitiveness of onchain markets.
Furthermore, this issue stems from the underlying mechanism: in a single leader block production structure, the transaction ordering and inclusion rights are highly centralized, increasing the risks of censorship, delays, and information asymmetry.
Based on this, the authors propose two directions: one is to provide short-term, predictable transaction inclusion assurances, and the second is to introduce information hiding mechanisms before confirmation, to reduce front-running and adverse selection. In summary, for blockchains to truly become financial infrastructure, transaction execution certainty and fairness are more critical than throughput.
Here is the original text:
Blockchains can now confidently declare that they have the capacity to compete with existing financial infrastructure. Current production systems can handle tens of thousands of transactions per second and will achieve orders of magnitude increases in the foreseeable future.
However, compared to simple throughput capability, financial applications need predictability more. Whether facilitating transactions, participating in auctions, or exercising options, when a transaction is sent, the system must reliably guarantee when that transaction can be confirmed onchain, which is crucial for the normal operation of the financial system. If there are uncertain delays in transaction confirmation (whether due to adversarial behavior or incidental factors), many applications will lose their usability.
Therefore, for onchain financial applications to be competitive, the underlying blockchain must provide short-term inclusion assurance: once a valid transaction is submitted to the network, it should be included in a block in the shortest possible time.
Taking an onchain order book as an example. An efficient order book relies on market makers to constantly provide liquidity, maintaining market operations through continuously posting buy and sell orders. The core issue faced by market makers is to avoid adverse selection risk while compressing the buy-sell spread (the gap between buy and sell quotes) as much as possible.
To do this, market makers must continuously update their orders to reflect changes in market conditions. For instance, when the Federal Reserve announces something that causes asset prices to fluctuate, market makers need to adjust their quotes immediately. If these trades used to update orders cannot be quickly included onchain, they may be executed by arbitrageurs at outdated prices, resulting in losses. The consequence is that market makers have to widen the spread to reduce risk exposure, further undermining the competitiveness of onchain trading venues.
It is precisely the predictable inclusion of transactions into blocks that enables market makers to respond quickly to offchain events, thereby maintaining the efficiency of onchain markets.
What We Have vs. What We Really Need
At present, most blockchains only provide a strong assurance that transactions will eventually be written to the chain, a process that typically occurs within a time scale of several seconds. While this is sufficient for payment applications, it remains too weak of a guarantee for many financial applications that require real-time participant responses to information.
Continuing with the aforementioned order book example: if market makers can only obtain the guarantee of "it will be included in a block in the next few seconds," while arbitrageurs’ trades may enter earlier blocks, then this assurance is effectively meaningless. Without strong inclusion guarantees, market makers can only hedge against increasing adverse selection risk by widening the spread, resulting in worse trading prices for users. This also makes onchain trading significantly less attractive compared to venues offering stronger execution certainty.
If blockchains are to truly realize their vision as modern capital market infrastructure, developers must address these issues so that high-value financial applications like order books can genuinely thrive onchain and remain competitive.
Why Is Achieving "Predictability" So Difficult?
Strengthening transaction inclusion guarantees on existing blockchains to support the aforementioned application scenarios is a highly challenging task. Some protocols currently rely on a single node (the "leader") to decide at any time which transactions can be included in a block. While this mechanism simplifies the engineering challenges of building high-performance blockchains, it also introduces a potential economic bottleneck: these leaders can extract value from it. Typically, within the time window when a node is chosen as a leader, it has complete control over which transactions are included in the block.
For any blockchain that supports financial activities, leaders are in a privileged position. If this single leader decides not to include a transaction, the only response is to wait for the next leader willing to include that transaction.
In an unpermissioned network, leaders are inherently incentivized to extract value, which is often referred to as MEV. MEV goes beyond merely performing sandwich attacks on AMM trades. Even delaying the inclusion of transactions by a few milliseconds can yield considerable profits while reducing the efficiency of underlying applications. An order book that prioritizes only certain traders’ orders places other participants in an unfair competitive environment. In extreme cases, leaders might even exhibit strong adversarial behavior, causing traders to leave the platform altogether.
Imagine a scenario: if interest rates rise and the price of ETH suddenly drops by 5%. All market makers on the order book will swiftly cancel existing orders and repost them at new prices; meanwhile, arbitrageurs will submit sell orders at outdated prices, seizing those orders that have yet to be updated. If this order book operates on a single leader protocol, then the leader will have immense power. The leader can directly choose to censor all market makers' cancellations, allowing arbitrageurs to reap significant profits; or, even without complete censorship, the leader can delay the on-chain time of the cancellations, packaging the arbitrageurs' trades first; furthermore, the leader could insert their own arbitrage trades, fully taking advantage of this price mismatch.
Two Key Objectives: Censorship Resistance and Information Hiding
Under this power structure, market makers will lose the economic incentive to participate; each time prices change, they risk being systematically "harvested." The essence of the problem is that the leader possesses excessive privileges in two areas:
1) The leader can censor others' transactions;
2) The leader can see the content of others' transactions and adjust their own trading behavior accordingly.
Any one of these points can lead to catastrophic consequences.
Example
We can illustrate the problem more precisely with a simple example. Imagine an auction scenario with only two bidders: Alice and Bob, where Bob is also the leader of that block. (Having only two bidders here is for illustration; the actual situation applies to any number of participants.)
The auction takes place within the time window of a block being generated, for example, from time t=0 to t=1. Alice submits a bid bA at time tA, and Bob submits a bid bB at time tB (tB > tA). Since Bob is the leader of that block, he can ensure that his bid is always last.
Meanwhile, both Alice and Bob can continuously access real-time prices of a certain asset (for example, from a centralized exchange's midpoint). At any time t, this price is denoted as pt. We assume that at time t, the market's expectation of the price at t=1 (when the auction ends) always equals pt. This means that at any moment, both parties expect the final price to equal the currently observed price. The auction rules are simple: the higher bid wins and pays their bid.
The Necessity of Censorship Resistance
Firstly, consider how Bob could utilize his leadership advantage. If Bob can censor Alice’s bid, then the auction mechanism will fail directly. Bob only needs to submit an extremely low bid to win the auction without competition. This would lead to auction proceeds being nearly zero.
The Necessity of Information Hiding
The more complex scenario is that Bob cannot censor Alice’s bid but can see Alice's bid before placing his own. In this case, Bob's strategy is very straightforward: when he bids, he simply assesses whether ptB is greater than bA. If so, he submits a price slightly above bA; if not, he does not participate in the bidding.
Through this strategy, Bob creates adverse selection for Alice. Alice will only win the auction when the market price changes such that her bid exceeds the asset's expected value. However, in that case, she is effectively incurring a loss, so the rational choice is not to participate in the auction. Once other bidders exit, Bob can win the auction again at an extremely low price, bringing auction proceeds close to zero.
Key Conclusion
The key conclusion from this example is: the duration of the auction does not matter. As long as Bob can censor Alice’s bid or see her bid before placing his, the auction mechanism is doomed to fail.
The same principle applies to all high-frequency trading scenarios—whether spot trading, perpetual contracts, or derivatives trading. If there exists a leader with such power, that leader can cause the entire market structure to collapse. Therefore, if onchain products hope to be feasible in these scenarios, they must avoid granting leaders such power.
How Do These Issues Arise in Reality?
The foregoing analysis paints a rather pessimistic picture: engaging in onchain transactions on any unpermissioned, single-leader protocol faces structural problems. However, the reality is that many decentralized exchanges (DEXs) on such protocols continue to see active trading volumes. What is the reason behind this?
In practice, two forces have somewhat offset the above issues: first, leaders do not fully exploit their economic power because they are often deeply bound to the long-term success of the underlying chain; second, the application layer employs various "workarounds" to reduce their sensitivity to these issues.
While these two factors have maintained the current operation of decentralized finance (DeFi) to a certain extent, in the long run, they are inadequate for onchain markets to truly possess the capability to compete with offchain markets.
To become a leader of a chain with real economic activities usually requires holding a large amount of staked assets. Therefore, either the node itself holds a substantial amount of tokens or its reputation is strong enough that other token holders are willing to delegate their staking to it. In both scenarios, large node operators are usually well-known entities with significant reputations, whose actions face reputational risk. Furthermore, this staking itself implies they have an economic incentive to promote the long-term development of the chain. As a result, we have not widely observed leaders fully abusing their market power as described above—however, this does not mean the problems do not exist.
Firstly, relying solely on node operators' "goodwill," social pressure, and considerations of long-term interests cannot form a solid foundation for the future financial system. As the scale of onchain financial activities expands, the potential profits leaders can extract also increase. The greater the potential profit, the harder it becomes to rely on social constraints to prevent them from pursuing short-term gains.
Secondly, the extent to which leaders utilize their market power is a continuous spectrum, ranging from almost harmless to sufficient to render the market entirely ineffective. Node operators can progressively breach the boundaries of "acceptable behavior" to achieve higher returns. Once some nodes start attempting to exploit these gaps, others will quickly follow suit. The actions of a single node may seem limited in impact, but when the collective behavior changes, it can be significant.
A typical example is the so-called "timing games": leaders will attempt to delay the publication time of blocks as much as possible while still ensuring that blocks are valid to reap higher rewards. This behavior can lead to prolonged block times, or even skipping blocks when too aggressive. While the profitability of such strategies is well-known, in the past, node operators typically chose not to adopt them out of concern for "maintaining network health." However, this is a fragile social equilibrium. Once a node begins to use these strategies and achieves higher rewards without facing penalties, others will rapidly imitate. "Timing games" are just one example; leaders have various ways to increase their own profits without completely abusing power, often at the expense of the application layer. Individually, these behaviors might be bearable, but as they accumulate to a certain extent, the costs of onchain operation will exceed its benefits.
Another important factor in maintaining DeFi operations is that the application layer migrates key logic offchain, only bringing the results onchain. For instance, any protocol requiring rapid auction execution typically completes the auction process offchain. Such applications often rely on a set of permissioned nodes to run key mechanisms to circumvent the risks posed by adversarial leaders. For example, Uniswap's UniswapX performs Dutch auctions offchain on the Ethereum mainnet to complete trade facilitation; similarly, CowSwap also executes batch auctions offchain. While these solutions are effective at the application level, they make the value proposition of the underlying layer fragile. If the execution logic of the application is entirely moved offchain, the underlying blockchain merely becomes a settlement layer. Moreover, one of DeFi's core selling points—composability—will be weakened. In a world where all executions happen offchain, various applications will inherently exist in isolated environments. Additionally, relying on offchain execution introduces new trust assumptions: not only must the underlying blockchain remain operational, but the offchain infrastructure must also be stable and available.
How to Achieve "Predictability"
To solve the above issues, protocols need to meet two key attributes: consistent transaction inclusion and ordering rules, as well as privacy for transactions before confirmation (for a more stringent definition, see the related papers).
Objective One: Censorship Resistance
We summarize the first attribute as "short-term censorship resistance." Its definition is: as long as a transaction is received by any honest node, it must be guaranteed that it is included in the next possible block.
More specifically, one can assume that the protocol runs under a fixed clock, generating a block every 100ms, for example. Therefore, if a transaction is received by an honest node at t=250ms, it must be included in the block generated at t=300ms. Attackers should not have the discretion to selectively include some transactions while excluding others. The core spirit of this definition is that users and applications must be able to submit transactions onchain in a highly reliable manner at any point in time. There should not be cases where a transaction cannot be placed onchain due to a node dropping packets (whether malicious or incidental).
Although the definition requires "any honest node" to guarantee transaction inclusion, in practice, achieving this may be cost-prohibitive. More critically, the protocol should possess sufficient robustness so that the pathway for transactions to enter the chain is highly predictable. Clearly, unpermissioned single-leader protocols cannot meet this requirement; once the current leader engages in Byzantine behavior, transactions cannot be included onchain. However, even having a small number of nodes (for example, four nodes) collectively ensure transaction inclusion in each time slot can significantly enhance the onchain options for users and applications. To enable applications to truly flourish, it is worthwhile to make certain trade-offs in performance. There is still a need to explore the best balance between robustness and performance, but the assurances provided by existing protocols are clearly inadequate.
Once a protocol can guarantee transaction inclusion, the ordering issue is to some extent resolved. The protocol can use any deterministic ordering rules to ensure consistency, such as prioritizing by fee or allowing applications to conduct custom ordering of transactions relevant to their state. While the optimal ordering remains an active research problem, the prerequisite is always that transactions must first be successfully included.
Objective Two: Hiding
After achieving short-term censorship resistance, the next key attribute is "hiding," which is a privacy protection mechanism for transactions before confirmation.
Its definition is: before a transaction is finally confirmed and included in a block, no other parties besides the node receiving that transaction can access the transaction's information.
In a protocol with hiding, nodes can see the plaintext of transactions submitted to them, but until consensus is reached and the transaction order has been finally determined, other parts of the network remain unaware of the content of the transaction. For example, time-lock encryption can be used to ensure that the block content cannot be decrypted before a certain time point; or threshold encryption can be used to uniformly decrypt after the committee has confirmed the block as irreversible.
This means that although a receiving node may misuse its information, other nodes in the network do not know the transaction content during the consensus process. Once transaction information is made public, its order has been determined and cannot be changed, thus preventing front-running. To make this mechanism effective, the protocol needs to support transactions being received and included by multiple nodes within the same time slot.
We do not adopt a stronger privacy model (such as a fully encrypted mempool visible only to the user), because the protocol must be able to filter out junk transactions. If the transaction content is completely hidden from the entire network, it becomes impossible to distinguish valid transactions from junk ones. The only alternative is to leak some metadata (such as the address paying transaction fees), but this type of information could similarly be utilized by attackers. Therefore, a more realistic design is to allow individual nodes to fully see the transaction content, while other nodes in the network cannot access any information before confirmation. This also means that to satisfy this property, users must have at least one honest node as a transaction entry in each time slot.
A protocol that simultaneously possesses "short-term censorship resistance" and "hiding" will provide an ideal foundation for building financial applications. Returning to the earlier auction example, these two attributes eliminate Bob's two capabilities to disrupt the market: he cannot censor Alice’s bid nor access her information before bidding, thus fundamentally solving the problem.
With short-term censorship resistance in place, any submitted transaction—whether for matching, bidding, or settlement—can be included instantaneously. Market makers can dynamically adjust orders, bidders can quickly submit bids, and settlements can be efficiently executed. Users can be assured that any of their actions will be executed promptly. This will enable the next generation of low-latency real financial applications to operate entirely onchain.
To make blockchains truly competitive with and even surpass existing financial infrastructure, merely enhancing throughput is far from sufficient.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
