Agradecimentos especiais a Fede, Danno Ferrin, Justin Drake, Ladislaus e Tim Beiko por seu feedback e revisão.

O objetivo do Ethereum é se tornar um livro-razão global - uma plataforma que transporta ativos e registros humanos, e é a camada subjacente para aplicativos como finanças, governança e verificação de dados de alto valor. Para alcançar esse objetivo, ele deve ter escalabilidade e resiliência. O plano de hard fork Fusaka aumentará o espaço de disponibilidade de dados L2 em 10 vezes, enquantoO cronograma proposto para 2026Também inclui uma escala semelhante de expansão de dados L1. Enquanto isso, 'The Merge' atualizou o Ethereum para um mecanismo de consenso de prova de participação (PoS).A diversidade de clientes está aumentando rapidamente, A verificabilidade ZK (Prova de Conhecimento Zero) e a resistência aos ataques quânticos também estão avançando constantemente, e o ecossistema de aplicativos está cada vez maisMaduro e robusto.

O objetivo deste artigo é enfatizar um aspecto igualmente crítico, mas frequentemente subestimadoResiliência (e, em última análise, escalabilidade)Elementos:
Simplicidade do protocolo.

Um dos aspectos mais elogiados do Bitcoin é o design de seu protocolo, que é extremamente elegante e simples:

O sistema é um blockchain, composto por uma série de blocos. Cada bloco está ligado ao anterior através de um hash. A validade de cada bloco é verificada através do Proof of Work (PoW), o que significa... você só precisa verificar se os dígitos principais do seu hash são zeros. Cada bloco contém transações, que gastam as moedas obtidas através da mineração, ou gastam as moedas resultantes de transações anteriores. Basicamente é isso.
Mesmo um aluno inteligente do ensino médio tem a capacidade de entender completamente os princípios de operação do protocolo Bitcoin. E um programador pode até desenvolver um cliente Bitcoin como um projeto de hobby.

Manter o protocolo simples traz uma série de vantagens-chave, potencialmente tornando o Bitcoin e o EthereumNeutralidade confiávelA camada fundamental da confiança global:

• Tornar a lógica do protocolo mais fácil de entender, expandir o grupo que pode participar da pesquisa, desenvolvimento e governança do protocolo, diminuir as barreiras técnicas e evitar a dominação de uma 'classe burocrática tecnológica' no protocolo.
• Reduza significativamente o custo de desenvolvimento de nova infraestrutura integrada com protocolos (como novos clientes, novos verificadores, novas ferramentas de registro, etc.).
• Reduza o custo de manutenção a longo prazo do protocolo.
• Reduzindo o risco de vulnerabilidades catastróficas, quer nas especificações de protocolo ou no código de implementação; também torna mais fácil verificar que o protocolo não contém tais vulnerabilidades.
• Reduza a superfície de ataque social: quanto menos componentes, menos lugares podem ser explorados e controlados por partes interessadas específicas.

No passado, a Ethereum não se saiu bem neste aspecto (às vezes até por causa das minhas decisões pessoais), o que levou a nossos gastos excessivos com desenvolvimento,@vbuterin/selfdestruct”>Vários riscos de segurança e a natureza fechada da cultura de P&D, e esses esforços muitas vezes só trazem retornos ilusórios.
Este artigo explicará como o Ethereum poderia alcançar um nível de simplicidade próximo ao do Bitcoin em cinco anos.

Camada de Consenso Simplificado

3-slot finality（3槽终结性）模拟图 — 3sf-mini

O novo design da camada de consenso (anteriormente conhecido como ‘cadeia de feixes’) tem como objetivo integrar a experiência que acumulamos na teoria do consenso, desenvolvimento ZK-SNARK, economia de staking e outras áreas ao longo da última década, para criar uma camada de consenso Ethereum ideal a longo prazo. Esta nova camada de consenso, em comparação com a Beacon Chain existente, espera alcançar maior simplicidade. Isso é particularmente evidente em:

• reestruturação final de 3 slots
  Este design elimina a distinção entre 'slot' e 'epoch', a reorganização do comitê e outros detalhes de especificação de protocolo relacionados a esses mecanismos (como comitês síncronos). Uma versão básica de finalização de 3 slot,Apenas cerca de 200 linhas de código são necessáriasIsso pode ser alcançado. Comparado ao protocolo Gasper atual, finalidade de 3 slots também tem segurança próxima à ótima.
• O número de validadores ativos diminuiu
  Torna mais seguro e viável adotar uma regra de escolha de fork mais simples.
