Entretien avec le père du langage Move : Move bénéficie d'un avantage de postériorité, la blockchain étant fondamentalement une technologie visant à éliminer les frictions
TechFlow SélectionTechFlow Sélection
Entretien avec le père du langage Move : Move bénéficie d'un avantage de postériorité, la blockchain étant fondamentalement une technologie visant à éliminer les frictions
Pour les développeurs provenant d'autres langages de programmation Web3, l'expérience de développement sur Move et Sui Move est effectivement plus efficace et plus sécurisée.
Dédié à des analyses Web3 approfondiesRécemment, nous avons discuté avec Sam Blackshear, directeur technique de Mysten Labs et créateur du langage de programmation Move, sur les raisons pour lesquelles il a développé Sui Move, un nouveau langage de contrats intelligents, les fonctionnalités évolutives de Sui et les avantages des technologies décentralisées pour les développeurs.
Voici le contenu de cet entretien :
01. Pour commencer, pouvez-vous expliquer ce qu’est un langage de programmation, quelles sont les qualités que les développeurs recherchent lorsqu’ils choisissent un langage, et qu’est-ce qui vous a poussé à créer votre propre langage ?
Un langage de programmation est simplement un outil convivial, sûr, efficace et précis pour interagir avec un ordinateur, ce qui est particulièrement crucial pour la machine. Nous ne pouvons pas utiliser le langage naturel pour communiquer avec un ordinateur, car l’intérêt même du langage naturel réside dans sa richesse expressive. Une légère variation de ton ou de choix lexical peut radicalement changer le sens d’une phrase ou d’un paragraphe.
Dans un langage de programmation, ce qui compte avant tout, c’est une sémantique rigoureusement définie. Quand vous écrivez un programme, vous savez exactement ce qu’il fera. Si vous y apportez une petite modification, vous comprenez clairement l’effet de ce changement. Cette cohérence doit être maintenue à tous les niveaux : lorsque vous écrivez du code source, celui-ci a une signification donnée, puis il est transformé en d’autres représentations – cette signification doit rester inchangée jusqu’à ce qu’il atteigne le module de traitement de la machine.
J’estime que, contrairement au langage naturel, un langage de programmation est essentiellement conçu pour un domaine ou une tâche spécifique. Sinon, un seul langage suffirait pour tout faire. Mais il existe de nombreux langages parce qu’aucun ne peut exceller partout. Chaque langage vise plutôt un domaine particulier et se concentre sur ses problèmes spécifiques. Prenons par exemple Rust, le langage utilisé pour développer la blockchain Sui et bon nombre d’autres projets système chez Mysten. Il est optimisé pour produire du code rapide, performant et sécurisé. Il permet d’accéder aux détails bas niveau comme la mémoire, les threads ou la concurrence, sans les pièges courants des langages précédents comme C ou C++.
L’histoire de Move suit une logique similaire. Lorsque je l’ai créé, ce n’était pas dans le but initial de concevoir un nouveau langage. Vous avez mentionné ce que les développeurs cherchent dans un langage : « Ce langage convient-il à ce que je veux accomplir ? » Mais encore plus important, selon moi, c’est : « A-t-il une grande communauté ? Y a-t-il beaucoup de bibliothèques disponibles ? De nombreux développeurs l’utilisent-ils ? Existe-t-il de bonnes ressources pédagogiques ? » Tous ces éléments sont cruciaux. Créer un nouveau langage nécessite donc un seuil très élevé : même s’il est techniquement meilleur, son avantage devient insignifiant s’il manque ces conditions. Construire une communauté vaste et dynamique à partir de zéro est extrêmement difficile.
02. Pouvez-vous en dire plus sur le développement de Move ?
Move trouve son origine dans le projet Libra de Facebook. Ma mission initiale n’était pas de créer un nouveau langage, mais plutôt : « Libra a besoin de contrats intelligents ; trouvons la meilleure solution. » J’ai examiné plusieurs options : pouvions-nous utiliser Solidity dans une EVM ? Devrions-nous adopter un langage universel classique comme WASM ou JVM pour Libra ? Ou fallait-il concevoir notre propre solution ?
Le choix de créer notre propre langage s’est fondé sur l’étude des contrats intelligents existants, afin de comprendre ce que les développeurs tentaient de faire, où certains langages les aidaient, et où ils les laissaient tomber. Ma conclusion fut que, dans bien des cas, les langages actuels les décevaient vraiment.
Cela transparaît clairement dans le bilan désastreux de Solidity en matière de sécurité. Plus fondamentalement, les contrats intelligents ne sont pas des programmes traditionnels. Solidity n’a pas été conçu pour les usages auxquels on l’emploie aujourd’hui. Je ne critique pas Solidity — c’était le premier langage de contrats intelligents, et personne ne savait alors à quoi il serait utilisé. Mais une fois qu’on observe les besoins réels des utilisateurs, il devient évident qu’un autre ensemble d’abstractions et d’outils de programmation était nécessaire, que Solidity ne fournit pas.
Ces contrats intelligents sont très simples : ils font essentiellement deux choses. Ils définissent des types d’actifs, incluant les règles sur leur transfert, leurs utilisations possibles, qui peut les lire ou les modifier. Et ils vérifient les politiques de contrôle d’accès : qui possède l’actif, qui est autorisé à l’utiliser ou à y effectuer des opérations. Tout tourne autour des actifs. On souhaite que ceux-ci aient les mêmes propriétés que les objets physiques : si je vous donne quelque chose, vous le possédez, et je ne l’ai plus.
Les contrats intelligents manipulent des notions de propriété et de transfert, mais dans un ordinateur, tout n’est que chiffres et octets, librement copiables. Ces concepts n’existent pas nativement dans le monde numérique. D’où la nécessité d’un langage fournissant de bonnes abstractions pour la propriété et l’unicité, comme dans le monde réel, sans obliger les programmeurs à les réinventer à chaque fois. On veut des garanties de sécurité de base intégrées.
C’est précisément le rôle de Move, et la raison pour laquelle nous avons fini par créer ce nouveau langage. Ces fonctionnalités sont fondamentales pour la programmation des contrats intelligents. Elles sont difficiles à recréer dans d’autres langages, y compris les langages existants de contrats intelligents. Nous avons donc choisi de concevoir un langage entier autour de ces fonctions de base, afin que les développeurs puissent écrire du code de manière sûre et efficace, sans avoir à réinventer la roue à chaque nouvelle fonctionnalité.
03. Sui utilise une variante de Move appelée Sui Move. Quels facteurs ont motivé ces modifications ? Quelles caractéristiques de Sui Move sont particulièrement adaptées à la construction de produits dans Web3 ?
Plusieurs facteurs ont conduit à ces changements. Le projet initial Libra visait à construire un réseau de paiement conforme à la réglementation. Nous avons donc conçu Move (https://docs.sui.io/learn/sui-move-diffs) comme un langage généraliste, mais en intégrant volontairement certaines limitations propres à Libra. Par exemple, on ne souhaitait pas permettre d’envoyer certains actifs n’importe où. On voulait obliger la création explicite de comptes, avec des règles fixées dès le départ : le propriétaire devrait passer une vérification d’identité (KYC), payer des frais, ou seul un petit groupe d’utilisateurs autorisés pourrait créer des comptes. Étant donné que Libra visait des paiements et contrats intelligents conformes, ces restrictions avaient du sens. Mais dans le domaine plus large de Web3, c’est l’inverse : on ne veut pas imposer de conformité au niveau de base. C’est justement l’idée des contrats intelligents : maximiser la liberté, pouvoir envoyer un objet vers n’importe quelle adresse. La création explicite de comptes bloquerait trop d’usages. Voilà un facteur clé.
Un autre facteur : même si Move était centré sur les actifs, dans le cadre de Libra, nous n’avions pas pensé à intégrer cette notion d’actif directement dans les transactions. Au niveau transactionnel, on avait toujours une API classique, prenant des nombres, booléens, etc., des données non liées aux actifs. Ensuite, dans Move, on utilisait ces valeurs pour extraire des actifs depuis les comptes et effectuer des opérations. Or, une grande partie du code exécuté consistait en une fastidieuse gestion administrative : sortir ceci, sortir cela, récupérer cet autre élément… « Bon, j’ai maintenant tous les actifs dont j’ai besoin. Ils sont là, dans mon espace de travail. Maintenant, je peux enfin faire quelque chose d’intéressant. » À la fin, on remettait les actifs dans leurs comptes respectifs, en les réorganisant.
Dans Sui, nous nous sommes demandé : puisque chaque programme commence et finit ainsi, pourquoi ne pas automatiser ce processus ? La logique de traitement des transactions peut réaliser cette opération pour le développeur. Du point de vue du programmeur, il suffit de disposer des actifs nécessaires pour démarrer immédiatement le travail utile. C’est ce qu’on appelle le modèle de données orienté objet présent dans Sui. Dans Move original, on avait un modèle basé sur les comptes : les actifs étaient stockés sous un compte, et le développeur devait les extraire explicitement. Dans Sui, le runtime Sui récupère automatiquement les actifs avant que la partie Move de la transaction ne commence. C’est bien plus pratique pour le développeur, qui n’a plus à gérer cette gestion préliminaire et finale. C’est aussi la clé qui permet de déterminer, sans exécuter la transaction, si elle peut être exécutée en parallèle avec une autre, rendant Sui horizontalement évolutif et plus efficace pour d’autres opérations.
Nous avons également travaillé sur d’autres aspects intéressants, comme les blocs de transactions programmables grâce au modèle orienté objet. C’est un sujet technique, mais je serais ravi d’en parler plus en détail. Ces deux facteurs sont les principaux moteurs des différences entre Sui Move et Move d’origine.
04. Pourriez-vous en dire plus sur les blocs de transactions programmables et leurs fonctionnalités ?
J’aime utiliser une analogie : d’autres blockchains ressemblent à une zone de restauration dans un centre commercial. Vous voulez une glace ? Vous allez au stand de glaces, vous payez avec votre carte. Si vous décidez ensuite de prendre un hamburger, vous allez au stand suivant, vous payez à nouveau. Personnellement, je ne suis pas gourmand, mais si je veux huit choses différentes, je dois faire huit transactions séparées. Sui, lui, ressemble davantage à un buffet : une transaction peut contenir plusieurs actions. Une fois que vous avez payé pour le buffet, vous pouvez faire beaucoup de choses sans frais supplémentaires. Vous pouvez prendre de la glace, un hamburger, les mélanger.
Pour rendre cela plus concret, dans un cas simple, si vous envoyez 100 transactions pour frapper 100 NFT, vous pouvez désormais envoyer une seule transaction qui frappe les 100 NFT. Le coût sera presque identique à celui d’un seul NFT. Vous pouvez aussi combiner des transactions hétérogènes : la première transaction sort un personnage Mario de votre portefeuille multisignature, la deuxième lance une requête pour obtenir Mario, ce qui vous permet de jouer. Si vous gagnez et obtenez un trophée, une troisième transaction peut placer ce trophée dans une vitrine partagée avec un ami. L’aspect remarquable est que les blocs de transactions programmables permettent aux développeurs d’écrire du code sans que le jeu ait besoin de connaître le portefeuille multisignature, ni la manière dont Mario est stocké, ni la vitrine ou son implémentation.
Un bloc de transactions programmable est constitué de transactions ayant des objets d’entrée et de sortie. Si vous avez besoin d’un objet d’entrée, vous l’obtenez sans vous soucier de son origine, puis vous transmettez sa sortie à l’élément qui en a besoin, sans savoir où il ira. Sur d’autres blockchains, le couplage est plus fort : le jeu doit s’intégrer au portefeuille et à la vitrine, ou tous doivent implémenter une interface commune, ce qui crée une forte dépendance. Sui facilite ce qu’on appelle la composition temporaire : tant que les interfaces correspondent, on peut tout faire dans une seule transaction.
05. Quels sont les avantages des blocs de transactions programmables pour les utilisateurs ?
Pour les utilisateurs, les bénéfices incluent des frais gas réduits, car toutes les opérations sont regroupées dans une seule transaction. En outre, le nombre d’autorisations nécessaires diminue : si votre système exige une validation, vous n’en faites qu’une, et tout s’exécute d’un coup. Un autre avantage est l’atomicité : si vous souhaitez effectuer trois actions différentes, et que la troisième ne doit réussir que si les deux premières ont réussi, cela est impossible avec des transactions indépendantes. Mais si elles sont dans une même transaction, c’est facile à réaliser.
06. J’ai entendu dire, par vous et d’autres, que développer sur Sui est une excellente expérience pour les programmeurs, et que cela compte. Avez-vous des anecdotes à partager concernant les développeurs expérimentés ou nouveaux en Web3 qui commencent avec Sui Move ?
Pour les développeurs venant d’autres langages Web3, leur expérience avec Move et Sui Move est nettement plus efficace et plus sûre. J’ai récemment participé à un podcast sur Bucket Protocol, qui construit un projet DeFi très innovant sur Sui. En présentant leur architecture, ils ont expliqué comment les composants interagissent. Ils ont dit que s’ils avaient utilisé Solidity, cela aurait pris environ huit mois, mais avec Sui Move, seulement deux mois, et ils ont une grande confiance dans la sécurité du code. Le langage correspond parfaitement à leur vision mentale du projet. Avec Solidity, ce lien n’est pas aussi direct.
Ce n’est qu’un exemple, mais nous entendons souvent ce type de retour : les gens vont plus vite, et ont plus confiance une fois terminé. Cela me rend heureux. Mais d’une certaine manière, ce n’est pas surprenant : nous avons étudié Solidity, identifié ses problèmes, et conçu intentionnellement Move pour être plus sûr et plus rapide. Nous avons observé ce que les développeurs essaient de faire, et conçu un langage adapté à leurs besoins, plutôt que de coller à des standards existants. Ce langage résout les problèmes réels rencontrés, donc quand ils passent dessus, ils l’apprécient vraiment.
On parle souvent d’avantage du premier entrant, mais ici, c’est plutôt l’avantage du dernier arrivé qui compte.
Exactement.
07. Vous avez déjà évoqué les caractéristiques orientées objet de Sui Move et de Sui en général. Pourriez-vous expliquer plus clairement le lien entre la conception de Sui Move et la capacité de Sui à permettre une adoption massive de Web3, avec faible latence, faible coût et extensibilité ?
Un point auquel nous sommes très attentifs chez Sui, et qui pose problème à d’autres plateformes, est la limite de capacité. Que ce soit 15 transactions par seconde (TPS) comme Ethereum, ou 100, 1 000 — si c’est un chiffre fixe, quand la plateforme devient trop populaire, elle atteint sa limite. Alors, l’expérience de tous se dégrade. S’il n’y a que 1 000 places, il faut choisir les 1 000 plus importantes, par enchères gas ou autre. Pour tout le monde, le prix du gas augmente, la latence croît, ou les deux. Beaucoup d’usages sont exclus, car seuls ceux prêts à payer le plus haut prix réussissent. Les autres doivent partir ou attendre. Ce n’est pas acceptable.
L’objectif de Sui est l’évolutivité horizontale. Avec une quantité donnée de matériel, on obtient un certain débit. Si on a besoin de plus, les nœuds validateurs peuvent ajouter du matériel — il n’y a pas de plafond. C’est ainsi que fonctionnent tous les services Web2. Bien sûr, il y a des contraintes techniques à résoudre, ce n’est pas trivial, mais toute conception de service Web évolutif vise cela.
Si Sui attire plus d’utilisateurs, notre objectif est qu’il continue à croître sans problème, tout en gardant une latence très faible. On ne veut pas sacrifier la latence pour augmenter le débit.
Dans Libra, ces aspects n’étaient pas pris en compte. C’était un petit système de paiement, avec quelques centaines d’opérateurs, peut-être des dizaines de millions de transactions par jour, pas plus. Nous avons donc adopté une architecture monolithique, plus simple et suffisante. Mais pour Sui, nous savions que cette approche ne marcherait pas, car elle n’est pas horizontalement évolutible. Nous avons donc repensé tout depuis zéro. D’où vient le modèle orienté objet ? Nous avons abandonné le modèle basé sur les comptes, car il rend l’évolutivité horizontale extrêmement difficile. En revanche, si tout est organisé en objets, l’état global devient une simple table de hachage associant ID d’objet → objet. C’est un stockage clé-valeur, que nous savons évoluer — c’est un problème d’ingénierie classique.
Ensuite, la question est : comment concevoir une structure de transaction compatible avec la lecture/mise à jour dans un tel stockage ? Comment fragmenter ce stockage ? Où traiter chaque transaction ? C’est là que tout commence. Nous savons comment évoluer ces composants. Comment les transformer en un système avec des propriétés de blockchain : lectures vérifiables, compatibilité avec Move, etc. Et comment les assembler harmonieusement.
08. À un niveau plus élevé, comment abordez-vous avec les développeurs Web2 sceptiques le potentiel des technologies décentralisées ?
Je pense que les blockchains et les cryptomonnaies sont fondamentalement des technologies qui réduisent les frictions. Il existe des obstacles qui rendent les transactions financières, la création d’applications ou l’échange d’informations très compliqués, car les données ne peuvent pas traverser ces barrières sans l’aide d’un tiers, qui facture pour ce service.
Un exemple classique est l’achat immobilier. Il y a un acheteur et un vendeur, mais lors du paiement, un notaire ou agent de fiducie est nécessaire, qui ne fait rien d’autre que garder l’argent, car les deux parties ne se font pas confiance. C’est la réalité. Mais si cet intermédiaire pouvait être remplacé par du code accessible aux deux parties, ou validé par un tiers, cette tâche pourrait être accomplie gratuitement ou à moindre coût. Le but de la blockchain n’est pas d’éliminer les agents immobiliers, mais c’est un exemple typique de friction que l’on peut réduire.
Imaginez qu’il n’y ait plus de barrière d’interopérabilité entre l’application A et B, car elles reposent sur la même infrastructure. Vous pouvez alors faire circuler librement objets, données, promotions croisées, ou créer des produits tiers combinant les deux. Ou imaginez Internet : les sites partagent des données via des cookies, mais ceux-ci ne sont que des métadonnées en lecture seule. Et si ces cookies pouvaient être monétisés ? Devenir des objets utilisables ? Des coupons ou des programmes de fidélité intégrés ? Tout aurait cette fonctionnalité. C’est très abstrait, mais c’est là que réside le potentiel. Pour un développeur, ce sont de nouvelles super-pouvoirs pour créer des applications plus attractives.
09. Concernant les utilisateurs finaux, même s’ils n’ont pas de compétences techniques, ressentent-ils une certaine hésitation face à l’idée de faire confiance au code, même si l’alternative est une grande entité centralisée opaque ?
Je ne pense pas. Car nous faisons cela tous les jours, non ? Quand je me connecte à mon email, je ne crains pas que le code supprime un message ou empêche l’envoi. Si cela arrivait, j’arrêterais d’utiliser ce service ou changerais de fournisseur. C’est très similaire. Bien sûr, tout le monde ne peut pas inspecter le code, mais certains le peuvent. Et surtout, la transparence est un élément clé. Même si je voulais vérifier le code de mon email, je ne le peux pas — il n’est pas accessible. Donc, la transparence compte. Certains peuvent faire des audits ponctuels. Combinée à la réutilisation et à l’immuabilité, c’est ici que réside la différence. Quand je me connecte à mon email, je ne sais pas si le code a changé depuis ma dernière utilisation. Il n’y a aucune transparence là-dessus. En revanche, dans Web3, cette transparence existe — et ailleurs, non.
10. Quels sont vos espoirs pour l’évolution future de Sui Move ?
Nous nous concentrons actuellement sur de nombreuses fonctionnalités inspirées de nos échanges avec les développeurs ayant publié les premiers packages Sui Move, observant comment ils souhaitent les faire évoluer, quels aspects sont faciles ou difficiles à modifier. Sui Move est excellent pour publier un package initial, mais quand on veut modifier un type, ajouter des champs ou des fonctions, tout en restant cohérent sans trahir la confiance des utilisateurs initiaux, cela devient très complexe. Notre travail consiste à étudier ce problème et à identifier quelles fonctionnalités linguistiques peuvent offrir à la fois flexibilité aux développeurs et maintenir la confiance des utilisateurs.
Nous travaillons sur plusieurs fonctionnalités liées, notamment les types énumérés. Nous améliorons aussi fortement l’expérience de connexion entre Move et le code frontend. Nous plaisantons souvent en disant qu’une application Sui typique est composée de 5 % de code Move et 95 % de code frontend. Nous accordons donc une grande attention à ce 95 %. Nous parlons beaucoup de Move, mais nous nous efforçons aussi de rendre les autres parties plus efficaces et la liaison plus simple. Globalement, nous souhaitons que les applications intègrent davantage de Move pour plus de sécurité, tout en rendant ce 95 % de code accessible, que ce soit pour les programmeurs Move ou non.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Sui Network
