Can applying a specific sorting scheme really solve all problems?

Author: Pavel Paramonov Source: X, @paramonoww Translation: Shan Ouba, Golden Finance

Many people think that "ASS is everything you need", thinking it is a complete solution with little need for improvement. However, ASS does not solve all problems, and it also has some trust assumptions.

1. Self-serializing dApp is a partial block builder

When a transaction bundle enters the block, the dApp has the right to extract its own MEV (maximum extractable value) from it, and obtain its own value from other "members" in the MEV supply chain such as proposers, searchers, and builders. However, this concept is not perfect (nothing in the crypto world is perfect), and it may also have some trust assumptions.

2. Inclusive Games

The challenge faced by self-serialized dApps is that the higher the value of the bundle, the greater the demand for guaranteed inclusion in the block. If transactions that capture MEV are not included in the block, then they may become completely unprofitable, which not only hurts other transactions that cannot generate MEV, but also hurts users.

This is an interesting scenario to think about:

• dApp has the ability to capture all MEV generated by it

• but if you not only lose the opportunity to MEV, but also the users who bring value to the platform (for example, if the AMM continues to fail, who will use it), there is no point in doing so.

The most interesting thing is that proposers also need to make a profit, which creates a lose-lose situation:

• Self-serializing dApps lose MEV because the bundle is not included in the block

• Proposers lose MEV because they cannot unpack and reorder atomic bundles (although they can choose other transactions)

3.ASS dApps should not hurt ordinary users and liquidity providers (LPs) by extracting MEV

As we all know, MEV is mostly generated and extracted through toxic traffic. LPs lose most of the benefits they get from uninformed traffic because of MEV. Attracting liquidity to a platform is one of the hardest things in crypto, and AMMs should focus on the fair distribution of MEV to LPs, which may help reduce impermanent loss.

In the current reality, actively managing LP positions (or even multiple LP positions) can be considered a full-time job. If it is a sandwich attack, return value to traders; if it is arbitrage between centralized and decentralized exchanges, return value to LPs. So, the question is how much return should they get and how much value should the dApp keep?

4. What if the size of the bundle conflicts with the block size of the underlying chain?

Obviously, not all dApps will be self-serialized (at least in the near future). The block size (or transaction batches) is limited; if there is no limit, there is no blockchain or "blockchain". Assuming a block can hold at most 100 transactions, several scenarios could occur:

• A dApp sends a bundle of 100 transactions, filling the entire block. How profitable is it for other "members" in the MEV supply chain to include it, propose a block, and execute it?

• A dApp sends a bundle of 99 transactions, with 1 slot left. Does the proposer have enough incentive to include this bundle? (Unless they do some kind of collaboration, like pre-confirmation)

• Two dApps send bundles. The first bundle contains 60 transactions, the second contains 50 transactions. Obviously, only one bundle can be included.

The point is that the first bundle generates more MEV than the second, but from another perspective, it is more beneficial to include the second bundle because the 50 transactions of other non-self-serializing dApps combined with the bundle can create more value for the block.

So who should be included? Who is the most profitable in the block, not just within the bundle?

The solution that can be implemented is FCFS (First Come First Served), but it does not guarantee accuracy because the delay still exists.

How to ensure that serialization is beneficial to everyone, rather than only one participant benefiting and others (LPs, users) being deprived of value?

A potential solution is to set specific serialization rules, and only those who follow these rules have the right to order bundles. This is important because improper serialization can lead to security vulnerabilities.

For AMM trading pairs, using greedy verifiable rules can prevent transactions from being squeezed in specific AMM pools. However, most DEX transactions are multi-exchange transactions, so other ways are needed to provide MEV-resistant guarantees.

Still early stages!

There are currently multiple ways to do self-serialization, and I was inspired by @SorellaLabs' approach on this topic. We are still in the early stages of implementing self-serialization (or ASS, as @ballsyalchemist calls it), and different infrastructures have different tradeoffs.

The goal of ASS is to let dApps be responsible for their serialization, without caring about the execution (which is handled by the chain). While ASS on L1 is relatively clear, it is more attractive on L2 because there is only one serializer to deal with, and L2 can bring more content by enforcing local serialization rules.

There is huge room for growth! (Except for block space)