Recentemente, tem havido uma discussão acalorada na comunidade Ethereum sobre a intenção e as suas aplicações. Este artigo tem como objetivo fornecer uma breve visão geral dos princípios por trás da intenção, suas aplicações atuais, riscos potenciais e métodos para resolvê-los.

Se a transação se refere explicitamente a como um comportamento é executado, então a intenção refere-se ao resultado esperado desse comportamento.

Por exemplo, se as instruções de uma transação são:

“Faça A, depois faça B, depois pague C para obter D.”

A intenção correspondente seria:

“Posso pagar e quero ter um D.”

Os protocolos centrados na intenção podem melhorar significativamente a experiência e a eficiência do utilizador. As transações exigem que os utilizadores especifiquem explicitamente cada parâmetro, aumentando a barreira de entrada. Em contraste, usando o Intenção, os utilizadores podem simplesmente expressar o resultado esperado enquanto terceirizam a tarefa de alcançar os resultados da melhor forma a um terceiro maduro.

Embora a intenção forneça mais possibilidades para o ecossistema, os designs baseados em intenção na cadeia Ethereum podem impactar significativamente as infraestruturas fora da cadeia. As atividades relacionadas com MEV e controlo de mercado estão crucialmente ligadas aos designs baseados em intenção na cadeia.

Como funciona a intenção

Atualmente, o método padrão para os utilizadores interagirem com o Ethereum envolve a formulação e assinatura de transações e mensagens num formato específico que fornece ao EVM toda a informação necessária para realizar transições de estado. No entanto, a criação de transações pode envolver operações bastante complexas, o que requer operações intrincadas substanciais relativas a contratos inteligentes e gestão nonce, mantendo ativos específicos para pagar taxas de gás. Os meandros levam a uma má experiência do utilizador e a uma eficiência reduzida, uma vez que os utilizadores precisam de tomar decisões sem informação suficiente ou envolvendo estratégias de execução complexas.

O objetivo da intenção é reduzir o fardo dos utilizadores. As intenções permitem aos utilizadores terceirizarem a criação de transações a terceiros sem abrir mão do controlo total assinando um conjunto de restrições descritivas.

Num processo padrão baseado em transações, quando os validadores são incentivados a verificar, as assinaturas de transação permitem que os validadores sigam com precisão o caminho computacional para um estado específico. Em contraste, uma intenção não especifica exatamente quais caminhos computacionais devem ser tomados, mas permite qualquer ação que satisfaça restrições específicas. Ao assinar e partilhar intenções, o utilizador concede efetivamente ao destinatário permissão para escolher o caminho computacional em seu nome (como mostrado na figura abaixo). Vale a pena notar que várias intenções podem ser incluídas numa única transação, permitindo que intenções sobrepostas sejam combinadas, poupando taxas de gás e melhorando a eficiência económica. Além disso, os utilizadores podem pagar taxas de gás de forma mais flexível, permitindo o patrocínio de gás por terceiros ou pagamentos usando tokens alternativos.

Como mostrado na figura, ao submeter uma transação, os utilizadores especificam o caminho computacional exato, enquanto ao submeter a intenção, os utilizadores especificam o objetivo e algumas condições de restrição, com matchmaking determinando o caminho computacional a seguir.

Aplicações Atuais de Intenção

Criar intenções tercioriza as complexidades da interação com a cadeia de blocos enquanto permite aos utilizadores manter a custódia dos seus ativos e identidades criptográficas. Na verdade, muitos conceitos sobre intenção correspondem a sistemas que estão a funcionar há vários anos, tais como os seguintes cenários:

Limite de ordens: Se um utilizador receber pelo menos 200 fichas B, pode retirar 100 tokens A da sua conta.

Leilão ao estilo Cowswape: Semelhante a ordens limitadas mas depende de terceiros ou mecanismos para corresponder a várias ordens para otimizar a qualidade de execução.

Patrocínio de gás: Os utilizadores podem optar por pagar taxas de transação em USDC em vez de ETH, e há USDC na conta para pagar as taxas de gás.

Autorização delegada: Permite a interação com contas específicas apenas de determinadas formas pré-autorizadas. Uma intenção só pode ser cumprida se a transação final seguir a lista de controlo de acesso especificada na intenção.

Processamento de transações em lote: Permite o processamento em lote de múltiplas intenções para melhorar a eficiência do gás.

Agregadores: Opera apenas com o melhor preço/rendimentos. Cumpra a intenção provando a agregação de vários cenários e seguindo o caminho ideal.

