Paradigma: Arquitetura Baseada em Intenção e Seus Riscos

Escrito por: Quintus Kilbourn, Georgios Konstantopoulos Compilado por: Kate, Marsbit

introduzir

As discussões sobre “intenções” e suas aplicações tornaram-se um tema quente na comunidade Ethereum recentemente.

Onde as transações se referem explicitamente a “como” uma ação deve ser executada, a intenção refere-se a qual deve ser o resultado esperado dessa ação. Se o conteúdo da transação for “faça A primeiro, depois B, pague C para obter X”, então a intenção é “Quero X e estou disposto a pagar C”.

Este paradigma declarativo traz melhorias interessantes na experiência e eficiência do usuário. Com as intenções, os usuários podem simplesmente expressar um resultado desejado enquanto terceirizam a tarefa de alcançar esse resultado de maneira ideal para um terceiro experiente. O conceito de intenção contrasta com o paradigma de transação imperativo atual, onde cada parâmetro é especificado explicitamente pelo usuário.

Embora a promessa dessas melhorias forneça um passo em frente muito necessário para o ecossistema, o design baseado em intenções no Ethereum também pode ter implicações significativas para a infraestrutura fora da cadeia. Em particular, existem ligações importantes entre as atividades relacionadas com o MEV e o controlo do mercado. Este artigo tem como objetivo fornecer uma breve definição de intenção e seus benefícios, explorar os riscos envolvidos na sua implementação e discutir possíveis mitigações.

O que é uma intenção?

A forma padrão atual de interação dos usuários com o Ethereum é criar e assinar transações que forneçam todas as informações necessárias em um formato específico para que a Máquina Virtual Ethereum (EVM) execute transições de estado. No entanto, criar transações pode ser complicado. A criação de uma transação requer raciocínio sobre detalhes como uma vasta rede de contratos inteligentes e gerenciamento de nonce, ao mesmo tempo que mantém um ativo específico para pagar as taxas de gás. Esta complexidade resulta numa experiência de utilizador abaixo do ideal e na perda de eficiência, uma vez que os utilizadores são forçados a tomar decisões sem acesso adequado a informações ou políticas de aplicação complexas.

Há uma intenção de aliviar esses encargos. Informalmente, as intenções são assinadas como 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ção permitem que os validadores sigam exatamente um caminho computacional para um estado, e as dicas incentivam os validadores a fazer isso. As intenções, por outro lado, não especificam o caminho computacional que deve ser seguido, mas permitem qualquer caminho computacional que satisfaça certas restrições. Ao assinar e compartilhar intenções, os usuários concedem efetivamente permissões aos destinatários para escolherem caminhos de computação em seu nome (veja o diagrama abaixo). Esta distinção permite uma definição um pouco mais rigorosa de intenções como mensagens assinadas, permitindo 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ção” de transações.

*Figura 1: Ao enviar uma transação, o usuário especifica o caminho de cálculo exato. Ao enviar uma intenção, o usuário especifica um objetivo e algumas restrições, e o processo de correspondência decide o caminho computacional a seguir. *

É importante ressaltar que muitas intenções podem ser incluídas em uma única transação, permitindo que intenções sobrepostas sejam correspondidas, aumentando a eficiência econômica e de gás, por exemplo, em uma carteira de pedidos mantida por um construtor, duas ordens podem ser canceladas antes de entrarem no mercado. Outras aplicações incluem intenções entre domínios – assinatura de uma única mensagem, em vez de múltiplas transações em domínios diferentes – com diferentes esquemas de resistência à repetição e pagamentos de gás de usuário mais flexíveis, como permitir que terceiros patrocinem gás ou em diferentes pagamentos de token.

passado e futuro são intenções

A intenção foi criada para terceirizar a complexidade da interação com o blockchain, ao mesmo tempo que permite aos usuários manter 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:

• Pedido com limite: 100X podem ser debitados da minha conta se eu receber pelo menos 200Y.
• Leilões no estilo CowSwap: iguais aos anteriores, mas dependem de terceiros ou mecanismos para combinar muitos pedidos e maximizar a qualidade da execução.
• Patrocínio de Gás: Pague Gás com USDC em vez de ETH. Esta intenção só pode ser cumprida por uma intenção correspondente que pague uma taxa à ETH.
• Autorização: permite apenas a interação com determinadas contas de determinadas formas pré-autorizadas. Uma intenção só pode ser cumprida se a transação resultante obedecer à lista de controle de acesso especificada na intenção.
• Lote de transações: permite o lote de intenções para melhorar a eficiência e reduzir as taxas de gás.
• Agregadores: operam usando apenas o “melhor” preço/rendimento. Esta intenção pode ser alcançada provando que a agregação de múltiplos locais é realizada e o melhor caminho é seguido.

