Em 2 de março, na primeira Conferência Ecológica Xuantie RISC-V realizada por Ali Pingtou, David Patterson, pai do RISC-V e vencedor do Prêmio Turing, disse com confiança.

Desde a sua introdução até 10 bilhões de processadores, a arquitetura x86 da Intel levou décadas, o ARM levou 17 anos e o RISC-V levou apenas cerca de 10 anos, o que não tem precedentes na história do desenvolvimento da arquitetura de chips.

Alguns dados prevêem que até 2025, o número de processadores que utilizam a arquitectura RISC-V ultrapassará os 80 mil milhões. No campo IoT, prevê-se que 28% do mercado será ocupado por RISC-V até 2025.

Então, o que é RISC-V? (O conteúdo a seguir vem principalmente da série de artigos "O Nascimento do CKB-VM")

Introdução ao RISC-V

RISC-V é uma arquitetura de conjunto de instruções de CPU clara, simples e de código aberto, nascida na Universidade da Califórnia, Berkeley.

Em 2010, devido às limitações de outros conjuntos comerciais de instruções de código fechado, uma equipe de pesquisa da escola projetou um novo conjunto de instruções de código aberto do zero ao iniciar um novo projeto. Este novo conjunto de instruções possui um grande número de registros e velocidade de execução de instruções transparente, o que pode ajudar compiladores e programadores de linguagem assembly a converter problemas práticos e importantes em código apropriado e eficiente e contém menos de 50 instruções.

Este conjunto de instruções é RISC-V, então RISC-V é um conjunto de instruções muito jovem.

Então, quais são os principais conjuntos de instruções antes disso?

Na era do PC, o x86 é o senhor inabalável. O x86 é um CISC (computador com conjunto de instruções complexo), que é diferente do RISC (computador com conjunto de instruções reduzido). O número de conjuntos de instruções CISC continua a aumentar com o desenvolvimento. Isso fará com que os custos continuem a aumentar e o desempenho e o consumo de energia também serão afetados. Além disso, o comprimento do conjunto de instruções CISC e o tempo de execução não são fixos, tornando difícil encontrar um caminho de design universal eficiente para completar a execução das instruções.

Após a popularidade dos smartphones, o ARM se tornou o queridinho do terminal móvel. ARM é um conjunto de instruções reduzido (RISC) com baixo consumo de energia e baixo custo. No entanto, para manter a compatibilidade com versões anteriores, o ARM precisa manter muitas definições desatualizadas, resultando em redundância grave do conjunto de instruções, o que torna a documentação da arquitetura ARM complexa. mais alto e mais alto.

No atual monopólio de x86 e ARM, o RISC-V trouxe uma nova vitalidade ao mercado.

O objetivo do RISC-V é fornecer uma arquitetura comum de conjunto de instruções de CPU para apoiar o desenvolvimento de arquiteturas de sistema de próxima geração sem o fardo de problemas arquitetônicos legados nas próximas décadas.

O RISC-V pode atender aos requisitos de implementação, desde pequenos microprocessadores de baixo consumo de energia até processadores de data center (DC) de alto desempenho. Comparado com outros conjuntos de instruções da CPU, o conjunto de instruções RISC-V tem as seguintes vantagens:

Transparência (código aberto)

ARM e x86 são projetos de código fechado e os termos de licenciamento são extremamente severos: a Intel não permite que nenhuma empresa, exceto AMD e VIA, use o conjunto de instruções x86. A obtenção de uma licença para o conjunto de instruções ARM pode exigir dezenas de milhões de dólares; Serão cobradas taxas de licenciamento e a autorização precisará ser renegociada após o vencimento da autorização.

RISC-V é um verdadeiro projeto de código aberto, conhecido como Linux na área de hardware. Na verdade, a intenção original do Professor David Patterson, Professor Krste Asanovic, Andrew Waterman e Yunsup Lee que inventaram o RISC-V era "Os conjuntos de instruções querem ser livres", e qualquer empresa, universidade, instituição de pesquisa e indivíduo em todo o mundo pode desenvolver processadores compatíveis com RISC com o conjunto de instruções -V pode ser integrado ao ecossistema de software e hardware construído em RISC-V.

RISC-V usa o contrato de código aberto de licença BSD (um dos contratos de licença mais amplamente utilizados em software livre). O contrato de código aberto BSD permite aos usuários modificar e redistribuir código-fonte aberto e também permite o desenvolvimento e venda de software comercial baseado. em código-fonte aberto e pode criar novo software/hardware sem restrições.

simplicidade

Após décadas de desenvolvimento, os documentos de arquitetura x86 e ARM atingiram milhares de páginas, o que leva quase um mês para um engenheiro ler, enquanto a leitura de documentos RISC-V leva apenas 1 a 2 dias.

Isso ocorre porque o RISC-V seleciona apenas os conjuntos de instruções mais comumente usados ​​e os otimiza especificamente. Quanto às instruções incomuns, elas podem ser concluídas combinando várias instruções básicas, o que pode melhorar bastante a eficiência. Portanto, com a premissa de fornecer as mesmas funções, o conjunto de instruções RISC-V é mais fácil de implementar e pode evitar bugs do que o conjunto de instruções x86 com milhares de instruções.

