Entretien avec le père du langage Move : pourquoi le langage de contrat intelligent Sui Move est-il adapté à la construction de produits Web3 ?

Récemment, nous avons discuté avec Sam Blackshear, le directeur technique de Mysten Labs et créateur du langage de programmation Move, de pourquoi il a développé ce nouveau langage de programmation de smart contracts, des capacités d'expansion de Sui et des avantages des technologies décentralisées pour les créateurs.

Voici le contenu de cette interview :

Q1. Tout d'abord, pouvez-vous donner un aperçu de ce qu'est un langage de programmation, quelles sont les qualités les plus importantes pour les développeurs lors du choix d'un langage de programmation, et qu'est-ce qui vous a poussé à développer votre propre langage de programmation ?

Les langages de programmation ne sont qu'un outil d'interaction amical, sûr, efficace et précis avec les ordinateurs, ce qui est particulièrement important pour eux. Nous ne pouvons pas communiquer avec les ordinateurs en utilisant des langues naturelles, car le sens entier des langues naturelles est riche et expressif. Lorsque vous exprimez des mots avec un ton légèrement différent ou en choisissant une manière légèrement différente, le sens de vos phrases ou de vos paragraphes peut être complètement différent.

Et dans les langages de programmation, ce qui est le plus important, c'est d'avoir une sémantique précisément définie. Lorsque vous écrivez un programme, vous savez exactement ce qu'il va faire. Si vous apportez de petites modifications, vous savez quel sera le résultat de ce changement. Cela doit être maintenu à plusieurs niveaux, par exemple, vous pouvez écrire du code dans un langage source qui a une signification, puis être converti en d'autres formes de représentation, il devrait également avoir la même signification, jusqu'à ce qu'il atteigne le module de traitement de la machine.

Je pense que, contrairement aux langages naturels, l'essence des langages de programmation est de cibler un domaine ou une tâche spécifique. Sinon, une seule langue de programmation pourrait accomplir toutes les tâches. Mais la raison pour laquelle il existe plusieurs langages de programmation est que vous ne pouvez pas exceller dans tous les domaines. Ils s'efforcent de se concentrer sur des domaines de problèmes spécifiques et se concentrent sur la résolution de ces problèmes. Par exemple, si vous regardez le langage de programmation Rust que nous utilisons pour écrire la blockchain Sui et la plupart des autres systèmes sur lesquels nous travaillons chez Mysten, il se concentre sur l'écriture de code à la fois rapide et performant, tout en garantissant la sécurité. Il vous permet d'accéder à des détails de bas niveau tels que la mémoire, la structure des threads ou la concurrence, mais ne vous laisse pas commettre des erreurs comme le faisaient les langages précédents (comme C ou C++).

Ainsi, l'histoire de Move est très similaire à cela. Quand je l'ai créé, ce n'était pas pour créer un nouveau langage. Vous avez mentionné auparavant ce que les développeurs recherchent dans un langage. Ils se demandent : "Ce langage est-il adapté aux tâches que je veux accomplir ?" Mais je pense qu'il est peut-être plus important de se demander : "Ce langage a-t-il une grande communauté ? Y a-t-il beaucoup de bases de données disponibles ? Y a-t-il beaucoup de programmeurs qui l'utilisent ? Y a-t-il de bonnes ressources pédagogiques ?" Tous ces éléments sont très importants, donc le seuil pour créer un nouveau langage doit être très élevé, même si ce langage est meilleur en soi. Mais s'il n'a pas ces facteurs, alors ses avantages n'ont pas de sens. Construire une grande communauté dynamique à partir de zéro est très difficile.

Q2, pouvez-vous partager plus d'informations sur le développement de Move ?

Move provient du projet Libra de Facebook. Ma tâche à l'époque n'était pas de créer un nouveau langage, mais de "Libra a besoin de smart contracts, alors découvrons ce que nous devrions faire." J'ai examiné toutes sortes de choses. Pouvons-nous utiliser Solidity dans l'EVM ? Devons-nous utiliser un langage général comme WASM ou JVM et l'appliquer à Libra ? Ou devrions-nous créer notre propre chose ?

La décision de créer nos propres éléments est basée sur l'étude des smart contracts existants, la compréhension de ce que les programmeurs essaient de faire, ainsi que des endroits où certaines langues les aident et les déçoivent. Ma conclusion est que, dans de nombreux cas, les langages de smart contracts existants les déçoivent effectivement.

Cela peut être clairement vu dans le mauvais dossier de sécurité de Solidity, mais plus fondamentalement, ces smart contracts ne sont pas vraiment le type de programme traditionnel. Solidity n'est pas un langage conçu pour les choses que les gens font actuellement. Je ne veux pas le critiquer, car c'est le premier langage de smart contracts, il ne savait pas encore ce que les gens voulaient en faire. Une fois que vous voyez ce que les gens essaient d'en faire, je pense qu'il est évident que vous avez besoin d'un ensemble différent d'abstractions et d'outils de programmation, que le langage Solidity ne fournit pas.

