Um cartaz do lançamento do Polygon zkEVM provocou uma grande discussão entre os fundadores da cadeia pública sobre escalabilidade

Em 26 de fevereiro, um cartaz promocional anunciando o lançamento da mainnet do Polygon zkEVM provocou um debate sobre o uso da equivalência do termo “Ethereum”, e Ye Zhang, o fundador da Scroll, apontou solenemente que o Polygon zkEVM não tem esse recurso. Em retrospetiva, Ryan Wyatt, chefe da Polygon Labs, respondeu que isso era mais o resultado da má comunicação entre profissionais de marketing e técnicos dentro da equipe.

Esta não é uma questão trivial, e a extensão da eficácia estará mesmo diretamente relacionada com o desempenho e escalabilidade L1/L2, apenas dois dias atrás, Solana cocriador Toly publicou um artigo que ZK L2s não será a melhor solução para resolver escalabilidade.

No dia 27 de fevereiro, a equipe técnica do Polygon, protagonista deste evento, também respondeu ativamente ao princípio de funcionamento do zkRollup, explicando para onde a escalabilidade do zkRollup está apontando.

Em 1º de março, Solana também anunciou um “plano para melhorar a atualização da rede” para recarregar a bandeira do assassino do Ethereum, mas seu mecanismo operacional não foi fundamentalmente inovado após várias interrupções, e é mais como uma otimização pós-crise, que também lança uma sombra sobre a substituição do Ethereum por L1 de alto desempenho.

Este artigo combinará os tweets de vários fundadores de L1/L2 para revelar os meandros da grande discussão sobre o desempenho das cadeias públicas.

Origens: O Debate sobre a Equivalência EVM

O zkEVM da Polygon, estritamente falando, é um mecanismo zk VM, que é consistente com a mainnet Ethereum no nível L2 através do mapeamento, e a introdução da tecnologia zk é a razão pela qual ela é chamada de zk VM, e em um sentido não estrito, desde que possa manter a sincronização, então é inofensivo chamá-la de zk EVM.

No entanto, de acordo com Ye Zhang, o fundador da Scroll, a equivalência EVM não é exatamente a mesma que a equivalência Ethereum, porque esta última precisa ser pelo menos consistente com a mainnet Ethereum em termos de armazenamento de dados.

De uma perspetiva mais ampla, nenhuma das atuais pontes de cadeia cruzada L2s ou Ethereum pode reivindicar ser equivalente ao Ethereum, e as pilhas mais modulares e complexas do Ethereum trarão compatibilidade mais difícil.

Um exemplo simples pode ser dado para entender intuitivamente a diferença entre os dois, o Otimismo lida com a diferença entre os dois no planejamento de produto, em sua opinião:

Equivalência EVM: Principalmente da perspetiva dos desenvolvedores dApp, sua experiência em OVM não é diferente da de desenvolver dApps na mainnet Ethereum, então OVM tem equivalência EVM;

Equivalência Ethereum: Principalmente da perspetiva dos desenvolvedores de protocolo, é necessário manter um alto grau de consistência com o Ethereum em termos de cliente, camada de comunicação, camada de consenso e camada de execução.

Além do debate sobre equivalência de EVM, também deve ser notado que a controvérsia sobre escalabilidade é atualmente o foco da batalha entre L2 baseado em Ethereum e L1 de alto desempenho.

Antecedente: Dúvidas de Solana sobre a escalabilidade do ZK

Em 24 de fevereiro, dois dias antes do lançamento do trailer do Polygon zkEVM, o cocriador de Solana, Toly, postou um post no Twitter questionando a capacidade do ZK L2s de resolver o problema do escalonamento da cadeia pública, a fim de compensar as dúvidas do público sobre o mecanismo de operação de Solana.

Os seus principais pontos são os seguintes:

• O carregamento de dados em tempo real para a cadeia requer capacidades de execução sequencial estáveis;
• O esquema de prova ZK é válido, desde que a soma do tempo de geração da prova ZK + tempo de verificação seja menor do que o tempo de execução em tempo real;
• A solução ZK não pode processar grandes quantidades de dados em tempo real, e só pode executar agregação intermitente, mas não pode manter o status em tempo real do estado on-chain;

