Esta postagem propõe uma ideia radical para o futuro da camada de execução do Ethereum, tão ambiciosa quanto o esforço da cadeia de feixes para a camada de consenso. O objetivo é melhorar significativamente a eficiência da camada de execução do Ethereum, resolvendo um dos principais gargalos de escalabilidade, e também pode melhorar muito a simplicidade da camada de execução - na verdade, talvez seja a única maneira de fazê-lo.

A ideia: substituir o EVM pelo RISC-V como a linguagem da máquina virtual na qual os contratos inteligentes são escritos.

Important clarifications:

• Os conceitos de contas, chamadas entre contratos, armazenamento, etc., permaneceriam exatamente iguais. Essas abstrações funcionam bem e os desenvolvedores estão acostumados a elas. Opcodes como SLOAD, SSTORE, BALANCE, CALL, etc., se tornariam chamadas de sistema RISC-V.
• Neste mundo, os contratos inteligentes poderiam ser escritos em Rust, mas eu espero que a maioria dos desenvolvedores continue escrevendo contratos inteligentes em Solidity (ou Vyper), que se adaptaria para adicionar RISC-V como um backend. Isso porque os contratos inteligentes escritos em Rust são na verdadebastantefeio, e Solidity e Vyper são muitomaislegívelPotencialmente, o devex mudaria muito pouco e os desenvolvedores talvez mal percebessem a mudança.
• Contratos EVM no estilo antigo continuarão a funcionar e serão totalmente interoperáveis em ambas as direções com contratos RISC-V no estilo novo. Existem algumas maneiras de fazer isso, nas quais falarei mais tarde nesta postagem.

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

Por que fazer isso?

No curto prazo, os principais gargalos de escalabilidade da Ethereum L1 são abordados com os próximos EIPs, como listas de acesso de nível de bloco, execução atrasadae armazenamento de histórico distribuído plusEIP-4444. No médio prazo, abordamos mais questões comapatridiaeZK-EVMsNo longo prazo, os principais fatores limitantes na escalabilidade da Ethereum L1 são:

1. Estabilidade de amostragem de disponibilidade de dados e protocolos de armazenamento de histórico
2. Desejo de manter a produção de blocos como um mercado competitivo
3. Capacidades de comprovação ZK-EVM

Vou argumentar que substituir o ZK-EVM pelo RISC-V resolve um gargalo chave em (2) e (3).

Esta é uma tabela do número de ciclos que o Succinct ZK-EVM usa para provar diferentes partes da camada de execução EVM:

Existem quatro partes que consomem uma quantidade significativa de tempo: deserialize_inputs, initialize_witness_db, state_root_computation e block_execution.

initialize_witness_db e state_root_computation têm a ver com a árvore de estado, e deserialize_inputs refere-se ao processo de converter dados de bloco e testemunha em uma representação interna; portanto, realisticamente mais de 50% disso é proporcional aos tamanhos de testemunhas.

Essas partes podem ser altamente otimizadas substituindo a atual árvore patricia Merkle 16-ária keccak por uma árvore binária que usa uma função de hash amigável ao verificador. Se usarmos Poseidon, podemos provar 2 milhões de hashes por segundoem um laptop (em comparação com ~15.000 hash/seg para keccak). Há também muitas opções além de Poseidon. No geral, existem oportunidades para reduzir massivamente esses componentes. Como bônus, podemos nos livrar de accrue_logs_bloom, bem,livrando-se do florescimento.

Isso deixa a execução do bloco, que representa cerca de metade dos ciclos do provador gastos hoje. Se quisermos aumentar em 100 vezes a eficiência total do provador, não há como contornar o fato de que precisamos aumentar em pelo menos 50 vezes a eficiência do provador EVM. Uma coisa que poderíamos fazer é tentar criar implementações do EVM muito mais eficientes em termos de ciclos do provador. A outra coisa que podemos fazer é notar que os provadores ZK-EVM de hoje já funcionam provando sobre implementações do EVM compiladas para RISC-V, e dar aos desenvolvedores de contratos inteligentes acesso direto a esse VM RISC-V.

Alguns números sugerem que, em casos limitados, isso poderia proporcionar ganhos de eficiência superiores a 100x:

Na prática, espero que o tempo restante do provador seja dominado pelo que hoje são precompilados. Se tornarmos o RISC-V o VM primário, então o cronograma de gás refletirá os tempos de prova, e haverá pressão econômica para parar de usar precompilados mais caros; mas ainda assim os ganhos não serão tão impressionantes, mas temos boas razões para acreditar que serão muito significativos.

(Aliás, a divisão aproximada de 50/50 entre "EVM" e "outras coisas" também aparece na execução regular do EVM, e intuitivamente esperamos que os ganhos decorrentes da remoção do EVM como “o intermediário” sejam igualmente grandes)

Detalhes de implementação

Existem várias maneiras de implementar esse tipo de proposta. A menos disruptiva é suportar dois VMs e permitir que contratos sejam escritos em qualquer um deles. Ambos os tipos de contratos teriam acesso aos mesmos tipos de recursos: armazenamento persistente (SLOAD e SSTORE), a capacidade de manter saldos de ETH, a capacidade de fazer e receber chamadas, etc. Contratos EVM e RISC-V seriam livres para chamar um ao outro; do ponto de vista do RISC-V, chamar um contrato EVM pareceria, do seu ponto de vista, estar fazendo uma chamada de sistema com alguns parâmetros especiais; o contrato EVM que recebe a mensagem o interpretaria como sendo um CALL.

Uma abordagem mais radical do ponto de vista do protocolo é converter os contratos EVM existentes em contratos que chamam um contrato de intérprete EVM escrito em RISC-V que executa seu código EVM existente. Ou seja, se um contrato EVM tem o código C, e o intérprete EVM está no endereço X, então o contrato é substituído pela lógica de nível superior que, quando chamada de fora com os parâmetros de chamada D, chama X com (C, D), e depois espera pelo valor de retorno e o encaminha. Se o intérprete EVM em si chama o contrato, pedindo para executar um CALL ou SLOAD/SSTORE, então o contrato faz isso.

Uma rota intermediária é fazer a segunda opção, mas criar um recurso de protocolo explícito para isso - basicamente, consagrar o conceito de um "interpretador de máquina virtual" e exigir que sua lógica seja escrita em RISC-V. O EVM seria o primeiro, mas poderia haver outros (por exemplo, o Move poderia ser um candidato).

Um benefício-chave da segunda e terceira proposta é que elas simplificam enormemente a especificação da camada de execução - de fato, esse tipo de ideia pode ser a única maneira prática de fazer isso, dada a grande dificuldade de simplificações incrementais como a remoção de SELFDESTRUCT. O Tinygrad possui a regra rígida denunca ultrapassando 10000 linhas de código; uma camada de base blockchain ideal deve ser capaz de se encaixar bem dentro dessas margens e ser ainda menor. O esforço da cadeia de feixes promete simplificar enormemente a camada de consenso do Ethereum. Mas para que a camada de execução veja ganhos semelhantes, esse tipo de mudança radical pode ser o único caminho viável.

Isenção de responsabilidade:

1. Este artigo é reproduzido a partir de [Ethereum Magicians]. Todos os direitos autorais pertencem ao autor original [Vitalik Buterin]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe, e eles lidarão com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. A equipe do Gate Learn faz traduções do artigo para outros idiomas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que seja mencionado.