Dialogue approfondi avec le scientifique en chef de Mysten Labs : De la théorie à la pratique, comment Sui résout-il le problème de l'évolutivité du réseau ?

Récemment, nous avons interviewé George Danezis pour discuter de la complexité et de l'évolutivité de l'infrastructure de Sui, ainsi que de la manière dont le système de traitement des transactions de Sui permet de créer un réseau hautes performances. George Danezis est le co-fondateur et scientifique en chef de Mysten Labs (et le contributeur original de Sui) et professeur dans le domaine de l'ingénierie de la sécurité et de la confidentialité à l'UCL.

Voici le contenu de cet entretien :

**Q1 : Vous êtes issu du domaine académique, pouvez-vous présenter votre axe de recherche ? **

Je suis professeur à l'University College London (UCL) et mes recherches portent sur la sécurité et la confidentialité au sens large. Au début du 20e siècle, j'ai effectué de nombreuses recherches sur les systèmes peer-to-peer et anonymes, dont beaucoup étaient de grands systèmes distribués axés sur le stockage. Alors que l’ensemble de la blockchain devenait de plus en plus orienté vers l’exécution, notamment représenté par Ethereum, je me suis intéressé aux registres distribués et aux blockchains ainsi qu’à la manière d’exécuter des contrats intelligents. Sa nature sans autorisation m'est familière grâce à mon travail sur les premiers systèmes peer-to-peer. Mon groupe de recherche à l’UCL a donc cherché à comprendre comment construire des systèmes plus performants. Nous avons lancé Chainspace pour commercialiser certaines de nos idées, et l'équipe a été rachetée par Facebook. Nous avons ensuite aidé Facebook à trouver une solution pour faire évoluer la blockchain Libra/Diem. Mais lorsque la proposition n’a pas progressé, j’ai quitté et j’ai continué à rechercher d’autres opportunités pour mettre en œuvre le concept de blockchain haute performance.

**Q2 : Vous êtes toujours professeur, alors, selon vous, quelle est la différence entre l'application et la recherche ? **

Il n'y a vraiment pas beaucoup de différence. Lorsque nous menons des recherches, nous envisageons toutes les possibilités pour atteindre un objectif spécifique, comme construire une blockchain performante ou une fonction spécifique. Bien entendu, lors de la construction d’une blockchain ou du choix d’une fonction spécifique à utiliser dans un système réel, nous devons choisir l’une de ces possibilités. Nous devons constamment porter un jugement, parmi toutes ces bonnes idées, lesquelles sont réellement les plus utiles aux gens ? Qu’est-ce que les gens recherchent ? Quels sont les obstacles à l’adoption de la blockchain ? Qu’est-ce qui empêche les gens de réaliser ce qu’ils veulent ? Lorsque vous construisez un système, vous envisagez toujours toutes les possibilités et essayez de comprendre ce qui est possible à partir de la littérature universitaire, puis de choisir ce qui est le plus pertinent. Il ne s’agit pas seulement d’un intérêt intellectuel, mais aussi d’une création de valeur pour les utilisateurs.

**Q3 : Lorsque vous passez de la théorie à l'application pratique, comment déterminez-vous les problèmes à résoudre ? **

Le principal problème que j’aborde dans mes recherches est de savoir comment faire évoluer les différentes fonctions de la blockchain. Je me concentre sur les aspects système de la blockchain, c'est-à-dire comment augmenter le débit des transactions et réduire la latence. Le problème à cet égard est évident : chaque fois que nous voyons un certain contrat sur Ethereum devenir très populaire, la plate-forme Ethereum ne peut pas supporter un volume de transactions aussi important, une congestion des transactions se produit et les frais montent en flèche. Chaque fois qu’une blockchain réussit, nous la voyons traiter plus de transactions qu’elle n’en fait actuellement. Le problème est donc clairement qu’il n’y a pas assez de capacité pour ce que les gens veulent faire sur ces blockchains. Ce n’est pas seulement dans nos esprits, nous l’avons vu se produire à maintes reprises. Pendant un certain temps, cela a été reconnu comme un défi louable, non seulement dans mon groupe, mais en fait, toute la communauté universitaire travaillait sur la blockchain, chacun résolvant ce problème de différentes manières. Aujourd’hui, de nombreuses technologies ont été développées pour étendre les capacités de la blockchain afin de relever ces défis. Mais à l’époque, comme nous le savons tous, beaucoup de gens l’abordaient de différentes manières.