Atualmente, o intent encontrou novas aplicações em MEV de cadeia cruzada (como SUAVE), abstrações de contas ERC4337 e cenários de pedidos Seaport. À medida que o ERC4337 evolui, a exploração para outras novas aplicações, como a intenção entre domínios, também está em curso.

Em todas as aplicações baseadas em intenção, é necessário haver pelo menos um grupo que compreenda a intenção e seja incentivado a executar a intenção em tempo hábil. Quanto a quem desempenha este papel, como é implementado e os seus incentivos, são necessárias mais exploração e prática para determinar a eficácia, a confiança e outros impactos dos sistemas orientados por intenção.

Intermediários e Mempool

A maneira mais óbvia de colocar intenções nas mãos de intermediários dispostos é o Ethereum Mempool. No entanto, o design atual do Mempool não suporta a propagação da intenção. As perspectivas de longo prazo sugerem uma probabilidade mínima de suporte generalizado para intenções dentro do Ethereum Mempool, considerando a vulnerabilidade dos ataques DOS. A natureza aberta e sem permissão do Ethereum Mempool apresenta uma barreira à adoção da intenção.

Na ausência do Ethereum Mempool, os designers de sistemas de intenções enfrentam alguns desafios. O dilema atual gira em torno de propagar a intenção a partes com permissão ou fazê-lo de maneira sem permissão para que qualquer parte possa executar a intenção.

Como mostra a figura acima, a intenção flui primeiro do utilizador para o Intentpool público/privado, público/privado e depois converte-o numa transação através do matchmaker e, finalmente, converte-o num Mempool público, ou apresenta-o diretamente na cadeia através dos leilões MEV Boost.

Mempool sem permissão

Um design que está a ser experimentado é uma API descentralizada que permite que vários nós no sistema transmitam intenções através de fofocas, concedendo assim acesso sem permissão aos executores.

Por exemplo, nos relayers do protocolo 0x, a transmissão de fofocas é facilitada para ordens limitadas, sendo empurrada na cadeia ao encontrar correspondências. Esta abordagem está também a ser explorada no contexto do ERC4337 Mempool partilhado para combater os riscos de centralização e censura. No entanto, o design deste Intentpool sem permissão também enfrenta alguns desafios, incluindo:

Resistência DoS: Os programadores podem ter de limitar a funcionalidade das intenções para evitar potenciais ataques DoS.

Incentivos de propagação: Para muitas aplicações, executar intenções é uma atividade rentável. Portanto, teoricamente, os nós que operam o Intentpool têm um incentivo para não propagar intenções para reduzir a concorrência pela execução de intenções.

MEV: Uma vez que a qualidade de execução das intenções depende do bom comportamento dos participantes fora da cadeia, existem algumas dificuldades enfrentadas ao usar Intentpools públicos e sem permissão. Se a execução for rentável, um Intentpool sem permissão pode tentar fazer arbitragem contra os utilizadores. Isto é semelhante aos “ataques sanduíche” no Ethereum Mempool, o que será um problema comum para intenções relacionadas com o DeFI. Uma melhoria potencial poderia ser a criação de um Intentpool sem permissão mas encriptado.

Mempool Permissionado

As APIs centralizadas de confiança são mais resistentes a ataques DOS e não precisam de propagar intenções. Este modelo de confiança fornece alguma base para as preocupações do MEV. Enquanto o pressuposto de confiança for válido, a qualidade da execução pode ser garantida. Intermediários de confiança também podem ter uma reputação associada a eles, incentivando a execução séria.

Portanto, os Intentpools permissíveis são atraentes para os programadores de aplicações baseadas em intenção a curto prazo. No entanto, suposições de confiança fortes têm inerentemente falhas e, em certa medida, contradizem o design original da blockchain.

Soluções Híbridas

Existem também soluções que são uma mistura das duas situações mencionadas acima. Por exemplo, há uma situação em que o processo de propagação é permissível mas a execução não tem permissão e vice-versa. Um exemplo comum de uma solução híbrida são os leilões de fluxo de encomendas.

A ideia por trás deste tipo de design é que os utilizadores que precisam de contrapartes podem ter de diferenciar entre contrapartes melhores e piores para negociar a preços mais favoráveis. O processo de design envolve normalmente uma parte de confiança que obtém a intenção (ou transação) do utilizador e facilita leilões em nome do utilizador. Não é necessária permissão para participar no leilão. No entanto, estes designs também têm desvantagens, na medida em que são suscetíveis a várias perturbações dentro do Intentpool permissível.

