O Ethereum visa se tornar um livro-razão global, necessitando de escalabilidade e resiliência. Este artigo foca na importância da simplicidade do protocolo, propondo uma significativa redução da complexidade através da simplificação da camada de consenso (finalidade de 3 slots, agregação STARK) e da camada de execução (substituindo EVM por RISC-V ou uma máquina virtual similar), diminuindo os custos de desenvolvimento, riscos de erros e superfícies de ataque. Recomenda-se uma transição suave através de uma estratégia de compatibilidade retroativa (como um interpretador EVM on-chain) e unificação de códigos de correção de erros, formatos de serialização (SSZ) e estruturas de árvore para simplificação adicional. O objetivo é aproximar o código crítico de consenso do Ethereum da simplicidade do Bitcoin, aumentando a resiliência e a participação, sendo necessário valorizar a simplicidade culturalmente e estabelecer um objetivo máximo de linhas de código.
O objetivo do Ethereum é se tornar um livro-razão global: uma plataforma para armazenar ativos e registros da civilização humana, servindo aos campos de finanças, governança e certificação de dados de alto valor. Isso requer dois suportes: escalabilidade e resiliência. **O hard fork Fusaka está planejado para aumentar o espaço disponível para dados L2 por um fator de 10, e o roteiro atualmente proposto para 2026 planeja trazer um impulso igualmente significativo para a camada L1. Ao mesmo tempo, o Ethereum completou a transição para prova de participação (PoS), a diversidade de clientes aumentou rapidamente, a verificação de conhecimento zero (ZK) e a pesquisa de resistência quântica também estão avançando constantemente, e o ecossistema de aplicativos está se tornando cada vez mais estável.
Este artigo visa focar em um elemento de resiliência (e até mesmo escalabilidade) que é igualmente importante, mas frequentemente subestimado: a simplicidade dos protocolos.
A parte mais impressionante do protocolo Bitcoin é a sua elegância e simplicidade:
Existe uma cadeia composta por blocos, onde cada bloco está ligado ao bloco anterior através de um hash.
A validade do bloco é verificada através da prova de trabalho (PoW), ou seja, verificando se os primeiros dígitos do hash são zeros.
Cada bloco contém transações, os tokens gastos nas transações vêm de recompensas de mineração ou de saídas de transações anteriores.
Isso é tudo! Mesmo um estudante de ensino médio inteligente pode compreender totalmente o funcionamento do protocolo Bitcoin, e um programador pode até escrever um cliente como um projeto de hobby.
A simplicidade do protocolo trouxe várias vantagens-chave para o Bitcoin (e Ethereum) se tornarem uma camada base global confiável e neutra:
1. Fácil de entender: Reduzir a complexidade do protocolo, permitindo que mais pessoas possam participar da pesquisa, desenvolvimento e governança do protocolo, diminuindo o risco de domínio da camada de elite técnica.
2. Reduzir os custos de desenvolvimento: Simplificar o protocolo reduz significativamente o custo de criação de novas infraestruturas (como novos clientes, provadores, ferramentas para desenvolvedores, etc.).
3. Reduzir a carga de manutenção: reduzir os custos de manutenção de contratos a longo prazo.
4. Reduzir o risco de erros: diminuir a probabilidade de erros catastróficos ocorrerem nas especificações e implementações dos protocolos, ao mesmo tempo em que facilita a verificação de que tais erros não existem.
5. Reduzir a superfície de ataque: diminuir os componentes complexos do protocolo, reduzindo o risco de ataques por grupos de interesses especiais.
Historicamente, o Ethereum (às vezes devido às minhas decisões pessoais) frequentemente falhou em manter a simplicidade, resultando em altos custos de desenvolvimento, aumento dos riscos de segurança e uma cultura de pesquisa e desenvolvimento fechada, enquanto os benefícios dessa busca pela complexidade muitas vezes se mostraram ilusórios. Este artigo irá explorar como o Ethereum, após cinco anos, se aproxima da simplicidade do Bitcoin.
Camada de Consenso Simplificada
O novo design da camada de consenso (historicamente conhecido como "Beacon Chain") visa aproveitar a experiência adquirida na última década em teoria de consenso, desenvolvimento de ZK-SNARK, economia de staking, entre outros, para construir uma camada de consenso a longo prazo, otimizada e mais simples. Em comparação com a Beacon Chain existente, o novo design simplifica significativamente:
1. Designação de finalização 3-slot: remoção dos conceitos de slot, época, reestruturação do comitê, entre outros, assim como mecanismos de processamento eficientes relacionados (como o comitê de sincronização). A implementação básica da finalização 3-slot requer apenas cerca de 200 linhas de código e, em comparação com Gasper, a segurança é quase ótima.
2. Reduzir o número de validadores ativos: Permitir a implementação de regras de seleção de forks mais simples para aumentar a segurança.
3. Protocólo de Agregação baseado em STARK: Qualquer pessoa pode tornar-se um agregador, sem necessidade de confiar no agregador ou pagar altos custos por campos de bit duplicados. A complexidade da criptografia de agregação é alta, mas essa complexidade é altamente encapsulada, resultando em um risco sistêmico mais baixo.
4. Simplificação da arquitetura P2P: Os fatores mencionados podem apoiar uma rede ponto a ponto mais simples e robusta.
5. Redesign do mecanismo de validadores: inclui mecanismos de entrada, saída, retirada, troca de chaves, vazamento de inatividade, etc., simplificando o número de linhas de código e oferecendo garantias mais claras (como períodos de fraca subjetividade).
A vantagem da camada de consenso reside na sua relativa independência em relação à camada de execução EVM, permitindo assim um maior espaço para melhorias contínuas. O maior desafio é como implementar uma simplificação semelhante na camada de execução.
Camada de Execução Simplificada
A complexidade do EVM está a aumentar, e muita dessa complexidade provou-se desnecessária (em parte devido a erros de decisão pessoais): a máquina virtual de 256 bits está excessivamente otimizada para formas criptográficas específicas que estão gradualmente a tornar-se obsoletas, e as pré-compilações (precompiles) estão otimizadas para um único caso de uso, mas raramente são utilizadas.
Resolver esses problemas um a um tem efeitos limitados. Por exemplo, a remoção do opcode SELFDESTRUCT exige um esforço enorme, mas traz apenas um pequeno benefício. As discussões recentes sobre o EOF (EVM Object Format) também mostram desafios semelhantes.
Recentemente, propus um plano mais radical: em vez de fazer alterações de médio porte (mas ainda destrutivas) no EVM em troca de um retorno de 1,5 vezes, seria melhor transitar para uma máquina virtual mais eficiente e simples, a fim de alcançar um retorno de 100 vezes. Semelhante à “fusão” (The Merge), reduzimos o número de alterações destrutivas, mas tornamos cada alteração mais significativa. Especificamente, sugiro substituir o EVM por RISC-V, ou outra máquina virtual usada pelo provedor de ZK do Ethereum. Isso traria:
1. Aumento significativo de eficiência: A execução de contratos inteligentes (no provedor de provas) não requer sobrecarga de interpretador, executando diretamente. Os dados da Succinct mostram que, em muitos cenários, o desempenho pode ser melhorado em mais de 100 vezes.
2. Melhoria significativa na simplicidade: A especificação RISC-V é extremamente simples em comparação com o EVM, e alternativas (como Cairo) também são igualmente simples.
3. Motivos para suportar EOF: como partição de código, análise estática mais amigável, limite de tamanho de código maior, etc.
4. Mais escolhas para desenvolvedores: Solidity e Vyper podem adicionar backend para compilar para a nova máquina virtual. Se escolher RISC-V, os desenvolvedores de linguagens mainstream também poderão facilmente portar o código para essa máquina virtual.
5. Remover a maior parte dos pré-compilados: pode apenas manter operações de curva elíptica altamente otimizadas (depois que os computadores quânticos se tornarem comuns, até essas desaparecerão).
O principal inconveniente é que, ao contrário do EOF já preparado, os benefícios da nova máquina virtual demoram mais a chegar aos desenvolvedores. Podemos mitigar esse problema através da implementação de melhorias de alto valor no EVM a curto prazo (como aumentar o limite de tamanho do código do contrato, suportar DUP/SWAP17-32).
Isso trará uma máquina virtual mais simples. O desafio central é: como lidar com o EVM existente?
Estratégia de compatibilidade retroativa para a transição de máquinas virtuais
O maior desafio de simplificar (ou melhorar sem aumentar a complexidade) a EVM é como equilibrar a realização dos objetivos com a compatibilidade retroativa das aplicações existentes.
Primeiro é necessário esclarecer: o repositório de código do Ethereum (mesmo dentro de um único cliente) não tem apenas uma forma de definição.
O objetivo é minimizar ao máximo a área verde: a lógica necessária para que os nós participem do consenso do Ethereum, incluindo o cálculo do estado atual, provas, validações, FOCIL (regras de escolha de bifurcação) e a construção de blocos "normais".
A área laranja não pode ser reduzida: se a especificação do protocolo remover ou alterar alguma funcionalidade da camada de execução (como máquinas virtuais, pré-compilados, etc.), o cliente que processa blocos históricos ainda precisará manter o código relacionado. No entanto, novos clientes, ZK-EVM ou provadores formais podem ignorar completamente a área laranja.
Nova área amarela: muito valiosa para entender a cadeia atual ou otimizar a construção de blocos, mas não pertence à lógica de consenso. Por exemplo, Etherscan e alguns construtores de blocos suportam operações de usuários ERC-4337. Se substituirmos certas funcionalidades do Ethereum (como EOA e seus tipos de transação antigos) por uma implementação RISC-V em cadeia, o código de consenso será significativamente simplificado, mas nós dedicados podem continuar a usar o código original para análise.
A complexidade das áreas laranja e amarela é a complexidade de encapsulamento. Aqueles que compreendem o protocolo podem pular essas partes; o Ethereum pode ignorá-las, e os erros nessas áreas não gerarão riscos de consenso. Portanto, a complexidade do código nas áreas laranja e amarela é muito menos prejudicial do que a complexidade na área verde.
A ideia de mover o código da área verde para a área amarela é semelhante à estratégia da Apple de garantir compatibilidade a longo prazo através da camada de tradução Rosetta.
Inspirado por um artigo recente da equipa Ipsilon, proponho o seguinte processo de alteração da máquina virtual (usando EVM para RISC-V como exemplo, mas também aplicável de EVM para Cairo ou de RISC-V para uma máquina virtual mais otimizada):
1. Exigir que a nova pré-compilação forneça a implementação RISC-V on-chain: permitir que o ecossistema se adapte gradualmente à máquina virtual RISC-V.
2. Introdução do RISC-V como opção para desenvolvedores: O protocolo suporta simultaneamente RISC-V e EVM, permitindo que os contratos das duas máquinas virtuais interajam livremente.
3. Substituição da maioria dos pré-compilados: Exceto para operações de curva elíptica e KECCAK (devido à necessidade de velocidade extrema), usar RISC-V para substituir outros pré-compilados. Remover os pré-compilados através de um hard fork, enquanto muda o código desse endereço (semelhante ao fork DAO) de vazio para a implementação RISC-V. A máquina virtual RISC-V é extremamente simples, mesmo que pare aqui, simplifica ainda mais o protocolo.
4. Implementação do interpretador EVM em RISC-V: como contratos inteligentes em cadeia (uma vez que o provador ZK precisa ser realizado). Após alguns anos da publicação inicial, contratos EVM existentes são executados através deste interpretador.
Após completar o passo 4, muitas "implementações EVM" ainda serão utilizadas para otimizar a construção de blocos, ferramentas para desenvolvedores e análise de cadeias, mas não serão mais parte das normas de consenso críticas. O consenso do Ethereum entenderá "nativamente" apenas RISC-V.
Simplificar através do componente de protocolo de compartilhamento
A terceira forma de reduzir a complexidade total do protocolo (também a mais subestimada) é compartilhar padrões unificados em diferentes partes da pilha do protocolo sempre que possível. Protocolos diferentes que fazem a mesma coisa em diferentes cenários geralmente não trazem benefícios, mas esse padrão ainda aparece com frequência, principalmente porque diferentes partes do roteiro do protocolo carecem de comunicação. Abaixo estão alguns exemplos concretos de simplificação do Ethereum através do compartilhamento de componentes.
Código de Correção e Exclusão Unificado
Precisamos de códigos de correção em três cenários:
1. Amostragem de disponibilidade de dados: O cliente verifica se o bloco foi publicado.
2. Transmissão P2P mais rápida: Os nós podem aceitar blocos após receber n/2 fragmentos, equilibrando atraso e redundância.
3. Armazenamento Histórico Distribuído: Os dados históricos do Ethereum são armazenados em fragmentos, onde cada grupo de n/2 fragmentos pode recuperar os outros fragmentos, reduzindo o risco de perda de um único fragmento.
Se usar o mesmo código de correção (seja Reed-Solomon, códigos lineares aleatórios, etc.) em três cenários diferentes, obterá as seguintes vantagens:
1. Minimizar a quantidade de código: reduzir o número total de linhas de código.
2. Aumentar a eficiência: se um nó baixar partes de um determinado cenário, esses dados podem ser utilizados em outros cenários.
3. Garantir a verificabilidade: Todos os fragmentos dos cenários podem ser verificados com base na raiz.
Se diferentes códigos de correção de erros forem utilizados, deve-se garantir pelo menos a compatibilidade, como os códigos Reed-Solomon de amostragem de disponibilidade de dados em nível e os códigos lineares aleatórios verticais operando no mesmo domínio.
Formato de Serialização Unificado
O formato de serialização do Ethereum está atualmente apenas parcialmente consolidado, pois os dados podem ser reserializados e transmitidos em qualquer formato. A exceção são os hashes de assinatura de transação, que precisam ser hashados em um formato padrão. No futuro, o grau de consolidação do formato de serialização aumentará ainda mais devido aos seguintes motivos:
1. Abstração completa da conta (EIP-7701): O conteúdo completo da transação é visível para a máquina virtual.
2. Limite de Gas mais alto: Os dados da camada de execução precisam ser inseridos em blocos de dados (blobs).
Na altura, teremos a oportunidade de unificar os formatos de serialização dos três níveis do Ethereum: camada de execução, camada de consenso e ABI de chamada de contrato inteligente.
Eu proponho o uso de SSZ, porque SSZ:
Fácil de decifrar: incluído dentro do contrato inteligente (devido ao seu design baseado em 4 bytes e menos casos extremos).
Já é amplamente utilizado na camada de consenso.
Muito semelhante ao ABI existente: a adaptação da ferramenta é relativamente simples.
Já existem esforços para uma migração completa para o SSZ, e devemos considerar e continuar esses esforços ao planejar futuras atualizações.
Estrutura de Árvore Unificada
Se a migração de EVM para RISC-V (ou outra máquina virtual mínima opcional) ocorrer, a árvore Merkle Patricia em hexadecimal se tornará o maior gargalo para provar a execução de blocos, mesmo em média. Migrar para uma árvore binária baseada em funções de hash mais eficientes aumentará significativamente a eficiência do provador, ao mesmo tempo que reduzirá o custo de dados em cenários como clientes leves.
Ao migrar, deve-se garantir que a camada de consenso utilize a mesma estrutura de árvore. Isso permitirá que a camada de consenso do Ethereum acesse e analise a camada de execução através do mesmo código.
Do agora ao futuro
A simplicidade é semelhante à descentralização em muitos aspectos, ambas sendo metas resilientes a montante. Valorizar claramente a simplicidade requer uma certa mudança cultural. Os benefícios são muitas vezes difíceis de quantificar, enquanto os custos de esforço adicional e a renúncia a certas funcionalidades chamativas são imediatos. No entanto, com o passar do tempo, os benefícios tornam-se cada vez mais evidentes — o próprio Bitcoin é um excelente exemplo.
Eu proponho seguir o tinygrad, estabelecendo um objetivo claro de número máximo de linhas de código para a norma de longo prazo do Ethereum, de modo a aproximar o código crítico do consenso do Ethereum da simplicidade do Bitcoin. O código que lida com as regras históricas do Ethereum continuará a existir, mas deve ser colocado fora do caminho crítico do consenso. Ao mesmo tempo, devemos manter a filosofia de escolher soluções mais simples, priorizando a encapsulação da complexidade em vez da complexidade sistêmica, e fazer escolhas de design que ofereçam atributos e garantias claras.
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Vitalik Blog: Como tornar o Ethereum daqui a 5 anos tão simples quanto o Bitcoin
Resumo
O Ethereum visa se tornar um livro-razão global, necessitando de escalabilidade e resiliência. Este artigo foca na importância da simplicidade do protocolo, propondo uma significativa redução da complexidade através da simplificação da camada de consenso (finalidade de 3 slots, agregação STARK) e da camada de execução (substituindo EVM por RISC-V ou uma máquina virtual similar), diminuindo os custos de desenvolvimento, riscos de erros e superfícies de ataque. Recomenda-se uma transição suave através de uma estratégia de compatibilidade retroativa (como um interpretador EVM on-chain) e unificação de códigos de correção de erros, formatos de serialização (SSZ) e estruturas de árvore para simplificação adicional. O objetivo é aproximar o código crítico de consenso do Ethereum da simplicidade do Bitcoin, aumentando a resiliência e a participação, sendo necessário valorizar a simplicidade culturalmente e estabelecer um objetivo máximo de linhas de código.
O objetivo do Ethereum é se tornar um livro-razão global: uma plataforma para armazenar ativos e registros da civilização humana, servindo aos campos de finanças, governança e certificação de dados de alto valor. Isso requer dois suportes: escalabilidade e resiliência. **O hard fork Fusaka está planejado para aumentar o espaço disponível para dados L2 por um fator de 10, e o roteiro atualmente proposto para 2026 planeja trazer um impulso igualmente significativo para a camada L1. Ao mesmo tempo, o Ethereum completou a transição para prova de participação (PoS), a diversidade de clientes aumentou rapidamente, a verificação de conhecimento zero (ZK) e a pesquisa de resistência quântica também estão avançando constantemente, e o ecossistema de aplicativos está se tornando cada vez mais estável.
Este artigo visa focar em um elemento de resiliência (e até mesmo escalabilidade) que é igualmente importante, mas frequentemente subestimado: a simplicidade dos protocolos.
A parte mais impressionante do protocolo Bitcoin é a sua elegância e simplicidade:
Existe uma cadeia composta por blocos, onde cada bloco está ligado ao bloco anterior através de um hash.
A validade do bloco é verificada através da prova de trabalho (PoW), ou seja, verificando se os primeiros dígitos do hash são zeros.
Cada bloco contém transações, os tokens gastos nas transações vêm de recompensas de mineração ou de saídas de transações anteriores.
Isso é tudo! Mesmo um estudante de ensino médio inteligente pode compreender totalmente o funcionamento do protocolo Bitcoin, e um programador pode até escrever um cliente como um projeto de hobby.
A simplicidade do protocolo trouxe várias vantagens-chave para o Bitcoin (e Ethereum) se tornarem uma camada base global confiável e neutra:
1. Fácil de entender: Reduzir a complexidade do protocolo, permitindo que mais pessoas possam participar da pesquisa, desenvolvimento e governança do protocolo, diminuindo o risco de domínio da camada de elite técnica.
2. Reduzir os custos de desenvolvimento: Simplificar o protocolo reduz significativamente o custo de criação de novas infraestruturas (como novos clientes, provadores, ferramentas para desenvolvedores, etc.).
3. Reduzir a carga de manutenção: reduzir os custos de manutenção de contratos a longo prazo.
4. Reduzir o risco de erros: diminuir a probabilidade de erros catastróficos ocorrerem nas especificações e implementações dos protocolos, ao mesmo tempo em que facilita a verificação de que tais erros não existem.
5. Reduzir a superfície de ataque: diminuir os componentes complexos do protocolo, reduzindo o risco de ataques por grupos de interesses especiais.
Historicamente, o Ethereum (às vezes devido às minhas decisões pessoais) frequentemente falhou em manter a simplicidade, resultando em altos custos de desenvolvimento, aumento dos riscos de segurança e uma cultura de pesquisa e desenvolvimento fechada, enquanto os benefícios dessa busca pela complexidade muitas vezes se mostraram ilusórios. Este artigo irá explorar como o Ethereum, após cinco anos, se aproxima da simplicidade do Bitcoin.
Camada de Consenso Simplificada
O novo design da camada de consenso (historicamente conhecido como "Beacon Chain") visa aproveitar a experiência adquirida na última década em teoria de consenso, desenvolvimento de ZK-SNARK, economia de staking, entre outros, para construir uma camada de consenso a longo prazo, otimizada e mais simples. Em comparação com a Beacon Chain existente, o novo design simplifica significativamente:
1. Designação de finalização 3-slot: remoção dos conceitos de slot, época, reestruturação do comitê, entre outros, assim como mecanismos de processamento eficientes relacionados (como o comitê de sincronização). A implementação básica da finalização 3-slot requer apenas cerca de 200 linhas de código e, em comparação com Gasper, a segurança é quase ótima.
2. Reduzir o número de validadores ativos: Permitir a implementação de regras de seleção de forks mais simples para aumentar a segurança.
3. Protocólo de Agregação baseado em STARK: Qualquer pessoa pode tornar-se um agregador, sem necessidade de confiar no agregador ou pagar altos custos por campos de bit duplicados. A complexidade da criptografia de agregação é alta, mas essa complexidade é altamente encapsulada, resultando em um risco sistêmico mais baixo.
4. Simplificação da arquitetura P2P: Os fatores mencionados podem apoiar uma rede ponto a ponto mais simples e robusta.
5. Redesign do mecanismo de validadores: inclui mecanismos de entrada, saída, retirada, troca de chaves, vazamento de inatividade, etc., simplificando o número de linhas de código e oferecendo garantias mais claras (como períodos de fraca subjetividade).
A vantagem da camada de consenso reside na sua relativa independência em relação à camada de execução EVM, permitindo assim um maior espaço para melhorias contínuas. O maior desafio é como implementar uma simplificação semelhante na camada de execução.
Camada de Execução Simplificada
A complexidade do EVM está a aumentar, e muita dessa complexidade provou-se desnecessária (em parte devido a erros de decisão pessoais): a máquina virtual de 256 bits está excessivamente otimizada para formas criptográficas específicas que estão gradualmente a tornar-se obsoletas, e as pré-compilações (precompiles) estão otimizadas para um único caso de uso, mas raramente são utilizadas.
Resolver esses problemas um a um tem efeitos limitados. Por exemplo, a remoção do opcode SELFDESTRUCT exige um esforço enorme, mas traz apenas um pequeno benefício. As discussões recentes sobre o EOF (EVM Object Format) também mostram desafios semelhantes.
Recentemente, propus um plano mais radical: em vez de fazer alterações de médio porte (mas ainda destrutivas) no EVM em troca de um retorno de 1,5 vezes, seria melhor transitar para uma máquina virtual mais eficiente e simples, a fim de alcançar um retorno de 100 vezes. Semelhante à “fusão” (The Merge), reduzimos o número de alterações destrutivas, mas tornamos cada alteração mais significativa. Especificamente, sugiro substituir o EVM por RISC-V, ou outra máquina virtual usada pelo provedor de ZK do Ethereum. Isso traria:
1. Aumento significativo de eficiência: A execução de contratos inteligentes (no provedor de provas) não requer sobrecarga de interpretador, executando diretamente. Os dados da Succinct mostram que, em muitos cenários, o desempenho pode ser melhorado em mais de 100 vezes.
2. Melhoria significativa na simplicidade: A especificação RISC-V é extremamente simples em comparação com o EVM, e alternativas (como Cairo) também são igualmente simples.
3. Motivos para suportar EOF: como partição de código, análise estática mais amigável, limite de tamanho de código maior, etc.
4. Mais escolhas para desenvolvedores: Solidity e Vyper podem adicionar backend para compilar para a nova máquina virtual. Se escolher RISC-V, os desenvolvedores de linguagens mainstream também poderão facilmente portar o código para essa máquina virtual.
5. Remover a maior parte dos pré-compilados: pode apenas manter operações de curva elíptica altamente otimizadas (depois que os computadores quânticos se tornarem comuns, até essas desaparecerão).
O principal inconveniente é que, ao contrário do EOF já preparado, os benefícios da nova máquina virtual demoram mais a chegar aos desenvolvedores. Podemos mitigar esse problema através da implementação de melhorias de alto valor no EVM a curto prazo (como aumentar o limite de tamanho do código do contrato, suportar DUP/SWAP17-32).
Isso trará uma máquina virtual mais simples. O desafio central é: como lidar com o EVM existente?
Estratégia de compatibilidade retroativa para a transição de máquinas virtuais
O maior desafio de simplificar (ou melhorar sem aumentar a complexidade) a EVM é como equilibrar a realização dos objetivos com a compatibilidade retroativa das aplicações existentes.
Primeiro é necessário esclarecer: o repositório de código do Ethereum (mesmo dentro de um único cliente) não tem apenas uma forma de definição.
O objetivo é minimizar ao máximo a área verde: a lógica necessária para que os nós participem do consenso do Ethereum, incluindo o cálculo do estado atual, provas, validações, FOCIL (regras de escolha de bifurcação) e a construção de blocos "normais".
A área laranja não pode ser reduzida: se a especificação do protocolo remover ou alterar alguma funcionalidade da camada de execução (como máquinas virtuais, pré-compilados, etc.), o cliente que processa blocos históricos ainda precisará manter o código relacionado. No entanto, novos clientes, ZK-EVM ou provadores formais podem ignorar completamente a área laranja.
Nova área amarela: muito valiosa para entender a cadeia atual ou otimizar a construção de blocos, mas não pertence à lógica de consenso. Por exemplo, Etherscan e alguns construtores de blocos suportam operações de usuários ERC-4337. Se substituirmos certas funcionalidades do Ethereum (como EOA e seus tipos de transação antigos) por uma implementação RISC-V em cadeia, o código de consenso será significativamente simplificado, mas nós dedicados podem continuar a usar o código original para análise.
A complexidade das áreas laranja e amarela é a complexidade de encapsulamento. Aqueles que compreendem o protocolo podem pular essas partes; o Ethereum pode ignorá-las, e os erros nessas áreas não gerarão riscos de consenso. Portanto, a complexidade do código nas áreas laranja e amarela é muito menos prejudicial do que a complexidade na área verde.
A ideia de mover o código da área verde para a área amarela é semelhante à estratégia da Apple de garantir compatibilidade a longo prazo através da camada de tradução Rosetta.
Inspirado por um artigo recente da equipa Ipsilon, proponho o seguinte processo de alteração da máquina virtual (usando EVM para RISC-V como exemplo, mas também aplicável de EVM para Cairo ou de RISC-V para uma máquina virtual mais otimizada):
1. Exigir que a nova pré-compilação forneça a implementação RISC-V on-chain: permitir que o ecossistema se adapte gradualmente à máquina virtual RISC-V.
2. Introdução do RISC-V como opção para desenvolvedores: O protocolo suporta simultaneamente RISC-V e EVM, permitindo que os contratos das duas máquinas virtuais interajam livremente.
3. Substituição da maioria dos pré-compilados: Exceto para operações de curva elíptica e KECCAK (devido à necessidade de velocidade extrema), usar RISC-V para substituir outros pré-compilados. Remover os pré-compilados através de um hard fork, enquanto muda o código desse endereço (semelhante ao fork DAO) de vazio para a implementação RISC-V. A máquina virtual RISC-V é extremamente simples, mesmo que pare aqui, simplifica ainda mais o protocolo.
4. Implementação do interpretador EVM em RISC-V: como contratos inteligentes em cadeia (uma vez que o provador ZK precisa ser realizado). Após alguns anos da publicação inicial, contratos EVM existentes são executados através deste interpretador.
Após completar o passo 4, muitas "implementações EVM" ainda serão utilizadas para otimizar a construção de blocos, ferramentas para desenvolvedores e análise de cadeias, mas não serão mais parte das normas de consenso críticas. O consenso do Ethereum entenderá "nativamente" apenas RISC-V.
Simplificar através do componente de protocolo de compartilhamento
A terceira forma de reduzir a complexidade total do protocolo (também a mais subestimada) é compartilhar padrões unificados em diferentes partes da pilha do protocolo sempre que possível. Protocolos diferentes que fazem a mesma coisa em diferentes cenários geralmente não trazem benefícios, mas esse padrão ainda aparece com frequência, principalmente porque diferentes partes do roteiro do protocolo carecem de comunicação. Abaixo estão alguns exemplos concretos de simplificação do Ethereum através do compartilhamento de componentes.
Código de Correção e Exclusão Unificado
Precisamos de códigos de correção em três cenários:
1. Amostragem de disponibilidade de dados: O cliente verifica se o bloco foi publicado.
2. Transmissão P2P mais rápida: Os nós podem aceitar blocos após receber n/2 fragmentos, equilibrando atraso e redundância.
3. Armazenamento Histórico Distribuído: Os dados históricos do Ethereum são armazenados em fragmentos, onde cada grupo de n/2 fragmentos pode recuperar os outros fragmentos, reduzindo o risco de perda de um único fragmento.
Se usar o mesmo código de correção (seja Reed-Solomon, códigos lineares aleatórios, etc.) em três cenários diferentes, obterá as seguintes vantagens:
1. Minimizar a quantidade de código: reduzir o número total de linhas de código.
2. Aumentar a eficiência: se um nó baixar partes de um determinado cenário, esses dados podem ser utilizados em outros cenários.
3. Garantir a verificabilidade: Todos os fragmentos dos cenários podem ser verificados com base na raiz.
Se diferentes códigos de correção de erros forem utilizados, deve-se garantir pelo menos a compatibilidade, como os códigos Reed-Solomon de amostragem de disponibilidade de dados em nível e os códigos lineares aleatórios verticais operando no mesmo domínio.
Formato de Serialização Unificado
O formato de serialização do Ethereum está atualmente apenas parcialmente consolidado, pois os dados podem ser reserializados e transmitidos em qualquer formato. A exceção são os hashes de assinatura de transação, que precisam ser hashados em um formato padrão. No futuro, o grau de consolidação do formato de serialização aumentará ainda mais devido aos seguintes motivos:
1. Abstração completa da conta (EIP-7701): O conteúdo completo da transação é visível para a máquina virtual.
2. Limite de Gas mais alto: Os dados da camada de execução precisam ser inseridos em blocos de dados (blobs).
Na altura, teremos a oportunidade de unificar os formatos de serialização dos três níveis do Ethereum: camada de execução, camada de consenso e ABI de chamada de contrato inteligente.
Eu proponho o uso de SSZ, porque SSZ:
Fácil de decifrar: incluído dentro do contrato inteligente (devido ao seu design baseado em 4 bytes e menos casos extremos).
Já é amplamente utilizado na camada de consenso.
Muito semelhante ao ABI existente: a adaptação da ferramenta é relativamente simples.
Já existem esforços para uma migração completa para o SSZ, e devemos considerar e continuar esses esforços ao planejar futuras atualizações.
Estrutura de Árvore Unificada
Se a migração de EVM para RISC-V (ou outra máquina virtual mínima opcional) ocorrer, a árvore Merkle Patricia em hexadecimal se tornará o maior gargalo para provar a execução de blocos, mesmo em média. Migrar para uma árvore binária baseada em funções de hash mais eficientes aumentará significativamente a eficiência do provador, ao mesmo tempo que reduzirá o custo de dados em cenários como clientes leves.
Ao migrar, deve-se garantir que a camada de consenso utilize a mesma estrutura de árvore. Isso permitirá que a camada de consenso do Ethereum acesse e analise a camada de execução através do mesmo código.
Do agora ao futuro
A simplicidade é semelhante à descentralização em muitos aspectos, ambas sendo metas resilientes a montante. Valorizar claramente a simplicidade requer uma certa mudança cultural. Os benefícios são muitas vezes difíceis de quantificar, enquanto os custos de esforço adicional e a renúncia a certas funcionalidades chamativas são imediatos. No entanto, com o passar do tempo, os benefícios tornam-se cada vez mais evidentes — o próprio Bitcoin é um excelente exemplo.
Eu proponho seguir o tinygrad, estabelecendo um objetivo claro de número máximo de linhas de código para a norma de longo prazo do Ethereum, de modo a aproximar o código crítico do consenso do Ethereum da simplicidade do Bitcoin. O código que lida com as regras históricas do Ethereum continuará a existir, mas deve ser colocado fora do caminho crítico do consenso. Ao mesmo tempo, devemos manter a filosofia de escolher soluções mais simples, priorizando a encapsulação da complexidade em vez da complexidade sistêmica, e fazer escolhas de design que ofereçam atributos e garantias claras.