Ethereum pode fazer os rollups parecerem uma única rede?

Um trader em uma demonstração na Devcon assinou uma ordem em um rollup Ethereum, comprou tokens usando liquidez na mainnet e os recebeu de volta no rollup. A negociação mostra como os usuários poderiam alcançar um mercado mais profundo sem mover fundos eles mesmos, uma abordagem que a Gnosis está mirando para sua configuração padrão na primavera de 2027.

A equipe da Ethereum Economic Zone demonstrou uma negociação na qual um usuário assinou uma ordem na rede experimental Rollup X, um solver do CoW Swap a preencheu usando liquidez da mainnet Ethereum, e os tokens comprados chegaram de volta ao rollup. A demonstração mostra como um trader poderia alcançar um mercado mais profundo na mainnet sem primeiro enviar fundos para lá e esperar que chegassem antes de fazer a ordem.

A equipe apresentou a negociação na Devcon em 4 de novembro, conforme relatado pela crypto.news. A distinção importa quando os preços se movem rapidamente, já que uma cotação disponível quando um trader começa a mover fundos pode mudar antes que os fundos estejam prontos para negociar.

A Gnosis tem como meta a primavera de 2027 para tornar o design seu padrão. Para os traders, o teste prático será se suas carteiras e aplicativos de negociação podem oferecer a rota e se o preço disponível na mainnet ainda vale a pena após os custos de execução.

Como a negociação funcionaria entre dois ambientes de execução

A equipe da Ethereum Economic Zone começou com uma transação de outubro envolvendo 0,001 ETH e uma atualização do estado do rollup. A troca na Devcon levou o mesmo problema de coordenação para um cenário que os traders reconhecem. Ela tinha que cumprir uma ordem contra liquidez em outra chain e entregar o ativo resultante onde o usuário havia começado.

Para um trader, a ordem descreve um resultado. Um vendedor quer trocar um ativo por outro, sujeito aos termos da ordem, e receber o resultado no rollup. O solver assume a responsabilidade de encontrar um caminho de execução. A distinção importa porque o usuário pode autorizar um resultado sem decidir qual pool o solver usará ou preparar uma transação separada para cada operação.

No exemplo da Devcon, esse caminho incluía a mainnet Ethereum. A liquidez de negociação permaneceu lá, enquanto a ordem do usuário se originou no Rollup X e os ativos comprados retornaram para ele. A demonstração, assim, abordou um problema que pode surgir mesmo quando as aplicações de cada rede funcionam corretamente por conta própria. Um trader pode ter fundos em uma chain com um mercado raso para o par desejado, enquanto a melhor execução está disponível em outro lugar.

Uma rota com etapas separadas expõe o usuário a decisões ao longo do caminho. A primeira transferência pode ser concluída enquanto a cotação que o usuário viu mudou. Nesse ponto, o usuário deve aceitar o preço atual, esperar ou mover os fundos novamente. Uma rota coordenada pode condicionar os movimentos de ativos à conclusão de toda a ordem, desde que a infraestrutura participante possa realizar a operação na janela de execução acordada.

A distinção prática é entre uma rota que promete entrega e uma rota que vincula as operações componentes entre si. Um serviço pode fazer uma negociação cross-chain parecer simples assumindo a responsabilidade pela entrega em si. O design na demonstração dá à aplicação uma maneira de vincular o resultado em uma chain à execução em outra. Qual abordagem oferece a melhor experiência depende do preço, dos ativos disponíveis e dos termos sob os quais cada serviço entrega a ordem.

Ainda há trabalho por trás da assinatura do usuário. Uma aplicação tem que apresentar os termos, o solver tem que encontrar e precificar a rota, e as redes participantes têm que concordar sobre o estado relevante. Um sistema de produção deve lidar com falhas em cada um desses pontos. A aplicação pode simplificar a interface sem fazer esses trabalhos desaparecerem.

Para uma carteira, um teste igualmente prático é o registro de transação que ela pode mostrar após a ordem expirar. Se um usuário assina uma vez e uma negociação é bem-sucedida, o usuário deve poder ver o ativo recebido e qual conta o recebeu. Se a rota falhar, a carteira ainda precisa de uma forma de distinguir uma ordem expirada de uma transação que está aguardando liquidação. Isso importa durante um movimento de mercado, quando um trader pode colocar uma segunda ordem e precisa saber se a primeira ainda pode ser executada.

Em que as redes precisam concordar antes de poderem executar juntas

Uma blockchain registra mais do que saldos. Seu estado inclui informações usadas por aplicações, como permissões de conta, saldos de contratos e o status das transações. Um contrato que deseja depender de um resultado de outra cadeia precisa de evidência sobre esse estado. A evidência deve estar disponível quando o contrato precisar usar o resultado.

A Gnosis descreve duas condições para redes que aderem ao design da EEZ. Elas precisam produzir uma prova dentro de um slot do Ethereum e seguir o Ethereum em caso de reorganização. A Gnosis apresenta essas como condições para uma rede conectada, deixando algumas escolhas de implementação para participantes individuais.

Um slot dá aos engenheiros um prazo. Se uma rede levar mais tempo do que o disponível para produzir a prova necessária, o outro lado não pode depender dela dentro da mesma janela. Um sistema de prova que tem bom desempenho em blocos típicos ainda precisa lidar com cargas de trabalho excepcionalmente exigentes, interrupções e competição por recursos computacionais.

A segunda condição aborda o que acontece quando o histórico recente do Ethereum muda. Uma transação em outra rede pode ter dependido de um evento em um bloco recente da mainnet. Se um bloco concorrente o substituir, o sistema conectado precisa de regras para lidar com a transação dependente. O alinhamento limita a possibilidade de um lado manter um resultado baseado em um evento da mainnet que não pertence mais à cadeia aceita.

Essa relação é importante para os usuários porque uma transação coordenada e a liquidação final descrevem propriedades diferentes. A execução coordenada diz respeito a se as etapas podem ser concluídas juntas. A liquidação final diz respeito a quando os participantes podem tratar o resultado como liquidado sob as regras das redes envolvidas. Uma carteira pode oferecer uma visão da operação enquanto ainda distingue uma transação incluída de uma que atingiu o status de liquidação que um negócio exige.

Trabalhos de engenharia anteriores da Gnosis abordaram compromissos de raiz de bloco, limites de gas e como as atualizações seriam realizadas. Essas escolhas afetam como as redes podem reconhecer os resultados umas das outras e quanto trabalho as aplicações podem pedir que elas façam. O marco de outubro colocou uma operação simples na mainnet, enquanto as demonstrações de novembro deram aos desenvolvedores cargas de trabalho mais variadas para experimentar.

Onde o design pode ir além da negociação

A demonstração da Safe aplicou a mesma abordagem à propriedade de carteira. Um tesouro que usa contas separadas entre cadeias pode enfrentar uma lacuna entre remover um signatário em uma rede e atualizar permissões em outro lugar. O exemplo mostrou como um rollup poderia verificar uma mudança de propriedade feita na mainnet dentro da mesma transação.

Uma terceira demonstração verificou uma assinatura pós-quântica Falcon no rollup e usou o resultado para autorizar uma transferência na mainnet. A equipe relatou consumo de gas 91% menor em sua comparação com fazer a verificação diretamente na mainnet. A economia medida foi para esse exercício de verificação, e uma aplicação em produção teria que contabilizar seus custos totais de execução e liquidação.

Uma assinatura ainda deixa um mercado para execução

A rota de swap afasta parte do trabalho da pessoa que coloca uma ordem. Um solver precisa decidir onde preenchê-la, contabilizar taxas e enviar as operações necessárias para concluí-la. Um usuário pode receber uma única cotação mesmo que o solver tenha precificado várias etapas no valor oferecido.

Esse arranjo é mais útil quando a liquidez disponível em outra rede melhora a negociação o suficiente para cobrir o custo de alcançá-la. Uma ordem pequena em um mercado local profundo pode ser mais barata de preencher localmente. Uma ordem maior em um pool raso pode receber um preço melhor da liquidez da mainnet mesmo após os custos extras de execução.

Também importa o que acontece com tentativas fracassadas. Reverter os movimentos de ativos evita que o trader fique apenas com uma perna da negociação pretendida. Uma aplicação ou solver ainda pode incorrer em custos ao organizar ou tentar a execução, dependendo de como a rota é implementada. Em um mercado em produção, esses custos podem afetar quais ordens os solvers estão dispostos a preencher e como eles precificam suas cotações.

Uma boa comparação para traders usaria o mesmo tamanho de ordem, par de tokens e janela de tempo. O preço recebido após as taxas pode então ser comparado com um swap local ou uma rota que faz a ponte dos fundos em etapas separadas. O número de cliques captura a conveniência. O valor líquido recebido captura a negociação em si.

Como o projeto passou de uma proposta para uma devnet

