a16z dialogue avec le père du langage Move : pourquoi Move est-il une direction clé pour l'avenir des contrats intelligents, à partir du langage de programmation ?
TechFlow SélectionTechFlow Sélection
a16z dialogue avec le père du langage Move : pourquoi Move est-il une direction clé pour l'avenir des contrats intelligents, à partir du langage de programmation ?
L'année dernière, une foule d'institutions dont a16z ont fortement promu des blockchains publiques Move comme Sui, relançant ainsi la popularité du langage Move depuis les cendres de Meta Diem.
Dédié à des analyses Web3 approfondiesTraduction : Sui World
L'année dernière, des institutions comme a16z ont fortement promu les blockchains publiques Move telles que Sui, relançant le langage Move depuis les cendres de Meta Diem. Cependant, dès l'apparition de Sui Move, des voix critiques n’ont cessé de s’élever :
Si le seul fait que le langage Move puisse être meilleur que Solidity ou d'autres langages de développement implique-t-il nécessairement la création d'une nouvelle blockchain de couche 1 et de tout reconstruire à zéro ?
Récemment, l'équipe a16z Crypto a mené un podcast intitulé « Programming Languages & Crypto » avec Sam Blackshear, cofondateur et CTO de Mysten Labs, père du langage Move, afin d’explorer pourquoi Move représente une direction essentielle pour l’avenir des contrats intelligents.
Au cours de cet épisode, a16z Crypto et Sam Blackshear ont discuté des différences et similitudes entre les langages de programmation traditionnels et ceux des contrats intelligents, débattant des contraintes et opportunités uniques des blockchains, abordant la philosophie de conception du langage Move, la programmation orientée objet et actif, la sécurité, ainsi que des sujets tels que la vérification formelle, la gouvernance, les outils communautaires et l’adaptabilité interplateformes.
Les points principaux abordés incluent :
1. Histoire des langages de programmation et des contrats intelligents
De la programmation classique à celle des contrats intelligents, puis à Move. Move est l’un des premiers langages conçus spécifiquement pour répondre aux besoins de systèmes de types, de typage statique et de vérifications à la compilation.
2. L’innovation des contrats intelligents Move
La machine virtuelle Ethereum (EVM) s’adapte excessivement aux détails d’implémentation d’Ethereum. Les développeurs héritent ainsi de nombreuses décisions de conception propres à Ethereum, y compris certaines erreurs qui entravent sa scalabilité.
Move, quant à lui, n’intègre aucun élément spécifique à une blockchain dans son langage central. Les innovations au niveau du code source seront cruciales. Move permet en fin de compte d’offrir une protection via des vérificateurs de code et au niveau de la machine virtuelle contre les attaques d’autres programmeurs.
3. La philosophie derrière Sui Move
Move est un langage exécutable basé sur du bytecode, destiné à l’exécution de transactions utilisateur et de contrats intelligents. Avec Sui Move, les validateurs peuvent paralléliser efficacement, rendant le stockage et l’exécution plus simples sans avoir à coder ces aspects au niveau du protocole ni obliger les utilisateurs et développeurs à y réfléchir.
4. La sécurité
Dans l’univers des contrats intelligents, nous sommes dans un état de contrainte extrême. Nous écrivons très peu de code, mais il doit être parfait. La sécurité doit être la priorité absolue. Move vise non seulement à empêcher les erreurs auto-infligées des programmeurs, mais aussi à leur fournir les primitives adéquates pour se défendre contre les attaques.
5. Programmation orientée objet et actif
Move est conçu comme un langage de programmation de contrats intelligents orienté objet et actif, car la plupart des langages Web2 orientés objet fonctionnent ainsi. Dans Sui Move, placer l’objet au centre encourage une représentation fine et précise des accès granulaires. La structure du stockage global dans Sui Move est une correspondance d’identifiants d’objets vers des objets.
6. Comparaison de sécurité
Move élimine par construction les problèmes de réentrance et de vérification manquante des permissions dans la programmation des contrats intelligents. Les informations de propriété d’un objet sont stockées dans ses métadonnées — un aspect que le programmeur ne peut pas contrôler. Le Move Prover est conçu précisément pour éviter les erreurs courantes lors de l’écriture de contrats intelligents, aidant ainsi les développeurs à éviter de nombreuses erreurs fondamentales.
7. Gouvernance des langages de contrats intelligents
Initialement développé chez Facebook, Move n’avait aucune gouvernance réelle. Nous faisons preuve d’une grande prudence dans l’extension du langage. La simplicité prime, mais nous continuons activement à l’étendre. Sam Blackshear a une vision claire : Move doit être un langage interplateforme, dont les fonctions de base restent applicables quel que soit le réseau, accessible tant aux experts des contrats intelligents qu’aux nouveaux venus du Web2, offrant une flexibilité maximale.
8. Conseils aux développeurs
Lisez beaucoup de code, c’est la meilleure façon de comprendre un langage. Partagez vos connaissances, approfondissez les discussions, et trouvez des personnes qui aiment partager leur code et construire ensemble une communauté open source. Apprenez le fonctionnement de chaque outil qui peut simplifier votre travail.
Voici ci-dessous la transcription complète du podcast, environ 25 000 mots, lecture estimée à 30 minutes.
Introduction par l’animatrice Sonal Chokshi
Bienvenue dans Web 3.0, l’émission produite par l’équipe a16z Crypto sur la construction de la prochaine génération d’internet. Je suis votre animatrice, Sonal Chokshi.
Ce programme vise à aider toute personne souhaitant comprendre ou approfondir les sujets liés à la cryptographie et au Web 3.0 — développeurs, créateurs, architectes, dirigeants d’entreprise ou décideurs politiques. Nous lançons aujourd’hui une nouvelle saison. Ce nouvel épisode traite des langages de programmation et de la cryptomonnaie, adapté aussi bien aux programmeurs expérimentés qu’à ceux qui souhaitent intégrer ce domaine. Il intéressera également ceux curieux de l’évolution des langages de programmation.
Notre invité exceptionnel aujourd'hui est Sam Blackshear, cofondateur et CTO de Mysten Labs, entreprise qui pose les bases d’un futur décentralisé pour le Web 3.0. Sam possède une solide expérience en langages de programmation, depuis son doctorat jusqu’à son passage chez Facebook, puis en tant qu’auteur du langage Move, un langage open source dédié à la construction de contrats intelligents. Nous en parlerons davantage.
Nous accueillons également durant tout l’épisode Noah, ingénieur spécialisé en recherche de contrats intelligents chez a16z Crypto, qui a récemment développé avec un collègue Helios, un client léger pour Ethereum, remportant un défi difficile d’optimisation de gaz.
Nous avons aussi invité Eddy Lazzarin, responsable technique chez a16z Crypto. Avant cela, Eddy travaillait chez Netflix en ingénierie logicielle, puis chez Facebook en ingénierie et science des données. Rappelons que les propos tenus ici ne constituent ni un conseil financier, commercial, juridique ni fiscal.
1. Histoire de la programmation et des contrats intelligents
Animatrice Sonal Chokshi :
Commençons par l’histoire de la programmation traditionnelle. Première intervention de Noah, puis Sam Blackshear et Eddy.
a16z Crypto Noah :
Nous aimerions comprendre comment l’histoire de la programmation classique a influencé celle des contrats intelligents, car je pense qu’il existe trois éléments distincts : la programmation classique, celle des contrats intelligents, et le langage Move. Ces trois domaines ont chacun leur propre histoire, n’est-ce pas ?
Sui CTO Sam Blackshear :
Exactement, j’aime cette approche. On crée souvent des langages pour leur syntaxe ou pour plaire, ce qui est valable, mais ce n’est pas tout. J’apprécie donc cette vision globale.
a16z Crypto Eddy Lazzarin :
Sur cette base, la programmation traditionnelle a connu diverses tendances au cours des deux ou trois dernières décennies. Les langages classiques ont évolué, certains sujets passant à la mode puis disparaissant. Pendant longtemps, les langages dynamiques et les vérifications de type souples ont été très populaires. On pensait alors qu’il était plus ergonomique de simplement écrire du code sans se soucier des types ni des détails techniques.
Sui CTO Sam Blackshear :
Mais récemment, on réfléchit davantage aux systèmes de types, au typage statique et aux vérifications à la compilation, afin de mieux comprendre un programme avant son exécution. Ces tendances changent constamment. Pourtant, concernant la programmation des contrats intelligents, étant donné son caractère si nouveau, nous n’avons pas encore vu émerger une telle histoire. C’est très différent.
Je pense que Move constitue l’une des premières preuves concrètes de la conception d’un langage adapté à ces exigences (système de types, typage statique, vérifications à la compilation). J’aimerais savoir quels changements nous attendons, par exemple sur les thèmes du typage statique et dynamique dans la programmation des contrats intelligents ? Ces sujets n’ont peut-être pas encore émergé parce qu’actuellement, il n’existe qu’un seul langage dominant : Solidity.
Animatrice Sonal Chokshi : Alors, comment cela se relie-t-il au passage aux contrats intelligents ? Encore une fois, Sam, à vous.
Sui CTO Sam Blackshear :
Dans l’espace des contrats intelligents, l’EVM a été l’un des premiers entrants. Personne ne savait vraiment quoi faire avec les contrats intelligents, ni comment les écrire. Ainsi, la flexibilité semblait primordiale pour explorer les cas d’usage. Aujourd’hui, je pense que nous savons déjà, ou du moins avons une idée des briques de base.
Les contrats intelligents sont extrêmement spécialisés : définir des modèles d’actifs, des stratégies de transfert, vérifier les contrôles d’accès et les autorisations.
C’est fondamental. On n’utilise pas un langage de contrats intelligents pour écrire un compilateur ou un système d’exploitation. Ils excellent donc particulièrement là où ils surpassent les langages généralistes.
Je pense que beaucoup sous-estiment que même le standard ERC-20 est apparu longtemps après que l’EVM pouvait être programmée, et que l’EVM était déjà considérée comme l’un des blocs fondamentaux d’Ethereum. Je ne vois aucune preuve évidente que ces éléments de base étaient clairs auparavant.
Donc, vous avez raison, on peut désormais considérer le typage comme acquis. Je pense que contourner le typage implique une dette technique acceptable. Si le projet est petit, que l’on veut avancer vite et que le code sera jeté ensuite, cette dette technique est tolérable. Mais, quand la taille devient très importante, avec de nombreux contributeurs modifiant le code sans connaître pleinement les conséquences, intégrer le typage permet d’imposer des obstacles explicites plutôt que de créer accidentellement des barrières invisibles que d’autres heurteront plus tard.
Par exemple, comme vous l’avez mentionné, empêcher la copie ou fixer un approvisionnement maximal d’un actif. Ces contraintes sont cruciales, indépendamment de l’échelle du projet. Elles sont essentielles à l’intégrité et à la sécurité du projet. Connaître ces limites signifie que vous pouvez maintenant concevoir un langage de programmation capable de les imposer. C’est ainsi que je perçois le langage Move.
À mesure que nous identifions les types de contraintes nécessaires pour faire les choses correctement, nous pouvons désormais les intégrer directement au langage. Je pense donc qu’il y a effectivement un lien avec le typage, comme vous le soulignez.
Vous avez mentionné que le typage est crucial pour l’intégrité et la sécurité des programmes. Vous dites que le typage dynamique convient peut-être aux petits projets, mais qu’il faut passer au typage statique à mesure qu’ils grandissent. Je suis un peu en désaccord : je pense que le typage entièrement statique pourrait être encore plus approprié. C’est peut-être une vue novatrice. Cela vise l’intégrité du programmeur. Ce que j’ai vu de plus effrayant, c’est lorsque j’appuie sur mon raccourci « control k » et que ça m’indique la signature de la fonction. En Python, cela me terrifie. Je regarde la signature et ne vois que les noms des paramètres. Et je me demande : que dois-je faire exactement ?
a16z Noah : Je n’arrive pas à croire que certaines personnes acceptent d’écrire du code qu’elles ne reliront jamais.
a16z Eddy Lazzarin : Ils partent du principe implicite qu’ils peuvent garder en tête les exigences du système.
a16z Noah : Même pour un programme de 100 lignes, je trouve cela impossible.
Sam Blackshear : Cela peut fonctionner, mais ce n’est pas parfait.
a16z Eddy Lazzarin :
Je pense que vous avez raison. Et cette mentalité a évolué. Autrefois, les systèmes de types protégeaient le programmeur contre ses collègues. Quand votre startup grossit trop, cela devient utile. Mais maintenant, c’est surtout pour me protéger moi-même.
Dans le contexte des contrats intelligents, cela me protège contre les attaquants. C’est une vraie différence, car dans un programme classique, vous ne déployez pas en supposant que l’attaquant est limité par le système de types. L’attaquant peut utiliser un autre langage ou écrire du code machine. Vous devez juste protéger votre propre pare-feu. Ici, mon bel objet typé traverse le code de l’attaquant tout en conservant son intégrité. Le système de types doit garantir ma sécurité.
Comme vous le dites, c’est un outil formidable qui impose des besoins différents : empêcher la copie, par exemple. Ce n’est pas quelque chose à considérer dans un système de types classique, ni empêcher la suppression ou garantir une utilisation ou destruction particulière. Tout cela découle de notre travail sur les contrats intelligents et de la volonté de fournir des systèmes de types significatifs, que nous intégrons dans Move et peut-être dans les futurs langages de contrats intelligents.
Animatrice Sonal Chokshi :
En réalité, parlons davantage des autres différences entre programmation classique et programmation de contrats intelligents. Avant d’aller plus loin, pourriez-vous rapidement présenter les langages disponibles aux programmeurs de contrats intelligents ? Il me semble important d’avoir une vue d’ensemble, de comprendre l’état actuel — Solidity, Viper, etc. Cela nous aidera à démarrer plus vite.
Sui CTO Sam Blackshear :
Oui, fondamentalement, si vous voulez écrire des contrats intelligents, vous utilisez presque toujours Solidity, sauf si vous êtes dans l’un des quelques autres écosystèmes plus petits.
Dans l’écosystème Polkadot, vous utilisez ink! (note de Sui World : ink! est un langage de contrats intelligents développé par Parity, permettant d’écrire des contrats en Rust et de les compiler en code Wasm). Sur StarkNet, vous utilisez Cairo (note de Sui World : Cairo est l’un des langages de programmation du système de preuves STARK).
Mais dans la majorité des cas, si je devais donner un conseil pour apprendre à écrire des contrats intelligents, je recommanderais d’apprendre Solidity, puis l’EVM. Vous pourriez aussi envisager Viper, dont le seul inconvénient est d’être plus récent et potentiellement plus vulnérable. Je me souviens qu’il y a quelques années, lors de la vérification d’un contrat de dépôt, on a découvert plusieurs failles dans le compilateur Viper. Celui qui les a trouvées travaille maintenant chez a16z ; c’est Day June, un expert en vérification formelle.
Day June est un expert en vérification formelle, c’est pourquoi il travaille maintenant chez a16z. La réalité, c’est que vous devez apprendre quelque chose, apprendre un langage.
Vous devez même approfondir l’EVM. Si vous voulez être un excellent ingénieur de contrats intelligents, vous devez connaître l’EVM à un niveau absurde, jusqu’à pouvoir énoncer le coût en gaz de chaque opération, et savoir exactement quel code coûte combien. Voilà dans quel monde nous vivons actuellement.
a16z Eddy Lazzarin : Peut-être un point mérite d’être noté : en tant qu’ingénieur logiciel, vous pouvez toujours comprendre la machine sur laquelle votre code s’exécute. Il y a beaucoup à apprendre sur l’environnement de programmation. Mais dans la programmation de contrats intelligents, l’environnement est extrêmement riche et complexe. Beaucoup de contexte est requis, presque indépendamment du langage lui-même. C’est ce qui se passe autour de vous, quels objets sont présents, comment différents codes sont appelés. C’est très étrange.
Animatrice Sonal Chokshi : Est-il vrai que ceux qui maîtrisent JavaScript sont les plus proches de pouvoir apprendre Solidity ?
Sui CTO Sam Blackshear : Tout le monde dit JavaScript à cause du mot-clé « function », que JavaScript utilise aussi. Malheureusement, ils ne sont pas vraiment similaires.
a16z Eddy Lazzarin : D’un point de vue syntaxique, Solidity reprend beaucoup de caractéristiques de JavaScript. Si vous fermez les yeux ou êtes de mauvaise humeur, cela peut sembler similaire, mais en réalité, c’est complètement différent. L’environnement de la machine virtuelle diffère radicalement, donc les points communs sont rares.
Animatrice Sonal Chokshi : Y a-t-il des langages de programmation comparables ?
a16z Noah : Oui, je ne pense pas qu’il existe de langage directement comparable. Si vous connaissez Was (note de Sui World : WebAssembly Studio, un outil en ligne pour compiler des codes C/C++ et Rust en format WASM), et que vous essayez d’écrire du code dans un environnement nécessitant un haut niveau d’isolation (comme Surplus), cela pourrait être le plus proche. Ce code s’exécute indépendamment mais nécessite un certain niveau de communication. Mais ce n’est toujours pas très similaire, la mentalité est complètement différente, et les similarités superficielles peuvent être dangereuses.
a16z Eddy Lazzarin : Peut-être que certains grands échecs historiques des langages de programmation sont pertinents. Je me demande s’il existe dans la blockchain des chemins empruntés qui se sont révélés être de mauvais choix. Avons-nous pris des mauvaises directions ?
Animatrice Sonal Chokshi : Excellente question.
Sui CTO Sam Blackshear :
Excellente question. En 1977, C a été publié, tout comme Standard ML. Standard ML a eu une influence majeure. Aujourd’hui, OCaml, Rust et Move sont fortement influencés par lui. Ces idées existent depuis longtemps. Beaucoup imaginent un univers alternatif où C n’aurait pas dominé, et où les idées de Standard ML — typage fort, sécurité intégrée — auraient été largement adoptées.
Animatrice Sonal Chokshi : Quelle est donc l’évolution de ces technologies informatiques ? Je ne dis pas que c’est une erreur, mais des langages comme Standard ML semblent encore très modernes aujourd’hui. Imaginer cet univers alternatif est fascinant ; j’ai été stupéfait quand je l’ai découvert.
a16z Eddy Lazzarin : Par curiosité, pourquoi pensez-vous que des langages comme C et leurs dérivés soient si directs, si impératifs ? Ils pensent l’ordinateur à un niveau assez bas, et en tant que langages de programmation, ils n’accomplissent pas grand-chose. Telle est ma perception de C. Pourquoi avons-nous pris cette voie ?
Sui CTO Sam Blackshear :
Je pense que les limitations matérielles de l’époque forçaient l’usage de C si l’on voulait écrire des programmes efficaces ou repousser les limites de l’ordinateur. Si les performances matérielles avaient progressé plus vite, on aurait pu choisir une autre voie. Mais la programmation fonctionnelle est difficile, souvent contre-intuitive. Je ne dis pas que C est facile, mais il est plus accessible. Puis on réalise qu’on a accompli des choses très complexes, mais difficiles à raisonner. Trop tard. Bonne remarque : les langages fonctionnels ont une courbe d’apprentissage plus raide, mais une fois maîtrisés, on peut penser son code de manière indépendante et résoudre les problèmes efficacement.
a16z Eddy Lazzarin : Je pense que si vous réfléchissez beaucoup à la manière dont l’ordinateur fonctionne au niveau matériel, des langages comme C semblent plus directs. Mais si vous êtes novice en programmation, C est plus facile à apprendre. En revanche, si vous maîtrisez bien les langages de programmation, je pense que les langages comme ML et la programmation fonctionnelle offrent davantage à explorer.
Sui CTO Sam Blackshear :
C’est une réponse globale. Mais je voudrais aborder les petits « erreurs linguistiques ».
a16z Noah :
J’hésite un peu sur ce point, car j’entends souvent dire que la programmation fonctionnelle est excellente, mais je la trouve difficile à comprendre. Ma question persistante est : si elle est si bonne, pourquoi n’a-t-elle jamais surmonté l’effet réseau des langages actuels ? Cette situation me surprend.
Mais je voudrais ajouter que la contribution majeure de la programmation fonctionnelle est que tous nos langages impératifs en ont emprunté des éléments. Le meilleur exemple, comme vous l’avez dit, est que Rust est fortement influencé par Standard ML, mais reste fondamentalement un langage impératif, n’est-ce pas ? Pourtant, il contient toutes ces merveilleuses « paillettes magiques » issues de cette inspiration.
Sui CTO Sam Blackshear :
Globalement, je pense que le véritable problème est que depuis 1977, les langages impératifs ont eu une influence énorme. Ensuite est venu PRFP, comme vous dites, pas forcément génial, avec ses propres bonnes idées, mais isolément, chacun avait ses défauts. Maintenant, nous voyons des hybrides réussis comme Rust qui fusionnent tout cela. Cela change vraiment la donne.
Je voudrais mentionner une chose : ce que Tony Hoare appelle « l’erreur de dix milliards de dollars » du pointeur null. Bien qu’il ait probablement exagéré, le coût de cette erreur dépasse clairement celui de ne pas l’avoir commise.
a16z Eddy Lazzarin : Non, c’est peut-être même une sous-estimation.
2. Innovation dans le développement des contrats intelligents
a16z Noah : Je suis curieux de savoir pourquoi vous n’avez pas beaucoup parlé de l’innovation au niveau de la machine virtuelle et du langage de programmation, et de leur impact sur l’évolution des contrats intelligents.
Sui CTO Sam Blackshear :
Bonne question. Je pense que les gens ne font pas suffisamment la distinction entre ces niveaux — machine virtuelle versus langage source. En effet, il existe de nombreuses innovations au-delà de l’EVM, comme les langages sources Viper, etc. Ces outils sont souvent meilleurs que Solidity à bien des égards, et très intéressants.
Je pense que si Move devient la norme juridique attendue du Web 3.0, l’innovation au niveau de la machine virtuelle sera lente et progressive. Le noyau restant fixe, nous n’ajouterons que de nouvelles fonctionnalités sans
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