Donc, ces smart contracts sont très simples, ils font essentiellement deux choses. Ils définissent le type d'actif, y compris quand l'actif peut être transféré, ce que vous pouvez en faire, qui peut les lire, qui peut les écrire, et les règles. Et ils vérifient les politiques de contrôle d'accès, déterminant qui possède l'actif, qui est autorisé à l'utiliser, et qui est autorisé à y effectuer des opérations. Tout tourne autour de l'actif, vous voulez que ces actifs aient les mêmes propriétés que les actifs physiques. Si je vous donne quelque chose, alors vous devriez le posséder, et je ne le possède plus.

Les contrats intelligents contiennent des concepts de propriété et de transfert de propriété, mais sur un ordinateur, tout n'est que des chiffres et des octets, et tout peut être copié librement. De plus, vous savez que ces concepts n'existent pas dans le monde réel. Par conséquent, vous espérez avoir un langage qui puisse vous fournir une bonne abstraction sur la propriété et l'homogénéité. Comme dans le monde réel, mais sans forcer les programmeurs à le réinventer. Vous souhaitez obtenir des garanties de sécurité de base.

C'est le rôle de Move et pourquoi nous avons finalement créé ce nouveau langage. Ces tâches sont fondamentales pour la programmation des smart contracts. Elles sont difficiles à recréer dans d'autres langages, y compris les langages de smart contracts existants. Nous voulions concevoir un langage entier autour de la fourniture de ces fonctionnalités de base afin que les programmeurs puissent écrire du code de manière sûre et efficace, sans avoir à réinventer la roue à chaque fois qu'ils souhaitent écrire un peu de code.

Q3, Sui utilise une variante de Move, appelée Sui Move. Qu'est-ce qui a motivé ces changements ? Quelles caractéristiques de Sui Move sont particulièrement adaptées à la construction de produits dans Web3 ?

Plusieurs facteurs ont contribué à ces changements, l'un d'eux étant que l'objectif initial du projet Libra était de construire un réseau de paiement conforme. Ainsi, nous avons essayé de concevoir Move comme un langage universel. Mais nous avons également consciemment fait certaines choses, car Libra souhaitait avoir des conditions restrictives. L'une des choses importantes est qu'ils ne voulaient pas que les gens puissent envoyer certains actifs n'importe où. Ils souhaitaient que les gens créent explicitement un compte et qu'à la création du compte, certaines règles soient mises en place, comme par exemple que le propriétaire du compte doive passer une vérification KYC. Ou il pourrait être nécessaire de payer des frais pour créer un compte, ou bien seuls un petit nombre de personnes ayant les droits de création de compte pourraient en créer un. Étant donné que l'objectif global est que Libra souhaite effectuer des paiements conformes et des smart contracts conformes, ces restrictions existent. Mais dans le domaine Web3 plus général, c'est tout le contraire. Vous ne souhaitez pas être conforme au niveau de base, c'est le concept des smart contracts. Vous souhaitez que les choses soient aussi libres que possible, et qu'il soit totalement possible d'envoyer quelque chose à n'importe quelle adresse. Ensuite, vous ne devriez pas procéder à une création de compte explicite, car cela bloquerait divers cas d'utilisation. C'est un facteur important.

Un autre facteur est que, bien que nous nous concentrions sur les actifs dans Move, nous n'avons pas pris en compte à l'époque comment introduire l'accent sur les actifs dans la transaction elle-même dans Libra. Donc, lorsque vous arrivez au niveau de la transaction, vous n'avez toujours que cette API, où vous entrez des chiffres et des booléens, des choses qui ne sont pas des actifs, puis dans Move, vous utilisez ces chiffres pour extraire des actifs de votre compte et effectuer d'autres opérations. Il s'avère que la plupart du code que vous exécutez est ce travail de livre déplaisant, qui consiste à sortir cette chose, sortir celle-là, sortir d'autres choses, d'accord, j'ai tous les actifs que je veux. Ils sont ici, dans mon atelier, maintenant je peux commencer à faire quelque chose de significatif. Puis à la fin de ce processus, vous pourriez dire : "D'accord, remettez ces actifs dans ce compte, remettez-les dans cet autre compte, réorganisez-les."

Dans Sui, après mûre réflexion, si chaque programme commence et se termine de cette manière, pouvons-nous l'abstraire ? Ainsi, la logique de gestion des transactions sera effectuée par le programmeur, et du point de vue du programmeur, il lui suffit de préparer les actifs nécessaires et de commencer immédiatement à travailler sur des tâches intéressantes. C'est le modèle de données centré sur les objets qui existe dans Sui. Dans le Move original, nous avons un modèle de données basé sur les comptes, les actifs étant stockés sous les comptes, et le programmeur doit les extraire explicitement. Dans Sui, lorsqu'ils entrent dans la partie Move de la transaction, les actifs ont déjà été récupérés par le runtime de Sui. C'est plus pratique pour le programmeur, car il n'a pas besoin de faire tout ce travail de comptabilité avant et après, et c'est aussi l'arme secrète qui nous permet de déterminer si une transaction peut être exécutée en parallèle avec une autre sans l'exécuter réellement, d'effectuer l'évolutivité horizontale de Sui et de réaliser d'autres opérations de manière plus efficace.

