Understanding Application Specific Sorting (ASS) to make DeFi sustainable

Author: Yuki Yuminaga Source: Sorella Translation: Shan Ouba, Golden Finance

Introduction

Solving the Maximum Extractable Value (MEV) has always been a challenge for Ethereum. The value supply chain encourages arbitrageurs to frequently operate through various strategies, often at the expense of retail users. While many researchers have tried to address MEV through protocol-level changes, these efforts have not yet provided a satisfactory solution. While the current infrastructure and auction mechanisms are able to effectively capture MEV in blocks, they do not fairly distribute the captured value: why should the value of MEV be attributed to network validators, rather than being more effectively captured and internalized by each application itself?

So Application-Specific Sorting (ASS) came into being. Instead of trying to rewrite the rules at the protocol level, ASS gives each application control over how its own transactions are ordered. By doing so, ASS enables on-chain applications to protect their users and liquidity from the negative impacts of MEV while giving them the opportunity to capture the value that would otherwise go to Ethereum validators.

Imagine: instead of having high-frequency traders compete to maximize arbitrage for each user (with almost all of the arbitrage value leaking to the validators and the underlying chain), each application can define its own transaction sorting rules, creating a more customized, efficient, and fair system for its users. This marks a shift from trying to solve MEV at the network layer to solving it where it matters most - the application layer.

Background

The concept of application-specific sorting (ASS) originated from Matheus's research on verifiable sorting rules (VSRs) in decentralized exchanges (DEXs). Matheus demonstrated that VSRs can improve transaction execution and mitigate MEV by reducing the impact of miners on transaction sorting. Tarun then expanded on this idea, showing how application-specific sorting rules can significantly affect the reward function of protocol participants such as users, validators, and sorters.

Here, the reward function represents the economic value of a specific ordering of transactions. This value reflects the profit or utility that a protocol participant gains from ordering transactions, showing how the ordering affects their financial outcomes. The reward function has two key characteristics:

• Non-smooth returns: Small changes in the ordering can lead to large fluctuations in MEV.

• Non-monotonic returns: Small changes in the ordering may increase or decrease MEV, but the direction of change is not consistent.

When a reward function has both of these characteristics, optimizing the ordering strategy becomes very complex. In this case, a more complex and customized approach is needed at the application layer to ensure fair outcomes for users and a sustainable DeFi ecosystem.

How does application-specific ordering work?

To understand ASS, first we need to review the existing transaction supply chain.

In the existing system:

• Transactions are sent to a public or private mempool.

• Builders collect these transactions and package them into blocks.

• Builders compete in block auctions, and the winner's block will be included in the blockchain, and the value of their bid will be paid to the proposer of the block.

In contrast, ASS-based applications have the following characteristics:

• Restricted sorting rights: This restriction ensures that only designated sorters or stake validators can interact with the application's contracts, preventing malicious bypassing of the application's internal value distribution logic.

• Application-specific memory pool: Instead of submitting transactions to the public memory pool, users send their intentions to the application-specific memory pool. These intentions are then collected and processed by the application-specific sorter.

• Order-independent results: In order to enforce the sorting rules and provide the best economic returns for the target users, ASS transactions need to be independent of the builder's ordering of other transactions. This is achieved by ensuring that the state of the application is controlled by its consensus mechanism. ASS orders are aggregated into a bundle and sent to the builder for inclusion. Since the bundle does not conflict with state accessed by other applications, its position in the block is irrelevant.

Through these basic principles, ASS enables applications on any chain to regain sovereignty over their execution and contract state, thereby achieving sovereign applications.

Actual Case: Angstrom

As a practical example of sovereign application, Angstrom is a hook of UniswapV4 to protect its liquidity providers from the adverse effects of centralized exchanges (CEX) and decentralized exchanges (DEX) arbitrageurs, while also protecting traders from "sandwich attacks". The Angstrom node network reaches consensus on the set of transactions to be executed in parallel with Ethereum. Here’s how it works:

• CEX-DEX arbitrageurs bid for the right to be the first to swap through the AMM (without fees).

• Meanwhile, users send their scheduled swaps as signed limit orders to Angstrom’s memory pool.

• The Angstrom network runs the consensus protocol and forms a bundle where the first swap is the highest-bid arbitrageur’s trade. The bid amount is proportionally distributed to underlying liquidity providers within the swap range. All other valid limit orders and AMM liquidity are executed at the same unified clearing price.

• The bundle is then sent by the proposing Angstrom node to Ethereum’s builder and public memory pools.

Liveness and Trust Assumptions

At its core, ASS is a form of partial block construction where sovereign applications delegate ordering rights to a decentralized network of operators in accordance with prescribed ordering rules. As a result, ASS inevitably involves external parties that introduce additional liveness and trust assumptions.

Liveness Assumptions

Sovereign applications rely on application-specific orderers to correctly follow the protocol and provide state updates in a timely manner. In the event of a liveness disruption (e.g., a network partition), users may be unable to interact with parts of the application until valid consensus is restored.

Sovereign applications can also limit the scope of contract state that depends on its collator for updates. This helps minimize the contract's external dependencies so that critical state (such as deposited liquidity) remains accessible even in the event of a collator failure.

Trust Assumptions

To ensure that collators adhere to prescribed collating rules, sovereign applications can leverage cryptoeconomic solutions (e.g., PoS) or cryptographic approaches (e.g., TEE or MPC). Specific approaches can vary widely depending on the needs of the application; some may require consensus on execution optimizations, while others may focus on ensuring pre-execution privacy through cryptographic mechanisms. There are many tools available to reduce the trust overhead of collators and meet the unique goals of each sovereign application.

