Le 2 mars, lors de la première conférence écologique Xuantie RISC-V organisée par Ali Pingtou, David Patterson, le père de RISC-V et lauréat du prix Turing, a déclaré avec confiance.

Depuis son introduction sur 10 milliards de processeurs, l'architecture x86 d'Intel a pris des décennies, ARM 17 ans et RISC-V seulement 10 ans environ, ce qui est sans précédent dans l'histoire du développement de l'architecture des puces.

Certaines données prédisent que le nombre de processeurs utilisant l'architecture RISC-V dépassera les milliards 80 d'ici 2025. Dans le domaine de l'IoT, on prévoit que 28 % du marché sera occupé par RISC-V d'ici 2025.

Alors, qu’est-ce que RISC-V ? (Le contenu suivant provient principalement de la série d'articles "La naissance de CKB-VM")

Introduction à RISC-V

RISC-V est une architecture de jeu d'instructions CPU claire, simple et open source, née à l'Université de Californie à Berkeley.

En 2010, en raison des limites d'autres ensembles d'instructions commerciaux à source fermée, une équipe de recherche de l'école a conçu un nouvel ensemble d'instructions open source à partir de zéro lors du démarrage d'un nouveau projet. Ce nouveau jeu d'instructions possède un grand nombre de registres et une vitesse d'exécution transparente des instructions, ce qui peut aider les compilateurs et les programmeurs en langage assembleur à convertir des problèmes pratiques et importants en code approprié et efficace, et contient moins de 50 instructions.

Ce jeu d'instructions est RISC-V, donc RISC-V est un très jeune jeu d'instructions.

Alors, quels sont les principaux jeux d’instructions avant cela ?

À l'ère du PC, x86 est le seigneur inébranlable. x86 est un CISC (Complex Instruction Set Computer), qui est différent du RISC (Reduced Instruction Set Computer). Le nombre de jeux d'instructions CISC continue d'augmenter avec le développement. Cela entraînera une augmentation continue des coûts, et les performances et la consommation d'énergie seront également affectées. De plus, la longueur du jeu d'instructions CISC et le temps d'exécution ne sont pas fixes, ce qui rend difficile la recherche d'un chemin de conception universel efficace pour terminer l'exécution des instructions.

Après la popularité des smartphones, ARM est devenu le chouchou du terminal mobile. ARM est un jeu d'instructions réduit (RISC) avec une faible consommation d'énergie et un faible coût. Cependant, pour maintenir la compatibilité descendante, ARM doit conserver de nombreuses définitions obsolètes, ce qui entraîne une redondance importante des jeux d'instructions, ce qui rend la documentation de l'architecture ARM complexe. de plus en plus haut.

Dans le monopole actuel du x86 et d'ARM, RISC-V a apporté une nouvelle vitalité au marché.

L'objectif de RISC-V est de fournir une architecture de jeu d'instructions CPU commune pour prendre en charge le développement d'architectures système de nouvelle génération sans le fardeau des problèmes architecturaux hérités pour les décennies à venir.

RISC-V peut répondre aux exigences de mise en œuvre, depuis les petits microprocesseurs basse consommation jusqu'aux processeurs de centre de données (DC) hautes performances. Par rapport aux autres jeux d'instructions CPU, le jeu d'instructions RISC-V présente les avantages suivants :

Transparence (open source)

ARM et x86 sont tous deux des projets fermés et les conditions de licence sont extrêmement strictes : Intel n'autorise aucune entreprise, à l'exception d'AMD et VIA, à utiliser le jeu d'instructions x86 ; l'obtention d'une licence pour le jeu d'instructions ARM peut nécessiter des dizaines de millions de dollars ; Des frais de licence seront facturés et l’autorisation devra être renégociée après son expiration.

RISC-V est un véritable projet open source, connu sous le nom de Linux dans le domaine du matériel. En fait, l'intention initiale des professeurs David Patterson, Krste Asanovic, Andrew Waterman et Yunsup Lee, qui ont inventé RISC-V, était de « les ensembles d'instructions veulent être libres », et toute entreprise, université, établissement de recherche et individu dans le monde peut le faire. développer des processeurs compatibles RISC avec le jeu d'instructions -V peut être intégré à l'écosystème logiciel et matériel construit sur RISC-V.

RISC-V utilise l'accord open source de licence BSD (l'un des accords de licence les plus utilisés dans les logiciels libres). L'accord open source BSD permet aux utilisateurs de modifier et de redistribuer du code open source, et permet également le développement et la vente de logiciels commerciaux basés sur sur le code open source et peut créer de nouveaux logiciels/matériels sans restrictions.

