Agenda

O Problema

1. Definir 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 as aplicações de criptomoeda utilizáveis devem ser construídas 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. Compreender que os mercados de intenção funcionam melhor quando a rede de solucionadores é grande e competitiva

3. Iniciar a rede do resolvedor de intenções requer a integração de mais aplicações que produzam intenções

A Proposta

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

Aplicativos de criptografia utilizáveis não podem ser construídos sem abstração em cadeia

Estão os nossos melhores e mais brilhantes a construir infraestruturas redundantes?

Muitos lamentaram que os melhores engenheiros de criptografia e a maioria dos pensadores baseados estejam alocando atenção e energia demais para oferecer mais espaço de bloqueio aos usuários finais. Esta crítica tem mérito; há muitos L2s disponíveis para os usuários finais em relação à demanda por eles.

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

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 as 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 aplicações cripto úteis, mas sim o atrito para os utilizadores finais que tentam aceder a elas. Os utilizadores finais devem ser capazes de experimentar o seguinte ao interagir com aplicações cripto:

1. Velocidade: As aplicações devem parecer tão rápidas como as aplicações web2.
2. Custo: Ao contrário da web2, todas as interações da web3 devem incorrer em algum custo, mas o "custo por clique" deve ser negligenciável.
3. Resistência à censura ("permissão livre"): Qualquer pessoa com uma carteira deve poder interagir com a aplicação se tiver possibilidade de clicar.
4. Segurança: Os cliques devem fazer o que os utilizadores esperam que façam e não reverter—todas as atualizações web3 devem ser permanentes.

Estas são as propriedades de aplicações de criptomoeda “utilizáveis”.

Temos estado a tentar construir criptomoeda utilizável há muito 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 utilizadores finais: velocidade, custo ou segurança. Nós então imaginámos um futuro centrado em rollup ou modularque desbloquearia as três propriedades simultaneamente.

Hoje, construímos as bases para esta infraestrutura centrada em rollup. L2s oferecem espaço de bloco barato e rápido, e a maioria deles oferece espaço de bloco sem permissão. Por outro lado, L1 oferece espaço de bloco seguro e resistente à WW3. (Você pode ler mais sobre a relação segurança-UX oferecida por L1s e L2s emmeu artigo de pesquisa curto). Estes L2s ligam-se de forma segura à L1 através de caminhos de mensagens canónicos, lançando as bases para uma rede modular mas interoperável. Nos últimos quatro anos, construímos a fibra ótica entre blockchains que um dia suportará aplicações criptográficas úteis. Mas por que as 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 utilizadores se acumularão nas camadas mais rápidas e mais baratas.

A topologia modular da blockchain encoraja o espaço de bloco seguro a ser oferecido em uma camada diferente do que o espaço de bloco barato e rápido. Os utilizadores naturalmente preferirão armazenar o seu valor nas redes mais seguras, mas irão exigir interagir com mais frequência com as redes baratas e rápidas.Por design, os caminhos canónicos entre L2s e L1 são lentos e/ou caros. Estes fenómenos explicam por que os utilizadores têm de percorrer estes caminhos canónicos para pagar pelas interações L2 usando ativos L1. Isto resulta numa experiência de utilizador de criptomoeda "inutilizável".

Vitalik em diferentes tipos de L2s

O objetivo da abstração de chain é reduzir o atrito de enviar valor através desses caminhos em protocolo longe do usuário.Abstractores de cadeiassuponha que os utilizadores prefiram especificar o seu estado final desejado para as dapps como "intenções" e é responsabilidade da dapp cumprir as suas intenções. Os utilizadores não devem comprometer a custódia segura dos seus ativos para aceder a taxas baixas e baixa latência.

Portanto, abstração de cadeiadepende criticamente de os utilizadores serem capazes de transferir valor entre redes de forma segura, barata e rápida. Um fluxo comum de utilizador hoje em dia é um utilizador com um saldo de USDC numa cadeia 'segura' como Ethereum querer criar um NFT ou trocar por novos tokens numa cadeia mais recente como Blast ou Base. A forma de fazer isto em o menor número de passos possível é executar sequencialmente uma série de transações de Bridge→Swap→Mint (ou Swap→Bridge→Mint).

Neste exemplo, a intenção do utilizador é utilizar o seu USDC na cadeia segura para criar um NFT noutra cadeia. O utilizador ficará satisfeito desde que receba o NFT e o seu saldo de USDC seja debitado onde quer que opte por custodiar.

A Arquitetura Baseada em Intenções é a Única Forma de Construir a Abstração de Cadeias

