Introdução

Abordar o MEV (Valor Extraível Máximo) tem sido um desafio contínuo para o Ethereum; a cadeia de suprimentos de valor incentiva a atividade constante de arbitrageiros com diversas estratégias de diferentes níveis de sofisticação, muitas vezes às custas dos usuários de varejo. Embora muitos pesquisadores tenham tentado abordar o MEV por meio de mudanças no nível do protocolo, esses esforços ainda não forneceram uma solução satisfatória. A infraestrutura canônica e os mecanismos de leilão atualmente em uso são capazes de capturar competitivamente o MEV em uma soma global em um bloco, mas a captura sem redistribuição justa é inadequada: por que o valor do MEV deve ser acumulado pelos validadores da rede quando ele pode ser capturado e internalizado de forma mais eficaz em uma base aplicativo por aplicativo?

Inserir Sequenciamento Específico da Aplicação (ASS). Em vez de tentar reescrever as regras no nível do protocolo, o ASS dá às aplicações individuais o poder de controlar como suas transações são sequenciadas. Ao fazer isso, o ASS permite que as aplicações onchain protejam seus usuários e liquidez dos efeitos prejudiciais do MEV, ao mesmo tempo em que lhes dá a oportunidade de capturar valor que de outra forma seria perdido para os validadores do Ethereum.

Imagine o potencial: em vez de traders de alta frequência competindo para arbitrar cada usuário de forma máxima (com quase todo o valor arbitrado vazando para os validadores e, portanto, cadeias subjacentes), cada aplicativo poderia definir suas próprias regras para a ordenação de transações, criando um sistema mais personalizado, eficiente e justo para seus próprios usuários. Isso marca uma mudança de tentar resolver o MEV no nível da rede para abordá-lo onde mais importa - o próprio aplicativo.

Antecedentes

O conceito por trás da Sequência Específica de Aplicação (ASS) teve origem no trabalho de Matheus sobre o Regra de Sequenciamento Verificável (VSR) para exchanges descentralizadas (DEXes). Matheus demonstrou que VSR poderia melhorar a execução do comércio e mitigar MEV ao reduzir a influência dos mineradores sobre a ordenação das transações. Tarun mais tarde expandiu essa ideiamostrando como as regras de sequenciamento específicas do aplicativo podem afetar significativamente as funções de pagamento para os participantes do protocolo, como usuários, validadores e sequenciadores.

Aqui, a função de payoff representa o valor econômico de uma determinada ordem de transação. Esse valor reflete o lucro ou utilidade obtidos pelos participantes do protocolo, mostrando como a ordem das transações afeta seus resultados financeiros. Existem duas características críticas das funções de payoff:

1. Pagamentos não suaves: Pequenas mudanças na ordem podem causar grandes mudanças em MEV.
2. Pagamentos não-monótonos: Pequenas mudanças na ordem podem tanto aumentar quanto diminuir o MEV, mas não consistentemente em uma direção.

Quando as funções de payoff exibem essas duas características, a otimização da estratégia de sequenciamento torna-se altamente complexa. Nesses casos, abordagens mais sofisticadas e sob medida são necessárias, no nível do aplicativo, para garantir resultados equitativos para os usuários e um ecossistema DeFi sustentável.

Como funciona o ASS?

Para entender a ASS, vamos primeiro revisar a cadeia de suprimento de transações existente.

No sistema atual:

1. As transações são enviadas para mempools públicos ou privados.
2. Os construtores coletam essas transações e as empacotam em blocos.
3. Os construtores então competem em um leilão de blocos.
4. O bloco do construtor vencedor está incluído no blockchain e o valor que eles ofereceram é pago ao proponente escolhido para o bloco dado.

A figura abaixo ilustra esse processo, mostrando como as transações fluem dos mempools para o blockchain através de construtores e relés confiáveis.

Diagrama da cadeia de suprimentos atual da transação

As aplicações habilitadas por ASS, por outro lado, possuem as seguintes propriedades:

1. Direitos de Sequenciamento Restrito: Essa restrição garante que apenas um sequenciador designado ou validadores com apostas possam interagir com o contrato da aplicação na cadeia em que se estabelece, evitando a contornagem maliciosa da lógica da aplicação para redistribuição interna de valor.
2. Mempools específicos do aplicativo: Em vez de enviar transações para um mempool público, os usuários enviam mensagens assinadas expressando sua intenção a um mempool específico do aplicativo. Essas intenções são então coletadas e processadas pelo sequenciador específico do aplicativo.
3. Resultados independentes de pedidos: Para aplicar a regra de sequenciamento e entregar os retornos econômicos ideais para os usuários-alvo, as transações ASS precisam ser independentes de ordem para o pedido de transação dos construtores para o resto do bloco. Isto é conseguido garantindo que o estado da candidatura é limitado pelo seu mecanismo de consenso. Os pedidos ASS são então consolidados em um único pacote que é enviado aos construtores para inclusão. Dado que esse pacote não é controverso com o estado acessado por outros aplicativos, ele é agnóstico à sua posição no bloco.