simplicité

Après des décennies de développement, les documents d'architecture de x86 et d'ARM ont atteint des milliers de pages, ce qui prend presque un mois à un ingénieur pour les lire, alors que la lecture des documents RISC-V ne prend que 1 à 2 jours.

En effet, RISC-V sélectionne uniquement les jeux d'instructions les plus couramment utilisés et les optimise ensuite spécifiquement. Quant aux instructions peu courantes, elles peuvent être complétées en combinant plusieurs instructions de base, ce qui peut grandement améliorer l'efficacité. Par conséquent, dans la mesure où il fournit les mêmes fonctions, le jeu d'instructions RISC-V est plus facile à mettre en œuvre et peut éviter les bogues que le jeu d'instructions x86 avec des milliers d'instructions.

Par exemple, si nous utilisons x86, nous devons acheter un supermarché entier pour profiter des articles dont nous avons besoin ; mais RISC-V est un supermarché où vous pouvez acheter des articles individuellement, et les clients n'ont qu'à choisir les articles dont ils ont besoin. il suffit de payer pour cela.

Modulaire

RISC-V utilise un noyau simplifié et utilise un mécanisme modulaire pour fournir des paramètres de jeu d'instructions plus étendus.

étendue du soutien

Les compilateurs tels que GCC et LLVM prennent en charge le jeu d'instructions RISC-V, et le backend de Go pour RISC-V est également en cours de développement.

maturité

Le jeu d'instructions de base de RISC-V a finalement été confirmé et corrigé, et toutes les futures implémentations de RISC-V doivent être rétrocompatibles. De plus, le jeu d'instructions RISC-V a été implémenté dans le matériel et a été vérifié dans des scénarios d'application réels, et il n'existe aucun risque potentiel qui existe dans d'autres jeux d'instructions avec moins de prise en charge.

Quand CKB-VM rencontre RISC-V

CKB est la couche de base du réseau Nervos et son objectif est de fournir une sécurité et une décentralisation suffisantes pour les applications de couche supérieure. Au cours du processus de recherche et de sélection de CKB-VM, nous avons réfléchi à plusieurs reprises : quelles fonctionnalités CKB-VM devrait-il avoir ?

Évidemment, pour qu’une machine virtuelle puisse être utilisée sur une blockchain, il y a deux caractéristiques clés qui doivent dans tous les cas être remplies :

1. Déterminisme : pour les programmes et les entrées fixes, la machine virtuelle doit toujours renvoyer des résultats de sortie fixes, et les résultats ne changeront pas en raison du temps, de l'environnement d'exploitation et d'autres conditions externes ;

2. Sécurité : L'exécution d'une machine virtuelle n'affectera pas le fonctionnement de la plateforme elle-même.

Mais ces conditions ne sont que obligatoires, et nous espérons concevoir une machine virtuelle qui pourra mieux servir les objectifs de CKB. Après mûre réflexion, nous pensons qu’une telle machine virtuelle devrait répondre aux caractéristiques suivantes :

la flexibilité