A abstração de cadeias baseia-se na transferência de valor entre cadeias, mas enviar valor através de caminhos de mensagens canônicas é ou caro ou lento. As 'pontes rápidas' oferecem alternativas baratas e rápidas para os utilizadores enviarem valor entre redes, mas introduzem novas suposições de confiança. A passagem de mensagens é a forma mais intuitiva de construir uma ponte rápida, pois é modelada com base na arquitetura TCP/IP; ela depende de um protocolo de ponte que atua 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 da ponte enviando mensagens entre seus contratos nas cadeias de origem e destino. Esta mensagem é desencadeada no lado de origem por uma transação do usuário e transmitida para o lado de destino uma vez que a "validade" da mensagem é verificada.

Uma mensagem só pode ser verificada depois de a transação na cadeia de origem que iniciou a mensagem ter sido finalizada, ou seja, a transação estar permanentemente incluída na blockchain canônica da cadeia de origem. Esta 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 de um limiar de assinaturas de testemunhas atestando a sua inclusão ter acumulado do 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 plena finalidade antes de enviar a mensagem ao contrato do protocolo da cadeia de destino. Isso pode demorar até sete dias para L2s com períodos de finalidade otimista.
2. Uma mensagem de cross-chain é 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 uma capacidade limitada de obter liquidez externa para dar ao utilizador melhorias de preço, uma vez que deve ser declarativa sobre o caminho de cumprimento da intenção do utilizador.

As pontes rápidas de passagem de mensagens vão ser inseguras, lentas ou caras, dependendo do mecanismo de verificação. Os mercados de intenções são uma arquitetura alternativa para pontes rápidas que surgem de uma visão fundamental:

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

Pode uma ponte externalizar a transferência de valor para um agente sofisticado para ganhar velocidade e reduzir custos? A liquidez é dinâmica dentro e fora da cadeia, e a melhoria de preço pode ser realizada se o mecanismo da ponte tiver flexibilidade para escolher um caminho de execução ótimo no momento da transferência da ponte.

Mecanismos de intenção permitem aos utilizadores especificar condições ou pactos precisos sob os quais a 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 de ponte não precisa enviar uma mensagem entre domínios por transação de ponte para cumprir a intenção de cruzamento de domínio 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á posteriormente o reembolso do protocolo de ponte. Em comparação, os mecanismos de passagem de mensagens 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 de forma mais precisa como protocolos de resoluçã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 resolução de intenção oferecem aos solucionadores a segurança de que serão reembolsados e recompensados por cumprir as intenções do usuário. Para fazer isso, os protocolos de resolução de intenção precisam recorrer a um oráculo para verificar a autenticidade do cumprimento da intenção. A segurança do oráculo pode ser fundamentada 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 finalização e identificar caminhos de execução ótimos

As pontes de passagem de mensagens só podem comunicar tão rapidamente quanto a finalização é alcançada pela cadeia de origem. Os tempos de finalização são de sete dias em rollups otimistas e uma hora em rollups ZK hoje. Embora estes tempos de finalização devam diminuir com a adoção mais ampla da tecnologia ZK light client e avanços na tecnologia de pré-confirmação de sequenciamento compartilhado, é improvável que os tempos de finalização para todas as blockchains alguma vez se sintam “instantâneos” para os utilizadores, o que sugere uma necessidade persistente de soluções de ponte rápidas. É impossível retransmitir uma mensagem mais rapidamente do que o período de finalização sem assumir riscos de finalização - o que está fora do âmbito de uma ponte de passagem de mensagens - a menos que a ponte queira adicionar um agente de confiança adicional ao caminho de retransmissão que irá cobrir 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êneos podem assumir mais risco de finalidade do que um protocolo de passagem de mensagens pode e preencher a intenção de um usuário antes que o risco de reorganização de cadeia desapareça completamente. Os solucionadores subsequentemente cobrarão dos usuários por esse risco de finalidade que assumem em troca de tempos de preenchimento mais rápidos.

A externalização da realização de intenções de interoperabilidade para um agente também conduz, em média, a uma melhoria de preços para os utilizadores. Nas pontes baseadas em intenções, os solucionadores que antecipam as encomendas dos utilizadores na cadeia de destino desejada são reembolsados mais tarde pelo sistema após a validação da sua realização. Estes acordos de intenção podem ser agrupados para amortizar o custo. Os preenchedores, ao contrário dos utilizadores, não exigem um reembolso imediato e cobrarão aos utilizadores de acordo por anteciparem-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 o passo de reembolso do passo de realização de intenção.

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 fazer a ponte entre USDC e CCTP.)

