TL; Dr

• A UX cripto padrão hoje é 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. Trazer essa abordagem para blockchains é o que chamamos de Chain Abstraction.
• Este artigo apresenta a estrutura CAKE, ou seja, elementos-chave de abstração de cadeia. Ele é composto por quatro camadas: Aplicativos, Permissões, Solução e Povoado, que coletivamente facilitam as operações de cadeia cruzada contínuas para os usuários.
• Alcançar a abstração da cadeia requer o uso de um conjunto complexo de tecnologias para fornecer execução confiável, econômica, segura, rápida e privada.
• Definimos o espaço cadeia cruzada tradeoff na abstração de cadeias como um trilema e propomos seis projetos, cada um oferecendo vantagens únicas.
• A ordem de dar o salto com sucesso para um futuro de abstração em cadeia, é imperativo que nós, como indústria, definamos e adotemos um padrão comum para mensagens entre as camadas do CAKE. Um grande padrão é a cereja do bolo. 🎂

Introdução

Em 2020, a rede Ethereum fez a transição para um roteiro centrado em rollup para escala. Quatro anos depois dessa decisão, mais de 50 acúmulos (L2s) já estão em produção. Embora acúmulos forneça o dimensionamento horizontal muito necessário para o espaço de bloco EVM, ele arruinou totalmente a experiência do usuário.

Os usuários não devem se importar, nem saber, com qual rollup estão interagindo. Cripto usuários sabendo com qual rollup (Optimism ou Base) eles estão interagindo é equivalente a usuários web2 sabendo com qual provedor de nuvem (AWS ou GCP) eles estão interagindo. Chain Abstraction é uma visão onde a informação em cadeia é abstraída longe do usuário. O usuário apenas conecta sua carteira a um dApp e assina para a operação pretendida, os detalhes de certificar-se de que o usuário tem saldo correto na cadeia de destino e, em seguida, executar a operação pretendida acontece nos bastidores.

Ao longo deste artigo, observaremos que a Abstração em Cadeia é um problema verdadeiramente multidisciplinar. Envolvendo interações com o Camada de aplicação, Permission Layer, Solver Layer e Povoado Layer. Introduzimos a estrutura Chain Abstraction Key Elements (CAKE 🎂) e, em seguida, nos aprofundamos nos trade-offs de design de sistemas de abstração de cadeia.

Apresentando o CAKE Framework

Em um mundo abstrato em cadeia, um usuário vai a um site dApps, conecta sua carteira, assina a operação pretendida e aguarda uma eventual liquidação. Toda a complexidade de adquirir os ativos necessários para a cadeia de destino e a liquidação final é abstraída do usuário, acontecendo em camadas de infraestrutura do CAKE. Há três camadas de infraestrutura do CAKE:

1. Camada de permissão: O usuário conecta sua carteira a um dApp e solicita a cotação para uma intenção do usuário. Uma intenção é o que o usuário espera (ou seja, saída) no final de uma transação e não o caminho final que a transação toma. Pode ser transferindo USDT para um endereço Tron ou depositando USDC em uma estratégia de geração de rendimento no Arbitrum. A carteira deve ser capaz de conhecer os ativos dos usuários (ou seja, estado de leitura) e executar transações (ou seja, estado de atualização) em cadeias de destino.
2. Camada do Solver: A camada do solucionador estima as taxas e a velocidade de execução com base no saldo inicial e na intenção do usuário. Esse processo, conhecido como solução, é crucial em uma configuração de cadeia cruzada em que as transações se tornam assíncronas e as subtransações podem falhar durante a execução. A introdução da assincronicidade cria um cadeia cruzada trilema envolvendo taxas, velocidade de execução e garantia de execução.
3. Povoado camada: Depois que o usuário aprova a transação com sua chave privada, o camada de liquidação garante sua execução. Envolve duas etapas: fazer a ponte dos ativos do usuário para a cadeia de destino e, em seguida, executar a transação. Se o protocolo usa solvers sofisticados para determinadas operações, ele pode trazer sua própria liquidez e executar a operação em nome do usuário sem a necessidade de ponte.

