Attacks in blockchain are undeniable. The case of Peraire-Bueno brothers stealing $25 Million through an MEV attack is an example of this. Also, hundreds of millions of dollars are lost every year due to MEV and sandwich attacks. Over the years, several innovations have been rolled out to tackle MEV issues, and the latest one is application-specific sequencing, commonly known as ASS.
By switching to app-specific sequencers , dApps get access to full sovereignty over transaction sequencing, thus getting the freedom to build highly intent-specific dApps. While ASS is an innovative concept and it has been there for a while, there is still some sort of confusion, counterarguments, and a lack of awareness around it. Hence, let’s do an in-depth analysis of app-specific sequencing. We’ll understand its core concept, working mechanism, comparison with L1/L2, and the possibilities it opens for dApps.
The challenges with existing sequencing methods
A bunch of innovations have been introduced to eliminate the challenge of MEV (Maximum Extractable Value) and ensure fairness in dApps and user experience. Proposer-builder separation (PBS) and Multiple Concurrent Proposers (MCP) are among the two popular concepts that dApps often use. PBS was proposed before MCP due to challenges such as the centralization of the sequencer. In PBS, sequencer function is controlled by the respective team, and its mempool remains private. While this maximally eliminated the MEV issue, the concept of a centralized sequencer could not endure in long run.
Ethereum’s rising concern for centralization and censorship risks led to creation of MCP. The idea of MCP is to enable parallel block proposals, i.e., individual proposers for each account. This definitely solved the decentralization issue and reduced the risks related to centralised proposers. However, MCP also faced challenges like reordering complexities, higher switching costs, and a lack of ordering rules. As a solution to the challenges of PBS and MCP, application-specific sequencing has been brought forward.
Deep dive into Application-Specific Sequencing
Application-specific sequencing is a key innovation in Layer2 paradigm to offer sovereignty
for applications without spinning up a new chain. A good example can be ‘userOps’. ASS-based dApps can program their custom sequencing method and start sequencing userOps in a more composable way. With ASS, applications have the flexibility to–
-Control their transaction ordering process.
-Implement custom execution policies.
-Execute functions autonomously.
Control on transaction ordering refers to dApp’s ability to control how users’ transactions (both for front-end and smart contract) are ordered, implement customs, and use case-specific parameters for further ordering processes. These transactions are specific to application’s operations, touching its state. This more refined ordering mechanism helps lower the negative consequences of MEV.
Speaking about policy execution, ASS enables dApps to implement execution policies that define what transactions will be ordered under which condition. This means dApps can set up scripts off-chain to monitor sequencer’s behavior and revoke admin privilege if any suspicious activity is detected. This avoids problems like the protocol’s TVL being compromised and MEV issues and ensures a decentralization ethos. Regarding, the autonomous function execution, it opens possibilities for smart contracts to customize the execution function based on user-centric needs.
The end motive for all these approaches is to enable sovereignty for dApps, enabling them to sequence and operate with their custom fee structure while retaining the composability of general-purpose Layer2s, the best of both aspects.
How application-specific sequencing works?
To better understand the working mechanism of ASS, let’s look at the two different transaction ordering methods; one without ASS and another with ASS.
-Transactions are coming out from public and private mempools.
-Transactions go to the builder.
-Send to the Relayer (the auctioneer).
-Finally, transactions reach the block proposers, where block will be created.
With ASS, there will be an additional ‘App-specific mempool’, and the transaction ordering/supply will be like this:
-With the app-specific mempool, the sequencer network will perform transaction sequencing and develop a large bundle (Angstrom Bundle).
-The bundle is submitted to the builder along with the transactions coming from public and private mempools.
-Later on, transactions will be processed through Relayers and Proposers.
Key Properties of App-specific Sequencing
Following are the key properties that underpin the whole application-specific sequencing process:
1. Controlled Sequencing Rights: ASS-powered applications achieve the ‘app-specific’ effect by setting up their own delegated sequencers. This means applications can have a different consensus mechanism but with pre-defined rules about what all sequencers can participate in sequencing, allowing for predictable and secure transaction sequencing.
2. App-Specific Mempools: ASS allows dApps to set up & manage their own use case-specific mempools that grant them full control over how network’s state is updated and through which sequencer (as discussed in the previous section). This granularity in the state comes naturally with app-specific mempools through a bunch of signed transactions propagated within the ASS infrastructure.
3. Order Agnostic Outcomes: As the most important aspect of ASS, order-agnostic outcomes ensure consistency in transaction execution, allowing the sequencer to achieve more efficient task execution as defined by the dApp.
What all possibilities App-specific sequencers open for dApps?
Offers sovereignty & autonomy to dApps:
One of the main ideas of ASS is to bring back sovereignty to dApps. When we say ‘sovereignty’, it means that the application can control their state, state updates, and all the execution of all the transactions happening from the contracts. All these are possible because dApp is able to achieve sovereignty over its sequencing process through the privacy controlled by block builders. Additionally, sequencing allows dApps to be hyper-optimized for the users. This optimization refers to ‘economic payoffs’ (paper). This includes better price optimization, lower transaction costs, and improved overall user experience.
Regarding autonomy, dApps with ASS can use on-chain agents to maintain interaction with other protocols directly. Think of a dApp optimized for fully autonomous trading; this is a major step to bring ‘autonomous capitalism’ in DeFi, removing the biggest issues like fragmented liquidity.
Clear revenue source with MEV capture:
The ability to control transactions opens up very feasible design possibilities for applications, allowing them to generate higher revenue with more refined and controlled ‘MEV extraction.’ That’s because ASS offers applications with full control to reorder transactions based on their priority fees submitted on the underlying Layer1. This eliminates the issue of MEV spamming, which often leaves out significant value uncaptured. Here’s a tweet from Farcaster Labs further highlighting this:
Supports user-centric design:
Another exciting feature of ASS is the support for user-centric design. Let’s see how:
User-centric rule for economic payoffs- One of the significant features of ASS is its design to be user-centric. The rules governing sequencing and execution should prioritize the users’ economic benefits. Example-a trading dApp like CoW DAO can use ASS to achieve the best price execution based on the users’ intentions, ensuring that the transaction outcomes are as favorable as possible for the user.
Off-chain computation for complex sequencing- Computation in ASS can be initially (or at some point) complex for dApps. Hence, ASS allows applications to move peer-to-peer move to off-chain. This allows for enhanced scalability and efficiency as a substantial volume of transactions are off-loaded.
Intent-based orders/signed messages- All the orders or signed messages that ASS receives are intent-based. For example, defined limit order for a trade. Based on the given intent, ASS ensures to achieve the best results from the messages it receives.
Interoperable nature:
ASS is designed to have seamless compatibility with global state (while maintaining its own local state), thus enabling cross-chain interoperability without needing any bridging solution or third-party services. dApps using ASS can basically coordinate through block building, or they can design a specific consensus enabled with assets transfer rules.
Scaling & Customizability:
Critical functionality of a dApp, for example- AMM, is largely dependent on the sequencing rules. By granting dApps control over the sequencing, ASS opens possibilities for next-gen dApps. For example, a few additions to application’s existing construction can allow for additional customization, like the flexibility to choose programming language or customization in the execution environment itself. That said, it depends largely on the ASS you select.
Comparing ASS with L1, L2s, and Based L2 Rollups
One question that often arises for ASS is’ “why app-specific sequencer and not a sovereign L1/L2, or based L2s? Here’s a tweet from Celestia’s COO highlighting this:
The below comparative table answers it well:
**Transition to App-specific sequencing with Cero **
App-specific sequencing is definitely a future-ready concept, and hence dApps have been adopting ASS on a rapid scale. If you want to achieve dApp sovereignty and eliminate MEV issues, Cero can be your ideal solution. Cero’s decentralized sequencing network is optimized for all new-age sequencing needs, including application-specific, shared, and dedicated sequencing. Also, if you have a custom need for a sequencer (for appchains, L1, L2s, or rollups), Cero is ready to assist you. Get your early access to Cero here. Or, you can connect with our experts to understand more about Cero, its features & offerings. Send all your queries via email or for an upfront discussion, and schedule a 1-to-1 meeting.