As pontes de passagem de mensagens devem codificar como irão transferir valor para o utilizador. Alguns optam por enviar tokens de uma piscina de liquidez a uma taxa de câmbio predeterminada, enquanto outros criam tokens representativos para os destinatários que precisam então trocar pelo ativo de token canónico desejado.

Ao cumprir a intenção de um usuário, um agente pode obter liquidez a partir de uma combinação de locais de liquidez onchain e offchain. As redes de solucionadores competitivas oferecem aos usuários fontes ilimitadas de liquidez na teoria (mas mesmo essas fontes de liquidez podem ser rapidamente esgotadas quando o volume tende em uma direção durante eventos onchain de alta volatilidade, como lançamentos populares de NFTs, airdrops e rug pulls).

Submeter uma ordem de cadeia cruzada como uma intenção permite aos solucionadores internalizar o MEV gerado da ordem como melhoria de preço.

A arquitetura baseada em intenções é fundamentalmente projetada para ser segura

As pontes baseadas em intenções podem ser construídas com segurança porque separam as demandas urgentes do usuário das demandas complexas da rede de liquidação. Os resolutores podem esperar pelo reembolso, ao contrário dos usuários, e cobrarão dos usuários pelo tempo que o protocolo de liquidação os fizer esperar pelo reembolso. Portanto, os acordos de intenção podem ser validados usando mecanismos muito robustos sem uma restrição de tempo estrita. Isso é preferível do ponto de vista da segurança, pois 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 esforçar-se para reembolsar os preenchedores o mais rapidamente possível para reduzir as taxas dos utilizadores finais. Uma melhoria no mecanismo de desafio otimista seria um mecanismo de prova de validade ZK, que exigiria a codificação da lógica de validação de intenções num circuito ZK. Na minha opinião, é inevitável que os mecanismos de prova de validade substituam os mecanismos de desafio otimista e permitam às redes de liquidação de intenções reembolsar os utilizadores 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 da cadeia requer transferência de valor rápida e barata entre cadeias. Também não deve exigir que o usuário envie uma transação on-chain na rede onde seus ativos estão armazenados.

A intenção de um utilizador não precisa de ser submetida onchain pelo utilizador se incluir um Permit2ouEIP3074assinatura. Isso é verdade tanto para pontes de passagem de mensagens 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 estão dispostos a pagar de sua carteira de cadeia de origem.

Os mercados de intenção suportam melhor a abstração da cadeia porque 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 uma cotação para entrar em uma posição de staking WETH no Arbitrum, usando seu USDC no Optimism como pagamento. O usuário poderia enviar essa intenção offchain para um leilão de RFQ onde os solvers poderiam dar lances nela. O solucionador vencedor do leilão poderia então receber a intenção assinada do usuário, contendo uma permissão para gastar seu USDC no Otimismo, sua quantidade desejada de WETH para receber no Arbitrum e os dados de chamada necessários para depositar esse WETH em uma posição de staking no Arbitrum. O solucionador poderia posteriormente enviar essa transação no Optimism (em nome do usuário) para iniciar a intenção cross-chain e retirar USDC da carteira Optimism do usuário. 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 staking onchain.

Construir infraestrutura de abstração de cadeia significa tornar este fluxo de usuário instantâneo e barato sem exigir que eles submetam uma transação na cadeia. Vamos concluir este artigo discutindo os obstáculos a uma adoção mais ampla de intenções.

Arquitetura de Intenções pela Across

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

A ponte com intenções depende dos efeitos de rede do solver para funcionar melhor do que as variantes de passagem de mensagens. Este é o trade-off central da intenção versus 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 solvers, e algumas poderão preferir encaminhar suas intenções para redes de resolução oligopolísticasNo 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ções dependem.

Não queremos um mundo onde cada dapp está encaminhando intenções para redes de solucionadores isoladas. O melhor cenário para a experiência do usuário é que muitos dapps comuniquem com os mesmos pools de solucionadores, e todos os dapps tenham a liberdade de alterar para quais pools de solucionadores enviam as suas intenções.

Como inicializamos a rede do solucionador?

Devemos priorizar a experiência do utilizador do solucionador.

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

Realmente precisamos aumentar a eficiência de capital agregado da rede de solucionadores para todas as dapps baseadas em intenções. Isso exigirá abordar 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 muitas redes de liquidação de intenções diferenciadas e competitivas. Isso daria confiança aos solucionadores de que poderiam optar por encaminhar suas realizações de intenção para uma rede de liquidação em que confiam. A concorrência entre 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 características que afetariam a capacidade do solucionador de preencher uma intenção.

