Author: Yuki Yuminaga Source: Sorella Translator: Shan Ouba, Jinse Finance
Introduction
Solving the maximum extractable value (MEV) has been a challenge facing Ethereum. The value supply chain incentivizes arbitrageurs to engage in frequent activities through various strategies, often harming the interests of retail users. While many researchers have tried to address MEV through protocol-layer changes, these efforts have not yet provided satisfactory solutions. The current infrastructure and auction mechanisms can effectively capture the MEV in the block, but they do not fairly distribute the captured value: why should the value of MEV accrue to the network validators, rather than being more effectively captured and internalized by each application itself?
This is where Application-Specific Sequencing (ASS) comes into play. Rather than trying to rewrite the rules at the protocol layer, ASS empowers each application to control its own transaction ordering. By doing so, ASS allows on-chain applications to protect their users and liquidity from the negative impacts of MEV, while also giving them the opportunity to capture the value that would otherwise flow to Ethereum validators.
Imagine this: instead of letting high-frequency traders compete to maximize the extraction of value from each user (with almost all the arbitrage value leaking to the validators and the underlying chain), each application can define its own transaction ordering rules to create a more customized, efficient, and fair system for its users. This marks a shift from attempting to solve MEV at the network layer to solving it at the most important place - the application layer.
Background
The concept of Application-Specific Sequencing (ASS) stems from Matheus' research on Verifiable Sequencing Rules (VSR) in decentralized exchanges (DEXes). Matheus proved that VSR can improve trade execution and mitigate MEV by reducing the influence of miners on transaction ordering. Subsequently, Tarun expanded on this idea, demonstrating how application-specific ordering rules can significantly impact the payoff functions of protocol participants (such as users, validators, and sequencers).
Here, the payoff function represents the economic value of a specific transaction ordering. This value reflects the profits or utility that protocol participants derive from the transaction ordering, showing how ordering affects their financial outcomes. Payoff functions have two key characteristics:
Non-smooth payoffs: Tiny changes in ordering can lead to large fluctuations in MEV.
Non-monotonic payoffs: Tiny changes in ordering may increase or decrease MEV, but the direction of change is inconsistent.
When payoff functions exhibit both of these characteristics, optimizing the ordering strategy becomes highly complex. In such cases, more sophisticated and customized approaches are needed at the application layer to ensure fair outcomes for users and a sustainable DeFi ecosystem.
How Does Application-Specific Sequencing Work?
To understand ASS, we first need to review the existing transaction supply chain.
In the current system:
Transactions are sent to a public or private mempool.
Builders collect these transactions and package them into blocks.
Builders compete in a block auction, and the winning block is included in the blockchain, with the value of their bid paid to the proposer of that block.
In contrast, applications based on ASS have the following characteristics:
Restricted Sequencing Rights: This restriction ensures that only designated sequencers or staked validators can interact with the application's contracts, preventing malicious actors from bypassing the application's internal value distribution logic.
Application-Specific Mempool: Users no longer submit transactions to the public mempool, but instead send their intents to the application-specific mempool. These intents are then collected and processed by the application-specific sequencers.
Order-Agnostic Outcomes: To execute the ordering rules and provide the best economic returns for the target users, ASS transactions need to be order-agnostic with respect to how builders order other transactions. This is achieved by ensuring that the application's state is controlled by its own consensus mechanism. ASS orders are bundled and sent to builders for inclusion. Since this bundle does not conflict with the state accessed by other applications, its position in the block is irrelevant.
Through these basic principles, ASS allows any on-chain application to regain sovereignty over its execution and contract state, enabling sovereign applications.
Real-World Case: Angstrom
As a real-world example of a sovereign application, Angstrom is a hook for UniswapV4 that protects its liquidity providers from the adverse effects of centralized exchange (CEX) and decentralized exchange (DEX) arbitrageurs, while also protecting traders from "sandwich attacks". The Angstrom node network reaches consensus in parallel with Ethereum on the set of transactions to be executed. The process is as follows:
CEX-DEX arbitrageurs bid to become the first to execute an exchange through the AMM (with no fees).
Meanwhile, users submit their pre-arranged swap operations as signed limit orders to Angstrom's mempool.
The Angstrom network runs a consensus protocol and forms a bundle, where the first trade is the highest-bidding arbitrage trade. The bid amount is proportionally distributed to the underlying liquidity providers within the swap range. All other valid limit orders and the AMM's liquidity are executed at the same unified clearing price.
This bundle is then sent by the proposed Angstrom node to Ethereum's builders and the public mempool.
Liveness and Trust Assumptions
The core of ASS is a form of partial block construction, where sovereign applications delegate the sequencing rights to a decentralized operator network according to specified ordering rules. As a result, ASS inevitably involves introducing additional liveness and trust assumptions with external parties.
Liveness Assumption
Sovereign applications rely on application-specific sequencers to correctly follow the protocol and provide timely state updates. If there is a liveness breach (e.g., a network partition), users may be unable to interact with certain parts of the application until effective consensus is restored.
Sovereign applications can also limit the scope of contract state updates that depend on their sequencers. This helps minimize the application's external dependencies, so that even in the event of sequencer failure, critical state (such as deposited liquidity) remains accessible.
Trust Assumption
To ensure that sequencers follow the specified ordering rules, sovereign applications can leverage cryptoeconomic solutions (e.g., PoS) or cryptographic methods (e.g., TEE or MPC). The specific approach may vary greatly depending on the application's needs; some may require consensus on execution optimization, while others may focus on ensuring pre-execution privacy through cryptographic mechanisms. There are many tools available to reduce the trust burden on sequencers and meet the unique objectives of each sovereign application.
Resistance to Censorship
There are various types of censorship in the Ethereum ecosystem:
Regulatory Censorship: Builders and relayers review transactions based on OFAC sanction lists. This is currently one of the most prominent forms of censorship on Ethereum, primarily executed by relayers.
Economic Censorship: Motivated attackers can bribe block proposers to censor victim transactions.
Node-Level Censorship: Nodes in the P2P network may refuse to propagate incoming transactions. This can be a significant issue if the protocol assumes that most nodes have the same view on incoming transactions. Additionally, in such protocols, adversaries may be incentivized to split the local view of honest nodes (by only sending transactions to half the nodes at the last slot) and thus halt the protocol.
Many researchers have argued that Ethereum needs better censorship resistance mechanisms. Some proposals, such as the Multiple Concurrent Proposers (MCP) and the Forced Ordering Censorship-Immune List (FOCIL), have emerged and are the focus of ongoing discussions.
Censorship resistance is also a key concern for sovereign applications. Application-specific sequencers may be external entities with various interests in receiving additional private transaction and order flows. For example, application-specific validators acting as market makers may have incentives to censor transactions from competing market makers. Thus, even if the underlying protocol does not engage in censorship, the top-level sovereign applications may still suffer from local censorship.
An example of the ASS review resistance mechanism is Angstrom. To ensure that all valid orders are included in the upcoming epoch, Angstrom nodes must broadcast any verified incoming orders and reach consensus on including them in the proposed transaction bundle. If the transaction bundle is missing the majority of orders observed by the network, the proposer will be penalized. The following is an explanation of the Angstrom review resistance mechanism.
Composability Dilemma
One of the main challenges facing sovereign applications is ensuring the composability of transactions that interact with external contract states. Simply bundling application-specific transactions with arbitrary external transactions would break the order agnosticism necessary to protect sovereign applications and their users. When a single invalid non-ASS transaction is combined with application-specific transactions, it may result in second-order effects that require the restoration of the entire bundle. When this happens, the sovereign application is unable to execute its users' orders within the allocated time period (despite reaching valid consensus), thereby harming the user experience and overall welfare.
However, there are potential solutions to the composability problem, and several teams are exploring various approaches. These approaches include concepts such as pre-confirmation, shared application-specific sequencers and builder commitments, each offering a tradeoff between the degree of composability and trust overhead.
Incorporating Pre-Confirmation
To explain the incorporation of pre-confirmation, we first need to understand how pre-confirmation-based systems work. Pre-confirmation-based systems leverage cryptoeconomic security to ensure that proposers have posted collateral to guarantee the inclusion of a specific set of transactions before a certain time within the current epoch. This guarantee is bounded by the size of the margin posted by the participating proposers.
Incorporating pre-confirmation is a specific form of pre-confirmation-based systems where transaction inclusion is independent of any contract state. Transactions requesting pre-confirmation must be state-agnostic and uncontested, meaning their execution is not affected by their position in the block. By utilizing pre-confirmation, proposers can commit to including non-ASS transactions only when the ASS bundle is included in the same block. This approach provides cryptoeconomically enforced composability between uncontested transactions and the ASS bundle.
However, given the limited composability provided by this solution, the increased complexity and trust overhead may outweigh its benefits for certain sovereign applications. Therefore, it is crucial to explore alternative approaches that can provide a more effective balance between simplicity and functionality.
Shared Application-Specific Sequencers and Builder Commitments
Sovereign applications can utilize application-specific sequencers to manage transaction ordering across multiple applications without relying on proposer commitments. For example, a sequencer handling transactions for multiple sovereign applications can facilitate atomic composability between them, as long as it follows the ordering rules of each application. This shared application-specific sequencer approach can achieve seamless composability and coordination across sovereign applications.
However, for non-sovereign applications, a different solution is needed. Inclusion commitments from block builders participating in the ordering of sovereign application transactions can create atomic composability between non-sovereign and sovereign applications. Builders ensure the specified transaction order between the two types of applications. These builder commitments can bridge the composability gap of ASS.
Illustration of builder commitments for atomic composability between sovereign and non-sovereign dApps (right) and shared application-specific sequencers for atomic composability between sovereign applications (left)
While there are still questions regarding the economic dynamics of builder commitments, the feasibility of pre-confirmation, and potential second-order effects, we believe the composability challenges of ASS will be resolved over time. Teams like Astria and Primev are actively researching and developing improved frameworks for shared ordering and builder commitments. As these advancements progress, composability will no longer be an issue for sovereign applications.
ASS vs. Application-Specific L2 and L1
Currently, dApps must build application-specific chains to control the ordering of their transactions. Concepts like Protocol-Owned Builder (PoB) enable Cosmos L1 to have more expressive ordering rules, helping to capture and redistribute MEV to their applications. Similarly, L2 sequencers with VSR can perform such operations. While both of these solutions allow their applications to order and capture MEV more expressively, ASS is unique in the following ways:
No trust overhead in transaction execution - ASS does not execute or settle ordered transactions. Only the ordering is delegated. The baseline trust assumption extends from the native execution environment (e.g., Ethereum or other L2s).
Obtain liquidity and order flow - Users do not need to bridge. dApps can directly leverage the flow and liquidity within the chain.
Assets remain in the native execution environment, not freezable - Unlike L2s, most ASS do not require users to lock funds in bridging contracts. This design choice provides better security: if the application-specific sequencer fails, the potential damage is limited, as the sequencer can only control transactions within the boundaries set by the smart contract. While some L2 solutions do implement safety features (e.g., emergency exits and forced inclusion), these measures are often difficult to use in practice. After losing connection with L2 updates, users may have to wait several days to activate the emergency exit. Similarly, forced inclusion through L1 typically requires at least a day's delay. Perhaps most importantly, these safety measures often require technical expertise that ordinary users lack, making them impractical for the average person.
Strong-ASS liveness assumption - L2 liveness depends on execution nodes, usually the rollup sequencer, unless sequencing-based. L1 liveness depends on an honest majority of nodes re-executing the corresponding state transition function. The liveness of sovereign applications primarily depends on the underlying execution environment, with smart contracts specifying the parts that need to rely on the application-specific sequencer.
Comparison table of sovereign applications, L2, L2-based, and L1
Conclusion
ASS gives applications complete control over transaction ordering, allowing them to define custom rules without managing the complexity of execution. This control enables applications to govern their execution to optimize user outcomes. For example, on Angstrom, LPs and swappers are treated as first-class participants, directly increasing their economic rewards through custom ordering rules.
Furthermore, ASS can leverage a range of cryptoeconomic and cryptographic tools to enforce the optimality of user-paid fees and implement robust review resistance mechanisms. Cryptoeconomic solutions like staking and slashing can incentivize honest behavior among sequencers, while cryptographic methods like TEE and MPC can enhance privacy and security. With these tools, the design potential of ASS is vast, enabling the creation of more secure, efficient, and user-centric sovereign applications.
While ASS presents many opportunities, challenges such as the lack of native composability still exist. However, solutions like pre-confirmation, shared ASS, and builder commitments offer promising approaches to overcoming these barriers. Although some questions remain, we are committed to improving these methods to provide a smoother and more composable ASS experience.
Our goal is to make DeFi more sustainable, one ASS at a time.
