Agenda

O Problema

1. Definindo o estado final: o que torna as aplicações de cripto "utilizáveis"

2. Por que a "abstração de cadeia" é uma solução para um problema de UX que surge da topologia fundamental das blockchains modulares

3. Por que aplicativos de cripto usáveis devem ser construídos em cima da infraestrutura de abstração de cadeia

O Espaço de Soluções

1. Como a arquitetura baseada em intenção dará origem à abstração de cadeia

2. Compreendendo que os mercados de intenção funcionam melhor quando a rede de solucionadores é grande e competitiva

3. Iniciar a rede de resolução de intenções requer a integração de mais aplicativos que produzirão intenções

A Proposta

1. Por que precisamos de um padrão de intenções de intercadeia que priorize a 'experiência do solucionador' para expandir o mercado de solucionadores e intenções para uma escala grande o suficiente para alcançar efeitos de rede

Aplicações criptográficas utilizáveis não podem ser construídas sem abstração de cadeia

Nossos melhores e mais brilhantes estão construindo infraestrutura redundante?

Muitos lamentaram que os melhores engenheiros de criptomoedas e os pensadores mais fundamentais estejam superalocando atenção e energia para oferecer mais espaço de bloco aos usuários finais. Essa crítica tem mérito; existem Gate muitos L2s disponíveis para os usuários finais em relação à demanda por eles.

No entanto, rejeito a ideia de que não existam aplicações úteis de criptomoeda.

As finanças descentralizadas oferecem às pessoas a capacidade de auto-guardar ativos digitais, permitindo-lhes contornar prestadores de serviços draconianos e usar seus ativos digitais para comprar coisas valorizadas no mundo real. A promessa de dados auto-guardados também oferece uma alternativa utópica para pessoas que estão cada vez mais desconfiadas de confiar nos monopólios FAANG para manter seus dados seguros.

O verdadeiro problema, na minha opinião, não é a falta de aplicativos de criptomoedas úteis, mas sim o atrito para os usuários finais que tentam acessá-los. Os usuários finais devem ser capazes de vivenciar o seguinte ao interagir com aplicativos de criptomoedas:

1. Velocidade: As aplicações devem parecer tão rápidas quanto as aplicações web2.
2. Custo: Ao contrário do web2, todas as interações do web3 devem incorrer em algum custo, mas o "custo por clique" deve ser negligenciável.
3. Resistência à censura ("sem permissão"): Qualquer pessoa com uma carteira deve ser capaz de interagir com o aplicativo se puder arcar com o custo de clicar.
4. Segurança: Os cliques devem fazer o que os usuários esperam que eles façam e não reverter - todas as atualizações web3 devem ser permanentes.

Estas são as propriedades de aplicativos de criptomoedas “utilizáveis”.

Nós temos tentado construir criptomoeda utilizável por um longo tempo

As soluções modulares de blockchain de hoje oferecem aos consumidores todas essas propriedades, mas elas não estão todas disponíveis no mesmo lugar.

Em 2020, as blockchains eram monolíticas, oferecendo duas das três propriedades aos usuários finais: velocidade, custo ou segurança. Então, imaginamos um futuro centrado em rollup ou modularque desbloquearia todas as três propriedades simultaneamente.

