This article delves into how blockchain technologies such as modularity, Rollup, and VSR can improve DeFi, especially in terms of user experience and transaction efficiency. The article is sourced from Maven 11, compiled, translated, and written by Foresight News.
Table of Contents:
1. The Importance of Modularity
2. Verifiable Sorting Rules (VSR)
3. Rollup and Blockchain Structures
4. Frequent Batch Auctions (FBA)
5. Uniswap Case Study
In the first two parts of this series, we mainly focused on the technical challenges that arise when splitting stacks and the improvements needed in a modular world. We have introduced many advancements to solve the problems that naturally occur in cross-domain setups. However, in the final part of this series, we want to pay more attention to 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 for developers to create Web2 user experiences with Web3 verifiability.
The reason behind building modularity should not only be for storytelling or modularity itself, but because it allows us to build better, more efficient, and more customizable applications. Building modular and specialized systems brings forth many unique features. Some of these features are obvious, while others may not be as apparent. Therefore, our goal is to provide an overview of the capabilities of modular systems that you may not be aware of, such as scalable packageability.
We believe that one of the capabilities provided by modularity is the ability for developers to build highly customizable professional applications that bring a better experience to end-users. We have previously discussed the ability to set rules or reorder the execution order of transactions.
Verifiable Sorting Rules (VSR) is one of the interesting opportunities that control the sorting provided, especially for developers interested in building “fairer” transaction systems in terms of execution. Obviously, the relationship between liquidity providers’ losses and Liquidity Value Rebalancing (LVR) goes beyond the scope of this article, so we will avoid touching too much on that knowledge. Please note that the settings we are about to explain mainly focus on AMM rather than order book models. Additionally, CLOB (or even CEX) could benefit greatly from verifiable sorting rules that suit their specific setups. In off-chain settings, obviously some concepts supported by cryptographic-economic security are needed, such as zero-knowledge or optimistic execution.
VSR becomes particularly interesting when considering that most retail users 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 frontend (whether it’s an aggregator or a DEX frontend). Therefore, unless the application directly interferes with the process and handling of orders, the execution effects obtained by end-users may not be ideal.
When considering the position of transaction supply chain sorting, the role of VSR becomes evident. It is where professional participants sort (or include) transactions, usually based on some auction or base fee. This sorting is crucial as it determines which transactions are executed and when. Essentially, those with sorting rights have the ability to extract MEV, usually in the form of priority fees (or tips).
Therefore, writing rules about how to handle sorting in order to provide fairer transaction execution to end-users (in DEX settings) can be interesting. However, if you are building a general network, you should try to avoid following such rules as much as possible.
Furthermore, there are some important MEV such as arbitrage and liquidation. One idea is to create a “fast lane” channel at the top of the block specifically for whitelisted arbitrageurs and liquidators who pay higher fees and share part of the protocol’s revenue.
In the paper “Designing Trustworthy Decentralized Exchanges through Verifiable Sorting Rules” by Matheus V., X. Ferreira, and David C. Parkes, they propose a model where the block’s sorter is constrained by a set of execution sorting rules (and these constraints are verifiable). Observers can generate fault proofs (or imagine a ZK circuit with these verifiable constraints, which uses ZKP as proof of validity) if the rules are not followed. The main idea is essentially to provide execution price guarantees to end-users (traders). This guarantee ensures that the execution price of a transaction is as good as the sole transaction in the block (obviously, if we assume a first-come, first-served buy/sell/buy/sell sorting, there is some degree of delay involved here). The proposed idea in the paper is that these sorting rules restrict builders (in the context of PBS) or sorters to only include transactions in the same direction (e.g., sell/sell) if they execute at better prices than what is available at the top of the block. Additionally, if there is a case where you sell at the end of a series of purchases, the sell will not be executed (e.g., buy, buy, buy, sell), which may indicate that searchers (or builders/sorters) take advantage of these purchases to push the price in their favor. This essentially means that the protocol rules guarantee that users are not used to provide better prices for others (i.e., MEV) or cause price slippage due to priority fees. Obviously, a flaw in these rules (when the sell quantity is greater than the buy quantity, and vice versa) is that you may end up with relatively worse tail-end prices.
For general smart contract platforms, it is almost impossible to have these rules as purely on-chain structural rules as you have no control over execution and sorting. At the same time, you are competing with many others, so it would be unnecessarily expensive to try to enforce those at the top of the block to pay priority fees. One of the capabilities of modular setups is that it allows application developers to customize how their execution environment should behave. Whether it is sorting rules, using different virtual machines, or making custom changes to existing virtual machines (e.g., adding new opcodes or changing gas limits), it depends on the developers and their products.
In the case of a Rollup that utilizes data availability, consensus layer, and liquidity settlement layer, a possible configuration could be as follows:
Another possible idea is transaction splitting. Imagine having a transaction pool, how would you execute large order transactions (which would result in significant slippage)? If this transaction is executed across multiple consecutive blocks (or if it matches VSR, then at the end of the block), is it fair to end-users?
If end-users are concerned about latency, they may not want their orders to be split. However, this scenario is not very common, and optimizing for split transactions for larger orders may result in more efficient execution for the vast majority of users. Nonetheless, one concern is that MEV searchers may become aware of these consecutive transactions,And try to position their trades before or after those traders. However, due to a series of small-scale split trades on the blocks, the total value of extracted MEV may be much smaller.
Another interesting idea we mentioned in a previous post is the use of Frequent Batch Auctions (FBA) advocated by legendary figure Eric Budish and his colleagues. This is to help discover Coincidence of Wants (CoW) and incorporate arbitrage opportunities into market mechanism design. This also helps “counter” the delay game in continuous block construction (or the priority fee war in sequential blocks). Thanks to Michael Jordan (DBA) for bringing this paper to our attention and for his work on mitigating Latency Roast. It is also an interesting setting that developers can use as part of the fork selection and sorting rules for Rollups, and we have seen significant appeal in the past year, especially for Penumbra and CoWSwap. One possible configuration is as follows:
In this configuration, there is no first-come, first-served or priority gas fee war, but instead, a batch auction is performed based on accumulated orders within the time between each block.
In general, as most transactions have moved to the non-custodial “on-chain” world, FBA may be one of the more efficient ways to achieve “real” price discovery, depending on the block time. Using FBA also means that front-running is greatly reduced since all bulk orders are batched and not revealed until the auction ends (assuming some encryption settings). A unified settlement price is crucial here as reordering transactions would make no sense.
It should also be noted 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 accepted orders to purchase other ERC 20 tokens at a certain maximum limit price. These orders were collected within a certain time interval and provided a unified settlement price for all token pairs. The general idea behind this model is that it would help eliminate front-running, which is common in popular AMMs.
Another important point to note is that in these configurations, the sorter may need some incentives to enforce the above rules. This is often overlooked, but most of the infrastructure of the blockchain network is operated by professional companies that have completely different costs from ordinary home participants. Incentives are generally an important part of implementing secure infrastructure. With incentives aligned with the rules being enforced, sorters and builders are also more likely to make greater efforts. This means that these configurations 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. Exclusive order flow may be a stumbling block for some participants, leading to increased centralization. A general benchmark fee may be sufficient, but it doesn’t really drive sorter participants towards specialization. Therefore, you may want to introduce some concept of satisfying outcomes for traders through incentive mechanisms that suit your specific situation.
This is clear to most people, but still worth mentioning when discussing sorting at the Rollup level. If you have control over the sorting, it becomes easier to “extract” value from the protocol. This is because you control the power to reorder transactions, which is usually based on the priority fee on most L1s (MEV-boost-esque settings). It offers you the MEV-extracting value that complex participants on the chain pay for. These participants are usually willing to pay significant amounts until it no longer provides value. However, currently, most Rollups primarily adopt a first-come, first-served mechanism. Most MEV extraction is done through delay wars, which puts significant pressure on Rollup infrastructure. For the reasons mentioned above, we may see more and more Rollups starting to implement sorting structures with the concept of priority fees (e.g., Arbitrum’s time-enhanced mechanism).
Another example we like is Uniswap. Currently, Uniswap “creates” a lot of inefficiency as a protocol. These inefficiencies are exploited by participants seeking to extract MEV (arbitrage at the expense of liquidity providers). Meanwhile, these participants pay significant fees to extract value, but none of this value is captured by the Uniswap protocol or its token holders. Instead, a large portion of the value extracted goes to Ethereum proposers (validators) as priority fees paid through MEV-Boost, granting them the right to be included in a block at a certain moment that allows capturing value. Therefore, although Uniswap’s order flow presents a lot of MEV opportunities, none of it is captured by Uniswap itself.
If Uniswap were able to control the sorting within the protocol (as well as the ability to extract priority fees from searchers), it could achieve commercialization and possibly distribute some of the profits to token holders, liquidity providers, or others. With the changes in Uniswap (such as UniswapX) turning towards off-chain execution (and Ethereum as the settlement layer), this mechanism seems increasingly possible.
If we assume a Rollup with partial PBS mechanisms, the order flow and commercialization process may look like this:
From this, 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) is being extracted on Ethereum currently can be found on Mevboost.pics, which provides a good overview of how much value can be practically extracted from inefficiency.
Furthermore, separating the priority fee gas war from off-chain structures can isolate MEV extraction to the execution environment, helping to contain disruptions in the supply chain. However, considering that if leader elections occur on the Rollup, most MEV will be extracted on the Rollup, leaving little room for the underlying infrastructure, unless DA layer includes priority fees from liquidity integration or other economies of scale.
It should be clarified that many of these structures can function as purely off-chain structures without any verification bridges or strong security guarantees. However, some trade-offs must be made. We are starting to see more of these things suddenly appearing, both existing and hidden. One point I want to point out is that modular configurations do not necessarily mean Rollup.
The above sorting rules represent an example where fine-tuning the infrastructure can significantly improve the applications built on top of it.
Related Reports
Uniswap Timeline: A Review of Updates, Iterations, and Developments from V1 to UniswapX
Underrated Web3 Front-end Services: MEV, Monetizing User Behavior, Brand Moats
Thousand-word Research Report: The Impact of Ethereum Merge on MEV Ecosystem