Inovação na camada de execução do Ethereum: Perspectivas e desafios da arquitetura RISC-V

O cofundador do Ethereum propôs recentemente uma proposta visionária na comunidade: substituir a atual Máquina Virtual de Execução (EVM) por uma arquitetura de conjunto de instruções de código aberto RISC-V. Este conceito foi comparado à Beam Chain da camada de execução, visando romper os gargalos de desempenho e simplificar a lógica do protocolo. Especialmente em termos de eficiência de provas de conhecimento zero (ZK Proof), espera-se que seja possível alcançar uma otimização de até 100 vezes. A proposta visa resolver os problemas de gargalo atuais do Ethereum em relação à eficiência das provas ZK, à complexidade da construção de blocos e à disponibilidade de dados.

Limitações atuais do EVM e vantagens do RISC-V

Problemas com EVM:

• Arquitetura desatualizada: a estrutura em pilha de 256 bits é incompatível com CPUs modernas, afetando a eficiência de execução do ZK-EVM.
• Gargalo da prova ZK: cerca de metade dos recursos do ZK-EVM é utilizado na execução do EVM em si, limitando a eficiência da prova.
• Baixa manutenção: a acumulação de funcionalidades leva a uma confusão de normas, como a dificuldade em abolir o SELFDESTRUCT.
• Desenvolvimento limitado: Conjuntos de instruções não padrão restringem o suporte entre linguagens, tornando difícil a compilação eficiente em linguagens populares.

Vantagens do RISC-V:

• Desempenho eficiente: conjunto de instruções simplificado, amigável para hardware, pode ser utilizado para otimização JIT e até aceleração de hardware.
• Otimização ZK: geração direta de circuitos para instruções RISC-V, simplificando o processo de prova ZK.
• Cadeia de ferramentas madura: suporta linguagens principais, reduzindo a barreira de desenvolvimento e expandindo o ecossistema.
• Padrão universal: já adotado por projetos de blockchain, com casos de sucesso.

A proposta considera que a adoção direta do RISC-V como arquitetura de execução de contratos é mais capaz de melhorar fundamentalmente a eficiência de execução e o potencial de escalabilidade do que compilar o EVM para RISC-V dentro do ZK-EVM.

Substituição de Caminhos e Desafios

Três opções de substituição:

1. Dupla VM em coexistência (conservadora): EVM e RISC-V funcionam em paralelo, garantindo compatibilidade durante o período de transição.
2. Solução de interpretador em cadeia (radical): todos os contratos EVM são interpretados e executados por contratos RISC-V em cadeia.
3. Mecanismo de plugins do interpretador (compromisso): incluir o interpretador como um elemento do protocolo, permitindo a inserção futura de outras VMs.

Desafios técnicos enfrentados na implementação:

• Risco de perda de desempenho de execução: RISC-V precisa ser simulado em chips x86, a eficiência inicial pode ser inferior à do EVM otimizado.
• Reconstrução da avaliação de Gas: é necessário definir um novo modelo de Gas para as instruções RISC-V.
• Design de sandbox seguro: limitar chamadas de sistema, prevenir auto-modificação de código, garantir execução determinística.
• Ferramentas de desenvolvimento adaptadas: atualizações para compiladores, depuradores e ferramentas de auditoria de segurança, suportando bytecode RISC-V.
• Compatibilidade de migração: alguns contratos dependem das características do EVM, sendo necessário projetar cuidadosamente a camada de compatibilidade ou mecanismos de fallback.

A proposta tende a adotar a coexistência de duas VMs como um caminho de transição, comprometendo-se a manter a interoperabilidade entre contratos novos e antigos, garantindo que a experiência do desenvolvedor permaneça inalterada e que os usuários tenham uma atualização sem perceber.

Impacto nas rotas de escalabilidade existentes

RISC-V é uma otimização de infraestrutura, não substituirá as rotas de escalabilidade existentes:

• Camada 2: RISC-V melhora a eficiência de processamento L1 e o desempenho de validação ZK, ajudando a Rollup a submeter dados a um custo mais baixo e de forma mais rápida.
• Sharding de dados e EIP-4844: o gargalo de disponibilidade de dados ainda precisa ser resolvido através de blobs e Danksharding.
• FaaS, MEV: não dependem da arquitetura da máquina virtual, não são afetados pelo avanço do RISC-V.

RISC-V é "motor de troca", L2/fragmentação é "rede de expansão", ambos têm dimensões diferentes e não se contradizem.

Feedback da Comunidade e Tentativas Relacionadas

Divergência na comunidade:

• Apoiante: considera que é uma atualização necessária para enfrentar os desafios de desempenho, ajudando a atrair desenvolvedores tradicionais.
• Conservadores: preocupam-se com a dificuldade de implementação, o peso histórico, o custo de atualização da cadeia de ferramentas ecológicas, e questionam a relação custo-benefício.

Projetos semelhantes de referência:

• Move VM (Aptos/Sui): VM orientada a recursos, com forte segurança de linguagem, mas não compatível com EVM.
• FuelVM: projetado para processamento paralelo, compatível com a linguagem Sway, com compatibilidade limitada.
• WASM (Stylus): Introdução do WASM como linguagem de contrato no L2, já implementado em certa plataforma.
• Um projeto de blockchain: a mainnet utiliza RISC-V como VM de contrato, fornecendo referência prática para Ethereum.

A proposta não exclui outras opções, acreditando que mecanismos de interpretador no futuro poderão ser utilizados para inserir VMs como Move, WASM, construindo um ecossistema de execução diversificado.

Perspectivas de Impacto Futuro

Experiência do desenvolvedor:

• Linguagens como Solidity/Vyper ainda podem ser usadas, apenas mudando o backend do compilador.
• Pode haver a abertura para novas linguagens como Rust/C para escrever contratos, mas a migração não é obrigatória.

Custos operacionais e desempenho:

• A melhoria da eficiência de execução trará limites de Gas mais altos e custos mais baixos.
• O contrato RISC-V pode reduzir a dependência de contratos pré-compilados, e o modelo de Gas está mais próximo do custo de prova ZK.

Compatibilidade e Desenvolvimento Ecológico:

• Durante o período de coexistência das duas VMs, os contratos existentes podem continuar a funcionar, e os novos contratos adotarão gradualmente o RISC-V.
• A infraestrutura deve suportar o novo formato de bytecode, o que pode provocar alterações na compatibilidade entre cadeias.

Segurança e Estabilidade:

• A nova arquitetura precisa de testes extensivos e verificação formal, para aumentar a confiabilidade do protocolo.
• Uma camada de execução mais simples é benéfica para auditoria e controle da superfície de ataque.

Conclusão

Os desenvolvedores principais do Ethereum propuseram substituir a EVM pelo RISC-V, refletindo uma profunda reflexão sobre os limites de desempenho futuros e a simplicidade do protocolo. Esta proposta ainda está em fase de discussão inicial, e a implementação deverá ser um processo que levará vários anos, enfrentando múltiplos desafios tecnológicos, comunitários e ecológicos. Não se trata de derrubar a rota existente, mas de fortalecer a base e preparar o futuro.

Como disse o proponente: "Para alcançar um aumento de magnitude, essa mudança radical pode ser o único caminho viável."

Esta é uma aposta no futuro, mas também uma profunda exploração sobre "se a base merece ser remodelada".