**Q4 : Le réseau L2 est un moyen proposé par les gens pour résoudre le problème de mise à l'échelle. Quelle est la différence et l'avantage de construire un nouveau réseau L1 comme Sui ? **

L2 est une solution de mise à l’échelle dans l’écosystème Ethereum. Mais pour les développeurs d'applications, travailler avec des réseaux L2 est un peu délicat. Lorsqu’un réseau L2 tente d’interagir avec Ethereum, une activité de pontage doit se produire, bien que cela soit vrai pour toute relation L2/L1. L'état représentant une pièce, un actif ou un autre contenu dans L1 doit être reflété dans L2, et vice versa. Au-delà de cela, L2 doit disposer d’un mécanisme pour que L1 puisse vérifier tout ce qui s’y passe. Mais ce n'est que la première partie, tout actif qui existe sur L1 doit être transféré vers L2, une certaine activité doit avoir lieu sur L2, puis d'une manière ou d'une autre transférer l'actif vers L1. C'est très gênant.

Pour les actifs fongibles tels que les jetons, cette activité de pontage est relativement fluide, car les gens disposent de deux comptes et d'un middleware de pontage. Mais pour des actifs plus généraux, cela ne fonctionne pas très bien. Pour utiliser réellement le réseau L2 sur Ethereum pour développer des applications plus complexes que les jetons, vous devez avoir des contrats intelligents des deux côtés, un pour la frappe (mint) et un pour la gravure (burn). Ils doivent faire la navette entre deux écosystèmes différents, ce qui constitue une activité personnalisée pour chaque contrat. Vous ne pouvez pas simplement dire : je vais créer un réseau L2, retirer tous les actifs, faire ce que je veux et les ramener, un tel concept n'existe pas. Il s’agit d’un processus manuel et très sujet aux erreurs. Ce n'est donc pas une expérience formidable. Imaginez que vous disposez d'actifs sur plusieurs réseaux L2 différents et que vous disposez de ces contrats intelligents personnalisés sur différents réseaux L2. Chaque fois que vous souhaitez opérer sur un état qui se trouve sur un autre réseau L2, vous devez revenir jusqu'à L1, puis revenir à L2. Vous ne pouvez pas facilement dire : je viens de faire quelque chose sur cette blockchain, puis je vais faire autre chose sur une autre blockchain, et je n'ai pas besoin de penser à sur quelle L1 ou L2 il se trouve. Tout est là et je l'ai entre les mains en ce moment, prêt à effectuer davantage de transactions dans l'État que je souhaite visiter. C'est pourquoi la propagation de l'état sur un réseau L2 est une mauvaise expérience. Déplacer des actifs entre différentes chaînes est délicat et évident pour les utilisateurs. C'est pourquoi les réseaux L2 n'ont jamais vraiment suscité mon intérêt.

Un autre exemple est Cosmos, qui possède un écosystème très intéressant qui adopte une autre approche de mise à l’échelle en utilisant différentes blockchains pour différentes applications. Nous pouvons avoir différentes vitesses de transaction sur différentes chaînes et relier les actifs entre les chaînes lorsque nous devons opérer entre différentes applications, mais nous sommes également confrontés au même problème. Chaque fois que vous souhaitez utiliser une application différente, vous devez d'abord effectuer une opération de pont, qui est subtile et évidente pour l'utilisateur, puis vous pouvez utiliser cette application et revenir en arrière. Vous passerez plus de temps à déplacer des actifs d’une chaîne à une autre qu’à faire ce que vous voulez vraiment faire.