Alcançar a abstração da cadeia significa combinar as três camadas de infraestrutura acima em um produto unificado. Um insight importante ao combinar essas camadas é a diferença entre transferir informações versus transferir valor. A transferência de informações entre cadeias deve ser sem perdas e, portanto, precisa depender dos caminhos mais seguros. Suponha que um usuário esteja tentando votar Sim em uma votação de governança de uma cadeia para outra, ele não quer que seu voto se converta em um Talvez. Por outro lado, a transferência de valor pode ser deficitária com base na preferência dos usuários. Um terceiro sofisticado pode ser aproveitado para dar ao usuário uma transferência de valor mais rápida, barata ou garantida. Note, 95% do espaço de bloco ethereum (ponderado por taxas pagas a validadores) é consumido para transferir valor.

Key Design Decisions

As três camadas acima introduzem decisões-chave de design que precisam ser tomadas por um CAF. Eles estão relacionados a quem controla o poder sobre a execução da intenção, quais informações devem ser reveladas aos solucionadores e quais são os caminhos de liquidação disponíveis para os solucionadores. Vejamos cada um deles em detalhes.

Permission Layer

A camada de permissão mantém a chave privada para o usuário e assina mensagens em seu nome, que são executadas na rede como transações. Um CAF precisa apoiar esquemas de assinatura e cargas úteis de transação para todas as cadeias de destino que deseja apoiar. Por exemplo, uma carteira que suporta o esquema de assinatura ECDSA e EVM padrão de transação será limitada a Ethereum, seus L2s e suas cadeias laterais (por exemplo, carteira Metamask). Por outro lado, uma carteira que suporte EVM e SVM (Solana VM) será capaz de apoiar ambos os ecossistemas (por exemplo, carteira Phantom). É importante notar que o mesmo mnemônico pode ser usado para gerar carteiras em cadeias EVM e SVM.

Uma única transação multi-cadeia consiste em várias subtransações que precisam ser executadas da ordem correta. Essas subtransações devem ser executadas em várias cadeias, cada uma com suas próprias taxas e nonce que variam no tempo. Como ocorre a coordenação e a liquidação dessas subtransações é uma decisão de projeto crucial para a camada de permissão.

1. As carteiras EOA são softwares de carteira que são executados nas máquinas dos usuários e mantêm suas chaves privadas. Eles podem ser extensões baseadas em navegador (como Metamask e Phantom), aplicativos móveis (como Coinbase Carteira) ou hardware dedicado (como Ledger). As carteiras EOA exigem que o usuário assine individualmente cada subtransação, o que atualmente requer vários cliques. Eles também exigem que o usuário mantenha saldos de taxas na cadeia de destino, o que introduz um atrito significativo no processo. No entanto, o atrito de vários cliques pode ser abstraído do usuário, permitindo que ele assine várias subtransações com um único clique.
2. Nas carteiras de Abstração de Conta (AA), o usuário ainda tem acesso à sua chave privada, mas eles separam o signatário da carga útil da transação com o executor da transação. Permitindo que partes sofisticadas agrupem e executem atomicamente transações de usuários (Avocado, Pimlico). As carteiras AA ainda exigem que o usuário assine individualmente cada subtransação (atualmente por meio de vários cliques), mas não exigem a manutenção de saldos de taxas em cada cadeia.
3. Os agentes baseados em políticas mantêm a chave privada do usuário em um ambiente de execução separado e geram mensagens assinadas em seu nome com base nas políticas do usuário. Bots do Telegram, agregador de contas próximas ou TEEs SUAVE são carteiras baseadas em políticas, enquanto Entropia ou Capsule são extensões de carteira baseadas em políticas. O usuário só precisa assinar uma única aprovação e posterior assinatura de subtransações e gerenciamento de taxas pode ser realizado a bordo por esses agentes.

Camada Solver Uma

vez que um usuário posta sua intenção, a camada de resolução envolve o retorno de uma taxa e tempo de confirmação para o usuário. Esse problema está intimamente relacionado ao projeto de um Leilão de Fluxo de Pedidos e foi escrito em detalhes aqui. Um CAF pode aproveitar caminhos protocolo para executar uma intenção de usuário ou aproveitar terceiros sofisticados, também conhecidos como solvers, para fornecer UX aprimorada ao usuário, comprometendo algumas garantias de segurança. As duas próximas decisões de design surgem quando trazemos solvers para uma estrutura CAF, e estão relacionadas à informação.