• Protocolo de agregação baseado em STARK
  Significa que qualquer pessoa pode se tornar um agregador sem se preocupar em confiar no agregador, taxas excessivas para campos de bits repetidos, etc. Embora a criptografia de agregação em si tenha uma certa complexidade, issoComplexidade altamente encapsuladaO risco sistêmico geral do protocolo é muito menor.
• Os dois pontos acima também são provavelmente para apoiar uma arquitetura mais simples e robusta de peer-to-peer (p2p).
• Temos a oportunidade de repensar os mecanismos de entrada, saída, retirada, troca de chave, penalidade de inércia, etc., e simplificá-los— não apenas reduzindo o número de linhas de código (LoC), mas também fornecendo garantias de mecanismo mais claras, como um prazo de 'subjetividade fraca' mais explícito.

A vantagem da camada de consenso é que ela está relativamente desacoplada da execução do EVM, então temos muito espaço para continuar impulsionando essas melhorias.
Mais desafiador é: como alcançar a mesma simplificação na camada de execução.

Simplificar Camada de Execução

A complexidade da Máquina Virtual Ethereum (EVM) está continuamente aumentando, e grande parte dessa complexidade tem se mostrado desnecessária (muitas vezes relacionada às minhas decisões pessoais): temos uma máquina virtual de 256 bits que é excessivamente otimizada para formas criptográficas muito específicas, as quais agora estão gradualmente sendo marginalizadas; e alguns contratos precompilados focam excessivamente em poucos casos de uso únicos.

Tentar resolver gradualmente esses problemas práticos não é viável.Remover @vbuterinA instrução SELFDESTRUCT consome uma quantidade enorme de energia, mas os resultados são limitados. O recente debate sobre EOF (Formato de Objeto EVM) demonstra ainda mais a dificuldade de fazer mudanças semelhantes na máquina virtual.

Portanto, como alternativa, recentemente propus uma ideia mais radical: em vez de fazer mudanças incrementais (mas ainda destrutivas) para uma melhoria de 1,5 vezes, é melhor migrar diretamente para uma máquina virtual totalmente nova, muito superior e mais simples, visando um retorno de 100 vezes. Assim como ‘The Merge,’ reduzimos o número de transformações, mas cada uma é significativa. Especificamente, sugiro substituir o EVM existente pelo RISC-V (ou outra máquina virtual que será usada pelo provador ZK do Ethereum). Dessa forma, conseguiremos:

• Melhoria significativa na eficiência: porque os contratos inteligentes podem ser executados diretamente no prover sem o custo adicional de um intérprete. Dados sucintos indicam que o desempenho pode ser melhorado em mais de 100 vezes em muitos cenários.
• Simplicidade máxima: comparado ao EVM, especificação RISC-VExtremamente simples. Outras soluções alternativas (como Cairo) são igualmente concisas.
• Herdando as vantagens esperadas do EOF: como segmentação de código, análise estática mais amigável, limite de capacidade de código maior, etc.
• Os desenvolvedores têm mais opções: Solidity e Vyper podem ser compilados para o novo backend da máquina virtual. Se o RISC-V for escolhido, os desenvolvedores de linguagens mainstream também podem facilmente portar seu código.
• Reduza significativamente a necessidade de pré-compilação: possivelmente mantendo apenas algumas operações de curva elíptica altamente otimizadas (embora essas não existam mais quando a computação quântica se tornar popular).

A principal desvantagem deste enfoque é que, ao contrário do EOF (implementação imediata), a nova máquina virtual leva mais tempo para beneficiar os desenvolvedores. Para mitigar isso, podemos introduzir algumas melhorias EVM pequenas, mas de alto valor, a curto prazo.Aumentar o limite de tamanho do código do contrato、Aumentar as instruções DUP/SWAP17-32, etc.)

No final, isso nos dará uma máquina virtual muito simplificada. Mas a maior questão é: o que acontecerá com o EVM existente?

Estratégia de compatibilidade retroativa transitória do VM

Ao simplificar significativamente (ou mesmo apenas melhorar sem adicionar complexidade) qualquer parte da Máquina Virtual Ethereum (EVM), o maior desafio é: como manter a compatibilidade com versões anteriores com as aplicações existentes ao atingir o objetivo.

Primeiramente, deve ficar claro que não há uma única maneira de definir o escopo da "base de código Ethereum" (mesmo dentro do mesmo cliente).

O objetivo é minimizar o escopo da área verde o máximo possível: isto é, a lógica que os nós devem executar para participar do consenso Ethereum, incluindo o cálculo do estado atual, prova, validação, FOCIL (Camada de Integridade de Consenso de Primeira Ordem), construção básica de blocos, etc.