Sur Sui, notre solution est de construire une grande base de données qui contient en fait tous les états répliqués par les validateurs. Une fois une transaction terminée, tous les états de la même base de données peuvent être utilisés pour effectuer la transaction suivante sans que les utilisateurs aient à déplacer constamment les états des actifs entre L1 et L2.

**Q5 : Sui Lutris est le fondement du protocole Sui. Quelles sont ses principales innovations qui permettent à Sui d'avoir un débit élevé et une faible latence ? **

Sui Lutris se compose de deux idées clés : (1) pour de nombreuses opérations sur la blockchain, le consensus n'est pas réellement requis ; (2) lorsque vous avez besoin d'un consensus, il existe une méthode à très haut débit qui combine ces deux méthodes. Sui Lutris est le cœur du système distribué de Sui, garantissant que deux nœuds de vérification différents suivant le protocole ne seront jamais dans un état incohérent lors de la réalisation de transactions sur le réseau distribué. Il n'y a aucune situation dans laquelle un validateur pense que vous avez dépensé une pièce et l'avez envoyée à Alice, tandis qu'un autre validateur pense que la même pièce a en fait été envoyée à Bob.

🌟 Auto-loutre :

Deux voies différentes, l’une qui ne nécessite pas de consensus (voie rapide) et l’autre qui nécessite un consensus (voie du consensus). Lorsque l’objet que vous souhaitez manipuler n’appartient qu’à vous, comme votre propre personnage NFT et le chapeau que vous souhaitez combiner pour que votre personnage puisse porter le chapeau, en théorie personne d’autre ne devrait pouvoir les manipuler. Dans ces cas, Sui utilise la voie rapide, ce qui signifie que vous pouvez manipuler vos propres objets, que vous obtenez la finalité de la transaction sans attendre le consensus, que la transaction est garantie et que le chapeau est sur votre tête NFT.

Mais dans certains cas, les transactions ne concernent pas uniquement des objets qui vous appartiennent, ils sont partagés par de nombreuses personnes. Par exemple, s’il existe une vente aux enchères de petits chapeaux, ce type d’enchère sera représenté dans Sui comme un objet partagé. Les gens peuvent enchérir et le plus offrant remporte le chapeau. Ce type d'enchères est un objet qui n'appartient pas à une seule entité. Chacun doit pouvoir enchérir, partager et mettre à jour l'état de la dernière offre. Ces types d'opérations nécessitent un consensus supplémentaire. Sui Lutris vous permet de posséder des objets partagés et d'effectuer des transactions sur eux, vous permettant ainsi de posséder d'autres objets, de modifier l'état des objets partagés ou de créer de nouveaux objets partagés. Il permet aux deux chemins de coexister et d’interagir entre des objets exclusifs appartenant à un individu particulier ou des objets partagés par plusieurs personnes.

Ces deux voies différentes présentent des avantages différents. Le chemin rapide pour les objets exclusifs a une latence extrêmement faible, prend moins d’une seconde, est très rapide et évolue largement. La voie consensuelle a une latence plus élevée, généralement supérieure à une seconde, et une capacité assez élevée, mais elle est plus difficile à mettre à l'échelle que la première voie. Sur Sui, ceux qui pilotent réellement les applications en chaîne avec des millions de transactions par jour utilisent généralement le premier chemin et structurent leurs applications dans une large mesure pour avoir le plus de transactions principalement sur des objets exclusifs, sans pour autant être un accord de partage. En revanche, les protocoles qui effectuent un travail complexe (comme DeFi) pratiquent souvent le deuxième type de transaction, car ils doivent combiner les offres ou les liquidités de nombreuses personnes différentes pour effectuer des opérations.

**Q6 : Les développeurs d'applications sur Sui peuvent-ils concevoir leurs applications pour tirer parti de la voie rapide ? **

