Esta publicação 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.

Clarificações importantes:

• Os conceitos de contas, chamadas entre contratos, armazenamento, etc., permaneceriam exatamente iguais. Essas abstrações funcionam bem e os desenvolvedores estão habituados a elas. Opcodes como SLOAD, SSTORE, BALANCE, CALL, etc., tornar-se-iam chamadas ao sistema RISC-V.
• Nesse 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 adaptariam para adicionar RISC-V como um backend. Isso ocorre porque os contratos inteligentes escritos em Rust são na verdadebastantefeio, e Solidity e Vyper são muitomaislegível. Potencialmente, o devex mudaria muito pouco e os desenvolvedores poderiam mal notar a mudança.
• Os contratos EVM no estilo antigo continuarão a funcionar e serão totalmente interoperáveis bidirecionalmente com os contratos RISC-V no estilo novo. Existem algumas maneiras de fazer isso, nas quais entrarei mais tarde neste post.

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

Por que fazer isso?

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

1. Estabilidade dos protocolos de amostragem de disponibilidade de dados e armazenamento de histórico
2. Desejo de manter a produção de blocos um mercado competitivo
3. Capacidades de prova 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 SC ZK-EVM usa para provar diferentes partes da camada de execução do EVM:

Há 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 ambos a ver com a árvore de estado, e deserialize_inputs refere-se ao processo de conversão de dados de bloco e testemunha numa representação interna; assim, realisticamente mais de 50% disso é proporcional aos tamanhos das testemunhas.

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

Isto deixa a execução de blocos, que representa aproximadamente metade dos ciclos do provador gastos hoje. Se quisermos aumentar a eficiência total do provador em 100 vezes, não há como contornar o facto de que precisamos de pelo menos 50 vezes mais eficiência do provador EVM. Uma coisa que poderíamos fazer é tentar criar implementações do EVM que sejam 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 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 pré-compilações. 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 pré-compilações mais caras; mas mesmo assim os ganhos não serão tão impressionantes, mas temos boas razões para acreditar que serão muito significativos.

(A propósito, 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 de remover EVM como “o intermediário” sejam igualmente grandes)

Detalhes de implementação

Existem várias maneiras de implementar este 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 facilidades: 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 estar a fazer uma chamada de sistema com alguns parâmetros especiais; o contrato EVM que recebe a mensagem 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 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 reside no endereço X, então o contrato é substituído por lógica de nível superior que, quando chamada de fora com parâmetros de chamada D, chama X com (C, D) e depois aguarda o valor de retorno e o encaminha. Se o próprio intérprete EVM chamar o contrato, pedindo para executar uma CALL ou SLOAD/SSTORE, então o contrato o faz.

Uma rota intermédia é fazer a segunda opção, mas criar uma funcionalidade de protocolo explícita para ela - basicamente, consagrar o conceito de um 'interpretador de máquina virtual' e exigir que sua lógica seja escrita em RISC-V. A EVM seria a primeira, mas poderia haver outras (por exemplo, Move poderia ser um candidato).

Um benefício-chave da segunda e terceira proposta é que 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 até mesmo de simplificações incrementais como a remoção de SELFDESTRUCT. Tinygrad tem a regra rígida de nunca ultrapassando as 10000 linhas de código; uma camada base de blockchain ótima deve ser capaz de se encaixar bem dentro dessas margens e até mesmo 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.

Aviso legal:

1. Este artigo é reimpresso de [ Magos do Ethereum]. Todos os direitos de autor pertencem ao autor original [Vitalik Buterin]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipa e eles tratarão disso prontamente.
2. Responsabilidade de Isenção: As opiniões expressas neste artigo são exclusivamente as do autor e não constituem qualquer conselho de investimento.
3. A equipa da Gate Learn faz traduções do artigo para outras línguas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que mencionado.