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.
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.
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.