ASS permite que aplicativos em qualquer cadeia recuperem a soberania sobre sua execução e estado do contrato, possibilitando assim aplicativos soberanos.

Diante desses princípios fundamentais, vamos usar Angstrom como um exemplo prático de uma aplicação soberana. O Angstrom é um gancho UniswapV4 que protege seus provedores de liquidez de seleção adversa por arbitradores CEX-DEX, ao mesmo tempo em que protege os swappers de ataques sanduíche. Uma rede de nós Angstrom chega a um consenso, em paralelo ao Ethereum, sobre o conjunto de transações a serem executadas no próximo bloco. O fluxo geral é o seguinte:

1. Arbitradores CEX-DEX disputam o direito de ser a primeira transação a trocar através do AMM (sem taxa). Enquanto isso, os usuários enviam suas trocas pretendidas como ordens limitadas assinadas para a mempool de Angstrom.
2. A Angstrom Network executa seu protocolo de consenso e forma um pacote onde o primeiro swap é a transação de arbitragem com o maior lance. O montante da oferta é posteriormente distribuído, proporcionalmente, aos LP subjacentes no intervalo do swap. Todas as outras ordens de limite válidas, juntamente com a liquidez AMM subjacente, são executadas ao mesmo preço de compensação uniforme.
3. Em seguida, este pacote é enviado para construtores Ethereum e para a mempool pública pelo nó Angstrom que está propondo o slot.
4. Os construtores incluem o pacote Angstrom em qualquer posição no bloco. O pacote só precisa pagar a taxa básica de inclusão devido à sua construção agnóstica à ordem.

O diagrama a seguir ilustra a aplicação soberana em ação.

A cadeia de suprimentos da transação em Angstrom

Suposição de Vida e Confiança

Em sua essência, ASS é uma forma de construção parcial de blocos em que um aplicativo soberano deleGates os direitos de sequenciamento a uma rede descentralizada de operadores seguindo uma regra de sequenciamento prescrita. Consequentemente, ASS inevitavelmente envolve partes externas que introduzem suposições adicionais de vivacidade e confiança.

Assunção de Vitalidade

Aplicações soberanas dependem de sequenciadores específicos do aplicativo para seguir o protocolo corretamente e fornecer atualizações de estado oportunas. No caso de uma violação de vivacidade, como um partição de rede, os usuários podem ser incapazes de interagir com partes do aplicativo até que um consenso válido seja restaurado.

Aplicações soberanas também podem limitar o escopo do estado do contrato, cujas atualizações dependem de seus sequenciadores. Isso ajuda a minimizar as dependências externas do contrato, de modo que estados críticos, como a liquidez depositada, possam permanecer acessíveis mesmo em caso de falha do sequenciador.

Pressuposição de Confiança

Para garantir que os sequenciadores adiram às regras de sequenciamento prescritas, as aplicações soberanas podem alavancar soluções criptoeconômicas (como PoS) ou métodos criptográficos (como TEE ou MPC). A abordagem específica pode variar significativamente dependendo das necessidades da aplicação; alguns podem exigir consenso sobre a otimalidade da execução, enquanto outros podem se concentrar em garantir a privacidade pré-execução por meio de mecanismos criptográficos. Há numerosas ferramentas disponíveis para reduzir a sobrecarga de confiança dos sequenciadores e atender aos objetivos únicos de cada aplicação soberana.

Resistência à censura

Existem vários tipos de censura que assolam o ecossistema Ethereum:

1. Censura regulatória: Os construtores e relés censuram transações com base na lista de sanções da OFAC. Esta é uma das formas mais proeminentes de censura presente no Ethereum hoje.predominantemente aplicado por relés.
2. Censura econômica: um atacante motivado podeSubornar o proponente do bloco para censurar transações de vítimas.
3. Censura no nível do nó: Os nós na rede P2P podem se recusar a propor transações de entrada. Isso pode ser um grande problema se o protocolo operar de forma ideal sob a suposição de que a maioria dos nós compartilha a mesma visão das transações de entrada. Além disso, em tais protocolos, um adversário pode ser incentivado a particionar as exibições locais dos nós honestos (enviando uma transação para apenas metade dos nós no final de um slot) e interromper o protocolo como resultado.

Muitos pesquisadores expressaram a necessidade de um mecanismo de resistência à censura melhor no Ethereum. Algumas propostas, como Múltiplo Proponente Concorrente (MCP)eLista de inclusão com aplicação de Fork-Choice (FOCIL), vieram à tona e se tornaram o centro de uma discussão em curso.

