Le fondateur de Sui explique l'architecture de la blockchain haute performance : avantages des chemins rapides et de consensus.

Récemment, nous avons interviewé un expert renommé dans le domaine de la blockchain, pour discuter de la complexité et de l'évolutivité de l'infrastructure Sui, ainsi que de la manière dont le système de traitement des transactions de Sui contribue à un réseau haute performance. Cet expert est professeur dans le domaine de la sécurité et de la vie privée dans une université réputée.

Voici le contenu de cette interview :

Q1 : Vous venez du domaine académique, pouvez-vous nous parler de vos axes de recherche ?

Je suis professeur dans une université bien connue, et mes recherches portent, de manière générale, sur la sécurité et la vie privée. Au début du 20ème siècle, j'ai effectué pas mal de recherches sur les systèmes pair à pair et les systèmes anonymes, dont beaucoup étaient de grands systèmes distribués axés sur le stockage. Lorsque toute la Blockchain a commencé à se concentrer davantage sur l'exécution, notamment avec Ethereum, je me suis intéressé aux registres distribués et à la Blockchain ainsi qu'à la manière d'exécuter des contrats intelligents. J'étais déjà très familier avec la caractéristique sans autorisation, grâce à mon travail sur les premiers systèmes pair à pair. Ainsi, mon groupe de recherche à l'université a commencé à explorer comment construire des systèmes plus performants. Nous avons fondé une entreprise pour commercialiser certaines de nos idées, et plus tard, l'équipe a été acquise par une grande entreprise technologique. Ensuite, nous avons aidé cette entreprise à proposer des solutions pour étendre la Blockchain. Mais lorsque la solution n'a pas progressé, je suis parti pour continuer à chercher d'autres opportunités afin de réaliser l'idée d'une Blockchain à haute performance.

Q2 : Vous êtes toujours professeur, que pensez-vous qu'il y ait comme différence entre l'application et la recherche ?

Il n'y a en réalité pas de grande différence. Lorsque nous faisons des recherches, nous prenons en compte toutes les possibilités d'atteindre des objectifs spécifiques, comme construire un Blockchain haute performance ou des fonctionnalités spécifiques. Bien sûr, lors de la construction d'un Blockchain ou du choix des fonctionnalités spécifiques à utiliser dans un système réel, nous devons faire un choix parmi ces possibilités. Nous devons constamment juger laquelle de toutes ces bonnes idées est réellement la plus utile pour les gens ? Laquelle les gens recherchent-ils ? Quels sont les goulets d'étranglement dans l'adoption du Blockchain ? Qu'est-ce qui empêche les gens de réaliser ce qu'ils souhaitent faire ? Lors de la construction d'un système, vous continuerez à considérer toutes les possibilités et à essayer de comprendre les situations possibles à partir de la littérature académique, puis à choisir les éléments les plus pertinents. Ce n'est pas seulement un intérêt pour la connaissance, mais aussi la création de valeur pour les utilisateurs.

Q3 : Comment avez-vous déterminé quels problèmes résoudre lors du passage de la théorie à la pratique ?

Le principal problème que je résous dans ma recherche est la manière d'étendre les différentes fonctionnalités de la Blockchain. Je me concentre sur les aspects systémiques de la Blockchain, par exemple, comment augmenter le débit des transactions et réduire la latence. Les problèmes dans ce domaine sont évidents : chaque fois que nous voyons un contrat sur Ethereum devenir très populaire, la plateforme Ethereum ne peut pas supporter un tel volume de transactions, ce qui entraîne des congestions de transaction et une explosion des frais. Chaque fois que la Blockchain réussit, nous constatons que le volume de transactions qu'elle peut traiter dépasse les capacités existantes. Il est donc clair que le problème réside dans le fait qu'il n'y a pas assez de capacité pour répondre à ce que les gens veulent faire sur ces Blockchains. Ce n'est pas seulement une question de notre réflexion, nous avons vu cette situation se reproduire encore et encore. Pendant un certain temps, cela a été considéré comme un défi précieux, non seulement dans mon équipe, mais en réalité, l'ensemble de la communauté académique étudie la Blockchain, chacun trouvant différentes manières de résoudre ce problème. Maintenant, un nombre considérable de technologies ont été développées pour étendre les capacités de la Blockchain afin de relever ces défis. Mais à l'époque, il était bien connu que beaucoup de gens cherchaient à le résoudre de différentes manières.

Q4 : Quelles sont les différences et les avantages entre le réseau L2 proposé par les gens comme solution au problème d'évolutivité et l'établissement de nouveaux réseaux L1 comme Sui ?

