No dia 20 de abril, Vitalik Buterin apresentou uma proposta importante sobre a camada de execução L1 do Ethereum na plataforma Ethereum Magicians. Ele sugeriu a adoção da arquitetura RISC-V para substituir a atual EVM (Máquina Virtual Ethereum) como a linguagem da máquina virtual para a escrita de contratos inteligentes, com o objetivo de melhorar fundamentalmente a eficiência operacional da camada de execução do Ethereum, superando um dos principais gargalos de escalabilidade atuais, ao mesmo tempo que simplifica significativamente a clareza da camada de execução.
A Foresight News fez uma compilação completa desta proposta, com o objetivo de ajudar os leitores a entender esta ideia tecnológica. Abaixo está o conteúdo compilado do texto original da proposta:
Este artigo apresenta uma ideia radical sobre o futuro da camada de execução do Ethereum, cuja ambição é tão grande quanto o plano Beam Chain da camada de consenso. A proposta visa aumentar significativamente a eficiência da camada de execução do Ethereum, resolvendo um dos principais gargalos de escalabilidade e simplificando significativamente a camada de execução - na verdade, esta pode ser a única maneira de alcançar esse objetivo.
Ideia central: substituir o EVM pelo RISC-V como a linguagem da máquina virtual para a escrita de contratos inteligentes.
Nota importante:
O sistema de contas, chamadas entre contratos, armazenamento e outros conceitos serão totalmente preservados. Esses designs abstratos funcionam bem e os desenvolvedores já estão acostumados a usá-los. Os códigos de operação SLOAD, SSTORE, BALANCE, CALL, entre outros, serão convertidos em chamadas de sistema RISC-V.
Neste modo, os contratos inteligentes podem ser escritos em Rust, mas espero que a maioria dos desenvolvedores continue a escrever contratos em Solidity (ou Vyper), que se adaptará ao RISC-V como o novo backend. Porque os contratos inteligentes escritos em Rust são realmente menos legíveis, enquanto Solidity e Vyper são mais claros e fáceis de ler. A experiência de desenvolvimento pode ser pouco afetada, e os desenvolvedores podem nem notar a mudança.
Os contratos EVM da versão antiga continuarão a funcionar e serão totalmente compatíveis de forma bidirecional com os contratos RISC-V da nova versão. Existem várias maneiras de implementar isso, que serão discutidas em detalhe mais adiante neste artigo.
Nervos CKB VM já estabeleceu um precedente, que na sua essência é uma implementação RISC-V.
Por que fazer isso?
A curto prazo, os EIPs que serão implementados (como listas de acesso em nível de bloco, execução atrasada, armazenamento de histórico distribuído e EIP-4444) podem resolver os principais gargalos de escalabilidade do Ethereum L1. A médio prazo, mais problemas serão resolvidos por meio da sem estado e ZK-EVM. A longo prazo, os principais fatores limitantes da escalabilidade do Ethereum L1 se tornarão:
Estabilidade do protocolo de amostragem de disponibilidade de dados e armazenamento histórico
Manter a competitividade do mercado de produção de blocos.
A capacidade de prova do ZK-EVM
Vou argumentar que substituir o ZK-EVM pelo RISC-V pode resolver os principais gargalos em (2) e (3).
A tabela abaixo mostra o número de ciclos necessários para cada etapa da execução da EVM no Succinct ZK-EVM:
Descrição do gráfico: As quatro principais etapas que consomem tempo são deserialize_inputs, initialize_witness_db, state_root_computation e block_execution.
Entre initialize_witness_db e state_root_computation estão relacionados à árvore de estados, enquanto deserialize_inputs envolve o processo de conversão de blocos e dados de testemunho em representações internas - na verdade, mais de 50% é proporcional ao tamanho dos dados de testemunho.
Essas seções podem ser muito otimizadas substituindo a atual árvore Merkle patricia keccak 16-ary por uma árvore binária que usa uma função hash fácil de provar. Se usarmos Poseidon, podemos provar 2 milhões de hashes por segundo em um laptop (para comparação, keccak é cerca de 15.000 hash / seg). Além do Poseidon, existem muitas outras opções. No geral, há muito espaço para otimização para esses componentes. Além disso, podemos eliminar acumular_logs_bloom removendo a floração.
O bloco_execution restante representa cerca de metade do ciclo de prova atual (prover cycles). Para alcançar um aumento de 100 vezes na eficiência global da prova, a eficiência da prova EVM precisa ser aumentada pelo menos 50 vezes. Uma das soluções é criar uma implementação de prova mais eficiente para EVM, outra solução é notar que o provador ZK-EVM atual está realmente provando ao compilar EVM para RISC-V, permitindo que os desenvolvedores de contratos inteligentes acessem diretamente essa máquina virtual RISC-V.
Alguns dados mostram que, em determinadas situações, o aumento da eficiência pode ultrapassar 100 vezes:
Na prática, o tempo restante do prover pode ser principalmente ocupado pelas operações de pré-compilação atuais. Se o RISC-V for usado como a máquina virtual principal, a programação de Gas refletirá o tempo de prova real, e a pressão econômica incentivará os desenvolvedores a reduzir o uso de pré-compilações de alto custo. Mesmo assim, os ganhos não serão tão significativos, mas temos razões para acreditar que esses ganhos serão bastante consideráveis.
(É importante notar que a proporção do tempo de execução entre "operações EVM" e "outras operações" na execução EVM convencional também é próxima de 50/50, portanto acreditamos intuitivamente que remover a EVM como "camada intermediária" trará um ganho igualmente significativo.)
Detalhes de implementação
A proposta tem várias formas de implementação. A solução com menor impacto destrutivo é suportar simultaneamente duas máquinas virtuais, permitindo que os contratos sejam escritos em qualquer uma delas. Ambos os tipos de contratos podem acessar as mesmas funcionalidades: armazenamento persistente (SLOAD/SSTORE), capacidade de manter um saldo de ETH, iniciar / receber chamadas, etc. Contratos EVM e RISC-V podem chamar um ao outro - do ponto de vista do RISC-V, chamar um contrato EVM equivale a executar uma chamada de sistema com parâmetros especiais; enquanto o contrato EVM que recebe a mensagem a interpretará como CALL.
Uma abordagem mais agressiva do ponto de vista do protocolo é converter contratos EVM existentes para chamar um contrato interpretador EVM escrito em RISC-V, executando seu código EVM existente. Ou seja, se um contrato EVM tiver o código C, e o interpretador EVM estiver no endereço X, então esse contrato será substituído pela lógica de nível superior, quando for chamado externamente com o parâmetro D, chamando X e passando (C, D), e aguardando o valor de retorno para encaminhar. Se o interpretador EVM chamar o contrato, solicitando a execução de CALL ou SLOAD/SSTORE, então o contrato executará essas operações.
A solução de compromisso é adotar a segunda opção, mas com um protocolo que suporte claramente o conceito de "interpretador de máquina virtual", exigindo que sua lógica seja escrita em RISC-V. O EVM será o primeiro exemplo, e no futuro, outras linguagens poderão ser suportadas (Move pode ser uma opção candidata).
As principais vantagens das segundas e terceiras propostas residem no fato de que podem simplificar drasticamente as especificações da camada de execução. Considerando que até mesmo a remoção de SELFDESTRUCT, uma simplificação gradual, é repleta de dificuldades, essa abordagem pode ser o único caminho viável para a simplificação. O Tinygrad segue a rígida regra de "o código não deve exceder 10.000 linhas", enquanto a blockchain ideal deve ser capaz de atender a essa limitação com facilidade e ainda se tornar mais enxuta. O plano da Beam Chain promete simplificar significativamente a camada de consenso do Ethereum, e se a camada de execução quiser alcançar melhorias semelhantes, essa transformação radical pode ser o único caminho viável.
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.
Proposta completa de Vitalik para a camada de execução L1 a longo prazo: substituir EVM por RISC-V
Fonte: Vitalik Buterin
Compilado por: KarenZ, Foresight News
No dia 20 de abril, Vitalik Buterin apresentou uma proposta importante sobre a camada de execução L1 do Ethereum na plataforma Ethereum Magicians. Ele sugeriu a adoção da arquitetura RISC-V para substituir a atual EVM (Máquina Virtual Ethereum) como a linguagem da máquina virtual para a escrita de contratos inteligentes, com o objetivo de melhorar fundamentalmente a eficiência operacional da camada de execução do Ethereum, superando um dos principais gargalos de escalabilidade atuais, ao mesmo tempo que simplifica significativamente a clareza da camada de execução.
A Foresight News fez uma compilação completa desta proposta, com o objetivo de ajudar os leitores a entender esta ideia tecnológica. Abaixo está o conteúdo compilado do texto original da proposta:
Este artigo apresenta uma ideia radical sobre o futuro da camada de execução do Ethereum, cuja ambição é tão grande quanto o plano Beam Chain da camada de consenso. A proposta visa aumentar significativamente a eficiência da camada de execução do Ethereum, resolvendo um dos principais gargalos de escalabilidade e simplificando significativamente a camada de execução - na verdade, esta pode ser a única maneira de alcançar esse objetivo.
Ideia central: substituir o EVM pelo RISC-V como a linguagem da máquina virtual para a escrita de contratos inteligentes.
Nota importante:
O sistema de contas, chamadas entre contratos, armazenamento e outros conceitos serão totalmente preservados. Esses designs abstratos funcionam bem e os desenvolvedores já estão acostumados a usá-los. Os códigos de operação SLOAD, SSTORE, BALANCE, CALL, entre outros, serão convertidos em chamadas de sistema RISC-V.
Neste modo, os contratos inteligentes podem ser escritos em Rust, mas espero que a maioria dos desenvolvedores continue a escrever contratos em Solidity (ou Vyper), que se adaptará ao RISC-V como o novo backend. Porque os contratos inteligentes escritos em Rust são realmente menos legíveis, enquanto Solidity e Vyper são mais claros e fáceis de ler. A experiência de desenvolvimento pode ser pouco afetada, e os desenvolvedores podem nem notar a mudança.
Os contratos EVM da versão antiga continuarão a funcionar e serão totalmente compatíveis de forma bidirecional com os contratos RISC-V da nova versão. Existem várias maneiras de implementar isso, que serão discutidas em detalhe mais adiante neste artigo.
Nervos CKB VM já estabeleceu um precedente, que na sua essência é uma implementação RISC-V.
Por que fazer isso?
A curto prazo, os EIPs que serão implementados (como listas de acesso em nível de bloco, execução atrasada, armazenamento de histórico distribuído e EIP-4444) podem resolver os principais gargalos de escalabilidade do Ethereum L1. A médio prazo, mais problemas serão resolvidos por meio da sem estado e ZK-EVM. A longo prazo, os principais fatores limitantes da escalabilidade do Ethereum L1 se tornarão:
Estabilidade do protocolo de amostragem de disponibilidade de dados e armazenamento histórico
Manter a competitividade do mercado de produção de blocos.
A capacidade de prova do ZK-EVM
Vou argumentar que substituir o ZK-EVM pelo RISC-V pode resolver os principais gargalos em (2) e (3).
A tabela abaixo mostra o número de ciclos necessários para cada etapa da execução da EVM no Succinct ZK-EVM:
Descrição do gráfico: As quatro principais etapas que consomem tempo são deserialize_inputs, initialize_witness_db, state_root_computation e block_execution.
Entre initialize_witness_db e state_root_computation estão relacionados à árvore de estados, enquanto deserialize_inputs envolve o processo de conversão de blocos e dados de testemunho em representações internas - na verdade, mais de 50% é proporcional ao tamanho dos dados de testemunho.
Essas seções podem ser muito otimizadas substituindo a atual árvore Merkle patricia keccak 16-ary por uma árvore binária que usa uma função hash fácil de provar. Se usarmos Poseidon, podemos provar 2 milhões de hashes por segundo em um laptop (para comparação, keccak é cerca de 15.000 hash / seg). Além do Poseidon, existem muitas outras opções. No geral, há muito espaço para otimização para esses componentes. Além disso, podemos eliminar acumular_logs_bloom removendo a floração.
O bloco_execution restante representa cerca de metade do ciclo de prova atual (prover cycles). Para alcançar um aumento de 100 vezes na eficiência global da prova, a eficiência da prova EVM precisa ser aumentada pelo menos 50 vezes. Uma das soluções é criar uma implementação de prova mais eficiente para EVM, outra solução é notar que o provador ZK-EVM atual está realmente provando ao compilar EVM para RISC-V, permitindo que os desenvolvedores de contratos inteligentes acessem diretamente essa máquina virtual RISC-V.
Alguns dados mostram que, em determinadas situações, o aumento da eficiência pode ultrapassar 100 vezes:
Na prática, o tempo restante do prover pode ser principalmente ocupado pelas operações de pré-compilação atuais. Se o RISC-V for usado como a máquina virtual principal, a programação de Gas refletirá o tempo de prova real, e a pressão econômica incentivará os desenvolvedores a reduzir o uso de pré-compilações de alto custo. Mesmo assim, os ganhos não serão tão significativos, mas temos razões para acreditar que esses ganhos serão bastante consideráveis.
(É importante notar que a proporção do tempo de execução entre "operações EVM" e "outras operações" na execução EVM convencional também é próxima de 50/50, portanto acreditamos intuitivamente que remover a EVM como "camada intermediária" trará um ganho igualmente significativo.)
Detalhes de implementação
A proposta tem várias formas de implementação. A solução com menor impacto destrutivo é suportar simultaneamente duas máquinas virtuais, permitindo que os contratos sejam escritos em qualquer uma delas. Ambos os tipos de contratos podem acessar as mesmas funcionalidades: armazenamento persistente (SLOAD/SSTORE), capacidade de manter um saldo de ETH, iniciar / receber chamadas, etc. Contratos EVM e RISC-V podem chamar um ao outro - do ponto de vista do RISC-V, chamar um contrato EVM equivale a executar uma chamada de sistema com parâmetros especiais; enquanto o contrato EVM que recebe a mensagem a interpretará como CALL.
Uma abordagem mais agressiva do ponto de vista do protocolo é converter contratos EVM existentes para chamar um contrato interpretador EVM escrito em RISC-V, executando seu código EVM existente. Ou seja, se um contrato EVM tiver o código C, e o interpretador EVM estiver no endereço X, então esse contrato será substituído pela lógica de nível superior, quando for chamado externamente com o parâmetro D, chamando X e passando (C, D), e aguardando o valor de retorno para encaminhar. Se o interpretador EVM chamar o contrato, solicitando a execução de CALL ou SLOAD/SSTORE, então o contrato executará essas operações.
A solução de compromisso é adotar a segunda opção, mas com um protocolo que suporte claramente o conceito de "interpretador de máquina virtual", exigindo que sua lógica seja escrita em RISC-V. O EVM será o primeiro exemplo, e no futuro, outras linguagens poderão ser suportadas (Move pode ser uma opção candidata).
As principais vantagens das segundas e terceiras propostas residem no fato de que podem simplificar drasticamente as especificações da camada de execução. Considerando que até mesmo a remoção de SELFDESTRUCT, uma simplificação gradual, é repleta de dificuldades, essa abordagem pode ser o único caminho viável para a simplificação. O Tinygrad segue a rígida regra de "o código não deve exceder 10.000 linhas", enquanto a blockchain ideal deve ser capaz de atender a essa limitação com facilidade e ainda se tornar mais enxuta. O plano da Beam Chain promete simplificar significativamente a camada de consenso do Ethereum, e se a camada de execução quiser alcançar melhorias semelhantes, essa transformação radical pode ser o único caminho viável.