Moteur Radix : un meilleur modèle pour « l’enchâssement »

Dans mon article précédent , j'ai expliqué comment Radix Engine a évité certaines des failles de MoveVM de Sui. Résumer:

• MoveVM de Sui est de niveau trop bas et générique, ce qui crée un environnement de programmation DeFi encombrant.
• Radix Engine est orienté logique de haut niveau et actif + métier, permettant aux développeurs de se concentrer sur la logique DeFi plutôt que sur les détails de bas niveau.

MoveVM de Sui suit l'original Philosophie Ethereum d’un protocole « propre, simple, beau », qui délègue tout à la couche application. Cela donne aux développeurs la liberté d’explorer n’importe quel domaine, y compris les domaines inconnus à ce moment-là.

Un protocole trop simple et non structuré crée cependant des compromis importants. Par exemple, des fonctionnalités système courantes telles que l'autorisation nécessiteraient une implémentation complexe dans l'espace applicatif, les interfaces standard pourraient devenir plus fragmentées et l'optimisation des performances deviendra plus difficile.

Radix Engine, d'autre part, est conçu pour exécuter une logique non générique à l'échelle du système comme objectif technique principal, car il nous permet d'effectuer les opérations suivantes :

• Appliquer les normes/mises en œuvre à l’échelle du système . Une norme avisée permet de faciliter le développement, la maintenabilité et l'outillage dans la pile, car les API ne sont pas fragmentées (par exemple, ERC-20 contre ERC-721 contre ERC-404), et la compréhension du comportement ne nécessite pas d'interprétation de bytecode (pas plus). Tirages de tapis ERC-20). Cela offre aux développeurs et aux utilisateurs finaux une expérience DeFi plus sûre et plus cohérente.
• Exécuter une logique plus proche du matériel . Comme la logique du système n'a pas besoin d'être exécutée par un interpréteur pour être correcte, l'exécution de cette logique peut être exécutée aussi près que possible du matériel.
• Parallélisez l’exécution. En ayant une connaissance approfondie du comportement de certains objets, il est plus facile de prendre des décisions d'analyse statique avant l'exécution, ce qui permet une exécution parallèle.

Vitalik a récemment évoqué cette idée avec le terme « consécration », ou l’idée de rompre sélectivement avec l’abstraction afin de bénéficier des avantages de la logique renforcée par le protocole. Volant l'une de ses images, il présente le problème comme un compromis entre abstraction et consécration :