O projeto foi apresentado publicamente na EthCC na primavera pela Gnosis e pela ZisK, com apoio da Ethereum Foundation. A proposição original dizia respeito à liquidez e às aplicações que haviam se distribuído entre diferentes redes de camada 2. A Rollup X oferece aos desenvolvedores um ambiente no qual testar como uma transação compartilhada pode usar essas aplicações.

Há um motivo pelo qual a escolha da demonstração importa. Mover uma pequena quantidade de ETH entre ambientes testa uma operação relativamente direta. Um swap introduz a necessidade de satisfazer uma ordem contra a liquidez de mercado e devolver um ativo. Uma mudança na propriedade de uma Safe envolve permissões. A verificação de assinatura exige que um ambiente realize uma checagem e outro aja com base em seu resultado. Cada uma sonda uma dependência diferente.

Uma rota que funciona para uma dessas operações pode ser impraticável para outra. Um swap tem de lidar com preços e liquidez que se movem continuamente. Uma mudança de propriedade é menos sensível ao preço de mercado, mas pode ter modos de falha mais consequentes. Uma aplicação de verificação pode se beneficiar de realizar trabalho computacional em outro lugar mesmo quando não há razão econômica para mover fundos entre redes.

O requisito comum é que o contrato receptor possa confiar na informação no momento em que precisa dela. Isso pressiona o software que mantém os vínculos. Uma aplicação pode oferecer uma interface simples apenas se o caminho de execução lidar com o estado necessário e retornar o resultado esperado. Em um produto em produção, os desenvolvedores teriam de decidir quais operações valem a pena ser colocadas nesse caminho e quais podem rodar de forma independente.

O argumento da Gnosis para tornar a tecnologia o padrão baseia-se em parte naquilo que as aplicações poderiam evitar duplicar. Uma equipe construindo em uma nova rede poderia, de outra forma, precisar financiar liquidez local para uma longa lista de mercados. A capacidade de alcançar pools da mainnet poderia permitir oferecer negociação em um par antes que um pool local dedicado se torne viável. Para um provedor de liquidez local, a mesma escolha cria concorrência a partir de outra fonte de execução.

O efeito sobre os usuários é mais facilmente medido em produtos que divulgam ambas as rotas. Uma carteira poderia comparar uma execução local com uma execução na mainnet para a mesma ordem e mostrar o valor líquido na mesma cadeia de destino. Uma ferramenta de tesouraria poderia documentar quantas transações separadas são necessárias para aplicar uma mudança de autoridade. Esses testes mostrariam onde a abordagem altera os custos reais de execução ou o trabalho operacional.

O cronograma importa porque uma demonstração bem-sucedida pode ser muito mais fácil de operar do que um serviço com muitos usuários e aplicações. Um sistema em produção precisa lidar com solicitações simultâneas, condições de mercado variáveis e mudanças de software. Trazer as aplicações existentes da Gnosis Chain por meio da migração testaria mais dessas dependências do que apenas os exemplos da Devcon.

O que o preço em um swap entre cadeias teria de cobrir

Um trader compara a quantidade do ativo comprado que chega após os custos. Um pool local tem sua própria taxa de negociação e impacto de preço. Uma rota pela mainnet pode oferecer liquidez mais profunda, mas pode exigir mais trabalho de execução e incorrer em custos para usá-la. Um solver decidindo entre rotas tem de pesar o melhor preço do pool contra esses custos.

Imagine que um pool local entregaria US$ 9.900 em valor de um ativo após todas as cobranças em uma ordem com valor de referência de US$ 10.000. Uma rota entre cadeias que consegue preencher a negociação por US$ 9.980 antes dos custos de execução tem até US$ 80 de margem antes que a cotação local se torne melhor. Se alcançar o melhor pool custar US$ 30, a rota entre cadeias entrega US$ 9.950. Com US$ 100 de custo adicional, a rota local oferece mais. Os números ilustram a comparação e não descrevem nenhuma cotação real.

O tamanho da ordem altera esse cálculo. Uma negociação maior pode mover o preço mais longe em um pool raso, dando ao solver mais motivo para alcançar um mercado mais profundo. Uma negociação pequena pode causar pouco impacto no preço local e deixar economias insuficientes para cobrir a rota entre cadeias. Mesmo para o mesmo par de tokens, a rota útil pode mudar ao longo de um dia à medida que a liquidez e os custos de rede se movem.

