Autor: Pavel Paramonov Fonte: X, @paramonoww Tradução: Shanooba, Golden Finance

Muitas pessoas acreditam que "ASS é tudo o que você precisa", considerando-o como uma solução completa que raramente precisa de melhorias. No entanto, o ASS não pode resolver todos os problemas e também possui algumas suposições de confiança.

1. O dApp de autossérie é parte dos construtores de Bloco

Quando um pacote de transação entra no Bloco, o dApp tem o direito de extrair seu próprio valor máximo extraível (MEV) do MEV da cadeia de fornecimento, obtendo seu próprio valor dos outros 'membros' da cadeia, como proponentes, pesquisadores e construtores. No entanto, esse conceito não é perfeito (nada é perfeito no mundo da encriptação) e pode ter algumas suposições de confiança.

2. Jogo inclusivo

Os desafios enfrentados pela dApp de auto-serialização são: quanto maior o valor agrupado, maior a demanda garantida no Bloco. Se as transações que capturam o MEV não forem incluídas no Bloco, elas podem se tornar completamente não lucrativas, prejudicando não apenas outras transações que não conseguem gerar MEV, mas também os usuários.

Este é um cenário de reflexão interessante:

• A dApp tem a capacidade de capturar todo o MEV gerado por ele.
• Mas se perdermos não apenas a oportunidade do MEV, mas também os usuários que trazem valor à plataforma (por exemplo, se o AMM continuar falhando, quem mais o usaria), então não faz sentido fazer isso.

O mais interessante é que o proponente também precisa lucrar, o que cria uma situação de dupla perda:

• Os dApps de autodeserialização perdem MEV porque são bloqueados e não estão incluídos no Bloco
• Os proponentes perdem o MEV porque não conseguem desempacotar e reorganizar as transações atômicas da embalagem (embora possam optar por outras transações)

3. A aplicação descentralizada ASS não deve prejudicar os usuários comuns e os provedores de Liquidez (LPs) extraindo MEV

Como é amplamente conhecido, a maior parte do MEV é gerada e extraída através de tráfego tóxico. Os LPs perdem a maior parte de seus ganhos de tráfego não informado devido ao MEV. Atrair Liquidez para a plataforma é uma das coisas mais difíceis no campo da encriptação, e AMM deve seguir a distribuição justa do MEV para os LPs, o que pode ajudar a reduzir a Perda impermanente.

Na realidade atual, gerenciar ativamente as posições do LP (até mesmo várias posições do LP) pode ser considerado um trabalho em tempo integral. Se for um ataque de sanduíche, o valor é devolvido aos traders; se for uma arbitragem entre a exchange centralizada e a exchange descentralizada, o valor é devolvido aos LPs. Então, a questão é quanto retorno eles devem obter e quanto valor o dApp deve reter?

**4. Se o tamanho do bloco de ligação conflitar com o tamanho do Bloco da cadeia subjacente, o que devo fazer?

Obviamente, nem todos os dApp serão auto-serializados (pelo menos num futuro próximo). O tamanho do Bloco (ou lote de transações) é limitado; sem limites, não haveria Bloco ou 'cadeia de Blocos'. Supondo que um Bloco possa conter no máximo 100 transações, podem ocorrer as seguintes situações:

• dApp enviou um pacote contendo 100 transações, preenchendo todo o Bloco. Quanto espaço de lucro existe para os outros 'membros' na Cadeia de fornecimento de MEV ao incluí-lo, propor Bloco e executá-lo?
• O dApp enviou um pacote com 99 transações agrupadas, restando 1 posição. O proponente tem incentivo suficiente para incluir esse pacote? (A menos que eles estejam fazendo alguma cooperação, como pré-confirmação)
• Dois dApps enviaram pacotes de transações em lotes. O primeiro pacote contém 60 transações e o segundo contém 50 transações. É claro que só pode haver um pacote de transações em lote.

O ponto crucial aqui é que o MEV gerado pelo primeiro agrupamento é maior do que o do segundo, mas, por outro lado, é mais vantajoso incluir o segundo agrupamento, uma vez que a combinação deste com as 50 transações de dApps não serializados pode criar mais valor para o Bloco.

Então, quem deve ser incluído? Quem é o mais lucrativo no Bloco, não apenas amarrado internamente?

A solução possível é FCFS (primeiro a chegar, primeiro a ser servido), mas não pode garantir precisão, pois a latência ainda existe.

Como garantir que a serialização beneficie a todos, e não apenas um participante, privando outros participantes (LPs, usuários) de valor?

A solução potencial é estabelecer regras de serialização específicas, e apenas aqueles que seguem essas regras têm permissão para ordenar os pacotes. Isto é crucial, pois a serialização inadequada pode levar a vulnerabilidades de segurança.

Para pares de negociação AMM, o uso de regras de verificação gananciosas pode prevenir ataques sandwich em pools AMM específicos. No entanto, a maioria das negociações DEX são trocas múltiplas, portanto, são necessárias outras formas de fornecer garantias contra MEV.

Ainda numa fase inicial!

Atualmente, existem várias maneiras de realizar a auto-serialização, inspirada pelo método de @SorellaLabs neste tópico. Ainda estamos em estágios iniciais na implementação da auto-serialização (ou ASS, conforme mencionado por @ballsyalchemist), com diferentes infraestruturas apresentando diferentes compromissos.

O objetivo da ASS é permitir que o dApp seja responsável por sua serialização, sem se preocupar com a execução (tratada pela cadeia). Embora o ASS na L1 seja relativamente claro, ele é mais atraente na L2, pois só precisa lidar com um serializador, e a L2 pode trazer mais conteúdo ao implementar regras de serialização locais.

subir空间巨大z！（Bloco空间除外）