A visão do Ethereum para 2030 transfere o trabalho para provas criptográficas. Quem verifica o resultado?

A visão de Vitalik Buterin de 27 de setembro descreve o Ethereum passando de um sistema no qual cada verificador repete grande parte do trabalho para um no qual os dados podem ser amostrados e a execução pode ser verificada com provas compactas. Uma parte, o PeerDAS, já foi implementada. A mudança mais ampla na execução permanece em desenvolvimento. Uma prova pode estabelecer que um cálculo seguiu regras especificadas, mas os usuários ainda precisam de dados, de uma forma de enviar transações e de um protocolo que decida qual resultado se torna final.

A pergunta principal tem duas respostas. Um provador produz uma prova criptográfica; um verificador, potencialmente qualquer nó validador executando o software relevante, verifica essa prova em relação às regras e às entradas públicas. O roteiro do Ethereum para uma zkEVM de camada base afirma que a verificação deve ser muito mais barata do que reexecutar cada transação. Mas decidir se uma prova é sólida não resolve por si só se os dados da transação estão disponíveis ou se um operador pode retê-la de um usuário.

O ensaio de 27 de setembro de Buterin, “The cryptographic world computer”, enquadra o destino como uma combinação de uma blockchain, privacidade e verificação criptográficas e componentes descentralizados fora da cadeia. Ele contrasta um padrão mais antigo de baixar e reexecutar com um modelo no qual os nós amostram dados e verificam provas. Ele descreve outras possíveis mudanças no consenso e na construção de blocos. Esta é uma visão técnica pessoal, não uma especificação final de atualização ratificada por todas as equipes de clientes do Ethereum.

A distinção entre o que existe e o que é vislumbrado é importante. O PeerDAS chegou com o Fusaka em dezembro de 2025, de acordo com a atualização de prioridades de protocolo da Ethereum Foundation de fevereiro de 2026. A Fundação afirma que os validadores agora amostram dados de blob em vez de baixar todos eles. Uma mudança em toda a rede para verificar provas de execução sucintas para blocos da camada base não é descrita como já implantada. Um leitor que ouve que o Ethereum “verificará provas em 2030” deve perguntar qual prova, qual cálculo ela cobre e quais atores podem testá-la de forma independente.

O PeerDAS verifica o acesso aos dados, não cada cálculo

A parte já implantada é o PeerDAS, ou amostragem de disponibilidade de dados ponto a ponto. Os rollups colocam os dados de transação no espaço de blob do Ethereum para que outros participantes possam recuperar informações suficientes para reconstruir o estado e responsabilizar um operador pelas regras. A abordagem antiga de fazer cada nó baixar cada blob tornaria volumes maiores de dados caros para validadores comuns. A amostragem pede que os nós verifiquem pequenas partes em relação a compromissos criptográficos, enquanto a rede distribui partes codificadas suficientes para a reconstrução.

A explicação do Ethereum diz que os dados de blob estendidos são divididos em 128 colunas. Um nó regular se junta a pelo menos 8 sub-redes de colunas escolhidas aleatoriamente. Oito dividido por 128 é um dezesseis avos dos dados estendidos. A codificação adiciona redundância, de modo que essa quantidade corresponde a cerca de um oitavo do volume de dados original, conforme a descrição da documentação. Os números se referem à carga de dados de um nó padrão, não a uma afirmação de que um nó pode pessoalmente armazenar todo o histórico de cada rollup por um oitavo do custo.

A codificação no estilo Reed-Solomon produz peças de dados redundantes, e compromissos criptográficos ajudam um nó a verificar que uma peça amostrada pertence ao que foi anunciado. A amostragem fornece uma garantia probabilística de disponibilidade entre os nós participantes. Ela não substitui a validação de execução. Um lote perfeitamente disponível de transações pode conter uma transição de estado inválida. Da mesma forma, uma prova válida sobre uma transição de estado não é suficiente para permitir que um usuário reconstrua o estado de uma conta se os dados necessários para isso forem retidos fora das garantias de disponibilidade.