O ponto principal desta abordagem é que as aplicações baseadas em intenção envolvem não só novos formatos de mensagem para interagir com contratos inteligentes, mas também mecanismos de propagação e descoberta de pares na forma de alternativas ao Mempool. A coisa mais crítica no momento é projetar um mecanismo de descoberta de intenção e correspondência compatível com incentivos, mantendo a descentralização.

Riscos e Estratégias de Mitigação

Embora as intenções sejam um novo paradigma empolgante para as transações, a sua adoção generalizada pode implicar uma aceleração de uma tendência maior de mudança da atividade do utilizador para mempools alternativos. Se gerida indevidamente, esta mudança pode prejudicar a descentralização do Ethereum e levar a um poder excessivo das partes de confiança. Os riscos potenciais incluem o seguinte:

Fluxo de ordens: Se a execução da intenção for autorizada, mas os utilizadores a escolherem descuidadamente e a migrarem do Mempool público, a produção de blocos Ethereum pode tornar-se centralizada.

Confiança: Uma vez que muitas soluções exigem confiança nos intermediários, a fim de garantir a qualidade de execução dos Intents, esta alta barreira à entrada dificultará o desenvolvimento de novas arquiteturas baseadas em intenção e reduzirá a velocidade da inovação e da concorrência.

Transparência: Várias arquiteturas de intenção comprometem o controlo dos utilizadores sobre os seus ativos na cadeia e o mempool permissionado, introduzindo um nível de opacidade. Esta opacidade representa o risco de o sistema que está a ser construído ser opaco. Neste caso, não está claro como as expectativas dos utilizadores são satisfeitas e se existem ameaças não detectadas ao ecossistema. Até o ecossistema de middleware e mempool que evolui entre os utilizadores e a cadeia de blocos pode tornar-se opaco também.

Então, como reduzir esses riscos? Sabemos que o espaço do Ethereum Mempool é limitado. Para algumas aplicações, surgem riscos devido à sua falta de privacidade, impedindo-as de suportar uma gama mais ampla de formatos de mensagem. Isto coloca os programadores de carteira e aplicações numa posição difícil, uma vez que têm de encontrar alguma forma de permitir que os utilizadores liguem-se à cadeia de blocos, evitando os riscos mencionados acima. O sistema ideal deve ser sem permissão para que qualquer pessoa possa igualar e executar intenções sem sacrificar muita qualidade de execução. O sistema deve ser versátil para que novas aplicações possam ser implementadas sem a necessidade de criar novos mempools. Os sistemas devem ser transparentes, permitindo a comunicação pública do processo de execução das intenções e fornecendo dados para a realização de auditorias de qualidade quando as garantias de privacidade permitirem.

Embora equipas como FlashBots e Anoma estejam a trabalhar arduamente para cumprir os requisitos acima para uma solução universal, combinando privacidade e falta de permissão, será difícil criar um sistema tão perfeito num futuro próximo. Portanto, os utilizadores precisam de fazer compensações e escolher soluções diferentes para diferentes aplicações. Da mesma forma, as aplicações que iniciam intentpools precisam de procurar a ubiquidade sem permissão e escolher os intermediários cuidadosamente onde a permissão está disponível.

Os designers de aplicações baseadas em intenção precisam considerar completamente as implicações fora da cadeia das suas aplicações, uma vez que dizem respeito não apenas à sua base de utilizadores, mas à comunidade em geral. Isto exige que a comunidade em geral preste especial atenção aos ecossistemas fora da cadeia em torno do Ethereum.

Conclusão

Devido à óbvia procura do mercado por aplicações baseadas em intenção, muitas aplicações baseadas em intenção têm sido amplamente utilizadas há vários anos. A crescente adoção da intenção, parcialmente impulsionada pelo ERC4337, pode acelerar a mudança do Ethereum Mempool para novos espaços. A adoção da intenção representa uma mudança para os utilizadores de um paradigma de “operação forçada” para um “descritivo”, prometendo melhorias significativas na experiência e eficiência do utilizador.

Site oficial do Ebunker: https://www.ebunker.io

Para mais discussões, junte-se a: https://t.me/ebunkerio

E-bunker Twitter: https://twitter.com/ebunker_eth

Isenção de responsabilidade：

1. Este artigo foi reimpresso de [Medium]. Todos os direitos de autor pertencem ao autor original [eBunkerChinese]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.