Nova proposta de Vitalik: substituir o atual EVM pelo RISC-V

Este artigo propõe uma ideia radical para o futuro da camada de execução do Ethereum, uma ideia tão ambiciosa quanto os esforços da Beam Chain em relação à camada de consenso. Visa aumentar significativamente a eficiência da camada de execução do Ethereum, resolver um dos principais gargalos de escalabilidade e também pode aumentar significativamente a simplicidade da camada de execução — de fato, talvez seja o único método.

Ideia: substituir o EVM pela linguagem de máquina virtual RISC-V para escrever contratos inteligentes (nota do tradutor: RISC-V refere-se a uma arquitetura de conjunto de instruções aberta baseada no princípio RISC de conjuntos de instruções reduzidas, onde V representa a quinta geração de RISC).

Importante esclarecimento:

• As contas, chamadas entre contratos, armazenamento e outros conceitos permanecerão totalmente os mesmos. Esses abstrações funcionam muito bem e os desenvolvedores estão acostumados a elas. Operações como SLOAD, SSTORE, BALANCE, CALL se tornarão chamadas de sistema RISC-V.
• Num mundo assim, os contratos inteligentes podem ser escritos em Rust, mas eu espero que a maioria dos desenvolvedores continue a escrever contratos inteligentes em Solidity (ou Vyper), o que se adaptará à adição do RISC-V como backend. Isso porque os contratos inteligentes escritos em Rust são na verdade bastante feios, enquanto a legibilidade de Solidity e Vyper é muito maior. Talvez a mudança no devex seja pequena, e os desenvolvedores possam quase não notar essa mudança.
• Os contratos EVM antigos continuarão válidos e serão totalmente interoperáveis em ambas as direções com os novos contratos RISC-V. Há várias maneiras de fazer isso, que irei apresentar mais adiante neste artigo.

Um precedente é o Nervos CKB VM, que é basicamente RISC-V.

Por que fazer isso?

A curto prazo, o principal gargalo da escalabilidade do Ethereum L1 será resolvido através dos próximos EIPs, como listas de acesso a blocos, execução atrasada e armazenamento de histórico distribuído, bem como o EIP-4444. A médio prazo, abordaremos questões adicionais relacionadas ao sem estado e ao ZK-EVM. A longo prazo, os principais fatores limitantes da escalabilidade do Ethereum Layer 1 são:

• Amostragem de disponibilidade de dados e estabilidade do protocolo de armazenamento histórico
• Espero manter a competitividade do mercado de produção de blocos
• Capacidade de verificação do ZK-EVM

Acredito que substituir o ZK-EVM pelo RISC-V pode resolver um dos principais gargalos em (2) e (3).

Esta é a tabela de contagem de ciclos para diferentes partes da camada de execução EVM usada pelo Succinct ZK-EVM:

Existem quatro partes que consomem muito tempo: deserialize_inputs, initialize_witness_db, state_root_computation e block_execution.

initialize_witness_db e state_root_computation estão relacionados com a árvore de estado, deserialize_inputs refere-se ao processo de conversão de dados de bloco e testemunho para uma representação interna; portanto, na verdade, mais de 50% é proporcional ao tamanho do testemunho.

Podemos otimizar significativamente essas partes substituindo a árvore Merkle patricia de 16 elementos keccak atual por uma árvore binária que utiliza uma função hash amigável para provadores. Se usarmos o Poseidon, podemos provar 2 milhões de hashes por segundo em um laptop (enquanto o keccak processa cerca de 15.000 hashes por segundo). Além do Poseidon, há muitas outras opções. Em resumo, temos a oportunidade de reduzir drasticamente esses componentes. Como recompensa, podemos nos livrar do accrue_logs_bloom ao eliminar o bloom.

O que resta é o block_execution, que representa cerca de metade do ciclo de prova gasto hoje. Se quisermos aumentar a eficiência do provador geral em 100 vezes, não podemos evitar o fato de que precisamos pelo menos aumentar a eficiência do provador EVM em 50 vezes. Uma coisa que podemos fazer é tentar criar uma implementação EVM mais eficiente em termos de ciclo de prova. Outra coisa que podemos fazer é notar que o provador ZK-EVM já está funcionando hoje através da prova compilada para a implementação EVM RISC-V, e permitir que os desenvolvedores de contratos inteligentes acessem diretamente essa VM RISC-V.

Alguns dados indicam que, em condições limitadas, isso pode aumentar a eficiência em mais de 100 vezes:

! JuLOouHUiv8vXajoUnYsOnYyFtRiCpO8cvkOUhPu.jpeg na verdade, espero que o tempo restante de prova seja dominado pela pré-compilação de hoje. Se tomarmos RISC-V como a máquina virtual primária, então o plano de gás refletirá o tempo de prova, então haverá pressão financeira para parar de usar a pré-compilação mais cara; Mas, mesmo assim, os ganhos não serão tão impressionantes, mas temos boas razões para acreditar que serão significativos.

(A propósito, uma divisão de cerca de 50/50 entre “EVM” e “outras coisas” também aparece na execução regular da EVM, e prevemos intuitivamente que os ganhos removidos da EVM como “intermediário” deveriam ser igualmente grandes)

Detalhes de implementação

Existem várias maneiras de implementar tais sugestões. O método de menor destruição é suportar duas máquinas virtuais e permitir a escrita de contratos em qualquer uma delas. Ambos os tipos de contratos podem usar o mesmo tipo de facilidades: armazenamento persistente (SLOAD e SSTORE), capacidade de manter um saldo de ETH, capacidade de fazer e receber chamadas, etc. Os contratos EVM e RISC-V podem chamar-se mutuamente livremente; do ponto de vista do RISC-V, chamar um contrato EVM parece ser uma chamada de sistema com alguns parâmetros especiais; o contrato EVM que recebe a mensagem irá interpretá-la como CALL.

Do ponto de vista do protocolo, uma abordagem mais agressiva é converter os contratos EVM existentes em contratos que chamam um interpretador EVM escrito em RISC-V, que executa seu código EVM existente. Ou seja, se um contrato EVM tiver um 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 chamado externamente com os parâmetros de chamada D, chamando X com (C, D), e então aguardando o valor de retorno e o encaminhando. Se o interpretador EVM chamar um contrato, exigindo a execução de CALL ou SLOAD/SSTORE, então o contrato fará isso.

A rota intermediária é adotar a segunda opção, mas criar uma função de protocolo clara para ela - basicamente, consagrar o conceito de “interpretador de máquina virtual” como um princípio e exigir que sua lógica seja escrita em RISC-V. O EVM será o primeiro, mas pode haver outros (por exemplo, o Move pode ser um candidato).

Uma das principais vantagens das segunda e terceira propostas é que elas simplificam enormemente a especificação da camada de execução — de fato, essa ideia pode ser a única abordagem viável, pois até mesmo uma simplificação progressiva, como a remoção do SELFDESTRUCT, é extremamente difícil. O Tinygrad tem uma regra estrita de que a quantidade de código nunca deve exceder 10.000 linhas; a melhor camada de base da blockchain deve ser capaz de se adaptar bem a esses limites, ou até mesmo menores. Os esforços da Beam Chain têm grande esperança de simplificar significativamente a camada de consenso do Ethereum. Mas, para a camada de execução, essa mudança radical pode ser a única maneira de obter benefícios semelhantes.