Oui absolument. Je pense que c'est le travail principal d'un concepteur d'applications d'extension. Les développeurs de contrats intelligents ont un contrôle total sur si les objets qu'ils manipulent dans le contrat sont l'objet exclusif ou partagé d'une seule entité à un moment donné. L'une des astuces pour faire évoluer votre application dans Sui est de vous assurer que la plupart des opérations portent essentiellement sur des objets exclusifs, car Sui peut gérer autant d'opérations que vous le souhaitez avec une latence très faible, ce qui est une expérience agréable. Les opérations nécessaires au jeu doivent être effectuées dans cette catégorie, et leur latence est très faible par rapport aux opérations qui doivent être médiatisées via un état partagé et des objets partagés. Une fois cliqué, la transaction peut être finalisée instantanément sur le réseau.

Le concepteur de contrats intelligents a un contrôle total sur cela et peut essentiellement spécifier exactement quelles sont les transactions dans chaque catégorie. Bien sûr, la première version du contrat peut tout traiter comme un état partagé, et tout passera par la voie du consensus à latence plus élevée, mais en raison de la nécessité d'évoluer, les développeurs doivent réfléchir à jusqu'où ils peuvent le faire. .

**Q7 : Comment le bloc de transaction programmable joue-t-il un rôle à cet égard ? **

Les blocs de transactions programmables peuvent fonctionner soit sur la voie rapide, soit sur la voie consensuelle. Si un bloc de transactions programmables implique uniquement votre objet exclusif, cela signifie que vous pouvez effectuer plusieurs opérations en une seule opération en chaîne. Par exemple, supposons que vous soyez une application CEX dans laquelle de nombreuses personnes achètent et vendent différentes pièces. Vous pouvez effectuer une transaction sur la chaîne, ce qui correspond conceptuellement à ce que les gens achètent et vendent. Mais comme vous êtes une bourse, elles vous appartiennent toutes, donc mille transactions peuvent être réglées en même temps, ce qui est la voie rapide. D'un autre côté, si certains objets du bloc de transaction programmable sont partagés, alors le chemin du consensus est entré et la latence sera légèrement plus élevée, pas moins d'une seconde mais plusieurs secondes.

**Q8 : Le réseau principal est en ligne depuis plus de 100 jours. La performance de Sui a-t-elle confirmé votre théorie de recherche hypothétique ? Y a-t-il quelque chose qui vous a surpris ? **

Il y a quelques éléments qui confirment le design de Sui, mais il y a aussi des éléments qui donnent matière à réflexion. La première est que lorsque le volume des transactions est particulièrement important, même à un moment particulier, le volume quotidien des transactions dépasse même 60 millions, dont la plupart sont sur la voie rapide. Sui Lutris est très évolutif et a une latence très faible. D’ici là, il n’est pas clair si quelqu’un utilisera cette voie, mais lorsque des volumes de transactions élevés et une faible latence sont requis, elle est utilisée et elle fonctionne très bien ! C'est facile à voir, c'est la méthode. À cette époque, Sui effectuait plus de transactions que toutes les autres blockchains réunies. C'est une confirmation intéressante que la conception de Sui est solide.

Pendant ce temps, la communauté Sui a trouvé cette voie rapide un peu délicate. Étant donné que les propriétaires d’objets doivent gérer dans une certaine mesure l’ordre des opérations sur leurs propres objets, les choses peuvent parfois mal tourner. Parfois, ils peuvent même utiliser une bibliothèque qui ne les aide pas, et la bibliothèque elle-même présente des bugs, donc parfois les objets sont verrouillés. Habituellement, ils se débloquent à la fin de la journée, à la fin d'une époque, mais ce n'est pas une expérience formidable. Les personnes qui conçoivent des contrats intelligents peuvent être intimidées par cela, craignant que des erreurs ne se produisent, ce qui les empêche de profiter pleinement des fonctionnalités de faible latence et d'évolutivité. De nombreuses technologies sont en cours de développement pour permettre à ceux qui ont verrouillé des objets par erreur de les déverrouiller rapidement en quelques secondes. Ainsi, si vous essayez d'utiliser le chemin rapide, qu'une erreur se produit et que votre objet est verrouillé, vous pouvez immédiatement utiliser le chemin consensuel pour le déverrouiller sans attendre la fin d'une époque.