L2 est une solution d'extension dans l'écosystème Ethereum. Cependant, pour les développeurs d'applications, l'utilisation des réseaux L2 peut être un peu délicate. Lorsqu'un réseau L2 tente d'interagir avec Ethereum, une activité de pontage doit avoir lieu, ce qui est le cas pour toute relation L2/L1. L'état représentant un coin, un actif ou autre dans L1 doit être reflété dans L2, et vice versa. En outre, L2 doit disposer de mécanismes permettant à L1 de vérifier tout ce qui s'y passe. Mais ce n'est que la première partie, à savoir que tout actif existant sur L1 doit être transféré vers L2, une certaine activité doit se produire sur L2, puis les actifs doivent d'une manière ou d'une autre être renvoyés à L1. C'est très ennuyeux.

Pour des actifs fongibles comme les tokens, cette activité de pont est relativement fluide, car les gens possèdent deux comptes et un middleware de pont. Mais pour des actifs plus généraux, ce n'est pas très efficace. Pour utiliser réellement un réseau L2 sur Ethereum pour développer des applications plus complexes que des tokens, vous avez besoin de contrats intelligents des deux côtés, un pour le minting et l'autre pour la destruction. Ils doivent naviguer dans deux écosystèmes différents, ce qui est une activité personnalisée pour chaque contrat. Vous ne pouvez pas simplement dire : je vais créer un réseau L2, puis emporter tous les actifs, puis agir selon ma volonté et les ramener, il n'y a pas ce concept. C'est un processus manuel, très sujet à erreur. Par conséquent, ce n'est pas une très bonne expérience. Imaginez que vous ayez des actifs sur plusieurs réseaux L2 différents, et qu'il y ait ces contrats intelligents personnalisés sur ces différents réseaux L2. Chaque fois que vous souhaitez agir sur un état situé sur un autre réseau L2, vous devez faire un pont jusqu'à L1, puis revenir à L2. Vous ne pouvez pas simplement dire : je viens de faire quelque chose sur cette blockchain, puis je veux faire autre chose sur une autre blockchain, je n'ai pas besoin de considérer sur quel L1 ou L2 cela se trouve. Tout est ici, je l'ai maintenant en main et je suis prêt à faire plus de transactions sur n'importe quel état que je souhaite accéder. C'est pourquoi l'expérience de la dispersion des états sur les réseaux L2 est mauvaise. Déplacer des actifs entre différentes chaînes est très délicat et évident pour les utilisateurs. C'est pourquoi les réseaux L2 ne m'ont jamais vraiment intéressé.

Un autre exemple est Cosmos, qui possède un écosystème très intéressant, adoptant une approche différente, en étendant via l'utilisation de différentes blockchains pour différentes applications. Nous pouvons effectuer des transactions à des vitesses différentes sur différentes chaînes, et lorsque nous avons besoin d'opérer entre différentes applications, nous pouvons faire le pont entre les actifs sur les chaînes, mais cela pose le même problème. Chaque fois que vous souhaitez utiliser différentes applications, vous devez d'abord effectuer une opération de pontage, ce qui est subtil et évident pour l'utilisateur, puis vous pouvez utiliser cette application et faire le pont en arrière. Vous constaterez que vous passez plus de temps à transférer des actifs d'une chaîne à une autre plutôt qu'à faire ce que vous voulez vraiment faire.

Sur Sui, notre solution consiste à établir une grande base de données qui contient en réalité tous les états répliqués par les nœuds vérifiés. Une fois que vous avez effectué une transaction, tous les états dans la même base de données peuvent être utilisés pour effectuer la transaction suivante, et l'utilisateur n'a pas besoin de déplacer constamment l'état des actifs entre L1 et L2.

Q5 : Sui Lutris est la base du protocole Sui, quelle est son innovation clé qui permet à Sui d'avoir des caractéristiques de haute capacité de traitement et de faible latence ?

Sui Lutris est composé de deux concepts clés : (1) pour de nombreuses opérations sur la blockchain, il n'est en réalité pas nécessaire d'obtenir un consensus ; (2) lorsque vous devez effectivement obtenir un consensus, il existe une méthode à très haut débit qui combine ces deux approches. Sui Lutris est au cœur du système distribué Sui, garantissant que lors de la réalisation de transactions sur un réseau distribué, les deux nœuds de validation respectant le protocole ne se retrouvent jamais dans un état d'incohérence. Ainsi, il ne peut pas arriver qu'un nœud de validation pense que vous avez dépensé un coin et l'avez envoyé à Alice, tandis qu'un autre nœud de validation pense que le même coin a en fait été envoyé à Bob.

Deux chemins différents, l'un n'exige pas de consensus (chemin rapide), l'autre nécessite un consensus (chemin de consensus). Lorsque l'objet sur lequel vous souhaitez agir appartient uniquement à vous, par exemple votre propre personnage NFT et le chapeau que vous souhaitez combiner afin que votre personnage puisse porter le chapeau, théoriquement, personne d'autre ne devrait pouvoir y agir. Dans ces cas, Sui utilise le chemin rapide, ce qui signifie que vous pouvez agir sur vos propres objets, vous pouvez obtenir la finalité de la transaction sans attendre le consensus, garantissant que la transaction se produise, le chapeau est porté sur la tête de votre NFT.