Por exemplo, se estivermos usando x86, teremos que comprar um supermercado inteiro para aproveitar os itens que precisamos, mas o RISC-V é um supermercado onde você pode comprar itens individualmente e os clientes só precisam escolher os itens que precisam; apenas pague por isso.

Modular

RISC-V usa um núcleo simplificado e um mecanismo modular para fornecer configurações de conjunto de instruções mais estendidas.

amplitude de suporte

Compiladores como GCC e LLVM suportam o conjunto de instruções RISC-V, e o backend de Go para RISC-V também está em desenvolvimento.

maturidade

O conjunto de instruções principais do RISC-V foi finalmente confirmado e corrigido, e todas as implementações futuras do RISC-V precisam ser compatíveis com versões anteriores. Além disso, o conjunto de instruções RISC-V foi implementado em hardware e verificado em cenários de aplicação reais, e não há riscos potenciais em outros conjuntos de instruções com menos suporte.

Quando CKB-VM encontra RISC-V

CKB é a camada básica da Rede Nervos e seu objetivo é fornecer segurança e descentralização suficientes para aplicações de camada superior. No processo de pesquisa e seleção do CKB-VM, pensamos repetidamente sobre: ​​Quais recursos o CKB-VM deve ter?

Obviamente, para que uma máquina virtual seja usada em um blockchain, existem duas características principais que devem ser atendidas em qualquer caso:

1. Determinismo: Para programas e entradas fixas, a máquina virtual deve sempre retornar resultados de saída fixos, e os resultados não serão alterados devido ao tempo, ambiente operacional e outras condições externas;

2. Segurança: A execução de uma máquina virtual não afetará o funcionamento da plataforma em si.

Mas essas condições são apenas obrigatórias e esperamos projetar uma máquina virtual que possa atender melhor aos objetivos do CKB. Após consideração cuidadosa, acreditamos que tal máquina virtual deve atender às seguintes características:

flexibilidade

Nosso objetivo é projetar uma máquina virtual que seja flexível o suficiente para operar por um longo tempo, para que o CKB possa acompanhar o desenvolvimento da criptografia. A história da criptografia é uma batalha eterna entre “empunhar a espada” e “quebrar a parede”: na história do desenvolvimento da criptografia durante milhares de anos, a criptografia e a descriptografia são uma competição intelectual sem fim. será o mesmo no futuro. Alguns algoritmos de criptografia adequados para hoje, como secp256k1, podem se tornar obsoletos no futuro; novos algoritmos e tecnologias mais valiosos (como Schnorr ou assinaturas pós-quânticas, etc.) continuarão a surgir no futuro; Os programas executados na máquina virtual do blockchain devem ser capazes de usar novos algoritmos de forma mais livre e conveniente e, ao mesmo tempo, esses algoritmos desatualizados devem ser naturalmente eliminados.

Para facilitar o entendimento, utilizamos o Bitcoin como exemplo. Atualmente, o Bitcoin usa SIGHASH para assinaturas de transações e usa o algoritmo de hash SHA-256 no protocolo de consenso. Então, podemos garantir que esta abordagem SIGHASH usada pelo Bitcoin ainda será a melhor escolha dentro de alguns anos? Ou, com o aumento do poder de computação, o SHA-256 ainda é adequado como um algoritmo de hash estável? Para todos os protocolos blockchain que estamos estudando atualmente, se o algoritmo de criptografia precisar ser atualizado, um hard fork será inevitavelmente necessário. Ao projetar o CKB, queríamos explorar como reduzir a possibilidade de hard forks por meio do design da VM.

Estamos pensando: a máquina virtual pode permitir a atualização do algoritmo de criptografia? Ou é possível adicionar nova lógica de validação de transação à VM? Por exemplo, embora ainda usemos secp256k1, se houver incentivos econômicos ou necessidade de atualizar o algoritmo, podemos implementar um algoritmo de verificação de assinatura mais eficiente sem bifurcação? Ou, se alguém encontrar uma maneira de implementar um algoritmo melhor no CKB, ou precisar introduzir um novo algoritmo de criptografia, podemos garantir que ele poderá implementá-lo livremente?

Esperamos que o CKB-VM possa fornecer a todos mais espaço de implementação, maximizar a flexibilidade e permitir que os usuários usem novos algoritmos de criptografia sem esperar por hard forks.

transparência operacional

Depois de pesquisar a geração atual de VMs blockchain, percebemos um problema, ainda tomando o Bitcoin como exemplo: a camada VM do Bitcoin fornece apenas uma pilha, e a pilha não pode saber o que pode ser armazenado na pilha durante a execução. , é o mesmo problema para todas as outras VMs implementadas no modo de pilha, embora a camada de consenso possa fornecer uma definição de profundidade de pilha ou fornecer profundidade de pilha indiretamente (com base no comprimento da instrução ou limites de gás). Isso forçará os desenvolvedores de programas na VM a adivinhar o estado do programa quando ele estiver em execução. Esse tipo de VM impede que o programa utilize todo o potencial da VM.