A escolha da rede de liquidação de intenções pelo solucionador afetará a 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 ao solucionador, o que apoiaria o desenvolvimento de leilões offchain onde solucionadores e usuários poderiam negociar e se comprometer com taxas de retransmissão. (Esses leilões de intenção podem ainda oferecer pré-confirmações economicamente vinculadas, melhorando ainda mais a UX. Para saber mais sobre um fluxo de usuário com descoberta de intenção via leilões e pré-confirmações, recomendo issoconversa por Karthik da Sorella.)

Algumas redes de liquidação podem oferecer expiração de intenção (ou seja, enviar o valor de volta aos utilizadores após o prazo de cumprimento), garantia de intenção (ou seja, a rede de liquidação usar o seu próprio balanço para cumprir a intenção de um utilizador se nenhum solucionador o fizer), ou cadeia de reembolso flexível (ou seja, permitir ao solucionador ser reembolsado na sua cadeia de escolha).

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

Está claro que precisamos de um padrão para intenções de cross-chain

Se os solucionadores puderem assumir que as intenções irão partilhar elementos comuns, então podem reutilizar o seu código para resolver intenções originadas por diferentes dapps e posteriormente reduzir os seus custos de configuração. Se diferentes dapps criarem intenções que se conformem com o mesmo padrão, então todos podem encaminhar as suas intenções para os mesmos pools de solucionadores. Isso ajudaria a integrar a próxima geração de dapps, dando-lhes a capacidade de ligar as suas intenções entre cadeias diretamente a um pool de solucionadores existente e maduro. As novas dapps não teriam que 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 estados de intenção para qualquer novo dapp se eles se conformassem a um padrão.

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

Imagino protocolos de liquidação concorrentes como SUAVE, Across, Anoma e Khalani oferecendo recursos diferenciados para solucionadores de intenção. Dependendo de qual rede de liquidação está reembolsando o solver, o solucionador pode oferecer diferentes garantias de preço e tempo para o proprietário da intenção. O dapp e o solucionador poderiam concordar em encaminhar a intenção de um usuário para uma rede de liquidação em que confiassem para evitar a censura, manter a privacidade dos dados e também ser seguro o suficiente para ser confiável para reembolsar o solucionador.

Ao consagrar a escolha da rede de liquidação no próprio pedido de intenção, o solucionador pode incorporar essa certeza na cotação que apresentaria ao utilizador. O solucionador e o utilizador eliminariam a incerteza inicial sobre o preço da ponte antes de submeter a intenção à cadeia, reduzindo custos.

Em colaboração com Uniswap e com base no feedback do grupo de trabalho CAKE, Across e eu propomos o seguinte padrão de intenção entre cadeias, priorizando a experiência do utilizador do solvedor.

///@titleTipo de Ordem CrossChain

///@noticeEstrutura de ordem padrão a ser assinada pelos trocadores, divulgada 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 origemaddress settlementContract;/// @dev O endereço do usuário que está iniciando a troca,/// cujos tokens de entrada serão retirados e mantidos em garantiaaddress swapper;/// @dev Nounce a ser usado como proteção contra repetição para a ordemuint256 nonce;/// @dev O chainId da cadeia de origemuint32 originChainId;/// @dev O carimbo de data/hora pelo qual a ordem deve ser iniciadauint32 initiateDeadline;/// @dev O carimbo de data/hora pelo qual a ordem deve ser preenchida na cadeia de destinouint32 fillDeadline;/// @dev Dados específicos da implementação arbitrária/// 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;

}

Esta norma foi concebida para facilitar o trabalho de um solucionador. Uma escolha opinativa que faz é apoiar o Permit2/EIP3074 nativamente com o nonce e o initiateDeadline e dá aos preenchedores algumas garantias, como o valor que eles serão reembolsados da rede de liquidação e o formato da intenção do usuário que eles podem rastrear. Além disso, uma função start é definida no padrão que permite crucialmente que o filler, aquele que trará o pedido onchain, especifique "fillerData" onchain adicional que o usuário não saberia no momento em que assinou o CrossChainOrder. Isso permite que o preenchedor se certifique de que eles são recompensados pelo contrato de liquidação por enviar a metatransação do usuário e também definir informações específicas de reembolso, como cadeia de reembolso.