Uma intenção consiste em dois tipos de valores extraíveis (EV): EV_ordering e EV_signal. EV_ordering é um valor específico do blockchain, normalmente extraído por entidades que executam ordens de usuário, como construtores de blocos ou validadores. Por outro lado, EV_signal representa o valor acessível a qualquer entidade que observe o ordem antes que ele seja oficialmente registrado no blockchain.

Diferentes intenções de usuário têm distribuições variadas entre EV_ordering e EV_signal. Por exemplo, uma intenção de trocar moedas em um DEX geralmente tem EV_ordering alto, mas EV_signal baixo. Por outro lado, uma transação de hack recebida terá um componente maior de EV_signal já que a execução frontal retornará significativamente mais valor do que executá-la. É importante notar que EV_signal às vezes pode ser negativa, como no caso de negociações de Criadores de Mercado, onde as entidades que executam essas ordens podem experimentar perdas devido a uma melhor compreensão dos criadores de mercado das condições futuras do mercado.

Quando alguém tem a capacidade de observar a intenção de um usuário com antecedência, ele pode se envolver em front-running, o que leva ao vazamento de valor. Além disso, o potencial de EV_signal ser negativo cria um ambiente competitivo entre os solucionadores, fazendo com que eles apresentem lances mais baixos e resultando em maior vazamento de valor (também conhecido como seleção adversa). Em última análise, o vazamento impacta o usuário, aumentando as taxas ou fornecendo preços menos favoráveis. Note, taxas baixas ou melhoria de preço são dois lados do mesmo moeda e serão usados de forma intercambiável durante o restante do artigo.

Compartilhamento de informações

Existem 3 métodos para compartilhar informações com solucionadores:

1. pool de membros pública: a intenção do usuário é transmitida publicamente, seja em uma pool de membros pública ou em uma camada DA. O primeiro solucionador que pode atender ao pedido executa o ordem e se torna o vencedor. Esse sistema é altamente extrativista, pois os usuários revelam tanto a EV_ordering quanto a EV_signal de seus ordem. Exemplos desse tipo de leilão incluem o pool de membros público da Ethereum e várias pontes de blockchain. No caso das pontes, os usuários devem colocar seus ativos em depósito antes de transferi-los para a cadeia alvo como precaução contra ataques de luto. No entanto, esse processo expõe, sem querer, suas intenções publicamente.
2. Compartilhamento parcial: Um CAF pode optar por limitar a quantidade de valor que revela aos licitantes, limitando as informações divulgadas. No entanto, essa abordagem resulta em uma perda direta da otimização de preço e pode levar a outros problemas, como spam de lances.
3. Private pool de membros: Desenvolvimentos recentes em MPC e TEEs abrem a possibilidade de alcançar mempools completamente privados. Nenhuma informação é vazada fora do Ambiente de Execução para que os solucionadores codificem suas preferências, que são combinadas com todas as intenções. Embora o pool de membros privado capture EV_ordering, ele não pode capturar totalmente o valor em EV_signal. Imagine o que acontecerá se uma transação de hack for enviada para o pool de membros. A primeira pessoa a ver essa ordem pode antecipar a potencial venda e captá EV_signal. Em um pool de membros privado, as informações são liberadas somente depois que um bloqueio é confirmado e, portanto, quem pode ver a transação pode capturar o EV_signal. Pode-se imaginar solvers girando atestado nós para capturar EV_signal de blocos frescos cunhados por um TEE, transformando EV_signal captura em uma corrida latência.

Solver List

A CAF também precisa decidir quantos e quais licitantes podem participar do leilão. Em linhas gerais, as opções são as seguintes:

