Roteiro de interoperabilidade acelerado: Após a atualização do Fusaka, a interoperabilidade com Ethereum pode dar um salto importante

Autor: imToken

Link:

Declaração: Este artigo é uma reprodução de conteúdo, os leitores podem obter mais informações através do link original. Caso o autor tenha alguma objeção à reprodução, entre em contato conosco e faremos as alterações necessárias conforme sua solicitação. A reprodução é apenas para compartilhamento de informações, não constitui aconselhamento de investimento, nem representa o ponto de vista ou posição do Wu.

Nos artigos anteriores da série Interop, discutimos separadamente o OIF (Estrutura de Intenção) e o EIL (Camada de Interoperabilidade), que resolvem respectivamente a padronização de intenções entre blockchains (para que toda a rede compreenda o que você deseja fazer) e o problema do canal de execução (permitindo que fundos operem de forma padronizada).

No entanto, para alcançar uma experiência “de um único chain” perfeita, ainda enfrentamos o trade-off entre velocidade e confiança. Afinal, na experiência atual de interoperabilidade, ou se aceita lentidão (como o Optimistic Rollup, que precisa esperar 7 dias de desafio para confirmar a finalidade), ou se sacrifica a descentralização (dependendo da confiança na ponte multi-assinatura).

Quebrar essa “tríade impossível” depende de uma rota de interoperabilidade na Ethereum com uma base de capacidades - “Aceleração” e a finalização (Finalisation), apoiadas pela tecnologia ZK para “provas em tempo real” (leitura adicional: 《Roteiro de Interoperabilidade da Ethereum: Como desbloquear a “última milha” para adoção em larga escala》).

Na recente atualização Fusaka, uma inovação aparentemente discreta, o EIP-7825 foi a maior barreira técnica que ajudou a avançar em direção ao objetivo final.

1. Por trás da atualização Fusaka, o EIP-7825 subestimado

Em 4 de dezembro, a atualização Fusaka da Ethereum foi oficialmente ativada na mainnet, embora não tenha tido o mesmo impacto do upgrade Dencun na época, com o foco do mercado mais voltado para a expansão do Blob e PeerDAS, e a redução de custos de dados em L2.

Porém, além do burburinho, há uma proposta pouco notada: o EIP-7825, que eliminou o maior obstáculo para a implementação do zkEVM em L1 e para provas em tempo real na Ethereum, e que silenciosamente pavimentou o caminho para o desfecho da interoperabilidade.

Na atualização Fusaka, o foco principal foi na expansão de capacidade: aumento de 8x na capacidade do Blob, combinado com validação por amostragem aleatória PeerDAS, tornando os custos na trilha de Disponibilidade de Dados (DA) totalmente ultrapassados.

Claro, L2 mais barato é positivo, mas, para o roteiro de ZK de longo prazo da Ethereum, o EIP-7825 é o verdadeiro “game changer”, pois estabelece um limite de Gas por transação única (cerca de 16,78 milhões de Gas).

Sabemos que o limite de Gas por bloco na Ethereum já foi elevado para 60 milhões este ano, mas mesmo com o limite aumentado, teoricamente alguém disposto a pagar um Gas Price altíssimo ainda pode enviar uma transação “mega” altamente complexa, ocupando os 60 milhões de Gas do bloco e congestionando toda a cadeia.

Antes, isso era permitido, mas o EIP-7825 impõe uma nova restrição: independentemente do tamanho do bloco, uma única transação não pode consumir mais de 16,78 milhões de Gas.

Por que limitar o tamanho de uma transação? Na prática, essa mudança não afeta transferências comuns de usuários, mas para os Provers de ZK (geradores de provas), a diferença entre vida e morte é crucial, pois está diretamente relacionada à forma de geração de provas ZK.

Por exemplo, antes do EIP-7825, uma “mega transação” consumindo 60 milhões de Gas em um bloco obrigava o ZK Prover a processar essa transação altamente complexa sequencialmente, sem possibilidade de divisão ou paralelismo, como uma rodovia de pista única, onde um caminhão gigante lento bloqueia toda a fila de veículos menores (outras transações).

Isso praticamente condenava a “prova em tempo real” à morte — pois o tempo de geração da prova poderia levar dezenas de minutos ou mais.

Após o EIP-7825, mesmo que o limite de capacidade do bloco seja ampliado para 100 milhões de Gas, a restrição de 16,78 milhões por transação permanece. Assim, cada bloco é decomposto em pequenas tarefas previsíveis, limitadas e paralelizáveis, transformando a geração de provas ZK de um “problema lógico” difícil para uma questão de “poder de processamento de hardware” (Money Problem):

Se houver capacidade de processamento paralelo suficiente, podemos gerar provas ZK para blocos enormes em poucos segundos.

Como disse Michael, cofundador e CEO da Brevis, o EIP-7825 é uma das atualizações mais subestimadas na trajetória de expansão de 100x da ZK e da Ethereum, pois faz a “prova em tempo real” passar de um “impossível teórico” para um “problema de engenharia resolvível”. Com processamento paralelo, até blocos de 200 milhões de Gas podem ter provas geradas em segundos — uma inovação não apenas para ZK, mas para a própria camada de interoperabilidade (EIL) da Ethereum, que assim pode realizar liquidações instantâneas entre chains.

Assim, essa atualização pode parecer secundária, mas é um avanço monumental para o roteiro ZK e a expansão da Ethereum até 2026.

2. L1 zkEVM: o “âncora de confiança” na interoperabilidade da Ethereum

Por outro lado, o EIP-7825, ao limitar o tamanho de uma transação única, pavimentou o caminho físico para provas em tempo real (paralelização), mas essa é apenas uma face da moeda. A outra questão é: como a própria mainnet da Ethereum pode aproveitar essa capacidade?

Aqui entra a narrativa mais hardcore do roteiro da Ethereum — o L1 zkEVM.

Há tempos, o zkEVM é considerado o “Santo Graal” da expansão da Ethereum, não apenas por resolver gargalos de desempenho, mas por redefinir o mecanismo de confiança da blockchain. Seu núcleo é possibilitar que a mainnet gere e verifique provas ZK.

Em outras palavras, futuramente, cada bloco da Ethereum poderá gerar uma prova matemática verificável, permitindo que outros nós (especialmente nós leves e L2) confirmem a correção dos resultados sem precisar recalcular tudo — se a capacidade de gerar provas ZK for integrada ao próprio protocolo L1 (proposta de Prover), o propositor (“Proposer”) ao montar um bloco e gerar uma prova ZK, os nós verificadores não precisarão mais reexecutar as transações, apenas validar essa prova matemática mínima.

O que isso significa para a interoperabilidade?

No contexto de Interop, o L1 zkEVM tem um impacto além do mero aumento de capacidade — ele é o “âncora de confiança” de todos os L2. Se a Ethereum L1 puder gerar provas em tempo real, todos os L2 poderão consultar o estado final da L1 de forma instantânea e sem confiança, levando a duas mudanças qualitativas:

· Eliminação do período de desafio: a confirmação entre blockchains cairá de “7 dias (mecanismo OP)” para “segundos (mecanismo ZK)”;

· Interoperabilidade descentralizada: as pontes entre chains não precisarão mais de terceiros confiáveis com múltiplas assinaturas, mas confiarão na verdade matemática da mainnet Ethereum;

Essa é a base física que permite a operação real do EIL que mencionamos anteriormente — sem a finalização em tempo real da L1, a interoperabilidade entre L2s nunca deixará de ter um “fantasma de atraso”.

Com o L1 zkEVM implementado e as limitações físicas do EIP-7825 superadas, quais as ferramentas concretas para realizar essas visões?

Isso nos leva à evolução sutil das tecnologias ZK: da zkEVM para a zkVM.

3. Fusaka & EIP-7825: a libertação da rota de interoperabilidade

Se o EIP-7825 fornece uma “infraestrutura de hardware paralelizado” para ZK, a evolução do stack ZK busca por uma “arquitetura de software mais eficiente”. Pode parecer um jogo de palavras, mas há uma distinção importante e ela marca duas fases no desenvolvimento de ZK (leitura adicional: 《O “Momento de Clareira” na rota ZK: o roteiro de fim de estrada da Ethereum acelerando?》).

A primeira fase é a zkEVM, que pode ser vista como uma abordagem compatibilista ou reformista.

A lógica é tentar imitar cada instrução do EVM da Ethereum, permitindo que desenvolvedores usem diretamente código Solidity, reduzindo custos de migração e barreiras.

Assim, a maior vantagem da zkEVM é a compatibilidade com aplicações existentes na Ethereum, permitindo que desenvolvedores reutilizem a maior parte de suas infraestruturas e ferramentas (clientes de execução, exploradores, ferramentas de depuração etc.).

Por outro lado, por ter sido inicialmente projetada sem foco em ZK, a zkEVM enfrenta limites de eficiência na geração de provas — prova mais lenta, peso histórico pesado.

Já a zkVM é uma abordagem mais radical, construindo uma máquina virtual otimizada para provas ZK, baseada em arquiteturas como RISC-V ou WASM, acelerando a geração de provas, com melhor desempenho.

No entanto, ela pode perder compatibilidade com muitos recursos do EVM e a facilidade de usar ferramentas existentes (como depuradores de baixo nível). Atualmente, o movimento predominante entre projetos L2 é justamente reduzir esse peso, otimizando provas e custos, explorando arquiteturas zkVM.

Por que a atualização Fusaka é um desbloqueador?

Antes do EIP-7825, tanto zkEVM quanto zkVM enfrentavam problemas ao lidar com mega transações na Ethereum, pois não podiam dividir tarefas, levando a tempos de prova exponencialmente maiores.

Com o EIP-7825, a obrigatoriedade de dividir transações em pequenas unidades previsíveis, com ambiente paralelizado, permite que arquiteturas zkVM funcionem ao máximo, até com blocos complexos, com provas geradas em tempo real usando processamento paralelo.

O que isso significa para interoperabilidade? A popularização de zkVM, aliada ao EIP-7825, reduzirá drasticamente o custo de geração de provas. Quando a prova transnacional puder ser produzida a custos quase nulos e em velocidades de envio de e-mails, as pontes tradicionais desaparecerão, dando lugar a protocolos de mensagens universais na camada base.

Palavra final

Como reiterado nas séries anteriores de artigos sobre Interop, o objetivo final não é apenas “cross-chain de ativos”, mas uma visão mais ampla de capacidades sistêmicas: comunicação de dados entre chains, execução lógica, experiência do usuário, segurança e consenso.

Nesse sentido, Interop será a linguagem universal dos protocolos do ecossistema Ethereum no futuro. Seu valor não está apenas na transferência de valor, mas na partilha de lógica, e o papel do ZK é garantir a correção da execução, suportando validações de estado em tempo real, tornando chamadas entre domínios “ousadas e possíveis”. Pode-se dizer que, sem ZK em tempo real, dificilmente haverá uma verdadeira experiência de Interop utilizável.

Assim, com a ativação silenciosa do EIP-7825 na Fusaka e a concretização do L1 zkEVM, estamos cada vez mais próximos do fim: execução, liquidação e provas sendo completamente abstratas ao usuário, que não perceberá a existência da cadeia.

Esse é o futuro que todos esperamos para a interoperabilidade.