Entretien avec le fondateur de 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 le fondateur du langage de programmation Move, de la raison pour laquelle il a développé Sui Move, ce nouveau langage de programmation pour les smart contracts, des capacités d'évolutivité 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 sont des outils permettant d'interagir de manière amicale, sûre, efficace et claire avec les ordinateurs. Cela est particulièrement important pour les ordinateurs. Nous ne pouvons pas communiquer avec les ordinateurs en utilisant le langage naturel, car la signification entière du langage naturel réside dans sa richesse et sa capacité d'expression. Lorsque vous exprimez des mots avec un ton légèrement différent ou en choisissant des manières légèrement différentes de les formuler, le sens de votre phrase ou de votre paragraphe peut complètement changer.

Dans les langages de programmation, il est le plus important d'avoir une sémantique définie avec précision. Lorsque vous écrivez un programme, vous savez exactement ce qu'il va faire. Si vous effectuez un léger ajustement, 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 un sens, puis être converti en d'autres formes de représentation, et il devrait alors avoir le même sens, jusqu'à ce qu'il atteigne le module de traitement de la machine.

Je pense qu'à la différence des langages naturels, l'essence des langages de programmation est de cibler des domaines spécifiques ou des tâches spécifiques. 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 de se concentrer sur la résolution de ces problèmes. Prenons par exemple le langage de programmation Rust que nous utilisons pour écrire la blockchain Sui et pour la plupart des autres systèmes travaillant 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 fils ou la concurrence, mais ne vous laisse pas commettre des erreurs comme le faisaient les langages précédents (comme le C ou le C++).

Ainsi, l'histoire de Move est très similaire. Lorsque je l'ai créé, ce n'était pas dans l'intention de 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é à la tâche 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 éducatives ?" Tout cela est très important, donc la barrière à l'entrée pour créer un nouveau langage doit être très élevée. Même si ce langage est meilleur en soi, s'il n'a pas ces facteurs, son avantage n'a pas de sens. Établir 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 conventionnel, comme WASM ou JVM, et l'appliquer à Libra ? Ou devrions-nous créer notre propre chose ?

La décision de créer nos propres choses est basée sur l'étude des smart contracts existants, de la compréhension de ce que les programmeurs essaient de faire et 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 construit pour ce que les gens font maintenant. Je ne veux pas le critiquer, car c'est le premier langage de smart contracts, et 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 peut pas fournir.

Donc, ces smart contracts sont très simples, ils font essentiellement deux choses. Ils définissent le type d'actif, y compris quand les actifs peuvent être transférés, ce que vous pouvez en faire, qui peut les lire, et les règles concernant qui peut les écrire. Et ils vérifient les politiques de contrôle d'accès pour déterminer qui possède cet actif, qui est autorisé à l'utiliser et qui est autorisé à agir dessus. Tout tourne autour de l'actif, vous souhaitez que ces actifs aient les mêmes caractéristiques que les actifs physiques. Si je vous confie quelque chose, alors vous devriez le posséder, et je ne le possède plus.

Les contrats intelligents contiennent les concepts de propriété et de transfert de propriété, mais sur un ordinateur, tout n'est que des chiffres et des octets, et peut être copié librement. De plus, vous savez que ces concepts n'existent pas dans le monde réel. Par conséquent, vous souhaitez avoir un langage capable de vous fournir une bonne abstraction sur la propriété et l'homogénéité. Comme dans le monde réel, mais sans obliger 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 souhaitons concevoir l'ensemble du langage 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 veulent écrire du code.