• Acesso aberto: As barreiras à entrada para a capacidade de participar são as mais baixas possíveis. Isso é semelhante a uma pool de membros pública e vaza tanto EV_signal quanto EV_ordering.
• Acesso fechado: há algum gatekeeping na capacidade de executar um ordem, seja por meio de uma lista branca, um sistema de reputação, uma taxa ou um leilão de assentos. O mecanismo de gatekeeping precisa garantir que os solucionadores no sistema não capturem EV_signal. Exemplos são 1inch Auction, Cowswap Auctions e Uniswap X leilões. A competição para ganhar ordens captura EV_ordering para o usuário, enquanto o mecanismo de fechamento pode capturar o EV_signal para o gerador de ordem (Carteira, dApps).
• Acesso exclusivo: O acesso exclusivo é um caso especial do leilão de solver sentado, onde apenas um solver é selecionado a cada período de tempo. Uma vez que nenhuma informação é vazada para outros solucionadores, não há seleção adversa e desconto de execução. O originador de fluxo de pedidos captura o valor esperado de EV_signal e EV_ordering, uma vez que não há concorrência, o usuário só pode obter execução e nenhuma melhoria de preço. Alguns exemplos desses leilões são os leilões Robinhood e DFlow.

Povoado Camada

Uma vez que uma carteira assina um conjunto de transações, elas precisam ser executadas no blockchain. As transações entre cadeias convertem o processo de liquidação de atômico para assíncrono. Enquanto as transações iniciais estão sendo executadas e confirmadas, o estado na cadeia de destino pode mudar, potencialmente principal à falha da transação. Esta subseção estudará os trade-offs entre o custo da segurança, o tempo de confirmação e a garantia de execução.

É importante observar que a execução da transação pretendida na cadeia de destino depende da mecânica de inclusão de transações da cadeia de destino. Incluindo a capacidade de censurar uma transação e o mecanismo de taxas da cadeia alvo, entre outros fatores. Acreditamos que a escolha da cadeia alvo é uma decisão para o dApp e vamos considerá-la além do escopo deste artigo.

Cross-Chain Oracle

Duas blockchains com estados distintos e mecanismos de consenso requerem um intermediário, como um Oracle, para facilitar a transferência de informações entre elas. Oráculos servem como retransmissores de informações entre cadeias. Isso inclui verificar situações como um usuário bloqueando fundos em um conta de garantia para um bloqueio e como ponte, ou confirmar o saldo de token de um usuário na cadeia de origem para participação na votação de governança na cadeia de destino.

Os oráculos transferem informações entre cadeias na velocidade da cadeia mais lenta. Isso é necessário para gerenciar o risco de reorganização, pois o Oracle precisa aguardar o consenso sobre a cadeia de origem. Vamos considerar um cenário em que um usuário deseja ponte USDC da cadeia de origem para a cadeia de destino. Para fazer isso, o usuário bloqueia seus fundos em uma garantia. No entanto, se o Oracle não aguardar confirmações suficientes e continuar a como tokens para o usuário na cadeia de destino, um problema pode ocorrer. No caso de uma reorganização, se o usuário sobrescrever sua transação de caução, o Oracle terá gasto em dobro.

Existem dois tipos de oráculos:

1. O Oracle fora do protocolo requer validadores de terceiros separados daqueles que executam o consenso para transferir informações entre cadeias. A necessidade de validadores extra aumenta o custo de execução do Oracle. LayerZero, Wormhole, ChainLink e rede Axelar são exemplos de Oráculos Fora do Protocolo.
2. Um Oracle In-Protocol é profundamente integrado ao algoritmo de consenso de um ecossistema e usa o conjunto de validadores que executa o consenso para transferir informações. O Cosmos tem IBC para cadeias que executam o SDK do Cosmos, o ecossistema Polygon está trabalhando no AggLayer, enquanto o Optimism está trabalhando no Superchain. Cada oráculo usa espaço de bloco dedicado para transferir informações entre cadeias do mesmo ecossistema.
3. Os sequenciadores compartilhados são entidades fora da protocolo que têm direitos de ordenação de transações no protocolo, ou seja, podem fornecer agregação de transações entre cadeias. Embora ainda em desenvolvimento, os sequenciadores compartilhados não precisam esperar por certas confirmações de bloco para reduzir o risco de reorganização. Para realmente fornecer cadeia cruzada atomicidade, os sequenciadores compartilhados precisam ser capazes de executar transações subsequentes condicionadas ao sucesso de transações anteriores, transformando-as em uma cadeia de cadeias.