Com base neste problema, acreditamos que deveria ser uma prioridade definir os limites de todos os recursos durante a operação da VM, incluindo limites de gás e tamanho do espaço de pilha, e permitir que programas em execução na VM consultem o uso de recursos. a VM para algoritmos diferentes são empregados com base na disponibilidade de recursos. Com esse design, os programas podem explorar todo o potencial da VM. E nos seguintes cenários, podemos ver mais flexibilidade da VM:

1. Você pode escolher diferentes estratégias para contratos inteligentes que armazenam dados com base no espaço de armazenamento (capacidade da célula) disponível para usuários no CKB. Quando a capacidade da célula é suficiente, o programa pode armazenar dados diretamente para reduzir o número de ciclos da CPU usados ​​(as etapas que a CPU executa para executar uma instrução de máquina quando a capacidade da célula é limitada, o programa pode compactar os dados para se adaptar); para a capacidade menor e usa mais muitos ciclos de CPU.

2. Diferentes mecanismos de processamento podem ser selecionados para o contrato inteligente com base na quantidade total de dados (Cell Data) armazenados pelo usuário e no tamanho da memória restante. Quando há uma pequena quantidade de dados da célula ou uma grande quantidade de memória restante, todos os dados da célula podem ser lidos na memória para processamento. Quando há uma grande quantidade de dados da célula ou pouca memória restante, cada operação pode ler apenas parte da memória, semelhante à operação de troca de memória.

3. Para alguns contratos comuns, como algoritmos hash, diferentes métodos de processamento podem ser selecionados com base no número de ciclos de CPU fornecidos pelo usuário. Por exemplo, a segurança do SHA3-256 é suficiente para atender às necessidades da maioria dos cenários; no entanto, o contrato pode utilizar o algoritmo SHA3-512 para atender a requisitos de segurança mais elevados usando mais ciclos de CPU.

Sobrecarga de tempo de execução

O mecanismo Gas na Máquina Virtual Ethereum (EVM) é um design muito genial. Ele resolve elegantemente o problema de desligamento em cenários de aplicativos blockchain (como Ethereum é Turing completo, instruções de loop são permitidas, mas instruções de loops infinitos podem facilmente causar problemas de desligamento. O mecanismo de gás limita a quantidade máxima de cálculo de um bloco, evitando assim este problema) e permitindo que o programa realize cálculos em uma máquina virtual totalmente descentralizada. No entanto, descobrimos que é muito difícil projetar um método de cálculo de gás razoável para diferentes Opcodes (operadores) no EVM e é necessário ajustar o mecanismo de cálculo de gás quase sempre que ele é atualizado (o nível de abstração do EVM é relativamente maior, um). A instrução EVM pode corresponder a várias instruções de hardware subjacentes. Ao executar o programa, a quantidade de dados processados ​​e a complexidade computacional só podem ser precificadas por meio de estimativa, portanto, o EVM precisa ajustar continuamente o mecanismo de cálculo do Gás.

Portanto, nos perguntamos: o design da VM pode ser usado para garantir que o método de cálculo do consumo de recursos durante a execução do programa seja mais razoável e preciso?

Esperávamos encontrar um design de VM que fornecesse todos os recursos acima, mas descobrimos que não havia nenhuma solução pronta para uso que pudesse concretizar nossa visão para o CKB. Portanto, decidimos redesenhar uma VM que pudesse atender a todas as características acima para melhor concretizar a visão do CKB.

Embora outros conjuntos de instruções possam compartilhar alguns desses recursos, em nossa avaliação, o conjunto de instruções RISC-V é o único que possui todos eles.

Portanto, optamos por implementar o CKB-VM usando o conjunto de instruções RISC-V.

Leitura recomendada:

1. Depois de esperar e observar, testar o terreno e cair em armadilhas, o RISC-V está no trampolim para entrar na era de ouro.

2. O RISC-V realmente se tornou uma realidade e a velocidade está um pouco além da imaginação.

3. Quando CKB-VM encontra RISC-V —— O nascimento de CKB-VM

https://talk.nervos.org/t/ckb-vm-risc-v-ckb-vm/1667

4. O nascimento do CKB-VM, uma máquina virtual blockchain baseada em RISC-V (1)

https://talk.nervos.org/t/risc-v-ckb-vm/1726

5. Inspiração, design e vantagens – o nascimento do CKB-VM (2)

https://talk.nervos.org/t/ckb-vm/1730

6. Como jogar feliz no CKB-VM - O nascimento do CKB-VM (3)

https://talk.nervos.org/t/ckb-vm-ckb-vm/1765

7. A questão central de Zaki Manian: Máquina virtual Blockchain, qual é mais adequada, WASM ou RISC-V?

https://talk.nervos.org/t/zaki-manian-wasm-risc-v/463