Ethereum Foundation estabelece o padrão de segurança de 128 bits: da corrida pela velocidade à corrida pela precisão

Do tempo da correção: mudança de paradigma

Ao longo do último ano, o ecossistema zkEVM lutou principalmente contra atrasos. O progresso foi impressionante: a geração de provas para blocos do Ethereum reduziu-se de 16 minutos para 16 segundos, os custos caíram 45 vezes, e as zkVMs participantes atualmente produzem provas para 99% dos blocos da mainnet em menos de 10 segundos no hardware alvo.

Em 18 de dezembro, a Ethereum Foundation anunciou um resultado revolucionário: a geração de provas em tempo real realmente funciona. No entanto, esse momento de triunfo revela-se um ponto de inflexão. Os gargalos de desempenho foram eliminados, mas isso gerou novas questões mais profundas. Velocidade sem correção não é uma vantagem técnica, mas uma ameaça sistêmica. Ao mesmo tempo, a matemática por trás de muitas zkEVMs baseadas em STARKs há meses se desmorona silenciosamente – exatamente por isso, a mudança de foco de desempenho para segurança não é apenas recomendada, mas inevitável.

Diferença matemática versus problema de premissas

Muitas zkEVMs baseadas em STARKs até agora dependiam de premissas matemáticas não comprovadas para alcançar o nível declarado de segurança. Nos últimos meses, especialmente durante trabalhos de pesquisa, premissas como a “proximity gap” usadas em testes de baixo grau de SNARKs e STARKs baseados em hashes foram refutadas matematicamente. Essa descoberta tem consequências importantes: a segurança efetiva em bits dos conjuntos de parâmetros, que dependiam dessas premissas, foi significativamente reduzida.

A Ethereum Foundation deixou claro seu posicionamento: a única solução aceitável para aplicações L1 é “segurança comprovada”, e não “segurança condicional que assume que a premissa X é verdadeira”. Essa diferença matemática entre especificação e prova real é fundamental para sistemas que lidam com centenas de bilhões de dólares em valor.

O objetivo estabelecido é segurança de 128 bits – um padrão alinhado às principais diretrizes criptográficas e à literatura científica sobre longevidade de sistemas criptográficos. De forma realista, 128 bits estão além do alcance prático de atacantes, de acordo com recordes de cálculo atuais.

Roteiro de três etapas: da implementação à verificação formal

A Ethereum Foundation apresentou um roteiro claro com três marcos rígidos:

Fase primeira – final de fevereiro de 2026:
Cada equipe zkEVM combina seu sistema de prova e circuitos em “soundcalc” – uma ferramenta mantida pela EF que calcula a segurança estimada com base nos limites atuais de criptanálise e nos parâmetros do esquema. Isso fornece uma medida comum de segurança, substituindo a situação anterior em que cada equipe fornecia seus próprios números de segurança em bits. O soundcalc torna-se um calculador canônico, atualizado à medida que novas vulnerabilidades são descobertas.

Fase segunda – “Glamsterdam” até o final de maio de 2026:
Requer pelo menos 100 bits de segurança comprovada pelo soundcalc, provas com tamanho não superior a 600 KB, e uma explicação pública da arquitetura de recursão de cada equipe com um esboço da prova de sua correção. Essa fase é de transição, abandonando a versão inicial de 128 bits para uma implementação precoce.

Fase terceira – “H-star” até o final de 2026:
Meta completa: segurança comprovada de 128 bits, provas com tamanho até 300 KB, e um argumento formal de segurança para a topologia de recursão. Nesta etapa, não se trata mais de engenharia, mas de métodos formais e provas criptográficas rigorosas.

Arsenal técnico: de WHIR à topologia de recursão

A Ethereum Foundation aponta ferramentas específicas que possibilitam alcançar a segurança de 128 bits mantendo provas compactas abaixo de 300 KB.

WHIR – novo teste de proximidade de Reed-Solomon – também funciona como esquema de compromisso para polinômios multilinha. Oferece transparência, segurança resistente a cálculos quânticos, e gera provas menores e mais rápidas na verificação do que esquemas mais antigos como FRI, com o mesmo nível de segurança. Benchmarks em segurança de 128 bits mostram provas cerca de 1,95 vezes menores e verificações várias vezes mais rápidas do que as construções base.

“JaggedPCS” é um conjunto de técnicas que evita preenchimento excessivo ao codificar traços como polinômios – geradores de provas economizam trabalho desnecessário, mantendo compromissos concisos.

“Grinding” – busca exaustiva de aleatoriedade do protocolo – permite encontrar provas mais baratas ou menores, mantendo limites de correção.

“Topologia de recursão bem organizada” refere-se a esquemas em camadas, onde múltiplas provas menores se agregam em uma prova final com justificativa de correção. Projetos independentes como Whirlaway usam WHIR para construir STARKs multilinha com maior eficiência.

Implicações práticas e questões em aberto

Se as provas estiverem consistentemente prontas em 10 segundos e tiverem tamanho abaixo de 300 KB, o Ethereum ganhará capacidade de aumentar o limite de gás sem forçar validadores a reexecutar toda transação. Validadores, ao invés disso, verificarão provas minúsculas, permitindo aumentar a capacidade dos blocos e manter a viabilidade do staking doméstico – por isso, o orçamento de “home proving” é de 10 kW de energia e hardware abaixo de 100.000 dólares.

Essa combinação de margens de segurança elevadas e provas compactas transforma o “L1 zkEVM” em uma camada de liquidação confiável. Se forem rápidas e confirmadas a nível de 128 bits, L2s e zk-rollups poderão usar a mesma infraestrutura via pré-compilações – a fronteira entre “rollup” e “execução L1” torna-se mais uma questão de configuração do que uma limitação arquitetônica rígida.

Ao mesmo tempo, permanecem incertezas relevantes. A geração de provas em tempo real hoje é um benchmark off-chain, não uma realidade on-chain. Os números de atrasos e custos vêm de configurações de hardware selecionadas da EthProofs. A lacuna entre isso e milhares de validadores independentes que realmente executam geradores de provas em casa continua real.

A história da segurança está em fase de mudanças. O soundcalc existe porque os parâmetros de STARKs e SNARKs baseados em hashes evoluem continuamente à medida que premissas são refutadas. Os últimos resultados redefiniram novamente a fronteira entre regimes “definitivamente seguros”, “seguro por padrão” e “definitivamente perigosos”, o que significa que as configurações atuais de 100 bits podem ser revistas com novos ataques.

Não é certo se todas as principais equipes zkEVM alcançarão segurança comprovada de 100 bits até maio de 2026 e 128 bits até dezembro de 2026, permanecendo abaixo dos limites de tamanho, ou se algumas aceitarão margens menores, dependerão de premissas mais pesadas ou prolongarão a verificação off-chain.

A maior barreira inicial pode não ser matemática ou potência de GPU, mas a formalização e auditoria de arquiteturas recursivas completas. A EF reconhece que diferentes zkEVMs combinam circuitos diversos com “glue code” significativo, e documentar a correção desses stacks não convencionais é fundamental. Isso abre um amplo campo de trabalho para projetos como Verified-zkEVM e frameworks de verificação formal, que ainda estão em estágio inicial e com desenvolvimento desigual nos diferentes ecossistemas.

Conclusões: fim de uma corrida, início de outra

Há um ano, a questão era: os zkEVMs podem gerar provas suficientemente rápidas? A resposta é conhecida. A nova questão é: podem gerá-las com correção suficiente, a um nível de segurança que não dependa de premissas que podem ruir amanhã, com provas pequenas o bastante para se propagar pela rede P2P do Ethereum, e com arquiteturas recursivas formalmente verificadas para proteger centenas de bilhões em valor?

A corrida por desempenho acabou. A corrida por correção matemática e segurança começa a sério.