Autores: Quintus Kilbourn, Georgios Konstantopoulos, Paradigm; Tradução: Golden Finance 0xxz
Introdução
As discussões sobre “intenções” e suas aplicações tornaram-se um tema quente na comunidade Ethereum recentemente.
Enquanto as transações se referem especificamente a "como" uma ação deve ser executada, as intenções se referem a "qual" o resultado esperado dessa ação deve ser. Se uma transação diz "faça A primeiro, depois B, pague C integralmente para obter X", as intenções dizem "Eu quero X e estou disposto a pagar até C".
Este paradigma declarativo desbloqueia uma experiência de usuário empolgante e melhorias de eficiência. Por meio de intenções, os usuários podem simplesmente expressar um resultado desejado enquanto terceirizam a tarefa ideal de alcançar esse resultado para um terceiro experiente. O conceito de intenções está em contraste com o paradigma de transação imperativa de hoje, onde cada parâmetro é explicitamente especificado pelo usuário.
Embora essas promessas de melhorias forneçam etapas muito necessárias para o ecossistema, o design baseado em intenção no Ethereum também pode ter implicações significativas para a infraestrutura fora da cadeia. Em particular, existem links importantes para atividades relacionadas a MEV e controle de mercado. Este post tem como objetivo fornecer uma breve definição de intenções e seus benefícios, uma exploração dos riscos envolvidos em sua implementação e algumas discussões sobre possíveis atenuações.
O que são intenções?
A forma padrão atual para os usuários interagirem com o Ethereum é criar e assinar uma transação, uma mensagem em um formato específico que fornece todas as informações necessárias para a Ethereum Virtual Machine (EVM) realizar transições de estado. No entanto, criar transações pode ser um assunto complicado. A criação de uma transação requer raciocínio sobre detalhes, como uma vasta rede de contratos inteligentes e gerenciamento de nonce, mantendo ativos específicos para pagar as taxas de gás. Essa complexidade resulta em uma experiência de usuário abaixo do ideal e perda de eficiência, já que os usuários são forçados a tomar decisões sem acesso adequado a informações ou políticas de aplicação complexas.
As intenções são projetadas para aliviar esses fardos do usuário. Informalmente, as intenções assinam um conjunto de restrições declarativas que permitem aos usuários terceirizar a criação de transações para terceiros sem abrir mão do controle total das partes da transação.
Em processos padrão baseados em transações, as assinaturas de transações permitem que os verificadores sigam exatamente um caminho computacional para um determinado estado, e as dicas incentivam os verificadores a fazê-lo. As intenções, por outro lado, não especificam explicitamente o caminho computacional que deve ser seguido, mas permitem qualquer caminho computacional que satisfaça certas restrições. Ao assinar e compartilhar intenções (intenções), os usuários efetivamente concedem permissão aos destinatários para escolher caminhos de computação em seu nome (consulte o diagrama abaixo). Essa distinção permite uma definição um pouco mais estrita de intents como mensagens assinadas que permitem um conjunto de transições de estado a partir de um determinado estado inicial, sendo um caso especial as transações que permitem transições únicas. Dito isto, continuaremos a distinguir "intenções" de transações.
*Figura 1: Ao enviar uma transação, o usuário especifica o caminho de cálculo exato. Ao enviar intenções, o usuário especifica uma meta e algumas restrições, e o processo de correspondência determina o caminho computacional a ser seguido. *
É importante ressaltar que muitas intenções (intenções) podem ser incluídas em uma única transação, permitindo a correspondência de intenções (intenções) sobrepostas, aumentando o gás e a eficiência econômica, por exemplo, no livro de pedidos mantido pelo construtor, dois pedidos podem ser trocados mutuamente antes de entrar no mercado compensação de mercado. Outras aplicações incluem intenções entre domínios (intenções) - assinatura de uma mensagem em vez de várias transações em domínios diferentes - uso de diferentes esquemas de resistência à reprodução (resistência à reprodução) e pagamentos de gás de usuário mais flexíveis, como permitir que as 3 primeiras partes patrocinem gás ou paguem em fichas diferentes.
passado e futuro das intenções
Foram criadas intenções que terceirizam a complexidade da interação com o blockchain, permitindo que os usuários mantenham a custódia de seus ativos e identidades criptográficas.
Você pode notar que muitas dessas ideias correspondem a sistemas que estão em operação há muitos anos:
Limit Order: Posso sacar 100X da minha conta se eu receber pelo menos 200Y.
Leilões no estilo CowSwap: Igual ao anterior, mas depende de um terceiro ou mecanismo para combinar muitos pedidos para maximizar a qualidade da execução.
**Patrocínio de gás: **Pague gás em USDC em vez de ETH. As intenções (intenções) só podem ser realizadas por correspondência de intenções e a taxa é paga em ETH.
Delegação: Permita apenas a interação com determinadas contas de determinadas formas pré-autorizadas. As intenções só podem ser implementadas se a transação resultante respeitar a lista de controle de acesso especificada na intenção.
**Transação em lote: **Permite o processamento em lote de intenções para melhorar a eficiência do gás.
** Agregadores: ** Só operam com o "melhor" preço/rendimento. Essa intenção pode ser alcançada provando que a agregação de vários locais é realizada e o melhor caminho é seguido.
No futuro, no contexto de MEVs de cadeia cruzada (como SUAVE), abstrações de contas no estilo ERC4337 e até pedidos de Seaport, as intenções das pessoas estão sendo revigoradas! Embora o ERC4337 esteja avançando a toda velocidade, outros novos aplicativos, como intents entre domínios, ainda exigem mais pesquisas.
Crucialmente, em todos os aplicativos baseados em intenção, antigos e novos, é necessário que haja pelo menos uma outra parte que entenda a intenção, seja motivada a executar a intenção e seja capaz de fazê-lo em tempo hábil. Perguntas sobre quem são essas partes, como elas atuam e quais são suas motivações devem ser feitas para determinar a eficácia, as suposições de confiança e as implicações mais amplas dos sistemas orientados por intenções.
O intermediário e seu mempool
O canal mais óbvio para as intenções chegarem às mãos dos intermediários é o mempool Ethereum. Infelizmente, o design atual não suporta a propagação de intents. Preocupações com ataques DoS podem significar que o suporte universal para intenções totalmente genéricas no mempool Ethereum é impossível, mesmo a longo prazo. Como veremos abaixo, a natureza aberta e sem permissão dos mempools Ethereum cria barreiras adicionais para a adoção de intents.
Na ausência de um mempool Ethereum, os projetistas de sistemas de intents agora enfrentam alguns problemas de design. Uma decisão de alto nível é propagar as intenções para o conjunto de permissões ou fornecê-las sem permissão para que qualquer uma das partes possa executar as intenções.
Figura 2: Intents fluem de usuários para pools de intents (intenções) com permissão/não permissão e públicos/privados, convertidos em transações por intermediários e, finalmente, entram no pool de memória pública ou vão diretamente para a cadeia por meio de leilões no estilo MEVBoost
Mempool sem permissão
Um projeto pelo qual alguém pode se esforçar é uma API descentralizada que permite que as intenções sejam propagadas pelos nós do sistema, fornecendo acesso sem permissão aos atores. Isso já foi feito antes. Por exemplo, as ordens de limite de fofoca entre os retransmissores de protocolo 0x e os colocam na cadeia quando correspondidos. Essa ideia também é explorada no contexto de um mempool ERC4337 compartilhado para combater os riscos de centralização e censura. No entanto, o design desse "pool de intenções" sem permissão enfrenta alguns desafios significativos:
** Anti-DoS: ** Pode ser necessário limitar a funcionalidade de intents (intent) para evitar ataques.
Propagar incentivos: Para muitos aplicativos, a execução de intents é uma atividade lucrativa. Portanto, os nós que operam um pool de intenções têm um incentivo para não propagar, a fim de reduzir a contenção ao executar as intenções.
**MEV: **as intenções dependem do bom comportamento de atores fora da cadeia para melhorar a qualidade da execução, e usar um pool de intenções público e sem permissão pode encontrar dificuldades. Se a execução ruim for lucrativa, é provável que um conjunto não autorizado de intenções leve a esse resultado. Isso é semelhante a ser capturado no mempool Ethereum hoje e espera-se que seja um problema comum para intenções relacionadas a DeFi. Um possível caminho a seguir pode ser pools de intenção sem permissão, mas criptografados.
** "Pool de memória" permitido **
APIs centralizadas confiáveis são mais resistentes a DoS e não precisam propagar intenções. Modelos confiáveis também fornecem alguma base para problemas de MEV. Enquanto a suposição de confiança for mantida, a qualidade da execução deve ser garantida. Um intermediário confiável também pode ter uma reputação associada a ele, fornecendo algum incentivo para fornecer uma boa execução. Por causa disso, pools de intents autorizados são atraentes para desenvolvedores de aplicativos baseados em intents no curto prazo. No entanto, como todos sabemos, a forte suposição de confiança é falha e um tanto antitética para grande parte do ethos do blockchain. Essas questões serão tratadas a seguir.
solução mista
Algumas soluções são misturas das anteriores. Por exemplo, pode haver permissão para propagar, mas nenhuma permissão para executar (supondo que a suposição de confiança seja válida) e vice-versa. Um exemplo comum de solução híbrida é um leilão de fluxo de pedidos.
A ideia de alto nível por trás desses designs é que um usuário que precisa de uma contraparte pode precisar distinguir entre contrapartes melhores e piores (por exemplo, a outra parte que aceita uma negociação a um preço favorável). O processo de design normalmente inclui uma parte confiável que recebe a intenção do usuário (ou transações) e facilita o leilão em seu nome. A participação em leilões é (às vezes) não autorizada.
Esses tipos de projetos têm suas próprias desvantagens e provavelmente sofrerão com muitas das preocupações relacionadas aos pools de intenção autorizados, mas há algumas distinções importantes que se tornarão aparentes posteriormente.
Resumindo: os aplicativos baseados em intenções não envolvem apenas novos formatos de mensagem para interagir com contratos inteligentes, mas também envolvem propagação alternativa no estilo mempool e mecanismos de descoberta de contraparte. Projetar um mecanismo de descoberta e correspondência de intenção que seja compatível com incentivos e descentralizado não é trivial.
Onde posso errar?
Embora as intenções sejam um novo paradigma de transação empolgante, sua adoção generalizada pode significar que a tendência maior de mudança da atividade do usuário para mempools alternativos está se acelerando. Se não for gerida de forma adequada, esta mudança pode levar à centralização e entrincheiramento de intermediários rentistas.
Fluxo de pedidos
A migração do mempool público pode levar à centralização da produção de blocos Ethereum se as intenções forem executadas com permissão, mas o conjunto de permissões não for escolhido com cuidado. *
A grande maioria da produção de blocos no Ethereum atualmente ocorre via MEV-Boost, uma implementação fora do protocolo da separação proponente-construtor (PBS), e o roteiro atual não dá nenhuma indicação de que essa interface será alterada em breve. A PBS depende da existência de um mercado competitivo para construtores de blocos para direcionar o MEV para o conjunto de validadores. Um grande problema no PBS é a capacidade dos construtores de blocos de obter acesso exclusivo às matérias-primas necessárias para produzir blocos valiosos – transações e intenções, também conhecidas como “fluxo de pedidos”. No jargão da PBS, o acesso autorizado às intenções será referido como "Fluxo de Pedido Exclusivo" (EOF). Conforme discutido neste artigo, o EOF nas mãos erradas ameaça a estrutura de mercado da qual a PBS depende, pois a exclusividade no fluxo de pedidos significa um fosso contra as forças competitivas.
Os construtores de blocos (ou entidades colaboradoras) que controlam a maior parte do fluxo de pedidos do Ethereum poderão produzir a maioria dos blocos da rede principal, abrindo um vetor para censura. Como a rede depende da competição entre os construtores para passar valor aos validadores (ou ser destruída no futuro), o domínio de um único construtor constituirá uma transferência de valor do Ethereum para os construtores. Rent-seeking e censura são, sem dúvida, ameaças significativas ao protocolo.
confiar
Como muitas soluções exigem confiança em intermediários, o desenvolvimento de novas arquiteturas baseadas em intenções é prejudicado por altas barreiras à entrada, o que significa menores taxas de inovação e concorrência para garantir a qualidade da execução. *
No pior dos casos, os usuários podem se encontrar em uma posição em que apenas uma parte executa as intenções, como o monopólio da construção de blocos na seção anterior. Em tal mundo, os monopólios de construção de blocos seriam capazes de extrair rendas, e quaisquer novas propostas de como lidar com as intenções seriam rejeitadas se não fossem adotadas pelos construtores. Os usuários individuais perdem o poder de negociação diante de um monopólio – um efeito que é exacerbado quando os usuários usam intenções para fornecer graus adicionais de liberdade aos intermediários.
Infelizmente, a estagnação do mercado devido à infraestrutura centralizada não inclui preocupações sobre um mercado para construtores. Mesmo para negócios de construção não quarteirões, altas barreiras à entrada colocam os intermediários em uma posição forte, já que eles enfrentam pouca concorrência. Por exemplo, considere o estado atual do mercado de leilões de fluxo de pedidos. Algumas entidades, como Flashbots e CoWswap, recebem a maior parte do fluxo de pedidos para o OFA. O fluxo de pedidos é distribuído em grande parte porque essas entidades existem há anos ou estão associadas a entidades respeitáveis, o que significa que conseguiram ganhar algum nível de confiança pública. Se um novo design de OFA tentar entrar no mercado, quem estiver executando o novo OFA terá que gastar muito tempo convencendo usuários e carteiras de que são respeitáveis e não abusarão de seu poder. A necessidade de uma campanha tão confiável certamente constitui uma barreira substancial à entrada.
O mercado de leilões de fluxo de pedidos só recentemente começou a ganhar força e resta saber como a concorrência se desenvolverá, mas o mercado fornece um exemplo ilustrativo em que mempools autorizados e confiáveis podem consagrar um pequeno número de participantes poderosos, prejudicando assim o melhores interesses dos usuários.
O formato de intenção EIP4337 fornece outro exemplo de um mecanismo que é possível para nós. Considere um mundo onde uma arquitetura confiável já está em vigor para dar suporte a 4337 intenções. Se outro formato para intenções for proposto - talvez atendendo a casos de uso adicionais, como funcionalidade de origem cruzada -, mas intermediários confiáveis estabelecidos não adotarem esse novo formato (afinal, ele não tem muita adoção e não é relevante para a concorrência do modelo de negócios ), a implementação de novos formatos requer a construção de confiança em novas entidades. Da mesma forma, nos encontramos em posição de inovar e desafiar o status quo, mas encontramos barreiras à entrada baseadas na confiança.
Opacidade
Uma vez que muitas arquiteturas de intents exigem que os usuários abram mão de algum controle sobre seus ativos on-chain, e os mempools autorizados implicam um grau de impenetrabilidade externa, corremos o risco de construir um sistema opaco onde não está claro como ou se as expectativas do usuário serão atendidas, e a ameaça ao ecossistema permanece desconhecida. *
As seções acima lidam com os riscos para usuários e protocolos que alimentam os desequilíbrios no mercado de fluxo de pedidos. Um problema relacionado é que o ecossistema de middleware e mempools que se desenvolve entre os usuários e o blockchain torna-se opaco, mesmo para observadores astutos. Essa preocupação é especialmente relevante para aplicativos baseados em intenções que procuram permitir que os usuários terceirizam decisões importantes, como roteamento de pedidos.
As situações em que o MEV afeta negativamente a execução do usuário geralmente ocorrem devido a executores que renunciam a um alto grau de liberdade na negociação (por exemplo, limites de derrapagem). Portanto, não é um grande salto de lógica afirmar que os aplicativos baseados em intenções que abrem mão de maiores graus de liberdade devem projetar seus sistemas de execução com mais cuidado. O pior resultado a esse respeito é um mundo onde o uso de um aplicativo baseado em intenção requer a assinatura de uma intenção que desaparece (em uma floresta escura, se preferir) e, de alguma forma, implementada como transações, mas não está claro como ou por quem as transações são criadas. Obviamente, a capacidade de monitorar esses ecossistemas também está relacionada a preocupações sobre EOF e defesas baseadas em confiança.
Diminuir riscos
O mempool Ethereum é limitado. Para alguns aplicativos, isso ocorre devido à falta de privacidade (clipes sanduíche), para outros, devido à incapacidade de suportar uma ampla variedade de formatos de mensagem. Isso coloca os desenvolvedores de carteiras e aplicativos em apuros, pois eles devem encontrar alguma maneira de conectar os usuários ao blockchain, evitando os perigos mencionados acima.
Ao examinar as questões acima, podemos inferir certas propriedades de sistemas ideais. Tal sistema deve ser sem permissão, para que qualquer pessoa possa combinar e executar intents sem sacrificar muito a qualidade de execução; genérico, para que a implantação de novos aplicativos não exija a construção de novos pools de memória; transparente, para que seja público Relatório sobre o processo de execução intenções e, onde as garantias de privacidade permitirem, fornecer dados para a realização de auditorias de qualidade.
Enquanto equipes como Flashbots e Anoma estão trabalhando em soluções gerais que atendem aos requisitos acima, combinando privacidade e permissão, o sistema ideal pode não estar pronto tão cedo. Portanto, diferentes soluções que fazem suas próprias compensações podem atender melhor a diferentes aplicações. Embora mecanismos como crlists tenham surgido em resposta a muitos dos mesmos problemas em torno de aplicativos baseados em transações, talvez não para intenções, seria bom usar gadgets que permitissem aos usuários recorrer a transações sempre que possível. de intents é melhor buscar a generalidade quando não são permitidos e escolher um intermediário com cuidado quando são permitidos.
De um modo geral, pedimos aos designers de aplicativos baseados em intenções que considerem minuciosamente o impacto off-chain de seus aplicativos, pois eles podem afetar comunidades mais amplas do que apenas sua base de usuários. Pedimos que a comunidade preste muita atenção ao ecossistema off-chain em torno Ethereum.
para concluir
A adoção de intents representa uma mudança de paradigmas imperativos para declarativos, o que promete melhorar significativamente a experiência do usuário e as perdas de eficiência devido ao MEV. A necessidade desses aplicativos é clara, e muitos aplicativos baseados em intenção estão em uso generalizado há muitos anos.
A maior adoção de intenções, impulsionada pelo ERC4337, pode acelerar a mudança de mempools Ethereum para novos locais. Embora a mudança seja razoável e inevitável, os projetistas de aplicativos baseados em intenções têm bons motivos para serem cuidadosos ao projetar os componentes fora da cadeia de seus sistemas ao desenvolver uma infraestrutura robusta.
Ainda há muita pesquisa e engenharia a serem feitas nesse paradigma de transação nascente e em áreas que não abordamos neste artigo, como projetar uma linguagem de expressão para intents que permita privacidade.
Muito obrigado a DanRobinson, CharlieNoyes, MattHuang, JohnGuibas, XinyuanSun e ElijahFox por seus comentários sobre este artigo, e a AchalSrinivasan pelo artigo.
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Paradigma: O paradigma de intenções das transações Ethereum - arquitetura e riscos
Autores: Quintus Kilbourn, Georgios Konstantopoulos, Paradigm; Tradução: Golden Finance 0xxz
Introdução
As discussões sobre “intenções” e suas aplicações tornaram-se um tema quente na comunidade Ethereum recentemente.
Enquanto as transações se referem especificamente a "como" uma ação deve ser executada, as intenções se referem a "qual" o resultado esperado dessa ação deve ser. Se uma transação diz "faça A primeiro, depois B, pague C integralmente para obter X", as intenções dizem "Eu quero X e estou disposto a pagar até C".
Este paradigma declarativo desbloqueia uma experiência de usuário empolgante e melhorias de eficiência. Por meio de intenções, os usuários podem simplesmente expressar um resultado desejado enquanto terceirizam a tarefa ideal de alcançar esse resultado para um terceiro experiente. O conceito de intenções está em contraste com o paradigma de transação imperativa de hoje, onde cada parâmetro é explicitamente especificado pelo usuário.
Embora essas promessas de melhorias forneçam etapas muito necessárias para o ecossistema, o design baseado em intenção no Ethereum também pode ter implicações significativas para a infraestrutura fora da cadeia. Em particular, existem links importantes para atividades relacionadas a MEV e controle de mercado. Este post tem como objetivo fornecer uma breve definição de intenções e seus benefícios, uma exploração dos riscos envolvidos em sua implementação e algumas discussões sobre possíveis atenuações.
O que são intenções?
A forma padrão atual para os usuários interagirem com o Ethereum é criar e assinar uma transação, uma mensagem em um formato específico que fornece todas as informações necessárias para a Ethereum Virtual Machine (EVM) realizar transições de estado. No entanto, criar transações pode ser um assunto complicado. A criação de uma transação requer raciocínio sobre detalhes, como uma vasta rede de contratos inteligentes e gerenciamento de nonce, mantendo ativos específicos para pagar as taxas de gás. Essa complexidade resulta em uma experiência de usuário abaixo do ideal e perda de eficiência, já que os usuários são forçados a tomar decisões sem acesso adequado a informações ou políticas de aplicação complexas.
As intenções são projetadas para aliviar esses fardos do usuário. Informalmente, as intenções assinam um conjunto de restrições declarativas que permitem aos usuários terceirizar a criação de transações para terceiros sem abrir mão do controle total das partes da transação.
Em processos padrão baseados em transações, as assinaturas de transações permitem que os verificadores sigam exatamente um caminho computacional para um determinado estado, e as dicas incentivam os verificadores a fazê-lo. As intenções, por outro lado, não especificam explicitamente o caminho computacional que deve ser seguido, mas permitem qualquer caminho computacional que satisfaça certas restrições. Ao assinar e compartilhar intenções (intenções), os usuários efetivamente concedem permissão aos destinatários para escolher caminhos de computação em seu nome (consulte o diagrama abaixo). Essa distinção permite uma definição um pouco mais estrita de intents como mensagens assinadas que permitem um conjunto de transições de estado a partir de um determinado estado inicial, sendo um caso especial as transações que permitem transições únicas. Dito isto, continuaremos a distinguir "intenções" de transações.
É importante ressaltar que muitas intenções (intenções) podem ser incluídas em uma única transação, permitindo a correspondência de intenções (intenções) sobrepostas, aumentando o gás e a eficiência econômica, por exemplo, no livro de pedidos mantido pelo construtor, dois pedidos podem ser trocados mutuamente antes de entrar no mercado compensação de mercado. Outras aplicações incluem intenções entre domínios (intenções) - assinatura de uma mensagem em vez de várias transações em domínios diferentes - uso de diferentes esquemas de resistência à reprodução (resistência à reprodução) e pagamentos de gás de usuário mais flexíveis, como permitir que as 3 primeiras partes patrocinem gás ou paguem em fichas diferentes.
passado e futuro das intenções
Foram criadas intenções que terceirizam a complexidade da interação com o blockchain, permitindo que os usuários mantenham a custódia de seus ativos e identidades criptográficas.
Você pode notar que muitas dessas ideias correspondem a sistemas que estão em operação há muitos anos:
No futuro, no contexto de MEVs de cadeia cruzada (como SUAVE), abstrações de contas no estilo ERC4337 e até pedidos de Seaport, as intenções das pessoas estão sendo revigoradas! Embora o ERC4337 esteja avançando a toda velocidade, outros novos aplicativos, como intents entre domínios, ainda exigem mais pesquisas.
Crucialmente, em todos os aplicativos baseados em intenção, antigos e novos, é necessário que haja pelo menos uma outra parte que entenda a intenção, seja motivada a executar a intenção e seja capaz de fazê-lo em tempo hábil. Perguntas sobre quem são essas partes, como elas atuam e quais são suas motivações devem ser feitas para determinar a eficácia, as suposições de confiança e as implicações mais amplas dos sistemas orientados por intenções.
O intermediário e seu mempool
O canal mais óbvio para as intenções chegarem às mãos dos intermediários é o mempool Ethereum. Infelizmente, o design atual não suporta a propagação de intents. Preocupações com ataques DoS podem significar que o suporte universal para intenções totalmente genéricas no mempool Ethereum é impossível, mesmo a longo prazo. Como veremos abaixo, a natureza aberta e sem permissão dos mempools Ethereum cria barreiras adicionais para a adoção de intents.
Na ausência de um mempool Ethereum, os projetistas de sistemas de intents agora enfrentam alguns problemas de design. Uma decisão de alto nível é propagar as intenções para o conjunto de permissões ou fornecê-las sem permissão para que qualquer uma das partes possa executar as intenções.
Figura 2: Intents fluem de usuários para pools de intents (intenções) com permissão/não permissão e públicos/privados, convertidos em transações por intermediários e, finalmente, entram no pool de memória pública ou vão diretamente para a cadeia por meio de leilões no estilo MEVBoost
Mempool sem permissão
Um projeto pelo qual alguém pode se esforçar é uma API descentralizada que permite que as intenções sejam propagadas pelos nós do sistema, fornecendo acesso sem permissão aos atores. Isso já foi feito antes. Por exemplo, as ordens de limite de fofoca entre os retransmissores de protocolo 0x e os colocam na cadeia quando correspondidos. Essa ideia também é explorada no contexto de um mempool ERC4337 compartilhado para combater os riscos de centralização e censura. No entanto, o design desse "pool de intenções" sem permissão enfrenta alguns desafios significativos:
** "Pool de memória" permitido **
APIs centralizadas confiáveis são mais resistentes a DoS e não precisam propagar intenções. Modelos confiáveis também fornecem alguma base para problemas de MEV. Enquanto a suposição de confiança for mantida, a qualidade da execução deve ser garantida. Um intermediário confiável também pode ter uma reputação associada a ele, fornecendo algum incentivo para fornecer uma boa execução. Por causa disso, pools de intents autorizados são atraentes para desenvolvedores de aplicativos baseados em intents no curto prazo. No entanto, como todos sabemos, a forte suposição de confiança é falha e um tanto antitética para grande parte do ethos do blockchain. Essas questões serão tratadas a seguir.
solução mista
Algumas soluções são misturas das anteriores. Por exemplo, pode haver permissão para propagar, mas nenhuma permissão para executar (supondo que a suposição de confiança seja válida) e vice-versa. Um exemplo comum de solução híbrida é um leilão de fluxo de pedidos.
A ideia de alto nível por trás desses designs é que um usuário que precisa de uma contraparte pode precisar distinguir entre contrapartes melhores e piores (por exemplo, a outra parte que aceita uma negociação a um preço favorável). O processo de design normalmente inclui uma parte confiável que recebe a intenção do usuário (ou transações) e facilita o leilão em seu nome. A participação em leilões é (às vezes) não autorizada.
Esses tipos de projetos têm suas próprias desvantagens e provavelmente sofrerão com muitas das preocupações relacionadas aos pools de intenção autorizados, mas há algumas distinções importantes que se tornarão aparentes posteriormente.
Resumindo: os aplicativos baseados em intenções não envolvem apenas novos formatos de mensagem para interagir com contratos inteligentes, mas também envolvem propagação alternativa no estilo mempool e mecanismos de descoberta de contraparte. Projetar um mecanismo de descoberta e correspondência de intenção que seja compatível com incentivos e descentralizado não é trivial.
Onde posso errar?
Embora as intenções sejam um novo paradigma de transação empolgante, sua adoção generalizada pode significar que a tendência maior de mudança da atividade do usuário para mempools alternativos está se acelerando. Se não for gerida de forma adequada, esta mudança pode levar à centralização e entrincheiramento de intermediários rentistas.
Fluxo de pedidos
A grande maioria da produção de blocos no Ethereum atualmente ocorre via MEV-Boost, uma implementação fora do protocolo da separação proponente-construtor (PBS), e o roteiro atual não dá nenhuma indicação de que essa interface será alterada em breve. A PBS depende da existência de um mercado competitivo para construtores de blocos para direcionar o MEV para o conjunto de validadores. Um grande problema no PBS é a capacidade dos construtores de blocos de obter acesso exclusivo às matérias-primas necessárias para produzir blocos valiosos – transações e intenções, também conhecidas como “fluxo de pedidos”. No jargão da PBS, o acesso autorizado às intenções será referido como "Fluxo de Pedido Exclusivo" (EOF). Conforme discutido neste artigo, o EOF nas mãos erradas ameaça a estrutura de mercado da qual a PBS depende, pois a exclusividade no fluxo de pedidos significa um fosso contra as forças competitivas.
Os construtores de blocos (ou entidades colaboradoras) que controlam a maior parte do fluxo de pedidos do Ethereum poderão produzir a maioria dos blocos da rede principal, abrindo um vetor para censura. Como a rede depende da competição entre os construtores para passar valor aos validadores (ou ser destruída no futuro), o domínio de um único construtor constituirá uma transferência de valor do Ethereum para os construtores. Rent-seeking e censura são, sem dúvida, ameaças significativas ao protocolo.
confiar
No pior dos casos, os usuários podem se encontrar em uma posição em que apenas uma parte executa as intenções, como o monopólio da construção de blocos na seção anterior. Em tal mundo, os monopólios de construção de blocos seriam capazes de extrair rendas, e quaisquer novas propostas de como lidar com as intenções seriam rejeitadas se não fossem adotadas pelos construtores. Os usuários individuais perdem o poder de negociação diante de um monopólio – um efeito que é exacerbado quando os usuários usam intenções para fornecer graus adicionais de liberdade aos intermediários.
Infelizmente, a estagnação do mercado devido à infraestrutura centralizada não inclui preocupações sobre um mercado para construtores. Mesmo para negócios de construção não quarteirões, altas barreiras à entrada colocam os intermediários em uma posição forte, já que eles enfrentam pouca concorrência. Por exemplo, considere o estado atual do mercado de leilões de fluxo de pedidos. Algumas entidades, como Flashbots e CoWswap, recebem a maior parte do fluxo de pedidos para o OFA. O fluxo de pedidos é distribuído em grande parte porque essas entidades existem há anos ou estão associadas a entidades respeitáveis, o que significa que conseguiram ganhar algum nível de confiança pública. Se um novo design de OFA tentar entrar no mercado, quem estiver executando o novo OFA terá que gastar muito tempo convencendo usuários e carteiras de que são respeitáveis e não abusarão de seu poder. A necessidade de uma campanha tão confiável certamente constitui uma barreira substancial à entrada.
O mercado de leilões de fluxo de pedidos só recentemente começou a ganhar força e resta saber como a concorrência se desenvolverá, mas o mercado fornece um exemplo ilustrativo em que mempools autorizados e confiáveis podem consagrar um pequeno número de participantes poderosos, prejudicando assim o melhores interesses dos usuários.
O formato de intenção EIP4337 fornece outro exemplo de um mecanismo que é possível para nós. Considere um mundo onde uma arquitetura confiável já está em vigor para dar suporte a 4337 intenções. Se outro formato para intenções for proposto - talvez atendendo a casos de uso adicionais, como funcionalidade de origem cruzada -, mas intermediários confiáveis estabelecidos não adotarem esse novo formato (afinal, ele não tem muita adoção e não é relevante para a concorrência do modelo de negócios ), a implementação de novos formatos requer a construção de confiança em novas entidades. Da mesma forma, nos encontramos em posição de inovar e desafiar o status quo, mas encontramos barreiras à entrada baseadas na confiança.
Opacidade
As seções acima lidam com os riscos para usuários e protocolos que alimentam os desequilíbrios no mercado de fluxo de pedidos. Um problema relacionado é que o ecossistema de middleware e mempools que se desenvolve entre os usuários e o blockchain torna-se opaco, mesmo para observadores astutos. Essa preocupação é especialmente relevante para aplicativos baseados em intenções que procuram permitir que os usuários terceirizam decisões importantes, como roteamento de pedidos.
As situações em que o MEV afeta negativamente a execução do usuário geralmente ocorrem devido a executores que renunciam a um alto grau de liberdade na negociação (por exemplo, limites de derrapagem). Portanto, não é um grande salto de lógica afirmar que os aplicativos baseados em intenções que abrem mão de maiores graus de liberdade devem projetar seus sistemas de execução com mais cuidado. O pior resultado a esse respeito é um mundo onde o uso de um aplicativo baseado em intenção requer a assinatura de uma intenção que desaparece (em uma floresta escura, se preferir) e, de alguma forma, implementada como transações, mas não está claro como ou por quem as transações são criadas. Obviamente, a capacidade de monitorar esses ecossistemas também está relacionada a preocupações sobre EOF e defesas baseadas em confiança.
Diminuir riscos
O mempool Ethereum é limitado. Para alguns aplicativos, isso ocorre devido à falta de privacidade (clipes sanduíche), para outros, devido à incapacidade de suportar uma ampla variedade de formatos de mensagem. Isso coloca os desenvolvedores de carteiras e aplicativos em apuros, pois eles devem encontrar alguma maneira de conectar os usuários ao blockchain, evitando os perigos mencionados acima.
Ao examinar as questões acima, podemos inferir certas propriedades de sistemas ideais. Tal sistema deve ser sem permissão, para que qualquer pessoa possa combinar e executar intents sem sacrificar muito a qualidade de execução; genérico, para que a implantação de novos aplicativos não exija a construção de novos pools de memória; transparente, para que seja público Relatório sobre o processo de execução intenções e, onde as garantias de privacidade permitirem, fornecer dados para a realização de auditorias de qualidade.
Enquanto equipes como Flashbots e Anoma estão trabalhando em soluções gerais que atendem aos requisitos acima, combinando privacidade e permissão, o sistema ideal pode não estar pronto tão cedo. Portanto, diferentes soluções que fazem suas próprias compensações podem atender melhor a diferentes aplicações. Embora mecanismos como crlists tenham surgido em resposta a muitos dos mesmos problemas em torno de aplicativos baseados em transações, talvez não para intenções, seria bom usar gadgets que permitissem aos usuários recorrer a transações sempre que possível. de intents é melhor buscar a generalidade quando não são permitidos e escolher um intermediário com cuidado quando são permitidos.
De um modo geral, pedimos aos designers de aplicativos baseados em intenções que considerem minuciosamente o impacto off-chain de seus aplicativos, pois eles podem afetar comunidades mais amplas do que apenas sua base de usuários. Pedimos que a comunidade preste muita atenção ao ecossistema off-chain em torno Ethereum.
para concluir
A adoção de intents representa uma mudança de paradigmas imperativos para declarativos, o que promete melhorar significativamente a experiência do usuário e as perdas de eficiência devido ao MEV. A necessidade desses aplicativos é clara, e muitos aplicativos baseados em intenção estão em uso generalizado há muitos anos.
A maior adoção de intenções, impulsionada pelo ERC4337, pode acelerar a mudança de mempools Ethereum para novos locais. Embora a mudança seja razoável e inevitável, os projetistas de aplicativos baseados em intenções têm bons motivos para serem cuidadosos ao projetar os componentes fora da cadeia de seus sistemas ao desenvolver uma infraestrutura robusta.
Ainda há muita pesquisa e engenharia a serem feitas nesse paradigma de transação nascente e em áreas que não abordamos neste artigo, como projetar uma linguagem de expressão para intents que permita privacidade.
Muito obrigado a DanRobinson, CharlieNoyes, MattHuang, JohnGuibas, XinyuanSun e ElijahFox por seus comentários sobre este artigo, e a AchalSrinivasan pelo artigo.