Autor original: Arquivo de leituras de espelho favoritas
Compilação original: Shenchao TechFlow
Resumo dos pontos principais
A experiência do usuário com criptografia padrão atual permite que os usuários sempre saibam com qual rede estão interagindo. No entanto, os usuários da Internet não precisam saber com qual provedor de nuvem estão interagindo. A introdução dessa abordagem ao blockchain é o que chamamos de Abstração de Cadeia.
Este artigo apresenta a estrutura Chain Abstraction Key Elements (CAKE). A estrutura consiste em quatro partes: camada de aplicação, camada de permissão, camada de resolução e camada de liquidação, com o objetivo de fornecer aos usuários uma experiência de operação contínua entre cadeias.
A implementação da abstração da cadeia requer um conjunto complexo de tecnologias para garantir confiabilidade, economia, segurança, velocidade e privacidade do processo de execução.
Definimos os trade-offs entre cadeias na abstração da cadeia como um trilema e propomos seis alternativas de design, cada uma com suas vantagens únicas.
Para dar o salto com sucesso para um futuro de abstração encadeada, como indústria, devemos definir e adotar um padrão comum para a passagem de informações entre as camadas do CAKE. Um bom padrão é a cereja do bolo.
Introdução
Em 2020, a rede Ethereum fez a transição para um roteiro de escalonamento centrado no rollup. Quatro anos depois, mais de 50 camadas rollup (L2) estão em uso. Embora a camada rollup forneça o dimensionamento horizontal necessário, ela quebra completamente a experiência do usuário.
Os usuários não devem se importar ou compreender com qual rollup estão interagindo. Os usuários de criptografia sabem qual rollup estão usando (Optimism ou Base), equivalente a usuários Web2 saberem qual provedor de nuvem estão usando (AWS ou GCP). A visão da Chain Abstraction é abstrair as informações da cadeia do campo de visão do usuário. O usuário simplesmente conecta a carteira ao dApp e assina as ações pretendidas, os detalhes para garantir que o usuário tenha o equilíbrio correto na cadeia de destino e execute as ações pretendidas são todos resolvidos nos bastidores.
Neste artigo, exploraremos como a abstração em cadeia é um problema verdadeiramente multidisciplinar que envolve a interação da camada de aplicação, camada de permissões, camada de resolução e camada de liquidação. Apresentamos a estrutura Key Elements of Chain Abstraction (CAKE) e nos aprofundamos nas compensações de design de sistemas de abstração de cadeia.
Apresentando a estrutura CAKE
No mundo da abstração em cadeia, os usuários visitam o site do dApp, conectam-se à sua carteira, assinam as operações e aguardam a liquidação final. Todas as operações complexas são realizadas na camada de infraestrutura do CAKE. As três camadas de infraestrutura do CAKE incluem:
Camada de permissões: os usuários conectam suas carteiras aos dApps e solicitam cotações de acordo com a intenção do usuário. A intenção se refere ao resultado que o usuário espera obter no final da transação, não ao caminho da transação. Por exemplo, transfira USDT para um endereço Tron ou deposite USDC em uma estratégia de geração de rendimento no Arbitrum. A carteira deve ser capaz de ler os ativos do usuário (ou seja, ler o estado) e realizar transações na cadeia de destino (ou seja, atualizar o estado).
Camada Solver: A camada solucionadora estima taxas e velocidade de execução com base no saldo inicial e na intenção do usuário. Em um ambiente de cadeia cruzada, esse processo, chamado de resolução, é crítico porque as transações são assíncronas e as subtransações podem falhar durante a execução. A assincronicidade introduz um trilema entre cadeias envolvendo taxas, velocidade de execução e garantias de execução.
Camada de liquidação: Depois que um usuário aprova uma transação usando uma chave privada, a camada de liquidação garante sua execução. Consiste em duas etapas: conectar os ativos do usuário à cadeia de destino e, em seguida, executar a transação. Se os protocolos utilizarem solucionadores complexos para determinadas operações, eles poderão fornecer sua própria liquidez e realizar operações em nome dos usuários sem a necessidade de pontes.
Implementar a abstração em cadeia significa fundir as três camadas de infraestrutura acima em um produto unificado. Um insight importante na fusão dessas camadas é a diferença entre entrega de informações e entrega de valor. A transferência de informações entre cadeias deve ocorrer sem perdas, portanto, confie no caminho mais seguro. Por exemplo, os utilizadores que votam “sim” numa cadeia para um voto de governação noutra cadeia não querem que o seu voto se torne “talvez”. Por outro lado, dependendo das preferências do usuário, a entrega de valor pode ser perdida. Um terceiro estabelecido pode ser aproveitado para fornecer aos usuários uma entrega de valor mais rápida, mais barata ou garantida. É importante observar que 95% do espaço do bloco Ethereum é usado para transferência de valor, medido pelas taxas pagas aos validadores.
principais decisões de design
Os três níveis acima apresentam as principais decisões de design que o CAF precisa tomar. Essas decisões envolvem quem controla a autoridade para executar a intenção, quais informações são divulgadas ao solucionador e quais caminhos de liquidação estão disponíveis para o solucionador. Abaixo está uma análise detalhada de cada nível.
Nível de permissão
A camada de permissão contém a chave privada do usuário e assina mensagens em nome do usuário, que são então executadas como transações na cadeia. O CAF precisa apoiar os esquemas de assinatura e as cargas de transação de todas as cadeias alvo. Por exemplo, as carteiras que suportam o esquema de assinatura ECDSA e o padrão de transação EVM serão limitadas ao Ethereum, às suas cadeias L2 e laterais (como a carteira Metamask). Por outro lado, as carteiras que suportam EVM e SVM (Solana VM) poderão suportar estes dois ecossistemas (como a carteira Phantom). Deve-se notar que a mesma frase mnemônica pode ser usada para gerar carteiras nas cadeias EVM e SVM.
Uma transação multicadeia consiste em múltiplas subtransações que precisam ser executadas na ordem correta. Essas subtransações devem ser executadas em múltiplas cadeias, cada uma com suas próprias taxas e nonces que variam no tempo. A forma como essas subtransações são coordenadas e liquidadas é uma decisão importante de design para a camada de permissões.
A carteira EOA é um software de carteira executado na máquina do usuário e que contém sua chave privada. Eles podem ser extensões baseadas em navegador como Metamask e Phantom, aplicativos móveis como Coinbase Wallet ou hardware especializado como Ledger. As carteiras EOA exigem que os usuários assinem cada subtransação individualmente, o que atualmente requer vários cliques. Eles também exigem que os usuários mantenham saldos de taxas na cadeia-alvo, o que introduz um atrito significativo no processo. No entanto, ao permitir que os usuários assinem múltiplas subtransações com um único clique, o atrito de múltiplos cliques pode ser abstraído do usuário.
Em uma carteira Account Abstraction (AA), os usuários ainda têm acesso às suas chaves privadas, mas separam o signatário da carga útil da transação do executor da transação. Permite que partes complexas agrupem e executem transações de usuários de forma atômica (Avocado, Pimlico). As carteiras AA ainda exigem que os usuários assinem cada subtransação individualmente (atualmente por meio de vários cliques), mas não exigem que um saldo de taxa seja mantido em cada cadeia.
Os agentes baseados em políticas salvam a chave privada do usuário em um ambiente de execução separado e geram mensagens assinadas em nome do usuário com base na política do usuário. Telegram Bot, Near Account Aggregator ou SUAVE TEE são carteiras baseadas em estratégia, enquanto Entropy ou Capsule são extensões de carteira baseadas em estratégia. Os usuários só precisam assinar um formulário de aprovação, e a posterior assinatura de subtransações e gerenciamento de despesas pode ser realizada por esses agentes durante a operação.
camada de solucionador
Depois que o usuário publica a intenção, a camada do solucionador envolve o retorno da taxa e do tempo de confirmação ao usuário. Esta questão está intimamente relacionada ao projeto de leilões de fluxo de pedidos e é discutida em detalhes aqui. O CAF pode aproveitar caminhos intraprotocolo para executar a intenção do usuário ou aproveitar terceiros complexos (ou seja, solucionadores) para comprometer certas garantias de segurança para fornecer aos usuários uma experiência de usuário aprimorada. A introdução do solucionador na estrutura CAF levará às próximas duas decisões de design, que estão intimamente relacionadas às informações.
As intenções consistem em dois tipos de valores extraíveis (EVs): valores EV_ordering e EV_signal.
EV_ordering é um valor específico do blockchain que normalmente é extraído pela entidade que executa os pedidos do usuário (como construtores de blocos ou validadores).
EV_signal representa o valor que está acessível a qualquer entidade que cumpra o pedido antes de ser oficialmente registrado no blockchain.
Diferentes intenções de usuário têm distribuições diferentes entre EV_ordering e EV_signal. Por exemplo, a intenção de trocar moedas em um DEX normalmente tem um valor EV_ordering alto, mas um valor baixo de EV_signal. Por outro lado, o componente EV_signal de uma transação hackeada será maior porque o front-running ganhará mais valor do que a execução da transação. É importante notar que o EV_signal às vezes pode ser negativo, como no caso da negociação do formador de mercado, onde a entidade que executa essas ordens pode sofrer perdas, uma vez que o formador de mercado tem melhor conhecimento das condições futuras do mercado.
Quando alguém consegue observar a intenção de um usuário com antecedência, pode avançar, causando vazamento de valor. Além disso, a possibilidade de um EV_signal negativo cria um ambiente competitivo entre os solucionadores, fazendo com que eles apresentem lances mais baixos, causando ainda mais vazamento de valor (também conhecido como seleção adversa). Em última análise, os vazamentos impactam os usuários, aumentando as taxas ou oferecendo melhores negócios. Observe que taxas baixas ou preços aumentados são duas faces da mesma moeda e serão usadas de forma intercambiável no restante deste artigo.
Compartilhamento de informações
Existem três maneiras de compartilhar informações com o solucionador:
Mempool público: as intenções do usuário são transmitidas publicamente para o mempool público ou camada de disponibilidade de dados, e o primeiro solucionador que puder satisfazer a solicitação executa o pedido e se torna o vencedor. Este sistema é altamente extrativo de informações do usuário porque os usuários expõem seu EV_ordering e EV_signal. Por exemplo, o mempool público do Ethereum e várias pontes blockchain. No caso de uma ponte, os usuários devem colocar os ativos em depósito antes de transferi-los para a cadeia alvo para evitar ataques maliciosos, mas esse processo inadvertidamente torna públicas suas intenções.
Compartilhamento parcial: a CAF pode reduzir o valor divulgado aos licitantes limitando as informações divulgadas. No entanto, esta abordagem levará diretamente à perda da otimização dos preços e poderá levar a problemas como spam de lances.
Mempools privados: Desenvolvimentos recentes em MPC e TEE tornam possíveis mempools totalmente privados. Nenhuma informação é vazada para fora do ambiente de execução e os solucionadores codificam suas preferências e correspondem a cada intenção. Embora o mempool privado capture EV_ordering, ele não pode capturar totalmente EV_signal. Por exemplo, se uma transação hackeada for enviada para o mempool, a primeira pessoa a ver o pedido poderá antecipar a transação e capturar o EV_signal. Em um mempool privado, as informações só são liberadas após a confirmação do bloqueio, para que qualquer pessoa que veja a transação possa capturar o EV_signal. É concebível que o solucionador estabeleça nós de autenticação para capturar EV_signal de blocos de TEE recém-criados, transformando a captura de EV_signal em uma competição atrasada.
Lista de solucionadores
A CAF também precisa decidir quantos e quais licitantes poderão participar do leilão. As principais opções são as seguintes:
Acesso Aberto: A barreira de entrada mais baixa possível para a capacidade de participar. Isso é semelhante a expor o mempool, que vaza EV_signal e EV_ordering.
Acesso restrito: recursos de execução de ordens por meio de listas de permissões, sistemas de reputação, taxas ou leilões de assentos. O mecanismo de disparo é necessário para garantir que o EV_signal não seja capturado pelos solucionadores do sistema. Por exemplo, Leilão de 1 polegada, Leilões Cowswap e Leilão Uniswap X. A competição vencedora de pedidos captura EV_ordering para os usuários, enquanto os mecanismos de controle capturam EV_signal para geradores de pedidos (carteiras, dApps).
Acesso Exclusivo: O Acesso Exclusivo é um formato de leilão especial onde apenas um solucionador é selecionado por período de tempo. Como nenhuma informação é vazada para outros solucionadores, não há seleção adversa e descontos antecipados. O iniciador do fluxo de pedidos captura os valores esperados de EV_signal e EV_ordering e, como não há concorrência, os usuários obtêm apenas execuções, mas não melhorias de preço. Exemplos de tais leilões são os leilões Robinhood e DFlow.
camada de liquidação
Depois que uma carteira assina um conjunto de transações, elas precisam ser executadas no blockchain. As transações entre cadeias transformam o processo de liquidação de uma operação atômica em uma operação assíncrona. Durante a execução e confirmação inicial da transação, o estado na cadeia de destino pode mudar, causando potencialmente a falha da transação. Esta subseção explora as compensações entre custo de segurança, tempo de confirmação e garantias de execução.
É importante notar que a execução da transacção pretendida na cadeia alvo depende do mecanismo de inclusão de transacções da cadeia alvo, incluindo a capacidade de rever transacções e o mecanismo de taxas da cadeia alvo, entre outros factores. Acreditamos que a escolha da cadeia alvo é uma decisão do dApp e está além do escopo deste artigo.
Oráculo de cadeia cruzada
Duas blockchains com diferentes estados e mecanismos de consenso requerem um intermediário, como um oráculo, para facilitar a transferência de informações entre elas. O oráculo atua como um retransmissor para a transferência de informações entre cadeias, incluindo a verificação de que um usuário bloqueou fundos em uma conta de garantia em uma ponte de bloqueio e cunhagem, ou a confirmação do saldo de tokens de um usuário na cadeia original para participar de votações de governança no cadeia alvo.
O oráculo transmite informações na velocidade da cadeia mais lenta. Isso serve para gerenciar o risco de reorganização, pois o oráculo precisa aguardar o consenso da cadeia original. Suponha que um usuário queira fazer a ponte entre o USDC da cadeia original e a cadeia alvo e, para esse fim, o usuário bloqueie seus fundos em depósito. No entanto, podem surgir problemas se o oráculo não esperar por confirmações suficientes e continuar a emitir tokens para o usuário na cadeia de destino. Se ocorrer uma reorganização e os usuários sobrescreverem suas transações de garantia, o oráculo causará um gasto duplo.
Existem dois tipos de oráculos:
Oráculos fora do protocolo: precisam ser separados dos validadores terceirizados que executam o consenso para passar informações entre as cadeias. Validadores adicionais aumentam o custo de funcionamento de um oráculo. LayerZero, Wormhole, ChainLink e Axelar Networks são exemplos de oráculos fora de protocolo.
Oráculos dentro do protocolo: Profundamente integrados ao algoritmo de consenso do ecossistema e comunicam informações usando o conjunto de validadores que executam o consenso. O IBC do Cosmos é usado para cadeias que executam o Cosmos SDK, o ecossistema Polygon está desenvolvendo AggLayer e o Optimism está desenvolvendo Superchain. Cada oráculo usa espaço de bloco dedicado para passar informações entre cadeias no mesmo ecossistema.
Sequenciadores compartilhados são entidades fora do protocolo que possuem direitos de ordenação de transações dentro do protocolo, ou seja, podem agrupar transações entre cadeias. Embora ainda em desenvolvimento, o sequenciador compartilhado não precisa esperar por confirmações de blocos específicos para reduzir o risco de reorganizações. Para realmente alcançar a atomicidade entre cadeias, o sequenciador compartilhado precisa ser capaz de executar transações subsequentes se as transações anteriores forem bem-sucedidas, transformando-as assim em cadeias.
token de ponte
Em um mundo com várias cadeias, os saldos de tokens e taxas de um usuário estão dispersos por todas as redes. Antes de cada operação entre cadeias, os usuários precisam transferir os fundos da cadeia original para a cadeia alvo. Existem atualmente 34 pontes entre cadeias ativas com um TVL total de US$ 7,7 bilhões e um volume de pontes nos últimos 30 dias de US$ 8,6 bilhões.
Os tokens de ponte são um caso de transferência de valor. Isto cria oportunidades para alavancar terceiros profissionais que sejam bons em gestão de capital e dispostos a assumir riscos de reestruturação, reduzindo o custo e o tempo necessários para os utilizadores negociarem.
Existem dois tipos de pontes de cadeia cruzada:
Lock and Mint Bridge: A Lock and Mint Bridge verifica os depósitos de tokens na cadeia original e cunha os tokens na cadeia alvo. O capital necessário para lançar tal ponte é pequeno, mas a transferência segura de informações bloqueadas requer um investimento significativo. As violações de segurança nessas pontes resultaram em perdas de bilhões de dólares para os detentores de tokens.
Liquidity Bridge: Liquidity Bridge utiliza os pools de liquidez na cadeia original e na cadeia alvo e usa algoritmos para determinar a taxa de conversão entre a cadeia original e o token alvo. Embora estas pontes tenham um custo inicial mais elevado, requerem menos garantias de segurança. Se ocorrer uma violação de segurança, apenas os fundos do pool de liquidez estarão em risco.
Em ambas as pontes entre cadeias, os usuários precisam pagar custos de liquidez. Em uma ponte de bloqueio e cunhagem, o custo de liquidez é incorrido ao trocar do token de embalagem para o token desejado (USDC.e para USDC) na cadeia alvo, enquanto em uma ponte de liquidez, o custo de liquidez é incorrido ao trocar do original token para USDC Ocorre quando os tokens da cadeia são trocados por tokens da cadeia alvo.
Trilema de cadeia cruzada
As cinco decisões de design acima levantam o trilema entre cadeias. A CAF deve escolher dois atributos entre garantia de execução, taxas baixas e velocidade de execução.
Caminho intraprotocolo: É o caminho designado para transmissão de informações entre cadeias. Esses sistemas levam em conta o risco de reorganização, sacrificando a velocidade de execução, mas reduzindo custos ao eliminar conjuntos adicionais de validadores ou custos de liquidez.
Agregação de solucionadores: colete cotações de vários solucionadores para identificar o caminho mais barato e rápido para executar a intenção do usuário. No entanto, devido à seleção adversa e ao front-running, às vezes o solucionador pode não conseguir cumprir a intenção, resultando em execução reduzida.
Competição de Execução: Selecione o solucionador vencedor organizando os solucionadores para competir com as intenções de execução ou selecionando um único solucionador. Ambas as abordagens resultam em altas taxas de utilização, uma vez que os solucionadores competem pela execução, em vez de pela melhoria dos preços.
Os seis componentes do BOLO
Para este artigo, estudamos mais de 20 designs de equipes que atuam direta e indiretamente na abstração da cadeia. Nesta seção, discutimos seis implementações independentes de CA que acreditamos terem eficiência inerente e adequação do produto ao mercado. Se construídos corretamente, esses projetos têm potencial para se combinarem entre si.
Uma conclusão importante é que precisamos de um padrão unificado para expressão de intenções entre cadeias. Cada equipe está trabalhando em seus próprios métodos e protocolos para codificar a intenção do usuário. Um padrão unificado melhorará a compreensão dos usuários sobre suas mensagens assinadas, tornará mais fácil para os solucionadores e oráculos entenderem essas intenções e simplificará a integração com carteiras.
Ponte designada por token
Há um caso especial de pontes lock-and-mint que não pagam custos de liquidez, também conhecidas como pontes burn-and-mint (por exemplo, USDC CCTP). A equipe de token atribui um endereço de token canônico em cada cadeia, e a ponte tem autoridade para cunhar os tokens que o usuário precisa.
Se você olhar de perto, verá que a ponte burn and mint é semelhante a uma transferência entre cadeias com velocidade de confirmação de bloco suficiente. xERC 20 é um padrão para especificar tokens canônicos e suas pontes delegadas em uma cadeia de destino. As pontes especificadas por token são um exemplo de caminho intraprotocolo que sacrifica a velocidade para uma execução garantida e taxas baixas, por exemplo, o CCTP leva 20 minutos para concluir uma transferência.
Ponte de Coordenação de Ecossistemas
A Ponte de Coordenação de Ecossistemas pode transmitir mensagens arbitrárias entre cadeias dentro do mesmo ecossistema. Essas pontes são caminhos intraprotocolo que priorizam garantias de execução e taxas baixas em detrimento da velocidade. Os exemplos incluem Cosmos IBC, Polygon AggLayer e Optimism Superchain.
Há três anos, o ecossistema Cosmos enfrentou desafios semelhantes aos enfrentados hoje pelo Ethereum. A liquidez está espalhada por várias cadeias, cada cadeia tem seu próprio token de taxa e o gerenciamento de contas de várias cadeias é muito complicado. O ecossistema Cosmos resolve esses problemas implementando uma ponte de mensagens intraprotocolo IBC, permitindo o gerenciamento contínuo de contas em várias cadeias e transferências entre cadeias.
O ecossistema Cosmos consiste em cadeias independentes com segurança soberana e finalidade rápida, tornando as mensagens entre cadeias dentro do protocolo muito rápidas. O ecossistema de rollup depende do final do período de desafio (rollups otimistas) ou do envio de provas zk (rollups de validade) para atingir a finalidade. Devido a estas restrições de finalidade, a entrega de mensagens em todo o ecossistema será mais lenta.
Concorrência de preços do solucionador
A competição de preços dos solucionadores envolve o compartilhamento de informações do pedido com todos os solucionadores. O solucionador foi projetado para combinar o valor esperado (EV) gerado pela intenção do pedido e fornecê-lo ao usuário. A seleção do Solver vencedor no sistema é baseada na maximização da melhoria do preço do usuário. No entanto, esta concepção acarreta o risco de não execução e requer mecanismos adicionais para garantir a fiabilidade da ordem. Exemplos de tais mecanismos incluem Uniswap X, Bungee e Jumper.
Mensagens de reconciliação da carteira
As mensagens de coordenação de carteira aproveitam os recursos fornecidos por AA ou carteiras baseadas em políticas para fornecer uma experiência entre cadeias compatível com qualquer tipo de intenção. Ele atua como o agregador definitivo de CA, redirecionando a intenção do usuário entre vários designs de CA para atender a intenções específicas. Os exemplos incluem Avocado Wallet, Near Account Aggregator e Metamask Portfolio.
É importante observar que, na última década, o ecossistema criptográfico aprendeu que a relação entre os usuários e suas carteiras é muito rígida. Sempre que penso em migrar minha frase mnemônica do Metamask para outra carteira, fico extremamente apavorado. Esta é também a razão pela qual o EIP-4337 ainda apresenta uma baixa taxa de adoção após 2,5 anos, mesmo com o apoio do próprio Vitalik Buterin. Embora as versões mais recentes do protocolo de carteira possam oferecer aos usuários melhores preços (abstração de contas) ou maior facilidade de uso (carteiras baseadas em políticas), migrar usuários de suas carteiras atuais é uma tarefa difícil.
Competição de velocidade do solucionador
A competição pela velocidade do solucionador permite que os usuários expressem intenções para transformações específicas entre cadeias para obter altas garantias de execução. Não ajuda os usuários a minimizar as taxas, mas fornece um canal confiável para conter transações complexas. O primeiro Solver a executar uma intenção com base nas taxas do construtor de blocos ou na velocidade de inclusão vencerá essa intenção.
O projeto visa atingir altas taxas de inclusão maximizando o EV capturado pelo Solver. No entanto, isso tem o custo da centralização, pois depende de gerenciamento complexo de capital na rede principal Ethereum ou de execução de baixa latência em L2.
Leilão em massa exclusivo
Um leilão em lote exclusivo realiza um leilão pelo direito exclusivo de executar todo o fluxo de pedidos dentro de uma janela de tempo. Como outros solucionadores não podem ver as ordens, eles fazem lances com base na volatilidade prevista do mercado e na qualidade média de execução. Os leilões de lotes exclusivos dependem de um preço alternativo para garantir bons preços ao usuário e, portanto, não podem ser usados para melhorias de preços. Enviar todo o fluxo de pedidos para um único licitante elimina o vazamento de informações e melhora a garantia de execução.
para concluir
O Chain Abstraction Framework (CAF) promete fornecer aos usuários interações contínuas entre cadeias. Neste artigo, examinamos projetos em produção e desenvolvimento por diversas equipes que estão tentando, explícita ou implicitamente, resolver o problema de abstração em cadeia. Acreditamos que este será o ano da CAF e esperamos que ocorra uma competição significativa entre diferentes projetos e suas implementações nos próximos 6 a 12 meses.
As transferências de valor entre cadeias serão possibilitadas por pontes delegadas por token para taxas baixas e execução rápida por meio da velocidade do solucionador ou de competições de preços. As transferências de mensagens são roteadas por meio de pontes de mensagens que correspondem ao ecossistema, projetadas para minimizar os custos do usuário e maximizar a velocidade por meio de uma plataforma controlada por carteira. Em última análise, estas seis opções de design diferentes formarão um cluster porque cada uma delas satisfaz necessidades diferentes e tira partido de eficiências em diferentes áreas da matriz de compromissos.
Uma conclusão importante que obtivemos deste processo é que precisamos de um padrão comum para expressar intenções entre cadeias. Atualmente, diversas equipes estão trabalhando de forma independente em protocolos para codificar a intenção do usuário, resultando na duplicação de esforços. Um padrão unificado ajudará a melhorar a compreensão do usuário sobre mensagens assinadas, facilitará que solucionadores e oráculos processem intenções e simplificarão a integração com carteiras.
Link original