Palestrante: Vitalik Buterin
Compilado por: Yuliya, PANews
Olá a todos! Bem-vindos ao ETHShanghai 2026. Hoje quero discutir com vocês um tópico técnico bastante complexo que é crucial para o futuro do Ethereum—ele pode permitir que o Ethereum alcance escalabilidade extremamente alta enquanto também equilibra privacidade e descentralização, e todos os três podem ser alcançados simultaneamente. Esta proposta tem grande probabilidade de realmente mudar a arquitetura operacional de muitos componentes na blockchain. Ela pode mudar muitas coisas, mas, inesperadamente, implementá-la no Ethereum existente não é tão difícil. Este é o EIP-8288: Assinatura Recursiva e Agregação.
Ponto de Dor Central: A Irreconciliabilidade entre Segurança, Privacidade e Escalabilidade
Hoje quero focar em várias questões importantes que todos se preocupam muito: segurança quântica, privacidade e escalabilidade. Atualmente, um grande problema é que tanto a segurança quântica quanto a privacidade atualmente entram em grande conflito com a escalabilidade:
Uma transação normal do Ethereum atualmente consome cerca de 21.000 gas; verificar independentemente uma assinatura ECDSA (cerca de 65 bytes) leva cerca de 4.000 gas.
Se substituída por assinaturas quântico-seguras (independentemente de qual tipo de esquema de assinatura pós-quântica), o consumo de gas ficará aproximadamente entre 100.000 e 300.000 gas, dependendo do tamanho do parâmetro escolhido (por exemplo, se precisa ser compatível com cenários de carteira blockchain). Mas não importa como você escolha, o custo será várias vezes maior que as transações de hoje—assinaturas quântico-seguras são grandes e caras.
O segundo problema: provas para protocolos de privacidade também são grandes e caras. Se alguém já usou qualquer protocolo de privacidade baseado em tecnologia de conhecimento zero (ZK), saberá que, no Ethereum, tais operações custam pelo menos cerca de 350.000 gas. Como muitos desses protocolos não são projetados de forma muito eficiente, às vezes o custo real pode até chegar a cerca de 1 milhão de gas—isso é muito caro. Hoje, uma transação normal pode custar apenas alguns centavos, enquanto tais transações podem custar 20 centavos, ou até dois dólares.
Um problema mais sério é: se você quer tanto segurança quântica quanto privacidade, precisa usar provas STARK para substituir os esquemas anteriores. No entanto, uma prova STARK consome cerca de 8 milhões de gas, e muito provavelmente mais. Ou seja, se agora deixarmos todos começarem a usar transações "quântico-seguras + privacidade", a capacidade de processamento original do Ethereum de cerca de 25 TPS despencará para cerca de 0,25 TPS, quase perdendo a usabilidade.
Outro problema é: as pessoas também podem querer suportar esquemas criptográficos personalizados. Por exemplo, mudar das curvas elípticas de hoje para a futura criptografia baseada em reticulados. O problema é que toda vez que você quer suportar tais novos esquemas, isso aumenta o tamanho do próprio protocolo e requer mais arquivos de pré-computação (grandes em tamanho, altos em custo). E se você não suportar nativamente esses esquemas na EVM, ou não tiver os arquivos de pré-computação correspondentes, então verificar qualquer assinatura desse tipo on-chain consumirá uma quantidade muito grande de gas.
Em outras palavras, todos os nossos objetivos em segurança e privacidade estão, na verdade, dificultando a escalabilidade, pelo menos sob a arquitetura atual.
Solução Central: Mover a Computação de Agregação para a Mempool
Então, como resolvemos esse problema? Este é o mecanismo central implementado pelo EIP-8288.
A ideia central é: em vez de colocar diretamente todas essas assinaturas e todas essas provas STARK (esses objetos enormes e estruturalmente complexos) on-chain, mantemo-los off-chain e completamos a agregação dentro da mempool.
Especificamente: quando um usuário envia uma transação, há um grupo de nós na mempool, e esses nós já estão trabalhando antes que a transação seja empacotada em um bloco. O que esses nós fazem é chamado de "agregação"—eles substituem um grande número de assinaturas e provas por uma única prova, que pode verificar que todas essas assinaturas e provas realmente existem e são válidas.
Então, da perspectiva do usuário: o usuário envia uma transação e, junto com a transação, também envia esse enorme objeto (assinatura/prova), mas esse enorme objeto em si nunca vai realmente para a blockchain. O que realmente vai para a blockchain é apenas uma única prova STARK, usada para verificar que todas as assinaturas e todas as provas contidas em todas as transações do usuário realmente existem e são válidas.
Esse mecanismo é construído sobre o EIP-8141 (abstração de conta nativa), que será introduzido no próximo hard fork. O EIP-8141 condensa quase uma década de pesquisa da comunidade Ethereum no campo da abstração de conta. Ele permite que cada transação declare direta e precisamente seus componentes constituintes, especificações de assinatura e algoritmos de verificação, dando às transações uma programabilidade mais forte e uma estrutura tipada.
No EIP-8288, adicionamos um novo tipo de frame, que pode ser entendido como uma "dependência". Existem dois tipos de dependências no total: uma corresponde a assinaturas, e outra corresponde a provas (STARK). Diferentemente do modelo atual, em que as assinaturas são incorporadas diretamente no corpo da transação, sob o novo mecanismo a própria transação contém apenas uma declaração abstrata indicando de que tipo de assinatura e prova a transação depende. Quando a transação é transmitida, embora os dados completos sejam enviados junto com ela, o que acaba sendo gravado no bloco é apenas a microestrutura de frame que carrega as dependências. Os dados ocupados por cada dependência são de apenas 96 bytes, e a maioria é ainda menor, chegando a 65 bytes. O restante das enormes entidades criptográficas é absorvido e agregado dentro do mempool, e, por fim, aparece no livro-razão da blockchain apenas na forma de uma única prova.
Sob essa arquitetura, cada nó no mempool escuta continuamente um portador de dados chamado "envelope". Um único envelope pode encapsular múltiplas transações e suas provas acompanhantes.
Os nós usam um período de tempo fixo como janela, coletam continuamente todos os objetos de envelope observados durante esse período, realizam computação de agregação local e então os transmitem. Durante a transmissão, todas as provas independentes originalmente discretas foram substituídas por uma única prova agregada global, que cobre matematicamente, de forma rigorosa, a correção de todas as assinaturas subjacentes nesse lote.
Isso mostra que, antes de os nós de empacotamento de blocos executarem formalmente as atualizações de estado, a rede Ethereum já concluiu a grande maioria da computação de verificação de alta intensidade na fase do mempool, na camada não consensual.
Essência Arquitetural: "Sharding Especializado"
Uma maneira de entender esse mecanismo é vê-lo como um tipo de sharding especializado. Sua ideia é: podemos destacar aquelas partes extremamente caras da computação que envolvem quantidades extremamente grandes de dados, e deixar que toda a rede distribuída processe essa parte da computação em paralelo de uma forma muito solta e não estruturada.
Essa abordagem não é frágil; pelo contrário, é muito robusta — qualquer nó pode assumir qualquer porção desse trabalho. O que estamos fazendo é, essencialmente, dividir cada transação em duas partes:
Uma parte explica "o que esta transação faz, como ela interage com o estado e como ela interage com outras transações";
A outra parte é a parte enorme e de alto custo desta transação — ou seja, o trabalho de verificação pura.
Ao fazer sharding especificamente e remover a carga de verificação, a carga útil de dados que a camada de consenso da cadeia principal finalmente exige que todos os nós de verificação da rede suportem em conjunto é estritamente comprimida para uma faixa extremamente pequena de 100 a 300 KB por bloco. Esse overhead é apenas cerca de duas vezes o volume atual de dados de bloco da Ethereum, e, à medida que a taxa de transferência geral da rede se expande linearmente, a proporção desse overhead constante na carga total da rede continuará sendo diluída.
Essencialmente, o que estamos fazendo é: afastar o trabalho dos validadores e até mesmo dos nós que empacotam blocos, empurrando essa parte do trabalho para aqueles nós fora da cadeia localizados entre "o usuário envia uma transação" e "o nó que empacota o bloco realmente inclui a transação no bloco".
O Que Isso Significa para a Ethereum?
De uma perspectiva técnica, isso significa que a Ethereum está hiperescalando uma classe específica de computação. Acho que essa também é uma tendência que veremos cada vez mais à medida que a Ethereum continua a se desenvolver.
A Ethereum, nascida há dez anos, concentrou-se em computação totalmente geral, mas também carecia completamente de escalabilidade. Então, o que estamos fazendo agora é dividir a computação em diferentes tipos e, em seguida, tornar especificamente extremamente escaláveis aqueles tipos de computação que são "naturalmente mais adequados para escalar" — estamos construindo essas "pequenas ferramentas" mais especializadas para realizar isso.
Ao mesmo tempo, também estamos tornando menores e mais fáceis de lidar aquelas computações que precisam ser processadas de uma forma menos eficiente. O EIP-8288 é precisamente o hiper-escalonamento de dois tipos de objetos: "verificação de assinatura" e "verificação de prova de conhecimento zero".
Outro ponto interessante é este: sei que muitas pessoas há muito tempo têm curiosidade sobre quando o Ethereum migrará para RISC-V — porque, comparado com a abordagem atual, o RISC-V ou algum outro conjunto de instruções mais moderno é muito mais eficiente, e também muito mais simples. E o EIP-8288 tem grande probabilidade de se tornar o primeiro cenário no Ethereum que realmente introduz o RISC-V (ou um conjunto de instruções semelhante). A razão é que o EIP-8288 permite que os usuários enviem provas, e quando os usuários enviam provas, eles precisam usar alguma linguagem para expressar as afirmações que estão verificando — o RISC-V é exatamente essa linguagem.
Ou seja, a lógica de verificação expressa em RISC-V só precisa ser executada como uma única computação física localmente no cliente do usuário: o usuário gera a prova correspondente (em cenários de privacidade, isto é um ZK-STARK), e então imediatamente a envia para o mempool; o primeiro nó de relay que a seguir a comprime recursivamente de imediato, junto com centenas ou milhares de provas semelhantes em toda a rede, em uma única entidade.
Isso também equivale a dividir toda a computação em duas grandes categorias:
Uma categoria são as "dependências" — ou seja, as partes que precisam ser garantidamente corretas para que a transação seja válida;
A outra categoria é a "lógica de negócios" — ou seja, o que a própria transação realmente faz.
A lógica de negócios pode, portanto, tornar-se mais leve e mais limpa, o que também significa que a parte da lógica de construção de blocos que depende da ordenação de transações também se tornará mais simples. E a parte das "dependências" pode ser processada em paralelo em uma escala extremamente grande, praticamente sem necessidade de quaisquer mudanças importantes na experiência de desenvolvimento dos desenvolvedores do Ethereum.
O Valor Prático para Desenvolvedores, Usuários e Layer 2
Para qualquer pessoa que construa aplicações on-chain, o significado central de tudo isso é: as operações mais caras hoje se tornarão muito mais baratas.
A sobrecarga de execução de transações resistentes a quantum será comprimida a um nível baixo quase desprezível;
Aplicações de preservação de privacidade construídas sobre zk-SNARK/STARK escaparão das restrições das altas taxas de Gas, tornar-se-ão amplamente difundidas a um custo acessível e terão nativamente resistência quântica.
Além dos cenários de privacidade, a eficiência de aplicação do zk-SNARK em escalonamento (especialmente Layer 2) verá um salto qualitativo. Atualmente, muitos ZK-Rollups, a fim de amortizar o alto custo de Gas de publicar provas de estado na mainnet, são frequentemente forçados a alongar o ciclo de submissão, liquidando em lotes a frequências de dez minutos ou até uma hora. Isso restringe severamente a velocidade de confirmação final durante períodos de baixa atividade de transações na rede.
Atualmente, muitos ZK-Rollups, a fim de amortizar o alto custo de Gas de publicar provas de estado na mainnet, são frequentemente forçados a alongar o ciclo de submissão, liquidando em lotes a frequências de dez minutos ou até uma hora. Isso restringe severamente a velocidade de confirmação final durante períodos de baixa atividade de transações na rede.
A Evolução do Endgame: Empurrando a Computação Completamente para a Borda
Por fim, se houver outras computações que você queira fazer, mas que sejam caras demais para executar dentro da EVM, espero que possamos realmente começar a mudar de direção — não mais fazendo com que o próprio protocolo Ethereum arque diretamente com toda a computação que todos querem fazer, mas em vez disso incentivando os usuários a completar essa parte da computação localmente em seus clientes, e então publicar uma prova, de modo que essa prova seja verificada no Ethereum.
Essencialmente, isto é escalar o Ethereum movendo a computação para fora do "centro" da cadeia e empurrando-a para a "borda". O resultado é: as coisas que são mais caras no Ethereum hoje (várias formas de segurança, várias formas de privacidade e várias formas de compatibilidade com aplicações externas) não são feitas pelas pessoas hoje porque são caras demais, e no futuro todas se tornarão muito mais baratas e verdadeiramente utilizáveis por todos.
Espero que este seja apenas o primeiro passo para transformar o Ethereum da arquitetura que ele praticamente usa desde o seu nascimento em uma arquitetura nova, completamente diferente e ainda mais poderosa — uma nova arquitetura que realmente combina duas coisas: uma é a ideia de blockchain inicial muito simples de Satoshi Nakamoto; a outra é a tecnologia criptográfica extremamente poderosa e extremamente moderna que acumulamos continuamente desde então.
Participação no Ecossistema e Progresso da Implementação
No momento, a exploração inicial e a validação de engenharia em torno dessa abordagem estão sendo realizadas intensivamente, e a comunidade técnica já pode participar da construção a partir de múltiplos pontos de entrada:
Modelos de simulação em nível de rede: ferramentas de simulação iniciais para topologia de mempool e mecanismos de propagação de agregação foram disponibilizadas;
Operação de testnet: a testnet EIP-8141 que suporta a forma de transação de frame foi colocada em teste;
Competições de otimização de algoritmos: competições de algoritmos especiais para a comunidade de desenvolvedores estão sendo promovidas, com foco na implementação eficiente do sistema de prova subjacente;
Implementação e verificação de código: a base de código protótipo subjacente já tomou forma, para que desenvolvedores do ecossistema realizem implementações independentes de clientes e verificação formal.
Um grande número de peças técnicas subjacentes está sendo rapidamente preenchido. Desenvolvedores são bem-vindos a participar profundamente deste processo técnico e ajudar esta arquitetura revolucionária a se tornar um padrão de realidade na mainnet do Ethereum o mais rápido possível.
