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:
Amostragem de disponibilidade de dados e a estabilidade do protocolo de armazenamento histórico;
Necessidade de manter a competitividade do mercado de produção de blocos;
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.
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
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:
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:
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.