A resistência à censura também é uma preocupação importante para aplicação soberana. Os sequenciadores específicos do aplicativo são provavelmente entidades externas com diversos interesses em receber transações privadas e fluxos de pedidos adicionais. Por exemplo, um validador específico do aplicativo que é um market maker tem um incentivo para censurar transações enviadas por market makers concorrentes. A aplicação soberana no topo pode, assim, sofrer censura local mesmo que o protocolo base não seja censurador.

Um exemplo de mecanismo de resistência à censura para o ASS é o Angstrom. Para garantir que todas as ordens válidas sejam incluídas no próximo slot, os nós da Angstrom devem transmitir quaisquer ordens recebidas verificadas e chegar a um consenso sobre sua inclusão no pacote de transações proposto. Se o pacote estiver faltando ordens observadas pela maioria da rede, o proponente será penalizado. Aqui está uma ilustração do mecanismo de resistência à censura para Angstrom.

Resistência à censura em uma aplicação soberana descentralizada

O Dilema da Componibilidade

Um dos principais desafios que as aplicações soberanas enfrentam é garantir a composabilidade com transações que interagem com estados de contratos externos. Simplesmente agrupar transações específicas do aplicativo com transações externas arbitrárias compromete a propriedade de ordem agnóstica que é necessária para proteger a aplicação soberana e seus usuários. Uma única transação não-ASS inválida, quando combinada com uma específica do aplicativo, pode ter o efeito de reverter completamente o pacote. Quando isso acontece, a aplicação soberana não pode executar as ordens de seus usuários durante o slot alocado (apesar de um consenso válido ter sido alcançado), prejudicando assim a experiência do usuário e o bem-estar geral.

Existem, no entanto, potenciais soluções para a questão da composabilidade, várias das quais estão a ser exploradas por várias equipas. Isso inclui conceitos como pré-confirmações de inclusão, sequenciadores específicos de aplicativos compartilhados e compromissos de construtor, cada um oferecendo compensações entre grau de capacidade de composição e sobrecarga de confiança.

Pré-confirmações de Inclusão

Para explicar as pré-confirmações de inclusão, é importante primeiro entender como as pré-confirmações baseadas funcionam. As pré-confirmações baseadas alavancam a segurança criptoeconômica, garantindo que os proponentes tenham apresentado garantias estacas para garantir a inclusão de um conjunto específico de transações antes de um slot dentro da época atual. Esta garantia é limitada pelo tamanho do título lançado pelos proponentes participantes.

As pré-confirmações de inclusão são uma forma especializada de pré-confirmações baseadas, onde a inclusão da transação é independente de qualquer estado do contrato. Transações que solicitam pré-confirmações de inclusão devem ser agnósticas ao estado e não controversas, o que significa que sua execução não é afetada pela posição dentro do bloco. Ao utilizar pré-confirmações de inclusão, os proponentes podem se comprometer a incluir uma transação não ASS apenas se o pacote ASS for incluído no mesmo bloco. Esse enfoque proporciona composabilidade criptoeconomicamente reforçada entre transações não controversas e pacotes ASS.

Ilustração do preconf de inclusão com ASS

No entanto, dado a limitada composição fornecida por essa solução, a complexidade adicionada e sobrecarga de confiança podem superar seus benefícios para certas aplicações soberanas. Como resultado, é importante explorar abordagens alternativas que possam oferecer um equilíbrio mais efetivo entre simplicidade e funcionalidade.

Sequenciadores específicos de aplicativos compartilhados e compromissos do Builder

Em vez de depender de compromissos de proponentes, as aplicações soberanas podem usar sequenciadores específicos do aplicativo para gerenciar a ordem de transações em várias aplicações. Por exemplo, um sequenciador que lida com transações para várias aplicações soberanas pode facilitar a composabilidade atômica entre elas, desde que siga as regras de sequenciamento de cada uma. Essa abordagem de sequenciador específico do aplicativo compartilhado permite uma composabilidade e coordenação perfeitas entre as aplicações soberanas.

No entanto, para aplicações não soberanas, é necessária uma solução diferente. Compromissos de inclusão de transação de construtores de blocos que participam da sequenciação para aplicações soberanas podem criar composabilidade atômica entre aplicações soberanas e não soberanas. O construtor garante a ordem de transação especificada em ambos os tipos de aplicações. Esse compromisso de construtor pode preencher a lacuna de composabilidade para ASS.

Ilustração do compromisso do construtor para composição atômica entre dApps soberanos e não soberanos (à direita) e sequenciador compartilhado específico do aplicativo para composição atômica entre aplicativos soberanos (à esquerda)