Os solvers também precisam precificar tentativas falhas e o tempo que gastam encontrando rotas. Uma operação falha pode deixar os movimentos de ativos do usuário revertidos, enquanto as partes que organizam a ordem ainda podem enfrentar despesas associadas à tentativa de execução. O efeito do design sobre o spread que um trader vê depende de como uma implementação em produção aloca esses custos e de quanta concorrência existe entre as empresas que oferecem cotações.

Para uma carteira que integra esse design, a informação importante é o que o usuário pode comparar. Uma cotação que informa o valor mínimo entregue e a rede na qual ele chegará dá ao trader uma forma de avaliar o resultado. Uma interface que enfatiza um clique ou uma assinatura mostra algo sobre conveniência, enquanto o preço e os termos de entrega mostram se a rota atende à ordem.

Uma plataforma de negociação que considere o design teria que decidir o que mostrar aos clientes sobre as dependências de uma cotação. Uma rota pode ser preenchida inteiramente onde o usuário mantém fundos. Outra poderia invocar liquidez da mainnet e depender de uma prova estar pronta dentro de um slot. Mesmo que ambas as cotações mostrem o mesmo token e o mesmo valor, elas podem ter regras de expiração diferentes e motivos diferentes para falhar. A interface teria que comunicar o valor mínimo que um cliente aceita e o que acontece se o solver não conseguir entregá-lo.

Os aplicativos também precisam definir como coletariam dados comparáveis suficientes para identificar por que uma rota custa mais. Uma série útil incluiria o mesmo par e os mesmos tamanhos de negociação nas mesmas redes, com as cotações capturadas próximas umas das outras. Uma única negociação de um par incomumente ilíquido poderia fazer a capacidade de alcançar outro mercado parecer mais valiosa do que é para ordens do dia a dia. O problema oposto pode surgir com um par importante que já é negociado barato no rollup do usuário. O preço de execução, as taxas incluídas e as condições de expiração têm que andar juntos na comparação.

A Safe torna a autoridade entre cadeias parte do problema

Um tesouro pode usar uma conta para pagamentos regulares e outra para manter ativos em uma rede diferente. Se ele altera as pessoas autorizadas a aprovar gastos, alguém precisa garantir que a mudança seja refletida onde os ativos são mantidos. Atualizações separadas criam oportunidades para que uma lista de signatários desatualizada permaneça ativa em uma conta usada com menos frequência.

A demonstração da Safe mostrou como um aplicativo poderia usar uma mudança de propriedade na mainnet dentro de uma transação coordenada envolvendo um rollup. Seu benefício depende de como o tesouro escolheu atribuir autoridade. Uma organização pode querer que a mainnet determine um conjunto compartilhado de signatários, mantendo uma política separada para uma conta de gastos local que atende a uma equipe específica.

Uma estrutura de autoridade compartilhada pode reduzir trabalho duplicado. Ela também torna o tratamento de erros mais importante, porque uma mudança pode ter consequências em vários locais. Um tesouro precisaria entender como suas contas se recuperam se uma atualização estiver errada, quem pode autorizar uma correção e como uma cadeia conectada se comporta se não conseguir obter um resultado atual.

Uma organização que avalia o design perguntaria, portanto, qual operação deseja coordenar. Ler uma lista de signatários, atualizar a propriedade e mover ativos do tesouro têm consequências diferentes. O valor de fazer uma delas dentro de uma transação compartilhada não estabelece que uma organização deva delegar todas as decisões à mesma conta.

O interesse institucional vai além do palco da Devcon. A Consensys anunciou um sistema de interoperabilidade para bancos e disse que planeja apoiar o padrão EEZ. Para um banco, a compatibilidade estaria ao lado de questões sobre quem pode usar o sistema, quais controles se aplicam a cada operação e como ele registra o resultado nos sistemas existentes.

O caso da Safe sugere um conjunto diferente de testes de produto. Uma equipe pode querer que signatários em uma rede aprovem uma operação que afeta apenas ativos em outra. Isso levanta a questão de se um signatário removido localmente ainda pode autorizar uma operação entre redes enviada anteriormente. A resposta depende de como o aplicativo lê o estado da conta e do que ele trata como o momento da autorização. Essas são questões que um aplicativo precisa especificar mesmo quando o protocolo subjacente é capaz de transportar a mensagem.

O que a demonstração do Falcon diz sobre fazer computação em outro lugar

A demonstração emblemática usou um rollup para verificar uma assinatura Falcon e forneceu esse resultado a uma ação na mainnet. A equipe relatou uma redução de 91% no consumo de gas em sua comparação com a verificação na mainnet. O exemplo tem um escopo mais restrito do que uma afirmação sobre o custo de cada transação que poderia usar o design. Ele compara uma operação especificada em dois caminhos de execução.

