Interpreting application-specific sorting (ASS) makes DeFi sustainable

Author: Yuki Yuminaga Source: Sorella Translation: Shan Oppa, Bitchain Vision

introduction

Solving the maximum extractable value (MEV) has always been a challenge facing Ethereum.Value supply chains prompt arbitrageurs to frequently operate through various strategies, which often harms the interests of retail users.While many researchers have tried to deal with MEV through protocol-layer change, these efforts have not yet provided satisfactory solutions.Although the current infrastructure and auction mechanisms can effectively capture MEVs in blocks, they do not have fair distribution of the value of capture: Why is the value of MEVs attributed to network validators, rather than being more efficiently captured and internalized by each application itself.?

So application-specific sorting (ASS) came into being.Rather than trying to rewrite rules at the protocol layer, ASS allows individual applications to control how they sort their transactions.By doing so, ASS enables on-chain applications to protect their users and liquidity from negative effects of MEVs, while giving them the opportunity to capture the value that should have flowed to Ethereum validators.

Imagine: instead of allowing high-frequency traders to compete to maximize arbitrage for each user (almost all arbitrage value is leaked to validators and underlying chains), each application can define transaction sorting rules by itself to create a moreCustomized, efficient and fair system.This marks the shift from trying to solve MEVs at the network layer to where it is most important – application layer solutions.

background

The concept of application-specific sorting (ASS) comes from Matheus’s research on verifiable sorting rules (VSR) in decentralized exchanges (DEXs).Matheus proves that VSR can improve transaction execution and mitigate MEV by reducing the impact of miners on transaction sorting.Tarun then expanded this philosophy to show how application-specific sorting rules significantly affect the return functions of protocol participants such as users, validators, and sorters.

Here, the return function represents the economic value of a particular transaction sort.This value reflects the profit or utility obtained by agreement participants through transaction sorting, showing how sorting affects their financial results.The return function has two key characteristics:

• Non-smooth return: Small changes in sorting can lead to large fluctuations in MEV.

• Non-monotonous returns: Small changes in sorting may increase or decrease MEV, but the direction of the change is inconsistent.

When the return function has both characteristics, the optimization sorting strategy becomes very complex.In this case, a more complex and customized approach is needed at the application layer to ensure fair results for users and a sustainable DeFi ecosystem.

How does a specific application sort work?

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

In existing systems:

• Transactions are sent to public or private memory pools (mempools).

• The builder collects these transactions and packages them into blocks.

• The builders compete for block auctions, and the winner’s block will be included in the blockchain, and the value they bid will be paid to the proposer of the block.

On the contrary, ASS-based applications have the following characteristics:

• Restricted sorting rights: This restriction ensures that only the specified sorter or staking validator can interact with the application’s contract, preventing maliciously bypassing the application’s internal value allocation logic.

• Application-specific memory pool: The user no longer submits transactions to the public memory pool, but sends its intent to the application-specific memory pool.These intents are then collected and processed by the application-specific sorter.

• Results that are not related to order: In order to execute sorting rules and provide the target user with the best financial returns, ASS transactions need to be independent of the builder’s sorting of other transactions.This is achieved by ensuring that the state of the application is controlled by its consensus mechanism.ASS orders are integrated into a bundle and sent to the builder for inclusion.Since the bundle does not conflict with the state accessed by other applications, its location in the block is irrelevant.

Through these basic principles, ASS enables any application on a chain to regain sovereignty over its execution and contract state, thus achieving sovereign application.

Actual case: Angstrom

As a practical example of sovereign application, Angstrom is a hook for UniswapV4 to protect its liquidity providers from adverse effects of centralized exchanges (CEX) and decentralized exchanges (DEX) arbitrageurs, while also protecting transactionsThose who are protected from “mezzanine attacks”.Angstrom node network and Ethereum agree on the set of transactions to be executed in parallel.The process is as follows:

• CEX-DEX arbitrageurs win the first transaction right to be exchanged through AMM (no handling fee).

• Meanwhile, the user sends his scheduled exchange operations to Angstrom’s memory pool in the form of a signed limit order.