A Fundação Ethereum disse que o Fusaka permitiu um aumento de oito vezes na capacidade teórica de blobs. A palavra teórica importa: a taxa de transferência sustentada real depende de aumentos programados de parâmetros, condições da rede e uso de rollups. A Crypto.news explicou como os rollups usam a camada de dados do Ethereum. O novo ensaio de Buterin trata o PeerDAS como o primeiro passo visível em direção a um sistema que verifica mais e repete menos; ele não deve ser reclassificado como a atualização final de prova de execução.

O provador faz o trabalho pesado; nós independentes o verificam

Em um modelo de execução baseado em provas, alguém ainda precisa executar transações e construir evidências sobre o resultado. Essa parte pode usar hardware e software especializados caros. Uma prova sucinta permite que um verificador confira, a um custo muito menor, que a mudança de estado alegada segue o programa e as entradas comprometidas sob as regras do protocolo. Uma verificação matemática não exige que o verificador confie na empresa provadora apenas porque ela gerou a prova.

Há condições atreladas a essa afirmação. O verificador deve executar um sistema de prova sólido com a chave de verificação correta, entradas públicas e regras de execução acordadas. Um circuito defeituoso poderia provar a afirmação errada perfeitamente. Um bug na implementação de um cliente poderia aceitar uma prova que deveria rejeitar. Uma chave de atualização que pode alterar o código do verificador sem controles robustos poderia enfraquecer a garantia. Em um protocolo ativo, implementações independentes e revisão importam tanto quanto a geração rápida de provas.

A página do roteiro do zkEVM da L1 do Ethereum descreve um futuro no qual um nó verifica uma prova de execução de bloco em vez de repetir cada transação. Seu objetivo declarado é reduzir o custo de recursos da verificação. Isso tornaria mais fácil para mais pessoas verificarem blocos se a verificação de provas permanecer prática em hardware acessível. Não significa que todos os domicílios possam produzir uma prova de bloco, nem que a produção de provas será distribuída uniformemente.

A Crypto.news relatou uma competição de hardware em torno da prova. A distinção útil é entre quem pode gerar uma prova a tempo para a cadeia e quem pode verificá-la barato. A geração de provas pode se concentrar entre empresas com hardware especializado sem automaticamente permitir que essas empresas falsifiquem uma transição de estado válida. Ainda assim, poderia introduzir uma dependência de vivacidade: se poucas partes puderem produzir provas rapidamente o suficiente, blocos ou finalidade podem desacelerar mesmo quando o sistema de prova permanece matematicamente sólido. Esse é um risco diferente de uma prova inválida ser aceita.

A questão da verificação, portanto, tem uma resposta humana além de uma matemática. Desenvolvedores definem o circuito, pesquisadores o auditam, equipes de clientes o implementam, operadores de nós executam verificadores, e participantes decidem se aceitam atualizações de protocolo. Buterin pode propor uma direção. Ele não pode, sozinho, tornar um futuro verificador seguro ou obrigatório para a rede.

Três promessas são frequentemente dobradas na palavra prova

Considere um usuário enviando um pagamento por meio de um rollup. A transação precisa ser incluída em um lote ordenado. Os dados do lote devem ser disponibilizados sob o modelo escolhido pelo rollup. Finalmente, a mudança de estado resultante deve seguir suas regras. Ordenação, disponibilidade e correção são promessas separadas. Uma prova de correção aborda a última para um cálculo especificado. O PeerDAS aborda a disponibilidade dos dados de blob do Ethereum. Um sequenciador ou mecanismo de construção de blocos afeta quais transações são incluídas e em que ordem.

Crypto.news examinou os sequenciadores como um ponto distinto de controle. Uma prova perfeitamente válida pode atestar que um lote foi processado de acordo com as regras, mesmo que seu operador tenha excluído a transação de um cliente específico. Um usuário pode ter uma rota de escape ou de inclusão forçada dependendo do design daquele rollup, mas a prova em si não obriga a um acesso justo. Um sequenciador também pode reordenar transações enquanto ainda produz uma transição de estado válida. A declaração que está sendo provada não deve ser confundida com todas as propriedades que os usuários desejam de um mercado.