Bridging Tokens

Em um mundo de várias cadeias, os saldos de token de usuário e taxas estão espalhados por todas as redes. Antes de cada operação cadeia cruzada, o usuário precisa ponte fundos da cadeia de origem para a cadeia de destino. Atualmente, existem 34 pontes ativas com um televisão combinado de US$ 7,7 bilhões e pontes volume de US$ 8,6 bilhões nos últimos 30 dias.

Bridging tokens é um caso de transferência de valor. Isso cria uma oportunidade de utilizar terceiros especializados que se destacam na gestão de capital e estão dispostos a assumir o risco de reorganização, reduzindo o custo e o tempo necessários para as transações do usuário.

Existem 2 tipos de pontes:

1. Lock and Mint ponte: Um bloqueio e como ponte verifica depósitos de tokens na cadeia de origem e cunha tokens na cadeia de destino. Embora seja necessário um pequeno capital para iniciar esse ponte, é necessário um investimento significativo para a transferência segura de informações de bloqueio entre cadeias. Falhas de segurança nessas pontes resultaram em perda de bilhões de dólares para os detentores de tokens.
2. Liquidez pontes: Liquidez pontes utilizam pools de liquidez nas cadeias de origem e destino, juntamente com um algoritmo para determinar as taxas de conversão entre os tokens de origem e de destino. Embora essas pontes tenham custos iniciais mais altos, elas exigem garantias de segurança mais baixas. Em caso de violação de títulos, apenas os fundos dos pools de liquidez estão em risco.

Em ambos os tipos de pontes há um custo de liquidez que precisa ser pago pelo usuário. Nas pontes Lock e Mint o custo de liquidez é ao trocar do token embrulhado para o token desejado (USDC.e para USDC) na cadeia de destino, enquanto em Liquidez Bridges o custo de liquidez é ao trocar do token na cadeia de origem para o token na cadeia de destino.

Trilema de cadeia cruzada

As 5 decisões de projeto acima dão Elevar ao trilema cadeia cruzada. Um CAF tem que escolher 2 propriedades entre Garantia de Execução, Taxas Baixas e Velocidade de Execução.

1. Os caminhos protocolo são designados caminhos para transferir informações entre cadeias. Esses sistemas conta para reorganização, correm o risco de sacrificar a velocidade de execução, mas reduzem os custos, eliminando a necessidade de um conjunto de validadores adicional ou os custos de liquidez.
2. A agregação do Solver coleta cotações de vários solucionadores para identificar o caminho mais barato e rápido para atender à intenção de um usuário. No entanto, devido à seleção adversa e ao front-running, os solvers às vezes podem não satisfazer a intenção, resultando em execução reduzida.
3. A competição de execução seleciona um solucionador vencedor organizando uma corrida entre solvers para executar uma intenção ou escolhendo um único solucionador exclusivamente. Ambas as abordagens levam a altas taxas para o usuário, já que os solucionadores competem pela execução em vez da melhoria do preço.

Os Seis Pedaços de CAKE

Para escrever este artigo, estudamos mais de 20 designs diferentes de equipes que trabalham explícita e implicitamente na Abstração em Cadeia. Nesta seção, discutimos seis implementações de CA independentes que acreditamos terem eficiências inerentes e adequação ao mercado de produtos. Esses projetos têm o potencial de compor uns com os outros se construídos corretamente.

Uma conclusão fundamental deste exercício é que precisamos de um padrão comum para expressar cadeia cruzada intenções. Cada uma das equipes está trabalhando em seus próprios métodos e protocolos para codificar as intenções do usuário. Unificar em direção a um padrão melhorará a compreensão do usuário da mensagem que está assinando, tornará mais fácil para solvers e oráculos entenderem essas intenções e simplificará a integração com carteiras.

Token Pontes Ungidas

Ecossistema alinhado ponte

Concorrência de preços do Solver

Carteira mensagens controladas

Competição de velocidade do Solver

