TL;

DR
• A UX cripto padrão hoje é para que os usuários sempre saibam com qual rede estão interagindo. No entanto, os utilizadores da Internet não têm de saber com que fornecedor de serviços em nuvem estão a interagir. Trazer essa abordagem para blockchains é o que chamamos de Chain Abstraction.
• Este artigo apresenta a estrutura CAKE, ou seja, elementos-chave de abstração em cadeia. Ele é composto por quatro camadas: Aplicativos, Permissões, Resolução e Liquidação, que coletivamente facilitam operações de cadeia cruzada contínuas para os usuários.
• Alcançar a abstração em 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 cadeia cruzada espaço de compensação na abstração em cadeia como um trilema e propomos seis projetos, cada um oferecendo vantagens únicas.
• Em ordem de dar com sucesso o salto para um futuro de abstração em cadeia, é imperativo que, como indústria, definamos e adotemos um padrão comum para mensagens entre as camadas do CAKE. Um ótimo padrão é a cereja do bolo. 🎂

Introdução

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

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

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

Apresentando o CAKE Framework

Em um mundo abstrato em cadeia, um usuário acessa 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. Existem 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 eventual que a transação toma. Pode ser transferir USDT para um endereço Tron ou depositar 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) nas cadeias de destino.
2. Camada Solver: A camada Solver estima as taxas e a velocidade de execução com base no saldo e intenção iniciais do usuário. Esse processo, conhecido como resolução, é crucial em um cenário 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 trilema cadeia cruzada envolvendo taxas, velocidade de execução e garantia de execução.
3. Liquidação 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 entre os ativos do usuário na cadeia de destino e, em seguida, executar a transação. Se o protocolo usa solvers sofisticados para determinadas operações, eles podem 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 em 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, por conseguinte, depende das vias mais seguras. Suponhamos que um usuário está 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 perdida 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 blockspace ethereum (ponderado pelas taxas pagas a validadores) é consumido para transferir valor.

Key Design Decisions

As três camadas acima introduzem as principais decisões 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. Vamos analisar cada um deles em detalhes.

Camada de permissão

A camada de permissão contém a chave privada para o usuário e assina mensagens em seu nome, que são executadas na cadeia como transações. Um CAF precisa suporte esquemas de assinatura e cargas úteis de transação para todas as cadeias de destino que deseja suporte. Por exemplo, uma carteira que suporte o esquema de assinatura de ECDSA e o padrão de transação EVM 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 suporte 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 multicadeia consiste em várias subtransações que precisam ser executadas na ordem correta. Essas subtransações devem ser executadas em várias cadeias, cada uma com suas próprias taxas e nonce variáveis no tempo. A forma como ocorre a coordenação e liquidação destas subtransações é uma decisão de conceção crucial para a camada de permissão.