O lado dos dados é igualmente fácil de confundir. A documentação de validium da Ethereum descreve sistemas que usam provas de validade, mas não publicam os dados das transações na mainnet da Ethereum. Sua execução pode estar correta de acordo com um verificador, mas uma falha de disponibilidade de dados pode impedir os usuários de reconstruir o estado ou sacar como esperado. Um rollup da Ethereum que publica dados suficientes na Ethereum tem um modelo de disponibilidade diferente. Chamar ambos simplesmente de “ZK” esconde uma diferença crítica na capacidade de um usuário de recuperar o estado de uma conta sem o operador.

O teste mais simples é uma lista de verificação mental de três colunas. Pergunte quem consegue incluir uma transação no lote. Pergunte onde os dados necessários para reconstruir os saldos podem ser recuperados. Pergunte qual contrato ou nó verifica a prova de correção do estado. Se um projeto responde apenas à terceira, ele não respondeu às duas primeiras. É por isso que o ensaio de Buterin fala sobre construção de blocos e distribuição de dados da rede juntamente com criptografia, em vez de substituir todo o sistema por uma única prova mágica.

A camada base não pode tomar emprestada todas as propriedades dos rollups existentes

Os rollups ZK já enviam provas de validade para a Ethereum sob seus próprios contratos e regras. A documentação da Ethereum sobre rollups ZK descreve um operador criando uma prova para um lote e um contrato verificador aceitando uma nova raiz de estado somente após a verificação. Esse é um precedente útil para provar computação. Isso não significa que a camada base da Ethereum já transferiu toda a validação de execução para tais provas.

O escopo é diferente. Um rollup prova sua própria transição de estado sob sua própria máquina virtual e contrato, enquanto o verificador da camada base da Ethereum teria que verificar a execução do bloco do protocolo de uma forma que as equipes de clientes aceitem. Uma incompatibilidade entre a lógica personalizada de um rollup e as regras de execução da mainnet da Ethereum não é um detalhe que um provador mais rápido possa simplesmente ignorar. Os sistemas de prova também devem permanecer robustos através de atualizações de protocolo, novos tipos de transação e entradas adversariais.

Um aplicativo pode terceirizar sua aritmética para um coprocessador e fornecer um resultado com uma prova, mas a cadeia base ainda decide se aceita as entradas públicas, armazena compromissos e liquida o estado resultante. Um aplicativo pode ser capaz de escolher seu próprio design de provador; uma regra da camada base exige ampla coordenação entre clientes e validadores. A frase de Buterin “computador mundial criptográfico” é útil como direção arquitetônica, não como promessa de que um único serviço de prova executará toda a Ethereum.

Há uma aparente contradição que vale a pena resolver. Se os nós param de reexecutar, como alguém encontra um bug na computação que está sendo provada? Uma resposta é que os desenvolvedores podem executar uma execução completa independente e compará-la com os resultados da prova durante o desenvolvimento e após a implantação. Outra é múltiplas implementações de prova e verificações formais dos circuitos. O design exato da Ethereum ainda não foi finalizado. Um protocolo que reduz a reexecução necessária não proíbe as pessoas de realizar verificações extras; ele muda o que cada nó validador comum deve fazer para o consenso.

A atualização de prioridades do protocolo de setembro da Fundação trata uma zkEVM de L1 e a verificação formal como grandes frentes de trabalho. Isso é evidência de engenharia ativa, não uma data de lançamento definida. O padrão de segurança é alto porque um erro em um sistema de prova da camada base afetaria a fundação da qual outros aplicativos dependem.

As provas podem melhorar a verificação enquanto o problema de estado cresce

