Introdução

Abordar o MEV (Maximal Extractable Value) tem sido um desafio contínuo para o Ethereum; A cadeia de suprimentos de valor incentiva a atividade constante de arbitradores 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 de montante fixo em um bloco, mas a captura sem uma redistribuição justa é inadequada: por que o valor do MEV deve ser acumulado para os validadores de rede quando pode ser capturado e internalizado de forma mais eficaz em uma base de aplicação por aplicativo?

Introduza a Sequenciação Específica da Aplicação (ASS). Em vez de tentar reescrever as regras ao nível do protocolo, a ASS dá às aplicações individuais o poder de controlar a sequência das suas transações. Ao fazê-lo, a ASS permite que as aplicações na blockchain protejam os seus utilizadores e liquidez dos efeitos prejudiciais do MEV, ao mesmo tempo que lhes dá a oportunidade de capturar valor que de outra forma seria perdido para os validadores da Ethereum.

Imagine o potencial: em vez de traders de alta frequência competirem para arbitrar ao máximo cada usuário (com quase todo o valor arbitrado vazando para os validadores e, portanto, para as 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 isso importa mais - o próprio aplicativo.

Antecedentes

O conceito por trás do Sequenciamento Específico de Aplicações (ASS) originou-se do trabalho de Matheus sobre o Regra de Sequenciamento Verificável (RSV) para trocas descentralizadas (DEXes). Matheus demonstrou que o VSR poderia melhorar a execução de transações e mitiGate MEV reduzindo a influência dos mineradores sobre os pedidos de transações. Tarun mais tarde expandiu esta ideiamostrando como regras de sequenciamento específicas do aplicativo podem afetar significativamente as funções de remuneração para os participantes do protocolo, como usuários, validadores e sequenciadores.

Aqui, a função de pagamento representa o valor econômico de uma determinada transação. Este valor reflete o lucro ou utilidade obtida pelos participantes do protocolo, mostrando como a ordenação da transação impacta seus resultados financeiros. Existem duas características críticas das funções de pagamento:

1. Pagamentos não suaves: pequenas mudanças na ordenação podem causar grandes mudanças em MEV.
2. Pagamentos não monotônicos: Pequenas alterações na ordem podem aumentar ou diminuir o MEV, mas não consistentemente em uma direção.

Quando as funções de pagamento exibem ambas essas características, otimizar a estratégia de sequenciamento torna-se altamente complexo. Em tais casos, abordagens mais sofisticadas e personalizadas são necessárias, ao nível da aplicação, para garantir resultados equitativos para os utilizadores e um ecossistema DeFi sustentável.

Como funciona a ASS?

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

No sistema atual:

1. As transações são enviadas para mempools públicas ou privadas.
2. Os construtores recolhem essas transações e as agrupam em blocos.
3. Os construtores competem então num leilão de bloco.
4. O bloco do construtor vencedor é 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 de mempools para o blockchain por meio de construtores e retransmissores confiáveis.

Diagrama da cadeia de fornecimento de transações atual

As aplicações habilitadas pela ASS, por sua vez, possuem as seguintes propriedades:

1. Direitos de sequenciamento restritos: essa restrição garante que apenas um sequenciador designado ou validadores de estaca possam interagir com o contrato do aplicativo na cadeia em que ele se instala, evitando o desvio nefasto da lógica do aplicativo para redistribuição interna de valor.
2. Mempools Específicas da Aplicação: Em vez de submeter transações a uma mempool pública, os utilizadores enviam mensagens assinadas expressando a sua intenção a uma mempool específica da aplicação. Estas intenções são depois recolhidas e processadas pelo sequenciador específico da aplicação.
3. Resultados independentes da ordem: Para impor a regra de sequenciamento e proporcionar o retorno econômico ideal aos usuários-alvo, as transações ASS precisam ser independentes da ordem de transação dos construtores para o restante do bloco. Isso é alcançado garantindo que o estado do aplicativo seja controlado pelo seu mecanismo de consenso. As ordens ASS são então consolidadas em um único pacote que é enviado aos construtores para inclusão. Dado que este pacote não é conflituoso com o estado acessado por outros aplicativos, ele é independente de sua posição no bloco.

O ASS permite que aplicações em qualquer cadeia recuperem a soberania sobre o seu estado de execução e contrato, permitindo assim aplicações soberanas.

Dadas essas premissas fundamentais, vamos usar Angstrom como um exemplo prático de um aplicativo soberano. Angstrom é um gancho UniswapV4 que protege seus provedores de liquidez contra seleção adversa por arbitragistas CEX-DEX, ao mesmo tempo em que protege os trocadores de ataques de 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. Os arbitradores da CEX-DEX oferecem o direito de ser a primeira transação a ser trocada através do AMM (sem uma taxa). Enquanto isso, os usuários enviam suas trocas pretendidas como ordens de limite assinadas para o mempool 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 é subsequentemente 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. Este pacote é então enviado para os construtores Ethereum e o mempool público pelo nó Angstrom propondo para o slot.
4. Os construtores incluem o pacote Angstrom em qualquer posição no bloco. O pacote só precisa pagar a taxa base para inclusão devido à sua construção sem ordem.

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

A cadeia de fornecimento de transações em Angstrom

Assunção de Vida e Confiança

No seu âmago, ASS é uma forma de construção de bloco parcial onde uma aplicação soberana delega os direitos de sequenciamento a uma rede descentralizada de operadores seguindo uma regra de sequenciamento prescrita. Consequentemente, ASS inevitavelmente envolve partes externas que introduzem pressupostos adicionais de vitalidade e confiança.

Pressuposição de Vida

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 utilizadores podem não conseguir interagir com partes da aplicação até que o consenso válido seja restabelecido.

As 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 liquidez depositada, possam permanecer acessíveis mesmo em caso de falha do sequenciador.

Pressuposição de Confiança

Para garantir que os sequenciadores cumpram as regras de sequenciamento prescritas, as aplicações soberanas podem alavancar soluções criptoecomonó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; algumas podem exigir consenso sobre a otimalidade da execução, enquanto outras podem focar em garantir a privacidade pré-execução por meio de mecanismos criptográficos. Existem inúmeros instrumentos 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 regulamentar: Os construtores e os relés censuram transações com base na lista de sanções do OFAC. Esta é uma das formas mais proeminentes de censura presentes no Ethereum hoje. predominantemente aplicado por relés.
2. Censura económica: Um atacante motivado podesubornar o proponente de bloco para censurar transações de vítimas.
3. Censura ao nível do nó: os nós na rede P2P podem recusar-se a propagar transações recebidas. Isso pode ser um grande problema se o protocolo operar de forma ótima sob a suposição de que a maioria dos nós compartilha a mesma visão das transações recebidas. Além disso, em tais protocolos, um adversário pode ser incentivado a particionar as visões locais dos nós honestos (enviando uma transação apenas para metade dos nós no final de um slot) e interromper o protocolo como resultado.

Muitos pesquisadores expressaram a necessidade de um melhor mecanismo de resistência à censura no Ethereum. Algumas propostas, como Proponente Múltiplo Simultâneo (MCP) e Lista de inclusão imposta por escolha de bifurcação (FOCIL), surgiram e tornaram-se o centro de uma discussão em curso.

A resistência à censura é também uma grande preocupação para a aplicação soberana. Os sequenciadores específicos do aplicativo são provavelmente entidades externas com vários interesses em receber transações privadas adicionais e fluxo de ordens. Por exemplo, um validador específico de aplicativo que seja um criador de mercado tem um incentivo para censurar transações enviadas por criadores de mercado concorrentes. A aplicação soberana no topo pode, assim, sofrer censura local, mesmo que o protocolo base não seja censurador.

Um exemplo de um mecanismo de resistência à censura para ASS é Angstrom. Para garantir que todas as ordens válidas sejam incluídas no próximo slot, os nós 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 pedidos observados 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 composibilidade

Um dos principais desafios que as aplicações soberanas enfrentam é garantir a compatibilidade com transações que interagem com estados contratuais externos. A simples agregação de transações específicas de aplicativos com transações externas arbitrárias prejudica a propriedade agnóstica de ordem que é necessária para proteger o aplicativo soberano e seus usuários. Uma única transação não-ASS inválida, quando composta com uma transação específica do aplicativo, pode ter o efeito de segunda ordem de reverter todo o pacote. Quando isso acontece, o aplicativo soberano não pode executar as ordens de seus usuários durante o slot alocado (apesar do 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 do construtor, cada um oferecendo compensações entre o grau de composição e a sobrecarga de confiança.

Pré-confirmações de inclusão

Para explicar as pré-confirmações de inclusão, é importante primeiro entender como funcionam as pré-confirmações baseadas. As pré-confirmações baseadas alavancam a segurança criptoeconômica, garantindo que os proponentes tenham apresentado garantias apostadas para garantir a inclusão de um conjunto específico de transações antes de um slot dentro da época atual. Essa garantia é limitada pelo valor da fiança enviada 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. As transações que solicitam pré-confirmações de inclusão devem ser agnósticas ao estado e não contenciosas, o que significa que sua execução não é afetada por sua 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 somente se o pacote ASS estiver incluído no mesmo bloco. Essa abordagem fornece compatibilidade imposta criptoeconomicamente entre transações não contenciosas e pacotes ASS.

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

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

Sequenciadores específicos de aplicativos compartilhados & Compromissos do construtor

Em vez de depender de compromissos de proponentes, os aplicativos soberanos podem usar sequenciadores específicos de aplicativos para gerenciar a ordem das transações em vários aplicativos. Por exemplo, um sequenciador que manipula transações para vários aplicativos soberanos pode facilitar a composabilidade atômica entre eles, desde que siga as regras de sequenciamento de cada um. Essa abordagem de sequenciador específico de aplicativo compartilhado permite a composabilidade e coordenação perfeitas entre aplicativos soberanos.

No entanto, para aplicações não soberanas, é necessário uma solução diferente. Compromissos de inclusão de transação dos construtores de bloco 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 especificada da transação em ambos os tipos de aplicações. Tal compromisso do construtor pode preencher a lacuna de composabilidade para ASS.

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

Embora permaneçam dúvidas sobre a dinâmica econômica dos compromissos do construtor, a viabilidade da pré-confirmação de inclusão e potenciais efeitos de segunda ordem, estamos confiantes de que os desafios de composição do ASS serão resolvidos ao longo do tempo. Equipas como Astria e ainda Primev estão ativamente pesquisando e desenvolvendo estruturas aprimoradas para sequenciamento compartilhado e compromissos do construtor. À medida que esses avanços progridem, a composibilidade deixará de ser um problema para aplicações soberanas.

ASS vs L2s específicos de aplicativos e L1s

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

1. Sem sobrecarga de confiança na execução da transação - ASS não executa nem liquida a transação sequenciada. Apenas a sequência é delegada. A suposição de confiança básica se estende do ambiente de execução nativo, como o Ethereum ou outros L2s.
2. Acesso à liquidez e fluxo de ordens – Os usuários não precisam fazer pontes. Os dApps podem alavancar 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 dos ASS não requer que os usuários bloqueiem seus fundos em contratos de ponte. Esta escolha de design oferece melhor segurança: se um sequenciador específico do aplicativo falhar, o dano potencial é limitado, uma vez que 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 escotilhas de fuga einclusão forçada- estas medidas são frequentemente difíceis de usar na prática. Os utilizadores podem precisar de esperar vários dias antes de poderem ativar uma saída de emergência após perderem a ligação às atualizações L2. Da mesma forma, a inclusão forçada via L1 envolve tipicamente pelo menos um 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 vivacidade Strong-ASS – A vivacidade do L2 depende dos nós de execução, que geralmente é o sequenciador de rollup, a menos que seja baseado em sequência. A vivacidade do L1 depende da maioria honesta dos nós que reexecutam as funções de transição de estado correspondentes. A vivacidade de um aplicativo soberano 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 aplicações soberanas, L2, Base L2 e L1

Conclusão

ASS capacita aplicações com total soberania sobre a sequência de transações, permitindo-lhes definir regras personalizadas sem a complexidade de gerir a execução. Essa soberania permite que as aplicações controlem sua execução para otimizar os 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 melhorada através de regras de sequenciamento personalizadas.

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

Apesar das oportunidades que a ASS oferece, desafios como a falta de componibilidade nativa ainda existem. No entanto, soluções como a pré-confirmação de inclusão, ASS partilhada e compromisso do construtor apresentam formas promissoras de superar estes obstáculos. Embora algumas questões permaneçam, estamos empenhados em refinar essas abordagens para oferecer uma experiência ASS mais suave e componível.

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

Aviso Legal:

1. Este artigo é reproduzido de [irmã]. Todos os direitos autorais pertencem ao autor original [Yuki Yuminaga]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipa e eles irão tratar disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as 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 seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.