Q3, Sui utilise une variante de Move, appelée Sui Move. Qu'est-ce qui a poussé ces changements ? Quelles caractéristiques de Sui Move sont particulièrement adaptées à la construction de produits dans le 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. Par conséquent, nous avons essayé de concevoir Move comme un langage universel. Mais nous avons également fait certaines choses de manière consciente, 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 définissent certaines règles lors de la création du compte, par exemple, le propriétaire du compte doit passer par une certification KYC. Ou il pourrait être nécessaire de payer des frais pour créer un compte, ou cela ne pourrait être fait que par une petite partie des personnes ayant le droit de créer des comptes. É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 exactement le contraire. Vous ne souhaitez pas être conforme au niveau de la base, c'est le concept des smart contracts. Vous souhaitez que les choses soient aussi libres que possible, vous devez pouvoir 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 soyons concentrés sur les actifs dans Move, à l'époque, nous ne considérions pas comment introduire l'accent sur les actifs dans la transaction elle-même au sein de Libra. Ainsi, lorsque vous arrivez au niveau de la transaction, vous n'avez toujours que cette API, où vous saisissez des nombres et des valeurs booléennes, etc., qui ne sont pas des actifs, puis dans Move, vous utilisez ces nombres 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 consiste en ce travail de registre ennuyeux, qui implique de retirer cette chose, de retirer cela, de retirer autre chose, d'accord, j'ai tous les actifs que je veux. Ils sont ici, dans mon studio, 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 ? Par conséquent, la logique utilisée pour traiter les transactions sera effectuée par les programmeurs. Du point de vue des programmeurs, ils n'ont qu'à préparer les actifs nécessaires et peuvent immédiatement commencer à 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 avions un modèle de données basé sur les comptes, les actifs étant stockés sous les comptes, et les programmeurs devaient les extraire explicitement. Dans Sui, lorsque nous entrons dans la partie Move de la transaction, les actifs ont déjà été récupérés par le runtime de Sui. Cela est plus pratique pour les programmeurs, car ils n'ont pas à 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, d'effectuer une mise à l'échelle horizontale de Sui et d'effectuer plus efficacement certaines autres opérations sans les exécuter réellement.

Nous avons également réalisé d'autres travaux très intéressants, comme l'utilisation de modèles de données orientés objet pour des blocs de transactions programmables. C'est un sujet plutôt technique, et je serais ravi d'en discuter en profondeur. Mais ces deux facteurs sont les principales motivations qui ont conduit aux divergences avec le Move original.

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

J'aime utiliser une analogie pour expliquer, d'autres blockchains sont comme un hall de restauration dans un centre commercial. Si vous souhaitez manger une glace, vous allez au stand de glaces et sortez votre carte de crédit pour payer. Mais si vous décidez que vous voulez aussi un hamburger, alors 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. Et Sui est plus comme un buffet, chaque transaction n'est pas juste une seule chose. Une fois que vous avez payé le prix 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 un peu plus concret, dans un cas simple, si vous devez envoyer 100 transactions pour frapper 100 NFT, vous pouvez envoyer une seule transaction pour frapper 100 NFT. Le coût de cela est presque identique à celui de frapper 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-signature, 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 cool, 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 la façon dont le portefeuille multi-signature ou 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.

Les blocs de transaction programmables sont composés 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 de son origine, puis transmettre sa sortie à l'objet qui en a besoin, sans vous soucier non plus de l'endroit où elle sera transmise. Dans d'autres blockchains, la couplage est plus fort, donc le jeu doit être intégré à 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 facilite la formation de ce qu'on appelle des combinaisons temporaires. Comme si le canal correspond, nous pouvons terminer 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 comprennent des frais de gas plus bas, car vous pouvez regrouper toutes les opérations en une seule transaction, au lieu de réaliser 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 toutes les opérations seront effectuées en une seule fois. Un autre avantage est l'atomicité : si vous souhaitez effectuer trois actions différentes et que vous souhaitez que la troisième ne réussisse que si les deux premières réussissent, vous ne pourrez pas y parvenir si ces opérations doivent être des transactions indépendantes. Cependant, si vous pouvez toutes les inclure dans une seule transaction, alors vous pouvez facilement y parvenir.

Q6, j'ai entendu vous et d'autres parler du fait que développer 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 nouveaux 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 quelque chose de très cool sur Sui.