Texto completo da proposta de camada executiva L1 de longo prazo da Vitalik: substituindo o EVM por RISC-V

Fonte: Vitalik Buterin

Compilação: KarenZ, Foresight News

Em 20 de abril, Vitalik Buterin apresentou uma importante proposta na plataforma Ethereum Magicians para a camada de execução L1 de longo prazo da 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, romper um dos principais gargalos de dimensionamento 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 entender essa visão técnica. A seguir, 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 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 por RISC-V como uma linguagem de máquina virtual para contratos inteligentes.

Anotações importantes:

• Conceitos como sistema de contas, chamadas de contratos cruzados, 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 DE SISTEMA RISC-V.

• Nesse 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 back-end. 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 perceber a mudança.

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

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

Por que?

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 dimensionamento 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 dimensionamento do Ethereum L1 serão:

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

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

3. Prova do ZK-EVM

Argumentarei que substituir ZK-EVM por 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 EVM à prova de ZK-EVM sucinta:

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

Essas seções podem ser bastante otimizadas substituindo a atual árvore de Merkle patricia keccak 16-ary por uma árvore binária que usa uma função hash fácil de provar. Se usarmos o Poseidon, podemos provar 2 milhões de hashes por segundo em um laptop (em comparação com cerca de 15.000 hash/s para keccak). Além de 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.

O block_execution restante é responsável por cerca de metade dos ciclos atuais de provadores. Para obter 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 é observar 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 ganhos de eficiência de mais de 100 vezes podem ocorrer em determinadas situações:

Na prática, o tempo restante do provador pode ser ocupado principalmente pela operação de pré-compilação atual. Com o RISC-V como a 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 do EVM também é próximo de 50/50, portanto, intuitivamente assumimos que remover o EVM como uma "camada intermediária" trará um ganho igualmente significativo.)

Detalhes da implementação

Existem várias maneiras de implementar esta proposta. A solução menos disruptiva é 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), capacidade de manter saldos de ETH, iniciar/receber chamadas e muito mais. Os contratos EVM e RISC-V podem ser chamados entre si - de uma perspectiva 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 um CALL.

Uma abordagem mais radical do ponto de vista do 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 código C e o interpretador EVM estiver no endereço X, 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), aguarda o valor de retorno e encaminha. Se o próprio interpretador EVM chamar o contrato, solicitando a execução de CALL ou SLOAD/SSTORE, o contrato executará essas operações.

O compromisso é a segunda opção, mas com suporte explícito ao conceito de "intérprete de máquina virtual" por meio de um protocolo que exige que sua lógica seja escrita em RISC-V. O EVM será a primeira instância, com suporte para outros idiomas no futuro (o 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 REMOVER SIMPLIFICAÇÕES INCREMENTAIS COMO A AUTODESTRUIÇÃO, ESSA LINHA DE PENSAMENTO PODE SER O ÚNICO CAMINHO VIÁVEL PARA SIMPLIFICAR. O Tinygrad adere à regra rígida de "não mais do que 10.000 linhas de código", e o blockchain subjacente ideal deve ser capaz de atender facilmente 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 obter um impulso semelhante na camada de execução.