A oportunidade é executar uma verificação computacionalmente cara em um ambiente adequado a ela, enquanto outro contrato confia na resposta. Um aplicativo que realiza uma verificação apenas raramente pode valorizar a economia de forma diferente de um que a repete em cada pedido. A decisão também depende de como o aplicativo valida o resultado e de quais outras etapas ele precisa concluir para usá-lo.

A verificação pós-quântica é uma aplicação desse padrão. Um contrato pode precisar de outras informações de um ambiente conectado antes de poder continuar, como se uma conta tem o direito de realizar uma operação. O problema comum é tornar um resultado disponível dentro da mesma janela de execução. Verificações diferentes podem ter requisitos de computação e de prova muito diferentes.

Para um usuário, o suporte a um esquema de assinatura em um aplicativo não determina a segurança de todas as carteiras ou transações na cadeia. A demonstração abordou a verificação e a autorização para a transferência específica. Mudar as regras pelas quais as carteiras geralmente assinam transações envolveria outras decisões sobre software, compatibilidade e quais contas adotam as mudanças.

Há uma distinção semelhante para desenvolvedores que avaliam a demonstração do Falcon. O gas gasto pelo contrato ao ler um resultado de verificação e o custo de produzir esse resultado em outro lugar pertencem a ambientes de execução diferentes. Medir o primeiro captura uma restrição real para um aplicativo que, de outra forma, teria que executar a verificação na mainnet. Um serviço que decide se pode oferecer o recurso precisa contabilizar o segundo também. Ele também precisa saber se a verificação pode ser concluída sob carga, quando muitas solicitações podem competir pela mesma capacidade.

A Gnosis terá que levar os aplicativos existentes pela transição

A GnosisDAO autorizou a mudança de uma rede autônoma para um rollup EEZ por meio da GIP 153 em agosto. A migração importa porque usuários e aplicativos existentes têm saldos, endereços e dependências vinculados à cadeia ativa. Para eles, adotar um novo arranjo de execução e liquidação é uma mudança na infraestrutura que já usam.

As perguntas que um aplicativo ativo tem que responder diferem daquelas de uma rede de desenvolvimento. Seus usuários precisam saber como os saldos são transferidos, quais carteiras e provedores de infraestrutura apoiam a migração e onde obter um registro confiável de atividade enquanto a transição está em andamento. Plataformas de negociação precisam considerar a possibilidade de que as integrações se tornem disponíveis em momentos diferentes.

Um rollup que pode acessar os mercados da mainnet pode ser capaz de oferecer rotas antes de construir pools profundos próprios para cada par de tokens. Uma cadeia com liquidez estabelecida tem uma decisão diferente. Seus aplicativos podem escolher entre execução local e uma rota compartilhada, e os provedores de liquidez já presentes na cadeia podem ver como essas escolhas afetam a atividade em seus pools.

A migração também testará a diferença entre lançar uma rede e tornar um recurso o padrão para os usuários. Um primeiro bloco pode demonstrar que a nova cadeia está funcionando. Uma rota padrão para o usuário exige que carteiras, aplicativos e outros provedores usem o novo caminho na atividade comum. Reportagens anteriores descreveram uma meta em torno da virada do ano para uma implantação inicial. A atualização de novembro da Gnosis indica a primavera de 2027 como meta para a operação padrão.

A Gnosis dá aos desenvolvedores um lugar para fazer essas perguntas em relação a uma implantação com aplicativos existentes. A migração colocaria execução, suporte de carteira e procedimentos operacionais sob o mesmo cronograma, tornando possível acompanhar como a equipe lida com atrasos ou integrações parciais. Sua atualização de novembro identifica a primavera de 2027 como meta para tornar o design o padrão. As operações da Devcon ocorreram na Rollup X.

O que observar

• Rotas suportadas. Carteiras e aplicações que publicam as redes nas quais a mesma operação está disponível.
• Cotações de execução. Saída líquida comparável e taxas de ordens falhadas para negociações locais e entre redes.
• Desempenho de slots. Testes repetidos mostrando disponibilidade de provas e recuperação quando o Ethereum se reorganiza.
• Permissões de tesouraria. Escopo publicado, expiração e regras de revogação para integrações com Safe.
• Marcos da Gnosis. Testes públicos de migração e progresso rumo à meta da primavera de 2027.

Perguntas frequentes