• The Angstrom network runs the consensus protocol and forms a bundle where the first exchange is the highest bidder arbitrage deal.The bid amount is distributed prorated to the underlying liquidity provider within the exchange scope.All other valid limit orders and AMM liquidity is executed at the same uniform liquidation price.

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

Activity and trust assumptions

At the heart of ASS is a partial block building form where sovereign applications delegate sorting rights to decentralized operator networks according to prescribed sorting rules.Therefore, ASS inevitably involves external parties introducing additional activity and trust hypotheses.

Activity assumptions

Sovereign applications rely on application-specific sorters to correctly follow protocols and provide status updates in a timely manner.If there is a life-destruction (such as network partitioning), the user may not be able to interact with certain parts of the application until a valid consensus is restored.

Sovereign applications can also limit the scope of contract states, which are updated depending on their sorter.This helps minimize external dependencies of the contract so that critical states such as deposited liquidity are still accessible even in the event of a sorter failure.

Trust assumption

To ensure that the sorter complies with prescribed sorting rules, sovereign applications can leverage crypto-economic solutions (such as PoS) or encryption methods (such as TEE or MPC).Specific approaches may vary greatly depending on application needs; some may require consensus on execution optimization, while others may focus on ensuring privacy before execution through encryption mechanisms.There are many tools available to reduce the trust overhead of the sorter and meet the unique goals of each sovereign application.

Resist the review

There are many types of censorship in the Ethereum ecosystem:

1. Regulatory Review: Builders and repeaters review transactions under the OFAC sanctions list.This is one of the most prominent forms of censorship on Ethereum at present, mainly performed by repeaters.

2. Economic Review: Motivated Attackers can bribe block proposers to review victimized transactions.

3. Node Level Review: Nodes in a P2P network may refuse to propagate incoming transactions.This can be a big problem if the protocol runs optimally when most nodes assume the same view of incoming transactions.Furthermore, in such protocols, the adversary may be motivated to split the local view of the honest node (by sending transactions to only half of the nodes at the end of the slot) and thus stop the protocol.

Many researchers have said Ethereum needs a better anti-censorship mechanism.Some proposals such as Multi-Concurrency Proposaler (MCP) and Fork Select 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 sorters may be external entities with various interests in receiving additional private transactions and order flows.For example, an application-specific validator as a market maker has the motivation to review transactions sent by a competitive market maker.Therefore, even if the underlying protocol is not reviewed, top-level sovereign applications may experience local censorship.

An example of ASS’s censorship boycott mechanism is Angstrom.To ensure that all valid orders are included in the upcoming time period, the Angstrom node must broadcast any verified incoming orders and reach consensus on inclusion of them in the proposed transaction package.Proposers will be punished if the transaction package lacks orders observed by most networks.Here is an explanation of Angstrom’s review of the boycott mechanism.

Composability dilemma

One of the main challenges facing sovereign applications is ensuring composability of transactions that interact with external contract states.Simply bundling application-specific transactions with arbitrary external transactions undermines order agnosticity necessary to protect sovereign applications and their users.When a single invalid non-ASS transaction is combined with an application-specific transaction, a second-order effect of restoring the entire bundle may occur.When this happens, the sovereign application is unable to execute its user’s orders (although a valid consensus is reached), thus damaging the user experience and overall welfare.

However, there are still potential solutions to the composability problem, and various teams are exploring several of them.These schemes include concepts including pre-confirmation, shared application-specific sorter and builder commitment, each providing a trade-off between degree of composability and trust overhead.

Included in advance confirmation

To explain incorporating pre-confirmation, you must first understand the working principle based on pre-confirmation.Based on pre-confirmation, utilizing crypto-economic security, ensures that the proposer has proposed collateral to ensure that a specific transaction set is included before a certain period of the current period.This guarantee is subject to the margin size issued by the participating proposers.

Inclusion of pre-confirmation is a special form of pre-confirmation based in which transaction inclusion is not related to any contract status.Transactions requesting the inclusion of pre-confirmation must be state-free and uncontroversial, meaning that their execution is not affected by their position in the block.By leveraging inclusion pre-confirmation, the proposer can promise to include non-ASS transactions only if the ASS bundle is included in the same block.This approach provides crypto-economic composability between uncontroversial transactions and ASS bundles.

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 important to explore alternatives that can provide a more effective balance between simplicity and functionality.

