Vitalik radical novo artigo: a expansão da camada de execução "não se quebra, não se estabelece", o EVM deve ser iterado no futuro

Este artigo é de: cofundador do Ethereum Vitalik

Compilação｜Odaily Planet Daily（@OdailyChina）

Tradutor｜Azuma（@azuma_eth）

Neste artigo, vou apresentar uma ideia radical sobre o futuro da camada de execução do Ethereum, cuja grandiosidade é comparável ao plano Beam Chain da camada de consenso. O objetivo deste plano é aumentar significativamente a eficiência da camada de execução do Ethereum, resolvendo um dos principais gargalos de escalabilidade, enquanto também simplifica enormemente a complexidade da camada de execução - na verdade, esta pode ser a única forma de alcançar a simplificação.

O ponto central deste artigo é substituir o EVM pela linguagem de máquina virtual para contratos inteligentes, utilizando RISC-V.

Nota importante:

• Os conceitos de contas, chamadas entre contratos, armazenamento, etc., serão totalmente mantidos. Esses mecanismos abstratos funcionam bem e os desenvolvedores estão acostumados a usá-los. Operações como SLOAD, SSTORE, BALANCE, CALL, etc., se tornarão chamadas de sistema do RISC-V.
• Os desenvolvedores ainda podem escolher Solidity ou Vyper. Embora seja teoricamente possível escrever contratos inteligentes em Rust, espera-se que a maioria dos desenvolvedores continue a usar Solidity (ou Vyper), pois essas linguagens serão adaptadas para RISC-V como alvo de compilação de backend - isso se deve ao fato de que contratos inteligentes escritos em Rust têm uma legibilidade inferior, enquanto Solidity e Vyper são mais fáceis de entender. A experiência de desenvolvimento quase não mudará, e os desenvolvedores podem não sentir diferença alguma.
• Os contratos antigos e novos permitirão a interoperabilidade bidirecional. Os contratos EVM tradicionais continuarão a funcionar e poderão interagir completamente com os novos contratos RISC-V. A forma específica de implementação será detalhada posteriormente.
• Já existem precedentes: A Nervos CKB VM é essencialmente uma implementação baseada em RISC-V.

Por que precisamos dessa transformação?

A curto prazo, o principal gargalo da escalabilidade do Ethereum Layer 1 será resolvido com os próximos EIPs (como listas de acesso a blocos, execução em atraso, armazenamento histórico distribuído e EIP-4444); a médio prazo, resolveremos mais problemas através da ausência de estado e ZK-EVM; mas a longo prazo, os principais fatores que limitarão a escalabilidade do Ethereum Layer 1 se tornarão:

1. Amostragem de disponibilidade de dados e a estabilidade do protocolo de armazenamento histórico;
2. Necessidade de manter a competitividade do mercado de produção de blocos;
3. A capacidade de prova do ZK-EVM.

Este artigo irá argumentar que substituir ZK-EVM por RISC-V pode superar os principais gargalos nos pontos 2 e 3.

Abaixo está a tabela de estatísticas do número de ciclos necessários para provar cada etapa da camada de execução do EVM usando o Succinct ZK-EVM:

Os quatro principais passos que consomem tempo são: "deserialize_inputs" (deserialização de dados), "initialize_witness_db" (inicialização da base de dados de testemunhas), "state_root_computation" (cálculo da raiz de estado) e "block_execution" (execução de bloco).

"A inicialização do banco de dados de testemunhas" e "o cálculo da raiz de estado" estão ambos relacionados com a árvore de estado, enquanto "a desserialização de dados" refere-se ao processo de conversão de blocos e dados de testemunha em uma representação interna. Portanto, na verdade, mais de 50% do tempo está relacionado ao tamanho dos dados de testemunha.