Notre objectif est de concevoir une machine virtuelle suffisamment flexible pour fonctionner longtemps afin que CKB puisse suivre le développement de la cryptographie. L'histoire de la cryptographie est une bataille éternelle entre « tenir l'épée » et « briser le mur » : dans l'histoire du développement de la cryptographie depuis des milliers d'années, le cryptage et le décryptage sont une compétition intellectuelle sans fin. Cela a été le cas dans le passé et. ce sera la même chose à l’avenir. Certains algorithmes de chiffrement adaptés aujourd’hui, comme secp256k1, pourraient devenir obsolètes à l’avenir ; de nouveaux algorithmes et technologies plus précieux (tels que Schnorr ou les signatures post-quantiques, etc.) continueront d’émerger à l’avenir. Les programmes exécutés sur la machine virtuelle de la blockchain devraient pouvoir utiliser de nouveaux algorithmes plus librement et plus facilement, et en même temps, ces algorithmes obsolètes devraient être naturellement éliminés.

Pour faciliter la compréhension, nous utilisons Bitcoin comme exemple. Actuellement, Bitcoin utilise SIGHASH pour les signatures de transactions et utilise l'algorithme de hachage SHA-256 dans le protocole de consensus. Alors peut-on garantir que cette approche SIGHASH utilisée par Bitcoin sera toujours le meilleur choix dans quelques années ? Ou, avec une puissance de calcul croissante, SHA-256 est-il toujours adapté comme algorithme de hachage stable ? Pour tous les protocoles blockchain que nous étudions actuellement, si l’algorithme de chiffrement doit être amélioré, un hard fork sera inévitablement nécessaire. Lors de la conception de CKB, nous voulions explorer comment réduire la possibilité de hard forks grâce à la conception de la VM.

Nous nous demandons si la machine virtuelle peut permettre de mettre à niveau l'algorithme de cryptage ? Ou est-il possible d'ajouter une nouvelle logique de validation de transaction à la VM ? Par exemple, tout en utilisant secp256k1, s’il existe des incitations économiques ou un besoin de mettre à jour l’algorithme, pouvons-nous implémenter un algorithme de vérification de signature plus efficace sans bifurquer ? Ou, si quelqu'un trouve un moyen d'implémenter un meilleur algorithme sur CKB, ou doit introduire un nouvel algorithme de cryptage, pouvons-nous garantir qu'il peut l'implémenter librement ?

Nous espérons que CKB-VM pourra offrir à chacun plus d'espace de mise en œuvre, maximiser la flexibilité et permettre aux utilisateurs d'utiliser de nouveaux algorithmes de chiffrement sans attendre les hard forks.

transparence opérationnelle

Après avoir étudié la génération actuelle de VM blockchain, nous avons remarqué un problème, en prenant toujours Bitcoin comme exemple : la couche VM de Bitcoin ne fournit qu'une pile, et la pile ne peut pas savoir ce qui peut être stocké sur la pile lors de l'exécution, ni la taille des données, ni la profondeur de la pile. , le problème est le même pour toutes les autres machines virtuelles implémentées en mode pile, bien que la couche consensus puisse fournir une définition de la profondeur de la pile ou fournir une profondeur de pile indirectement (en fonction de la longueur des instructions ou des limites de gaz). Cela obligera les développeurs de programmes sur la VM à deviner l'état du programme lorsqu'il est en cours d'exécution. Ce type de VM empêche le programme d'utiliser pleinement le potentiel de la VM.

Sur la base de ce problème, nous pensons qu'il devrait être prioritaire de définir les limites de toutes les ressources pendant le fonctionnement de la VM, y compris les limites de gaz et la taille de l'espace de pile, et de permettre aux programmes exécutés sur la VM d'interroger l'utilisation des ressources. Cela permettra aux programmes exécutés sur la VM d'interroger l'utilisation des ressources. la VM vers Différents algorithmes sont utilisés en fonction de la disponibilité des ressources. Avec cette conception, les programmes peuvent exploiter tout le potentiel de la VM. Et dans les scénarios suivants, nous pouvons constater plus de flexibilité de la VM :

1. Vous pouvez choisir différentes stratégies pour les contrats intelligents qui stockent les données en fonction de l'espace de stockage (capacité cellulaire) disponible pour les utilisateurs sur CKB. Lorsque la capacité de la cellule est suffisante, le programme peut stocker directement les données pour réduire le nombre de cycles CPU utilisés (les étapes que le CPU prend pour exécuter une instruction machine) ; lorsque la capacité de la cellule est limitée, le programme peut compresser les données pour s'adapter ; à une capacité plus petite et utilise plus de cycles CPU.