Hoje, construímos as bases para essa infraestrutura centrada em rollup. L2s oferecem espaços de bloco baratos e rápidos, e a maioria deles oferece espaços de bloco sem permissão. Por outro lado, L1 oferece espaços de bloco seguros, resistentes à WW3. (Você pode ler mais sobre a compensação segurança-UX oferecida por L1s e L2s emmeu artigo de pesquisa curto. Esses L2s se conectam de forma segura ao L1 por meio de caminhos de mensagem canônicos, lançando as bases para uma rede modular e interoperável. Nos últimos quatro anos, construímos a fibra óptica entre blockchains que um dia suportarão aplicações cripto úteis. Mas por que os blockchains modulares são tão inutilizáveis?

A inevitabilidade das redes blockchain modulares é que os ativos de capital se acumularão nas camadas mais seguras, enquanto os cliques dos usuários se acumularão nas camadas mais rápidas e mais baratas.

A topologia modular da blockchain encoraja que um espaço de bloco seguro seja oferecido em uma camada diferente do espaço de bloco barato e rápido. Os usuários naturalmente preferirão armazenar seu valor nas redes mais seguras, mas exigirão interagir com mais frequência com as mais baratas e rápidas.Por design, os caminhos canônicos entre L2s e L1 são lentos e/ou caros. Esses fenômenos explicam por que os usuários devem percorrer esses caminhos canônicos para pagar por interações L2 usando ativos L1. Isso resulta em uma UX de cripto “inutilizável”.

Vitalik sobre diferentes tipos de L2s

O objetivo da abstração de cadeia é reduzir o atrito ao enviar valor por esses caminhos no protocolo, longe do usuário.Abstractors de cadeiaAssumir que os usuários preferem especificar seu estado final desejado para dapps como "intenções" e é responsabilidade do dapp cumprir suas intenções. Os usuários não devem comprometer a custódia segura de seus ativos para acessar taxas baixas e baixa latência.

Portanto, abstração de cadeiadepende criticamente de os usuários serem capazes de transferir valor entre redes de forma segura, barata e rápida. Um fluxo comum de usuário hoje é que um usuário com um saldo de USDC em uma cadeia “segura” como Ethereum deseja criar um NFT ou trocar por novos tokens em uma cadeia mais recente como Blast ou Base. A maneira de fazer isso em poucas etapas é executar sequencialmente uma série de transações Ponte→Troca→Cunhagem (ou Troca→Ponte→Cunhagem).

Neste exemplo, a intenção do usuário é usar seu USDC na cadeia segura para criar um NFT em outra cadeia. O usuário ficará satisfeito contanto que receba o NFT e seu saldo de USDC seja debitado onde quer que escolha custodiar.

A arquitetura baseada em intenção é a única maneira de construir a abstração de cadeia

A abstração em cadeia depende da transferência de valor entre cadeias, mas enviar valor por meio de caminhos de mensagens canônicas é caro ou lento. As "pontes rápidas" oferecem alternativas baratas e rápidas para os usuários enviarem valor através das redes, mas introduzem novas suposições de confiança. A passagem de mensagens é a maneira mais intuitiva de construir uma ponte rápida, pois é modelada a partir da arquitetura TCP/IP; ela depende de um protocolo de ponte atuando como o Roteador TCP para conectar duas cadeias.

Diagrama TCP/IP do ResearchGate

A transferência de valor via passagem de mensagem envolve o protocolo Gate enviando mensagens entre seus contratos nas cadeias de origem e destino. Esta mensagem é acionada no lado de origem por uma transação do usuário e transmitida para o lado de destino assim que a 'validade' da mensagem é verificada.

Uma mensagem só pode ser verificada depois que a transação da cadeia de origem que iniciou a mensagem foi finalizada, ou seja, a transação está permanentemente incluída no blockchain canônico da cadeia de origem. Essa verificação pode ser concluída como uma prova de validade que comprova a inclusão do consenso da transação na cadeia de origem, como uma proposta otimista, ou depois que um limiar de assinaturas de testemunhas atestando sua inclusão tenha sido acumulado no lado da origem. Uma vez que a mensagem é transmitida para o contrato de ponte na cadeia de destino, os tokens são liberados para o usuário.

Existem várias questões fundamentais com esta arquitetura:

1. O mecanismo de verificação deve aguardar a total finalidade antes de enviar a mensagem para o contrato de protocolo da cadeia de destino. Isso pode levar até sete dias para L2s com períodos de finalidade otimista.
2. Uma mensagem de interligação é enviada por transação de ponte OU as mensagens são agrupadas, mas o lote só pode ser enviado depois que a última mensagem no lote for finalizada.
3. A ponte tem capacidade limitada para obter liquidez externa para oferecer melhorias de preço ao usuário, pois deve ser declarativa sobre o caminho de cumprimento da intenção do usuário.

Message-passing fast bridges are going to be either unsecure, slow, or expensive depending on the verification mechanism. Intent marketplaces are an alternative architecture for fast bridging that arise from a key insight:

O valor é fungível e não deve importar ao destinatário como o valor é transferido, desde que recebam os fundos

Um bridge pode terceirizar a transferência de valor para um agente sofisticado para ganhar velocidade e reduzir custos? A liquidez é dinâmica on e offchain e a melhoria de preço pode ser realizada se o mecanismo de bridge tiver flexibilidade para escolher um caminho de execução ótimo no momento da transferência da bridge.

Mecanismos de intenção permitem que os usuários especifiquem condições ou acordos precisos nos quais sua transação de transferência de valor pode ser executada.

Uma intenção mínima viável é uma ordem para pagar X token da cadeia A para receber Y token na cadeia B.

O protocolo da ponte não precisa enviar uma mensagem entre domínios por transação de ponte para cumprir a intenção de cruzar domínios do usuário. Em vez disso, o protocolo terceiriza a transferência de valor para um agente retirado de uma rede de solucionadores sem permissão, e o solucionador individual buscará reembolso posteriormente do protocolo da ponte. Em comparação, mecanismos de passagem de mensagem especificam exatamente como suas transações devem ser executadas e não precisam depender da disponibilidade de um agente.

Protocolos de liquidação de intenções

Os protocolos de ponte baseados em intenção podem ser rotulados com mais precisão como protocolos de liquidação de intenção que são responsáveis por garantir que os solucionadores não violem as condições especificadas pelo usuário. Os protocolos de liquidação de intenção oferecem segurança aos solucionadores de que serão reembolsados e recompensados por cumprir as intenções do usuário. Para fazer isso, os protocolos de liquidação de intenção precisam apelar a um oráculo para verificar a autenticidade do cumprimento da intenção. A segurança do oráculo pode ser baseada em um período de desafio otimista, um limiar de testemunhas, ou ser baseada em prova de validade ZK, por exemplo.

Os protocolos de liquidação de intenções oferecem transferência de valor rápida e barata porque os solucionadores individuais podem assumir o risco de finalidade e identificar os caminhos de execução ótimos

As pontes de passagem de mensagens só podem comunicar tão rapidamente quanto a finalidade é alcançada pela cadeia de origem. Os tempos de finalidade são de sete dias em rollups otimistas e uma hora em rollups ZK hoje. Embora esses tempos de finalidade devam diminuir com a adoção mais ampla da tecnologia de cliente leve ZK e avanços na tecnologia de pré-confirmação de sequenciamento compartilhado, é improvável que os tempos de finalidade para todas as blockchains nunca pareçam 'instantâneos' para os usuários, sugerindo uma necessidade persistente de soluções de ponte rápidas. É impossível transmitir uma mensagem mais rapidamente do que o período de finalidade sem assumir o risco de finalidade - o que está fora do escopo de uma ponte de passagem de mensagens - a menos que a ponte queira adicionar um agente confiável adicional ao caminho de retransmissão que cobrirá as perdas devido a reorganizações de cadeia.

A aceleração oferecida pela arquitetura baseada em intenções surge porque os solucionadores individuais dentro de uma rede de solucionadores heterogênea podem assumir mais risco de finalidade do que um protocolo de passagem de mensagens pode e preencher a intenção do usuário antes que o risco de reorganização de cadeia desapareça completamente. Os solucionadores posteriormente cobrarão dos usuários por esse risco de finalidade que assumem em troca de tempos de preenchimento mais rápidos.

A terceirização da realização de intenções entre cadeias a um agente também leva a uma melhoria de preço em média para os usuários. Nas pontes baseadas em intenções, os solucionadores que antecipam as ordens dos usuários na cadeia de destino desejada são reembolsados posteriormente pelo sistema após a validação de sua realização. Esses acordos de intenção podem ser agrupados para amortizar o custo. Os preenchedores, ao contrário dos usuários, não exigem reembolso imediato e cobrarão dos usuários de acordo por antecipar-lhes capital. A liquidação em lote não é única para a arquitetura baseada em intenções, mas a arquitetura é mais sinérgica com a liquidação em lote porque separa a etapa de reembolso da etapa de realização de intenções.

A maior fonte de melhoria de preço vem da intuição de que o valor é fungível, e encontrar o melhor caminho just-in-time geralmente superará a transferência de valor. (No entanto, alguns caminhos serão impossíveis de superar no custo just-in-time, como ao bridging USDC sobre CCTP.)

As pontes de transferência de mensagens devem codificar como irão transferir valor para o usuário. Alguns optam por enviar tokens de um pool de liquidez a uma taxa de câmbio predeterminada, enquanto outros cunham tokens representativos para os destinatários que precisam então trocar pelo ativo de token canônico desejado.

Ao atender a intenção de um usuário, um agente pode obter liquidez a partir de uma combinação de locais de liquidez on-chain e off-chain. Redes de solucionadores competitivos oferecem aos usuários fontes ilimitadas de liquidez na teoria (mas mesmo essas fontes de liquidez podem ser rapidamente esgotadas quando a tendência de volume segue em uma direção durante alta volatilidade em eventos on-chain populares, como lançamentos de NFT, airdrops e rug pulls).

Submeter uma ordem entre cadeias como uma intenção permite que os solucionadores internalizem o MEV gerado da ordem como melhoria de preço.

A arquitetura baseada em intenção é fundamentalmente projetada para ser segura

As pontes baseadas em intenção podem ser construídas com segurança porque separam as demandas urgentes do usuário das demandas complexas da rede de liquidação. Os solucionadores podem aguardar o reembolso, ao contrário dos usuários, e cobrarão dos usuários pelo tempo que o protocolo de liquidação os faz esperar pelo reembolso. Portanto, as liquidações de intenção podem ser validadas usando mecanismos muito robustos sem uma restrição de tempo estrita. Isso é preferível do ponto de vista da segurança porque verificar o cumprimento de uma intenção é intuitivamente complexo.

Como exemplo de verificação de intenção em produção, Atravésvalida e reembolsa preenchedores em lotes após um período de desafio otimista de 90 minutos. Claro, as redes de liquidação devem se esforçar para reembolsar os preenchedores o mais rapidamente possível para reduzir as taxas dos usuários finais. Uma melhoria no mecanismo de desafio otimista seria um mecanismo de prova de validade ZK, que exigiria codificar a lógica de validação de intenção em um circuito ZK. Na minha opinião, é inevitável que mecanismos de prova de validade substituam mecanismos de desafio otimista e permitam que redes de liquidação de intenção reembolsem os usuários mais rapidamente.

Então, como surge a abstração de cadeia a partir da arquitetura baseada em intenção?

Lembre-se de que a abstração de cadeia requer transferência de valor entre cadeias rápida e barata. Também não deve exigir que o usuário envie uma transação onchain na rede onde seus ativos estão armazenados.

A intenção do usuário não precisa ser enviada onchain pelo usuário se incluir um Alvará2 ou EIP3074assinatura. Isso é verdade tanto para pontes de passagem de mensagem quanto para pontes baseadas em intenção. Ambas as arquiteturas podem aproveitar o padrão Permit2 para permitir que o usuário assine offchain a quantidade de tokens que eles estão dispostos a pagar de sua carteira de origem na cadeia.

Mercados de intenção melhor suportam a abstração de cadeia, pois oferecem transferência de valor entre cadeias barata e rápida. Imagine um mundo onde um usuário poderia solicitar a um solucionador que lhe desse um orçamento para entrar em uma posição de aposta em WETH no Arbitrum, usando seu USDC no Optimism como pagamento. O usuário poderia enviar esta intenção offchain para um leilão RFQ onde os solucionadores poderiam dar lances. O solucionador vencedor do leilão poderia então receber a intenção assinada do usuário, contendo uma autorização para gastar seu USDC no Optimism, a quantidade desejada de WETH a receber no Arbitrum e os dados de chamada necessários para depositar este WETH em uma posição de aposta no Arbitrum. O solucionador poderia subsequentemente enviar esta transação no Optimism (em nome do usuário) para iniciar a intenção entre cadeias e retirar o USDC da carteira do usuário no Optimism. Finalmente, o solucionador poderia preencher a intenção do usuário no Arbitrum enviando-lhes WETH e encaminhando os dados de chamada para inserir o usuário na posição de aposta onchain.

Construir infraestrutura de abstração de cadeia significa fazer com que este fluxo de usuário pareça instantâneo e barato sem exigir que eles enviem uma transação onchain. Vamos concluir este artigo discutindo obstáculos para uma adoção mais ampla de intenções.

Arquitetura de Intenções pela Across

Para que a melhor experiência do usuário possa se materializar a partir da abstração baseada em intenção da cadeia, precisamos de uma rede competitiva de solucionadores

A ponte com intenções depende dos efeitos de rede do resolvedor para se sair melhor do que as variantes de passagem de mensagens. Este é o trade-off fundamental entre intenção e arquiteturas de passagem de mensagens. Realisticamente, nem todas as aplicações que produzem intenções precisarão de acesso a um conjunto perfeitamente competitivo de resolvedores, e algumas podem preferir rotear suas intenções para redes oligopolísticas de solucionadores. No entanto, o estado atual das redes de solucionadores é imaturoe não está perto de cumprir as suposições de vitalidade da rede do solucionador em que os mercados de intenção dependem.

Não queremos um mundo onde cada dapp está roteando intenções para redes de solucionadores isoladas. O melhor caso para UX é que muitos dapps se comuniquem com os mesmos pools de solucionadores, e todos os dapps tenham a liberdade de mudar para quais pools de solucionadores eles enviam suas intenções.

Como inicializamos a rede do solucionador?

Devemos priorizar a experiência do solucionador.

Executar um resolvedor de intenções é complicado e requer expertise na construção de software altamente performático, bem como na gestão do risco de inventário entre cadeias. Naturalmente, haverá partes interessadas limitadas em pagar o custo inicial para executar este código. No melhor cenário, um resolvedor escrito para um dapp, como um resolvedor UniswapX, poderia ser reutilizado para resolver outros dapps produtores de intenções, como Across e CowSwap.

Precisamos realmente aumentar a eficiência de capital agregado da rede de solucionadores para todos os dapps baseados em intenção. Isso exigirá enfrentar as barreiras para executar um solucionador.

Para isso, precisaremos que os dapps que produzem intenções sejam visíveis para qualquer solucionador e garantir que todos os solucionadores tenham acesso a várias redes de liquidação de intenções diferenciadas e competitivas. Isso daria confiança aos solucionadores de que poderiam escolher encaminhar suas realizações de intenções para uma rede de liquidação em que confiam. A competição entre as redes de liquidação também reduziria os custos para os solucionadores.

A proposta de valor das redes de liquidação de intenções é oferecer segurança aos solucionadores, bem como outras funcionalidades que afetariam a capacidade do solucionador de preencher uma intenção.

A escolha da rede de liquidação de intenções pelo solucionador afetará sua capacidade de oferecer taxas e garantias de tempo de execução aos usuários. Algumas redes de liquidação podem oferecer períodos de exclusividade para o solucionador, o que apoiaria o desenvolvimento de leilões offchain nos quais solucionadores e usuários poderiam negociar e se comprometer com taxas de transmissão. (Esses leilões de intenções também podem oferecer pré-confirmações economicamente vinculadas, melhorando ainda mais a experiência do usuário. Para saber mais sobre um fluxo de usuário que apresenta a descoberta de intenções por meio de leilões e pré-confirmações, recomendo estepalestra por Karthik da Sorella.)

Algumas redes de liquidação podem oferecer vencimento de intenção (ou seja, enviar o valor de volta para os usuários após o prazo de cumprimento), garantia de intenção (ou seja, a rede de liquidação usando seu próprio balanço para cumprir a intenção do usuário se nenhum solucionador fizer isso), ou cadeia de pagamento flexível (ou seja, permitindo que o solucionador seja reembolsado em sua cadeia de escolha).

No final, as redes de liquidação competirão ferozmente para reembolsar rapidamente e barato os solucionadores sem comprometer a segurança. Por sua vez, os solucionadores enviarão seu fluxo de pedidos para as redes de liquidação que lhes permitem oferecer as taxas mais baratas aos usuários para que possam ganhar o fluxo de pedidos do dapp. A competição nas redes de liquidação e solucionadores depende de todas as partes na cadeia de suprimentos de intenção coordenando para falar a mesma língua, e a competição levará à melhor experiência do usuário para a transferência de valor entre cadeias.

Está claro que precisamos de um padrão para intenções entre cadeias

Se os solucionadores puderem assumir que as intenções compartilharão elementos comuns, então eles podem reutilizar seu código para resolver intenções originadas por diferentes dapps e, posteriormente, reduzir seus custos de configuração. Se diferentes dapps criarem intenções que cumpram o mesmo padrão, então todos eles podem encaminhar suas intenções para os mesmos pools de solucionadores. Isso ajudaria a integrar a próxima geração de dapps, dando a eles a capacidade de conectar suas intenções intercadeias diretamente a um pool de solucionadores existente e maduro. Novos dapps não precisariam integrar solucionadores individualmente e, em vez disso, teriam acesso a transferências de valor baratas, rápidas, seguras e sem permissão.

O software de rastreamento de terceiros também seria capaz de rastrear mais facilmente os status de intenção para qualquer novo dapp, se eles seguirem um padrão.

Este padrão de intenção deve permitir que o principal da intenção ou o solucionador especifiquem em qual rede de liquidação desejam liquidar sua intenção.

Eu imagino protocolos de liquidação concorrentes como SUAVE, Across, Anoma e Khalani oferecendo recursos diferenciados aos solucionadores de intenções. Dependendo de qual rede de liquidação está reembolsando o solucionador, este pode oferecer garantias de preço e prazo diferentes ao proprietário da intenção. O dapp e o solucionador podem concordar em rotear a intenção do usuário para uma rede de liquidação em que confiam para evitar censura, manter a privacidade dos dados e também ser seguro o suficiente para ser confiável ao reembolsar o solucionador.

Ao consagrar a escolha da rede de liquidação no próprio pedido de intenção, o resolvedor poderia incorporar essa certeza na cotação que mostrariam ao usuário. O resolvedor e o usuário eliminariam a incerteza inicial sobre a precificação da ponte antes de enviar a intenção na cadeia, reduzindo os custos.

Em colaboração com Uniswap e com base no feedback do grupo de trabalho da CAKE, Across e eu propomos o seguinte padrão de intenção de cadeia cruzada priorizando a experiência do usuário do solucionador:

/// @titleTipo de Ordem CrossChain

///@noticeEstrutura de ordem padrão a ser assinada pelos swappers, disseminada aos preenchedores e submetida aos contratos de liquidação

struct CrossChainOrder {

/// @dev O endereço do contrato pelo qual a ordem deve ser liquidada./// Os preenchedores enviam esta ordem para este endereço de contrato na cadeia de origemendereço settlementContract;/// @dev O endereço do usuário que está iniciando a troca,/// cujos tokens de entrada serão retirados e mantidos em garantiaendereço swapper;/// @dev Número aleatório a ser usado como proteção contra repetição para a ordemuint256 nonce;/// @dev O chainId da cadeia de origemuint32 originChainId;/// @dev O timestamp pelo qual a ordem deve ser iniciadauint32 initiateDeadline;/// @dev O timestamp pelo qual a ordem deve ser preenchida na cadeia de destinouint32 fillDeadline;/// @dev Dados arbitrários específicos da implementação/// Pode ser usado para definir tokens, quantidades, cadeias de destino, taxas, parâmetros de liquidação,/// ou qualquer outra informação específica do tipo de ordembytes orderData;

}

Este padrão é projetado para facilitar o trabalho de um solucionador. Uma escolha opinativa que ele faz é apoiar Permit2/EIP3074 nativamente com o nonce e o initiateDeadline e ele dá aos preenchedores algumas garantias, como o valor que será reembolsado da rede de liquidação e o formato da intenção do usuário que eles podem rastrear. Além disso, uma função de iniciação é definida no padrão que permite crucialmente ao preenchedor, aquele que trará o pedido onchain, especificar dados adicionais “fillerData” onchain que o usuário não teria conhecido no momento em que assinou a CrossChainOrder. Isso permite ao preenchedor garantir que seja recompensado pelo contrato de liquidação por enviar a meta-transação do usuário e também definir informações específicas de reembolso, como a cadeia de reembolso.

Este padrão também é projetado para facilitar o rastreamento do status de realização de intenções ao longo de seu ciclo de vida para dapps. Qualquer contrato de liquidação que implemente esse padrão deve criar um subtipo personalizado ResolvedCrossChainOrder que pode ser analisado a partir do campo de dados do pedido arbitrário. Isso pode incluir informações como os tokens envolvidos na troca, a(s) cadeia(s) de destino e outras restrições de realização. Uma função de resolução está incluída no padrão para permitir que os dapps entendam como exibir os status de intenção aos usuários e para que os solucionadores saibam a estrutura exata do pedido de intenção com o qual estão trabalhando.

/// @titleTipo de Pedido Resolvido entre Cadeias

///@noticeUma representação genérica de implementação de um pedido

/// @devDefine todos os requisitos para preencher um pedido desagregando os dados do pedido específicos da implementação.

///@devDestinado a melhorar a generalização da integração permitindo que os preenchedores calculem as informações exatas de entrada e saída de qualquer ordem

struct ResolvedCrossChainOrder {

/// @dev O endereço do contrato pelo qual a ordem deve ser liquidada.endereço de liquidação do contrato;/// @dev O endereço do usuário que está iniciando a trocaendereço do trocador;/// @dev Número aleatório a ser usado como proteção contra repetição para a ordemuint256 nonce;/// @dev O chainId da chain de origemuint32 originChainId;/// @dev O horário limite para a ordem ser iniciadauint32 initiateDeadline;/// @dev O horário limite para a ordem ser preenchida na(s) chain(s) de destinouint32 fillDeadline;/// @dev As entradas a serem obtidas do trocador como parte da iniciação da ordemEntrada[] entradas do trocador;/// @dev As saídas a serem fornecidas ao trocador como parte do cumprimento da ordemSaída[] saídas do trocador;/// @dev As saídas a serem fornecidas ao preenchedor como parte da liquidação da ordemSaída[] saídas do preenchedor;

}

///@noticeTokens enviados pelo swapper como entradas para o pedido

struct Input {

/// @dev O endereço do token ERC20 na cadeia de origem endereço do token;/// @dev A quantidade do token a ser enviada uint256 quantidade;

}

///@noticeTokens que devem ser recebidos para um cumprimento de pedido válido

struct Output {

/// @dev O endereço do token ERC20 na cadeia de destino/// @dev O endereço(0) usado como um sentinela para o token nativoendereço do token;/// @dev A quantidade do token a ser enviadauint256 quantidade;/// @dev O endereço para receber os tokens de saídaendereço do destinatário;/// @dev A cadeia de destino para essa saídauint32 chainId;

}

Uma implementação de contrato de liquidação compatível DEVE implementar a interface ISettlementContract:

///@titleISettlementContract

/// @noticeInterface padrão para contratos de liquidação

interface ISettlementContract {

/// @aviso Inicia o acerto de uma ordem cross-chain/// @dev A ser chamado pelo preenchedor/// @param ordem A definição da ordem CrossChain/// @param assinatura A assinatura do trocador sobre a ordem/// @param dadosPreenchedor Quaisquer dados definidos pelo preenchedor necessários pelo liquidante função iniciar(CrossChainOrder ordem, bytes assinatura, bytes dadosPreenchedor) externo;/// @aviso Resolve uma specifica CrossChainOrder em uma ResolvedCrossChainOrder genérica/// @dev Destinado a melhorar a integração padronizada de vários tipos de ordem e contratos de acerto/// @param ordem A definição da ordem CrossChain/// @param dadosPreenchedor Quaisquer dados definidos pelo preenchedor necessários pelo liquidante/// @returns ResolvedCrossChainOrder dados da ordem hidratada incluindo as entradas e saídas da ordem função resolver(CrossChainOrder ordem, bytes dadosPreenchedor) externo view retorna (ResolvedCrossChainOrder);

}

Os objetivos de design deste padrão foram aprimorar a experiência do solucionador, tornar mais fácil para eles suportar várias redes de liquidação e calcular deterministicamente suas recompensas. Acredito que isso lhes permitirá fornecer cotações mais precisas e justas aos usuários. Você pode ler mais detalhes sobre este padrão, codinome ERC7683,neste post do X/Twittere a discussão em torno delano fórum Ethereum Magicians.

Pensamentos Finais

"Intents" são confusos porque não são definidos, e essa falta de definição está criando defeitos reais de UX.

Todos querem que os outros usem sua definição padrão de intenção, então reconheço plenamente que os padrões são praticamente impossíveis de estabelecer. Não acredito que definir primeiro um sistema de liquidação de intenções e tentar atrair o fluxo de pedidos seja a abordagem correta para estabelecer um padrão em toda a indústria.

Na minha opinião, a abordagem mais viável é que os dapps que já possuem muito fluxo de usuários e originam muitas intenções de usuários concordarão em conformar-se a algum padrão mínimo que seus solvers existentes adotarão. Isso formará um novo e maior pool de solvers. Ao obter acesso ao fluxo de pedidos combinado de locais já proeminentes, este novo pool de solvers obterá mais lucros e poderá cotar melhores preços para os usuários finais. Eventualmente, novos dapps também exigirão rotear suas intenções para este pool de solvers e apoiarão seu padrão de intenções.

Para nos dar um pontapé inicial, Across e Uniswap estão juntospropondo um padrãopara todas as partes da cadeia de suprimentos usarem ao lidar com pedidos de usuários para enviar tokens X da cadeia A e receber tokens Y da cadeia B. O fluxo de pedidos que passa pelo UniswapX (tendo uma vantagem comparativa no design de leilão e intenções de origem) e pelo Across (tendo uma vantagem comparativa no cumprimento de intenções) pode se fundir e iniciar o processo de nutrir uma rede de solucionadores maior e mais competitiva.

Aviso Legal：

1. Este artigo é reproduzido de [GateEspelho], Todos os direitos autorais pertencem ao autor original [Nick Pai]. Se houver objeções a este reenvio, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas 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 Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.