Nous avons également réalisé d'autres travaux très intéressants, tels que l'utilisation de modèles de données basés sur des objets pour des blocs de transactions programmables. C'est un sujet plutôt technique, et je serais ravi d'en discuter plus en profondeur. Mais ces deux facteurs sont les principales motivations qui ont conduit à l'écart avec la version originale de Move.

Q4, pouvez-vous partager plus d'informations sur les blocs de transactions programmables et leurs fonctionnalités ?

J'aime utiliser une analogie pour expliquer, les autres blockchains ressemblent à une aire de restauration dans un centre commercial. Si vous voulez une glace, vous allez au stand de glaces, sortez votre carte de crédit pour payer. Mais si vous décidez que vous voulez aussi un hamburger, vous allez au stand de hamburgers et payez à nouveau. Je ne suis pas une personne gourmande, mais si je veux manger huit choses, je dois effectuer huit transactions distinctes. En revanche, Sui ressemble plus à un buffet, où chaque transaction n'est pas seulement une chose. Une fois que vous avez payé les frais du buffet, vous pouvez faire beaucoup de choses sans frais supplémentaires. Vous pouvez manger de la glace, vous pouvez manger un hamburger, vous pouvez les mélanger.

Pour rendre ce concept plus concret, dans un cas simple, si vous devez envoyer 100 transactions pour créer 100 NFT, vous pouvez envoyer une transaction pour créer 100 NFT. Le coût de cette opération est presque le même que celui de la création d'un NFT. Vous pouvez également effectuer un emballage de transactions hétérogènes, par exemple, la première transaction dans le bloc retire un personnage Mario de votre portefeuille multi-signatures, tandis que la deuxième transaction demande un Mario, puis vous permet de jouer au jeu. Si vous gagnez le jeu et obtenez un trophée, peut-être que la troisième transaction mettra le trophée dans une vitrine de trophées partagée avec des amis. Ce qui est génial, c'est que les blocs de transactions programmables permettent aux programmeurs d'écrire du code de cette manière, le jeu n'a pas besoin de connaître le portefeuille multi-signatures ou la manière dont Mario est stocké, il n'a pas non plus besoin de connaître votre vitrine de trophées ou sa manière de mise en œuvre.

Un bloc de transaction programmable se compose de transactions avec des objets d'entrée et de sortie. Si vous avez besoin d'un objet d'entrée, vous pouvez obtenir cet objet sans vous soucier d'où il vient, puis transmettre sa sortie à l'objet qui en a besoin, sans avoir à vous soucier non plus de l'endroit où elle sera transmise. Dans d'autres blockchains, le couplage est plus fort, donc le jeu doit être intégré avec des portefeuilles multi-signatures et des vitrines de trophées, ou ils doivent tous deux mettre en œuvre certaines interfaces communes et avoir un couplage plus fort. Sui rend la soi-disant combinaison temporaire plus facile. C'est comme si, si les tuyaux correspondent, nous pouvons terminer en une seule transaction.

Q5, quels sont les avantages des blocs de transactions programmables pour les utilisateurs ?

Pour les utilisateurs, les avantages des blocs de transaction programmables incluent des frais de gaz plus bas, car vous pouvez regrouper toutes les opérations dans une seule transaction, au lieu de faire des transactions séparées. De plus, le nombre d'approbations nécessaires sera également réduit. Si le système que vous utilisez nécessite une approbation de transaction, vous n'avez besoin de faire qu'une seule approbation, puis cela accomplira toutes les opérations en une seule fois. Un autre avantage est l'atomicité. Si vous souhaitez faire trois choses différentes et que vous souhaitez que la troisième opération ne réussisse que si les deux premières réussissent, si ces opérations doivent être des transactions indépendantes, vous ne pouvez pas réaliser cela. Cependant, si vous pouvez les mettre toutes dans une seule transaction, alors vous pouvez facilement y parvenir.

Q6, j'ai entendu vous et d'autres parler du fait que le développement sur Sui est une excellente expérience pour les programmeurs, et c'est important. Avez-vous des anecdotes à partager pour les programmeurs Web3 expérimentés et novices qui commencent à utiliser Sui Move ?

Pour les développeurs venant d'autres langages de programmation Web3, leur expérience de développement sur Move et Sui Move est en effet plus efficace et plus sécurisée. Je viens de participer à un podcast sur le Bucket Protocol, qui construit un non sur Sui.