2. Différents mécanismes de traitement peuvent être sélectionnés pour le contrat intelligent en fonction de la quantité totale de données (Cell Data) stockées par l'utilisateur et de la taille de la mémoire restante. Lorsqu'il reste une petite quantité de données cellulaires ou une grande quantité de mémoire restante, toutes les données cellulaires peuvent être lues en mémoire pour être traitées. Lorsqu'il y a une grande quantité de données de cellule ou peu de mémoire restante, chaque opération ne peut lire qu'une partie de la mémoire, similaire à l'opération d'échange de mémoire.

3. Pour certains contrats courants, tels que les algorithmes de hachage, différentes méthodes de traitement peuvent être sélectionnées en fonction du nombre de cycles CPU fournis par l'utilisateur. Par exemple, la sécurité de SHA3-256 est suffisante pour répondre aux besoins de la plupart des scénarios. Cependant, le contrat peut utiliser l'algorithme SHA3-512 pour répondre à des exigences de sécurité plus élevées en utilisant davantage de cycles CPU.

Surcharge d'exécution

Le mécanisme Gas dans la machine virtuelle Ethereum (EVM) est une conception très géniale. Il résout avec élégance le problème d'arrêt dans les scénarios d'application blockchain (parce qu'Ethereum est Turing complet, les instructions en boucle sont autorisées, mais les instructions en boucle infinies peuvent facilement provoquer des problèmes d'arrêt. Le mécanisme de gaz limite la quantité maximale de calcul d'un bloc, évitant ainsi ce problème) et permettant au programme d'effectuer des calculs sur une machine virtuelle complètement décentralisée. Cependant, nous avons constaté qu'il est très difficile de concevoir une méthode de calcul de gaz raisonnable pour différents opcodes (opérateurs) dans EVM. Il faut ajuster le mécanisme de calcul de gaz presque à chaque fois qu'il est mis à jour (le niveau d'abstraction d'EVM est relativement plus élevé, un). L'instruction EVM peut correspondre à plusieurs instructions matérielles sous-jacentes. Lors de l'exécution du programme, la quantité de données traitées et la complexité de calcul ne peuvent être évaluées que par estimation, l'EVM doit donc ajuster en permanence le mécanisme de calcul du gaz.

Par conséquent, nous nous sommes demandés : la conception de la VM peut-elle être utilisée pour garantir que la méthode de calcul de la consommation des ressources lorsque le programme est en cours d'exécution est plus raisonnable et plus précise ?

Nous espérions trouver une conception de VM offrant toutes les fonctionnalités ci-dessus, mais nous avons constaté qu'il n'existait aucune solution standard permettant de réaliser notre vision de CKB. Par conséquent, nous avons décidé de repenser une VM pouvant répondre à toutes les caractéristiques ci-dessus pour mieux réaliser la vision de CKB.

Bien que d'autres jeux d'instructions puissent partager certaines de ces fonctionnalités, dans notre évaluation, le jeu d'instructions RISC-V est le seul à les posséder toutes.

Par conséquent, nous avons finalement choisi d'implémenter CKB-VM en utilisant le jeu d'instructions RISC-V.

Lecture recommandée:

1. Après avoir attendu et observé, tâté le terrain et affronté des pièges, RISC-V s'est tenu sur le tremplin pour entrer dans l'âge d'or.

2. RISC-V est vraiment devenu une réalité, et la vitesse dépasse un peu l'imagination.

3. Quand CKB-VM rencontre RISC-V——La naissance de CKB-VM

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

4. La naissance de CKB-VM, une machine virtuelle blockchain basée sur RISC-V (1)

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

5. Inspiration, design et avantages - la naissance de CKB-VM (2)

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

6. Comment jouer joyeusement sur CKB-VM - La naissance de CKB-VM (3)

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

7. La question centrale de Zaki Manian : Machine virtuelle Blockchain, laquelle est la plus adaptée, WASM ou RISC-V ?

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