Leilões de lotes exclusivos

propósito

Transferências cross-chain baratas

Chamada de mensagem entre cadeias

Swaps cross-chain baratos

Chamada de mensagem entre cadeias

Transferências rápidas entre cadeias

Chamada de mensagem entre cadeias

Exemplos

CCTP, CCIP, xERC20

AggLayer, Supercadeia, IBC

Bungee, Jumper, Uniswap X

Alfred, Abacate, Conta Próxima

Across, Orbitador

NA

carteira

qualquer

qualquer

Depende da implementação

AA ou baseado em políticas

qualquer

qualquer

Informações compartilhadas

público

público

Depende da implementação

Depende da implementação

Todos ou Nenhum

nenhum

Solver lista

Depende da implementação

Depende da implementação

Acesso fechado

Depende da implementação

Depende da implementação

exclusivo

oráculo

No protocolo

No protocolo

Fora de protocolo

Fora de protocolo

Fora de protocolo

Fora de protocolo

Token Ponte

Queimar e como

Bloqueio e como

Depende do solucionador

Depende do solucionador

Liquidez ponte

Depende da implementação

Token Pontes Ungidas:

Há um caso especial de bloqueio e como ponte que não paga o custo de liquidez, também chamado de queima e como ponte (por exemplo. USDC CCTP). A equipe de token unge um endereço de token canônico em cada cadeia, enquanto o ponte tem autoridade para como o token, ou seja, o token que o usuário precisa.

Se você apertar os olhos o suficiente, uma queimadura e como ponte é semelhante a uma transferência de cadeia cruzada na velocidade de confirmações de bloco suficientes. xERC20 é um desses padrões para ungir tokens canônicos e suas pontes autorizadas em cadeias de destino. Um token ungido ponte é um exemplo de um caminho protocolo, ou seja, compromete a velocidade para garantia de execução e taxas baixas, por exemplo, o CCTP leva 20 minutos para executar uma transferência.

Ecosystem Aligned Bridge

Uma ponte alinhada ao ecossistema permite a transferência de mensagens arbitrárias entre cadeias dentro do mesmo ecossistema. Ele se enquadra na categoria de caminhos em protocolo, priorizando garantia de execução e taxas baixas em detrimento da velocidade. Exemplos incluem Cosmos IBC, Polygon AggLayer e Optimism Superchain.

Há três anos, o ecossistema do Cosmos enfrentou desafios semelhantes aos que o Ethereum enfrenta hoje. Liquidez era fragmentado em cadeias, cada cadeia tinha seu próprio token de taxa e gerenciar contas de várias cadeias era complicado. O ecossistema Cosmos abordou essas questões implementando pontes de transmissão de mensagens no protocolo através do IBC, resultando em contas multi-chain perfeitas e transferências de cadeia cruzada.

O ecossistema do cosmos é composto por cadeias independentes com segurança soberana e finalidade rápida, tornando o caminho protocolo para cadeia cruzada mensagens muito rápido. Por outro lado, o ecossistema de rollup depende da expiração do período de desafio (Optimistic Rollups) ou da confirmação de zk-proofs (Validity Rollups) para finalidade. Os caminhos protocolo para a transmissão de mensagens através dos ecossistemas serão lentos devido a essas restrições de finalidade.

Solver Price Competition

Uma competição de preços do Solver envolve o compartilhamento de informações ordem com todos os solucionadores. Os solvers visam incorporar o valor esperado (VE) gerado pela intenção do ordem e fornecê-lo aos usuários. A seleção do solucionador vencedor no sistema é baseada na maximização da melhoria do preço do usuário. No entanto, esse projeto traz o risco de não execução e requer mecanismos adicionais para garantir a inclusão confiável de ordens. Exemplos de tais mecanismos incluem Uniswap X, Bungee e Jumper.

Carteira Mensagens coordenadas

Carteira mensagens coordenadas utilizam recursos fornecidos por carteiras AA ou baseadas em políticas para oferecer uma experiência cadeia cruzada compatível com qualquer tipo de intenção. Ele serve como o agregador de CA definitivo, redirecionando as intenções do usuário entre vários designs de CA para abordar intenções específicas. Exemplos incluem Avocado wallet, Near Account Aggregator e Metamask Portfolio.