Embora permaneçam dúvidas sobre a dinâmica econômica dos compromissos dos construtores, a viabilidade da pré-confirmação da inclusão e os potenciais efeitos de segunda ordem, estamos confiantes de que os desafios de composição do ASS serão resolvidos ao longo do tempo. Times como AstriaePrimevestão pesquisando ativamente e desenvolvendo estruturas aprimoradas para sequenciamento compartilhado e compromissos de construção. À medida que essas melhorias avançam, a composabilidade não será mais um problema para aplicativos soberanos.

ASS vs L2s específicos do aplicativo e L1s

Atualmente, as dApps têm que construir cadeias específicas de aplicativos se quiserem controlar a sequência de suas transações. Conceitos como Construtor de propriedade do protocolo (PoB) permite que o Cosmos L1s tenha regras de sequenciamento mais expressivas que ajudam a capturar e redistribuir o MEV para seu aplicativo. Da mesma forma, um sequenciador L2 com VSR também pode executar tais operações. Embora ambas as soluções permitam um sequenciamento e captura mais expressivos de MEV por suas aplicações, o ASS é único devido às seguintes características.

1. Sem sobrecarga de confiança da execução da transação – o ASS não executa ou liquida a transação sequenciada. Apenas o sequenciamento é excluído. A suposição de confiança da linha de base se estende do ambiente de execução nativo, como Ethereum ou outros L2s.
2. Acesso à liquidez e fluxo de pedidos - Os usuários não precisam fazer ponte. dApps podem aproveitar diretamente o fluxo e a liquidez na cadeia.
3. O ativo permanece no ambiente de execução nativo e não pode ser congelado - Ao contrário dos L2s, a maioria das ASS não exige que os usuários bloqueiem seus fundos em contratos de ponte. Essa escolha de design oferece melhor segurança: se um sequenciador específico do aplicativo falhar, os danos potenciais são limitados, pois o sequenciador só pode controlar transações dentro dos limites estabelecidos pelo contrato inteligente. Embora algumas soluções L2 implementem recursos de segurança - como saídas de emergência einclusão forçada - essas medidas geralmente são difíceis de usar na prática. Os usuários podem precisar esperar vários dias antes de poderem ativar uma saída de emergência após perderem a conexão com as atualizações L2. Da mesma forma, a inclusão forçada via L1 geralmente envolve pelo menosum diaatraso. Talvez o mais importante, essas medidas de segurança geralmente exigem conhecimentos técnicos que a maioria dos usuários não possui, tornando-as impraticáveis para a pessoa comum.
4. Suposição de Liveness forte-ASS - A Liveness da L2 depende dos nós de execução, que geralmente é o sequenciador de rollup, a menos que seja baseado em sequenciamento. A Liveness da L1 depende da maioria honesta dos nós que reexecutam as funções de transição de estado correspondentes. A Liveness de uma aplicação soberana depende principalmente do ambiente de execução subjacente, e os contratos inteligentes podem especificar partes que precisam depender de sequenciadores específicos do aplicativo.

Tabela comparativa de aplicativos soberanos, L2, Baseado em L2 e L1

Conclusão

A ASS capacita aplicativos com plena soberania sobre a sequência de transações, permitindo-lhes definir regras personalizadas sem a complexidade de gerenciar a execução. Essa soberania permite que os aplicativos controlem sua execução para otimizar resultados para seus usuários. Por exemplo, na Angstrom, LPs e swappers são tratados como participantes de primeira classe, com sua recompensa econômica diretamente aprimorada por meio de regras de sequenciamento personalizadas.

Além disso, o ASS pode alavancar uma variedade de ferramentas criptoeconômicas e criptográficas para garantir a optimalidade dos pagamentos dos usuários e implementar mecanismos robustos de resistência à censura. Soluções criptoeconômicas, como staking e slashing, podem incentivar o comportamento honesto entre os sequenciadores, enquanto métodos criptográficos como TEE e MPC aprimoram a privacidade e a segurança. Com essas ferramentas, o potencial de design do ASS é vasto, permitindo a criação de aplicativos soberanos mais seguros, eficientes e centrados no usuário.

Apesar das oportunidades que a ASS oferece, ainda existem desafios, como a falta de composabilidade nativa. No entanto, soluções como pré-confirmação de inclusão, ASS compartilhada e compromisso do construtor apresentam formas promissoras de superar esses obstáculos. Embora algumas perguntas ainda permaneçam, estamos comprometidos em aprimorar essas abordagens para oferecer uma experiência ASS mais suave e com maior composabilidade.

Estamos aqui para tornar o DeFi mais sustentável, um ASS de cada vez.

Aviso Legal:

1. Este artigo é reproduzido a partir de [irmã]. Todos os direitos autorais pertencem ao autor original [Yuki Yuminaga]. Se houver objeções a essa reprodução, por favor, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.