Share specific application sorters and manufacturer commitments

Sovereign applications can use application-specific sorters to manage transaction sorting across multiple applications without relying on the proposal’s commitment.For example, a sorter that handles multiple sovereign application transactions can promote atomic composability between them as long as it follows the sorting rules for each application.This shared application-specific sorter approach enables seamless composability and coordination across sovereign applications.

However, for non-sovereign applications, different solutions are needed.Transaction inclusion of block builders involved in sovereign application sorting promises to create atomic composability between non-sovereign and sovereign applications.The builder ensures that the order of transactions is specified between the two types of applications.This builder promises to bridge the composability gap in ASS.

Builder Commitment Illustration of Atomic Composability Between Sovereign and Non-Sovereign DApps (right) and Shared Application Specific Sorter Illustration of Atomic Composability Between Sovereign Applications (left)

While there are still questions about the economic dynamics of builder commitments, the feasibility of incorporating pre-identifications, and the potential second-order effects, we believe that the composability challenge of ASS will be addressed over time.Teams such as Astria and Primev are actively researching and developing improved frameworks shared sorting and builders’ commitments.As these advancements advance, composability will no longer be a problem for sovereign applications.

ASS with application-specific L2 and L1

Currently, dApps must build application-specific chains to control the sorting of their transactions.Concepts such as protocol-owned builders (PoBs) allow Cosmos L1 to have more expressive collations that help capture MEVs and reassign them to their applications.Similarly, an L2 sorter with VSR can do such operations.While both solutions allow their applications to sort and capture MEVs more expressively, ASS is unique for the following features.

1. Transaction execution does not incur trust overhead – ASS does not execute or settle sorted transactions.Only sorting is delegated.Baseline trust assumptions extend from native execution environments such as Ethereum or other L2.

2. Get liquidity and order flow – users do not need to bridge.dApps can directly utilize traffic and liquidity in the chain.

3. Assets remain in native execution environments and cannot be frozen – unlike L2, most ASSs do not require users to lock funds in bridge contracts.This design choice provides better security: if an application-specific sorter fails, the potential damage is limited, because the sorter can only control transactions within the boundaries set by the smart contract.While some L2 solutions do implement security features such as emergency exits and mandatory inclusion, these measures are often difficult to use in practice.After losing connection to the L2 update, users may have to wait a few days before activate the emergency exit.Likewise, enclosure via L1 usually requires at least one day delay.Perhaps most importantly, these security measures usually require technical expertise that most users do not have and are therefore not practical for the average person.

4. Strong-ASS Activity Assumption – The activity of L2 depends on the execution node, usually a rollup sorter, unless based on sorting.The activity of L1 depends on the honest majority of nodes re-execute the corresponding state transition function.The activity of a sovereign application depends primarily on the underlying execution environment, and smart contracts can specify the parts that need to rely on the application-specific sorter.

Sovereign Applications, L2, L2 and L1 based comparison table

in conclusion

ASS gives applications full control over transaction sorting, allowing them to define custom rules without managing the complexity of execution.This control allows the application to control its execution to optimize the user’s results.For example, on Angstrom, LPs and exchangers are seen as top-notch players, directly improving their financial benefits through custom sorting rules.

In addition, ASS can leverage a range of crypto economy and encryption tools to force the optimality of user payments and implement a powerful censorship boycott mechanism.Crypto-economic solutions such as staking and slashing can inspire honest behavior among sorters, while encryption methods such as TEE and MPC can enhance privacy and security.With these tools, ASS has great design potential to create safer, more efficient, user-centered sovereign applications.

Although ASS offers many opportunities, challenges such as the lack of native composability remain.However, solutions including pre-confirmation, shared ASS and builder commitments provide promising ways to overcome these obstacles.Although there are still some issues, we are committed to improving these approaches to provide a smoother, more composable ASS experience.

Our goal is to make DeFi more sustainable with one ASS at a time.