Portanto, a solução ZK é mais adequada para cenários únicos e de baixa frequência, como liquidação em lote, enquanto o Solana ainda é necessário para a escalabilidade da cadeia pública.

Infelizmente, Solana sofreu uma grave interrupção em 25 de fevereiro, e a comunidade, engenheiros e validadores recuperaram a rede principal após dois reboots, e o vazamento da casa coincidiu com a chuva durante a noite, e os “do-gooders” aproveitaram a oportunidade para questionar o mecanismo de Solana, com o usuário do Twitter DBCryptoX argumentando que “90-95% das transações no Solana contêm mensagens de validação e votação on-chain”.

Solana usa um mecanismo de consenso PoS, que se autodenomina um mecanismo de “Prova de História”. O PoH permite que a rede seja executada mais rapidamente porque os nós não precisam se comunicar para validar um bloco, e o PoH permite que os validadores identifiquem eventos em um determinado momento.

Por um lado, esse mecanismo traz um alto grau de uniformidade, trazendo o TPS muito além da rede principal Ethereum, mas, por outro lado, ele ocupa muito espaço de bloco on-chain, e uma vez que algo dá errado, é difícil chegar a um consenso para restaurar a rede. Pelo menos um evento de interrupção da rede principal ocorreu por ano durante pelo menos 2021-2023.

O evento de interrupção contribuiu com uma lição negativa para a escalabilidade de Solana. O cocriador do Solana, Toly, acredita que o provador no ZK L2 não pode ser executado em tempo real, então a execução on-chain final do ZK L2s não estará na ordem estabelecida, então os usuários podem executar nós completos para aumentar a carga na rede, ou confiar em alguns nós honestos para melhorar a eficiência e ir centralizado.

No entanto, acontece que o L1 Solana de alto desempenho não parece resolver o problema de execução em tempo real, afinal, uma rede colapsada acabará perdendo a ordem estabelecida, e os dados recuperados à força se tornarão um “consenso” artificial em vez do estado espontâneo da própria rede.

Consequências: A escalabilidade do Polygon mente criticamente

O Polygon zkEVM foi primeiro questionado por Solana e depois anunciou que houve um incidente oolong, que era suspeito de ser pouco profissional e enganoso. Então, o desenvolvedor, Jordi Baylina, saltou e aceitou o desafio do profissionalismo, concentrando-se em explicar que o provador não é o fator limitante para ZK L2s, e o verdadeiro obstáculo é DA (disponibilidade de dados).

O primeiro é o processo de operação do zkRollup, que pode ser dividido em três etapas, como mostra a figura abaixo:

Mantendo a rede em sincronia, independentemente da arquitetura do rollup, desde que os dados em L2 estejam envolvidos, ele precisa provar a validade do lote de mensagens para que elas possam ser confirmadas quando finalmente forem retornadas a L1.

A geração de provas agregadas requer o uso do esquema de prova zk (ZKP), que pode ser acelerado por processamento paralelo, mas a geração de provas em lote em si leva algum tempo. É ainda possível conceber mecanismos dinâmicos onde o número de provadores de rede pode ser aumentado ou diminuído dependendo das necessidades da rede.

Uma vez que o ZKP está em execução, uma rede completa à prova de árvore é gerada para os dados, o que permite que diferentes servidores verifiquem os dados e enviem os resultados para a cadeia L1.

O segundo é a questão do custo, o mais crítico dos quais é o custo de prova, o software, hardware e tempo de chamada de operação ZK será incluído no fator de cálculo pela taxa TX (transação) e, finalmente, refletido na taxa de gás da rede, e diferentes algoritmos, como STARK / SNARK / FLONK, etc., otimizarão muito o custo de uso da rede. O ponto-chave é que o carregamento de dados não precisa ser realizado sequencialmente para facilitar a paralelização.

Portanto, o Prover que Solana acredita não pode impedir o funcionamento das provas ZK, e o verdadeiro obstáculo é a disponibilidade de dados, que precisa ser resolvida por ETH 2.0, DankSharding, EIP4844 e outras soluções.

Conclusão: Para onde vai a escalabilidade

O debate em torno do Polygon zkEVM continuará, e a chave será até que ponto o zk EVM pode resolver o atual problema de escalabilidade, que será o próximo teste para L1/L2s enfrentar dApps e usuários em grande escala.