Ao substituir a atual "keccak 16-ary Merkle patricia tree" (árvore Merkle Patricia de 16 caminhos keccak) por uma "binary tree" (árvore binária) que utiliza funções de hash amigáveis à prova, esses passos podem ser significativamente otimizados. Se usarmos o "Poseidon", podemos provar 2 milhões de hashes por segundo em um laptop (em comparação, o keccak é cerca de 15.000 hashes por segundo). Além do "Poseidon", há muitas outras opções disponíveis. De forma geral, há uma oportunidade significativa de reduzir o tempo gasto nesses passos. Além disso, podemos simplificar ainda mais o processo removendo o "accrue_logs_bloom".

Agora só resta a "execução de blocos", que ocupa cerca da metade do atual ciclo de prova. Se quisermos aumentar a eficiência geral da prova em 100 vezes, devemos pelo menos aumentar a eficiência da prova do EVM em 50 vezes. Existem dois caminhos existentes: um é tentar criar uma implementação do EVM mais eficiente para reduzir o ciclo de prova; o outro é permitir que os desenvolvedores utilizem a máquina virtual RISC-V já adotada na camada base do ZK-EVM.

Alguns dados mostram que a melhoria da eficiência em cenários específicos pode ultrapassar 100 vezes:

Na prática, o tempo restante de prova será principalmente consumido pelos contratos pré-compilados (precompiles). Se o RISC-V for definido como a máquina virtual principal, o mecanismo de taxas de gás refletirá o tempo real de prova, e a pressão econômica levará os desenvolvedores a reduzir o uso de pré-compilados de alto custo. Embora os ganhos reais possam não ser tão altos quanto os valores teóricos, a expectativa ainda será muito significativa.

É importante notar que, na execução regular do EVM, também existe uma distribuição de tempo de 50/50 entre o "EVM" e "outros componentes". Acreditamos intuitivamente que a remoção do EVM como "camada intermediária" deve resultar em um aumento de eficiência semelhante.

Método de implementação

Existem várias maneiras de implementar a proposta acima.

O método com o menor impacto destrutivo é suportar duas máquinas virtuais, permitindo que os contratos sejam escritos em qualquer uma das máquinas virtuais. Ambos os tipos de contratos podem acessar as mesmas funcionalidades: armazenamento persistente (SLOAD/SSTORE), gestão de saldo ETH, iniciar e receber chamadas, entre outros. Contratos EVM e RISC-V podem interagir livremente: chamar um contrato EVM do ponto de vista RISC-V será considerado uma chamada de sistema (syscall) com parâmetros especiais, enquanto o contrato EVM que recebe a chamada irá interpretá-la como uma instrução CALL normal.

Uma solução mais agressiva converterá contratos EVM existentes em contratos de interpretador EVM escritos em RISC-V para executar seu código EVM original. Especificamente, suponha que um contrato EVM contenha o código C e que o interpretador EVM esteja localizado no endereço X, então o contrato será substituído pela lógica de nível superior: quando uma chamada externa for iniciada com os parâmetros D, essa lógica enviará um pedido (C, D) para X, aguardará um valor de retorno e o encaminhará. Se o próprio interpretador EVM precisar chamar um contrato para executar operações como CALL, SLOAD ou SSTORE, o contrato responderá diretamente.

A solução de compromisso é, portanto, baseada na segunda proposta, através da camada de protocolo, para apoiar claramente o conceito de "intérprete de máquina virtual" — ou seja, exige que a lógica do intérprete seja escrita em RISC-V. O EVM será o primeiro intérprete oficial, e no futuro poderão ser introduzidos outros tipos (como o intérprete da linguagem Move).

A principal vantagem das segunda e terceira opções reside na simplificação significativa das especificações da camada de execução. Considerando que até mesmo a remoção de elementos como SELFDESTRUCT apresenta muitas dificuldades, tais mudanças podem ser a única maneira realista de alcançar a simplificação. O projeto Tinygrad estipula rigorosamente que a quantidade de código nunca deve exceder 10 mil linhas, a camada base ideal de uma blockchain deve buscar uma redução ainda mais extrema. O plano Beam Chain aponta a direção para a simplificação da camada de consenso do Ethereum, e para que a camada de execução atinja uma quebra semelhante, talvez somente através de tais transformações fundamentais.