Et, curieusement, il ne s'agit pas seulement d'éviter les bugs, cela permet aux développeurs d'exprimer rapidement beaucoup plus de choses, il existe des techniques potentielles dans lesquelles certains objets n'appartiennent pas à une seule partie. Il existe peut-être un objet que vous et moi possédons conjointement, car il est partagé, et généralement les transactions sur cet objet doivent passer par la voie du consensus. Cependant, si Sui disposait d'un moyen de déverrouiller rapidement des objets, les développeurs pourraient en fait essayer d'accélérer les transactions. Dans le cas où vous et moi effectuons une transaction sur le même objet exactement au même moment, le système sera verrouillé, incapable de décider quelle transaction aura lieu ensuite, et Sui pourra alors la déverrouiller et passer par le chemin du consensus, le rendre partagé et le résoudre. Mais cela ne peut se produire que si les gens tentent délibérément d’être compétitifs. Une fois que Sui dispose de la fonctionnalité permettant de déverrouiller des objets, il devrait pouvoir accéder rapidement aux objets appartenant à plusieurs personnes. C'est un jeu qui essaie de faire passer autant de volume de transactions que possible par la voie rapide, ce qui est un type de chose en cours de développement pour aider la communauté des constructeurs.

**Q9 : Pouvez-vous partager plus en détail ce qui provoque actuellement le verrouillage des objets ? **

La raison pour laquelle il n'est pas nécessaire de passer par un consensus pour indiquer à Sui la séquence d'opérations à effectuer lorsqu'un objet vous appartient est que personne d'autre ne peut opérer sur votre objet. Sui compte sur vous pour dire au système que l'action A se produira en premier, l'action B se produira ensuite et l'action C se produira en dernier. Le système doit encore vérifier que les ABC sont vus par tous dans le même ordre. Le système est implémenté via un protocole distribué qui vérifie simplement si nous avons tous vu ABC à tour de rôle. La question est de savoir si vous faites une erreur ou si votre logiciel fait une erreur. Par exemple, si votre téléphone contrôle votre actif et que votre ordinateur contrôle votre actif, votre téléphone indique que A s'est produit en premier et votre ordinateur indique que B s'est produit en premier. Vous triez incorrectement deux choses différentes. C'est une contradiction. Dans ce cas, Sui dirait : « Eh bien, la personne que j'ai chargée de me raconter la séquence semble m'avoir donné deux choses contradictoires, donc je ne sais pas quoi faire. Je ne sais pas comment résoudre ce problème. Parce que Sui Ce problème est généralement résolu par la voie du consensus. Mais ici, vous essayez d’utiliser la voie rapide. Alors Sui leva la main et dit : « D'accord, il y a une erreur ici.

L'hypothèse initiale était que cela n'arriverait pas très souvent, mais il s'avère que cela se produit assez souvent lorsque les gens utilisent différents appareils ou tentent d'effectuer plusieurs transactions sur le même objet en même temps. Actuellement, lorsque ces objets sont verrouillés, Sui attend la fin d'une époque pour les déverrouiller, ce qui est très inquiétant. Imaginez que si vos actifs étaient inutilisables pendant une journée, cela pourrait en réalité constituer un problème sérieux.

Alors maintenant, Sui doit évoluer pour prendre les mesures appropriées lorsque quelque chose est verrouillé. Si l'entité chargée de fournir l'ordre correct donne un ordre ambigu, Sui résoudra l'ensemble de la situation par consensus. Cela se produira en quelques secondes, pas à la fin d’une époque.