Cet équilibre entre la prise en charge de l'abstraction (c'est-à-dire les besoins futurs/divers des utilisateurs) tout en maintenant les performances/sécurité/utilisabilité (c'est-à-dire la consécration) est en fait un problème informatique très ancien. La conception des systèmes d'exploitation a spécifiquement tenté de résoudre un problème similaire au cours des dernières décennies : comment prendre en charge une gamme d'applications abstraites tout en conservant un système rapide, sécurisé et utilisable ?

Dans cet article, j'expliquerai comment Radix Engine utilise le modèle de système d'exploitation pour créer un cadre capable de tous les types de « consécration » sans la charge de complexité du protocole ou la perte de flexibilité que craint Vitalik.

Commençons par examiner la norme actuelle de l'industrie, la machine virtuelle Ethereum (« EVM »).

EVM en tant que VM

L'EVM est suffisamment basique pour pouvoir être modélisé comme une machine virtuelle (« VM ») avec les opcodes suivants :

• Ensemble d'opcodes Turing-complet
• Opcodes pour les appels vers d'autres contrats intelligents
• Opcodes pour la lecture/écriture sur le stockage persistant appartenant au contrat intelligent actuel

Les contrats intelligents compilés dans le bytecode EVM peuvent ensuite être exécutés sur une telle VM.

Dans ce modèle, toute forme de « consécration » nécessite des modifications de l'EVM ou du matériel de la VM. Par exemple, la prise en charge de la signature BLS nécessiterait l’ajout d’une nouvelle précompilation. Exécution EIP-2938 nécessiterait l’ajout de nouveaux opcodes. Développer ce qui est inscrit aboutit inévitablement à une machine virtuelle plus grande et plus complexe et oblige le concepteur de protocole à prendre l' une ou l'autre décision décrite par Vitalik.

Le problème général de ce modèle est que la dichotomie Abstraction/Enchâssement est trop couplée à la dichotomie Logiciel/Matériel. Autrement dit, l’intégration d’une logique dans le protocole force son intégration dans la VM. Il n’existe aucun moyen d’exprimer un « logiciel inscrit » ou un logiciel faisant partie du système.

Les systèmes d'exploitation ont résolu cette dichotomie avec la notion de « logiciel système ». Regardons de plus près.

Le modèle du système d'exploitation

L’un des principaux objectifs d’un système d’exploitation est de gérer la dichotomie logiciel/matériel – ou, plus précisément, la dichotomie application/matériel. La partie essentielle de tout système d'exploitation est le noyau, un logiciel qui gère les applications de l'espace utilisateur et leur accès au matériel. Les modules et pilotes du noyau sont des éléments logiciels système supplémentaires qui étendent l'ensemble du matériel pris en charge ou étendent les fonctionnalités du noyau.

\Du point de vue de la « consécration », le noyau et ses modules sont des parties inscrites du système mais ont la flexibilité d'un logiciel. Les modules du noyau, les machines virtuelles (« VM ») et les processus système de l'espace utilisateur sont encore plus « logiciels » puisqu'ils sont abstraits du noyau lui-même.

Dans ce modèle, la couche d’indirection entre applications et matériel permet de dissocier la dichotomie logiciel/matériel de la dichotomie abstraction/enchâssement. Le « logiciel système » permet l’enchâssement sans surcharger le matériel.

Moteur Radix en tant que système d'exploitation

S'inspirant de ce modèle de système d'exploitation, Radix Engine comprend plusieurs couches, chacune avec une responsabilité et une abstraction spécifiques, permettant la modularité et la possibilité de branchement du système.

Une telle conception modulaire permet d'appliquer la logique du système tout en permettant également les éléments suivants :

• Hériter des propriétés d'isolation de la couche dans laquelle il se trouve . Par exemple, un package consacré, bien que consacré, ne peut pas accéder à un état arbitraire mais doit suivre les limites de la couche application. Il s'agit d'un type de sécurité similaire à celui observé dans les pilotes de l'espace utilisateur ou dans la conception du micro-noyau. Autrement dit, le risque est atténué en isolant chaque partie du système afin que toute mise à jour du système (enchâssement) n'expose pas l'ensemble du système à un risque.
• Accédez aux fonctionnalités de la couche dans laquelle il se trouve. Par exemple, un package intégré peut hériter des fonctionnalités d'authentification et/ou d'évolutivité fournies par le système.
• Découpler la gouvernance. Cette conception modulaire permet à l'innovation dans chacun de ces modules de se produire en parallèle et à des rythmes différents.

Passons maintenant en revue chacune de ces couches et voyons quelles sont leurs responsabilités.

Couche d'application

La couche application est chargée de définir la logique de haut niveau. Le bytecode qui décrit cette logique, ainsi que d'autres informations statiques, est regroupé dans un format exécutable appelé Package. Les packages sont ensuite stockés dans le grand livre et disponibles pour exécution.

Les applications écrites en Scrypto, le langage basé sur Rust que nous avons créé pour le développement DeFi, résident dans cette couche. Les programmes Scrypto sont compilés dans des programmes WASM avec accès à un ensemble d'exportations de fonctions qui permettent au programme d'accéder aux services système/noyau. Ce API d'appel système est similaire à Linux appels système , qui donnent accès aux E/S partagées.

Couche de machine virtuelle

En passant à la couche suivante, la couche VM est chargée de fournir l’environnement informatique pour la couche application. Cela inclut une VM Turing-complete ainsi que l'interface pour accéder à la couche système.

Radix Engine prend actuellement en charge deux machines virtuelles : une machine virtuelle Scrypto WASM utilisée pour exécuter les applications Scrypto et une machine virtuelle native qui exécute les packages natifs compilés dans l'environnement de l'hôte.

Si nous examinons spécifiquement la VM Scrypto WASM, cela ressemble à ceci :

Cela peut ressembler essentiellement au modèle EVM, mais il existe deux différences cruciales :

• Suppression de l’accès direct au stockage. Plutôt que chaque contrat intelligent puisse accéder uniquement à son stockage détenu, toute lecture/écriture d'état se fait via des appels système. Cette couche d'indirection permet d'implémenter de nombreuses choses intéressantes dans le système, telles que le partage d'état entre les applications, la virtualisation d'état, etc. Cette couche d'indirection est similaire à l'indirection fournie par mémoire virtuelle ou Linux descripteurs de fichiers .

  
  

• Ajout d'appels système . Les appels système sont le mécanisme par lequel la couche application peut accéder aux services de la couche système, comme effectuer des appels à d'autres applications ou écrire des données sur un objet. Ces appels système sont similaires aux instructions d'interruption logicielle dans les processeurs réels (par exemple, INT instruction en x86).

Couche système

La couche système est responsable de la maintenance d'un ensemble de modules système ou de logiciels enfichables pouvant étendre les fonctionnalités du système. Ceux-ci sont similaires à ceux de Linux modules du noyau .

À chaque appel système, chaque module système est appelé avant que la couche système ne passe le contrôle à la couche noyau. Lorsqu'il est appelé, chaque module système peut mettre à jour un état particulier (par exemple, les frais de mise à jour dépensés) ou paniquer pour mettre fin à la transaction (par exemple, si le vérificateur de type échoue).

Ce modèle permet au système d'implémenter des fonctionnalités telles que l'autorisation, les redevances ou la vérification de type tout en étant découplé des couches application et noyau.

Couche de noyau

La couche noyau est responsable des deux fonctionnalités principales de Radix Engine : l'accès au stockage et la communication entre les applications. Ceci est quelque peu similaire à la responsabilité du système d'exploitation traditionnel en matière d'accès au disque et au réseau.

Pour Radix Engine, cela inclut la gestion de bas niveau suivante :

• Vérifiez que la sémantique de déplacement/emprunt est conservée lors de tout appel ou écriture de données. La règle du propriétaire unique et les règles d'emprunt sont appliquées par le noyau. En cas de non-respect de l’une de ces règles, la transaction paniquera.
• Gérez les objets transitoires et persistants. Un objet peut se trouver dans l'espace global à tout moment ou peut appartenir à une trame d'appel. Le noyau conserve des pointeurs corrects vers ces objets pendant l'exécution à mesure que les références à ces objets sont transmises.
• Gérez les mises à jour de l’état des transactions. Le noyau garde une trace des mises à jour d'état qui ont eu lieu au cours d'une transaction et qui seront ensuite validées dans la base de données à la fin de la transaction.

Logiciel consacré

Quel est le lien entre ces couches et l’inscription dans un protocole DLT ? Semblables à la couche noyau des systèmes d'exploitation, ces couches intermédiaires de Radix Engine fournissent l'indirection nécessaire pour découpler la dichotomie abstraction/enchâssement de la dichotomie logiciel/matériel et créer la notion de « logiciel enchâssé ».

Les logiciels consacrés possèdent la flexibilité et les propriétés de sécurité des logiciels tout en conservant la capacité d'appliquer une logique à l'échelle du système.

Passons en revue quelques exemples d'enchâssement actuellement exécutés sur le réseau Radix et voyons comment ils sont implémentés.

Ressources consacrées

Le principal différenciateur de la plate-forme Radix DeFi/Web3 est l'idée selon laquelle une ressource (c'est-à-dire un actif) est une primitive fondamentale qui doit être comprise séparément de la logique métier. L'intégration de ce concept permet à tous les dApps, portefeuilles et outils d'avoir une compréhension commune de ce à quoi ressemblent l'interface et le comportement d'un actif, ce qui rend la composabilité beaucoup plus facile.

