Sui : la plateforme Web3 ultra-scalable de MystenLabs
Sui est une plateforme de smart contracts décentralisée et sans permission de dernière génération. Spécialement conçue par MystenLabs pour favoriser l’adoption à grande échelle du Web3, Sui innove sur tous les fronts.
Grâce à la combinaison du langage de programmation Move, d’un nouveau protocole de mempool appelé Narwhal et de l’algorithme de consensus Tusk, Sui offre des performances exceptionnelles et une scalabilité horizontale sans limites.
- Un produit made in MystenLabs
- Sui : le Web3 et son prochain milliard d’utilisateurs
- Architecture générale de Sui
- Fonctionnement technique de Sui
- Move : le langage de programmation des smart contracts de Sui
- La feuille de route de MystenLabs pour Sui
- En conclusion
Un produit made in MystenLabs
MystenLabs est une entreprise forte de plus d’une trentaine d’employés, dont la mission est de bâtir l’infrastructure du Web3 de demain. Après de nombreuses expériences au sein d’entreprises technologiques prestigieuses, et avoir travaillé sur plusieurs projets innovants, ses fondateurs ont uni leurs forces pour créer Sui.
Evan Cheng, CEO, a fait ses armes en tant qu’ingénieur et manager senior chez Apple pendant plus de dix ans. Il a ensuite été directeur de l’ingénierie et des langages de programmation chez Meta (ex-Facebook), puis directeur de la recherche et du développement chez Novi Financial.
Adeniyi Abiodun, CPO, était auparavant chef de produit pour Meta. Il est également passé par VMware, Oracle, HSBC, J.P. Morgan et d’autres entreprises de renom.
Sam Blackshear, CTO, fut aussi ingénieur chez Meta et a fondé le langage Move. Il a travaillé sur la plateforme Diem (ex-Libra) et Novi Financial.
George Danezis, scientifique en chef, est passé par le prestigieux University College de Londres. Il y est professeur en ingénierie de la sécurité et de la vie privée. Chez Meta, il participa à la conception de Diem; puis il travailla à l’élaboration de Narwhal et Tusk, deux protocoles dont nous reparlerons plus bas.
Enfin, Kostas Chalkias, cryptographe en chef, a participé au développement de la blockchain Diem et du wallet Novi chez Meta. Il fut aussi cryptographe et ingénieur blockchain pour R3 (l’entreprise qui a développé la blockchain Corda), CTO et cofondateur d’Erybo et de Safemarket, entre autres.
Vous l’aurez compris, les cofondateurs de MystenLabs n’en sont pas à leur coup d’essai, et ont une longue expérience dans le domaine des réseaux distribués, de la cryptographie, de l’ingénierie et de la finance. Vous retrouverez l’équipe de MystenLabs au complet ici.
Sui : le Web3 et son prochain milliard d’utilisateurs
Objectifs et atouts
Les équipes de MystenLabs ont conçu Sui dans l’optique d’une adoption à grande échelle, de l’ordre du milliard d’utilisateurs. La scalabilité de son architecture est horizontale et sans limites. La finalité des transactions est instantanée. Sui devrait donc offrir des performances jamais atteintes, en termes de latence, de débit et de coûts, pour des cas d’usage et des actifs numériques on-chain variés et composables.
Sui traite les transactions en actifs numériques et les smart contracts d’une façon radicalement différente des plateformes existantes. Son architecture innovante permet ainsi de traiter la majorité de ces transactions en parallèle. Cela offre un débit exceptionnellement élevé, et une gestion beaucoup plus intelligente des ressources.
Sui est programmé en Rust, tandis que ses smart contracts sont codés via le langage de programmation Move. Ce dernier possède des caractéristiques bien particulières, qui sont essentielles pour atteindre les propriétés désirées.
Sui est un réseau asynchrone, où les transactions sont traitées de façon individuelle. Son jeton natif est le SUI. Sa provision totale est limitée et il a deux fonctions :
- Paiement des frais du réseau (gas) ;
- Preuve d’enjeu déléguée pour les autorités du réseau.
On parle en effet d’autorités et non de validateurs – vous comprendrez pourquoi en poursuivant la lecture de cet article.
Innovations majeures
L’idée de base (jamais mise en pratique jusqu’ici) est de renoncer au consensus pour les transactions les plus communes (paiements et transferts d’actifs). Cette couche du système Sui n’est réservée qu’aux opérations complexes.
Bien entendu, il faut s’appuyer sur des piliers solides pour réaliser une telle prouesse.
Tout d’abord, des dizaines d’années de recherche sur les protocoles de consensus résistants aux fautes byzantines ont permis d’améliorer grandement les performances des systèmes distribués. L’invention de Bitcoin et l’effervescence s’en étant suivie en termes de recherche scientifique ont permis de trouver de nouveaux modèles pour diffuser et ordonnancer des messages complexes.
Les chercheurs de MystenLabs ont travaillé en profondeur sur l’ordonnancement des transactions au sein d’un réseau distribué pour optimiser les modèles existants. Ils proposent ainsi le 25 mai 2021 un nouveau modèle de memory pool, appelé Narwhal, basé sur les graphes orientés acycliques (directed acyclic graph ou DAG), et un mécanisme de consensus byzantin efficient, Tusk.
Mais ce n’est pas tout ! Après avoir participé au développement de Diem, l’équipe a repris le meilleur de son langage de programmation de smart contracts (open source) – Move.
Architecture générale de Sui
Les blockchains existantes permettent d’établir un consensus sur un ensemble totalement ordonnancé de transactions. Cela nécessite des calculs coûteux – dont certains sont inutiles, nous allons le voir.
Grâce au langage de programmation de smart contracts Move, l’état du registre distribué est défini par des “objets”, et non des blocs reliés entre eux. C’est une différence fondamentale, qui permet de paralléliser les opérations.
Le registre distribué de Sui est un ensemble d’objets programmables, qui ont chacun un identifiant. Chaque objet appartient à une adresse unique, et chaque adresse peut posséder un nombre arbitraire d’objets : nous entrerons dans les détails un peu plus bas.
Les autorités de Sui ont un rôle plus ou moins actif selon le type de transactions. Dans certains cas, elles participent à un mécanisme de consensus byzantin, dans d’autres, elles se contentent d’émettre et de recevoir des certificats.
Fonctionnement technique de Sui
Des blocs ? Non, des objets !
Sui est optimisé pour les transferts de valeur d’utilisateur à utilisateur et la manipulation d’actifs numériques. Outre une sécurité sans faille, la disponibilité (liveness) du réseau doit être assurée malgré d’éventuelles fautes byzantines.
Le langage de programmation des smart contracts de Sui est Move, dont nous reparlerons. C’est un langage orienté objet, radicalement différent du classique Solidity. Ce qu’il faut savoir pour le moment, c’est que le système distingue deux types d’actifs :
- Les objets ayant un propriétaire spécifique qui est le seul à pouvoir les modifier (owned objects) ;
- Les objets partagés (shared objects), qui n’ont pas de propriétaire spécifique, et qui peuvent être modifiés par plusieurs utilisateurs.
C’est grâce à cette distinction que l’on peut renoncer au consensus pour les transactions communes -impliquant (1) – et obtenir une latence très faible. Ce modèle permet d’éviter une limitation de performance typique des réseaux distribués. Le head-of-line blocking, que l’on pourrait traduire par “blocage en tête de ligne”, se produit lorsque le traitement d’un paquet de données – un message situé en tête de file – engorge le réseau.
Modification de l’état du registre
Sur les blockchains classiques, les nœuds du réseau mettent à jour périodiquement un accumulateur, qui représente l’état courant de la chaîne.
Cette mise à jour reflète les modifications du registre découlant des transactions des utilisateurs. Le consensus permet de s’accorder sur le nouvel état de la chaîne. Il faut donc ordonnancer la totalité des transactions de l’accumulateur (par exemple le mempool) avant de procéder à sa finalisation.
Dans le cas de Sui, il n’y a pas besoin de consensus pour les objets (1) – owned objects. Le consensus n’est requis que pour les objets partagés (2) – shared objects. Ce sont les autorités qui jouent alors un rôle actif en ordonnançant totalement les transactions impliquant des objets partagés.
Cette gestion de l’état du registre basée sur des objets nécessite donc d’identifier ces derniers. Ils possèdent un numéro de version unique. Chaque nouvelle version d’un objet provient d’une transaction qui peut impliquer plusieurs dépendances – qui sont elles-mêmes des objets versionnés.
Les autorités (ou toute autre entité ayant une copie du registre) peuvent donc accéder à l’histoire causale d’un objet depuis sa genèse. Dans la vaste majorité des cas, l’ordonnancement de l’histoire causale d’un objet vis-à-vis de l’histoire causale d’un autre objet n’est pas nécessaire. Dans le cas contraire, les métadonnées rendent cette relation causale explicite.
Ce modèle permet au système distribué asynchrone de garder une grande disponibilité. On parle ainsi de “cohérence éventuelle” (eventual consistency) :
- Si une autorité honnête exécute une transaction, les autres autorités feront de même;
- Deux autorités ayant reçu le même ensemble de transactions atteindront le même état du registre (convergence).
Le réseau distribué peut ainsi converger, sans pour autant devoir bloquer le flux des transactions.
Les transactions sur Sui
Protocole de diffusion
Sui part du principe que de nombreuses transactions ne dépendent pas d’autres parties de l’état du registre. C’est le cas, par exemple, lorsqu’un utilisateur souhaite simplement transférer un actif à un destinataire. Il suffit alors de vérifier la validité de la transaction en regardant le solde du compte de l’émetteur. Sui va ignorer le consensus et utiliser un algorithme beaucoup plus simple. On parle de Byzantine Consistent Broadcast – diffusion byzantine cohérente.
Ces protocoles sont issus de FastPay, un protocole de règlement tolérant aux fautes byzantines à haute performance, proposé par Mathieu Baudet, George Danezis et Alberto Sonnino en 2020.
Sans entrer dans les détails, il permet à un ensemble d’autorités de maintenir un système de règlement (crypto et fiat) avec un très haut degré d’intégrité et de disponibilité (théoriquement 80 000 tx/s avec 20 autorités).
Validation individuelle
Pour résumer, Sui se focalise seulement sur les données pertinentes et non pas sur l’ensemble du registre.
Grâce au langage Move, Sui étend ce concept aux transactions qui dépendent explicitement d’éléments multiples étant sous le contrôle de l’émetteur. Les objets et le système de propriété de Move permettent de valider des transactions sans entraver le flux de celles qui sont indépendantes.
Cette validation individuelle des transactions diminue drastiquement la latence et augmente fortement le débit, par rapport à l’agrégation traditionnelle des transactions en blocs.
Transactions « communes » (impliquant les owned objects)
L’utilisateur soumet donc ses transactions une par une au réseau :
- La transaction est diffusée aux autorités ;
- Chaque autorité répond par un vote individuel, pondéré par le stake qu’elle détient ;
- L’émetteur collecte alors une majorité (byzantine-résistante) de ces votes. Il forge alors un certificat de validité qu’il transfère à toutes les autorités. La transaction est alors finalisée.
- L’émetteur peut également créer un “certificat d’incidence” qui détaille les effets de la transaction.
Bien qu’il demande plus d’efforts de la part de l’émetteur, ce modèle permet de prouver cryptographiquement la finalité d’une transaction avec une latence minimale. Il n’y a pas besoin d’accéder à une quelconque clé privée pour forger la transaction, ce qui permet de déléguer ce processus à une tierce partie (gateway service).
Transactions et smart contracts « complexes » (impliquant les shared objects)
Les objets partagés (modifiables par plus d’un utilisateur) permettent d’élaborer des smart contracts complexes. Les transactions impliquant des objets partagés doivent être dans ce cas ordonnancées en totalité, puis les autorités établissent un consensus. Sui utilise pour ce faire un nouveau protocole de mempool, appelé Narwhal, ainsi que Tusk, un protocole de consensus asynchrone.
Narwhal et Tusk
Ces deux protocoles sont décrits dans ce papier du 25 mai 2021 : “Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus”. Leurs auteurs ne sont autres que George Danezis et Alberto Sonnino (Chief Scientist et chercheur chez Mysten Labs), Lefteris Kokoris-Kogias (IST Autriche, conseiller pour Mysten Labs) et Alexander Spiegelman (Aptos).
Narwhal est un protocole de mempool avancé, qui garantit un débit optimal même en cas de réseau asynchrone ou de fautes. Quant à Tusk, il s’agit d’un protocole de consensus à haut débit, résilient face aux attaques de déni de service. Il est basé sur un DAG (graphe orienté acyclique).
La combinaison de Narwhal et Tusk offre théoriquement des performances incroyables : un débit supérieur à 500 000 tx/s pour une latence de 3,5 s.
Le fonctionnement de ces deux protocoles (les plus avancés actuellement) ne sera pas détaillé dans cet article.
Traitement des transactions impliquant des objets partagés
Les transactions impliquant des objets partagés contiennent obligatoirement au moins un owned object. Il faut en effet payer pour les frais de gas. La transaction va alors se dérouler de la façon suivante :
- Diffusion : l’émetteur soumet la transaction à toutes les autorités de Sui ;
- Vote : chaque autorité vote individuellement pour la transaction. Le poids du vote est pondéré par le stake de cette dernière ;
- Certification : l’émetteur recueille la majorité (tolérante aux fautes byzantines) de ces votes et forge un certificat. Ce dernier est ensuite envoyé à toutes les autorités. Cette fois-ci, le certificat sera séquencé selon un agrément byzantin.
- Finalisation : une fois la transaction séquencée avec succès par les autorités, l’utilisateur renvoie le certificat aux autorités pour finaliser la transaction.
Synthèse du fonctionnement de Sui
En résumé, voici comment s’articulent les différentes interactions au sein du système, selon les objets impliqués dans la transaction :
Ordonnancement, causalité et scalabilité
Les différents procédés ci-dessus confèrent à Sui ses performances et sa scalabilité exceptionnelles.
Les transactions contenant des owned objects ne sont pas « totalement ordonnancées« , mais « ordonnancées par causalité« . Les transactions sans relation de causalité peuvent donc être traitées dans n’importe quel ordre. C’est ce qui permet à Sui de paralléliser leur exécution, et de fragmenter cette tâche sur de multiples machines.
L’ordonnancement ne concerne que les transactions ayant des relations de causalité. Si une tx1 produit en sortie un objet ob1, qui est utilisé en entrée dans une tx2, une autorité devra exécuter tx1 avant tx2. Bien sûr, même si tx2 n’utilise pas directement ob1 mais qu’une tx3 utilise ob1, et que sa sortie est une entrée pour Tx2, il y a relation causale.
L’ordonnancement des transactions impliquant des objets partagés est effectué grâce à Narwhal. La scalabilité reste horizontale, car il suffit d’ajouter plus de machines par autorité pour traiter plus de transactions.
Narwhal et Tusk permettent donc d’obtenir une scalabilité horizontale, en fonction du nombre de machines travaillant à la création du DAG ordonnançant les transactions « complexes ».
Les passerelles (gateway services) entre l’utilisateur et les autorités
Avec le système Sui, des tierces parties peuvent assister l’utilisateur pour soumettre les transactions. Par exemple, le développeur d’une dApp de gaming très utilisée gérera l’agrégation des votes et la diffusion des certificats à la place des joueurs. Le développeur de la dApp mettra en place une implémentation d’un Sui Gateway Service sur ses propres serveurs.
Les passerelles sont utiles pour une meilleure expérience utilisateur. Plutôt que d’envoyer des transactions à plusieurs autorités via son smartphone, l’utilisateur les soumettra à son application, qui les transmettra ensuite à une passerelle.
Encore une fois, il n’y a pas besoin d’accéder aux clés privées de l’utilisateur, donc aucun problème de sécurité.
Comme dans le cas du mempool sur une blockchain classique, le service de passerelle est un accumulateur. Il s’assure que le quorum d’autorités requis a bien reçu la transaction, collecte les votes nécessaires pour soumettre le certificat correspondant aux autorités, et répond au client.
Les services de passerelle améliorent ainsi la disponibilité en fonction de la bande passante.
Move : le langage de programmation des smart contracts de Sui
Le langage de programmation Move fut originellement conçu par les équipes développant Diem (anciennement Libra), la blockchain de Meta (anciennement Facebook).
Ce langage, orienté objet, est open-source. Par conception, Move est plateforme-agnostique. On peut ainsi l’utiliser pour créer des librairies et des outils communs à différentes communautés de développeurs Web3, sur différentes blockchains, présentant des modèles de données et d’exécution variés.
Au-delà de Sui, deux plateformes blockchain utilisent déjà Move (0L et Starcoin); et Celo devrait l’intégrer prochainement.
Il faut connaître les propriétés de Move pour comprendre les possibilités techniques de Sui. L’équipe de Mysten Labs a fait le choix de laisser de côté le bien connu Solidity pour pallier plusieurs problèmes inhérents aux langages de programmation de smart contracts existants :
- Manque de compatibilité inter-plateformes ;
- Sécurité sous-optimale ;
- Couche d’exécution lente ;
- Immaturité de l’écosystème des langages existants ;
- Mauvaise expérience utilisateur.
Ce sont des critiques qui ont déjà été formulées à maintes reprises. Il faut adapter chaque langage à la blockchain sur lequel il sera utilisé (ou le concevoir en fonction de ses caractéristiques).
Move est un langage de programmation sûr et expressif : sa syntaxe est facile à comprendre, à la fois par l’être humain et par le compilateur.
Les modules
L’état de la blockchain Sui est ainsi un ensemble d’objets programmables. Ces objets sont créés et gérés par des packages Move, qui sont eux-mêmes des ensembles de modules Move. Ces modules comportent des fonctions et des types.
Il y a alors deux catégories d’objets sur Sui :
- D’une part, les valeurs des données structurées (struct data values). Ces données typées sont contrôlées par les modules. Les champs des données struct peuvent contenir des primitives (comme des adresses ou des entiers), d’autres objets, et des structs qui ne sont pas des objets.
- D’autre part, le code des packages. Il s’agit du bytecode des modules relatifs à l’objet. Ces modules peuvent dépendre à la fois de modules présents dans le package, et de modules publiés précédemment.
C’est par ces objets que sont encodés les actifs de la blockchain Sui. Il peut s’agir de jetons fongibles ou non-fongibles. Suivant leurs capacités, il est possible d’appeler certaines fonctions, de créer d’autres objets, ou d’autres smart contracts, afin de gérer d’autres actifs, et ainsi de suite.
Les programmes Move sont donc des ensembles de modules. Ces modules sont eux-mêmes des ensembles de déclarations de structures et de fonctions. Il est possible d’importer des structures de types depuis d’autres modules, ou d’appeler des fonctions au sein d’autres modules. Contrairement à de nombreux langages de programmation de smart contracts, Move “encapsule” certaines opérations. Les types ne peuvent être créés, détruits ou copiés que par des fonctions issues du module les ayant déclarés. Il en va de même pour l’accès en lecture/écriture : on parle de langage “robustly safe” (solidement sûr).
Les transactions
L’ensemble des objets donc est mis à jour via les transactions. Elles peuvent ainsi créer, supprimer, lire et écrire des objets. Tout objet sur lequel une transaction souhaite opérer est donc une entrée pour cette dernière. L’identifiant de version de l’objet, le nom d’un module et les fonctions, ainsi que les arguments sont mentionnés dans la transaction.
Un objet créé rejoint l’ensemble global. Il est possible de le transférer à une adresse ou à un autre objet. En cas de transfert, il ne sera plus accessible par le code restant de la transaction.
Move comporte des protections – sécurité des ressources – garantissant que des objets ne peuvent pas être créés sans autorisation, copiés ou accidentellement détruits. De même, il est impossible de transférer le même objet deux fois.
Modèle de programmation
Une fois le code Move écrit par le développeur, il est testé et vérifié formellement en local. Il est ensuite compilé en bytecode puis publié. Ce bytecode passe également par un vérificateur, qui va s’assurer que les propriétés clé sont respectées : typage, utilisation de la mémoire et sûreté des ressources, etc.
Le langage Move peut être adapté à toutes les plateformes. Il a été étendu pour répondre aux objectifs spécifiques de Sui. C’est un langage très sûr, qui permet d’éviter par conception des problèmes et des attaques biens connus sur Ethereum. Son expressivité est avantageuse pour les développeurs passant du Web2 au Web3. MystenLabs fait le pari qu’il sera le langage le plus utilisé sur les plateformes de smart contracts de prochaine génération. Move permet d’améliorer à la fois l’expérience du développeur et de l’utilisateur final.
Il est donc possible d’utiliser toutes les instructions disponibles dans le langage Move, à l’exception de ce qui concerne le stockage. Originellement, ce dernier est basé sur les comptes. Sur Sui, il est géré au niveau de la globalité des objets composant l’état de la blockchain. Cela le rend peu coûteux, scalable, et permet ainsi aux développeurs de créer des actifs complexes, sans avoir à passer par des systèmes de stockage off-chain. La composabilité des smart contracts est ainsi grandement améliorée.
Pour plus de détails sur la programmation avec Move, consulter le whitepaper de Sui et la documentation technique de Move (liens en fin d’article).
La feuille de route de MystenLabs pour Sui
Les développeurs peuvent d’ores et déjà écrire des smart contracts en Move et les tester. Une fois un réseau Sui lancé en local, il pourront publier et y exécuter leurs contrats.
Dans le courant de l’année, MystenLabs lancera :
- Le devnet public (où les autorités seront gérées par MystenLabs)
- Le testnet public (que des autorités non-gérées par Mysten pourront rejoindre)
- Et enfin le mainnet public, avec de “vrais” actifs et des applications en production.
MystenLabs teste actuellement le réseau Sui sur son devnet interne (pile technologique, benchmark du débit et de la latence sous diverses configuration…). Quelques exemples :
- Implémentation du staking
- Modèle des frais de gas
- Alignement des API des services de passerelles
- Explorateur et wallet
- Kit de développement
- Amélioration du langage Move
MystenLabs recrute activement des ingénieurs et développeurs : vous pouvez candidater ici.
En conclusion
Sui représente l’aboutissement de nombreuses années de recherche et développement. MystenLabs a franchi une nouvelle étape en termes de scalabilité, de débit, de latence et d’accessibilité pour les plateformes du Web3.
Le langage Move permet de concevoir de nouveaux actifs numériques, riches et complexes, et de nouvelles applications :
- NFT dynamiques, pouvant être sans cesse mis à niveau, selon les besoins d’une application (changements d’avatar, objets personnalisables dans un jeu) ;
- Plateformes de trading on-chain à la latence très faible ;
- Réseaux sociaux décentralisés entièrement on-chain ;
- Programmes de fidélité accessibles à des millions d’utilisateurs à faible coût…
Si les performances de la plateforme sont à la hauteur des promesses, une fois le mainnet en production, Sui deviendra facilement l’un des géants de l’industrie.
Ressources
- Site officiel
- Documentation
- Discord
- GitHub
- Le whitepaper de Sui
- Le whitepaper de Narwhal et Tusk
- La documentation technique de Move