No futuro, a intenção está sendo revigorada no contexto de MEVs entre cadeias (como SUAVE), abstrações de contas no estilo ERC4337 e até mesmo pedidos do Seaport! Embora o ERC4337 esteja avançando a todo vapor, outras aplicações novas, como intenções de domínio cruzado, ainda exigem mais pesquisas. Uma discussão mais aprofundada sobre intenções e suas aplicações pode ser encontrada nesta palestra.

Crucialmente, em todos os aplicativos antigos e novos baseados em intenções, é necessário que haja pelo menos uma outra parte que entenda a intenção, esteja motivada para executá-la e seja capaz de executá-la em tempo hábil. Quem são estas partes, como ocorre a execução e quais são as suas motivações são questões que devem ser colocadas para determinar a eficácia, os pressupostos de confiança e as implicações mais amplas dos sistemas orientados pela intenção.

O intermediário e seu mempool

O canal mais óbvio é o mempool Ethereum. Infelizmente, o design atual não suporta a propagação de intenção. As preocupações com os ataques DoS podem significar que o suporte geral para intenções totalmente gerais no mempool Ethereum é impossível, mesmo no longo prazo. Como veremos abaixo, a natureza aberta e sem permissão do mempool Ethereum apresenta uma barreira adicional às intenções de adoção.

Na ausência de um mempool Ethereum, os projetistas de sistemas de intenção agora enfrentam alguns problemas de design. Uma decisão de alto nível é propagar a intenção para um conjunto com permissão ou fornecê-la sem permissão para que qualquer uma das partes possa executar a intenção.

Figura 2: Fluxo de intenções dos usuários para pools de intenções com/sem permissão e públicos/privados, convertidos por matchmakers em transações e, finalmente, em pools de memória públicos ou diretamente na cadeia por meio de leilões estilo boost MEV

Conjunto de memória não licenciado

Um design que se pode buscar é uma API descentralizada que permite que a intenção seja propagada entre nós do sistema, fornecendo aos executores acesso sem permissão. Isso já foi feito antes. Por exemplo, no protocolo 0x, os retransmissores conversam sobre pedidos limitados entre si e os colocam na cadeia quando há uma correspondência. Esta ideia também foi explorada no contexto de um mempool ERC4337 partilhado para combater os riscos de centralização e censura. No entanto, o design de tal “conjunto de intenções” sem permissão enfrenta alguns desafios significativos:

• Resistência DoS: pode ser necessário limitar a funcionalidade das intenções para evitar vetores de ataque (ver proposta ER C4337 para discussão mais aprofundada)
• Propagar incentivos: Para muitas aplicações, impor a intenção é uma atividade lucrativa. Portanto, os nós que operam o pool de intenções têm um incentivo para não propagar intenções para reduzir a contenção ao executar intenções.
• MEV: As intenções dependem do bom comportamento dos atores fora da cadeia para melhorar a qualidade da execução, o que pode ser difícil ao usar pools de intenções públicas e sem permissão. Se a má execução for lucrativa, os pools de intenções sem permissão provavelmente levarão a esse resultado. Isso é semelhante aos mempools Ethereum de hoje e espera-se que se torne um problema comum relacionado ao DeFi. Um possível caminho a seguir aqui poderia ser pools de intenções sem permissão, mas criptografados.

"pools de memória" permitidos

APIs centralizadas confiáveis são mais resistentes a ataques DoS e não precisam propagar intenções. Os modelos de confiança também fornecem alguma base para problemas de MEV. Enquanto a suposição de confiança se mantiver, a qualidade da execução deverá ser garantida. Os intermediários de confiança também podem ter uma reputação associada a eles, o que lhes proporciona um incentivo para executarem bem. Portanto, pools de intenções permitidas são atraentes para desenvolvedores de aplicativos baseados em intenções no curto prazo. No entanto, estamos todos cientes de que a forte suposição de confiança é falha e um tanto antitética em relação a grande parte do espírito das blockchains. Essas questões são discutidas abaixo.

Solução híbrida