Observe que, na última década, o ecossistema cripto aprendeu que a relação entre um usuário e sua carteira é muito pegajosa. Eu pessoalmente sinto um pavor mortal sempre que penso em migrar meu mnemônico de Metamask para outra carteira. Esta é também a razão pela qual mesmo depois de 2,5 anos e apoio do próprio Vitalik Buterin PEI-4337 ganhou adoção mínima. Embora as versões mais recentes dos protocolos de carteira possam fornecer ao usuário melhor preço (abstração de conta) ou maior facilidade de uso (carteiras baseadas em políticas), migrar o usuário de suas carteiras atuais é uma tarefa difícil.

Solver Speed Competition

A competição de velocidade Solver permite que os usuários expressem suas intenções para transições de cadeia cruzada específicas para garantias de alta execução. Ele não ajuda os usuários a minimizar as taxas, mas oferece um canal confiável para incluir transações complexas. O primeiro solucionador a executar a intenção com base em taxas de construtor de blocos ou velocidade de inclusão vence a intenção.

O projeto visa alcançar uma alta taxa de inclusão, maximizando o EV capturado por solvers. No entanto, ele tem o custo da centralização, pois depende de gerenciamento de capital sofisticado na mainnet Ethereum ou execução de baixo latência em L2s.

Leilões de lotes exclusivos

Um leilão de lote exclusivo realiza um leilão para os direitos exclusivos para executar todo o fluxo de ordem em uma janela de tempo para um único solver. Como outros solucionadores não podem ver as ordens, eles colocam o lance com base na volatilidade prevista do mercado e em sua qualidade média de execução. Os leilões de lotes exclusivos dependem de um preço contra-recuo em ordem para garantir bons preços ao usuário e, portanto, não podem ser usados para melhoria de preço. O envio de todo o fluxo de ordem para um único licitante elimina o vazamento de informações e melhora as garantias de execução.

Conclusion

Chain Abstraction Frameworks (CAFs) prometem oferecer aos usuários cadeia cruzada interação perfeita. Neste artigo, estudamos projetos em produção e em desenvolvimento por várias equipes que estão explícita ou implicitamente tentando resolver para Chain Abstraction. Acreditamos que este será o ano dos CAFs e esperamos que uma competição significativa aconteça entre diferentes projetos e suas implementações nos próximos 6 a 12 meses.

Transferência de Valor

Transferência de Informações

Caminhos protocolo

ponte Token-ungidos

Ecossistema alinhado ponte

Agregação do Solver

Concorrência de preços do Solver

Carteira mensagens coordenadas

Concurso de execução

Competição de velocidade do Solver

Leilões de lotes exclusivos

As transferências de valor entre cadeias serão encaminhadas por meio de uma combinação de pontes ungidas por tokens para taxas baixas e Solver Speed ou Price Competitions para velocidade e execução. Enquanto as transferências de informações serão encaminhadas por meio de uma combinação de pontes de mensagens alinhadas ao ecossistema, que terão como objetivo minimizar o custo para os usuários, e para plataformas controladas por carteiras que maximizarão a velocidade. As implementações finais se agruparão em torno desses seis projetos distintos, pois cada um deles atende a necessidades independentes e se beneficia das eficiências existentes em diferentes cantos da matriz de compensação.

Uma conclusão fundamental deste exercício é que precisamos de um padrão comum para expressar cadeia cruzada intenções. Várias equipes estão trabalhando em seus protocolos individuais para codificar as intenções do usuário que causam trabalho duplicado. A unificação em direção a um padrão melhorará a compreensão do usuário sobre a mensagem que está assinando, facilitará o trabalho de solucionadores e oráculos com intenções e simplificará a integração com carteiras.

Isenção de responsabilidade:

1. Este artigo foi reproduzido de [Medium]. Todos os direitos autorais pertencem ao autor original [Favorite Mirror Reads Archive]. Se houver objeções a esta reimpressão, entre em contato com a equipe Gate Learn, e eles lidarão com isso prontamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.