Um agradecimento especial a Fede, Danno Ferrin, Justin Drake, Ladislaus e Tim Beiko pelo seu feedback e revisão.

O objetivo do Ethereum é tornar-se um livro-razão global - uma plataforma que transporta ativos e registos humanos, e é a camada subjacente para aplicações como finanças, governação e verificação de dados de alto valor. Para alcançar este objetivo, é necessário ter escalabilidade e resiliência. O plano de hard fork Fusaka aumentará o espaço de disponibilidade de dados L2 em 10 vezes, enquantoA proposta de roteiro de 2026Inclui também uma escala semelhante de expansão de dados L1. Entretanto, 'The Merge' atualizou o Ethereum para um mecanismo de consenso de prova de participação (PoS).A diversidade de clientes está a aumentar rapidamente, A verificação de prova de conhecimento zero (Zero-Knowledge Proof) e a resistência aos ataques quânticos também estão a progredir de forma constante, e o ecossistema de aplicações está a crescer cada vez maisMaduro e robusto.

O objetivo deste artigo é enfatizar algo 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 do 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 de Proof of Work (PoW), o que significa... só precisa de 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 geradas a partir de transações anteriores. É basicamente isto.
Mesmo um aluno inteligente do ensino médio tem a capacidade de compreender plenamente os princípios de funcionamento do protocolo Bitcoin. E um programador até pode desenvolver um cliente Bitcoin como 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 na pesquisa, desenvolvimento e governação do protocolo, baixar as barreiras técnicas e evitar a dominação de uma 'classe burocrática tecnológica' no protocolo.
• Reduzir 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 do protocolo ou no código de implementação; também torna mais fácil verificar que o protocolo não contém tais vulnerabilidades.
• Reduzir a superfície de ataque social: quanto menos componentes, menos lugares que podem ser explorados e controlados por partes interessadas específicas.

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

Camada de Consenso Simplificada

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 ótima a longo prazo. Esta nova camada de consenso, em comparação com a atual Beacon Chain, espera-se que alcance uma maior simplicidade. Isto é especialmente 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 com estes mecanismos (como comités síncronos). Uma versão básica de finalidade de 3 slots,Apenas cerca de 200 linhas de código são necessáriasPode ser alcançado. Comparado com o protocolo Gasper atual, a finalidade de 3 slots também tem segurança próxima do ideal.
• 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 tornar-se um agregador sem se preocupar em confiar no agregador, em taxas excessivas para campos de bits repetidos, etc. Embora a própria encriptação de agregação tenha uma certa complexidade, issoComplexidade altamente encapsuladaO risco sistemático global do protocolo é muito menor.
• Os dois pontos acima também são susceptíveis de apoiar uma arquitetura peer-to-peer (p2p) mais simples e robusta.
• Temos a oportunidade de repensar os mecanismos de entrada de validadores, saída, retirada, troca de chaves, 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 está relativamente desacoplada da execução do EVM, então temos muito espaço para continuar a promover essas melhorias.
Mais desafiante é: 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 a aumentar, e grande parte desta complexidade tem-se revelado desnecessária (muitas vezes também relacionada com as minhas decisões pessoais): temos uma máquina virtual de 256 bits que está excessivamente otimizada para formas criptográficas muito específicas, que agora estão a ser gradualmente marginalizadas; e alguns contratos pré-compilados focam excessivamente em muito poucos casos de uso individuais.

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

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

• Melhoria significativa da eficiência: porque os contratos inteligentes podem ser executados diretamente no provador sem a sobrecarga 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 escolhas: Solidity e Vyper podem ser compilados para o novo backend da máquina virtual. Se for escolhido o RISC-V, os desenvolvedores de linguagens mainstream também podem facilmente portar seu código.
• Reduzir significativamente a necessidade de pré-compilação: possivelmente mantendo apenas algumas operações de curva elíptica altamente otimizadas (embora estas deixem de existir uma vez que a computação quântica se torne popular).

A principal desvantagem deste método é que, ao contrário do EOF (implementação imediata), a nova máquina virtual demora mais tempo a beneficiar os programadores. Para mitigar isto, 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, isto dar-nos-á uma máquina virtual muito simplificada. Mas a maior questão é: o que acontece com o EVM existente?