Algumas soluções são misturas das anteriores. Por exemplo, pode haver permissão para propagação, mas nenhuma permissão para execução (assumindo 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 geral por trás desses designs é que os usuários que precisam de contrapartes podem precisar distinguir entre contrapartes melhores e piores (por exemplo, a outra parte que aceita uma negociação a um preço favorável). Os fluxos de design normalmente incluem uma parte confiável que recebe intenções (ou transações) dos usuários e facilita leilões em nome dos usuários. Participar de leilões (às vezes) não requer permissão.

Esses tipos de projetos têm suas próprias desvantagens e provavelmente serão afetados por muitos conjuntos de intenções de permissão, mas há algumas distinções importantes que ficarão aparentes mais tarde.

Resumindo: os aplicativos baseados em intenção não envolvem apenas novos formatos de mensagens para interagir com contratos inteligentes, mas também envolvem mecanismos de propagação e descoberta de adversários na forma de mempools alternativos. Projetar um mecanismo de descoberta e correspondência de intenções que seja compatível com incentivos e ao mesmo tempo descentralizado não é trivial.

Onde posso errar?

Embora as intenções sejam um novo paradigma de transação interessante, sua adoção generalizada pode significar a aceleração de uma tendência maior de transferência da atividade do usuário para outros mempools. Se não for gerida de forma adequada, esta mudança poderá levar à centralização e ao fortalecimento de intermediários que procuram rendas.

Fluxo de pedidos

A migração do mempool público poderia centralizar a produção de blocos do Ethereum se a execução da intenção for permitida e o conjunto de permissões não for escolhido com cuidado.

A migração do mempool público poderia centralizar a produção de blocos no Ethereum se a execução da intenção fosse permitida, mas o conjunto de permissões não fosse escolhido com cuidado.

A grande maioria da produção de blocos no Ethereum ocorre atualmente via MEV-Boost, uma implementação fora do protocolo de separação proponente-construtor (PBS), e o roteiro atual não dá nenhuma indicação de que esta interface mudará em breve. A PBS depende da existência de um mercado competitivo para construtores de blocos para direcionar o MEV para o conjunto validador. Um grande problema com o PBS é que os construtores de blocos obtêm 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 permitido às intenções é conhecido como Exclusive Order Flow (EOF). Tal como discutido neste artigo, um EOF nas mãos da parte errada ameaça a estrutura de mercado em que o PBS se baseia, uma vez que a exclusividade do fluxo de ordens implica 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 serão capazes de produzir a maioria dos blocos da rede principal, abrindo um caminho para a censura. Como a rede depende da competição entre construtores para repassar valor aos validadores (ou ser queimada no futuro), o domínio de um único construtor constituirá uma transferência de valor do Ethereum para os construtores. A procura de renda e a censura são, obviamente, ameaças importantes ao protocolo.

confiar

Uma vez que muitas soluções exigem confiança num intermediário, o desenvolvimento de novas arquiteturas baseadas em intenções é dificultado por elevadas barreiras à entrada, o que significa taxas mais baixas de inovação e concorrência para garantir a qualidade da execução.

Na pior das hipóteses, os usuários se encontram em uma posição em que apenas uma parte executa a intenção, como o construtor de bloco monopolista da seção anterior. Num mundo assim, os construtores de blocos monopolistas seriam capazes de extrair rendas, e quaisquer novas propostas sobre como lidar com a intenção seriam rejeitadas se não fossem adoptadas pelos construtores. Os utilizadores individuais perdem poder de negociação face a um monopólio – um efeito que é exacerbado quando os utilizadores pretendem dar graus adicionais de liberdade aos intermediários.

Infelizmente, a estagnação do mercado devido à infra-estrutura centralizada não inclui preocupações sobre um mercado para construtores. Mesmo para empresas de construção não-bloco, uma elevada barreira à entrada pode colocar os intermediários numa posição vantajosa, uma vez que enfrentam pouca concorrência. Por exemplo, considere o estado atual do mercado de leilões de fluxo de ordens. Algumas entidades como Flashbots e CoWswap recebem a maior parte dos pedidos que chegam ao 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 quer que esteja administrando o novo OFA terá que gastar muito tempo convencendo os usuários e as carteiras de que são respeitáveis e não abusarão de seu poder. Esta necessidade de ganhar confiança representa certamente uma barreira significativa à entrada.

O mercado de leilões de fluxo de ordens só recentemente começou a ganhar força, e resta saber como a concorrência se desenvolverá, mas o mercado fornece um exemplo ilustrativo onde mempools autorizados e confiáveis podem conter 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 mecanismo possível. Considere um mundo onde existem arquiteturas confiáveis para suportar intenções 4337. Se outro formato de intenção fosse proposto, ele poderia servir outros casos de uso, como funcionalidade de origem cruzada, mas intermediários confiáveis estabelecidos não adotam esse novo formato (afinal, ele não é muito adotado e compete com seu modelo de negócios), implementações do novo formato necessitarão de estabelecer confiança na nova entidade. Mais uma vez, encontramo-nos numa situação em que a inovação e o desafio ao status quo encontram barreiras à entrada com base na confiança.

Opacidade

Como muitas arquiteturas de intenção exigem que os usuários abram mão de algum controle sobre seus ativos na cadeia, e os mempools autorizados implicam um grau de impermeabilidade externa, corremos o risco de construir um sistema opaco no qual o que os usuários esperam ou se é atendido não está claro , e as ameaças ao ecossistema permanecem sem serem detectadas.

As seções acima tratam dos riscos que os desequilíbrios de poder nos mercados de fluxo de ordens representam para usuários e protocolos. Um problema relacionado é que o ecossistema de middleware e mempools desenvolvido entre os usuários e o blockchain torna-se opaco até mesmo para observadores atentos. Esse problema se aplica especialmente a aplicativos baseados em intenção que tentam permitir que os usuários terceirizem decisões importantes, como o roteamento de pedidos.

As situações em que o MEV impacta negativamente a execução do usuário geralmente se devem ao fato de as transações concederem um alto grau de liberdade aos seus executores (por exemplo, limites de derrapagem). Portanto, não é um grande salto lógico afirmar que as aplicações baseadas em intenções que abrem mão de maiores graus de liberdade deveriam projetar seus sistemas para serem executados com mais cuidado. O pior resultado a esse respeito é que o uso de um aplicativo baseado em intenção requer a assinatura de uma intenção de desaparecimento (em uma floresta escura, se preferir), que é então de alguma forma implementada como uma transação sem que fique claro como ou por quem foi criada. É claro que a capacidade de monitorizar tais ecossistemas também está relacionada com preocupações sobre EOF e defesas baseadas na confiança. Se este ecossistema é obscuro para os observadores mais atentos, como é que a comunidade Ethereum deverá monitorizar as ameaças à saúde do seu ecossistema de produção de blocos?

Diminuir riscos

O mempool Ethereum é limitado. Para alguns aplicativos, isso se deve à falta de privacidade (imprensada no meio) e, para outros, à incapacidade de suportar uma gama mais ampla de formatos de mensagens. Isso coloca os desenvolvedores de carteiras e aplicativos em uma situação difícil, 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 deveria ser

Sem permissão, para que qualquer pessoa possa combinar e executar intenções sem sacrificar muita qualidade de execução

Genérico para que a implantação de novos aplicativos não exija a criação de novos pools de memória,

Transparente para que o processo de reporte da execução da intenção seja divulgado publicamente sempre que as garantias de privacidade o permitam, e forneça dados para a realização de auditorias de qualidade.

Embora equipes como Flashbots e Anoma estejam trabalhando em soluções gerais que atendam aos requisitos acima, combinando privacidade e ausência de permissão, o sistema ideal pode não estar pronto tão cedo. Portanto, diferentes soluções fazem suas próprias compensações que podem atender melhor a diferentes aplicações. Embora mecanismos como crlists tenham surgido em resposta a muitos dos mesmos problemas que envolvem aplicativos baseados em transações e possam não ser aplicáveis à intenção, um gadget que permita aos usuários recorrer às transações sempre que possível faria bem em melhorar o pior caso. Da mesma forma, os aplicativos que desejam iniciar um pool de intenções, se não tiverem permissão, farão bem em buscar pontos em comum e, se o fizerem, escolherão os intermediários com cuidado.

Em termos gerais, pedimos aos designers de aplicações baseadas em intenções que considerem plenamente o impacto fora da cadeia das suas aplicações, porque estas podem afectar a comunidade mais ampla, não apenas a sua base de utilizadores, e pedimos à comunidade mais ampla que se concentre de perto no mundo fora da cadeia. ecossistema em torno de Ethereum.

para concluir

A adoção de intenções representa uma mudança de um paradigma imperativo para um paradigma declarativo, que promete melhorar significativamente a experiência do usuário e as perdas de eficiência devido a vazamentos de MEV. A necessidade desses aplicativos é clara e muitos aplicativos baseados em intenções têm sido amplamente utilizados há muitos anos.

A crescente intenção de adoção, impulsionada pelo ERC4337, pode acelerar a transferência de mempools Ethereum para novos locais. Embora esta mudança seja razoável e inevitável, os designers de aplicações baseadas em intenções têm boas razões para projetar cuidadosamente os componentes fora da cadeia dos seus sistemas ao desenvolverem infraestruturas robustas.

Ainda há muita pesquisa e engenharia a serem feitas nesse paradigma transacional nascente e em áreas que não abordamos neste artigo, como o projeto de uma linguagem de expressão de intenção que permita privacidade. Se você achar interessante este ou outros tópicos de pesquisa relacionados à intenção, entre em contato com 0xquintus georgios@paradigm.xyz.

*Muito obrigado a Dan Robinson, Charlie Noyes, Matt Huang, John gu, Xinyuan Sun e Elijah Fox pelos comentários sobre este artigo, e Achal Srinivasan pelo design dos gráficos. *