Os desenvolvedores refutam Vitalik: as suposições estão erradas, e RISC-V não é a melhor escolha

Este artigo é de: Desenvolvedor Ethereum levochka.eth

Compilado por Odaily (@OdailyChina); Tradutor: Azuma(@azuma_eth).

Nota do editor:

Ontem, o cofundador do Ethereum Vitalik lançou um artigo radical sobre a atualização da camada de execução do Ethereum (veja "Vitalik's Radical New Article: Execution Layer Scaling "Doesn't Break, Stand", EVM Must Be Iterated in the Future), mencionando que ele quer substituir EVM por RISC-V como uma linguagem de máquina virtual para contratos inteligentes.

Assim que este artigo saiu, ele imediatamente causou um alvoroço na comunidade de desenvolvedores do Ethereum, e muitos figurões técnicos expressaram opiniões diferentes sobre o plano. Pouco depois que o artigo foi publicado, o desenvolvedor do Ethereum Tier-1 levochka.eth escreveu um longo artigo abaixo do artigo original refutando o argumento de Vitalik de que Vitalik havia feito suposições erradas sobre o sistema de prova e seu desempenho, e que o RISC-V poderia não ser a melhor escolha porque não poderia equilibrar "escalabilidade" e "manutenção".

Segue-se o artigo original sobre levochka.eth, compilado pelo jornal diário Odaily.

Por favor, não faça isso.

Este plano não faz sentido, porque você está fazendo as suposições erradas sobre provar o sistema e seu desempenho.

Validar hipóteses

No meu entender, os principais argumentos para esta abordagem são a "escalabilidade" e a "manutenabilidade".

Primeiro, quero falar sobre a manutenção.

Na verdade, todas as RISC-V zk-VMs requerem "pré-compilações" para lidar com operações de computação intensiva. A lista pré-compilada do SP 1 pode ser encontrada na documentação do Succinct, e você descobrirá que ele cobre quase todos os opcodes "computacionais" importantes no EVM.

Como resultado, todas as modificações nas primitivas criptográficas da camada base exigem que novos "circuitos" sejam escritos e auditados para essas pré-compilações, o que é uma limitação séria.

De fato, se o desempenho for bom o suficiente, pode ser relativamente fácil executar a facilidade de manutenção da parte "não-EVM" do cliente. Não tenho certeza se vai ser bom o suficiente, mas estou menos confiante nesta parte pelos seguintes motivos:

• A "computação da árvore de estado" pode realmente ser muito acelerada com pré-compilações amigáveis como Poseidon.

• No entanto, não está claro se a "desserialização" pode ser tratada de maneira elegante e sustentável.
  

• Além disso, existem alguns detalhes complicados (como medição de gás e várias verificações) que podem se enquadrar no "tempo de avaliação do bloco", mas na verdade devem ser classificados como peças "não-EVM", que tendem a ser mais vulneráveis à pressão de manutenção.

Em segundo lugar, a parte sobre escalabilidade.

Preciso reiterar que é impossível para o RISC-V lidar com cargas EVM sem usar pré-compilação, absolutamente não.

Assim, a afirmação no texto original de que "o tempo de prova final será dominado pela operação de pré-compilação atual" é tecnicamente correta, mas é excessivamente otimista - pressupõe que não haverá pré-compilação no futuro, quando na verdade (neste cenário futuro) a pré-compilação ainda existirá, e é exatamente o mesmo que os opcodes computacionalmente intensivos no EVM (como assinaturas, hashes e possivelmente grandes análogos).

É difícil julgar o exemplo de Fibonacci sem entrar em detalhes de nível muito baixo, mas as vantagens vêm pelo menos em parte de:

• a diferença entre a interpretação e a sobrecarga de execução;

• Desenrolamento cíclico (reduzindo o "fluxo de controle" do RISC-V, é incerto se o Solidity pode ser implementado, mas mesmo um único opcode ainda pode gerar um grande número de acessos de fluxo de controle/memória devido à sobrecarga de interpretação);

• utilizar tipos de dados mais pequenos;

A este respeito, gostaria de salientar que, para concretizar os benefícios do ponto 1 e do ponto 2, é necessário eliminar a "sobrecarga de interpretação". Isso está de acordo com a filosofia do RISC-V, mas este não é o RISC-V que estamos discutindo atualmente, mas sim um "(?)RISC-V" semelhante - requer certas capacidades adicionais, como suporte para conceitos de contrato.

Aqui está o problema

Portanto, há alguns problemas aqui.

• Para melhorar a capacidade de manutenção, você precisa de um RISC-V (com pré-compilação) que compile o EVM - é praticamente isso.

• Para melhorar a escalabilidade, algo completamente diferente é necessário – uma nova arquitetura que pode ser semelhante ao RISC-V que entende o conceito de "contratos", é compatível com as limitações de tempo de execução do Ethereum e pode executar o código do contrato diretamente (sem a "sobrecarga de interpretação").

Agora estou supondo que você esteja se referindo ao segundo caso (já que o resto do artigo parece sugerir isso). Preciso chamar sua atenção para o fato de que todo o código fora deste ambiente ainda será escrito na linguagem RISC-V zkVM atual, o que tem um impacto significativo na manutenção.

Outras possibilidades

Podemos compilar o bytecode a partir do opcode EVM de alto nível. O compilador é responsável por garantir que o construtor permaneça invariante, como não experimentar um "estouro de pilha". Eu gostaria de ver isso mostrado em um EVM normal. SNARKs compilados corretamente podem ser fornecidos com instruções de implantação de contrato.

Também podemos construir uma "prova formal" que prove que alguns invariantes são preservados. Tanto quanto eu posso dizer, essa abordagem (não "virtualização") tem sido usada em alguns contextos de navegador. Ao gerar SNARKs desta prova formal, você pode alcançar resultados semelhantes.

Claro, a opção mais fácil é morder a bala e fazer ......

Crie uma MMU "encadeada" mínima

Você pode estar expressando isso implicitamente em seu artigo, mas deixe-me avisar que, se você quiser eliminar a sobrecarga de virtualização, terá que executar o código compilado diretamente — o que significa que você precisa de alguma forma impedir que o contrato (agora executável) escreva na memória do kernel (implementação não-EVM).

Portanto, precisamos de algum tipo de "unidade de gerenciamento de memória" (MMU). O mecanismo de paginação dos computadores tradicionais pode não ser necessário porque o espaço de memória "física" é quase infinito. Esta MMU deve ser o mais enxuta possível (porque está no mesmo nível de abstração que a própria arquitetura), mas algumas características, como a atomicidade das transações, podem ser movidas para essa camada.

Neste ponto, o EVM demonstrável torna-se o programa kernel em execução nesta arquitetura.

RISC-V pode não ser a melhor opção

Curiosamente, em todas essas condições, a melhor "arquitetura de conjunto de instruções" (ISA) para esta tarefa pode não ser RISC-V, mas algo semelhante ao EOF-EVM em algum lugar:

• Opcodes "pequenos" realmente levam a um grande número de acessos à memória, que são difíceis de lidar eficientemente com os métodos de prova existentes.

• Para reduzir a sobrecarga de ramificação, mostramos como provar o código de "saltos estáticos" (EOF) com desempenho de nível pré-compilação em nosso artigo recente, Morgana.

Minha sugestão é construir uma nova arquitetura de prova amigável com um MMU mínimo que permita que o contrato seja executado como um executável separado. Eu não acho que deveria ser RISC-V, mas sim um novo ISA otimizado para limitações do protocolo SNARK, e até mesmo um ISA que herda parcialmente um subconjunto de opcodes EVM pode ser melhor - como sabemos, a pré-compilação veio para ficar, quer queiramos ou não, então o RISC-V não traz nenhuma simplificação aqui.