Can applying specific sorting schemes really solve all problems?

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

Many people believe that "ASS is all you need," thinking it is a complete solution that requires little improvement. However, ASS cannot solve all problems and also has some trust assumptions.

1. Self-serializing dApp is part of the Block builder

When a transaction bundle enters a Block, the dApp has the right to extract its own MEV (maximal extractable value) from it, obtaining its value from other 'members' in the MEV Supply Chain, such as proposers, searchers, and builders. However, this concept is not perfect (nothing is perfect in the encryption world), and it may also have some trust assumptions.

2. Inclusive Games

The challenge for self-liquidating dApps is that the higher the bundled value, the greater the demand for inclusion in the Block. If transactions capturing MEV are not included in the Block, they may become completely unprofitable, which not only harms other transactions that cannot generate MEV, but also harms users.

This is an interesting thought scenario:

• dApp has the ability to capture all MEV generated by it.
• But if not only the opportunity for MEV is lost, but also the users who bring value to the platform are lost (for example, if the AMM continues to fail, who would still use it), then it would be meaningless to do so.

What is most interesting is that the proposer also needs to profit, creating a situation where both sides lose.

• Self-serializing dApps lose MEV because bundling is not included in the Block
• The proposer loses MEV because they cannot unbundle and reorder atomic bundles (although they can choose other transactions)

3. The ASS dApp should not harm ordinary users and Liquidity Providers (LPs) by extracting MEV

As is well known, MEV is mostly generated and extracted through toxic traffic. LPs lose most of their income from non-informed traffic because of MEV. Attracting Liquidity to the platform is one of the most difficult things in the encryption field, and AMM should follow the fair distribution of MEV to LPs, which may help reduce Impermanent Loss.

In the current reality, actively managing LP positions (even multiple LP positions) can be considered a full-time job. If it's a sandwich attack, the value is returned to the traders; if it's Arbitrage between Centralized Exchange and DEX, the value is returned to LPs. So, the question is how much return they should get, and how much value should the dApp retain?

4. What should I do if the bundled size conflicts with the Block size of the underlying chain?

Obviously, not all dApps will self-serialize (at least not in the near future). The size of the Block (or batch of transactions) is limited; without limitation, there would be no Block chain or "Block chain". Assuming a Block can accommodate up to 100 transactions, the following situations may occur:

• The dApp sent a bundle containing 100 transactions, filling the entire Block. How much profit potential is there for other "members" of the MEV Supply Chain to include it, propose the Block, and execute it?
• The dApp sent a bundle with 99 transactions and there is 1 spot left. Does the proposer have enough incentive to include this bundle? (Unless they collaborate in some way, such as pre-confirmation)
• Two dApps sent bundles. The first bundle contains 60 transactions, and the second contains 50 transactions. Obviously, only one bundle can be included.

The key point is that the MEV generated by the first bundle is more than the second, but from another perspective, it is more beneficial to include the second bundle, because the combination of 50 transactions from other non-self-serialized dApps can create more value for the Block.

So who should be included? Who is the most profitable in the Block, not just bundled inside?

The achievable solution is FCFS (First Come, First Served), but it cannot guarantee accuracy, as latency still exists.

How to ensure that serialization benefits everyone, rather than just one participant, while depriving other participants (LPs, users) of value?

The potential solution is to set specific serialization rules, and only those who follow these rules are eligible to sort the bundles. This is important because improper serialization may lead to security vulnerabilities.

For AMM trading pairs, using a greedy verifiable rule can prevent sandwich attacks in specific AMM pools. However, most DEX trades are multi-hop trades, so other methods are needed to provide MEV resistance guarantees.

Still in the early stages!

There are currently multiple ways to self-serialize, 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 put it), with different trade-offs in different infrastructures.

The goal of ASS is to let dApp handle its serialization without caring about execution (which is handled by the chain). While ASS on L1 is relatively clear, it is more attractive on L2 because it only needs to deal with one serializer, and L2 can bring more content by implementing local serialization rules.

rise huge space z! (Block space excluded)