No futuro plano da Ethereum, uma nova proposta iniciada pelo co-fundador da Ethereum, Vitalik Buterin, gerou intensa discussão na comunidade: substituir o EVM (Máquina virtual Ethereum) pela linguagem de máquina virtual dos contratos inteligentes RISC-V. Esta ideia foi comparada a um "grande upgrade de nível de beam chain" na camada de execução, não apenas para aumentar a capacidade, mas também para resolver os gargalos fundamentais da complexidade e eficiência atuais da camada de execução.
O que é RISC-V? Por que substituir o EVM?
O núcleo da proposta é substituir a EVM, atualmente utilizada pelos contratos inteligentes do Ethereum, por uma arquitetura de conjunto de instruções modular e de código aberto — RISC-V. Essa transformação não irá derrubar as ferramentas de desenvolvedor existentes do Ethereum e os hábitos dos desenvolvedores, porque:
Os sistemas de contas existentes, chamadas entre contratos, métodos de armazenamento e outras camadas de abstração principais permanecem inalterados.
As linguagens Solidity e Vyper podem ser compiladas com RISC-V como backend, a experiência do desenvolvedor não terá grandes mudanças.
Os contratos EVM antigos ainda podem se comunicar bidirecionalmente com os novos contratos RISC-V.
Dessa forma, os desenvolvedores não precisam reaprender tudo, mas a performance e a simplicidade da camada base do Ethereum devem ser significativamente melhoradas.
ZK-EVM é o maior gargalo de desempenho
Com a futura implementação de várias propostas de escalabilidade (como EIP-4444, execução atrasada e clientes sem estado), os verdadeiros fatores que limitam a capacidade de escalabilidade do Ethereum L1 estarão concentrados em:
Amostragem de disponibilidade de dados e estabilidade dos protocolos de armazenamento histórico
Competição de mercado na produção de blocos
Eficiência da prova ZK-EVM
Atualmente, o processo de prova de um bloco no ZK-EVM consome cerca de 50% dos recursos apenas na execução da lógica da Máquina virtual EVM. Isso significa que, se for possível executar contratos inteligentes diretamente no ambiente RISC-V, há a oportunidade de aumentar a eficiência da prova ZK em até 50 vezes, ou mesmo 100 vezes.
É interessante notar que, atualmente, o processo de prova do ZK-EVM consiste, na verdade, em compilar o EVM para RISC-V e, em seguida, o sistema ZK realiza a prova. Portanto, permitir que o RISC-V se torne a máquina virtual nativa da camada de execução do Ethereum não só faz sentido, mas também pode economizar o consumo de recursos da conversão intermediária.
Por que RISC-V é rápido? Otimização total do design estrutural até a função de hash.
Atualmente, os quatro principais itens que consomem recursos no ZK-EVM são:
deserialize_inputs
initialize_witness_db
state_root_computation
execução de bloco
Os três primeiros podem ser significativamente otimizados utilizando funções de hash mais amigáveis (como Poseidon) e árvores de estado binárias. Por exemplo, o Poseidon pode processar 2 milhões de hashes por segundo em um laptop, muito superior às 15 mil vezes do Keccak. Se essas otimizações forem implementadas, a carga nos primeiros 50% será drasticamente reduzida.
mas os 50% restantes ainda vêm de
execução_de_blocos
Esta parte só pode ser resolvida fundamentalmente através de um design de VM mais eficiente, como o RISC-V.
Três tipos de implementações, desde as conservadoras até as radicais.
Vitalik propôs três caminhos de implementação técnica:
– Opção um: Máquinas virtuais duplas coexistindo (risco mínimo): permite que os contratos escolham usar EVM ou RISC-V, ambos interoperáveis e compartilhando recursos, equilibrando compatibilidade e inovação.
– Opção dois: RISC-V embalagem do interpretador EVM (upgrade radical): todos os contratos EVM serão executados através do interpretador EVM embutido no RISC-V, fazendo a transição da camada de execução geral para uma arquitetura subjacente unificada.
Opção três: suporte a interpretadores de máquina virtual na camada de protocolo (abordagem moderada): o protocolo é projetado com um "módulo de máquina virtual", implementando por padrão o interpretador EVM com RISC-V e permitindo a futura expansão para outras linguagens, como Move.
As vantagens comuns destes caminhos são: simplificar as especificações da camada de execução, aumentar a manutenibilidade e a transparência da verificação.
Co-fundador da Sui, empresa de desenvolvimento Mysten Labs: se pudesse recomeçar, escolheria Move, sem considerar múltiplas linguagens.
Em relação a esta proposta, Sam Blackshear, cofundador da empresa de desenvolvimento Sui, Mysten Labs, também expressou sua opinião. Ele afirmou: "Acredito que adotar um backend RISC-V é uma boa escolha para o Ethereum (pois precisa suportar contratos existentes da EVM). Mas se eu tivesse que projetar uma nova cadeia do zero, ainda escolheria Move, em vez de suporte a múltiplas linguagens. Muitas das vantagens do Sui vêm do uso de objetos fortemente tipados em toda a pilha como uma camada de abstração comum."
Isto reflete os fatores históricos da "estratégia de escolha da máquina virtual" entre diferentes cadeias. O Ethereum foi desenvolvido inicialmente sem a capacidade de prever as numerosas necessidades e desenvolvimentos futuros. Atualmente, está a adaptar-se às mudanças, enfatizando a compatibilidade e o design de transição; enquanto a nova blockchain Sui foca na integração total da pilha, desde a linguagem até ao nível inferior, permitindo uma estreita integração entre desenvolvimento e segurança.
Typus Finance crescimento Kyrie também compartilhou uma conversa que teve com Vitalik em um evento do EthTaipei no passado. Ele se lembrou: "Naquela época, eu perguntei ao Vitalik: 'Você acha que a linguagem Move e a configuração orientada a objetos podem melhorar a segurança da blockchain?'"
Ele respondeu: "Eu não acho que isso muda alguma coisa, o projeto foi roubado, foi roubado, qualquer língua é a mesma."
Mas Kyrie contra-argumentou na hora, apontando que o Move realmente pode reduzir a chance de erros no desenvolvimento, sendo mais fácil de usar do que Rust, e que o modelo orientado a objetos ajuda a limitar o alcance do risco. "Quando um contrato é hackeado, a perda pode ser um valor limitado e não uma exposição ilimitada," acrescentou.
Embora Vitalik não tenha se manifestado na época, a disposição dele agora de propor o RISC-V como uma alternativa mais forte e modular sugere que houve uma leve mudança em sua atitude em relação ao design de linguagens e à segurança da blockchain.
Este artigo cirurgia de troca de coração do Ethereum? Vitalik propôs que a camada de execução do Ethereum pode substituir completamente a EVM, utilizando RISC-V apareceu pela primeira vez na ABMedia de notícias da cadeia.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Cirurgia de troca de coração do Ethereum? Vitalik propôs que a camada de execução do Ethereum pode substituir totalmente o EVM, utilizando RISC-V.
No futuro plano da Ethereum, uma nova proposta iniciada pelo co-fundador da Ethereum, Vitalik Buterin, gerou intensa discussão na comunidade: substituir o EVM (Máquina virtual Ethereum) pela linguagem de máquina virtual dos contratos inteligentes RISC-V. Esta ideia foi comparada a um "grande upgrade de nível de beam chain" na camada de execução, não apenas para aumentar a capacidade, mas também para resolver os gargalos fundamentais da complexidade e eficiência atuais da camada de execução.
O que é RISC-V? Por que substituir o EVM?
O núcleo da proposta é substituir a EVM, atualmente utilizada pelos contratos inteligentes do Ethereum, por uma arquitetura de conjunto de instruções modular e de código aberto — RISC-V. Essa transformação não irá derrubar as ferramentas de desenvolvedor existentes do Ethereum e os hábitos dos desenvolvedores, porque:
Os sistemas de contas existentes, chamadas entre contratos, métodos de armazenamento e outras camadas de abstração principais permanecem inalterados.
As linguagens Solidity e Vyper podem ser compiladas com RISC-V como backend, a experiência do desenvolvedor não terá grandes mudanças.
Os contratos EVM antigos ainda podem se comunicar bidirecionalmente com os novos contratos RISC-V.
Dessa forma, os desenvolvedores não precisam reaprender tudo, mas a performance e a simplicidade da camada base do Ethereum devem ser significativamente melhoradas.
ZK-EVM é o maior gargalo de desempenho
Com a futura implementação de várias propostas de escalabilidade (como EIP-4444, execução atrasada e clientes sem estado), os verdadeiros fatores que limitam a capacidade de escalabilidade do Ethereum L1 estarão concentrados em:
Amostragem de disponibilidade de dados e estabilidade dos protocolos de armazenamento histórico
Competição de mercado na produção de blocos
Eficiência da prova ZK-EVM
Atualmente, o processo de prova de um bloco no ZK-EVM consome cerca de 50% dos recursos apenas na execução da lógica da Máquina virtual EVM. Isso significa que, se for possível executar contratos inteligentes diretamente no ambiente RISC-V, há a oportunidade de aumentar a eficiência da prova ZK em até 50 vezes, ou mesmo 100 vezes.
É interessante notar que, atualmente, o processo de prova do ZK-EVM consiste, na verdade, em compilar o EVM para RISC-V e, em seguida, o sistema ZK realiza a prova. Portanto, permitir que o RISC-V se torne a máquina virtual nativa da camada de execução do Ethereum não só faz sentido, mas também pode economizar o consumo de recursos da conversão intermediária.
Por que RISC-V é rápido? Otimização total do design estrutural até a função de hash.
Atualmente, os quatro principais itens que consomem recursos no ZK-EVM são:
deserialize_inputs
initialize_witness_db
state_root_computation
execução de bloco
Os três primeiros podem ser significativamente otimizados utilizando funções de hash mais amigáveis (como Poseidon) e árvores de estado binárias. Por exemplo, o Poseidon pode processar 2 milhões de hashes por segundo em um laptop, muito superior às 15 mil vezes do Keccak. Se essas otimizações forem implementadas, a carga nos primeiros 50% será drasticamente reduzida.
mas os 50% restantes ainda vêm de
execução_de_blocos
Esta parte só pode ser resolvida fundamentalmente através de um design de VM mais eficiente, como o RISC-V.
Três tipos de implementações, desde as conservadoras até as radicais.
Vitalik propôs três caminhos de implementação técnica:
– Opção um: Máquinas virtuais duplas coexistindo (risco mínimo): permite que os contratos escolham usar EVM ou RISC-V, ambos interoperáveis e compartilhando recursos, equilibrando compatibilidade e inovação.
– Opção dois: RISC-V embalagem do interpretador EVM (upgrade radical): todos os contratos EVM serão executados através do interpretador EVM embutido no RISC-V, fazendo a transição da camada de execução geral para uma arquitetura subjacente unificada.
Opção três: suporte a interpretadores de máquina virtual na camada de protocolo (abordagem moderada): o protocolo é projetado com um "módulo de máquina virtual", implementando por padrão o interpretador EVM com RISC-V e permitindo a futura expansão para outras linguagens, como Move.
As vantagens comuns destes caminhos são: simplificar as especificações da camada de execução, aumentar a manutenibilidade e a transparência da verificação.
Co-fundador da Sui, empresa de desenvolvimento Mysten Labs: se pudesse recomeçar, escolheria Move, sem considerar múltiplas linguagens.
Em relação a esta proposta, Sam Blackshear, cofundador da empresa de desenvolvimento Sui, Mysten Labs, também expressou sua opinião. Ele afirmou: "Acredito que adotar um backend RISC-V é uma boa escolha para o Ethereum (pois precisa suportar contratos existentes da EVM). Mas se eu tivesse que projetar uma nova cadeia do zero, ainda escolheria Move, em vez de suporte a múltiplas linguagens. Muitas das vantagens do Sui vêm do uso de objetos fortemente tipados em toda a pilha como uma camada de abstração comum."
Isto reflete os fatores históricos da "estratégia de escolha da máquina virtual" entre diferentes cadeias. O Ethereum foi desenvolvido inicialmente sem a capacidade de prever as numerosas necessidades e desenvolvimentos futuros. Atualmente, está a adaptar-se às mudanças, enfatizando a compatibilidade e o design de transição; enquanto a nova blockchain Sui foca na integração total da pilha, desde a linguagem até ao nível inferior, permitindo uma estreita integração entre desenvolvimento e segurança.
Typus Finance crescimento Kyrie também compartilhou uma conversa que teve com Vitalik em um evento do EthTaipei no passado. Ele se lembrou: "Naquela época, eu perguntei ao Vitalik: 'Você acha que a linguagem Move e a configuração orientada a objetos podem melhorar a segurança da blockchain?'"
Ele respondeu: "Eu não acho que isso muda alguma coisa, o projeto foi roubado, foi roubado, qualquer língua é a mesma."
Mas Kyrie contra-argumentou na hora, apontando que o Move realmente pode reduzir a chance de erros no desenvolvimento, sendo mais fácil de usar do que Rust, e que o modelo orientado a objetos ajuda a limitar o alcance do risco. "Quando um contrato é hackeado, a perda pode ser um valor limitado e não uma exposição ilimitada," acrescentou.
Embora Vitalik não tenha se manifestado na época, a disposição dele agora de propor o RISC-V como uma alternativa mais forte e modular sugere que houve uma leve mudança em sua atitude em relação ao design de linguagens e à segurança da blockchain.
Este artigo cirurgia de troca de coração do Ethereum? Vitalik propôs que a camada de execução do Ethereum pode substituir completamente a EVM, utilizando RISC-V apareceu pela primeira vez na ABMedia de notícias da cadeia.