Por que a Ethereum precisa, com urgência, migrar para ZK

A dúvida mais frequente atualmente é: Como devemos interpretar a narrativa do Ethereum neste momento?

Em 2017, o Ethereum era sinônimo de ICOs e do conceito de computador mundial. Em 2021, a atenção se voltou ao DeFi e ao papel do Ethereum como camada de liquidação financeira. Agora, olhando para 2025, ainda não surgiu uma narrativa que alcance o impacto dos ciclos anteriores.

Alguns consideram o ETF e o Staking ETF como narrativas parciais, mas esses avanços não estão sob o controle direto da comunidade de desenvolvedores do Ethereum. Se há um novo protagonista, é o ZK.

O Ethereum é, sem dúvida, a blockchain pública que mais investe em tecnologia ZK no universo cripto.

Recentemente, o Vitalik anunciou com entusiasmo no Twitter que o ZKEVM entrou em fase Alpha.

Por que o Ethereum aposta tanto no ZK?

O TPS atual do Ethereum já é elevado, com picos teóricos acima de 200 TPS—resultado, principalmente, de sucessivos aumentos no limite de gas.

Porém, aumentar o limite de gas tem um custo e um limite. Quanto maior o limite, maior o custo dos servidores necessários para os nós operarem.

Ao mesmo tempo, o Ethereum busca preservar sua descentralização, por isso não pode exigir hardware muito avançado dos nós (para referência, um servidor Solana é de 5 a 10 vezes mais caro que um servidor Ethereum).

Por isso, a integração total do ZK na mainnet é fundamental. Não se trata apenas de lançar algumas Layer 2 ZK—é uma integração ZK completa na própria Layer 1.

O que o ZK agrega?

Os nós do Ethereum poderão simplesmente validar provas ZK, em vez de conferir cada transação individualmente.

Imagine como se fosse corrigir provas: os nós são os professores e as transações, as avaliações dos alunos.

A correção manual é demorada, mas com gabaritos (integração ZK), uma máquina pode calcular as notas instantaneamente. O trabalho do professor diminui drasticamente.

Assim, quem corrigia 50 provas pode agora lidar com 1.000—a mesma pessoa, mas com eficiência exponencialmente maior.

É por isso que o Ethereum precisa do ZK na mainnet antes de aumentar ainda mais o limite de gas com segurança.

A integração ZK não é o que eleva diretamente o TPS—ela é o pré-requisito. O ganho de performance ainda depende do aumento do limite de gas, mas com ZK, os nós não precisarão investir tanto em hardware, tornando a atualização muito menos onerosa.

Com o recente upgrade Fusaka—em especial o PeerDAS—o desempenho melhorou, aproximando ainda mais o Ethereum da integração ZK na mainnet. É isso que empolga Vitalik.

Imagine a mainnet com TPS acima de 1.000—isso sim seria uma nova narrativa poderosa para o Ethereum.

Alguns questionam: Se o próprio Ethereum implementar ZK-EVM na mainnet, as demais equipes ZK ainda terão relevância?

Sim—elas continuam sendo essenciais.

Por quê?

Primeiro, a engenharia ZK é um dos projetos mais complexos do setor, comparável ao FHE. Exige profissionais altamente qualificados em criptografia.

A Ethereum Foundation possui alguns recursos, mas o espírito open source é coletivo. O Ethereum depende de várias equipes ZK terceirizadas para experimentação e inovação, recompensando-as com amplo suporte.

Segundo, existem quatro tipos de ZK-EVM, do tipo 1 ao tipo 4. Equipes como Polygon, Scroll, ZKsync e Taiko assumiram diferentes tipos—dividindo o trabalho.

Também existe o ZK-VM, como o Brevis.

Na verdade, o ZK-VM tem uma posição ainda mais sólida que o ZK-EVM.

Por quê? Porque entre os quatro principais tipos de ZK-EVM, um provavelmente será escolhido como solução mais eficiente e integrará o ZK-EVM oficial da mainnet do Ethereum, deixando os outros três em segundo plano.

Mas o ZK-VM não é compatível com EVM, então sempre fará parte do ecossistema ampliado do Ethereum.

E como as VMs não têm as limitações do EVM, seu desempenho pode ser muito superior. O ZK-EVM do Ethereum não representa ameaça—na verdade, a comunidade Ethereum incentiva esse tipo de inovação.

Por exemplo, Vitalik elogiou publicamente o desempenho do ZK-VM do Brevis e aguarda sua entrada no universo ZK-EVM.

E quanto à Layer 2? Pode haver algum impacto, mas é limitado.

Vitalik já afirmou ser melhor manter ZK e Layer 2 separados ao discutir Polygon.

Com ZK na Layer 1, parte dos usuários provavelmente migrará da Layer 2 ZK, pois uma Layer 1 mais barata reduz o incentivo para usar Layer 2.

Mas pense assim: Layer 1 é a base, Layer 2 é o arranha-céu. Quanto mais forte a base, melhor. Portanto, se a Layer 1 adotar ZK, a Layer 2 também terá custos menores e será beneficiada.

No mesmo post, Vitalik citou o trabalho do ZK-VM do Brevis, ressaltando que grande parte da pesquisa ZK deles não se limita à Layer 2—“A pesquisa ZK e a pesquisa em Layer 2 devem permanecer separadas.”

Por exemplo, eles operam um marketplace de computação ZK, ajudam hooks do Uniswap a implementar distribuição de recompensas baseada em ZK e promovem inovação voltada a aplicações.

Em resumo, o Ethereum está ativo há 10 anos, e a demanda por integração ZK existe há cinco ou seis anos. Após anos de dedicação, a integração ZK finalmente alcançou a fase Alpha—um marco possível graças ao empenho contínuo do Ethereum e de diversas equipes ZK terceirizadas, como Brevis e Polygon.

Isenção de responsabilidade:

1. Este artigo foi republicado de [Medium] e os direitos autorais pertencem ao autor original [Ebunker]. Caso tenha dúvidas sobre esta republicação, entre em contato com a equipe do Gate Learn para resolução imediata conforme os procedimentos padrão.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são de responsabilidade exclusiva do autor e não constituem aconselhamento de investimento.
3. As versões deste artigo em outros idiomas foram traduzidas pela equipe Gate Learn. Exceto quando Gate for citado, não copie, distribua ou plagie o conteúdo traduzido.