Buterin nomeia o acesso a um estado compartilhado muito grande como um problema não resolvido particularmente difícil. Crypto.news examinou sua proposta separada para escalonamento de mempool baseado em provas, que visa um gargalo diferente da execução final do estado. Uma prova pode atestar uma computação, mas o provador deve obter as informações das quais essa computação depende: saldos, armazenamento de contratos e outros estados de conta. Se muitas transações tocam o mesmo estado ao mesmo tempo, dividir a computação entre máquinas torna-se mais difícil. Um pagamento de uma conta e uma troca que toca um pool de liquidez não podem ambos ser finalizados a partir de instantâneos inconsistentes.

O ensaio sugere que as aplicações podem colocar a ordenação e as mudanças de estado não comutativas onchain, enquanto agregam outros cálculos antes da inclusão. Isso é um incentivo arquitetural, não uma regra vinculante para os desenvolvedores hoje. "Não comutativo" significa que mudar a ordem altera o resultado. Duas pessoas comprando do mesmo pool reduzido podem obter preços diferentes dependendo de qual ordem é processada primeiro. Nenhuma prova torna essas duas ordens economicamente equivalentes.

Este é um contrapeso útil a uma promessa simplista de escala gratuita. O trabalho paralelo é mais fácil quando as tarefas podem ser separadas com segurança. O estado compartilhado cria dependências. Um prover pode executar muitos cálculos independentes rapidamente e ainda assim esperar pelo acesso a um estado contestado ou pela escolha de ordenação de um construtor de blocos. Melhorar apenas a velocidade de prova não resolve a contenção do banco de dados, a censura ou o custo de tornar informação suficiente disponível para outros participantes.

Na visão de Buterin, uma camada intermediária descentralizada mais forte poderia processar trabalho em paralelo e, em alguns casos, proteger metadados sobre a origem das requisições. Tal infraestrutura poderia melhorar o desempenho ou a privacidade, mas teria que especificar como os dados são distribuídos, quem pode entrar e quais falhas têm um caminho de escape. A privacidade do pagamento de um usuário não é uma consequência automática do uso de uma prova de validade. Entradas públicas, atividade da carteira e metadados de rede ainda podem divulgar informações, a menos que um sistema proteja essas partes também.

A independência pode ser medida antes do fork final

"Qualquer um pode verificar" tem condições práticas. Um nó comum precisa do código do verificador, das entradas públicas relevantes, de uma conexão com o estado aceito da cadeia e de capacidade de processamento suficiente para completar a verificação dentro dos limites de tempo do protocolo. Se uma prova leva segundos para ser verificada em uma máquina modesta, mas horas para ser produzida em hardware caro, o sistema pode alcançar verificação ampla com produção restrita. Isso pode ser um trade-off de engenharia aceitável para a correção, desde que uma indisponibilidade de um produtor não se torne um bloqueio permanente para a liquidação.

O experimento é direto em linhas gerais. Execute o software verificador de mais de uma equipe de cliente contra a mesma prova de bloco válida e confirme que eles a aceitam. Forneça entradas públicas alteradas e confirme a rejeição. Pergunte se equipes de prova separadas podem produzir provas aceitas para as mesmas regras, com que rapidez podem fazê-lo e qual hardware cada uma exige. Repetir isso em uma rede de teste pública sob carga pesada diria mais sobre a prontidão do que uma demonstração de laboratório de uma única prova rápida. Os critérios exatos de aceitação do Ethereum permanecem sujeitos ao trabalho de protocolo; estas são questões observáveis, não limites oficiais de aprovação.

A geração de provas tem outro modo de falha que uma verificação de validade não consegue capturar por si só. Um prover pode se recusar a fazer uma prova para um bloco proposto. Um verificador não pode aceitar uma prova que não chegou. Um design pode abordar isso permitindo múltiplos provers independentes, um caminho de execução alternativo, temporização ajustada ou outros mecanismos. A escolha afetará a complexidade, o custo e o tempo até a finalidade. As regras atuais da camada base do Ethereum não devem ser descritas como tendo selecionado uma dessas soluções futuras apenas porque um roadmap diz que a verificação de provas é um objetivo.

Independência também significa que um usuário pode obter as informações necessárias para verificar sua própria reivindicação sobre ativos. Uma prova de que uma raiz de estado seguiu o código é poderosa, mas um usuário que não consegue reconstruir o caminho dos dados de sua conta até essa raiz ainda depende de um intermediário para uma verificação prática de saldo. O PeerDAS torna a disponibilidade de dados de blob menos exigente para cada nó, ao mesmo tempo que depende da distribuição e amostragem em toda a rede. Os dados de aplicação mantidos em outro lugar precisam de suas próprias garantias de disponibilidade. O verificador de provas da cadeia não pode obrigar um operador externo a publicar registros retidos.

Por fim, o programa que está sendo verificado deve ser o programa que os usuários pensam que é. Um hash público do código do verificador, um processo de atualização documentado e testes independentes do comportamento do circuito permitem que observadores externos comparem a regra anunciada com o que os nós realmente aplicam. A verificação formal pode reduzir a chance de um erro de lógica, mas ela também começa com uma especificação escrita por humanos. O resultado verificável não é "a criptografia resolveu a confiança". É que uma afirmação especificada pode ser independentemente rejeitada quando sua evidência é inválida, sem que cada nó pague o custo total de produzi-la.

Hegota é um marcador, não uma garantia de lançamento em 2030

Buterin se refere a Hegota, um fork planejado para 2027, como possivelmente a última atualização cujos componentes seriam familiares a um observador do Ethereum de 2015. Trabalhos posteriores em seu relato envolveriam STARKs recursivos, verificação formal, consenso otimizado e segurança quântica. A Crypto.news noticiou a meta quântica separada para 2029 como um objetivo de planejamento. Nem o ensaio nem uma data-alvo provam que cada componente proposto estará pronto e será adotado conforme o cronograma.

As atualizações do Ethereum exigem especificações, implementações de clientes, redes de teste, revisões de segurança e coordenação entre os participantes. Um strawmap é um mapa de pesquisa e marcos candidatos, não uma promulgação onchain. Pode-se verificar que o PeerDAS está implantado observando o lançamento do Fusaka e as regras atuais dos nós. Não se pode verificar um futuro zkEVM de camada base geral observando a coluna azul de 2030 de um ensaio. As evidências chegarão primeiro em especificações e testes públicos, depois em um plano de fork concreto e ativação em produção.

O argumento a favor da abordagem de Buterin é forte. Se a verificação se tornar barata e os dados puderem ser amostrados com segurança, mais usuários poderão verificar independentemente um sistema maior sem comprar máquinas proporcionais a toda a sua computação e dados. O desafio é igualmente real: a pilha de provas deve ser segura, produzida de forma competitiva e rápida o suficiente para manter o sistema ativo, enquanto os dados e a ordenação permanecem acessíveis. Uma rede com verificação barata, mas com um único provador ou sequenciador indispensável, ainda pode ser frágil.

O ensaio não define quem construirá cada prova ou qual sistema de prova vencerá. Ele identifica um teste que importa para os usuários: um participante independente comum pode rejeitar um resultado ruim, recuperar os dados necessários para conhecer seu próprio estado e enviar uma transação apesar de qualquer operador individual? Cada resposta exige um mecanismo separado. A verificação criptográfica é poderosa justamente porque pode ser repetida por pessoas que não fizeram o trabalho pesado.

O que observar

• Especificações da zkEVM de Camada 1. Procure por um verificador concreto, formato de entrada público e regras de execução aceitas entre os clientes.
• Diversidade de provers. Múltiplas implementações independentes e necessidades de hardware medidas testarão se a produção de provas tem um único ponto de estrangulamento.
• Medições do PeerDAS. Verifique a taxa de transferência de blobs e a largura de banda dos nós à medida que os aumentos de parâmetros acompanham o lançamento de dezembro de 2025.
• Decisões do Hegota. Um escopo final de fork importa mais do que recursos candidatos em um rascunho de roteiro.
• Salvaguardas de dados e ordenação. Inspecione se os rollups e futuros designs da camada base preservam a reconstrução independente e a inclusão de transações.

Perguntas frequentes