Bien que les ressources soient l'une des parties les plus enracinées du système, la mise en œuvre de leur intégration ne nécessite que deux logiciels modulaires :

• Un package natif qui gère la logique des objets ressources tels que les compartiments, les coffres-forts et les preuves

• Un module système qui applique les invariants de durée de vie de ces objets (tels que la mobilité et la brûlabilité des ressources)

  
  

Le fait que Radix Engine puisse exprimer le concept profond d'une ressource standardisée et mobile tout en étant abstrait du système/noyau montre la puissance d'un cadre logiciel système modulaire.

Autorisation consacrée et redevances

Radix Engine normalise les autorisations et les redevances en dissociant cette logique de la logique métier et en les implémentant en tant que fonctionnalités du système. Cela permet aux utilisateurs et aux développeurs de disposer d'un moyen commun intégré de comprendre les exigences pour accéder à n'importe quelle fonction du grand livre.

La modularité du découplage de la logique métier de la logique système permet également des options de développement/débogage pratiques comme la possibilité de prévisualiser une transaction sans les contrôles d'authentification normaux (vous voulez simuler le résultat de l'envoi de 10 millions d'USDC quelque part ? Avec l'autorisation désactivée, votre prévisualisation de transaction peut faites la frappe !).

La consécration de l'authentification et des redevances nécessite quatre logiciels modulaires :

• Packages natifs d'authentification et de redevances qui permettent à la couche application d'accéder aux authentifications/redevances de n'importe quel objet (par exemple, pour récupérer la règle d'authentification pour accéder à une méthode ou réclamer des redevances).

• Les modules système Auth et Royalties sont appelés avant un appel de méthode objet pour vérifier si l'appelant dispose d'une autorisation suffisante pour passer l'appel et collecter des redevances.

  
  

  
  

Transaction consacrée

L'interface correcte entre l'utilisateur et le système est primordiale pour que tout système soit utilisable. Pour être utilisable, l’interface doit trouver le bon équilibre entre simplicité d’utilisation et puissance/flexibilité.

Dans le monde des systèmes d'exploitation, l'interface la plus courante est le terminal, un processus de l'espace utilisateur qui donne à un utilisateur un outil de ligne de commande pour appeler et composer divers appels système.

Dans le monde DLT, cette interface est la transaction. La norme industrielle pour une transaction consiste à utiliser un seul appel d’invocation générique de bas niveau. Malheureusement, c’est trop simple dans la mesure où il est difficile de comprendre ce que l’on fait réellement lorsqu’on interagit avec le système.

Radix Engine, d'autre part, utilise le modèle de système d'exploitation traditionnel et consacre un langage d'application (similaire à un langage de script de terminal tel que bash) pour appeler et composer des appels système en une seule transaction.

Étant donné que le point d’entrée d’une transaction opère dans la couche application, l’interpréteur de langage est implémenté en ajoutant un package natif Transaction Processor.

BLS inscrit

Les signatures BLS sont une primitive cryptographique importante car elles permettent la possibilité de signatures à seuil. Malheureusement, l’exécution d’une telle logique dans WASM utilise rapidement l’unité de coût maximum. Dans la récente mise à jour « Anemone », nous avons consacré BLS en l'exécutant de manière native et avons constaté un gain de performances 500 fois supérieur à WASM.

La logique BLS étant sans état, elle peut facilement être ajoutée en tant que précompilation supplémentaire à la machine virtuelle Scrypto WASM.

Conclusion

Ce qu’il faut consacrer et ce qu’il ne faut pas consacrer est important pour tout protocole DLT. Malheureusement, le modèle de VM existant dans l'industrie fait de chaque décision de conservation une décision à enjeux élevés.

En s'inspirant du modèle du système d'exploitation, Radix Engine résout ce problème en ajoutant une couche d'indirection entre « logiciel » et « matériel ». Cela permet à Radix Engine d'exprimer la notion de « logiciel enchâssé » et permet au protocole d'ajouter, de modifier et d'exprimer facilement de nouveaux systèmes enchâssés sans prendre de décisions de compromis à enjeux élevés.

À l'origine, le système d'exploitation était censé être un petit logiciel conçu pour gérer les ressources partagées pour plusieurs applications. À mesure que les demandes des utilisateurs pour une plate-forme meilleure, plus rapide et plus sécurisée se sont développées, l'entreprise a assumé de plus en plus de responsabilités avec une suite de logiciels de plus en plus vaste.

DeFi ne sera pas différent. À mesure que la demande pour une plate-forme DeFi plus rapide, plus sécurisée et plus utilisable augmente, une consécration accrue suivra. Radix Engine a été conçu dans cet esprit et fournit le cadre évolutif et sécurisé nécessaire pour étendre la consécration dans le futur.