Vitalik Buterin admite o seu maior erro de design desde 2017 – então o seu Ethereum está em risco?

Vitalik Buterin disse que já não concorda com o seu tweet de 2017 que minimizava a necessidade de os utilizadores verificarem pessoalmente o Ethereum de ponta a ponta.

Esta semana, argumentou que a rede deve tratar a verificação auto-hospedada como uma saída de emergência inegociável à medida que a sua arquitetura se torna mais leve e modular.

A posição original de Buterin surgiu de um debate de design sobre se uma blockchain deve comprometer-se com o estado on-chain ou tratar o estado como "implícito", reconstruível apenas através da repetição de transações ordenadas.

A abordagem do Ethereum, colocando uma raiz de estado em cada cabeçalho de bloco e suportando provas no estilo Árvore de Merkle, permite que um utilizador prove um saldo específico, código de contrato ou valor de armazenamento sem re-executar todo o histórico, desde que o utilizador aceite a validade do consenso da chain sob uma suposição de maioria honesta.

Na sua nova publicação, Buterin reformulou esse compromisso como incompleto na prática porque ainda pode encurralar os utilizadores a escolher entre repetir a chain completa ou confiar num intermediário, como um operador RPC, um host de dados de arquivo ou um serviço de prova.

A mudança de posição de Vitalik sobre a verificação pessoal do histórico da blockchain

Ele ancorou a mudança em duas alterações: viabilidade e fragilidade.

Sobre a viabilidade, Buterin escreveu que as Provas de conhecimento zero agora oferecem um caminho para verificar a correção sem "literalmente re-executar cada transação".

Em 2017, argumentou que isso teria empurrado o Ethereum para uma capacidade inferior para manter a verificação ao alcance.

A mudança é importante porque o roteiro público do Ethereum trata cada vez mais o ZK como uma primitiva de verificabilidade, com o ethereum.org enquadrando as Provas de conhecimento zero como uma forma de preservar as propriedades de segurança enquanto reduz o que um verificador deve computar.

O trabalho em direções de "cliente leve ZK" também aponta para um modelo onde um dispositivo pode sincronizar usando provas compactas em vez de confiar num gateway sempre online.

Sobre a fragilidade, Buterin listou modos de falha que ficam fora dos modelos de ameaça limpos: rede p2p degradada, serviços de longa duração a encerrar, concentração de validadores que muda o significado prático de "maioria honesta" e pressão de governança informal que transforma "ligar aos programadores" no recurso final.

Citou a pressão de censura em torno do Tornado Cash como exemplo de como os intermediários podem restringir o acesso, argumentando que a opção de último recurso de um utilizador deve ser "usar diretamente a chain".

Esse enquadramento acompanha uma discussão mais ampla sobre o reforço da camada base do Ethereum e a limitação de mudanças, em meio a um impulso em direção à "ossificação" do protocolo.

Na narrativa de Buterin, a "cabana na montanha" não é um estilo de vida predefinido.

É um recurso credível que altera os incentivos, porque o conhecimento de que os utilizadores podem sair reduz a alavancagem de qualquer camada de serviço individual.

Esse argumento surge enquanto o Ethereum reduz o que se espera que os nós comuns armazenem, enquanto a história de verificação da rede tem de acompanhar o ritmo.

Uso e histórico de clientes Ethereum

Os clientes de execução estão a avançar para a expiração parcial do histórico, e a Ethereum Foundation disse que os utilizadores podem reduzir o uso de disco em cerca de 300–500 GB ao remover dados de blocos pré-Merge, colocando um nó ao alcance num disco de 2 TB.

Ao mesmo tempo, os clientes leves já refletem um modelo de confiança formalizado otimizado para dispositivos de baixos recursos, dependendo de um comité de sincronização de 512 validadores selecionados aproximadamente a cada 1,1 dias.

Esses parâmetros tornam a verificação de cliente leve viável em escala.

No entanto, também concentram a experiência do utilizador em torno da disponibilidade de dados corretos e relés bem comportados quando as condições se deterioram.

O trabalho de "ausência de estado" a longo prazo do Ethereum visa reduzir a necessidade de os nós manterem um grande estado enquanto mantêm intacta a validação de blocos.

O Ethereum.org adverte que "ausência de estado" é um termo incorreto, distinguindo formas mais fracas de designs mais fortes que permanecem em investigação, incluindo expiração de estado.

As árvores Verkle inserem-se nesse plano porque reduzem os tamanhos das provas e estão posicionadas como um passo crucial para validar sem armazenar um grande estado localmente.

À medida que mais da carga de armazenamento se desloca para o exterior, seja para hosts de histórico especializados ou outras redes de dados, a história de segurança torna-se menos sobre quem pode armazenar tudo e mais sobre quem pode verificar independentemente a correção e recuperar o que precisa quando um caminho predefinido falha.

O que isto significa daqui para a frente

Nos próximos 12–36 meses, a questão prática é se a verificação se expande para o exterior à medida que o Ethereum externaliza mais cargas de armazenamento, ou se a confiança se agrupa em torno de novos pontos de estrangulamento de serviços.

Um caminho é que as carteiras e infraestrutura mudem de "confiar no RPC" para "verificar a prova", enquanto a produção de provas se consolida num pequeno conjunto de pilhas otimizadas que são difíceis de replicar, movendo a dependência de uma classe de fornecedor para outra.

Outro caminho é que a verificação baseada em provas se torne comum, com implementações de prova redundantes e ferramentas que permitem aos utilizadores trocar de fornecedores ou verificar localmente quando um endpoint censura, degrada ou desaparece, alinhando-se com esforços direcionados a fluxos de verificação leves.

Um terceiro caminho é que a poda e modularidade progridam mais rapidamente do que a UX de verificação, deixando os utilizadores com menos opções viáveis durante interrupções ou eventos de censura.

Isso tornaria a "cabana na montanha" operacionalmente real apenas para uma fatia estreita da rede.

Buterin enquadrou a cabana como a BATNA do Ethereum, raramente usada mas sempre disponível, porque a existência de uma opção auto-suficiente restringe os termos impostos pelos intermediários.

Concluiu argumentando que manter esse recurso faz parte da manutenção do próprio Ethereum.

A publicação Vitalik Buterin admite o seu maior erro de design desde 2017 – então o seu Ethereum está em risco? apareceu primeiro no CryptoSlate.