Estratégia de compatibilidade regressiva transitória da VM

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

Em primeiro lugar, deve ficar claro que não há uma única maneira de definir o âmbito da “base de código do Ethereum” (mesmo dentro do mesmo cliente).

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

A área laranja não pode ser reduzida: se uma determinada funcionalidade da camada de execução (seja uma máquina virtual, pré-compilação ou outro mecanismo) for removida da especificação do protocolo, ou se sua funcionalidade for alterada, o cliente responsável pelo processamento de blocos históricos ainda deve mantê-la - mas, é importante notar que 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 compreender 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 significativa simplificação 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 compreender o protocolo pode ignorá-los, os clientes Ethereum também podem optar por não os implementar, e os 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.Traduzir através da camada de tradução RosettaPara garantir compatibilidade a longo prazo.

Propus (emprestado de@ipsilon/eof-ethereums-gateway-to-risc-v”> As recentes opiniões da equipa 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 o 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 o 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 ambas as linguagens interajam livremente.
3. Substituir todas as pré-compilações (exceto operações de curva elíptica e KECCAK) por implementação RISC-V. Removemos essas pré-compilações através de um hard fork e ao mesmo tempo alteramos o código no endereço correspondente (estilo DAO fork) para ser uma implementação RISC-V. Como a VM RISC-V é extremamente concisa, mesmo fazendo apenas isso simplifica a estrutura geral.
4. Implementar um interpretador EVM escrito em RISC-V e implementá-lo como um contrato inteligente na cadeia. Após vários anos do lançamento inicial, os contratos EVM existentes serão processados através deste interpretador.

Após concluir o passo 4, ainda haverá muitas 'implementações EVM' em curso 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-chave. Nesse momento, o consenso do Ethereum 'nativamente' só entenderá RISC-V.

Simplificar partilhando componentes de protocolo

O terceiro, e talvez o método de simplificação mais subestimado, é partilhar um padrão unificado em várias partes do protocolo tanto quanto possível. Normalmente, não há razão para usar diferentes protocolos para o mesmo propósito em diferentes cenários, mas esta situação ainda ocorre frequentemente na realidade, principalmente devido a uma 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 da partilha 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 a redução da latência e a redundância.
• Armazenamento Distribuído de Histórico - Cada pedaço da história do Ethereum é armazenado em muitos blocos, de modo que (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 ele 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ó tiver que baixar várias partes de um bloco para um caso de uso (em vez do 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 realmente necessários códigos de correção de erros diferentes, pelo menos deve ser garantida a 'compatibilidade': por exemplo, no cenário 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 poderá ver o conteúdo completo da transação
• Aumento do limite de gás: Execute os dados do bloco precisam ser empacotados em blob

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

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

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

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

Uma estrutura de árvore unificada

Uma vez que migrarmos do EVM para o RISC-V (ou outro VM minimalista), a árvore de Merkle Patricia hexadecimal se tornará o maior gargalo para comprovar a execução do bloco, mesmo em cenários médios. Migrar para uma função de hashÁrvore Binária, irá 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 - possa ser acessado e analisado utilizando o mesmo conjunto de códigos.

Do presente para o futuro

A simplificação e a descentralização têm muitas semelhanças. Ambas são requisitos iniciais necessários para atingir o objetivo mais elevado da resiliência do sistema. Enfatizar a simplificação explicitamente requer uma mudança cultural. Os benefícios da simplificação são frequentemente difíceis de ver nas fases iniciais, mas os custos de oportunidade e a carga de trabalho adicionais de rejeitar essas “novas funcionalidades brilhantes” são imediatamente evidentes. No entanto, ao longo do tempo, o valor a longo prazo da simplificação torna-se 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 inclinar-se para decisões de design que forneçam 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 tiver alguma objeção a esta reimpressão, por favor contacteGate LearnA equipa irá 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 equipa Gate Learn traduz artigos para outras línguas. Copiar, distribuir ou plagiar artigos traduzidos é proibido, exceto se indicado de outra forma.