Mais dans certains cas, les transactions ne concernent pas seulement des objets qui vous appartiennent, elles sont partagées par de nombreuses personnes. Par exemple, s'il y a une enchère pour vendre de petits chapeaux, ce type d'enchère est représenté dans Sui comme un objet partagé. Les gens peuvent enchérir, et la personne qui fait la plus haute offre remporte le chapeau. Cette enchère est un objet qui n'appartient pas à une seule entité, chaque personne doit être en mesure d'enchérir, de partager et de mettre à jour l'état concernant 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 dessus, 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 à deux chemins de coexister et d'interagir entre des objets exclusifs possédés par des individus spécifiques et des objets partagés possédés par plusieurs personnes.

Ces deux chemins différents ont des avantages différents. Le chemin rapide pour les objets exclusifs a une latence très faible, nécessitant moins d'une seconde, ce qui est très rapide et peut être largement évolutif. La latence du chemin de consensus est plus élevée, dépassant généralement une seconde, avec une capacité également assez élevée, mais, par rapport au premier chemin, il est plus difficile à étendre. Sur Sui, ceux qui propulsent réellement des applications on-chain avec des millions de transactions quotidiennes utilisent généralement le premier chemin, et structurent dans une large mesure leur application pour effectuer le plus de transactions principalement sur des objets exclusifs, plutôt que sur des transactions partagées. D'autre part, les protocoles exécutant des travaux complexes (comme DeFi) mettent généralement en œuvre le deuxième type de transaction, car ils doivent combiner les enchères ou la liquidité de nombreuses personnes différentes pour exécuter des opérations.

Q6 : Les développeurs d'applications sur Sui peuvent-ils concevoir leurs applications pour tirer parti des chemins rapides ?

Oui, absolument. Je pense que c'est le travail essentiel des concepteurs d'applications d'extension. Les développeurs de contrats intelligents peuvent totalement contrôler si les objets sur lesquels ils opèrent dans le contrat sont des objets exclusifs d'une entité unique ou des objets partagés à un moment donné. Un truc pour étendre les applications dans Sui est de s'assurer que la plupart des opérations se déroulent essentiellement sur des objets exclusifs, car Sui peut gérer de nombreuses opérations que vous souhaitez avec une très faible latence, ce qui offre une expérience agréable. Les opérations nécessaires pour les jeux devraient être effectuées dans cette catégorie, car leur latence est très faible par rapport aux opérations qui nécessitent une médiation via un état partagé et des objets partagés. Une fois cliqué, la transaction peut être immédiatement finalisée sur le réseau.

Les concepteurs de contrats intelligents ont un contrôle total sur cela, ils peuvent essentiellement spécifier avec précision ce que sont les transactions dans chaque catégorie. Bien sûr, la première version du contrat peut considérer tout comme un état partagé, et tout passera par un chemin de consensus à latence plus élevée, mais à mesure que l'extension est nécessaire, les développeurs doivent réfléchir à la mesure dans laquelle ils peuvent se passer de ces parties.

Q7 : Comment les blocs de transaction programmables jouent-ils un rôle dans tout cela ?

Les blocs de transactions programmables peuvent jouer un rôle sur le chemin rapide ou le chemin de consensus. Si un bloc de transactions programmables n'implique que vos objets exclusifs, cela signifie que vous pouvez effectuer plusieurs opérations dans une seule transaction sur la chaîne. Prenons un exemple : supposons que vous êtes une application de plateforme de trading où de nombreuses personnes achètent et vendent différentes coins, vous pouvez effectuer une transaction sur la chaîne qui correspond conceptuellement à ce que les gens achètent et vendent. Mais comme vous êtes une bourse, elles vous appartiennent toutes, vous pouvez donc régler simultanément mille transactions, ce qui constitue le chemin rapide. D'autre part, si certains objets dans le bloc de transactions programmables sont partagés, cela entre dans le chemin de consensus, où le délai sera un peu plus élevé, pas moins d'une seconde mais quelques secondes.

Q8 : Cela fait plus de 100 jours que le réseau principal est en ligne, la performance de Sui a-t-elle confirmé votre théorie de recherche supposée ? Y a-t-il quelque chose qui vous a surpris ?

Il y a plusieurs éléments qui confirment la conception de Sui, mais il y a aussi des choses qui font réfléchir. L'un d'eux est que lors de périodes de volume de transactions particulièrement élevé, même à un moment donné, le volume quotidien des transactions dépasse même 60 millions, dont la plupart sont sur un chemin rapide. Sui Lutris est très évolutif et présente une latence très faible. Avant cela, il n'était pas clair si quelqu'un utiliserait ce chemin, mais lorsqu'un grand nombre de transactions et une faible latence sont nécessaires, il a été utilisé, et de manière très efficace ! C'est facile à voir, c'est cette méthode. À ces jours-là, le volume des transactions de Sui a dépassé toutes les autres.