This article delves into how blockchain technologies such as modularity, Rollup, and VSR can improve DeFi, particularly in terms of user experience and transaction efficiency. The article is sourced from Maven 11 and compiled, translated, and written by Foresight News.
Table of Contents:
The Importance of Modularity
Verifiable Sorting Rules (VSR)
Rollup and Blockchain Structure
Frequent Batch Auctions (FBA)
Uniswap Case Study
In the first two parts of this series, we primarily focused on the technical issues that arise when decomposing stacks and the improvements needed in the modular world. We have introduced many advancements to address the inherent problems in cross-domain setups. However, in the final part of this series, we hope to focus more on the user experience. We want to explore how modularity, customization, and specialization can help build better applications. The final chapter of this series will focus on the exciting and unique creativity and possibilities in modularity for developers to create a Web2 user experience with Web3 verifiability.
The reason behind building modularity should not only be for the sake of narrative or modularity itself, but because it enables us to build better, more efficient, and customizable applications. There are many unique features that arise when building modular and specialized systems, some obvious and some less so. 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.
One of the capabilities that modularity provides developers, in our opinion, is the ability to build highly customizable professional applications that offer a better experience for end users. We have previously discussed the ability to set rules or reorder transaction execution. Verifiable Sorting Rules (VSR) is one of the interesting opportunities provided by controlling the sorting. This is particularly relevant for developers interested in building a “fairer” transaction system in terms of execution. Obviously, the relationship between liquidity providers’ losses and Liquidation Value Ratio (LVR) is beyond the scope of this article, so we will avoid delving too much into that knowledge. Please keep in mind that the setup we will explain here mainly pertains to AMM rather than order book models. Additionally, CLOB (or even CEX) would greatly benefit from verifiable sorting rules tailored to their specific setups. In off-chain setups, some concepts supported by cryptographic economic security, such as zero-knowledge or optimistic execution, are obviously required.
VSR becomes particularly interesting when considering that most retail participants have not yet (or are unlikely to) adopt protective measures. Most wallets/DEXs have not implemented private memory pools, RPC, or similar methods. Most trades are submitted directly through the frontend, whether it’s an aggregator or DEX frontend. As a result, unless the application directly interferes with its process and order handling, the execution outcomes received by end users may not be ideal.
When considering the role of VSR in the transaction supply chain sorting, it becomes apparent. It sits 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 who have the sorting power have the ability to extract MEV, usually in the form of priority fees or tips.
Therefore, writing rules about how to handle sorting to provide end users with fairer transaction execution (in the context of DEX setups) can be intriguing. However, if you are building a general network, you should try to avoid adhering to such rules as much as possible.
Additionally, there are important MEV aspects such as arbitrage and liquidation. One idea is to create a “highway” 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,” Matheus V., X. Ferreira, and David C. Parkes propose a model where the block sorter is constrained by a set of executable sorting rules (and these constraints are verifiable). Observers can generate fault proofs if the set rules are not followed (or you can imagine a ZK circuit with these constraints, which is verifiable in mathematics and uses ZKP as proof of validity). The main idea is essentially to provide execution price guarantees to end users (traders). This guarantee ensures that the execution price of a trade is just as good as the only trade in the block (obviously, there is some degree of delay involved if we assume a first-come-first-served buy/sell/buy/sell ordering). The proposed idea 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 restrict builders (in the PBS scenario) or sorters to only include trades in the same direction (e.g., sell/sell). Additionally, if there is a case where you have a series of buys followed by a sell, the sell will not be executed (e.g., buy, buy, buy, sell), which may indicate that searchers (or builders/sorters) exploit these buys to drive 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 of these rules (in the case of a larger quantity of sell than buy) is that you may get relatively worse tail-end prices.
For general smart contract platforms, it is almost impossible to implement these rules as pure on-chain structural rules since you have no control over execution and ordering. At the same time, you are also competing with many others, so it would be unnecessarily costly to try and force those at the top of the block to pay priority fees. One of the functionalities of modular setups is that it allows application developers to customize how their execution environment should behave. Whether it’s sorting rules, using different virtual machines, or making custom changes to existing virtual machines (e.g., adding new opcodes or changing Gas limits), it ultimately depends on the developers and their products.
In the case of Rollup using data availability, consensus layer, and liquidity settlement layer, a possible setup could be as follows:
Another possible idea is transaction fragmentation. Imagine having a transaction pool, how would you execute large order trades (which would result in significant slippage)? Is it fair to end users if this trade is executed across consecutive blocks (or at the end of the block if it complies with VSR)?
If end users are concerned about latency, they may not want their orders to be fragmented. However, this situation is not very common, and optimizing for trade fragmentation for larger orders could result in more efficient execution for the majority of users. Nevertheless, one concern is that MEV searchers may become aware of these consecutive trades and exploit them.And try to position their trades before or after those traders mentioned above. However, due to a series of small-scale split transactions on the blocks, the total value of extracted MEV may be much smaller.
Another interesting idea we mentioned in a post earlier is to use the Frequent Batch Auction (FBA) advocated by legendary figure Eric Budish and his colleagues, to process transactions in a batch auction manner instead of sequentially. 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 consecutive block constructions (or the priority fee war in sequential blocks). Thanks to Michael Jordan (DBA) for bringing this paper to our attention, and thank him for his work in mitigating Latency Roast. Implementing it as part of the forking choice and sorting rules of Rollup is also an interesting configuration that developers can use, and we have seen its significant attractiveness 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 a batch auction is conducted based on accumulated orders within the time between each block.
In general, with most transactions being moved to the non-custodial “on-chain” world, FBA may be one of the more efficient ways to achieve “true” price discovery, depending on block time. Utilizing FBA also means that, since all large orders are batched and not revealed until the end of the auction (assuming some cryptographic setting), front-running trades are significantly reduced. The key here is the unified settlement price, as reordering transactions would not make 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 (somewhat like the prequel to modern Rollup), where each batch accepts orders to purchase other ERC 20 tokens at a certain maximum limit price. These orders are collected within a certain time interval and provide a unified 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 configurations, the sorter may need some incentives to enforce (and enforce) the above rules. This is often overlooked, but most of the infrastructure of the blockchain network is operated by professional companies, whose costs are completely different from ordinary home participants. In general, incentives are an important part of implementing secure infrastructure. When incentives align 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. Clearly, such markets are becoming more centralized as the cost of specialized capital may be high. Therefore, the smartest (and richest) people may integrate and specialize to capture as much value as possible. Exclusive order flow may be a knee-jerk reaction for some participants, leading to increased centralization. General benchmark fees may be sufficient, but they do not really push sorting participants towards specialization. Therefore, you may want to introduce some concept that satisfies traders with the outcome through incentive mechanisms that suit 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 the sorting, it is easier to “extract” the value of 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 provides you with the priority fee paid by complex participants to extract on-chain value. These participants are usually willing to pay a considerable amount (until it no longer provides value). However, currently, most Rollups mainly adopt the first-come, first-served mechanism. Most MEV extraction is done through delay wars, which puts severe pressure on Rollup infrastructure. For the above reasons, we may see more and more Rollups starting to implement sorting structures with the concept of priority fees (such as Arbitrum’s time enhancement mechanism).
Another example we like is Uniswap. Currently, Uniswap “builds” a lot of inefficiency as a protocol. These inefficiencies are exploited by participants seeking to extract MEV (arbitrage at the expense of liquidity providers). At the same time, these participants pay a large amount of fees to extract value, but none of this value is captured by the Uniswap protocol or its token holders. Instead, a significant portion of the value of this extraction is paid as a priority fee to Ethereum proposers (validators) through MEV-Boost, giving them the right to be included in a block at a certain moment that allows capturing value. Therefore, although there are many MEV opportunities in Uniswap order flow, none are captured by Uniswap.
If Uniswap can control the sorting within the protocol (as well as the ability to extract priority fees from searchers), it can achieve commercialization and may even pay some of these profits to token holders, liquidity providers, or others. With the changes in Uniswap (such as UniswapX) shifting towards off-chain execution (and Ethereum as the settlement layer), this mechanism seems more and more likely.
If we assume a Rollup with a partial PBS mechanism, the order flow and commercialization process may be as follows:
From this, the commercialization of Rollup sorters and proposers may follow the following formula:
Issuance (PoS) + Fee Income (+ Priority) – Cost of DA, state pub, storage
A good way to see how much value (especially arbitrage) has been extracted on Ethereum is to check Mevboost.pics, which provides a good overview of how much value can actually be extracted from inefficiencies.
Furthermore, separating the priority fee gas war from the off-chain structure can isolate MEV extraction into the execution environment, which helps to contain disruptions in the supply chain. However, considering that if leader elections occur on Rollup, most MEV will be extracted on Rollup, leaving little room for the underlying structure unless the DA layer includes a priority fee 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 bridge or strong security guarantees. However, some trade-offs must be made there. We are starting to see more and more of these things suddenly appear, whether existing or 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 infrastructure can greatly improve applications built on top of it.
Related reports
Uniswap Time Machine: A Review of Updates, Iterations, and Developments from V1 to UniswapX
Underrated Web3 Frontend Services: MEV, Monetization of User Behavior, Brand Moat
Thousand-word Research Report: The Impact of Ethereum Merge on MEV Ecosystem