A área laranja não pode ser reduzida: se um determinado recurso da camada de execução (seja uma máquina virtual, pré-compilação ou outro mecanismo) for removido da especificação do protocolo, ou se sua funcionalidade for alterada, o cliente envolvido no processamento de blocos históricos ainda deve mantê-lo - mas, o que é importante, novos clientes (como ZK-EVMs ou verificadores formais) podem ignorar completamente a área laranja.

A nova categoria é a área amarela: este tipo de código é muito importante para entender e analisar o estado atual da cadeia, e para construir os melhores blocos, mas não faz parte do consenso. Um exemplo é Etherscan(E algunsConstrutor de Blocos) Suporte para operações de usuário ERC-4337. Se usarmos a implementação RISC-V on-chain para substituir certas funções grandes do Ethereum (como contas EOA e seu suporte para vários tipos antigos de transações), então, apesar da simplificação significativa do código de consenso, alguns nós profissionais ainda podem continuar a usar o código original para analisar essas funções.

É importante que as áreas laranja e amarela pertençam à “Gate”Complexidade de EncapsulamentoQualquer pessoa que deseje entender o protocolo pode ignorá-los, os clientes do Ethereum também podem optar por não implementá-los e bugs nessas áreas não representarão um risco de consenso. Isso significa que a complexidade do código e o impacto negativo trazido pelas áreas laranja e amarela são muito menores do que a área verde.

Transferir o código da zona verde para a zona amarela, esta abordagem é semelhante à Apple Inc.Traduza através da camada de tradução RosettaPara garantir compatibilidade de longo prazo.

Eu propus (emprestado de@ipsilon/eof-ethereums-gateway-to-risc-v”> As recentes visões da equipe da Ipsilon) O seguinte processo de migração de máquina virtual (usando a migração do EVM para RISC-V como exemplo, mas também aplicável à migração do EVM para Cairo e até mesmo à migração futura para uma VM mais ótima):

1. Todos os novos precompilados devem ser escritos na implementação padrão on-chain do RISC-V, para que o ecossistema possa começar a se familiarizar e usar o RISC-V como a máquina virtual.
2. Apresentando RISC-V como uma opção para o desenvolvimento de contratos em paralelo ao EVM para os desenvolvedores. O protocolo suporta nativamente tanto o RISC-V quanto o EVM, permitindo que os contratos escritos em ambos os idiomas interajam livremente.
3. Substituir todos os pré-compilados (exceto operações de curva elíptica e KECCAK) por implementação RISC-V. Removemos esses pré-compilados por meio de um hard fork e, ao mesmo tempo, alteramos o código no endereço correspondente (estilo fork DAO) para ser uma implementação RISC-V. Como a VM RISC-V é extremamente concisa, apenas fazer isso já simplifica a estrutura geral.
4. Implemente um interpretador EVM escrito em RISC-V e implante-o como um contrato inteligente na cadeia. Após vários anos do lançamento inicial, os contratos EVM existentes serão processados por meio deste interpretador.

Após a conclusão do passo 4, ainda haverá muitas 'implementações EVM' continuando a ser usadas para otimizar a construção de blocos, ferramentas de desenvolvimento e análise on-chain, mas elas não farão mais parte das especificações de consenso principais. Nesse momento, o consenso do Ethereum 'nativamente' só entenderá o RISC-V.

Simplificar compartilhando componentes de protocolo

O terceiro método de simplificação, e talvez o mais subestimado, é compartilhar um padrão unificado em várias partes da pilha de protocolos, tanto quanto possível. Geralmente, não há razão para usar diferentes protocolos para o mesmo propósito em cenários diferentes, mas essa situação ainda ocorre com frequência na realidade, principalmente devido à falta de comunicação entre diferentes partes do roteiro do protocolo. Aqui estão alguns exemplos específicos de simplificação do Ethereum através da 'maximização do compartilhamento de componentes':

Um código de apagamento unificado

Precisamos corrigir o código de exclusão em três cenários:

• Amostragem de disponibilidade de dados - O cliente verifica se o bloco foi publicado
• Transmissão P2P mais rápida - Os nós podem aceitar blocos após receberem n/2 de n blocos, estabelecendo assim o equilíbrio ideal entre redução de latência e redundância.
• Armazenamento Distribuído de Histórico - Cada pedaço de história do Ethereum é armazenado em muitos blocos, então (i) esses blocos podem ser verificados de forma independente e (ii) metade dos blocos em cada grupo pode recuperar a outra metade, reduzindo significativamente o risco de perda de qualquer bloco único.

