O ecossistema zkEVM passou por um ano de aceleração abrangente em termos de latência. O tempo para criar prova para um bloco Ethereum caiu de 16 minutos para apenas 16 segundos; os custos diminuíram 45 vezes; e os zkVM participantes agora podem criar provas para 99% dos blocos na mainnet em menos de 10 segundos ao rodar em hardware alvo.
No dia 18/12, a Ethereum Foundation (EF) anunciou oficialmente a vitória: a criação de provas em tempo real tornou-se viável. Os gargalos de desempenho fundamentais foram resolvidos. No entanto, a fase mais difícil realmente começou, pois a velocidade, se não acompanhada de solidez matemática, se tornará um risco em vez de uma vantagem. Preocupantemente, a base matemática de muitos zkEVM baseados em STARK tem apresentado silenciosamente pontos de falha nos últimos meses.
Objetivo de “prova em tempo real” e a mudança de paradigma em segurança
Em julho, a EF estabeleceu um objetivo oficial para “provas em tempo real”, não apenas em relação à latência, mas também incluindo hardware, energia, abertura e segurança. Especificamente, o sistema deve provar pelo menos 99% dos blocos da mainnet dentro de 10 segundos, em hardware no valor de cerca de 100.000 USD, consumindo não mais do que 10 kW de eletricidade, utilizando código aberto completo, alcançando um nível de segurança de 128 bits e um tamanho de prova que não ultrapasse 300 kilobytes.
A publicação de 18/12 afirma que o ecossistema alcançou este objetivo de desempenho, com base nos dados do site de benchmark EthProofs.
O conceito de “tempo real” aqui é definido relativamente ao ciclo de slot de 12 segundos do Ethereum e cerca de 1,5 segundos para a transmissão de blocos. Em outras palavras, a prova deve estar pronta rápido o suficiente para que o validador possa verificar sem interromper a liveness (liveness) da rede.
No entanto, a EF rapidamente mudou o foco de throughput para a solidez (soundness), e essa mudança é rigorosa. Muitos zkEVM baseados em STARK alcançaram um nível de segurança publicamente anunciado, baseando-se em hipóteses matemáticas não comprovadas.
Nos últimos meses, algumas dessas hipóteses, especialmente as suposições do “proximity gap” nos testes de baixo grau (low-degree tests) do SNARK e STARK baseados em funções hash, foram quebradas matematicamente. Isso diminui significativamente o nível de segurança real dos conjuntos de parâmetros que antes dependiam delas.
A EF enfatiza que, com o L1, o único objetivo aceitável é “segurança comprovável”, e não “segurança se a hipótese X for verdadeira”.
O nível de 128 bits foi escolhido como padrão, adequado para organizações de padronização de criptografia convencionais e documentos acadêmicos sobre sistemas de longa duração, assim como os registros computacionais no mundo real mostram que 128 bits estão além da capacidade de ataque prática.
A prioridade pela solidez em vez da velocidade reflete uma diferença fundamental. Se um atacante puder falsificar provas zkEVM, não apenas esgotará um contrato, mas poderá cunhar tokens arbitrários, reescrever o estado L1 e fazer todo o sistema “mentir”. Portanto, a EF considera que uma alta margem de segurança é uma condição inegociável para qualquer zkEVM utilizado em L1.
Roteiro de três marcos
EF apresentou um roteiro claro com três marcos obrigatórios.
Primeiro, até o final de fevereiro de 2026, todas as equipes zkEVM envolvidas devem integrar seu sistema de provas e circuitos ao “soundcalc”, uma ferramenta mantida pela EF para calcular o nível de segurança com base nos limites da análise criptográfica atual e nos parâmetros de cada esquema.
O objetivo é estabelecer uma “medida comum”. Em vez de cada equipe declarar seu nível de bit-security com base em suposições próprias, o soundcalc se tornará uma ferramenta padrão, que pode ser atualizada à medida que novos métodos de ataque surgem.
Em segundo lugar, o marco “Glamsterdam” no final de maio de 2026 exige a obtenção de pelo menos 100-bits de segurança que podem ser comprovados através do soundcalc, com o tamanho da prova não excedendo 600 kilobytes, juntamente com uma explicação pública e concisa sobre a arquitetura recursiva e os argumentos básicos para sua solidez.
Isto ajusta implicitamente o objetivo inicial de 128 bits para a fase de implementação inicial, considerando 100 bits como um nível intermédio.
Terça-feira, “H-star” no final de 2026 é o padrão completo: segurança de 128 bits que pode ser provada através do soundcalc, tamanho máximo da prova de 300 kilobytes, e uma argumentação de segurança formal para toda a estrutura recursiva. Neste estágio, o desafio não é mais puramente técnico, mas se inclina fortemente para métodos formais e provas criptográficas.
As alavancas técnicas
EF indica uma série de ferramentas para materializar o objetivo de 128 bits com uma prova abaixo de 300 kilobytes. Destaca-se o WHIR, um novo teste de proximidade Reed–Solomon, que também atua como um esquema de compromisso polinomial multilinear (multilinear polynomial commitment).
A WHIR fornece segurança transparente, pós-quântica, gerando provas menores e verificações mais rápidas em comparação com esquemas FRI tradicionais no mesmo nível de segurança. O benchmark de 128 bits mostra que o tamanho da prova cai cerca de 1,95 vezes, enquanto a velocidade de verificação é muito mais rápida em comparação com a estrutura básica.
EF também mencionou o JaggedPCS, um conjunto de técnicas que ajuda a evitar o (padding) excessivo ao codificar o trace em um polinômio, permitindo que o prover cair o desperdício computacional enquanto mantém o compromisso sucinto.
Além disso, há o “grinding”, que significa a busca brute-force no espaço aleatório do protocolo para obter uma prova mais barata ou menor que ainda se enquadre nos limites de segurança, juntamente com arquiteturas recursivas projetadas de forma rigorosa, onde várias provas pequenas são consolidadas em uma prova final com um argumento sólido.
As técnicas de álgebra polinomial e recursiva cada vez mais complexas estão a ser utilizadas para reduzir as provas após a elevação do nível de segurança para 128 bits.
Estudos independentes como o Whirlaway utilizam WHIR para construir STARKs multilineares de forma mais eficiente, enquanto outras estruturas de compromisso polinomial experimentais estão sendo desenvolvidas a partir de esquemas de disponibilidade de dados.
A matemática está avançando muito rapidamente, mas ao mesmo tempo também está se afastando das suposições que eram consideradas seguras apenas alguns meses atrás.
O que mudou e as perguntas em aberto
Se a prova estiver sempre pronta em até 10 segundos e mantiver um tamanho abaixo de 300 kilobytes, Ethereum pode aumentar o limite de gás sem forçar o validador a reexecutar toda a transação. Em vez disso, eles precisam apenas verificar uma pequena prova, permitindo expandir a capacidade do bloco enquanto mantém a capacidade de staking em casa.
Esta é a razão pela qual o EF nas postagens anteriores associou firmemente a latência e a energia com o orçamento de “home proving” como 10 kW e hardware abaixo de 100.000 USD.
A combinação de alta segurança e provas pequenas é o que faz um “L1 zkEVM” se tornar uma camada de pagamento confiável. Se essas provas forem rápidas e atingirem 128 bits de segurança que podem ser comprovadas, as L2 e zk-rollups poderão reutilizar o mesmo mecanismo através de pré-compilações, tornando a fronteira entre “rollup” e “execução L1” mais flexível, sendo configurável em vez de rigidamente separada.
Atualmente, a prova em tempo real existe apenas na forma de benchmark off-chain. Os dados sobre latência e custo vêm de configurações de hardware e carga de trabalho selecionadas no EthProofs. A distância entre isso e o fato de que milhares de validadores independentes realmente executam um provedor em casa ainda é considerável.
A questão da segurança ainda não está resolvida. A razão pela qual o soundcalc foi criado é porque os parâmetros de segurança do STARK e do SNARK se baseiam em funções de hash que mudam continuamente à medida que as hipóteses são refutadas. Resultados recentes redesenharam os limites entre “certamente seguro”, “seguro sob hipótese” e “certamente inseguro”, o que significa que as configurações “100-bit” de hoje podem precisar ser ajustadas no futuro.
Não está claro se todas as grandes equipas de zkEVM conseguirão atingir 100-bit em maio de 2026 e 128-bit até ao final de 2026, enquanto ainda cumprem o limite de tamanho das provas, ou se algumas aceitarão margens de segurança mais baixas, baseando-se em suposições mais pesadas, ou prolongarão a verificação off-chain.
O maior desafio pode não estar na matemática ou na GPU, mas sim na formalização e auditoria de toda a arquitetura recursiva. A EF reconhece que os zkEVM frequentemente combinam muitos circuitos com uma quantidade significativa de “código de cola”, e a documentação, bem como a comprovação da solidez desses stacks personalizados, é vital.
Isso abre um longo caminho para projetos como Verified-zkEVM e frameworks de verificação de forma, que ainda estão em uma fase inicial e não são uniformes entre os ecossistemas.
Há um ano, a grande questão era se o zkEVM poderia provar rápido o suficiente. Essa pergunta já tem resposta.
Agora, a questão é se podem provar ser suficientemente robustas, em um nível de segurança que não dependa de hipóteses que possam desmoronar amanhã, com provas pequenas o suficiente para se espalhar na rede P2P do Ethereum, e com uma arquitetura recursiva que seja formalmente verificada de forma suficientemente rigorosa para ancorar centenas de bilhões de dólares em valor.
A corrida de desempenho terminou.
A corrida pela segurança apenas começou.
Vương Tiễn
