Author: Maven11
Compilation: Luffy, Foresight News
In the first two parts of this series of papers, we mainly focused on the technical issues that arise when splitting the stack and the improvements needed for a modular world. We have introduced many advances in solving the natural problems that arise in cross-domain settings. However, in the final part of this series, we hope to focus more on user experience. We want to study how modularity, customization, and specialization can help create better applications. The last chapter of this series will focus on the exciting and unique creativity and possibilities in modularity, allowing developers to create Web2 user experiences with Web3 verifiability.
The reason for building modularity should not only be to cater to the narrative, nor just for modularity, but because it allows us to build better, more efficient, and more customizable applications. When building modular and specialized systems, many unique features emerge. Some of these are obvious, while others are not so obvious. Therefore, our goal is to provide an overview of the capabilities of modular systems that you may not be aware of, such as scalability.
We believe that one of the capabilities that modularity provides to developers is the ability to build highly customizable professional applications, providing a better experience for end users. We have previously discussed the ability to set rules or reorder the execution sequence of transactions.
The ability to verify sorting rules (referred to as VSR below) is one of the interesting opportunities that control sorting provides, especially for developers interested in building "fairer" trading systems in terms of execution. Obviously, the relationship between liquidity providers' losses and LVR (rebalancing) is beyond the scope of this article, so we will avoid touching on this aspect too much. Please remember that the settings we are about to explain are mainly aimed at AMM rather than order book models. In addition, CLOB (or even CEX) would also greatly benefit from utilizing sorting rules suitable for their specific settings in the off-chain setting, which obviously requires some concept of zero-knowledge or optimistic execution supported by cryptographic economic security.
VSR is particularly interesting when we consider the fact that most retail investors have not (or are unlikely to) adopt protective measures. Most wallets/DEXs also do not implement private memory pools, RPC, or similar methods. Most transactions are submitted directly through the front end (whether it is an aggregator or a DEX front end). Therefore, the execution effects that end users may receive are likely to be less than ideal unless the application directly interferes with their processes and the way orders are handled.
When we consider the role of VSR in the transaction supply chain sorting, its significance becomes obvious. It is where professional participants sort (or include) transactions, usually based on some auction or basic fees. This sorting is very important as it determines which transactions are executed and when. Essentially, those with the sorting rights have the ability to extract MEV, usually in the form of priority fees (or tips).
Therefore, it might be interesting to write rules on how to handle sorting in order to provide fairer transaction execution for end users (in DEX settings). However, if you are building a general network, you should try to avoid complying with such rules as much as possible.
Furthermore, some MEV is important, such as arbitrage, liquidation, and so on. One idea is to establish a "highway" at the top of the block specifically for whitelisted arbitrageurs and liquidators, who pay higher fees and share part of the income with the protocol.
In the paper "Designing Trustworthy Decentralized Exchanges through Verifiable Sorting Rules," Matheus V., X. Ferreira, and David C. Parkes proposed a model in which the block sorter is constrained by a series of executable sorting rules (and these constraints are verifiable). In the case of not complying with the set rules, observers can generate failure proofs (or because the constraints are mathematically verifiable, you can also imagine a ZK circuit with these constraints, which uses ZKP as a validity proof). The main idea is essentially to provide execution price guarantees for end users (traders). This guarantee ensures that the execution price of transactions is as good as the only transaction in the block (obviously, if we assume a certain degree of delay based on the first-come, first-served buy/sell/buy/sell sorting). The basic idea proposed in the paper is that if they execute at a better price than what is available at the top of the block, these sorting rules will limit the builder (in the PBS scenario) or the sorter to only include transactions in the same direction (e.g., sell/sell). Furthermore, if there is a series of purchases followed by a sale, the sale will not be executed (for example, buy, buy, buy, sell), which may indicate that the searcher (or builder/sorter) is using these purchases to push the price in a direction that benefits them. This essentially means that the protocol rules ensure that users are not used to provide better prices for others (i.e., MEV), or that price slippage occurs due to priority fees. Obviously, the flaw in these rules (when the quantity of sales exceeds the quantity of purchases, and vice versa) is that you may get relatively worse tail prices.
For a general smart contract platform, it is almost impossible to implement these rules as purely on-chain construction rules, because you cannot control execution and sorting. At the same time, you are also competing with many others, so trying to force those at the top of the block to pay priority fees would be unnecessarily expensive. One of the functions of modular settings is that it allows application developers to customize how their execution environment should operate. Whether it is sorting rules, using different virtual machines, or making custom changes to existing virtual machines (such as adding new opcodes or changing gas limits), it actually depends on the developers and their products.
In a scenario where a Rollup uses data availability, consensus layer, and liquidity settlement layer, the possible settings are as follows:
Another possible idea is transaction splitting. Imagine a transaction pool, how to execute large order transactions (which would result in a large amount of slippage)? Is it fair to end users if this transaction is executed across consecutive blocks (or if it complies with VSR, then at the end of the block)?
If the end user is concerned about latency, then the user may not want their order to be split. However, this situation is not very common, and optimizing the splitting of transactions for larger orders may result in more efficient execution for the vast majority of users. Nevertheless, one concern is that MEV searchers may realize these consecutive transactions and try to position their transactions before or after the above-mentioned traders. However, due to the small-scale split transactions across a series of blocks, the total value of extracted MEV may be much smaller.
Another interesting idea we mentioned in a previous post is to use frequent batch auctions (FBA) advocated by the legendary figure Eric Budish and his colleagues, to process transactions in batch auctions rather than serially. This is to help discover CoW (coincidence of wants) and integrate arbitrage opportunities into market mechanism design. This also helps "combat" the delay game in continuous block construction (or the priority fee war in serial blocks). Thanks to Michael Jordan (DBA) for bringing this paper to our attention and for his work in mitigating Latency Roast. Implementing it as part of the fork selection and sorting rules of Rollup is also an interesting setting that developers can use, and we have seen its significant appeal over the past year, especially for Penumbra and CoWSwap. One possible setting is as follows:
In this setting, there is no first-come, first-served or priority gas fee war, but rather batch auctions at the end of each block based on accumulated orders between blocks.
In general, as most trading has moved to the non-custodial "on-chain" world, FBA may be one of the more effective ways of "true" price discovery, depending on block times. Utilizing FBA also means that front-running trades will be greatly reduced, as all bulk orders are batched and not revealed until the end of the auction (assuming some cryptographic settings). Uniform settlement prices are crucial here, as reordering trades would be meaningless.
It is also worth noting that as early as 2018, similar designs to the one we just introduced were discussed on the Ethresear.ch forum (see here). In the post, they mentioned two papers that provided a batch auction mechanism on Plasma (a precursor to modern Rollups), where each batch accepts orders to purchase other ERC20 tokens at a certain maximum limit price. These orders are collected over a certain time interval and provide a uniform settlement price for all token pairs. The overall idea behind this model is that it will help eliminate the front-running phenomenon common in popular AMMs.
Another important point to note is that in these settings, sorters may need some incentives to enforce the above rules. This is often overlooked, but most of the infrastructure of blockchain networks is operated by professional companies, whose costs are completely different from those of ordinary household participants. Incentives are generally an important part of implementing secure infrastructure. When incentives align with the rules being enforced, sorters and builders are more likely to make greater efforts. This means that these settings should also have an active market. Obviously, such markets tend to centralize, as the cost of specialized capital may be high. Therefore, the smartest (and wealthiest) individuals may integrate and specialize to capture as much value as possible. Here, exclusive order flow may be a barrier for some participants, leading to increased centralization. General baseline fees may be sufficient, but they do not truly push sorting participants towards specialization. Therefore, you may want to introduce some concept of traders being satisfied with the results through incentive mechanisms tailored to your specific situation.
This is clear to most people, but it still needs to be mentioned when discussing sorting at the Rollup level. If you can control sorting, you can more easily "extract" value from the protocol. This is because you control the power to reorder trades, which is usually based on priority fees (MEV-boost-esque settings) on most L1s. It provides you with the ability to extract value from complex participants paying priority fees on-chain. These participants are usually willing to pay significant amounts (until it no longer provides value). However, currently, most Rollups mainly use a first-come, first-served mechanism. Most MEV extraction is done through a delay war, which puts significant pressure on Rollup infrastructure. For this reason, we may see more and more Rollups starting to implement sorting structures with the concept of priority fees (such as Arbitrum's time-bonus mechanism).
Another example we like is Uniswap. Currently, Uniswap "creates" a lot of inefficiency as a protocol. These inefficient behaviors are exploited by participants seeking to extract MEV (arbitrage, at the expense of liquidity providers). At the same time, these participants pay a significant amount of fees to extract value, but none of this value goes to the Uniswap protocol or its token holders. Instead, a large portion of this extracted value is paid as priority fees to Ethereum proposers (validators) through MEV-Boost, to gain the right to be included in a block at a certain moment that allows capturing value. Therefore, while there are many MEV opportunities in the Uniswap order flow, none of it is captured by Uniswap.
If Uniswap could control sorting within the protocol (and the ability to extract priority fees from searchers), it could commercialize and possibly redistribute some of the profits to token holders, liquidity providers, or others. As Uniswap evolves (such as UniswapX, etc.) towards off-chain execution (and Ethereum as the settlement layer), this mechanism seems increasingly likely.
If we assume a Rollup with some PBS mechanism, the order flow and commercialization process might look like this:
As a result, the commercialization of Rollup sorters and proposers may follow the following formula:
Issuance (PoS) + Fee income (+priority) - DA, state pub, storage costs
A good way to see how much value (especially arbitrage) has been extracted on Ethereum can be found on Mevboost.pics, which provides a good overview of how much value can actually be extracted from inefficiency.
Furthermore, separating the priority fee gas war from off-chain structures can isolate MEV extraction into the execution environment, helping to curb supply chain interruptions. However, considering that if leader elections occur on the Rollup, most MEV will be extracted on the Rollup, leaving little room for the underlying structure, unless DA layer inclusion, settlement layer priority fees come from liquidity aggregation, or other economies of scale.
It should be clarified that many of these structures can function as purely off-chain structures without any verification bridge or strong security guarantees. However, some trade-offs must be made there. We are starting to see more of these things suddenly appear, whether existing or hidden. One point I want to emphasize is that modular settings do not necessarily mean Rollup.
The above sorting rules represent an example where fine-tuning the infrastructure can greatly improve the applications built on top of it.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
