O cofundador do Ethereum, Vitalik Buterin, apoiou o EIP-8288 como uma forma proposta de dar suporte a criptografia complexa sem adicionar repetidamente novas funções de verificação ao Ethereum, argumentando que a maior parte do trabalho criptográfico pesado deve acontecer fora do processo de execução principal da rede.
Resumo
- Vitalik Buterin quer que o Ethereum verifique criptografia complexa por meio de provas agregadas em vez de atualizações repetidas de protocolo.
- O EIP-8288 propõe combinar assinaturas criptográficas e provas STARK antes que os validadores do Ethereum verifiquem sua validade coletiva de forma eficiente.
- A proposta poderia dar suporte a assinaturas de carteira resistentes a quantum sem exigir precompilações separadas do Ethereum para cada tipo de assinatura.
- Os desenvolvedores do Ethereum não aprovaram o EIP-8288, que continua sendo um rascunho que requer mais implementação e consenso da rede.
- O sistema proposto manteria grandes provas fora dos dados do bloco, ao mesmo tempo em que retém compromissos de transação para verificação.
Em uma série de publicações de 19 de outubro no X, Buterin argumentou que a máquina virtual existente do Ethereum e as funções criptográficas especializadas são inadequadas para dar suporte a cada novo sistema de assinatura ou prova. Ele, em vez disso, favoreceu um design que permitiria aos usuários gerar provas localmente e enviá-las por meio de um mecanismo de agregação.
A proposta, EIP-8288, permitiria ao Ethereum verificar que operações criptográficas foram executadas corretamente sem incluir cada assinatura ou prova original em um bloco.
Vitalik Buterin descreveu essa abordagem como parte de sua visão do Ethereum como um computador mundial criptográfico, onde computação substancial pode acontecer fora da blockchain enquanto seus resultados permanecem verificáveis.
A especificação continua sendo um rascunho e não recebeu aprovação para implantação na mainnet do Ethereum.
Vitalik Buterin quer menos trabalho criptográfico dentro do Ethereum
Os comentários mais recentes de Vitalik Buterin concentram-se em como o Ethereum lida com operações criptográficas que exigem grandes quantidades de computação ou dados.
Atualmente, os desenvolvedores podem usar a Ethereum Virtual Machine, ou EVM, para executar contratos inteligentes que verificam certas declarações criptográficas.
O Ethereum fornece precompilações, que são funções integradas que realizam cálculos específicos com mais eficiência do que o código comum de contrato inteligente.
Essas funções podem ajudar os desenvolvedores a verificar assinaturas, hashes e provas de conhecimento zero.
No entanto, dar suporte a métodos criptográficos adicionais diretamente por meio de precompilações pode exigir mudanças no protocolo do Ethereum.
Vitalik Buterin argumentou que nenhuma das abordagens deve se tornar a solução padrão para cada novo sistema criptográfico.
Sua preocupação concentra-se na quantidade de dados que deve ser incluída nos blocos do Ethereum quando aplicações enviam grandes assinaturas ou provas criptográficas para verificação.
Na discussão de 19 de outubro, ele estimou que mesmo com melhorias como PeerDAS e blocks-in-blobs, a rede enfrentaria limites práticos em torno de 8 megabytes por segundo antes que dados adicionais se tornassem difíceis de lidar.
A estimativa representa a avaliação de Buterin sobre restrições futuras de engenharia, não a taxa de transferência de transações atualmente medida do Ethereum.
Ele descreveu o Ethereum como um computador mundial criptográfico no qual a blockchain deve lidar apenas com informações que exigem execução e verificação compartilhadas.
A ideia é consistente com seu trabalho anterior sobre a redução da quantidade de computação que cada validador do Ethereum deve realizar de forma independente.
Em setembro, o crypto.news cobriu sua visão de computador criptográfico, que descrevia a transição proposta do Ethereum para verificação baseada em provas, privacidade e tratamento mais eficiente de dados.
Seus comentários de outubro focaram em uma proposta específica para fazer essa abordagem funcionar em diferentes sistemas criptográficos.
O EIP-8288 combinaria provas antes que elas cheguem ao Ethereum
O mecanismo proposto é descrito no EIP-8288, intitulado Agregação de assinaturas e provas no mempool.
Buterin e o pesquisador do Ethereum Thomas Coratger criaram a proposta em 3 de junho de 2026.
De acordo com a especificação oficial, o sistema permitiria que as transações declarassem quais afirmações criptográficas devem ser verificadas sem incluir todo o material de prova original no bloco final.
Essas declarações identificariam o esquema de verificação, um hash que representa os dados relevantes e um hash associado à chave de verificação.
A rede usaria essas referências para conectar transações com evidências de que as operações necessárias foram executadas corretamente.
Os usuários gerariam assinaturas ou provas criptográficas fora do ambiente de execução principal do Ethereum.
A proposta permite que essas provas sejam combinadas recursivamente, o que significa que uma prova pode estabelecer a validade de várias provas menores.
Em vez de verificar individualmente cada assinatura original e cada STARK, o Ethereum verificaria uma prova agregada que cobre as dependências de transação relevantes.
Um STARK é uma prova criptográfica que permite a alguém demonstrar que um cálculo foi executado corretamente sem exigir que cada verificador repita todo o cálculo.
O sistema de agregação proposto usaria ferramentas do Lean Ethereum para gerar e verificar essas provas.
O EIP-8288 descreve um novo modo de frame de transação que declararia dependências criptográficas. A proposta se baseia no EIP-8141, que introduz uma estrutura para transações com múltiplas etapas de execução e verificação.
No nível do bloco, um STARK recursivo demonstraria que as dependências declaradas foram satisfeitas.
O sistema continuaria registrando as informações necessárias das transações e os compromissos criptográficos no Ethereum.
No entanto, seu design pretendido evitaria publicar as grandes assinaturas e provas originais como calldata comum de transação.
A proposta não é um plano para remover todos os dados de transação da blockchain ou permitir que aplicações operem sem registros verificáveis.
Assinaturas resistentes a quantum são uma parte importante da proposta
O EIP-8288 inclui suporte para assinaturas criptográficas projetadas para resistir a ataques de futuros computadores quânticos.
Atualmente, o Ethereum depende de sistemas de assinatura digital estabelecidos para autenticação de contas e consenso da blockchain.
Os desenvolvedores estão pesquisando alternativas que permaneceriam seguras se computadores quânticos suficientemente poderosos se tornarem disponíveis.
Algumas assinaturas resistentes a quantum propostas são muito maiores do que as assinaturas usadas em transações convencionais do Ethereum.
De acordo com o EIP-8288, as assinaturas baseadas em hash em consideração podem exigir aproximadamente 2–3 kilobytes e um estimado de 150.000–200.000 de gas para verificação direta.
As assinaturas baseadas em reticulado apresentam desafios comparáveis na discussão de custos da proposta.
As provas STARK podem exigir mais de 128 kilobytes, com algumas configurações chegando a aproximadamente 512 kilobytes quando otimizadas para geração rápida de provas.
Incluir grandes quantidades desse material diretamente nas transações poderia criar custos substanciais de dados e execução.
Vitalik Buterin argumentou que os usuários deveriam ser capazes de produzir suas assinaturas preferidas localmente e provar sua validade por meio da agregação STARK.
Ele discutiu a possibilidade de usar criptografia baseada em reticulado para contas e carteiras do Ethereum se as premissas de segurança relevantes fossem estabelecidas.
Sua declaração de 19 de outubro referia-se especificamente à criptografia que poderia ser comprovada como segura contra ataques relacionados à IA. Essa condição é separada da definição padrão de resistência a ataques de computadores quânticos.
Reportagens anteriores sobre o roteiro do Ethereum descreveram como a resistência quântica e a privacidade se tornaram prioridades para o desenvolvimento futuro da rede.
O roteiro inclui mudanças na verificação de assinaturas e nos sistemas criptográficos que sustentam o consenso e a disponibilidade de dados do Ethereum.
O EIP-8288 aborda parte desse trabalho ao propor um método comum para verificar múltiplos esquemas criptográficos.
A agregação recursiva começaria antes da produção do bloco
O processo proposto não depende exclusivamente de um produtor de bloco coletar todas as assinaturas e gerar uma única prova final.
O EIP-8288 descreve a agregação recursiva começando no mempool do Ethereum, onde as transações aguardam antes de serem incluídas em blocos.
De acordo com o design, os usuários enviariam transações juntamente com as evidências criptográficas necessárias para autorizá-las.
Os participantes do mempool poderiam validar as evidências enviadas, combinar várias provas em uma e repassar o pacote resultante para outros participantes.
A especificação descreve um intervalo de agregação de 1.000 milissegundos para esse processo.
Os construtores de blocos então coletariam as transações relevantes e as provas agregadas antes de construir um bloco do Ethereum.
Um STARK recursivo final cobriria as dependências associadas às transações selecionadas para inclusão.
O rascunho propõe limites técnicos destinados a impedir que usuários maliciosos sobrecarreguem o sistema de agregação com exigências excessivas de provas.
Por exemplo, seus parâmetros atuais permitem até 16 dependências de assinatura especificadas e uma dependência de STARK por transação.
A especificação também aborda a compatibilidade com o FOCIL, um mecanismo proposto de inclusão de transações projetado para tornar a censura mais difícil.
Uma análise do Ethereum sobre verificação baseada em provas publicada em setembro examinou a distinção entre verificar o resultado de uma computação e garantir que os dados subjacentes permaneçam acessíveis.
O EIP-8288 aborda a verificação criptográfica enquanto retém as informações de transação necessárias para identificar e validar dependências.
Seu design introduz trabalho adicional para os participantes do mempool e os construtores de blocos, que precisariam gerar, atualizar e combinar provas. A seção de segurança da proposta identifica a correção dos circuitos de prova, das funções de hash e da verificação recursiva como suposições que exigem avaliação cuidadosa.
O EIP-8288 permanece um rascunho que requer aprovação da rede
O repositório oficial de Propostas de Melhoria do Ethereum classifica o EIP-8288 como uma proposta de rascunho da trilha de padrões na categoria principal.
Sua implementação alteraria as regras de consenso do Ethereum, porque blocos contendo o formato de prova recursiva proposto não seriam compreendidos por nós executando software sem a atualização.
A especificação identifica o EIP-2718 e o EIP-8141 como dependências. Vários detalhes de implementação permanecem incompletos, incluindo parâmetros associados à chave de verificação agregada e ao hashing de dependências.
A implementação de referência da proposta está listada como futura. Os desenvolvedores do Ethereum precisariam concluir o trabalho técnico, revisar as suposições de segurança e concordar com a ativação na rede antes que o design pudesse ser implantado. O repositório atualmente não lista uma data aprovada de ativação na mainnet para o EIP-8288.
Os casos de teste existentes da proposta cobrem a verificação individual de assinaturas, múltiplas dependências de provas, provas recursivas inválidas, agregação no mempool e compatibilidade com listas de inclusão de transações.
Sua seção de compatibilidade retroativa afirma que transações comuns sem os novos quadros de verificação criptográfica manteriam seu comportamento existente.
Nós que não implementarem as novas regras rejeitariam transações usando o modo de quadro proposto e blocos que carreguem o cabeçalho de prova recursiva.
A proposta, portanto, exige uma atualização coordenada da rede antes que seu sistema de agregação criptográfica possa se tornar parte das regras da mainnet do Ethereum.
