Written by: Pranav Garimidi, Joachim Neu, and Max Resnick, a16z crypto
Compiled by: Glendon, Techub News
Blockchain can now confidently claim to possess the capabilities necessary to compete with existing financial infrastructure. Current production systems can handle tens of thousands of transactions per second, with significant room for further improvement in the future.
However, beyond raw throughput, financial applications also require predictability. When a transaction is sent—whether a trade, an auction bid, or an option exercise—the normal operation of the financial system relies on a reliable guarantee of when the transaction will be included on the blockchain. If a transaction faces unpredictable delays (whether from malicious attacks or accidental events), many applications will become unusable. For blockchain to offer competitive on-chain financial applications, it must provide a guarantee of near-term inclusion: that is, once a valid transaction is submitted to the network, it is assured to be included as quickly as possible.
For example, consider an on-chain order book. An efficient order book requires market makers to provide liquidity through continuous order placements. A key issue faced by market makers is to avoid adverse selection while narrowing the bid-ask spread as much as possible. To this end, market makers must continuously update their orders to reflect changes in the external world. For instance, if a statement from the Federal Reserve causes asset prices to surge, market makers need to respond immediately and update their orders to the new prices. In this situation, if a market maker's order update does not get included on-chain in time, arbitrageurs will execute their orders at outdated prices, causing losses for the market maker. As a result, market makers are forced to widen their spreads to reduce exposure to such risks, thereby decreasing the competitiveness of on-chain trading venues.
A predictable transaction inclusion mechanism provides strong assurance to market makers, enabling them to respond quickly to off-chain events and maintain the efficient operation of on-chain markets.
Current Status and Future Needs
Currently, existing blockchains only offer finality guarantees that take effect within seconds. While these guarantees suffice for applications like payments, they are too weak for many financial applications that require real-time responses to information. For example, for market makers, if an arbitrageur's transaction can enter the block earlier, then the guarantee of "being included in the next few seconds" is meaningless. Without strong inclusion guarantees, market makers can only react to increased adverse selection risks by widening spreads, thus providing poorer prices to users. This, in turn, makes on-chain trading less attractive compared to other venues that can offer stronger guarantees.
To allow blockchain to truly realize its vision as modern capital market infrastructure, developers must address these issues to enable the flourishing of high-value applications like order books.
How Difficult Is It to Achieve Predictability?
Strengthening existing blockchain's transaction inclusion guarantees to support financial-grade applications is a challenging task. Currently, some protocols rely on a single node (the "leader") to determine the transaction inclusion order at any given time. While this simplifies the engineering implementation of high-performance chains, it also introduces potential economic bottlenecks, allowing the leader to extract value. Typically, during the window of time when a node is the leader, it has complete control over which transactions are included in the block.
For any blockchain processing financial activities, the leader is in a privileged position. If the single leader decides not to include a transaction, the only remedy is to wait for the next leader willing to include that transaction. In a permissionless network, the leader has the incentive to profit from this, commonly referred to as MEV (Maximum Extractable Value). The implications of MEV go far beyond actions like "sandwiching AMM trades." Even if the leader can only delay the inclusion of transactions by a few milliseconds, it can extract significant profits and reduce the efficiency of underlying applications. If the order book only prioritizes transactions from certain traders, all other traders will exist in an unfair competitive environment. In the worst case, the leader's behavior could even frustrate traders, causing them to leave the platform entirely.
Suppose interest rates rise, and the ETH price immediately drops by 5%. All market makers on the order book will rush to cancel their orders and place new ones at the new price. Meanwhile, all arbitrageurs will submit orders to sell ETH at the price of the outdated orders. If this order book operates on a protocol controlled by a single leader, that leader possesses immense power. The leader can directly prohibit all market makers' cancellation actions, allowing arbitrageurs to reap massive profits. Alternatively, the leader might not directly prohibit cancellations but instead delay them until arbitrageurs complete their trades. The leader could even insert their own arbitrage transactions directly to fully exploit the price differences for profit.
The Conflict of Two Ideal Needs: Censorship Resistance and the Necessity of Information Hiding
Faced with these advantages, market makers' active participation becomes unprofitable; every time there is a price change, they may be exploited. The crux of the problem is that market leaders possess two excessive privileges: 1) Leaders can censor other people's transactions; 2) Leaders can see others' transactions and respond by submitting their own transactions. Any of these two issues could lead to catastrophic consequences.
Examples
We can illustrate this issue precisely with the following example. Suppose there is an auction with two bidders, Alice and Bob, and Bob happens to be the "leader" of the block in which the auction occurs. (The presence of only two bidders is solely for illustrative purposes; the same reasoning applies regardless of the number of bidders.)
The auction accepts bids from the beginning to the end of block production, say from time t=0 to t=1. Alice submits a bid bA at time tA, and Bob submits a bid bB at time tB > tA. Since Bob is the leader of the block, he can always ensure that he bids last. Alice and Bob have a continuously updated asset price information source to read (for example, the mid-price from a centralized exchange). At time t, suppose that price is pt. We assume that at time t, both expect the asset price at the end of the auction (at t=1) to always equal pt. In other words, at any moment, Alice and Bob anticipate the asset price at the end of the auction to be equal to the price they currently see. The auction rules are simple: the one who bids higher between Alice and Bob wins the auction and pays their bid.
The Necessity of Censorship Resistance
Now consider what happens when Bob can exploit his position as leader. If Bob can block Alice's bid, the auction will obviously fail. Bob merely needs to bid an arbitrarily small amount and ensure he wins the auction because there are no other bids. This will result in the auction being concluded with nearly zero revenue.
The Need for Information Hiding
A more complex situation arises when Bob cannot directly prevent Alice's bid but can still see Alice's bid before he places his own. In this case, Bob has a simple strategy: when he bids, he just needs to check if ptB is greater than bA. If so, Bob bids a little higher than bA; if not, Bob simply abstains from bidding. By adopting this strategy, Bob causes Alice to suffer from adverse selection. Alice will only win if the price movements lead her bid to end up higher than the expected asset value. Whenever Alice wins the auction, she anticipates making a loss, making it better not to participate in the auction. With all competitive bidders gone, Bob again just needs to bid an arbitrarily small amount to win, and the auction effectively realizes zero revenue.
The key conclusion here is that the duration of the auction does not matter. As long as Bob is able to censor Alice's bid or see Alice's bid before placing his own, the auction is doomed to fail.
The principles in this example equally apply to any high-frequency asset trading scenario, whether in spot trading, perpetual contracts, or derivatives exchanges: if there exists a leader like Bob with immense power, then he can cause the market to collapse. For on-chain products serving these use cases to function sustainably, they must never grant leaders such power.
How Do These Problems Arise in Today's Practices?
The above description paints a grim picture of on-chain transactions for any single leader protocol in a permissionless network. However, why do many decentralized exchanges (DEX) on single leader protocols continue to see healthy trading volumes?
In reality, the combination of two forces can offset the above issues:
- Leaders do not fully exploit their economic power, as they often have significant stakes in the success of the underlying ecosystem;
- Applications have built corresponding evasion mechanisms to avoid being impacted by these problems.
While these two factors enable DeFi to thrive, they are insufficient in the long run to allow on-chain markets to truly compete with off-chain markets.
To become a leader on a blockchain with significant economic activity, substantial staking is required. Thus, a leader must either hold a large amount of stake themselves or have enough reputation to attract other token holders' delegation of stakes. In either case, large node operators are typically well-known entities with a good reputation. Besides reputation, this staking also means the operator has a financial incentive to ensure the chain performs well. Because of this, we rarely see leaders fully exploit their market power as described above—but that does not mean these issues do not exist.
First, relying on node operators' goodwill through social pressure and long-term incentives is not a solid foundation for the future of finance. As the scale of on-chain financial activities increases, the potential profits for leaders also grow accordingly. The larger this potential profit, the harder it becomes to restrain leaders' actions socially, making them act against their short-term interests.
Second, the degree to which leaders exploit their market power is a spectrum ranging from well-behaved to leading to a complete market collapse. Node operators can unilaterally push the envelope using their power for higher profits. As some operators test the boundaries of acceptable behavior, others quickly follow suit. The actions of a single node may seem trivial, but when all nodes make changes, the impact becomes evident.
A prime example of this phenomenon may be the "time game": when leaders try to announce blocks as late as possible while ensuring the blocks are valid for the protocol, they can earn higher rewards. This leads to increased block generation times, and in some cases, when leaders become overly aggressive, certain blocks may be skipped. Although the profitability of these strategies is well-known, leaders often choose to abstain from participating in them to maintain the good order of the chain.
However, this social equilibrium is very fragile. Once a node operator begins to exploit these strategies for higher rewards without any repercussions, other operators will quickly imitate. The time game is just one example of how leaders can increase profits without fully exploiting market power. Leaders can take many other actions to enhance their profits, often at the expense of application interests. Alone, these actions may be effective for applications, but ultimately their scale will reach a tipping point, where on-chain costs outweigh the benefits.
Another factor that allows DeFi to operate is that applications move critical logic off-chain, only posting results on-chain. For instance, any protocol requiring fast auctions will execute off-chain. These applications usually operate their required mechanisms on a set of permissioned nodes to avoid conflicts with malicious leaders.
For example, UniswapX runs its Dutch auctions off-chain to complete transactions on the Ethereum mainnet, and Cowswap similarly operates its batch auctions off-chain. While this is feasible for the applications, it places the underlying architecture and the value propositions built on-chain in a precarious position. If the execution logic of an application is off-chain, then the underlying infrastructure can only be used for settlement. One of DeFi's most powerful selling points is composability. Under circumstances where all execution happens off-chain, these applications essentially exist in isolated environments. Relying on off-chain execution also adds new assumptions to the trust model of these applications. Beyond depending on the underlying chain to remain active, these off-chain infrastructures must also operate correctly for the applications to work.
How to Achieve Predictability
To address these issues, protocols need to meet two properties: consistent transaction inclusion and ordering rules as well as transaction privacy before confirmation.
Prerequisite: Censorship Resistance
We summarize the first property with the term short-term censorship resistance. If a protocol can guarantee that any transactions reaching valid nodes will be included in the next possible block, then that protocol possesses short-term censorship resistance.
More accurately, we assume that the protocol operates in a fixed clock cycle, with each block generated at fixed intervals, such as every 100 milliseconds. Therefore, we want to ensure that if a transaction arrives at a valid node at t=250 milliseconds, it will be included in the block generated at t=300 milliseconds. Adversaries should not be able to selectively include certain transactions they hear while ignoring others. The crux of this definition is that users and applications should have an extraordinarily reliable way to receive transactions at any point in time. There should be no situation where a single node drops packets due to malicious behavior or simple operational failures, causing transactions to fail to be completed.
While this definition requires ensuring that all transactions reaching valid nodes can be included, the overhead of achieving this may be too high in practice. The key is that the protocol must be robust enough for the entry points of on-chain transactions to operate in a highly predictable and easily understandable manner. A permissionless single-leader protocol clearly doesn't satisfy this property, as if the single leader is in a "Byzantine state" at any moment, transactions cannot be included on-chain in any other manner. However, even a group of four nodes that can guarantee transaction inclusion during each time slot greatly increases the number of options for users and applications to land transactions. To ensure stable operation of applications, sacrificing some performance is worthwhile. There is still much work to find the right balance between robustness and performance, but the assurances currently provided by protocols are far from sufficient.
Given that protocols can guarantee inclusion, ensuring data integrity makes the ordering mechanism somewhat acquired for free. Protocols can freely use any deterministic ordering rules to ensure consistency in ordering. The simplest solution is to sort by priority fees or allow applications to flexibly order transactions interacting with their state. The best way to order transactions remains an active area of research, but in any case, ordering rules only have meaning when there are transactions to be sorted.
Second Requirement: Hiding
After possessing short-term censorship resistance, the next most important property the protocol needs to provide is a form of privacy that we refer to as "hiding."
Hiding: No party can know any information regarding a transaction before the protocol finalizes and confirms the transaction, aside from the node to which the transaction is submitted.
Protocols with hiding capabilities might allow nodes to see all transactions submitted to them in plaintext but require that the remainder of the protocol remains entirely blind to the transaction's content until consensus is reached and the order has been determined in the final log. For instance, the protocol might use time-lock encryption to keep the contents of an entire block hidden until a specified cutoff time; or the protocol can use threshold encryption so that the block is decrypted only after unanimous confirmation from the committee that it is irreversible.
This means a node could manipulate any transaction information submitted to it, but the rest of the protocol remains unaware of the specific details of the transactions they rely on until consensus is achieved. By the time the transaction information is revealed to other nodes in the network, the transaction has already been sorted and confirmed, preventing any other nodes from executing it prematurely. To make this definition practically meaningful, it implies multiple nodes can process the same transaction within any given time window.
We abandon more robust schemes (such as having only the user know transaction information before confirmation, like in an encrypted memory pool) because the protocol requires some steps to filter out junk transactions. If the transaction content is completely hidden from the network, then the network cannot distinguish between junk and valid transactions. The only solution is to leak some unhidden metadata in the transaction, such as the address of the payor that incurs fees regardless of whether the transaction is valid. However, this metadata might leak enough information for adversaries to exploit. Therefore, we prefer to have individual nodes fully possess transaction details while no other nodes in the network can acquire any information about them. But this means that to make this feature useful, users must have at least one honest node as an entry point to successfully submit transactions in every transaction slot.
Conclusion
A protocol that combines short-term censorship resistance with privacy protection provides an ideal foundation for building financial applications. Returning to our previous example of holding an auction on-chain, these two features directly address the issue of Bob potentially causing the market to collapse. Bob cannot censor Alice's bid nor exploit her bid to influence his own, which precisely resolves the issues of problem 1 and problem 2 in our earlier example.
With the resistance to short-term content censorship, any transaction submitted (whether a trade or auction bid) is assured to be promptly included. Market makers can modify their orders; bidders can quickly place bids; and liquidation operations can be efficiently completed. Users can be confident that any action they take will be executed immediately. This, in turn, will enable the next generation of low-latency real-world financial applications to be fully built on blockchain. However, for blockchain to truly compete with existing financial infrastructure, even surpassing its performance, we need to address far more than just throughput issues.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
