Resumo: Vitalik afirma que o uso de pré-compilados e da EVM para oferecer suporte à criptografia já esbarrou em um gargalo de capacidade. A proposta EIP-8288 pretende transferir a verificação para fora da thread principal, mantendo na cadeia apenas uma prova recursiva.
Em 19 de outubro, o cofundador do Ethereum, Vitalik Buterin, continuou a explicar a abordagem da EIP-8288 na plataforma X. Ele apresentou uma restrição concreta: mesmo com PeerDAS e blocks-in-blobs, o throughput de dados começa a enfrentar limitações práticas acima de aproximadamente 8 MB/s.
No contexto do suporte criptográfico, esta frase aponta para um conflito iminente. O Ethereum precisa aceitar um número cada vez maior de esquemas de assinatura e sistemas de prova, mas, se cada recurso criptográfico for incorporado à cadeia por meio de contratos pré-compilados ou da execução na EVM, o espaço de calldata ocupado continuará crescendo. 8 MB/s não é um limite teórico distante: é uma barreira física com a qual a expansão da thread principal está se deparando.
Pré-compilados e EVM: porque já não são a solução ideal
Os contratos pré-compilados foram uma solução pragmática para o #Ethereum introduzir operações criptográficas dispendiosas: cálculos específicos eram implementados como funções nativas da cadeia, contornando o custo da EVM, byte a byte. O problema é que os dados processados pelos contratos pré-compilados e pela EVM normalmente também têm de ser gravados nos blocos do Ethereum, ocupando espaço de calldata.
Cada novo esquema criptográfico implica um novo pré-compilado ou um novo trecho de lógica de verificação na EVM. A complexidade do protocolo aumenta, o espaço ocupado pela calldata aumenta, mas a capacidade de processamento da thread principal é limitada. O PeerDAS e os blobs já separaram parcialmente a disponibilidade de dados do caminho principal de execução, mas, segundo Vitalik, mesmo com estas medidas, continuará a haver pressão acima dos 8 MB/s.
Os contratos pré-compilados resolvem o problema da eficiência de uma verificação individual, mas não o do crescimento contínuo do volume total de verificações. Cada nova forma de criptografia acrescenta mais dados à carga da thread principal.
EIP-8288: retirar a verificação da thread principal
A alternativa proposta por Vitalik consiste em retirar os cálculos criptográficos pesados do caminho de execução on-chain.
No caso de cálculos pesados e autónomos, o utilizador ou o cliente executa-os localmente, gera uma prova STARK e, em seguida, submete-a através do mecanismo de agregação recursiva da EIP-8288. A cadeia deixa de receber os dados originais e o processo de cálculo completo, verificando apenas duas coisas: que o cálculo foi realmente executado e que o resultado está correto.
A agregação recursiva é o elemento central deste mecanismo. Os nós da mempool recolhem as provas anexadas às transações e agregam-nas e comprimem-nas recursivamente antes da inclusão no bloco. No fim, resta apenas uma prova agregada para todo o bloco, que representa a validade de todas as condições criptográficas de que dependem as transações nele incluídas. O trabalho dos validadores da cadeia principal passa de verificar cada prova completa, uma a uma, a confirmar se uma única prova recursiva é válida.
Isto dá continuidade à lógica de separação que tem caracterizado o Ethereum nos últimos anos: os rollups transferem a execução para a L2, os blobs separam os dados da execução e o PeerDAS reduz ainda mais a carga dos nós no que diz respeito à disponibilidade de dados. O que a EIP-8288 pretende separar é a própria verificação.
Vitalik também corrige uma ideia recorrente. O Ethereum não deve ser visto apenas como uma blockchain, mas como um «computador mundial criptográfico». A implicação é que a thread principal não tem de executar pessoalmente todos os cálculos; cabe-lhe fornecer a verificação final e fiável dos resultados. Os dados e a execução que não precisam de passar pela thread principal não devem ocupá-la.
Pós-quântica e privacidade: sem separação, o custo é incomportável
A motivação imediata para a EIP-8288 vem de dois tipos de custos que se estão a tornar impossíveis de ignorar.
No campo da criptografia pós-quântica, as assinaturas pós-quânticas baseadas em hash têm cerca de 2 a 3 KB, e uma única verificação pode consumir entre 150 000 e 200 000 unidades de gas; as provas STARK podem ultrapassar os 128 KB, e verificá-las diretamente on-chain custa milhões de unidades de gas. Se cada transação incluir uma prova completa resistente a ataques quânticos e todos os nós a verificarem individualmente, o custo da atualização de segurança será demasiado elevado para uma utilização em larga escala.
As transações privadas enfrentam um problema estrutural semelhante. Muitos sistemas de privacidade já são viáveis do ponto de vista criptográfico; o verdadeiro obstáculo é o custo das provas. Exigir simultaneamente privacidade e segurança pós-quântica aumenta ainda mais o custo da verificação. Agregar as provas na camada da mempool e processá-las em conjunto é um requisito para transformar estas capacidades de «opções dispendiosas» em «funcionalidades acessíveis ao nível da conta».
Isto explica porque é que a EIP-8288 não gera tanto entusiasmo nas discussões técnicas como as narrativas sobre preços, apesar de abordar uma questão mais fundamental: a compatibilidade criptográfica futura do Ethereum continuará a depender da adição de pré-compilados ou adotará uma abordagem diferente, em que a thread principal se encarrega apenas da etapa final da verificação?
O crepúsculo dos pré-compilados e a aurora da infraestrutura de provas
Se a EIP-8288 funcionar como previsto, uma consequência direta será uma redução significativa da necessidade de novos contratos pré-compilados. Os utilizadores poderão gerar localmente assinaturas de qualquer tipo, submetê-las sob a forma de provas STARK e, depois, encaminhá-las para a cadeia através de um agregador, sem que o Ethereum tenha de adicionar um pré-compilado específico para cada novo algoritmo.
Outra consequência será uma mudança na forma da infraestrutura. Hoje, a mempool serve sobretudo para propagar e ordenar transações; no modelo da EIP-8288, os nós da mempool também terão de recolher, agregar e comprimir recursivamente as provas. Isto poderá dar origem a uma infraestrutura de provas especializada: em vez de todos os nós repetirem os cálculos, o trabalho computacional passará a ser feito por uma rede mais especializada, cabendo depois à cadeia principal confirmar os resultados.
Mas este mecanismo não está isento de desafios de engenharia. O próprio Vitalik já observou que gerir e paralelizar o acesso ao estado de enorme escala do Ethereum poderá ser mais difícil do que tornar as provas de conhecimento zero eficientes e seguras. As provas podem ser agregadas, mas o estado não pode simplesmente desaparecer. A EIP-8288 resolve o problema da carga de dados da verificação, mas não resolve automaticamente o crescimento do estado.
O que acompanhar a seguir
Relação de dependência entre a EIP-8288 e a EIP-8141: a proposta depende atualmente sobretudo da estrutura de transações em quadros da EIP-8141. O progresso da sua implementação funcional nas redes de desenvolvimento determinará se a 8288 pode avançar para uma discussão substantiva
Caminho para a padronização do RISC-V: as STARK recursivas precisam de um conjunto de instruções genérico que lhes sirva de suporte. Vitalik considera o RISC-V o principal candidato; a formação de um consenso em torno desta escolha arquitetónica afetará a generalidade das provas agregadas
Janela de atualização Hegota e I-star: a EIP-8288 ainda é um rascunho e não foi formalmente incluída numa atualização definida da rede principal. O calendário posterior à Hegota, em 2027, será uma referência para acompanhar a sua possível implementação
Soluções de paralelização da gestão do estado: depois de a verificação sair da thread principal, o acesso ao estado será o próximo gargalo. Os avanços da investigação nesta área determinarão os limites dos benefícios práticos da EIP-8288
O que resta à thread principal?
A trajetória técnica do Ethereum ao longo da última década tem respondido repetidamente à mesma pergunta: que tarefas têm de ser realizadas em conjunto por toda a rede e quais podem ser delegadas a sistemas mais especializados, ficando depois a rede principal responsável por confirmar os resultados? A execução foi para a L2, os dados foram para os blobs e agora a verificação também está a ser transferida para a mempool e para os clientes. A função central que resta à thread principal é garantir a fiabilidade e o consenso finais dos resultados computacionais.
Isto não significa que o Ethereum esteja a encolher, mas sim que os limites das suas responsabilidades estão a ser redefinidos. A pressão de 8 MB/s não é o destino final; apenas fez com que o caminho de «colocar tudo na thread principal» chegasse mais cedo ao ponto em que é preciso mudar de direção.