O cofundador do Ethereum, Vitalik Buterin, fez recentemente uma proposta de longo prazo na comunidade Ethereum Magicians para substituir a atual Máquina Virtual de Camada de Execução (EVM) pela arquitetura de conjunto de instruções RISC-V de código aberto. Ele compara essa ideia com a cadeia de feixe da camada de consenso, que ele vê como o único caminho potencial para alcançar um avanço de desempenho na camada de execução e simplificar a lógica do protocolo. Especialmente em termos de eficiência à prova de conhecimento zero (prova ZK), a Vitalik espera alcançar uma melhoria de otimização de até 100x substituindo os EVMs. A proposta visa abordar os gargalos atuais do Ethereum em termos de eficiência de prova ZK, complexidade de construção de blocos, disponibilidade de dados, etc.
Este artigo irá analisar em linguagem simples a motivação, os detalhes técnicos, o caminho de implementação e os desafios desta proposta, discutir o seu impacto nas rotas de escalabilidade existentes do Ethereum e rever as reações da comunidade e tentativas semelhantes.
Um. As limitações atuais do EVM e as vantagens do RISC-V
Problemas com EVM:
Arquitetura obsoleta: EVM utiliza 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 pela Succinct, cerca de metade dos recursos do ZK-EVM é utilizada para executar o próprio EVM, limitando a eficiência da prova ZK.
Manutenção deficiente: acumulação de funcionalidades complexas ao longo dos anos, normas confusas, como a difícil revogação do SELFDESTRUCT.
Desenvolvimento limitado: Conjuntos de instruções não padronizados limitam o suporte entre linguagens, tornando difícil compilar eficientemente linguagens populares em bytecode EVM.
Vantagens do RISC-V:
Desempenho eficiente: RISC-V é um conjunto de instruções reduzido de CPUs reais, amigável ao hardware, podendo ser utilizado para otimização JIT e até aceleração de hardware.
Otimização ZK: A geração de circuitos diretamente para 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, melhorando fundamentalmente a eficiência de execução e o potencial de escalabilidade.
Dois, caminhos e desafios de substituição: como migrar do EVM?
Três opções de substituição:
Dual VM coexistence (most conservative): EVM and RISC-V run in parallel, new contracts can optionally use RISC-V, ensuring compatibility during the transition period.
Solução de interpretador em Blockchain (radical): Todos os contratos EVM são executados por contratos RISC-V na Blockchain.
Mecanismo de plugins do interpretador (compromisso): tratar o interpretador como um elemento de protocolo, permitindo a inserção futura de outras VMs (como Move).
Desafios técnicos enfrentados na implementação:
Risco de perda de desempenho: RISC-V precisa simular a execução em chips x86, o que pode resultar em eficiência inicial inferior à EVM otimizada.
A precificação do 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 ajustadas: é necessário atualizar o compilador, depurador e ferramentas de auditoria de segurança, suportando código de bytes 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 um mecanismo de fallback.
Vitalik prefere a opção um como caminho de transição e compromete-se a que os contratos antigos e novos mantenham a interoperabilidade, garantindo que a experiência do desenvolvedor permaneça inalterada e que os usuários não sintam a atualização.
Três, o impacto das rotas de escalabilidade existentes: O RISC-V substituirá L 2, fragmentação de dados, etc.?
A resposta é negativa: RISC-V é uma otimização de infraestrutura e não substituirá as rotas de escalabilidade existentes.
Layer 2:
Rollup continua a ser o principal motor de escalabilidade do Ethereum, o RISC-V aumenta a eficiência de processamento do L 1 e o desempenho de verificação ZK, e não expande diretamente a capacidade de processamento.
Uma validação L1 mais rápida pode ajudar o Rollup a submeter dados a um custo mais baixo e de forma mais rápida, melhorando a escalabilidade geral.
Partição de dados e EIP-4844:
O gargalo de disponibilidade de dados ainda precisa ser resolvido pelo EIP-4844 (blob) e Danksharding, o RISC-V não afeta a capacidade de dados na blockchain.
A alteração da arquitetura não altera as necessidades de armazenamento de dados do L 1.
FaaS, MEV:
Independente da arquitetura da máquina virtual, não falhará devido ao avanço do RISC-V.
Resumo: RISC-V é "trocar motor", L 2/partição é "rede de expansão", os dois têm dimensões diferentes, mas não se contradizem.
Quatro, feedback da comunidade e tentativas relacionadas
Divisão na comunidade:
Apoiadores: acreditam que esta é uma atualização estratégica necessária para enfrentar os desafios de desempenho do 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 e questionam a relação custo-benefício do investimento de recursos.
Projetos semelhantes de referência:
Move VM (Aptos/Sui): Máquina virtual orientada a recursos totalmente nova, com forte segurança de linguagem, mas não compatível com EVM.
FuelVM: uma nova VM projetada para processamento paralelo, acompanhada da linguagem Sway, com compatibilidade limitada.
WASM (Stylus): Introduzindo WASM como linguagem de contrato no L 2, já implementado no Arbitrum, com viabilidade prática.
Nervos CKB: O uso de RISC-V como VM de contrato na mainnet estabelece um precedente, fornecendo uma referência prática para o Ethereum.
Vitalik propôs que o RISC-V não significa rejeitar outras opções, ele acredita que futuros mecanismos de interpretadores também podem ser usados para inserir VMs como Move, WASM, entre outras, construindo um ecossistema de execução diversificado.
V. Perspectivas de Impacto Futuro: Se o Ethereum mudar para RISC-V
Experiência do desenvolvedor:
Linguagens como Solidity/Vyper ainda podem ser usadas, a mudança é 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ória a migração.
Custos operacionais e desempenho:
A melhoria da eficiência de execução trará um limite de Gas mais alto e custos mais baixos.
Os contratos RISC-V podem 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ógicos:
Durante o período de coexistência de duas VMs, os contratos existentes podem continuar a funcionar, enquanto os novos contratos adotam gradualmente o RISC-V.
A infraestrutura deve suportar o novo formato de bytecode, o que pode provocar alterações na compatibilidade entre cadeias (como questões de permanência e remoção no BSC e Polygon).
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 auditorias e controle da superfície de ataque.
Conclusão
Vitalik propôs substituir a EVM do Ethereum pelo RISC-V, representando um profundo pensamento do Ethereum sobre os limites de desempenho futuro e a simplicidade do protocolo. Esta proposta ainda está em fase de discussão inicial, e a sua implementação deverá 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 disse Vitalik: "Para alcançar uma melhoria de ordem 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 vale a pena ser reestruturada".
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.
A visão radical de Vitalik: o que significa substituir a EVM do Ethereum por RISC-V?
Escrito por: GaryMa Wu diz Blockchain
Introdução
O cofundador do Ethereum, Vitalik Buterin, fez recentemente uma proposta de longo prazo na comunidade Ethereum Magicians para substituir a atual Máquina Virtual de Camada de Execução (EVM) pela arquitetura de conjunto de instruções RISC-V de código aberto. Ele compara essa ideia com a cadeia de feixe da camada de consenso, que ele vê como o único caminho potencial para alcançar um avanço de desempenho na camada de execução e simplificar a lógica do protocolo. Especialmente em termos de eficiência à prova de conhecimento zero (prova ZK), a Vitalik espera alcançar uma melhoria de otimização de até 100x substituindo os EVMs. A proposta visa abordar os gargalos atuais do Ethereum em termos de eficiência de prova ZK, complexidade de construção de blocos, disponibilidade de dados, etc.
Este artigo irá analisar em linguagem simples a motivação, os detalhes técnicos, o caminho de implementação e os desafios desta proposta, discutir o seu impacto nas rotas de escalabilidade existentes do Ethereum e rever as reações da comunidade e tentativas semelhantes.
Um. As limitações atuais do EVM e as vantagens do RISC-V
Problemas com EVM:
Arquitetura obsoleta: EVM utiliza 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 pela Succinct, cerca de metade dos recursos do ZK-EVM é utilizada para executar o próprio EVM, limitando a eficiência da prova ZK.
Manutenção deficiente: acumulação de funcionalidades complexas ao longo dos anos, normas confusas, como a difícil revogação do SELFDESTRUCT.
Desenvolvimento limitado: Conjuntos de instruções não padronizados limitam o suporte entre linguagens, tornando difícil compilar eficientemente linguagens populares em bytecode EVM.
Vantagens do RISC-V:
Desempenho eficiente: RISC-V é um conjunto de instruções reduzido de CPUs reais, amigável ao hardware, podendo ser utilizado para otimização JIT e até aceleração de hardware.
Otimização ZK: A geração de circuitos diretamente para 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, melhorando fundamentalmente a eficiência de execução e o potencial de escalabilidade.
Dois, caminhos e desafios de substituição: como migrar do EVM?
Três opções de substituição:
Dual VM coexistence (most conservative): EVM and RISC-V run in parallel, new contracts can optionally use RISC-V, ensuring compatibility during the transition period.
Solução de interpretador em Blockchain (radical): Todos os contratos EVM são executados por contratos RISC-V na Blockchain.
Mecanismo de plugins do interpretador (compromisso): tratar o interpretador como um elemento de protocolo, permitindo a inserção futura de outras VMs (como Move).
Desafios técnicos enfrentados na implementação:
Risco de perda de desempenho: RISC-V precisa simular a execução em chips x86, o que pode resultar em eficiência inicial inferior à EVM otimizada.
A precificação do 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 ajustadas: é necessário atualizar o compilador, depurador e ferramentas de auditoria de segurança, suportando código de bytes 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 um mecanismo de fallback.
Vitalik prefere a opção um como caminho de transição e compromete-se a que os contratos antigos e novos mantenham a interoperabilidade, garantindo que a experiência do desenvolvedor permaneça inalterada e que os usuários não sintam a atualização.
Três, o impacto das rotas de escalabilidade existentes: O RISC-V substituirá L 2, fragmentação de dados, etc.?
A resposta é negativa: RISC-V é uma otimização de infraestrutura e não substituirá as rotas de escalabilidade existentes.
Layer 2:
Rollup continua a ser o principal motor de escalabilidade do Ethereum, o RISC-V aumenta a eficiência de processamento do L 1 e o desempenho de verificação ZK, e não expande diretamente a capacidade de processamento.
Uma validação L1 mais rápida pode ajudar o Rollup a submeter dados a um custo mais baixo e de forma mais rápida, melhorando a escalabilidade geral.
Partição de dados e EIP-4844:
O gargalo de disponibilidade de dados ainda precisa ser resolvido pelo EIP-4844 (blob) e Danksharding, o RISC-V não afeta a capacidade de dados na blockchain.
A alteração da arquitetura não altera as necessidades de armazenamento de dados do L 1.
FaaS, MEV:
Independente da arquitetura da máquina virtual, não falhará devido ao avanço do RISC-V.
Resumo: RISC-V é "trocar motor", L 2/partição é "rede de expansão", os dois têm dimensões diferentes, mas não se contradizem.
Quatro, feedback da comunidade e tentativas relacionadas
Divisão na comunidade:
Apoiadores: acreditam que esta é uma atualização estratégica necessária para enfrentar os desafios de desempenho do 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 e questionam a relação custo-benefício do investimento de recursos.
Projetos semelhantes de referência:
Move VM (Aptos/Sui): Máquina virtual orientada a recursos totalmente nova, com forte segurança de linguagem, mas não compatível com EVM.
FuelVM: uma nova VM projetada para processamento paralelo, acompanhada da linguagem Sway, com compatibilidade limitada.
WASM (Stylus): Introduzindo WASM como linguagem de contrato no L 2, já implementado no Arbitrum, com viabilidade prática.
Nervos CKB: O uso de RISC-V como VM de contrato na mainnet estabelece um precedente, fornecendo uma referência prática para o Ethereum.
Vitalik propôs que o RISC-V não significa rejeitar outras opções, ele acredita que futuros mecanismos de interpretadores também podem ser usados para inserir VMs como Move, WASM, entre outras, construindo um ecossistema de execução diversificado.
V. Perspectivas de Impacto Futuro: Se o Ethereum mudar para RISC-V
Experiência do desenvolvedor:
Linguagens como Solidity/Vyper ainda podem ser usadas, a mudança é 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ória a migração.
Custos operacionais e desempenho:
A melhoria da eficiência de execução trará um limite de Gas mais alto e custos mais baixos.
Os contratos RISC-V podem 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ógicos:
Durante o período de coexistência de duas VMs, os contratos existentes podem continuar a funcionar, enquanto os novos contratos adotam gradualmente o RISC-V.
A infraestrutura deve suportar o novo formato de bytecode, o que pode provocar alterações na compatibilidade entre cadeias (como questões de permanência e remoção no BSC e Polygon).
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 auditorias e controle da superfície de ataque.
Conclusão
Vitalik propôs substituir a EVM do Ethereum pelo RISC-V, representando um profundo pensamento do Ethereum sobre os limites de desempenho futuro e a simplicidade do protocolo. Esta proposta ainda está em fase de discussão inicial, e a sua implementação deverá 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 disse Vitalik: "Para alcançar uma melhoria de ordem 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 vale a pena ser reestruturada".