O cofundador do Ethereum, Vitalik Buterin, apresentou recentemente uma proposta de longo prazo na comunidade Ethereum Magicians: substituir a atual máquina virtual de execução (EVM) pela arquitetura de conjunto de instruções de código aberto RISC-V. Ele comparou essa ideia com a Beam Chain da camada de consenso, acreditando que essa é 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, uma otimização de até 100 vezes poderá ser alcançada. Esta proposta visa enfrentar os problemas de gargalo atuais do Ethereum em relação à eficiência de provas ZK, complexidade da construção de blocos e disponibilidade de dados.
Este artigo irá analisar, em linguagem simples, a motivação, os detalhes técnicos, o caminho de implementação e os desafios desta proposta, explorar 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
Problema do EVM:
Arquitetura antiga: EVM usa uma estrutura de pilha de 256 bits, incompatível com CPUs modernas, resultando em eficiência baixa ao executar ZK-EVM.
Gargalo da prova ZK: conforme descrito 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 difícil: acumulação de funções complexas ao longo dos anos, normas confusas, como a dificuldade em abolir o SELFDESTRUCT.
Desenvolvimento limitado: o conjunto de instruções não padrão limita o suporte a várias línguas, tornando difícil a compilação eficiente de linguagens mainstream em bytecode EVM.
As vantagens do RISC-V:
Desempenho eficiente: RISC-V é um conjunto de instruções reduzido de CPU real, 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 de cadeia madura: suporta linguagens populares como Rust/C/C++, com uma barreira de entrada mais baixa e um ecossistema mais amplo.
Padrões gerais: já adotados 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 como arquitetura de execução de contratos, aumentando 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 soluçõ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 interpretados e executados por contratos RISC-V em 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 ser simulado em chips x86, o que pode resultar em uma eficiência inicial inferior à do EVM otimizado.
A precificação do Gas precisa ser reestruturada: é necessário definir um novo modelo de Gas para as instruções RISC-V, garantindo equidade e segurança.
Design de sandbox seguro: limitar chamadas ao sistema, prevenir auto-modificação de código, garantir execução determinística.
Ferramentas de desenvolvimento compatíveis: é 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 projetada com cuidado para incluir uma camada de compatibilidade ou um mecanismo de fallback.
Vitalik prefere a opção 1 como um caminho de transição, e promete que os contratos antigos e novos permanecerão interoperáveis, garantindo que a experiência do desenvolvedor permaneça a mesma e os usuários não sintam a mesma atualização.
Três, impacto nas rotas de escalabilidade existentes: o RISC-V substituirá o L2, 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 a principal força de escalabilidade do Ethereum, o RISC-V melhora a eficiência de processamento do L1 e o desempenho da verificação ZK, em vez de expandir diretamente a capacidade de throughput.
A validação L1 mais rápida pode ajudar o Rollup a submeter dados a um custo mais baixo e mais rapidamente, melhorando a escalabilidade geral.
Fatiamento de dados e EIP-4844:
O gargalo de disponibilidade de dados ainda precisa ser resolvido pelo EIP-4844 (blob) e Danksharding; RISC-V não afeta a capacidade de dados na cadeia.
A alteração da arquitetura não altera os requisitos de armazenamento de dados do L1.
FaaS, MEV:
Não dependente da arquitetura da máquina virtual, não falhará devido ao avanço do RISC-V.
Resumo: RISC-V é "motor de troca", L2/fragmentação é "rede de expansão", as duas dimensões são 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: Preocupados com a dificuldade de implementação, a bagagem histórica e o alto custo de atualização da cadeia de ferramentas ecológicas, eles questionam a relação insumo-produto dos recursos.
Referência de projetos semelhantes:
Move VM (Aptos/Sui): Máquina virtual orientada a recursos completamente nova, com forte segurança de linguagem, mas não compatível com EVM.
FuelVM: uma nova VM projetada para processamento em paralelo, acompanhada pela linguagem Sway, com compatibilidade limitada.
WASM (Stylus): Introduzir o WASM como linguagem de contrato no L2, já implementado no Arbitrum, com viabilidade prática.
Nervos CKB: O uso do RISC-V como VM de contrato na mainnet é um precedente que fornece 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 mecanismos de intérprete no futuro também podem ser usados para inserir VMs como Move, WASM, construindo um ecossistema de execução diversificado.
Cinco, Perspectivas de Impacto Futuro: Se o Ethereum mudar para RISC-V
Experiência do desenvolvedor:
As linguagens como Solidity/Vyper ainda podem ser usadas, a mudança é no backend do compilador e não na própria linguagem.
Pode ser que sejam abertas novas linguagens como Rust/C para escrever contratos, mas a migração não é obrigatória.
Custos operacionais e desempenho:
A melhoria na eficiência de execução resultará em um limite de Gas mais alto 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 da prova ZK.
Compatibilidade e Desenvolvimento Ecológico:
Durante o período de coexistência de duas VMs, os contratos existentes podem continuar a funcionar, e 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 ou não do BSC e Polygon).
Segurança e estabilidade:
A nova arquitetura necessita de testes extensivos e validação formal para aumentar a fiabilidade do protocolo.
Uma camada de execução mais simples é benéfica para a auditoria e o controle da superfície de ataque.
Conclusão
Vitalik propôs substituir a EVM do Ethereum por RISC-V, representando uma reflexão profunda sobre os limites de desempenho futuros e a simplicidade do protocolo do Ethereum. Esta proposta ainda está em fase inicial de discussão, e espera-se que a sua implementação seja 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 ordem de magnitude, essa mudança radical pode ser o único caminho viável."
Podemos vê-lo como uma aposta no futuro, bem como uma exploração profunda sobre se a "base merece ser reformulada".
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.
A visão radical de Vitalik: o que significa substituir a EVM do Ethereum por RISC-V?
Autor | GaryMa Wu diz Blockchain
Introdução
O cofundador do Ethereum, Vitalik Buterin, apresentou recentemente uma proposta de longo prazo na comunidade Ethereum Magicians: substituir a atual máquina virtual de execução (EVM) pela arquitetura de conjunto de instruções de código aberto RISC-V. Ele comparou essa ideia com a Beam Chain da camada de consenso, acreditando que essa é 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, uma otimização de até 100 vezes poderá ser alcançada. Esta proposta visa enfrentar os problemas de gargalo atuais do Ethereum em relação à eficiência de provas ZK, complexidade da construção de blocos e disponibilidade de dados.
Este artigo irá analisar, em linguagem simples, a motivação, os detalhes técnicos, o caminho de implementação e os desafios desta proposta, explorar 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
Problema do EVM:
Arquitetura antiga: EVM usa uma estrutura de pilha de 256 bits, incompatível com CPUs modernas, resultando em eficiência baixa ao executar ZK-EVM.
Gargalo da prova ZK: conforme descrito 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 difícil: acumulação de funções complexas ao longo dos anos, normas confusas, como a dificuldade em abolir o SELFDESTRUCT.
Desenvolvimento limitado: o conjunto de instruções não padrão limita o suporte a várias línguas, tornando difícil a compilação eficiente de linguagens mainstream em bytecode EVM.
As vantagens do RISC-V:
Desempenho eficiente: RISC-V é um conjunto de instruções reduzido de CPU real, 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 de cadeia madura: suporta linguagens populares como Rust/C/C++, com uma barreira de entrada mais baixa e um ecossistema mais amplo.
Padrões gerais: já adotados 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 como arquitetura de execução de contratos, aumentando 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 soluçõ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 interpretados e executados por contratos RISC-V em 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 ser simulado em chips x86, o que pode resultar em uma eficiência inicial inferior à do EVM otimizado.
A precificação do Gas precisa ser reestruturada: é necessário definir um novo modelo de Gas para as instruções RISC-V, garantindo equidade e segurança.
Design de sandbox seguro: limitar chamadas ao sistema, prevenir auto-modificação de código, garantir execução determinística.
Ferramentas de desenvolvimento compatíveis: é 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 projetada com cuidado para incluir uma camada de compatibilidade ou um mecanismo de fallback.
Vitalik prefere a opção 1 como um caminho de transição, e promete que os contratos antigos e novos permanecerão interoperáveis, garantindo que a experiência do desenvolvedor permaneça a mesma e os usuários não sintam a mesma atualização.
Três, impacto nas rotas de escalabilidade existentes: o RISC-V substituirá o L2, 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 a principal força de escalabilidade do Ethereum, o RISC-V melhora a eficiência de processamento do L1 e o desempenho da verificação ZK, em vez de expandir diretamente a capacidade de throughput.
A validação L1 mais rápida pode ajudar o Rollup a submeter dados a um custo mais baixo e mais rapidamente, melhorando a escalabilidade geral.
Fatiamento de dados e EIP-4844:
O gargalo de disponibilidade de dados ainda precisa ser resolvido pelo EIP-4844 (blob) e Danksharding; RISC-V não afeta a capacidade de dados na cadeia.
A alteração da arquitetura não altera os requisitos de armazenamento de dados do L1.
FaaS, MEV:
Não dependente da arquitetura da máquina virtual, não falhará devido ao avanço do RISC-V.
Resumo: RISC-V é "motor de troca", L2/fragmentação é "rede de expansão", as duas dimensões são 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: Preocupados com a dificuldade de implementação, a bagagem histórica e o alto custo de atualização da cadeia de ferramentas ecológicas, eles questionam a relação insumo-produto dos recursos.
Referência de projetos semelhantes:
Move VM (Aptos/Sui): Máquina virtual orientada a recursos completamente nova, com forte segurança de linguagem, mas não compatível com EVM.
FuelVM: uma nova VM projetada para processamento em paralelo, acompanhada pela linguagem Sway, com compatibilidade limitada.
WASM (Stylus): Introduzir o WASM como linguagem de contrato no L2, já implementado no Arbitrum, com viabilidade prática.
Nervos CKB: O uso do RISC-V como VM de contrato na mainnet é um precedente que fornece 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 mecanismos de intérprete no futuro também podem ser usados para inserir VMs como Move, WASM, construindo um ecossistema de execução diversificado.
Cinco, Perspectivas de Impacto Futuro: Se o Ethereum mudar para RISC-V
Experiência do desenvolvedor:
As linguagens como Solidity/Vyper ainda podem ser usadas, a mudança é no backend do compilador e não na própria linguagem.
Pode ser que sejam abertas novas linguagens como Rust/C para escrever contratos, mas a migração não é obrigatória.
Custos operacionais e desempenho:
A melhoria na eficiência de execução resultará em um limite de Gas mais alto 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 da prova ZK.
Compatibilidade e Desenvolvimento Ecológico:
Durante o período de coexistência de duas VMs, os contratos existentes podem continuar a funcionar, e 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 ou não do BSC e Polygon).
Segurança e estabilidade:
A nova arquitetura necessita de testes extensivos e validação formal para aumentar a fiabilidade do protocolo.
Uma camada de execução mais simples é benéfica para a auditoria e o controle da superfície de ataque.
Conclusão
Vitalik propôs substituir a EVM do Ethereum por RISC-V, representando uma reflexão profunda sobre os limites de desempenho futuros e a simplicidade do protocolo do Ethereum. Esta proposta ainda está em fase inicial de discussão, e espera-se que a sua implementação seja 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 ordem de magnitude, essa mudança radical pode ser o único caminho viável."
Podemos vê-lo como uma aposta no futuro, bem como uma exploração profunda sobre se a "base merece ser reformulada".
Referência: