Un article d'opinion de Josh Primero, architecte en chef du protocole chez RDX Works.  Après avoir lancé Radix Engine V2 sur le réseau Babylon, j'ai examiné de plus près la nouvelle vague de VM qui fait surface sur la scène DeFi. L'un des plus convaincants est MoveVM de Sui, une amélioration par rapport au MoveVM original de Diem.  Je suis enthousiasmé par l'architecture de Sui depuis un moment maintenant, car elle partage quelques philosophies techniques clés avec Radix :  Utilisation de la sémantique de déplacement pour permettre une programmation orientée actifs.  Tirer parti de la connaissance des dépendances des États pour faire évoluer le consensus grâce à un ordre partiel (plutôt que de sur-abstraire et de déplacer l'évolutivité vers une couche supérieure, la mode du jour)  Techniquement parlant, j'ai trouvé très cool la façon dont ils ont utilisé un langage et un code d'octet compilé qui capture statiquement les dépendances d'état minimales requises pour exécuter une certaine logique.  Cela se traduit non seulement par une exécution rapide, mais offre également des avantages en matière de sécurité puisque les dépendances d'état et les écritures d'état d'une transaction sont bien limitées.  Cette réalisation a cependant un coût. Les programmeurs DeFi doivent gérer un modèle plus difficile et parfois peu intuitif, répétant même des problèmes bien connus de l’EVM.  Examinons maintenant ces problèmes dans ce que j'ai trouvé être quatre failles dans la machine virtuelle de Sui.  1. Objet primitif trop générique  La plus grande innovation de MoveVM de Sui (ou MoveVM en général) est l'utilisation de la sémantique de déplacement/emprunt au niveau de la couche de bytecode. Cela signifie que leur machine de bas niveau peut comprendre la propriété et le mouvement des objets ; assez cool!  Chaque objet dans la VM de Sui  , une valeur typée avec une logique associée qui peut être détenue, déplacée et partagée.    agit comme un NFT  Malheureusement, comme un objet peut faire beaucoup plus de choses génériques dans ce modèle, le programmeur DeFi est chargé de définir et de gérer une machine à états de durée de vie d'objet complexe.   Plus précisément, dans Sui, lors de la définition d'une nouvelle structure, un programmeur doit spécifier une combinaison de 4 capacités (« copier », « déposer », « clé » et « stocker ») dont chacune affecte la machine à états de différentes manières. De plus, un programmeur doit gérer si, lors de l'instanciation, un objet doit être partagé, transféré, renvoyé sous forme de valeur ou gelé.  Une mauvaise configuration sur l’un d’entre eux peut provoquer des bugs subtils pouvant entraîner une perte de fonds.  Par exemple, dans le code suivant, nous utilisons Sui  pour mettre en place un prêt flash simple. Le problème? Nous avons accidentellement ajouté la possibilité de déposer un reçu.    Modèle de patate chaude  Cette petite erreur permet à un emprunteur de s’enfuir avec le prêt sans jamais le rembourser en laissant tomber lui-même le reçu. (Il y a un autre bug avec la relation FlashLoan et Receipt, voyez si vous pouvez le trouver !)  Ainsi, bien qu'il soit conceptuellement élégant et simple d'organiser une VM autour d'une abstraction d'objet unique avec un ensemble de capacités, du point de vue d'un programmeur, il est difficile de comprendre les répercussions de chacune car il y a tellement d'états de bas niveau à gérer. gérer.  Ce n’est pas très différent des problèmes de gestion de la mémoire des langages plus anciens et de la raison pour laquelle les machines virtuelles de récupération de place ont connu beaucoup de succès. Les programmeurs d'applications ne se soucient pas de la gestion des états de bas niveau, comme quand la mémoire peut-elle être libérée ; ils se soucient des objets et des relations entre ces objets.  Dans le même esprit, les programmeurs DeFi se soucient fondamentalement des actifs et de la logique autour du mouvement et de la propriété de ces actifs. Les actifs en eux-mêmes n'ont pas de logique inhérente, et la logique qui gère ces actifs n'a pas besoin de « bouger » ni d'être « possédée ».  MoveVM de Sui regroupe ces deux choses très différentes en une seule abstraction d'objet générique, ce qui constitue un modèle mental de programmation DeFi difficile.  2. Pas de répartition dynamique  Une caractéristique déterminante de MoveVM est son utilisation de la répartition statique, ce qui signifie qu'il n'y a aucune couche d'indirection entre un appel de fonction et son exécution pendant l'exécution. Les appels de fonction et sa logique sous-jacente sont liés statiquement au moment où un nouveau package est publié. Cela permet à la VM d'être rapide et prévisible, mais au prix d'une flexibilité moindre et d'un environnement de programmation plus difficile à utiliser.  Jetons un coup d'œil à trois répercussions du manque de répartition dynamique.  2a) Aucune composition fonctionnelle  Étant donné que la VM doit connaître la fonction exacte à appeler au moment de la publication du code, il est impossible de composer différentes fonctions ensemble ; un modèle très courant dans la programmation régulière (par exemple, les interfaces dans les langages OO ou les traits dans Rust).  Jetons un coup d'œil à un simple incitatif de pool de liquidités. Si je devais écrire un incitatif qui ajoute 10 % à votre contribution dans Rust, cela ressemblerait à ceci :   De cette façon, mon LiquidityEnhancer fonctionnerait avec n'importe quel pool qui implémente le trait Pool (Oui, pour vous les pintailleurs de Rust, ce trait est également lié statiquement. Ceci n'est qu'un exemple de composition de fonctions).  Ceci est impossible dans Sui puisque « contribuer » doit être une fonction déjà définie. Au lieu de cela, un nouveau package lié aux implémentations exactes du pool devrait être publié pour toute nouvelle implémentation du pool.  2b) Pas de rappels dynamiques ni de pointeurs de fonction  De même, être capable d’exécuter une logique arbitraire via une interface générique est une construction très utile, en particulier dans le cadre DeFi.  Imaginez un futur exécuteur incité qui incite un appelant à l'avenir à faire appel à une logique arbitraire (par exemple, pour l'utilisation de paiements différés). Dans Rust, cela ressemblerait à :   Cependant, cela n'est pas possible dans Sui en raison du manque de répartition dynamique. Au lieu de cela, un nouveau package IncentivizedFutureExecution devrait être publié pour chaque méthode souhaitant utiliser une telle fonctionnalité.  2c) Mise à niveau difficile  Sui a un soutien pour  . Malheureusement, en raison de l'invariant de répartition statique, la gestion des mises à niveau des packages est plus délicate et moins sécurisée que ce à quoi on pourrait s'attendre.   mise à niveau et versionnage des packages  Premièrement, des mises à jour de code transparentes et transparentes ne sont pas possibles. Si j'ai un package qui appelle un autre package et que l'autre package a une mise à jour de correctif de bogue requise, je dois publier moi-même un nouveau package si je veux le correctif.   Avec de plus en plus de dépendances de packages, cela peut facilement conduire à une explosion de mise à niveau de package, même à partir d'une simple correction de bug d'un package très utilisé.   Deuxièmement, tout l'ancien code existera toujours (nécessaire car tout autre code qui en dépend devra pouvoir l'appeler) même dans les cas où ce code peut contenir des bugs et/ou du code malveillant. Pour contrecarrer cela, la charge incombe à la couche application de maintenir un schéma de versionnage raisonnable dans l'état de ses objets.  3. Un modèle de boîte aux lettres gênant  Sui a récemment publié un  qui peut être mieux décrit comme un moyen d'envoyer un objet à un autre objet sans que l'autre objet le sache (auparavant, cela n'était possible qu'avec les adresses). Pour pouvoir accéder à cet objet, une transaction distincte avec connaissance de ce transfert doit être exécutée.    Modèle de transfert vers un objet  Une telle construction est utile pour supprimer la dépendance à l'égard de l'état de l'objet récepteur ; ce n'est pas différent de l'envoi d'UTXO à une autre adresse dans le modèle UTXO (la partie réception est également similaire à la preuve de propriété via des scripts de témoin UTXO). Le consensus de Sui est alors en mesure de tirer parti de cette absence de contestation et de mieux paralléliser une telle transaction.  Un tel gain de performances n’est cependant pas sans compromis en matière de sécurité. Le fait que des objets puissent être reçus sans informations sur l'objet destinataire (y compris s'il existe ou non !) introduit la possibilité de perdre définitivement l'accès à ces objets envoyés.  Ceci est possible si l'objet récepteur ne prend pas en charge l'objet envoyé. Une telle faille est similaire à l’envoi par erreur d’un jeton ERC-20 à un contrat intelligent qui ne prend pas en charge ce jeton (une cause   courante de perte de fonds). très  De plus, le fait qu'il existe deux types de relations parent-enfant, l'une dans laquelle le parent connaît ses enfants et l'autre dans laquelle les enfants connaissent leur parent, en fait un modèle plus complexe que celui typique des programmes traditionnels.   Existe-t-il une approche qui conserve les avantages en termes de performances sans programmer sur cette structure délicate ? Je crois que oui. Cela nécessite l'utilisation de pointeurs immuables ainsi que d'autres approches CRDT, mais j'en parlerai dans un prochain article.  4. Programmation d’état partagé délicate  La machine virtuelle de Sui est optimisée pour programmer et exécuter un état non litigieux. Cela a conduit à des mécanismes de programmation plutôt délicats lorsqu'il s'agit réellement de gérer un état partagé. Jetons un coup d'oeil à certains d'entre eux.  4a) Aucune référence stockée  La VM de Sui n'a aucune notion de références stockées. Si c'était le cas, il perdrait la capacité d'analyser statiquement les dépendances d'état d'une fonction et perdrait ainsi la capacité de parallélisme. La conséquence de ceci est que la charge de la gestion des références stockées incombe désormais au programmeur/utilisateur.  Par exemple, disons que j'ai un objet qui nécessite un prix d'un Oracle spécifique dans l'une de ses fonctions. Dans Rust, cela peut ressembler à ceci :   Dans Sui, les références ne pouvant pas être stockées, cette relation entre MyDefi et Oracle doit être décrite de manière plus fonctionnelle :   Mais attendez! N'importe quel oracle arbitraire peut désormais être transmis. Pour garantir que le bon oracle est utilisé, le  doit être utilisé:    Modèle de pointeur d'identification  Ce modèle, comparé aux références régulières, est plus fragile et il faut veiller à mettre en œuvre la relation correcte. À mesure que le graphe de relations entre les objets grandit et devient plus complexe, il est difficile d'imaginer que cette charge de programmation évolue très bien (par exemple, que se passerait-il si l'appel Oracle get_price avait également ses propres dépendances).  De plus, il incombera toujours à l'appelant, qu'il s'agisse d'un code de transaction ou de forfait, de transmettre la référence correcte. Si cette référence peut changer, cela impose une autre charge supplémentaire à l'appelant : s'assurer que la référence a été mise à jour vers le dernier état.  4b) Sécurité de type non dynamique pour les instances associées  Contrairement à la programmation traditionnelle, dans la programmation DeFi, il est très utile de pouvoir vérifier si une instance fait partie du même « groupe d'instances » qu'une autre instance.  Par exemple, il serait bien de vérifier que la jointure de deux pièces porte le même identifiant de pièce :   Le problème lors de l’implémentation de cela avec la sémantique générique traditionnelle est que les génériques sont utilisés pour représenter des types, et non « un groupe d’instances liées ».  De manière plutôt intelligente, Sui a pu contourner ce problème grâce à son  . Dans ce modèle pris en charge par le système, ils ont essentiellement dit que si vous souhaitez un nouveau groupe d'instances liées, créez ce nouveau type spécial qui représentera l'identifiant de ce groupe.   Modèle de témoin unique  Un énorme avantage est que la couche linguistique n’a pas besoin de changer du tout, et il suffit d’utiliser une sémantique générique bien connue pour obtenir ce type de sécurité.  Le plus gros défaut est qu'un nouveau type (et donc un nouveau package) doit être déployé chaque fois qu'un nouveau groupe d'éléments liés doit être créé. On ne peut pas simplement créer un nouveau Coin<T> dynamiquement sans déployer un nouveau package par exemple.   Conclusion  MoveVM de Sui a été construit selon les normes des ingénieurs système : une VM basée sur des primitives de bas niveau conceptuellement simples, appliquées de manière statique.  Malheureusement, simple ne veut pas dire facile, et leur insistance à éviter les modèles d’objets partagés normaux rend leur couche d’application assez complexe et peu intuitive à programmer.  DeFi est un monde d'objets partagés et désordonné : des pools avec d'importantes liquidités auxquels tout le monde peut accéder, des protocoles de prêt où n'importe qui peut emprunter et prêter, des oracles qui peuvent être appelés par n'importe qui, et la composition et l'interaction de tous ces objets se produisent en même temps.  Paralléliser un tel écosystème est le Saint Graal des DLT, et la tentative de Sui fonctionne bien, sauf qu'elle pousse trop de désordre vers la couche d'application.  Bien qu'il soit vrai que certains problèmes pourraient potentiellement être résolus avec un meilleur support d'outils et de langage (   ), certains sont irréparables sans de gros changements de VM (   ). 1 Object Primitive qui est trop générique, 4 Programmation d'état partagé maladroite 2 No Dynamic Dispatch, 3 An Awkward Modèle de boîte aux lettres

Buy XRD with card or bank transfer via Switchere.

Cet audio est produit dans la langue originale de l'histoire !

MoveVM de Sui : une revue complète

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Nomades numériques, écoutez : ce que vous devez savoir sur le nouveau visa DTV de la Thaïlande

Appuyez pour gagner : Telegram pourrait intégrer les 10 prochains milliards d'utilisateurs de crypto avant Solana

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Nomades numériques, écoutez : ce que vous devez savoir sur le nouveau visa DTV de la Thaïlande

Appuyez pour gagner : Telegram pourrait intégrer les 10 prochains milliards d'utilisateurs de crypto avant Solana

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps