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

Nous avons récemment discuté avec Sam Blackshear, directeur technique de Mysten Labs et créateur du langage de programmation Move, des raisons pour lesquelles il a développé Sui Move, un nouveau langage de programmation de contrats intelligents, des capacités que Sui peut étendre et de l'impact de la technologie décentralisée sur la création d'avantages. du destinataire.

Voici le contenu de cet entretien :

**Q1. Tout d'abord, pouvez-vous donner un aperçu de ce qu'est un langage de programmation, quelles qualités les développeurs recherchent le plus lorsqu'ils choisissent un langage de programmation et qu'est-ce qui vous pousse à développer votre propre langage de programmation ? **

Le langage de programmation n'est qu'un outil permettant une interaction conviviale, sûre, efficace et claire avec les ordinateurs, ce qui est particulièrement important pour les ordinateurs. Nous ne pouvons pas communiquer avec des ordinateurs en langage naturel, car tout le sens du langage naturel est d'être riche et expressif. Lorsque vous utilisez un ton légèrement différent ou que vous choisissez des façons subtilement différentes d'exprimer des mots, votre phrase ou votre paragraphe peut signifier quelque chose de complètement différent.

**Dans les langages de programmation, le plus important est d'avoir une sémantique définie avec précision. **Lorsque vous écrivez un programme, vous savez ce qu'il va faire. Si vous y apportez de petites modifications, vous savez où ce changement ira. Cela doit être maintenu à plusieurs niveaux, comme vous pouvez écrire du code dans un langage source, il a un sens, puis il est traduit dans d'autres formes de représentation, puis il doit également avoir le même sens, jusqu'à ce qu'il atteigne le il en va de même pour les modules de traitement.

** Je pense que les langages de programmation sont spécifiques à un domaine ou à une tâche, contrairement aux langages naturels. **Sinon, avec un seul langage de programmation, vous pouvez tout faire. Mais la raison pour laquelle il existe plusieurs langages de programmation est que vous ne pouvez pas être bon dans tous les domaines. Ils essaient de cibler des domaines problématiques spécifiques et de se concentrer 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 travaux système que nous effectuons chez Mysten, il se concentre sur l'écriture de code à la fois rapide et performant tout en maintenant la sécurité. Il vous donne accès à des détails de bas niveau comme la mémoire, les structures de thread ou la concurrence, mais ne vous laisse pas faire d'erreurs comme les langages précédents comme C ou C++.

L'histoire de Move est donc très similaire à cela. Quand je l'ai créé, ce n'était pas pour créer un nouveau langage. Vous avez mentionné plus tôt ce que les développeurs recherchent dans un langage. Ils demandent, "ce langage est-il bon pour ce que j'essaie d'accomplir ?" Mais je pense que ce qui est peut-être plus important, "*ce langage a-t-il une grande communauté ? Y a-t-il de nombreuses bases de données disponibles ? Y a-t-il de nombreux programmeurs qui l'utilisent ? y a-t-il de bonnes ressources pédagogiques? *" Celles-ci sont très importantes, donc la barre pour créer une nouvelle langue doit être très haute, même si la langue elle-même est meilleure, mais si elle ne possède pas ces facteurs, alors son avantage n'a pas de sens. Construire une communauté vaste et dynamique à partir de zéro est très difficile.

**Q2、****Pouvez-vous en dire plus sur le développement de Move ? **

**Le mouvement provient du projet Libra de Facebook. **Ma tâche à l'époque n'était pas de créer un nouveau langage, mais de "La Balance a besoin d'avoir des contrats intelligents, alors découvrez ce que nous devrions faire." J'ai regardé toutes sortes de choses. Pouvons-nous utiliser Solidity dans EVM ? Devrions-nous prendre un langage standard à usage général, comme WASM ou la JVM, et l'utiliser pour Libra ? Ou devrions-nous créer le nôtre ?

La décision de créer quelque chose à nous était basée sur la recherche de contrats intelligents existants, la compréhension de ce que les programmeurs essayaient de faire, et où certains langages les ont aidés et où ils les ont laissé tomber. Ma conclusion est que dans de nombreux cas, les langages de contrats intelligents existants les laissent tomber.

Cela ressort clairement du mauvais bilan de sécurité de Solidity, mais plus fondamentalement, ces contrats intelligents ne sont pas des types de programmes très traditionnels. La solidité n'est pas un langage construit pour ce que les gens font maintenant. Je ne le critique pas car c'est le premier langage de contrat intelligent qui ne sait pas encore ce que les gens veulent en faire. Une fois que vous voyez ce que les gens essaient de faire avec, je pense qu'il est clair que vous avez besoin d'un ensemble différent d'abstractions et d'outils de programmation que le langage Solidity ne fournit pas.

Ces contrats intelligents sont donc très simples, ils font essentiellement deux choses. Ils définissent les types d'actifs, y compris les règles de transfert des actifs, ce que vous pouvez en faire, qui peut les lire et qui peut y écrire**. **** Et vérifiez la politique de contrôle d'accès pour déterminer qui possède l'actif, qui est autorisé à l'utiliser et qui est autorisé à l'utiliser. **Tout tourne autour des actifs, et vous voulez que ces actifs aient les mêmes attributs que les actifs physiques. Si je te remets quelque chose, alors tu devrais l'avoir et je ne l'aurai plus.

** Dans les contrats intelligents, il existe le concept de propriété et de transfert de propriété, mais sur un ordinateur, tout n'est que des bits et des octets et peut être copié librement. ** Et, vous savez, ces concepts n'existent pas dans le monde réel. Vous voulez donc un langage qui vous donne de bonnes abstractions sur la propriété et l'homogénéisation. Comme dans le monde réel, mais sans obliger les programmeurs à le réinventer. Vous voulez des garanties de sécurité de base.

C'est ce que fait Move et pourquoi nous avons fini par créer ce nouveau langage. Ces tâches sont fondamentales pour la programmation de contrats intelligents. Ils sont difficiles à recréer dans d'autres langages, y compris les langages de contrats intelligents existants, et nous voulons concevoir l'ensemble du langage autour de ces fonctions de base afin que les programmeurs puissent écrire du code en toute sécurité et efficacement sans avoir à écrire du code à chaque fois. Les deux réinventent la roue.

**Q3、****Sui utilise une variante de Move appelée Sui Move. Qu'est-ce qui a motivé ces changements ? Quelles fonctionnalités de Sui Move sont idéales pour créer des produits dans Web3 ? **

Plusieurs facteurs ont conduit à ces changements, dont l'un était l'objectif du projet Libra initial de construire un réseau de paiement conforme. Nous avons donc essayé de concevoir Move (comme un langage à usage général. Mais nous avons aussi fait certaines choses consciemment, car Libra veut avoir des contraintes. L'une des choses importantes est qu'ils ne veulent pas que les gens puissent envoyer certains actifs à n'importe où. Ils veulent que les gens créent explicitement un compte et définissent certaines règles lors de la création du compte, telles que le propriétaire du compte doit passer par la vérification KYC. Ou il peut y avoir des frais pour créer le compte, ou il ne peut être créé par une petite personne autorisée à créer un compte Certaines personnes créent des comptes. Étant donné que le but de Libra est d'effectuer des paiements conformes et des contrats intelligents conformes, il y a ces limitations. Mais dans le monde Web3 plus général, c'est le contraire. Vous ne voulez pas être conforme au niveau de base, c'est le concept des contrats intelligents. Vous voulez que les choses soient aussi gratuites que possible, il est parfaitement possible d'envoyer quelque chose à n'importe quelle adresse. Ensuite, vous ne devriez pas avoir de création de compte explicite car qui bloquera divers cas d'utilisation, ce qui est un facteur important.

Un autre facteur est que, alors que nous nous sommes concentrés sur les actifs dans Move, à l'époque, dans Libra, nous n'avons pas réfléchi à la manière de mettre l'accent sur les actifs dans la transaction elle-même. Ainsi, lorsque vous arrivez au niveau de la transaction, vous n'avez toujours que cette API, où vous saisissez des nombres et des booléens et des choses qui ne sont pas des actifs, puis dans Move, vous utilisez ces nombres pour retirer des actifs des comptes et faire d'autres choses. Il s'avère que la plupart du code que vous exécutez est cette mauvaise comptabilité qui implique de retirer ceci, de retirer ce truc, de retirer autre chose, et ok, j'ai tous les actifs que je veux. Les voici, dans mon studio, et maintenant je peux commencer à faire quelque chose de significatif. Et puis à la fin du processus, vous pourriez dire : « OK, remettez ces actifs dans ce compte, remettez-les dans ce compte, réorganisez-les.

Dans Sui, nous avons réfléchi, si chaque programme commence et se termine de cette façon, pouvons-nous l'abstraire ? Ainsi, la logique pour traiter la transaction le fera pour le programmeur, et du point de vue du programmeur, ils ont juste les actifs dont ils ont besoin prêts et commencent à faire le travail intéressant tout de suite. **** Il s'agit du **** modèle de données centré sur l'objet qui existe dans Sui ****. ** Dans le Move original, nous avions un modèle de données basé sur des comptes, les actifs étaient stockés sous des comptes et les programmeurs devaient les extraire explicitement. Dans Sui, lorsqu'ils entrent dans la partie Move de la transaction, les actifs ont déjà été acquis par le runtime Sui. C'est plus pratique pour les programmeurs car ils n'ont pas à faire tout cela avant et après la comptabilité, et cela nous permet également de déterminer si nous pouvons exécuter une transaction en parallèle avec une autre sans réellement l'exécuter. quelques autres choses plus efficacement.

Nous avons également effectué d'autres travaux très intéressants, comme tirer parti d'un modèle de données basé sur des objets pour des blocs de transaction programmables. C'est un sujet un peu technique que je suis heureux de discuter en profondeur. Mais ces deux facteurs ont été les principaux moteurs de la divergence par rapport au Move original.

**Q4、****Pouvez-vous partager plus d'informations sur les blocs de transaction programmables et leurs fonctions ? **

J'aime utiliser une analogie pour expliquer que les autres blockchains sont comme une aire de restauration dans un centre commercial. Tu veux une glace, tu vas au stand de glaces, tu sors ta carte bleue et tu payes. Mais si vous décidez que vous voulez toujours un hamburger, vous allez au stand de hamburgers et vous payez à nouveau. Je ne suis pas un glouton, mais si je voulais manger huit choses, il faudrait que je fasse huit transactions distinctes. ** Là où Sui est plus un buffet, chaque offre est plus qu'une chose. Une fois que vous avez payé pour le buffet, vous pouvez faire beaucoup de choses sans frais supplémentaires. ** Vous pouvez avoir de la glace, vous pouvez avoir des hamburgers, vous pouvez tous les mélanger.

Pour rendre ce concept un peu plus concret, dans le cas simple, si vous envoyez 100 transactions pour frapper 100 NFT, vous pouvez envoyer une transaction qui frappe 100 NFT. Un tel coût est presque le même que le coût de frappe d'un NFT. Vous pouvez également effectuer des packages de transactions hétérogènes, de sorte que la première transaction d'un bloc prend un personnage Mario de votre portefeuille multisig, et la deuxième transaction demande un Mario, qui vous permet ensuite de jouer au jeu. Si vous gagnez le jeu et obtenez le trophée, peut-être qu'un troisième échange place le trophée dans une armoire à trophées que vous partagez avec des amis. ** Ce qui est cool, c'est que les blocs de transaction programmables permettent aux programmeurs d'écrire du code de telle manière que le jeu n'a pas à connaître les portefeuilles multisig ou comment Mario est stocké, ni à connaître votre armoire à trophées ou comment elle est implémentée . **

**Les blocs de transaction programmables consistent en des 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 de son origine et transmettre sa sortie à l'objet qui en a besoin, sans vous soucier de l'endroit où il est transmis. Dans d'autres blockchains, le couplage est plus fort, donc les jeux doivent s'intégrer aux portefeuilles multisig et aux casiers à trophées, ou ils doivent tous implémenter une interface commune et avoir un couplage plus fort. **Sui rend les combinaisons dites ad-hoc beaucoup plus faciles. ** Par exemple, si les tuyaux correspondent, nous pouvons le faire en une seule transaction.

**Q5、****Quels sont les avantages des blocs de transaction programmables pour les utilisateurs ? **

Pour les utilisateurs, les avantages des blocs de transactions programmables incluent ** des coûts de gaz réduits **, car vous pouvez regrouper toutes les opérations en une seule transaction au lieu de faire des transactions séparées. De plus, nécessite moins d'approbations. Si vous utilisez un système qui nécessite l'approbation des transactions, vous n'avez besoin de le faire qu'une seule fois, puis il le fait en une seule fois. Un autre avantage est atomicité, si vous voulez faire trois choses différentes et que la troisième opération ne réussisse que si les deux premières opérations réussissent, si ces opérations doivent être des transactions indépendantes, alors vous ne pouvez pas y arriver. Cependant, si vous pouvez les mettre tous en une seule transaction, vous pouvez facilement y parvenir.

**Q6, ****Je vous ai entendu, ainsi que d'autres, parler du développement sur Sui comme d'une excellente expérience pour les programmeurs et c'est important. Avez-vous des anecdotes à partager pour les programmeurs Web3 expérimentés et débutants qui débutent avec 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ûre **. J'étais juste sur un podcast sur Bucket Protocol et ils construisent un projet DeFi vraiment cool sur Sui. Tout en démontrant l'architecture du système, ils décrivent comment les différents composants fonctionnent ensemble. Ils ont dit que s'ils avaient écrit ce projet dans Solidity, cela aurait peut-être pris huit mois, mais avec Sui Move, cela n'a pris que deux mois, et ils sont très confiants dans sa sécurité. Le fonctionnement de la langue est très proche de l'idée d'un portefeuille de projets dans leur tête. Dans le monde de Solidity, la connexion est moins directe.

Ce n'est qu'un exemple, mais nous entendons beaucoup de cas similaires où les gens disent qu'ils se développent plus rapidement sur la langue et se sentent plus confiants lorsqu'ils ont terminé. Ça me fait plaisir d'entendre ça. Mais d'une certaine manière, ce n'est pas surprenant, nous nous sommes penchés sur Solidity et avons découvert les problèmes. Nous avons explicitement conçu des scénarios sur la façon de le rendre plus sûr et plus rapide. Nous avons examiné ce que les développeurs du langage essayaient de faire et comment concevoir le langage pour répondre à leurs besoins, plutôt que de répondre à ce qui existait déjà. La langue est conçue pour les problèmes que les gens ont, donc quand ils changent, ils apprécient vraiment la langue.

** Ils disent que l'avantage du premier arrivé est important, mais je suppose que dans ce cas, c'est l'avantage du retardataire qui compte le plus. **

C'est vrai, c'est ça.

** Q7 、 **** Vous avez abordé ce sujet lorsque vous avez mentionné Sui Move et les fonctionnalités globales orientées objet de Sui. Mais pouvez-vous articuler plus clairement le lien entre la conception de Sui Move et la capacité de Sui à parvenir à une adoption massive du Web3, à une faible latence, à un faible coût et à l'évolutivité ? **

L'une des choses que nous hésitons beaucoup à apporter à Sui, et le problème auquel sont confrontées les autres plates-formes, c'est que si vous avez une capacité limitée, qu'il s'agisse de 15 transactions par seconde (TPS) comme Ethereum ou de 100 ou 1 000 transactions, si c'est un nombre fixe, puis lorsque la plate-forme devient trop performante, elle atteindra la limite supérieure de capacité. À ce stade, l'expérience de tous ceux qui utilisent la plateforme est dégradée. S'il n'y a que 1 000 postes vacants, vous devez choisir les 1 000 plus importants, qui peuvent être sélectionnés par le biais d'offres de gaz ou d'autres méthodes. Pour tous, les prix du gaz augmenteront, la latence augmentera, ou les deux. De nombreux cas d'utilisation sont exclus car seuls ceux qui peuvent payer les frais les plus élevés réussiront, tandis que d'autres devront chercher ailleurs ou attendre plus longtemps. Ce n'est pas une bonne situation.

**Sui cible l'évolutivité horizontale. **Un certain débit peut être atteint si une certaine quantité de matériel est allouée. Si un débit supérieur est requis, le validateur peut introduire davantage de fonctionnalités matérielles, sans limite supérieure. C'est ainsi que fonctionnent tous les services Web2. Je veux dire, il y a certaines contraintes d'ingénierie que vous devez contourner, ce n'est pas une chose sûre ou facile à faire, mais tout le monde veut atteindre une évolutivité horizontale lors de la conception de services Web évolutifs.

Si Sui a plus de clients ou d'utilisateurs, notre objectif est que Sui continue de croître et tout devrait fonctionner. Bien sûr, tout en conservant une latence très faible. Vous ne voulez pas sacrifier la latence tout en augmentant le débit.

Dans le système Libra, ces caractéristiques ne sont pas prises en compte. Ce n'est qu'un système de paiement à petite échelle, avec des centaines d'opérateurs de paiement, et il peut y avoir des dizaines de millions de paiements par jour, mais pas plus. Nous avons donc adopté une architecture single box, plus simple et suffisante. Mais dans Sui, nous savons que le système Libra ne fonctionnera pas car il n'a pas la fonctionnalité d'évolutivité horizontale. Nous avons donc pensé, comment pouvons-nous concevoir un système à partir de zéro qui peut faire cela. C'est là qu'intervient le modèle de données orienté objet. Nous avons essentiellement abandonné l'ancien modèle de données basé sur les comptes, car il rendait très difficile la réalisation d'une évolutivité horizontale. Au lieu de cela, si vous organisez tout en objets, l'état global n'est qu'une grande carte des ID d'objet aux objets. C'est un magasin clé-valeur, et nous savons comment faire évoluer les magasins clé-valeur, c'est un simple problème d'ingénierie.

La question devient alors, comment concevons-nous une structure de transaction qui s'adapte à la récupération et à la mise à jour des données du magasin clé-valeur ? Comment partitionner un magasin clé-valeur ? Comment décidons-nous où les transactions doivent être traitées ? C'est essentiellement de là que ça vient. Cela dit, nous savons comment mettre à l'échelle ces choses. Comment transformer cela en quelque chose qui a des propriétés de blockchain, des lectures vérifiables, fonctionne avec Move, etc. Et puis comment les réunir le plus harmonieusement possible.

Q8、** À un niveau supérieur, comment discutez-vous du potentiel de la technologie décentralisée avec les développeurs qui sont sceptiques vis-à-vis du Web2 ? **

** Je pense que la blockchain et les crypto-monnaies sont fondamentalement une technologie qui élimine les frictions. ** Il existe des obstacles qui nous empêchent d'effectuer des transactions financières, de créer des applications ou de configurer des informations, car les informations ne peuvent pas franchir ces barrières, ou si elles franchissent ces barrières, elles nécessitent l'aide de tiers, et ces premiers Le tiers facture des frais pour être en mesure de fournir une assistance.

Un exemple classique que les gens aiment utiliser est l'achat d'une maison. Il y a un acheteur et un vendeur, mais lorsque vous effectuez les paiements, il doit y avoir un agent d'entiercement qui ne fait rien d'autre que de s'asseoir et d'entiercer les fonds parce que l'acheteur et le vendeur ne se font pas entièrement confiance. C'est une réalité. Nous allons nous en occuper. Cependant, si l'agent d'entiercement peut être un code visible par les deux parties ou vérifié par un tiers, il peut alors faire le travail gratuitement ou pour beaucoup moins. Le but de la blockchain n'est pas d'éliminer les agents fiduciaires dans l'immobilier. Ce n'est qu'un des cas d'utilisation, mais c'est souvent le cas.

** S'il n'y a plus de barrière d'interopérabilité entre l'application A et l'application B, mais construites sur la même plate-forme sous-jacente, vous pouvez donc faire passer les choses d'une application à l'autre, qu'il s'agisse d'éléments intégrés à l'application, de données, de promotions ou de tiers -produits de fête construits sur les deux. **Ou imaginez Internet, où les sites Web partagent des données entre eux, mais ce ne sont que des métadonnées en lecture seule. Et si ceux-ci pouvaient devenir des monnaies ? Ou pourrait-il s'agir d'un article consommable? Ou pourrait-il s'agir de programmes de fidélité et de coupons ? Tout a cette fonctionnalité intégrée. C'est très abstrait, mais c'est là que réside le potentiel. Habituellement, une personne qui construit les considérera comme de nouvelles superpuissances qu'il peut utiliser pour construire quelque chose de plus attrayant.

Q9、** Pour les utilisateurs finaux, même s'ils n'ont pas de connaissances techniques, ressentez-vous une hésitation lorsqu'ils envisagent la confiance dans le code, même si l'autre option est une grande entité centrale opaque ? **

Je ne pense pas. Parce qu'on fait des trucs comme ça tous les jours, non ? Lorsque je me connecte à mon e-mail, je ne crains pas que le code supprime l'un de mes e-mails, ou que lorsque j'envoie un e-mail, il ne l'enverra pas réellement. Si cela se produit, j'arrêterai probablement d'utiliser le courrier électronique ou j'utiliserai un autre fournisseur. Je pense que c'est très similaire, bien sûr, tout le monde ne peut pas lire quelque chose et vérifier comment cela fonctionne.

Et, vous savez, si je veux vérifier le code de l'e-mail, je ne peux pas parce que le code n'y est pas. La transparence est donc un aspect important de cela. Bien que tout le monde ne soit pas capable de le faire, certains peuvent le goûter. Et, combinez cela avec la réutilisation de n'importe quoi, plus l'immuabilité. C'est la clé ici. Lorsque je me connecte à mon e-mail, je ne sais pas si le code a changé depuis la dernière fois que j'ai fait quelque chose. Il n'y a aucune transparence à ce sujet. Même en connaissant ces informations, vous pouvez les obtenir dans Web3, et vous ne pouvez pas les obtenir ailleurs.

**Q10、****Quelles sont vos attentes concernant le développement futur de Sui Move ? **

** De nombreuses fonctionnalités sur lesquelles nous nous concentrons actuellement sont basées sur notre expérience avec les développeurs qui ont publié leurs premiers lots de packs Sui Move, puis ont examiné comment ils souhaitaient faire évoluer ces fonctionnalités, lesquelles étaient faciles à développer et lesquelles ceux étaient plus difficiles. **Sui Move est un excellent langage pour un premier package de version, mais pour le type que je vais changer, je vais ajouter des champs, je vais ajouter des fonctions, je vais le faire d'une manière cohérente mais qui ne va pas à l'encontre de l'utilisation du package initial. Pour fonctionner d'une manière en laquelle les utilisateurs ont confiance, cela devient un problème très difficile. Une grande partie de ce que nous faisons consiste à examiner cela et à déterminer quelles fonctionnalités au niveau du langage nous pouvons ajouter qui donnent aux programmeurs la flexibilité d'étendre tout en maintenant la confiance des utilisateurs du code d'origine.

** Nous travaillons sur de nombreuses fonctionnalités liées à cela, en particulier les types d'énumération. ** Nous travaillons également beaucoup sur l'amélioration de l'expérience de connexion de Move avec le code frontal. Nous plaisantons souvent sur le fait qu'une application Sui typique est constituée de 5 % de code Move et de 95 % de code frontal. Nous sommes donc très concentrés sur ces 95 %. Nous avons passé beaucoup de temps à parler de Move, mais nous nous sommes également beaucoup concentrés sur le fait de rendre les autres parties plus efficaces et de faciliter les connexions. En général, nous sommes très concentrés sur la façon de faire en sorte que l'application se compose davantage de Move pour plus de sécurité. En même temps, comment pouvons-nous rendre ces 95 % du code compréhensibles à la fois pour les programmeurs Move et les programmeurs non-Move ?