Vitalik Buterin tem proposto Uma revisão de longo prazo ao ambiente de execução do Ethereum para substituir a máquina virtual Ethereum por Risc-v, Uma arquitetura de conjunto de instruções padronizada e extensível.
A proposta, compartilhada no fórum do Ethereum Magicians em 20 de abril, descreve uma mudança multifásica para melhorar a eficiência da prova e simplificar a camada de execução, sem alterar as abstrações do núcleo como contas, armazenamento ou chamadas de contrato cruzado.
A mudança reteria Solidez e vyper como idiomas primários de desenvolvimento, que seriam adaptados para compilar Risc-v.
Por Buterin, enquanto escrever contratos diretamente na ferrugem seria tecnicamente possível, as preocupações de legibilidade e a familiaridade do desenvolvedor com os idiomas existentes sugerem que a ferrugem não substituirá a solidez na camada de aplicação. Os contratos de EVM existentes continuariam operando e interagindo totalmente com novos contratos baseados em RISC-V, preservando a compatibilidade com versões anteriores.
Gargalos de execução e escala de longo prazo
Buterin identificou a execução como um dos gargalos finais de longo prazo do Ethereum, depois que os problemas de curto prazo são atenuados por EIPs como execução tardia, listas de acesso em nível de bloco e armazenamento histórico distribuído.
Em particular, ele apontou para provar custos em ZK-EVMS como a principal restrição para a escalabilidade futura. A análise do ZK-EVM da Succinto indica que a execução de blocos somente representa quase metade de todos os ciclos de provador, enquanto o restante é consumido pelo manuseio de dados de testemunhas e operações de árvores estaduais.
Embora a sobrecarga relacionada ao estado possa ser reduzida pela mudança das árvores de Patricia, com sede em Keccak, para árvores binárias com funções de hash prover otimizadas, como Poseidon, a eficiência da execução do bloco permanecerá limitadora, a menos que o EVM seja abordado diretamente.
Buterin observou que os ZK-EVMs já compilam o RISC-V sob o capô, sugerindo que a exposição de RISC-V como a VM primária poderia eliminar uma camada de abstração e produzir ganhos de eficiência. Alguns cenários de teste mostram melhorias de 100x no desempenho do provador, contornando completamente a tradução do EVM.
Caminhos de coexistência, migração e simplificação
Várias vias de implementação estão em consideração. O mais conservador permitiria suporte duplo para contratos de EVM e RISC-V, mantendo chamadas interoperáveis e acesso compartilhado ao estado persistente. Os contratos de EVM continuariam funcionando e poderiam entrar ou ser chamados por contratos RISC-V por meio de chamadas de sistema mapeadas para códigos de operações tradicionais, como Call, Sload e Sstore.
Uma abordagem mais agressiva envolve a transformação de contratos EVM existentes em invólucros que delegam a execução a um intérprete de EVM escrito no RISC-V. De acordo com esse modelo, o bytecode de um contrato seria substituído por lógica que rotula chamadas e parâmetros de execução para um contrato de interpregador de RISC-V designado, recebe o valor de retorno e o encaminha para o chamador.
Uma estratégia intermediária propõe suporte no nível do protocolo para intérpretes de máquinas virtuais, consagrando esse processo de delegação e permitindo que vários formatos de execução coexistem. Embora o EVM seja a primeira VM apoiada sob esse modelo, outros, incluindo Move, poderiam ser adicionados no futuro.
Cada abordagem procura equilibrar a compatibilidade com a simplificação de longo prazo. Segundo Buterin, as simplificações incrementais para o EVM, como a remoção de autodestruição, se mostraram difíceis devido a casos complexos de borda e comportamentos herdados.
Uma transição completa para o RISC-V pode permitir uma camada base mais sustentável com a lógica mínima de execução, comparável na compactação a projetos como o TinyGrad que aplica limites estritos de base de código.
Filosofia mais ampla de design e alinhamento com cadeia de feixe
A proposta alinha com esforços contínuos, como a iniciativa da cadeia de feixe, que visa simplificar o mecanismo de consenso do Ethereum. O plano RISC-V traria melhorias paralelas para a camada de execução, permitindo que a rede busque a modularidade e reduziu a complexidade em ambos os domínios.
Como publicado sobre os mágicos do Ethereum, Buterin caracterizou a proposta como um passo radical, mas possivelmente necessário, para realizar a eficiência e a simplicidade de L1 a longo prazo. Enquanto as estruturas ativas de EIPS e apatridia abordam melhorias de escalabilidade a curto e médio prazo, o futuro do Ethereum como um protocolo de desempenho e sustentável pode depender de mudanças arquitetônicas dessa magnitude.
Nenhuma linha do tempo foi anunciada para qualquer fase de implementação. Espera-se que a comunidade Ethereum se envolva em discussões adicionais para avaliar trade-offs, impacto de ferramentas e caminhos de migração de desenvolvedores como parte de um ciclo de deliberação mais longo.
A proposta permanece exploratória e pretende abrir uma conversa mais ampla sobre a direção do ambiente de execução do Ethereum nos próximos anos.
Resposta da comunidade
Alguns membros da comunidade levantaram reservas estratégicas e técnicas em resposta à proposta de Buterin. Adam Cochran questionou a priorização da eficiência de L1 às custas potenciais da capacitação de L2, sugerindo que consagrar o RISC-V poderia restringir o roteiro modular do Ethereum.
Ele destacou propostas alternativas, como agregação de prova recursiva, raízes de compromisso sem estado e unificação de assinatura do BLS, que poderia potencialmente oferecer ganhos sistêmicos mais amplos com menos custos de implementação.
Outros, incluindo Ben A Adams, co-fundador e CTO da Illyriad Games, e o LEVS57, um desenvolvedor da Web3, apontaram para trade-offs de desempenho, particularmente em torno da compatibilidade de hardware e o papel persistente dos pré-compilos.
As preocupações incluíram a dificuldade de otimizar as instruções RISC-V de baixo nível em operações eficientes de 256 bits e dúvidas sobre se os sistemas ZK-RISC-V atuais são suficientemente maduros ou audíveis para justificar uma mudança fundamental.
Buterin respondeu subestimando até que ponto o tamanho da palavra de 256 bits do EVM restringe a execução, afirmando que a maioria dos valores na prática são menores, normalmente U32, U64 ou U128, que os compiladores podem mapear com eficiência para instruções RISC-V.
Ele reiterou que o ZK-EVMS de hoje já opera como ambientes RISC-V que incorporam um intérprete de EVM, enquadrando a exposição direta do RISC-V como uma maneira de remover camadas redundantes. Embora reconheça o gerenciamento de pilhas e os saltos como possíveis pontos de atrito, ele sustentou que a eliminação da sobrecarga interpretativa continua sendo um ganho líquido.
