O Ethereum visa tornar-se 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 (substituição da EVM por RISC-V ou máquinas virtuais semelhantes), reduzindo custos de desenvolvimento, riscos de erros e superfícies de ataque. Sugere-se uma transição suave através de uma estratégia de compatibilidade com versões anteriores (como um interpretador EVM on-chain) e a unificação de códigos de correção, formatos de serialização (SSZ) e estruturas de árvore para simplificar ainda mais. 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 culturalmente a simplicidade 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 a áreas como finanças, governança e certificação de dados de alto valor. Isso requer apoio em duas frentes: escalabilidade e resiliência. O plano de hard fork Fusaka aumentará o espaço disponível para dados L2 em 10 vezes, enquanto o roteiro proposto para 2026 também planeja trazer um aumento semelhante para a camada L1. Ao mesmo tempo, o Ethereum completou a transição para a prova de participação (PoS), a diversidade de clientes aumentou rapidamente, a validação de conhecimento zero (ZK) e a pesquisa de resistência quântica estão avançando de forma constante, e o ecossistema de aplicativos está se tornando cada vez mais robusto.
Este artigo visa focar em um elemento de resiliência (ou 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 zero.
Cada bloco contém transações, e as moedas gastas nas transações vêm de recompensas de mineração ou de saídas de transações anteriores.
Isso é tudo! Mesmo um estudante do ensino médio inteligente pode entender completamente como funciona o protocolo do Bitcoin, e um programador pode até escrever um cliente como um projeto pessoal.
A simplicidade do protocolo trouxe várias vantagens chave para que o Bitcoin (e o Ethereum) se tornassem uma camada base global confiável e neutra:
Fácil de entender: reduzir a complexidade do protocolo, permitindo que mais pessoas participem da pesquisa, desenvolvimento e governança do protocolo, diminuindo o risco de dominação por uma elite técnica.
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.).
Reduzir a carga de manutenção: diminuir os custos de manutenção de acordos a longo prazo.
Reduzir o risco de erros: diminuir a probabilidade de erros catastróficos na especificação e implementação do protocolo, ao mesmo tempo que facilita a verificação da inexistência de tais erros.
Reduzir a superfície de ataque: diminuir os componentes complexos do protocolo, reduzindo o risco de ataque por grupos de interesses especiais.
Historicamente, o Ethereum (às vezes devido a decisões pessoais minhas) frequentemente falhou em manter a simplicidade, resultando em altos custos de desenvolvimento, aumento dos riscos de segurança e uma cultura de P&D fechada, enquanto os benefícios da busca por essa complexidade muitas vezes se provaram 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 que seja otimizada a longo prazo e mais simples. Em comparação com a Beacon Chain existente, o novo design simplifica significativamente:
Designação de 3-slot final: remoção de conceitos como slot, epoch, reestruturação do comitê, entre outros, assim como mecanismos de processamento eficiente relacionados (como o comitê de sincronização). A implementação básica da finalização de 3-slot requer apenas cerca de 200 linhas de código e, em comparação com Gasper, a segurança é quase ótima.
Reduzir o número de validadores ativos: permitir a implementação de regras de escolha de bifurcação mais simples para aumentar a segurança.
Protocolo de agregação baseado em STARK: qualquer um pode se tornar um agregador, sem necessidade de confiar no agregador ou pagar altas taxas por domínios duplicados. A complexidade da criptografia de agregação é alta, mas sua complexidade é altamente encapsulada, resultando em um risco sistêmico baixo.
Simplificação da arquitetura P2P: Os fatores acima podem suportar uma arquitetura de rede ponto a ponto mais simples e robusta.
Redesigner o mecanismo de validadores: incluindo mecanismos de entrada, saída, retirada, troca de chaves, vazamento de inatividade, etc., simplificar o número de linhas de código e fornecer garantias mais claras (como o ciclo de subjetividade fraca).
A vantagem da camada de consenso é a 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 reside em como implementar uma simplificação semelhante na camada de execução.
Camada de execução simplificada
A complexidade do EVM está a aumentar, e muitas dessas complexidades provaram ser desnecessárias (em parte devido a erros de decisão pessoal): a máquina virtual de 256 bits otimizou excessivamente formas criptográficas específicas que estão gradualmente a tornar-se obsoletas, e as pré-compilações (precompiles) foram otimizadas para um único caso de uso, mas raramente são utilizadas.
Resolver esses problemas um a um tem efeitos limitados. Por exemplo, remover o opcode SELFDESTRUCT exige um enorme esforço, mas traz apenas pequenos benefícios. As recentes discussões sobre o EOF (EVM Object Format) também mostram desafios semelhantes.
Recentemente, propus um plano mais agressivo: em vez de fazer alterações de médio alcance (mas ainda destrutivas) no EVM em troca de um retorno de 1,5 vezes, seria melhor fazer a transição para uma máquina virtual mais otimizada e simples, para 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 pelos provadores ZK do Ethereum. Isso traria:
A eficiência aumentou drasticamente: a execução de contratos inteligentes (no provador) não requer sobrecarga do interpretador, executando diretamente. Os dados da Succinct mostram que, em muitos cenários, o desempenho pode ser aumentado em mais de 100 vezes.
Grande melhoria na simplicidade: a especificação RISC-V é extremamente simples em comparação com a EVM, e alternativas (como Cairo) também são igualmente simples.
Motivos para suportar EOF: como partição de código, análise estática mais amigável, limites de tamanho de código maiores, etc.
Mais escolhas para desenvolvedores: Solidity e Vyper podem adicionar back-end para compilar para a nova máquina virtual. Se escolher RISC-V, desenvolvedores de linguagens populares também poderão facilmente portar o código para essa máquina virtual.
Remover a maior parte da pré-compilação: pode manter apenas operações de curvas elípticas altamente otimizadas (depois que os computadores quânticos se tornarem comuns, até estas desaparecerão).
A principal desvantagem é que, ao contrário do EOF já pronto, os benefícios da nova máquina virtual demoram mais a chegar aos desenvolvedores. Podemos mitigar esse problema implementando melhorias de alto valor no EVM a curto prazo (como aumentar o limite de tamanho do código do contrato e suportar DUP/SWAP17–32).
Isto trará uma máquina virtual mais simples. O desafio central é: como lidar com o EVM existente?
Estratégia de retrocompatibilidade na transição da máquina virtual
O maior desafio na simplificação (ou melhoria sem aumentar a complexidade) do EVM é equilibrar a realização dos objetivos com a compatibilidade retroativa das aplicações existentes.
Primeiro é necessário esclarecer: a biblioteca de código do Ethereum (mesmo dentro de um único cliente) não possui apenas uma forma de definição.
O objetivo é minimizar a área verde: a lógica necessária para os nós participarem do consenso do Ethereum, incluindo o cálculo do estado atual, provas, validação, FOCIL (regras de seleção de fork) e construção de blocos "normais".
A área laranja não pode ser reduzida: se as especificações do protocolo removerem ou alterarem alguma funcionalidade da camada de execução (como máquinas virtuais, pré-compilações, etc.), o cliente que processa blocos históricos ainda precisa manter o código relevante. 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 faz parte da 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ções antigos) pela implementação em RISC-V na 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, pessoas que compreendem o protocolo podem pular essas partes, o Ethereum pode ignorá-las, e os erros nessas áreas não causarão risco de consenso. Portanto, a complexidade do código nas áreas laranja e amarela é muito menos prejudicial do que a complexidade da área verde.
A abordagem de mover o código da área verde para a área amarela é semelhante à estratégia da Apple de garantir a compatibilidade retroativa a longo prazo por meio da camada de tradução Rosetta.
Inspirado por um artigo recente da equipe Ipsilon, proponho o seguinte processo de alteração de máquinas virtuais (usando EVM para RISC-V como exemplo, mas que também pode ser aplicado para EVM para Cairo ou RISC-V para uma máquina virtual mais otimizada):
Solicitar que a nova pré-compilação forneça uma implementação RISC-V na cadeia: permitir que o ecossistema se adapte gradualmente à máquina virtual RISC-V.
Introduzir RISC-V como opção para desenvolvedores: o protocolo suporta simultaneamente RISC-V e EVM, permitindo que os contratos de ambas as máquinas virtuais interajam livremente.
Substituir a maioria dos pré-compilados: exceto para operações de curva elíptica e KECCAK (devido à necessidade de velocidade extrema), implementar a substituição de outros pré-compilados com RISC-V. Remover os pré-compilados através de um hard fork, ao mesmo tempo que altera 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 se pare aqui, simplifica consideravelmente o protocolo.
Implementação do interpretador EVM em RISC-V: como contratos inteligentes em cadeia (pois o provador ZK precisa ser realizado). Após alguns anos da publicação inicial, os contratos EVM existentes são executados através deste interpretador.
Após completar o passo 4, muitas "implementações EVM" ainda serão usadas para otimizar a construção de blocos, ferramentas para desenvolvedores e análise de cadeias, mas não farão mais parte das normas de consenso fundamentais. O consenso do Ethereum entenderá "nativamente" apenas RISC-V.
Simplificar através de componentes de protocolo de compartilhamento
A terceira forma de reduzir a complexidade total do protocolo (também a mais subestimada) é compartilhar padrões unificados nas diferentes partes da pilha de protocolos sempre que possível. Diferentes protocolos que fazem a mesma coisa em diferentes cenários geralmente não trazem benefícios, mas esse padrão ainda aparece frequentemente, principalmente porque as diferentes partes do roteiro do protocolo carecem de comunicação. Abaixo estão alguns exemplos específicos de como simplificar o Ethereum através do compartilhamento de componentes.
Códigos de correção de erros unificados
Precisamos de códigos de correção e exclusão em três cenários:
Amostragem de disponibilidade de dados: o cliente valida que o bloco foi publicado.
Broadcast P2P mais rápido: os nós podem aceitar blocos após receber n/2 fragmentos, equilibrando latência e redundância.
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 fragmentos restantes, reduzindo o risco de perda de um único fragmento.
Se uma mesma codificação de correção de erros (seja Reed-Solomon, códigos lineares aleatórios, etc.) for utilizada em três cenários, as seguintes vantagens serão obtidas:
Minimizar a quantidade de código: reduzir o número total de linhas de código.
Aumentar a eficiência: Se um nó baixar partes de segmentos para um determinado cenário, esses dados podem ser usados para outros cenários.
Garantir a verificabilidade: todos os segmentos dos cenários podem ser verificados de acordo com a raiz.
Se forem utilizados diferentes códigos de correção, deve-se garantir pelo menos a compatibilidade, por exemplo, 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 das assinaturas das transações, que precisam ser hashados em um formato padrão. No futuro, o grau de consolidação do formato de serialização será ainda mais elevado devido aos seguintes motivos:
Abstração total de conta (EIP-7701): O conteúdo completo da transação é visível para a máquina virtual.
Limite de Gas mais alto: os dados da camada de execução precisam ser colocados em blocos de dados (blobs).
Na altura, teremos a oportunidade de unificar os três níveis de formato de serialização do Ethereum: camada de execução, camada de consenso e ABI de chamada de contrato inteligente.
Eu proponho o uso do SSZ, porque o SSZ:
Fácil de decodificar: inclui dentro do contrato inteligente (devido ao seu design baseado em 4 bytes e menos casos extremos).
Já está amplamente utilizado na camada de consenso.
Altamente semelhante ao ABI existente: a adaptação da ferramenta é relativamente simples.
Já existem esforços para a migração total para o SSZ, devemos considerar e continuar esses esforços ao planejar futuras atualizações.
Estrutura de árvore unificada
Se migrar de EVM para RISC-V (ou outra máquina virtual mínima opcional), a árvore Merkle Patricia em hexadecimal se tornará o maior gargalo na prova da execução de blocos, mesmo em média. Migrar para uma árvore binária baseada em funções de hash mais eficientes melhorará significativamente a eficiência do provador, ao mesmo tempo que reduzirá os custos 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 e a camada de execução sejam acessadas e analisadas através do mesmo código.
Do agora ao futuro
A simplicidade é semelhante à descentralização de muitas maneiras, ambas são metas resilientes a montante. Valorizar claramente a simplicidade requer uma certa mudança cultural. Os seus benefícios muitas vezes são difíceis de quantificar, enquanto o custo do esforço adicional e da renúncia a certas funcionalidades atraentes é imediata. No entanto, com o tempo, os benefícios se tornarão cada vez mais evidentes — o próprio Bitcoin é um excelente exemplo.
Eu proponho seguir o exemplo do tinygrad e estabelecer um objetivo claro de número máximo de linhas de código para a norma de longo prazo do Ethereum, de modo que o código crítico de consenso do Ethereum se aproxime 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 de consenso. Ao mesmo tempo, devemos manter a filosofia de escolher soluções mais simples, priorizando o encapsulamento 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
Autor | Vitalik Buterin
Compilado | GaryMa Wu disse blockchain
Link original:
Resumo
O Ethereum visa tornar-se 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 (substituição da EVM por RISC-V ou máquinas virtuais semelhantes), reduzindo custos de desenvolvimento, riscos de erros e superfícies de ataque. Sugere-se uma transição suave através de uma estratégia de compatibilidade com versões anteriores (como um interpretador EVM on-chain) e a unificação de códigos de correção, formatos de serialização (SSZ) e estruturas de árvore para simplificar ainda mais. 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 culturalmente a simplicidade 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 a áreas como finanças, governança e certificação de dados de alto valor. Isso requer apoio em duas frentes: escalabilidade e resiliência. O plano de hard fork Fusaka aumentará o espaço disponível para dados L2 em 10 vezes, enquanto o roteiro proposto para 2026 também planeja trazer um aumento semelhante para a camada L1. Ao mesmo tempo, o Ethereum completou a transição para a prova de participação (PoS), a diversidade de clientes aumentou rapidamente, a validação de conhecimento zero (ZK) e a pesquisa de resistência quântica estão avançando de forma constante, e o ecossistema de aplicativos está se tornando cada vez mais robusto.
Este artigo visa focar em um elemento de resiliência (ou 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 zero.
Cada bloco contém transações, e as moedas gastas nas transações vêm de recompensas de mineração ou de saídas de transações anteriores.
Isso é tudo! Mesmo um estudante do ensino médio inteligente pode entender completamente como funciona o protocolo do Bitcoin, e um programador pode até escrever um cliente como um projeto pessoal.
A simplicidade do protocolo trouxe várias vantagens chave para que o Bitcoin (e o Ethereum) se tornassem uma camada base global confiável e neutra:
Fácil de entender: reduzir a complexidade do protocolo, permitindo que mais pessoas participem da pesquisa, desenvolvimento e governança do protocolo, diminuindo o risco de dominação por uma elite técnica.
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.).
Reduzir a carga de manutenção: diminuir os custos de manutenção de acordos a longo prazo.
Reduzir o risco de erros: diminuir a probabilidade de erros catastróficos na especificação e implementação do protocolo, ao mesmo tempo que facilita a verificação da inexistência de tais erros.
Reduzir a superfície de ataque: diminuir os componentes complexos do protocolo, reduzindo o risco de ataque por grupos de interesses especiais.
Historicamente, o Ethereum (às vezes devido a decisões pessoais minhas) frequentemente falhou em manter a simplicidade, resultando em altos custos de desenvolvimento, aumento dos riscos de segurança e uma cultura de P&D fechada, enquanto os benefícios da busca por essa complexidade muitas vezes se provaram 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 que seja otimizada a longo prazo e mais simples. Em comparação com a Beacon Chain existente, o novo design simplifica significativamente:
Designação de 3-slot final: remoção de conceitos como slot, epoch, reestruturação do comitê, entre outros, assim como mecanismos de processamento eficiente relacionados (como o comitê de sincronização). A implementação básica da finalização de 3-slot requer apenas cerca de 200 linhas de código e, em comparação com Gasper, a segurança é quase ótima.
Reduzir o número de validadores ativos: permitir a implementação de regras de escolha de bifurcação mais simples para aumentar a segurança.
Protocolo de agregação baseado em STARK: qualquer um pode se tornar um agregador, sem necessidade de confiar no agregador ou pagar altas taxas por domínios duplicados. A complexidade da criptografia de agregação é alta, mas sua complexidade é altamente encapsulada, resultando em um risco sistêmico baixo.
Simplificação da arquitetura P2P: Os fatores acima podem suportar uma arquitetura de rede ponto a ponto mais simples e robusta.
Redesigner o mecanismo de validadores: incluindo mecanismos de entrada, saída, retirada, troca de chaves, vazamento de inatividade, etc., simplificar o número de linhas de código e fornecer garantias mais claras (como o ciclo de subjetividade fraca).
A vantagem da camada de consenso é a 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 reside em como implementar uma simplificação semelhante na camada de execução.
Camada de execução simplificada
A complexidade do EVM está a aumentar, e muitas dessas complexidades provaram ser desnecessárias (em parte devido a erros de decisão pessoal): a máquina virtual de 256 bits otimizou excessivamente formas criptográficas específicas que estão gradualmente a tornar-se obsoletas, e as pré-compilações (precompiles) foram otimizadas para um único caso de uso, mas raramente são utilizadas.
Resolver esses problemas um a um tem efeitos limitados. Por exemplo, remover o opcode SELFDESTRUCT exige um enorme esforço, mas traz apenas pequenos benefícios. As recentes discussões sobre o EOF (EVM Object Format) também mostram desafios semelhantes.
Recentemente, propus um plano mais agressivo: em vez de fazer alterações de médio alcance (mas ainda destrutivas) no EVM em troca de um retorno de 1,5 vezes, seria melhor fazer a transição para uma máquina virtual mais otimizada e simples, para 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 pelos provadores ZK do Ethereum. Isso traria:
A eficiência aumentou drasticamente: a execução de contratos inteligentes (no provador) não requer sobrecarga do interpretador, executando diretamente. Os dados da Succinct mostram que, em muitos cenários, o desempenho pode ser aumentado em mais de 100 vezes.
Grande melhoria na simplicidade: a especificação RISC-V é extremamente simples em comparação com a EVM, e alternativas (como Cairo) também são igualmente simples.
Motivos para suportar EOF: como partição de código, análise estática mais amigável, limites de tamanho de código maiores, etc.
Mais escolhas para desenvolvedores: Solidity e Vyper podem adicionar back-end para compilar para a nova máquina virtual. Se escolher RISC-V, desenvolvedores de linguagens populares também poderão facilmente portar o código para essa máquina virtual.
Remover a maior parte da pré-compilação: pode manter apenas operações de curvas elípticas altamente otimizadas (depois que os computadores quânticos se tornarem comuns, até estas desaparecerão).
A principal desvantagem é que, ao contrário do EOF já pronto, os benefícios da nova máquina virtual demoram mais a chegar aos desenvolvedores. Podemos mitigar esse problema implementando melhorias de alto valor no EVM a curto prazo (como aumentar o limite de tamanho do código do contrato e suportar DUP/SWAP17–32).
Isto trará uma máquina virtual mais simples. O desafio central é: como lidar com o EVM existente?
Estratégia de retrocompatibilidade na transição da máquina virtual
O maior desafio na simplificação (ou melhoria sem aumentar a complexidade) do EVM é equilibrar a realização dos objetivos com a compatibilidade retroativa das aplicações existentes.
Primeiro é necessário esclarecer: a biblioteca de código do Ethereum (mesmo dentro de um único cliente) não possui apenas uma forma de definição.
O objetivo é minimizar a área verde: a lógica necessária para os nós participarem do consenso do Ethereum, incluindo o cálculo do estado atual, provas, validação, FOCIL (regras de seleção de fork) e construção de blocos "normais".
A área laranja não pode ser reduzida: se as especificações do protocolo removerem ou alterarem alguma funcionalidade da camada de execução (como máquinas virtuais, pré-compilações, etc.), o cliente que processa blocos históricos ainda precisa manter o código relevante. 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 faz parte da 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ções antigos) pela implementação em RISC-V na 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, pessoas que compreendem o protocolo podem pular essas partes, o Ethereum pode ignorá-las, e os erros nessas áreas não causarão risco de consenso. Portanto, a complexidade do código nas áreas laranja e amarela é muito menos prejudicial do que a complexidade da área verde.
A abordagem de mover o código da área verde para a área amarela é semelhante à estratégia da Apple de garantir a compatibilidade retroativa a longo prazo por meio da camada de tradução Rosetta.
Inspirado por um artigo recente da equipe Ipsilon, proponho o seguinte processo de alteração de máquinas virtuais (usando EVM para RISC-V como exemplo, mas que também pode ser aplicado para EVM para Cairo ou RISC-V para uma máquina virtual mais otimizada):
Solicitar que a nova pré-compilação forneça uma implementação RISC-V na cadeia: permitir que o ecossistema se adapte gradualmente à máquina virtual RISC-V.
Introduzir RISC-V como opção para desenvolvedores: o protocolo suporta simultaneamente RISC-V e EVM, permitindo que os contratos de ambas as máquinas virtuais interajam livremente.
Substituir a maioria dos pré-compilados: exceto para operações de curva elíptica e KECCAK (devido à necessidade de velocidade extrema), implementar a substituição de outros pré-compilados com RISC-V. Remover os pré-compilados através de um hard fork, ao mesmo tempo que altera 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 se pare aqui, simplifica consideravelmente o protocolo.
Implementação do interpretador EVM em RISC-V: como contratos inteligentes em cadeia (pois o provador ZK precisa ser realizado). Após alguns anos da publicação inicial, os contratos EVM existentes são executados através deste interpretador.
Após completar o passo 4, muitas "implementações EVM" ainda serão usadas para otimizar a construção de blocos, ferramentas para desenvolvedores e análise de cadeias, mas não farão mais parte das normas de consenso fundamentais. O consenso do Ethereum entenderá "nativamente" apenas RISC-V.
Simplificar através de componentes de protocolo de compartilhamento
A terceira forma de reduzir a complexidade total do protocolo (também a mais subestimada) é compartilhar padrões unificados nas diferentes partes da pilha de protocolos sempre que possível. Diferentes protocolos que fazem a mesma coisa em diferentes cenários geralmente não trazem benefícios, mas esse padrão ainda aparece frequentemente, principalmente porque as diferentes partes do roteiro do protocolo carecem de comunicação. Abaixo estão alguns exemplos específicos de como simplificar o Ethereum através do compartilhamento de componentes.
Códigos de correção de erros unificados
Precisamos de códigos de correção e exclusão em três cenários:
Amostragem de disponibilidade de dados: o cliente valida que o bloco foi publicado.
Broadcast P2P mais rápido: os nós podem aceitar blocos após receber n/2 fragmentos, equilibrando latência e redundância.
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 fragmentos restantes, reduzindo o risco de perda de um único fragmento.
Se uma mesma codificação de correção de erros (seja Reed-Solomon, códigos lineares aleatórios, etc.) for utilizada em três cenários, as seguintes vantagens serão obtidas:
Minimizar a quantidade de código: reduzir o número total de linhas de código.
Aumentar a eficiência: Se um nó baixar partes de segmentos para um determinado cenário, esses dados podem ser usados para outros cenários.
Garantir a verificabilidade: todos os segmentos dos cenários podem ser verificados de acordo com a raiz.
Se forem utilizados diferentes códigos de correção, deve-se garantir pelo menos a compatibilidade, por exemplo, 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 das assinaturas das transações, que precisam ser hashados em um formato padrão. No futuro, o grau de consolidação do formato de serialização será ainda mais elevado devido aos seguintes motivos:
Abstração total de conta (EIP-7701): O conteúdo completo da transação é visível para a máquina virtual.
Limite de Gas mais alto: os dados da camada de execução precisam ser colocados em blocos de dados (blobs).
Na altura, teremos a oportunidade de unificar os três níveis de formato de serialização do Ethereum: camada de execução, camada de consenso e ABI de chamada de contrato inteligente.
Eu proponho o uso do SSZ, porque o SSZ:
Fácil de decodificar: inclui dentro do contrato inteligente (devido ao seu design baseado em 4 bytes e menos casos extremos).
Já está amplamente utilizado na camada de consenso.
Altamente semelhante ao ABI existente: a adaptação da ferramenta é relativamente simples.
Já existem esforços para a migração total para o SSZ, devemos considerar e continuar esses esforços ao planejar futuras atualizações.
Estrutura de árvore unificada
Se migrar de EVM para RISC-V (ou outra máquina virtual mínima opcional), a árvore Merkle Patricia em hexadecimal se tornará o maior gargalo na prova da execução de blocos, mesmo em média. Migrar para uma árvore binária baseada em funções de hash mais eficientes melhorará significativamente a eficiência do provador, ao mesmo tempo que reduzirá os custos 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 e a camada de execução sejam acessadas e analisadas através do mesmo código.
Do agora ao futuro
A simplicidade é semelhante à descentralização de muitas maneiras, ambas são metas resilientes a montante. Valorizar claramente a simplicidade requer uma certa mudança cultural. Os seus benefícios muitas vezes são difíceis de quantificar, enquanto o custo do esforço adicional e da renúncia a certas funcionalidades atraentes é imediata. No entanto, com o tempo, os benefícios se tornarão cada vez mais evidentes — o próprio Bitcoin é um excelente exemplo.
Eu proponho seguir o exemplo do tinygrad e estabelecer um objetivo claro de número máximo de linhas de código para a norma de longo prazo do Ethereum, de modo que o código crítico de consenso do Ethereum se aproxime 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 de consenso. Ao mesmo tempo, devemos manter a filosofia de escolher soluções mais simples, priorizando o encapsulamento da complexidade em vez da complexidade sistêmica, e fazer escolhas de design que ofereçam atributos e garantias claras.