**Q10 : Une grande partie de vos recherches portent sur la confidentialité. Que pensez-vous de la manière dont les blockchains publiques peuvent équilibrer au mieux transparence, traçabilité et confidentialité ? **

Dans la chaîne publique, comment équilibrer la transparence, la traçabilité et la confidentialité est une question très liée à l'application, et mon point de vue sur la confidentialité est que ce qui doit rester privé dépend en grande partie de l'application elle-même. Par exemple, sur Sui, il est logique que les développeurs d’applications élaborent des contrats qui protègent la vie privée de leurs utilisateurs. Étant donné que certaines personnes souhaitent simplement développer des jeux, les problèmes de confidentialité ne sont peut-être pas si préoccupants. Certaines personnes souhaitent effectuer des transactions financières sur la blockchain, et la confidentialité peut être plus préoccupante, mais en même temps, d'autres types de problèmes réglementaires sont impliqués. L'attitude de Sui est donc que nous vous fournirons une bonne plate-forme et que vous devez renforcer la confidentialité sur cette plate-forme.

Pour aider les gens à renforcer leur confidentialité, Sui fournit un support crypto-natif qui peut leur être utile lors de la conception de contrats intelligents. L’un des plus importants est la possibilité de vérifier les preuves de connaissance nulle sur Sui. Il existe une fonction native qui vérifie l'un des schémas les plus utilisés et compris, le schéma Groth16 développé par mon collègue Jens Groth. Cela signifie qu'en effet, les concepteurs d'applications peuvent vérifier certains événements hors chaîne sans révéler quels sont ces événements. Il s’agit de l’élément fondamental pour créer toute une classe d’applications respectueuses de la vie privée qui maintiennent certains états hors chaîne, mais en chaîne, vous pouvez vérifier que tout ce qui se passe hors chaîne est correct.

Les développeurs d'applications décident du type de protection de la confidentialité dont leurs applications ont besoin et utilisent ces supports natifs pour combiner des stratégies de chiffrement en chaîne, hors chaîne et en chaîne afin de résoudre les problèmes de confidentialité qu'ils peuvent rencontrer.

**Q11 : Existe-t-il davantage de prise en charge native de la confidentialité sur Sui ? **

La communauté réfléchit au soutien dont les développeurs ont besoin pour rédiger des contrats intelligents dans un environnement plus respectueux de la vie privée, et la preuve sans connaissance en fait partie. Certaines personnes peuvent penser que Sui a besoin de fonctions mathématiques ou cryptographiques plus générales sur la chaîne. Nous aimerions voir les concepteurs de contrats intelligents fournir des commentaires sur ce qui manque, et il existe toute une classe d'autres techniques qui peuvent être utilisées pour préserver la confidentialité, comme le calcul multipartite ou le matériel fiable. Différentes blockchains ont été développées dans ces directions, et celles-ci nécessitent des systèmes supplémentaires très complexes. Il doit y avoir suffisamment de preuves dans la communauté que les gens veulent ces technologies, car elles représentent des changements fondamentaux dans l'architecture de Sui. Mais si la communauté souhaite aller dans cette direction, il existe un processus permettant de proposer des moyens d'ajouter des protections de la vie privée.

**Q12 : Comment pensez-vous que Sui va évoluer dans les 6 à 12 prochains mois ? **

Cela dépend du type d'applications que les gens créent sur le Sui, et à court terme, de nombreuses améliorations concerneront les applications que les gens créent réellement. Dans une perspective à très long terme, selon les normes blockchain, 6 à 12 mois peuvent être considérés comme une période très longue. Nous améliorerons le protocole Sui Lutris pour obtenir une latence plus faible, des protocoles plus simples et améliorer l'échelle de Sui. De plus, cela rendrait l'économie plus efficace, en permettant aux nœuds de validation de fonctionner sur un matériel plus contraint et d'utiliser le matériel existant pour exécuter réellement des transactions plutôt que de faire de la cryptographie ou d'autres frais généraux de la blockchain. C'est ce que nous nous attendons à voir.