Texto completo da proposta de camada executiva L1 de longo prazo da Vitalik: substituição do EVM pelo RISC-V

Fonte: Vitalik Buterin

Compilação: KarenZ, Foresight News

Em 20 de abril, Vitalik Buterin apresentou uma proposta importante na plataforma Ethereum Magicians para a camada de execução L1 de longo prazo do Ethereum. Ele propôs substituir o EVM (Ethereum Virtual Machine) existente pela arquitetura RISC-V como uma linguagem de máquina virtual para escrever contratos inteligentes, com o objetivo de melhorar fundamentalmente a eficiência operacional da camada de execução do Ethereum, quebrar um dos principais gargalos de escala atuais e simplificar muito a simplicidade da camada de execução.

A Foresight News compilou o texto completo da proposta para ajudar os leitores a compreender esta visão técnica. Segue-se uma compilação da proposta original:

Este artigo apresenta uma ideia radical sobre o futuro da camada de execução do Ethereum, não menos ambiciosa do que as iniciativas da Beam Chain da camada de consenso. A proposta visa melhorar drasticamente a eficiência da camada de execução do Ethereum, resolver um dos principais gargalos de escala e simplificar significativamente a camada de execução – na verdade, essa pode ser a única maneira de conseguir isso.

Ideia central: substituir o EVM pelo RISC-V como uma linguagem de máquina virtual para contratos inteligentes.

Observações importantes:

• Conceitos como sistema de conta, chamadas entre contratos, armazenamento, etc., serão totalmente mantidos. Esses designs abstratos funcionam bem e os desenvolvedores estão acostumados a usá-los. OPCODES COMO SLOAD, SSTORE, BALANCE, CALL, ETC., SÃO CONVERTIDOS EM CHAMADAS DO 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.

• O antigo contrato EVM continuará a funcionar e é totalmente compatível bidirecionalmente com o novo contrato RISC-V. Existem várias maneiras de fazer isso, que serão discutidas em mais detalhes mais adiante neste artigo.

Nervos CKB VM estabeleceu um precedente e é essencialmente uma implementação RISC-V.

Porquê?

No curto prazo, os próximos EIPs (por exemplo, listas de acesso em nível de bloco, execução diferida, armazenamento de histórico distribuído e EIP-4444) abordarão os principais gargalos de escala do Ethereum L1. Mais problemas serão resolvidos a médio prazo com a apatridia e o ZK-EVM. A longo prazo, os principais fatores limitantes para o escalonamento do Ethereum L1 se tornarão:

1. Estabilidade dos protocolos de disponibilidade, amostragem e armazenamento histórico de dados

2. Manter a demanda por concorrência no mercado de produção de blocos

3. Prova do ZK-EVM

Argumentarei que a substituição do ZK-EVM pelo RISC-V pode resolver os principais gargalos em (2) e (3).

A tabela a seguir ilustra o número de ciclos necessários para cada etapa da camada de execução do Succinct ZK-EVM Proof EVM:

Descrição do diagrama: Os quatro principais segmentos demorados são deserialize_inputs, initialize_witness_db, state_root_computation e block_execution

initialize_witness_db e state_root_computation estão relacionados a árvores de estado, e deserialize_inputs envolvem o processo de conversão de dados de bloco e testemunha em representações internas – mais de 50% das quais são realmente proporcionais ao tamanho dos dados testemunhais.

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 (em comparação com cerca de 15.000 hash / seg para keccak). 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 accrue_logs_bloom removendo a floração.

Os restantes block_execution representam cerca de metade dos atuais ciclos de provação. Para alcançar um aumento de 100x na eficiência geral da prova, é necessária uma eficiência de prova EVM de pelo menos 50x. Uma solução é criar uma implementação de prova mais eficiente para o EVM, e a outra é notar que o provador ZK-EVM atual realmente compila o EVM para RISC-V para prova, dando aos desenvolvedores de contratos inteligentes acesso direto à máquina virtual RISC-V.

Alguns dados mostram que podem ocorrer ganhos de eficiência superiores a 100 vezes em determinadas situações:

Na prática, o tempo de provação restante pode ser ocupado principalmente pela operação de pré-compilação atual. Com o RISC-V como VM principal, o cronograma de gás refletirá o tempo real de prova, e a pressão econômica levará os desenvolvedores a reduzir o uso de pré-compilação de alto custo. Mesmo assim, os ganhos não serão tão significativos, mas temos boas razões para acreditar que serão substanciais.

(Vale a pena notar que o tempo necessário para "operações EVM" e "outras operações" na execução regular de EVM também está perto de 50/50, então intuitivamente assumimos que remover o EVM como uma "camada intermediária" trará um ganho igualmente significativo.)

Detalhes da implementação

Existem várias formas de aplicar esta proposta. A solução menos perturbadora é oferecer suporte a ambas as máquinas virtuais e permitir que o contrato seja escrito em uma delas. Ambos os tipos de contratos têm acesso aos mesmos recursos: armazenamento persistente (SLOAD/SSTORE), a capacidade de manter saldos de ETH, iniciar/receber chamadas e muito mais. Os contratos EVM e RISC-V podem ser chamados um ao outro - de uma perspetiva RISC-V, chamar o contrato EVM é equivalente a executar uma chamada de sistema com parâmetros especiais; O contrato EVM que recebe a mensagem irá interpretá-la como uma CHAMADA.

Uma abordagem mais radical de uma perspetiva de protocolo é converter um contrato EVM existente em uma chamada para um contrato de intérprete EVM escrito em RISC-V para executar 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 o contrato será substituído por uma lógica de nível superior que, quando chamada de fora com um argumento de chamada D, chama X e passa (C, D), então aguarda o valor de retorno e encaminha. Se o próprio intérprete EVM ligar para o contrato, pedindo para executar CALL ou SLOAD/SSTORE, o contrato executa essas operações.

O compromisso é a segunda opção, mas com suporte explícito para o conceito de um "interpretador de máquina virtual" através de um protocolo que requer que sua lógica seja escrita em RISC-V. EVM será a primeira instância, com suporte para outros idiomas no futuro (Move pode ser um candidato).

A principal vantagem da segunda e terceira opções é que elas simplificam muito a especificação da camada de execução. DADA A DIFICULDADE DE ATÉ MESMO REMOVER SIMPLIFICAÇÕES INCREMENTAIS COMO A AUTODESTRUIÇÃO, ESSA LINHA DE PENSAMENTO PODE SER O ÚNICO CAMINHO VIÁVEL PARA SIMPLIFICAR. Tinygrad adere à regra rígida de "não mais de 10.000 linhas de código", e o blockchain subjacente ideal deve ser capaz de facilmente atender a esse limite e simplificá-lo ainda mais. A iniciativa Beam Chain promete simplificar drasticamente a camada de consenso do Ethereum, e uma mudança tão radical pode ser a única maneira de alcançar um impulso semelhante na camada de execução.