Se usarmos o mesmo código de apagamento (seja Reed-Solomon, código linear aleatório ou outro) em três casos de uso, obteremos algumas vantagens importantes:

1. Minimizar o total de linhas de código
2. Melhore a eficiência porque se cada nó precisar baixar várias partes de um bloco para um caso de uso (em vez de baixar o bloco inteiro), os dados podem ser usados para outro caso de uso
3. Garantir Verificabilidade: Todos os três blocos no contexto podem ser verificados com base na raiz

Se forem de fato necessários diferentes códigos de correção de erro, a 'compatibilidade' deve ser garantida pelo menos: por exemplo, no cenário de DAS, Reed-Solomon é usado horizontalmente e o código linear aleatório é usado verticalmente, mas ambos são baseados no mesmo campo matemático.

Um formato de serialização unificado

Atualmente, o formato de serialização do Ethereum é estritamente falando, apenas "semi-padronizado", pois os dados podem ser re-serializados e transmitidos em qualquer formato. A única exceção é o hash de assinatura da transação, onde um formato padronizado é necessário para o cálculo do hash.
Mas a padronização dos formatos de serialização futuros será ainda mais aprimorada, por duas razões:

• Abstração de Conta Abrangente (EIP-7701): A máquina virtual será capaz de ver o conteúdo completo da transação
• Aumento do limite de gás: Execute os dados do bloco que precisam ser empacotados em blob

Naquele momento, temos a oportunidade de unificar as soluções de serialização necessárias para os atuais três aspectos: 1) camada de execução; 2) camada de consenso; 3) ABI de invocação de contrato inteligente.

Eu sugiro adotar SSZ(Simple Serialize), porque SSZ tem as seguintes vantagens:

• Fácil de decodificar: incluindo dentro de contratos inteligentes (com base no design de 4 bytes, poucos casos limite)
• Amplamente utilizado em consenso
• Altamente semelhante ao ABI existente: baixo custo de migração de ferramentas

Atualmente, mais componentes foramMigraçãoPara SSZTrabalhoAo planejar futuras atualizações, devemos considerar e utilizar plenamente esses desenvolvimentos.

Uma estrutura de árvore unificada

Uma vez que migramos do EVM para o RISC-V (ou outro VM minimalista), a árvore de Merkle Patricia hexadecimal se tornará o maior gargalo para provar a execução do bloco, mesmo em cenários médios. Migrar para uma função hashÁrvore Binária, melhorará significativamente a eficiência do verificador e reduzirá o custo de dados de nós leves e outros cenários.

Ao concluir a migração da estrutura de árvore, também devemos garantir que a camada de consenso utilize a mesma estrutura de árvore para garantir que todo o Ethereum - tanto as camadas de consenso quanto de execução - possam ser acessadas e analisadas usando o mesmo conjunto de códigos.

Do presente para o futuro

Simplificação e descentralização têm muitas semelhanças. Ambas são requisitos primordiais necessários para alcançar o objetivo maior de resiliência do sistema. Enfatizar a simplificação explicitamente requer uma mudança cultural. Os benefícios da simplificação muitas vezes são difíceis de ver nas fases iniciais, mas os custos de oportunidade e a carga de trabalho adicional de rejeitar esses 'novos recursos brilhantes' são imediatamente evidentes. No entanto, com o tempo, o valor a longo prazo da simplificação se torna cada vez mais evidente - o próprio Bitcoin é um excelente exemplo.

Eu sugiro que nósAprenda com a abordagem do tinygradPara definir um objetivo claro de limite de linha de código para a especificação de longo prazo do Ethereum, o objetivo é tornar o código crítico de consenso do Ethereum o mais próximo possível do estilo minimalista do Bitcoin. O código que lida com as regras históricas do Ethereum ainda existirá, mas deve ser isolado do caminho crítico de consenso. Ao mesmo tempo, devemos formar um princípio de design universal: escolher soluções mais simples sempre que possível, priorizar a complexidade encapsulada sobre a complexidade sistêmica e tender para decisões de design que oferecem propriedades e garantias claras e verificáveis.

Aviso legal:

1. Este artigo é reproduzido de [vitalik]. Todos os direitos autorais pertencem ao autor original [vitalikTudo. Se você tiver alguma objeção a esta reimpressão, entre em contatoGate LearnA equipe lidará com isso de forma oportuna.
2. Aviso Legal: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. A equipe do Gate Learn traduz artigos para outros idiomas. Copiar, distribuir ou plagiar artigos traduzidos é proibido, exceto quando especificado de outra forma.