1. As carteiras EOA são softwares de carteira que são executados nas máquinas dos utilizadores e guardam as 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 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 Account Abstraction (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 as transações dos usuários (Abacate, 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. Os bots do Telegram, o agregador Near Account ou os TEEs SUAVE são carteiras baseadas em políticas, enquanto o Entropy ou o Capsule são extensões de carteira baseadas em políticas. O usuário só precisa assinar uma única aprovação e a assinatura subsequente de subtransações e gerenciamento de taxas pode ser realizada durante o voo por esses agentes.

Solver Layer

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. Este problema está intimamente relacionado com a conceção de um Leilão de Fluxo de Ordens e foi escrito em detalhe aqui. Um CAF pode aproveitar caminhos no protocolo para executar uma intenção do usuário ou alavancar terceiros sofisticados, também conhecidos como solvers, para fornecer UX aprimorada ao usuário, comprometendo algumas garantias de segurança. As próximas duas decisões de design surgem quando trazemos os solucionadores 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 para o 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 de ser oficialmente registrado no blockchain.

Diferentes intenções do 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 de EV_signal mais alto, uma vez que a execução frontal retornará significativamente mais valor do que executá-la. É importante notar que EV_signal às vezes pode ser negativo, 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 negativa cria um ambiente competitivo entre os solucionadores, fazendo com que eles apresentem propostas mais baixas e resultando em mais vazamento de valor (também conhecido como seleção adversa). Em última análise, as fugas afetam o utilizador, aumentando as taxas ou proporcionando preços menos favoráveis. Observe que taxas baixas ou melhoria de preço são dois lados do mesmo moeda e serão usados indistintamente durante o restante do artigo.

Compartilhamento de informações

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

1. pool de mem pública: a intenção do usuário é transmitida publicamente, seja em uma pool de mem pública ou em uma camada DA. O primeiro solucionador que conseguir atender a solicitação executa o ordem e se torna o vencedor. Este sistema é altamente extrativo, pois os usuários revelam tanto o EV_ordering quanto o EV_signal de seus ordem. Exemplos deste tipo de leilão incluem o pool de mem público da Ethereum e várias pontes blockchain. No caso de pontes, os usuários devem colocar seus ativos em depósito antes de transferi-los para a cadeia de destino como precaução contra ataques de luto. No entanto, este processo expõe involuntariamente as suas intenções publicamente.
2. Partilha 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ços e pode levar a outros problemas, como spam de lances.
3. pool de mem privadas: Os 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 correspondidas a todas as intenções. Embora o pool de mem privado capture EV_ordering, ele não pode capturar totalmente o valor em EV_signal. Imagine o que acontecerá se uma transação hacker for enviada para o pool de mem. A primeira pessoa a ver este ordem pode antecipar a potencial venda e captar EV_signal. Em um pool de mem privado a informação só é divulgada após a confirmação de um bloqueio e, portanto, quem pode ver a transação pode capturar o EV_signal. Pode-se imaginar solvers girando atestação nós para pegar 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 termos gerais, as opções são as seguintes:

• Acesso livre: As barreiras à entrada para a capacidade de participar são tão baixas quanto possível. Isso é semelhante a um pool de mem público e vaza tanto EV_signal quanto EV_ordering.
• Acesso fechado: Há algum controle sobre a 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 os leilões 1inch Auction, Cowswap Auctions e Uniswap X. A competição para ganhar ordens captura EV_ordering para o usuário, enquanto o mecanismo de regulação 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 solucionador é selecionado a cada período de tempo. Como nenhuma informação é vazada para outros solucionadores, não há seleção adversa e desconto de primeira linha. O originador de fluxo de ordem 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.

Liquidação 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 a falha na transação. Esta subseção estudará as compensações entre o custo da segurança, o tempo de confirmação e a garantia de execução.

É importante notar que a execução da transação pretendida na cadeia de destino depende da mecânica de inclusão da transação 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. Os oráculos servem como relés de informação entre cadeias. Isso inclui verificar situações como um usuário bloqueando fundos em um conta de depósito para um bloqueio e cunhar ponte, ou confirmando 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.

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 esperar pelo 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 esperar por confirmações suficientes e continuar a cunhar 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 depósito, o Oracle terá gastos duplos.

Existem dois tipos de oráculos:

1. A Oracle fora do protocolo exige validadores de terceiros separadas das 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. A Cosmos tem IBC para cadeias que executam o Cosmos SDK, o ecossistema Polygon está trabalhando no AggLayer, enquanto o Optimism está trabalhando na Superchain. Cada oráculo usa blockspace dedicado para transferir informações entre cadeias do mesmo ecossistema.
3. Os sequenciadores partilhados são entidades fora de protocolo que têm direitos de ordenação de transações em protocolo, ou seja, podem agregar transações entre cadeias. Embora ainda estejam 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 sequenciadores compartilhados de atomicidade 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 multicadeia, os saldos de token de usuário e taxa 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 pontes ativas 34 com um TVL 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 cunhar ponte verifica os depósitos de tokens na cadeia de origem e os tokens de cunhagem 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. Violações de segurança nessas pontes resultaram em perda de bilhões de dólares para os detentores de tokens.
2. Liquidez bridges: Liquidez bridges 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 estas pontes tenham custos iniciais mais elevados, exigem garantias de segurança mais baixas. Em caso de violação de valores mobiliários, apenas os fundos dos pools de liquidez estão em risco.

Em ambos os tipos de pontes existe um custo de liquidez que tem de ser pago pelo utilizador. Em Lock and Mint bridges o custo de liquidez é durante a troca do wrapped tokens para o token desejado (USDC.e para USDC) na cadeia de destino, enquanto em Liquidez Bridges o custo de liquidez é durante a troca do token na cadeia de origem para o token na cadeia de destino.

Trilema de cadeia cruzada

As 5 decisões de design acima dão subir ao trilema cadeia cruzada. Um CAF tem que escolher 2 imóveis entre Garantia de Execução, Taxas Baixas e Velocidade de Execução.

1. Os caminhos no protocolo são caminhos designados para transferir informações entre cadeias. Esses sistemas conta para reorganização arriscam sacrificar a velocidade de execução, mas reduzem os custos eliminando a necessidade de um conjunto de validadores adicionais ou custos de liquidez.
2. A agregação do Solver coleta cotações de vários solvers para identificar o caminho mais barato e mais rápido para cumprir a intenção de um usuário. No entanto, devido à seleção adversa e ao front-running, os solucionadores podem, por vezes, não satisfazer a intenção, resultando numa execução reduzida.
3. A competição de execução seleciona um solucionador vencedor, organizando uma corrida entre os solucionadores para executar uma intenção ou escolhendo um único solucionador exclusivamente. Ambas as abordagens conduzem a taxas elevadas para o utilizador, uma vez que os solvers 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 em Chain Abstraction. Nesta seção, discutimos seis implementações independentes de CA que acreditamos ter 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 uma norma comum para expressar as 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 sobre a mensagem que está assinando, tornará mais fácil para solucionadores 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 de resolução

Leilões em lote exclusivos

Finalidade

Transferências baratas entre cadeias

Chamada de mensagem entre cadeias

Swaps baratos entre cadeias

Chamada de mensagem entre cadeias

Transferências rápidas entre cadeias

Chamada de mensagem entre cadeias

Exemplos

CCTP, CCIP, xERC20

AggLayer, Superchain, IBC

Bungee, Jumper, Uniswap X

Alfred, Abacate, perto de Conta

Transversal, Orbitador

NA

Carteira

Qualquer

Qualquer

Depende da implementação

AA ou baseado em políticas

Qualquer

Qualquer

Informação partilhada

Público

Público

Depende da implementação

Depende da implementação

Tudo 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

Em protocolo

Em protocolo

Fora de protocolo

Fora de protocolo

Fora de protocolo

Fora de protocolo

Token Ponte

Queimar e cunhar

Fechadura e cunhar

Depende do solucionador

Depende do solucionador

Liquidez ponte

Depende da implementação

Token Pontes Ungidas

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

Se você apertar os olhos o suficiente, uma queimadura e cunhar 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 em 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.

Ponte alinhada ao ecossistema

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

Há três anos, o ecossistema Cosmos enfrentou desafios semelhantes aos que o Ethereum enfrenta hoje. Liquidez estava 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 esses problemas implementando pontes de passagem de mensagens no protocolo através do IBC, resultando em contas multi-cadeia contínuas e transferências de cadeia cruzada.

O ecossistema cosmos é composto por cadeias independentes com segurança soberana e finalidade rápida, tornando o caminho protocolo para mensagens cadeia cruzada 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 a finalidade. Os caminhos protocolo para a passagem de mensagens pelos ecossistemas serão lentos devido a essas restrições de finalidade.

Concorrência de preços do Solver

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 (EV) 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, esta conceção acarreta o risco de não execução e requer mecanismos adicionais para assegurar a inclusão fiável das ordens. Exemplos de tais mecanismos incluem Uniswap X, Bungee e Jumper.

Carteira Mensagens coordenadas

Carteira mensagens coordenadas utilizam recursos fornecidos por AA ou carteiras 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 a carteira Avocado , Near Account Aggregator e Metamask Portfolio.

Note-se que, ao longo da última década, o ecossistema cripto aprendeu que a relação entre um utilizador e a sua carteira é muito complicada. Eu pessoalmente sinto um pavor mortal sempre que penso em migrar meu mnemônico da 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 EIP-4337 ganhou adoção mínima. Embora as versões mais recentes dos protocolos de carteira possam fornecer ao usuário um preço melhor (abstração de contas) 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 do Solver permite que os usuários expressem suas intenções para transições 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 ganha a intenção.

O projeto visa alcançar uma alta taxa de inclusão, maximizando o EV capturado pelos solucionadores. No entanto, ele tem o custo da centralização, pois depende de uma gestão sofisticada de capital na rede principal 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 de executar todo o fluxo de ordem em uma janela de tempo para um único solver. Como outros solucionadores não conseguem ver as ordens, eles fazem o lance 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 backstop em ordem para garantir bons preços ao usuário e, portanto, não podem ser usados para melhorar o 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 dar aos usuários uma interação cadeia cruzada 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 designs e suas implementações nos próximos 6 a 12 meses.

Transferência de Valor

Transferência de Informação

Caminhos no protocolo

Token ungido ponte

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 de resolução

Leilões em lote exclusivos

As transferências de valor entre cadeias serão encaminhadas através de uma combinação de pontes ungidas por tokens para taxas baixas e Competição de Velocidade ou Preço para velocidade e execução. Enquanto as transferências de informações serão encaminhadas através 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 serão agrupadas em torno desses seis designs distintos, pois cada um deles atende a necessidades independentes e se beneficia de eficiências existentes em diferentes cantos da matriz de compensação.

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

Declaração de exoneração de responsabilidade:

1. Este artigo foi reproduzido a partir 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 imediatamente.
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.