O cofundador do Ethereum, Vitalik Buterin, recentemente apresentou uma proposta de longo prazo na comunidade Ethereum Magicians: substituir a máquina virtual de execução atual (EVM) pela arquitetura de conjunto de instruções RISC-V de código aberto. Ele comparou essa ideia à Beam Chain da camada de consenso, acreditando que esta é a única maneira potencial de alcançar um avanço no desempenho da camada de execução e simplificar a lógica do protocolo. Especialmente em termos de eficiência de prova de conhecimento zero (ZK Proof), Vitalik prevê que, ao substituir a EVM, poderá ser alcançado um aumento de otimização de até 100 vezes. A proposta visa abordar os problemas atuais do Ethereum em relação à eficiência das provas ZK, complexidade da construção de blocos, disponibilidade de dados, entre outros.
Este artigo irá analisar, em linguagem simples, a motivação, os detalhes técnicos, o caminho de implementação e os desafios desta proposta, explorando seu impacto nas rotas de escalabilidade existentes do Ethereum e revisando a reação da comunidade e tentativas semelhantes.
Uma, as limitações atuais do EVM e as vantagens do RISC-V
Problema do EVM:
Arquitetura antiga: EVM usa uma estrutura de pilha de 256 bits, incompatível com CPUs modernas, resultando em baixa eficiência na execução do ZK-EVM.
Gargalo da prova ZK: como mencionado pelo Succinct, cerca de metade dos recursos do ZK-EVM são utilizados para executar o próprio EVM, limitando a eficiência da prova ZK.
Manutenção ruim: acumulação de funções complexas ao longo dos anos, normas confusas, como a dificuldade em abolir SELFDESTRUCT.
Desenvolvimento limitado: as restrições do conjunto de instruções não padrão limitam o suporte a várias linguagens, tornando difícil compilar eficientemente linguagens populares em bytecode EVM.
As vantagens do RISC-V:
Desempenho eficiente: RISC-V é um conjunto de instruções reduzido de uma CPU real, amigável ao hardware, que pode ser usado para otimização JIT e até aceleração de hardware.
Otimização ZK: a geração de circuitos diretamente a partir das instruções RISC-V em provas ZK é mais simples do que provar operações EVM.
Ferramenta madura: suporta linguagens populares como Rust/C/C++, com uma barreira de entrada mais baixa e um ecossistema mais amplo.
Padrão genérico: já adotado por blockchains como Nervos CKB, com casos de sucesso.
Vitalik apontou que, em vez de compilar o EVM para RISC-V no ZK-EVM, é melhor usar o RISC-V diretamente como a arquitetura de execução de contratos, aumentando fundamentalmente a eficiência de execução e o potencial de escalabilidade.
Dois, Caminhos e Desafios da Substituição: Como Migrar do EVM?
Três opções de substituição:
Duplo VM em coexistência (o mais conservador): EVM e RISC-V a correr em paralelo, novos contratos podem optar por RISC-V, garantindo compatibilidade durante o período de transição.
Solução de interpretador em cadeia (radical): todos os contratos EVM são agora executados por contratos RISC-V em cadeia.
Mecanismo de plugins do interpretador (compromisso): tratar o interpretador como um elemento do protocolo, permitindo a inserção futura de outras VMs (como Move).
Desafios técnicos enfrentados na implementação:
Risco de perda de desempenho na execução: o RISC-V precisa simular a execução em chips x86, podendo ter uma eficiência inicial inferior à do EVM otimizado.
A precificação de Gas precisa ser reestruturada: é necessário definir um novo modelo de Gas para as instruções RISC-V, garantindo justiça e segurança.
Design de sandbox seguro: limitar chamadas de sistema, prevenir auto-modificação de código, garantir execução determinística.
Ferramentas de desenvolvimento: é necessário atualizar o compilador, o depurador e as ferramentas de auditoria de segurança, suportando bytecode RISC-V.
Problemas de compatibilidade de migração: alguns contratos dependem de características do EVM, a migração deve ser cuidadosamente projetada com uma camada de compatibilidade ou mecanismo de fallback.
Vitalik prefere a opção um como caminho de transição e promete que os novos e antigos contratos manterão a interoperabilidade, garantindo que a experiência do desenvolvedor permaneça inalterada e que os usuários não percebam a atualização.
Três, impacto nas rotas de expansão existentes: O RISC-V substituirá L2, fragmentação de dados, etc.?
A resposta é negativa: RISC-V é uma otimização de infraestrutura, não irá substituir as rotas de expansão existentes.
Layer 2：
Rollup continua a ser o principal motor de escalabilidade do Ethereum, o RISC-V melhora a eficiência de processamento do L1 e o desempenho de verificação ZK, em vez de aumentar diretamente a capacidade de processamento.
Validações L1 mais rápidas podem ajudar o Rollup a submeter dados a um custo mais baixo e de forma mais rápida, aumentando a escalabilidade geral.
Fragmentação de dados e EIP-4844:
A limitação da disponibilidade de dados ainda precisa ser resolvida pelo EIP-4844 (blob) e Danksharding, e o RISC-V não afeta a capacidade de dados na cadeia.
A alteração da arquitetura não muda os requisitos de armazenamento de dados do L1.
FaaS, MEV:
Independente da arquitetura da máquina virtual, não se tornará obsoleto devido ao avanço do RISC-V.
Resumo: RISC-V é "mudar motor", L2/fragmentação é "abrir rede", as duas dimensões são diferentes, mas não se contradizem.
Quatro, feedback da comunidade e tentativas relacionadas
Divisões na comunidade:
Apoiadores: acreditam que esta é uma atualização estratégica necessária para enfrentar desafios de desempenho como os da Solana/Sui, ajudando a atrair desenvolvedores tradicionais.
Conservadores: preocupações com a dificuldade de implementação, o peso histórico, os altos custos de atualização da cadeia de ferramentas ecológicas, questionando a relação custo-benefício do investimento de recursos.
Referência de projetos semelhantes:
Move VM (Aptos/Sui): Uma nova VM orientada a recursos, com forte segurança de linguagem, mas não compatível com EVM.
FuelVM: Uma nova VM projetada para processamento paralelo, emparelhada com a linguagem Sway, com compatibilidade limitada.
WASM (Stylus): Introduzindo WASM como linguagem de contrato no L2, já implementado no Arbitrum, com viabilidade prática.
Nervos CKB: O uso de RISC-V como VM de contrato na mainnet é um precedente que fornece uma referência prática para o Ethereum.
Vitalik propôs que a RISC-V não significa rejeitar outras opções, ele acredita que mecanismos de interpretadores no futuro também podem ser usados para inserir VMs como Move, WASM, entre outras, construindo um ecossistema de execução diversificado.
Cinco, Perspectivas de Impacto Futuro: Se o Ethereum mudar para RISC-V
Experiência do desenvolvedor:
Línguas como Solidity/Vyper ainda podem ser usadas, a mudança está no backend do compilador e não na própria linguagem.
Pode ser aberta a escrita de contratos em novas linguagens como Rust/C, mas não é obrigatório migrar.
Custos de operação e desempenho:
A melhoria na eficiência de execução trará um limite de Gas mais alto e custos mais baixos.
O contrato RISC-V pode reduzir a dependência de contratos pré-compilados, o modelo de Gas está mais próximo do custo da prova ZK.
Compatibilidade e Desenvolvimento Ecológico:
Durante o período de coexistência de duas VMs, os contratos existentes podem continuar a operar, enquanto os novos contratos adotam gradualmente o RISC-V.
A infraestrutura deve suportar o novo formato de bytecode, o que pode levar a alterações na compatibilidade entre cadeias (como questões de permanência ou saída do BSC e Polygon).
Segurança e Estabilidade:
A nova arquitetura necessita de testes abrangentes e verificação formal para aumentar a fiabilidade do protocolo.
Uma camada de execução mais simples favorece a auditoria e o controle da superfície de ataque.
Conclusão
Vitalik propôs substituir a EVM do Ethereum por RISC-V, representando um profundo pensamento do Ethereum sobre os limites de desempenho futuros e a simplicidade do protocolo. Esta proposta ainda está em fase inicial de discussão, e a implementação deve ser um processo que levará vários anos, enfrentando múltiplos desafios técnicos, comunitários e ecológicos. Não se trata de derrubar a rota existente, mas sim de fortalecer a base e preparar o futuro.
Como Vitalik disse: "Para alcançar um aumento de magnitude, essa mudança radical pode ser o único caminho viável."
Podemos considerá-lo como uma aposta no futuro, bem como uma exploração profunda sobre se "a base deve ser reestruturada".
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Proposta radical de V神: substituir o EVM do Ethereum por RISC-V, ZK é a solução final para escalabilidade?
Autor | GaryMa 吴 disse Blockchain
Introdução
O cofundador do Ethereum, Vitalik Buterin, recentemente apresentou uma proposta de longo prazo na comunidade Ethereum Magicians: substituir a máquina virtual de execução atual (EVM) pela arquitetura de conjunto de instruções RISC-V de código aberto. Ele comparou essa ideia à Beam Chain da camada de consenso, acreditando que esta é a única maneira potencial de alcançar um avanço no desempenho da camada de execução e simplificar a lógica do protocolo. Especialmente em termos de eficiência de prova de conhecimento zero (ZK Proof), Vitalik prevê que, ao substituir a EVM, poderá ser alcançado um aumento de otimização de até 100 vezes. A proposta visa abordar os problemas atuais do Ethereum em relação à eficiência das provas ZK, complexidade da construção de blocos, disponibilidade de dados, entre outros.
Este artigo irá analisar, em linguagem simples, a motivação, os detalhes técnicos, o caminho de implementação e os desafios desta proposta, explorando seu impacto nas rotas de escalabilidade existentes do Ethereum e revisando a reação da comunidade e tentativas semelhantes.
Uma, as limitações atuais do EVM e as vantagens do RISC-V
Problema do EVM:
Arquitetura antiga: EVM usa uma estrutura de pilha de 256 bits, incompatível com CPUs modernas, resultando em baixa eficiência na execução do ZK-EVM.
Gargalo da prova ZK: como mencionado pelo Succinct, cerca de metade dos recursos do ZK-EVM são utilizados para executar o próprio EVM, limitando a eficiência da prova ZK.
Manutenção ruim: acumulação de funções complexas ao longo dos anos, normas confusas, como a dificuldade em abolir SELFDESTRUCT.
Desenvolvimento limitado: as restrições do conjunto de instruções não padrão limitam o suporte a várias linguagens, tornando difícil compilar eficientemente linguagens populares em bytecode EVM.
As vantagens do RISC-V:
Desempenho eficiente: RISC-V é um conjunto de instruções reduzido de uma CPU real, amigável ao hardware, que pode ser usado para otimização JIT e até aceleração de hardware.
Otimização ZK: a geração de circuitos diretamente a partir das instruções RISC-V em provas ZK é mais simples do que provar operações EVM.
Ferramenta madura: suporta linguagens populares como Rust/C/C++, com uma barreira de entrada mais baixa e um ecossistema mais amplo.
Padrão genérico: já adotado por blockchains como Nervos CKB, com casos de sucesso.
Vitalik apontou que, em vez de compilar o EVM para RISC-V no ZK-EVM, é melhor usar o RISC-V diretamente como a arquitetura de execução de contratos, aumentando fundamentalmente a eficiência de execução e o potencial de escalabilidade.
Dois, Caminhos e Desafios da Substituição: Como Migrar do EVM?
Três opções de substituição:
Duplo VM em coexistência (o mais conservador): EVM e RISC-V a correr em paralelo, novos contratos podem optar por RISC-V, garantindo compatibilidade durante o período de transição.
Solução de interpretador em cadeia (radical): todos os contratos EVM são agora executados por contratos RISC-V em cadeia.
Mecanismo de plugins do interpretador (compromisso): tratar o interpretador como um elemento do protocolo, permitindo a inserção futura de outras VMs (como Move).
Desafios técnicos enfrentados na implementação:
Risco de perda de desempenho na execução: o RISC-V precisa simular a execução em chips x86, podendo ter uma eficiência inicial inferior à do EVM otimizado.
A precificação de Gas precisa ser reestruturada: é necessário definir um novo modelo de Gas para as instruções RISC-V, garantindo justiça e segurança.
Design de sandbox seguro: limitar chamadas de sistema, prevenir auto-modificação de código, garantir execução determinística.
Ferramentas de desenvolvimento: é necessário atualizar o compilador, o depurador e as ferramentas de auditoria de segurança, suportando bytecode RISC-V.
Problemas de compatibilidade de migração: alguns contratos dependem de características do EVM, a migração deve ser cuidadosamente projetada com uma camada de compatibilidade ou mecanismo de fallback.
Vitalik prefere a opção um como caminho de transição e promete que os novos e antigos contratos manterão a interoperabilidade, garantindo que a experiência do desenvolvedor permaneça inalterada e que os usuários não percebam a atualização.
Três, impacto nas rotas de expansão existentes: O RISC-V substituirá L2, fragmentação de dados, etc.?
A resposta é negativa: RISC-V é uma otimização de infraestrutura, não irá substituir as rotas de expansão existentes.
Layer 2：
Rollup continua a ser o principal motor de escalabilidade do Ethereum, o RISC-V melhora a eficiência de processamento do L1 e o desempenho de verificação ZK, em vez de aumentar diretamente a capacidade de processamento.
Validações L1 mais rápidas podem ajudar o Rollup a submeter dados a um custo mais baixo e de forma mais rápida, aumentando a escalabilidade geral.
Fragmentação de dados e EIP-4844:
A limitação da disponibilidade de dados ainda precisa ser resolvida pelo EIP-4844 (blob) e Danksharding, e o RISC-V não afeta a capacidade de dados na cadeia.
A alteração da arquitetura não muda os requisitos de armazenamento de dados do L1.
FaaS, MEV:
Independente da arquitetura da máquina virtual, não se tornará obsoleto devido ao avanço do RISC-V.
Resumo: RISC-V é "mudar motor", L2/fragmentação é "abrir rede", as duas dimensões são diferentes, mas não se contradizem.
Quatro, feedback da comunidade e tentativas relacionadas
Divisões na comunidade:
Apoiadores: acreditam que esta é uma atualização estratégica necessária para enfrentar desafios de desempenho como os da Solana/Sui, ajudando a atrair desenvolvedores tradicionais.
Conservadores: preocupações com a dificuldade de implementação, o peso histórico, os altos custos de atualização da cadeia de ferramentas ecológicas, questionando a relação custo-benefício do investimento de recursos.
Referência de projetos semelhantes:
Move VM (Aptos/Sui): Uma nova VM orientada a recursos, com forte segurança de linguagem, mas não compatível com EVM.
FuelVM: Uma nova VM projetada para processamento paralelo, emparelhada com a linguagem Sway, com compatibilidade limitada.
WASM (Stylus): Introduzindo WASM como linguagem de contrato no L2, já implementado no Arbitrum, com viabilidade prática.
Nervos CKB: O uso de RISC-V como VM de contrato na mainnet é um precedente que fornece uma referência prática para o Ethereum.
Vitalik propôs que a RISC-V não significa rejeitar outras opções, ele acredita que mecanismos de interpretadores no futuro também podem ser usados para inserir VMs como Move, WASM, entre outras, construindo um ecossistema de execução diversificado.
Cinco, Perspectivas de Impacto Futuro: Se o Ethereum mudar para RISC-V
Experiência do desenvolvedor:
Línguas como Solidity/Vyper ainda podem ser usadas, a mudança está no backend do compilador e não na própria linguagem.
Pode ser aberta a escrita de contratos em novas linguagens como Rust/C, mas não é obrigatório migrar.
Custos de operação e desempenho:
A melhoria na eficiência de execução trará um limite de Gas mais alto e custos mais baixos.
O contrato RISC-V pode reduzir a dependência de contratos pré-compilados, o modelo de Gas está mais próximo do custo da prova ZK.
Compatibilidade e Desenvolvimento Ecológico:
Durante o período de coexistência de duas VMs, os contratos existentes podem continuar a operar, enquanto os novos contratos adotam gradualmente o RISC-V.
A infraestrutura deve suportar o novo formato de bytecode, o que pode levar a alterações na compatibilidade entre cadeias (como questões de permanência ou saída do BSC e Polygon).
Segurança e Estabilidade:
A nova arquitetura necessita de testes abrangentes e verificação formal para aumentar a fiabilidade do protocolo.
Uma camada de execução mais simples favorece a auditoria e o controle da superfície de ataque.
Conclusão
Vitalik propôs substituir a EVM do Ethereum por RISC-V, representando um profundo pensamento do Ethereum sobre os limites de desempenho futuros e a simplicidade do protocolo. Esta proposta ainda está em fase inicial de discussão, e a implementação deve ser um processo que levará vários anos, enfrentando múltiplos desafios técnicos, comunitários e ecológicos. Não se trata de derrubar a rota existente, mas sim de fortalecer a base e preparar o futuro.
Como Vitalik disse: "Para alcançar um aumento de magnitude, essa mudança radical pode ser o único caminho viável."
Podemos considerá-lo como uma aposta no futuro, bem como uma exploração profunda sobre se "a base deve ser reestruturada".
Fonte de referência: