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

Este artigo é de: compilação levochka.eth do desenvolvedor Ethereum

|Odaily Planet Daily (@OdailyChina); @azuma_eth Nota do editor

:

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

Assim que este artigo foi publicado, 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. Logo após a publicação do artigo, 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 pode não ser a melhor escolha porque não conseguiu equilibrar "escalabilidade" e "capacidade de manutenção".

O seguinte é o artigo original em 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 suposições erradas sobre a prova do sistema e seu desempenho.

Hipótese de validação

Pelo que entendi, os principais argumentos para este esquema são "escalabilidade" e "capacidade de manutenção".

Primeiro, quero falar sobre manutenção.

Na verdade, todas as zk-VMs RISC-V exigem "pré-compilações" para lidar com operações com uso intensivo de computação. A lista pré-compilada do SP 1 pode ser encontrada na documentação do Succinct, e você descobrirá que ela 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 gravados 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 realizar a capacidade de manutenção da parte "não EVM" do cliente. Não tenho certeza se é bom o suficiente, mas estou menos confiante nesta parte pelos seguintes motivos: a

• "computação da árvore de estados" pode realmente ser bastante acelerada com uma pré-compilação amigável 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.

Portanto, 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 nos detalhes mais sutis, mas as vantagens vêm pelo menos em parte:

• a diferença entre Interpretação e 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/memória de controle devido à sobrecarga de interpretação);

• usar tipos de dados menores;

Aqui, gostaria de salientar que, para obter os benefícios do ponto 1 e do ponto 2, a "sobrecarga de interpretação" deve ser eliminada. 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 certos recursos adicionais, como suporte para conceitos de contrato.

Aí vem o problema

, então, existem alguns problemas aqui.

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

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

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

Como alternativa,

podemos compilar o bytecode a partir do opcode EVM de alto nível. O compilador é responsável por garantir que o construtor permaneça invariável, 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 prova que alguns invariantes são preservados. Pelo que eu posso dizer, essa abordagem (não "virtualização") tem sido usada em alguns contextos de navegador. Ao gerar SNARKs dessa prova formal, você pode obter resultados semelhantes. 

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

Construindo uma MMU "encadeada" mínima

, que você pode expressar implicitamente no artigo, mas deixe-me avisar que, se você quiser eliminar a sobrecarga de virtualização, precisará executar o código compilado diretamente - o que significa que você precisa de alguma forma impedir que o contrato (agora executável) seja gravado na memória do kernel (não em uma implementaçã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ísico" é quase infinito. Essa MMU deve ser o mais enxuta possível (porque está no mesmo nível de abstração que a própria arquitetura), mas alguns recursos, como atomicidade das transações, podem ser movidos para essa camada.

Neste ponto, o EVM comprovável torna-se o programa do 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 essa tarefa pode não ser RISC-V, mas algo semelhante ao EOF-EVM pelos seguintes motivos:

• Opcodes "pequenos" realmente resultam em muito acesso à memória, o que é difícil para os métodos de atestado existentes lidarem com eficiência.

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

Minha sugestão é construir uma nova arquitetura amigável à prova com um MMU mínimo que permita que o contrato seja executado como um executável separado. Não acho que deva ser RISC-V, mas sim um novo ISA otimizado para as 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, gostemos ou não, então o RISC-V não traz nenhuma simplificação aqui.