Censorship Resistance

There are multiple types of censorship in the Ethereum ecosystem:

1. Regulatory censorship: builders and relayers censor transactions against OFAC sanctions lists. This is currently one of the most prominent forms of censorship on Ethereum and is primarily performed by relayers.

2. Economic censorship: motivated attackers can bribe block proposers to censor victim transactions.

3. Node-level censorship: nodes in a P2P network may refuse to propagate incoming transactions. This can be a big problem if the protocol operates optimally under the assumption that most nodes have the same view of incoming transactions. Furthermore, in such protocols, an adversary may be incentivized to split the local view of honest nodes (by sending transactions to only half of the nodes at the end of a slot) and thus halt the protocol.

Many researchers have expressed the need for better censorship resistance in Ethereum. Several proposals, such as Multiple Concurrent Proposers (MCP) and Fork Choice Forced Inclusion List (FOCIL) have surfaced and become the focus of ongoing discussion.

Censorship resistance is also a major concern for sovereign applications. Application-specific orderers may be external entities with various interests in receiving additional private transactions and order flow. For example, an application-specific validator that acts as a market maker has an incentive to censor transactions sent by competing market makers. Therefore, even if the base protocol is not censored, sovereign applications on top may be subject to local censorship.

An example of a censorship resistance mechanism for ASS is Angstrom. To ensure that all valid orders are included in the upcoming slot, Angstrom nodes must broadcast any validated incoming orders and reach consensus on their inclusion in the proposed transaction package. If the transaction package lacks orders observed by the majority of the network, the proposer will be punished. Below is an illustration of Angstrom’s censorship resistance mechanism.

The Composability Dilemma

One ​​of the main challenges facing sovereign applications is ensuring composability of transactions that interact with external contract state. Simply bundling application-specific transactions with arbitrary external transactions undermines the order agnosticism necessary to protect sovereign applications and their users. When a single invalid non-ASS transaction is combined with an application-specific transaction, it can have the second-order effect of reverting the entire bundle. When this happens, the sovereign application is unable to execute its users’ orders within the allotted time period (despite reaching valid consensus), thereby harming the user experience and overall welfare.

There are potential solutions to the composability problem, however, and various teams are exploring several of them. These include concepts such as inclusion preconfirmations, shared application-specific sequencers, and builder commitments, each of which offers a tradeoff between the degree of composability and trust overhead.

Inclusion Preconfirmations

To explain inclusion preconfirmations, it is first important to understand how preconfirmation-based works. Preconfirmation-based leverages cryptoeconomic security to ensure that a proposer has put up pledged collateral to guarantee inclusion of a specific set of transactions before a certain time in the current epoch. This guarantee is limited by the size of the security deposit posted by the participating proposers.

Inclusion preconfirmations are a special form of preconfirmation-based where transaction inclusion is independent of any contract state. Transactions requested for inclusion in preconfirmations must be state-independent and non-contentious, meaning that their execution is not affected by their position in a block. By leveraging inclusion pre-confirmations, a proposer can commit to including non-ASS transactions only if an ASS bundle is included in the same block. This approach provides cryptoeconomically enforced composability between non-disputed transactions and ASS bundles.

However, given the limited composability provided by this solution, the added complexity and trust overhead may outweigh its benefits for certain sovereign applications. It is therefore important to explore alternative approaches that can provide a more effective balance between simplicity and functionality.

Shared Application-Specific Sequencers and Maker Commitments

Sovereign applications can use application-specific sequencers to manage transaction ordering across multiple applications without relying on proposer commitments. For example, a sequencer that processes 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 enables seamless composability and coordination across sovereign applications.

However, for non-sovereign applications, a different solution is needed. Transaction inclusion commitments by block builders participating in sovereign application ordering can create atomic composability between non-sovereign and sovereign applications. Builders ensure a specified transaction ordering between both types of applications. Such 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 sorters for atomic composability between sovereign applications (left)

While questions remain about the economic dynamics of builder commitments, the feasibility of incorporating pre-confirmations, and potential second-order effects, we believe that the composability challenges of ASS will be resolved over time. Teams such as Astria and Primev are actively researching and developing improved frameworks for shared sorting and builder commitments. As these advances advance, 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 such as Protocol Owned Builders (PoB) enable Cosmos L1 to have more expressive ordering rules that help capture and redistribute MEV to their applications. Similarly, L2 orderers with VSRs can also perform such operations. While both solutions allow their applications to more expressively order and capture MEV, ASS is unique due to the following characteristics. Transaction execution does not incur trust overhead - ASS does not execute or settle ordering transactions. Only ordering is delegated. Baseline trust assumptions are extended from native execution environments such as Ethereum or other L2s.

Sovereign Applications, L2, Comparison Table of L2-based and L1-based

Conclusion

ASS gives applications full control over transaction ordering, enabling them to define custom rules without having to manage the complexity of execution. This control allows applications to control their execution to optimize outcomes for users. For example, on Angstrom, LPs and exchangers are treated as first-class participants, directly improving their economic gains through custom ordering rules.

In addition, ASS can leverage a range of cryptoeconomic and cryptographic tools to enforce optimality of user payments and implement strong censorship resistance mechanisms. Cryptoeconomic solutions such as staking and slashing can incentivize honest behavior among orderers, while cryptographic methods such as TEE and MPC can enhance privacy and security. With these tools, ASS has great design potential to create more secure, efficient, and user-centric sovereign applications.

Despite the many opportunities ASS offers, challenges such as lack of native composability remain. However, solutions such as pre-confirmation, shared ASS, and builder commitments provide promising approaches to overcoming these obstacles. Although some issues 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.