Este padrão também foi concebido para facilitar o acompanhamento pelo dapps do estado de cumprimento da intenção ao longo do seu ciclo de vida. Qualquer contrato de liquidação que implemente este padrão deve criar um subtipo personalizado ResolvedCrossChainOrder que pode ser analisado a partir do campo de dados de ordem arbitrário. Isto pode incluir informações como os tokens envolvidos na troca, a(s) cadeia(s) de destino e outras restrições de cumprimento. Uma função de resolução está incluída no padrão para permitir aos dapps compreender como apresentar os estados de intenção aos utilizadores e para que os solvers saibam a estrutura exata da ordem de intenção com que estão a trabalhar.

///@titleTipo de Ordem ResolvedCrossChain

///@noticeUma representação genérica de uma ordem de implementação

///@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 settlementContract;/// @dev O endereço do utilizador que está a iniciar a trocaendereço swapper;/// @dev Nounce a ser usado como proteção contra repetição para a ordemuint256 nonce;/// @dev O chainId da chain 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(s) chain(s) de destinouint32 fillDeadline;/// @dev As entradas a serem obtidas do swapper como parte da iniciação da ordemInput[] swapperInputs;/// @dev As saídas a serem fornecidas ao swapper como parte do cumprimento da ordemOutput[] swapperOutputs;/// @dev As saídas a serem fornecidas ao filler como parte da liquidação da ordem;Output[] fillerOutputs;

}

///@noticeTokens enviados pelo swapper como entradas para a ordem

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 ordem válido

struct Output {

/// @dev O endereço do token ERC20 na cadeia de destino/// @dev endereço(0) usado como um sentinela para o token nativotokenaddress token;/// @dev A quantidade do token a ser enviadauint256 montante;/// @dev O endereço para receber os tokens de saídaaddress destinatário;/// @dev A cadeia de destino para esta 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 Deve ser chamado pelo preenchedor/// @param ordem A definição de CrossChainOrder/// @param assinatura A assinatura do swapper sobre a ordem/// @param dadosPreenchedor Quaisquer dados definidos pelo preenchedor necessários para o acertofunção iniciar(CrossChainOrder ordem, bytes assinatura, bytes dadosPreenchedor) externo;/// @aviso Resolve uma CrossChainOrder específica numa CrossChainOrder resolvida 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 de CrossChainOrder/// @param dadosPreenchedor Quaisquer dados definidos pelo preenchedor necessários para o acerto/// @returns CrossChainOrder resolvida dados da ordem hidratada incluindo as entradas e saídas da ordemfunção resolver(CrossChainOrder ordem, bytes dadosPreenchedor) externo view returns (CrossChainOrder resolvida);

}

Os objetivos de design deste padrão eram melhorar a experiência do solucionador, tornar mais fácil para eles suportar várias redes de liquidação e calcular de forma determinística suas recompensas. Acredito que isso lhes permitirá fornecer cotações mais precisas e mais apertadas aos utilizadores. Pode ler mais detalhes sobre este padrão, codinome ERC7683, neste post do X/Twittere a discussão em torno delano fórum dos Magos do Ethereum.

Considerações Finais

Os 'intents' são confusos porque não estão definidos, e esta falta de definição está a criar defeitos reais na experiência do utilizador (UX).

Todos querem que todos os outros usem a sua definição padrão de um intento, por isso reconheço plenamente que os padrões são praticamente impossíveis de estabelecer. Não acho que definir primeiro um sistema de liquidação de intento e tentar atrair fluxo de ordens em segundo lugar seja a abordagem correta para estabelecer um padrão em toda a indústria.

Na minha opinião, a abordagem mais viável é para dapps que já possuem muita afluência de utilizadores e originam muitas intenções de utilizadores, concordarem em conformar-se a algum padrão mínimo que os seus solucionadores existentes adotarão. Isto formará um novo e maior grupo de solucionadores. Ao obter acesso ao fluxo de pedidos combinado de locais já proeminentes, este novo grupo de solucionadores obterá mais lucros e será capaz de cotar melhores preços aos utilizadores finais. Eventualmente, dapps mais recentes também exigirão encaminhar as suas intenções para este grupo de solucionadores e apoiarão o seu padrão de intenção.

Para nos dar início, 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ões e origem de intenções) 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 a partir de [Espelho], Todos os direitos de autor pertencem ao autor original [Nick Pai]. Se houver objeções a esta reimpressão, por favor contacte o Gate Learnequipa, e eles vão tratar do assunto prontamente.
2. Responsabilidade de Isenção: 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. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.