Sui experts expliquent la conception de Blockchain hautes performances : applications innovantes des chemins rapides et des chemins de consensus

Récemment, nous avons interviewé un expert en 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 facilite 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é renommée.

Voici le contenu de cette interview :

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

Je suis professeur dans une université, et mes recherches se concentrent, de manière générale, sur la sécurité et la confidentialité. Au début du 20e siècle, j'ai mené 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 la Blockchain est devenue davantage axée sur l'exécution, notamment avec Ethereum comme représentant, 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 cette caractéristique sans autorisation dans mes travaux sur les systèmes pair-à-pair précoces. Ainsi, mon groupe de recherche à l'université a commencé à travailler sur la manière de 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é rachetée par une grande entreprise technologique. Ensuite, nous avons aidé cette entreprise à proposer des solutions pour étendre la Blockchain. Mais lorsque les solutions n'ont pas progressé, je suis parti à la recherche d'autres opportunités pour réaliser l'idée d'une Blockchain à haute performance.

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

En réalité, il n'y a pas de grande différence. Lorsque nous faisons des recherches, nous prenons en compte toutes les possibilités pour 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 de la sélection des fonctionnalités spécifiques à utiliser dans un système réel, nous devons choisir l'une des possibilités. Nous devons constamment faire des jugements, parmi toutes ces bonnes idées, laquelle est réellement la plus utile pour les gens ? Laquelle les gens recherchent-ils ? Quels sont les goulots d'étranglement à l'adoption du Blockchain ? Qu'est-ce qui empêche les gens de réaliser ce qu'ils veulent 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 à l'application pratique ?

Le principal problème que je résous dans mes recherches est comment é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 une plateforme devenir très populaire, cette plateforme ne peut pas supporter un volume de transactions aussi important, ce qui entraîne des congestions 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 sa capacité actuelle. Il est donc clair que le problème réside dans l'insuffisance de capacité pour répondre aux attentes des utilisateurs sur ces Blockchains. Ce n'est pas seulement une question de notre propre 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é, dans l'ensemble du monde académique qui étudie la Blockchain, tout le monde essaie de résoudre ce problème de différentes manières. Aujourd'hui, 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 de nombreuses personnes tentaient de le résoudre de différentes manières.

Q4 : Quelles sont les différences et les avantages entre un réseau L2, qui est une solution proposée pour le problème d'évolutivité, et l'établissement de nouveaux réseaux L1 comme Sui ?

L2 est une solution d'extension dans un certain écosystème. Cependant, pour les développeurs d'applications, l'utilisation d'un réseau L2 peut être un peu délicate. Lorsqu'un réseau L2 tente d'interagir avec L1, des activités de pontage doivent être effectuées, ce qui est vrai pour toute relation L2/L1. L'état représentant la coin, les actifs ou d'autres contenus dans L1 doit être reflété dans L2, et vice versa. En outre, L2 doit également disposer de certains mécanismes pour que L1 puisse vérifier tout ce qui se passe en son sein. Mais cela n'est que la première partie, à savoir que tout actif existant sur L1 doit être transféré vers L2, des activités doivent se produire sur L2, puis les actifs doivent être retournés vers L1 d'une manière ou d'une autre. C'est très ennuyeux.

Pour les actifs fongibles comme les tokens, cette activité de pont s'est plutôt bien déroulée, car les gens ont 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 pour développer des applications plus complexes que les tokens sur L1, vous avez besoin de contrats intelligents des deux côtés, un pour mint et l'autre pour burn. 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 que je vais créer un réseau L2, puis emporter tous les actifs avec moi et agir selon ma propre volonté, puis les ramener, il n'y a pas un tel concept. C'est un processus manuel, très sujet aux erreurs. Ainsi, ce n'est pas une très bonne expérience. Imaginez que vous avez des actifs sur plusieurs réseaux L2 différents, et que vous avez ces contrats intelligents personnalisés sur ces différents réseaux L2. Chaque fois que vous voulez effectuer une opération sur un état situé sur un autre réseau L2, vous devez faire un pont tout le chemin de retour à L1, puis revenir à L2. Vous ne pouvez pas simplement dire que 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 penser à savoir sur quel L1 ou L2 cela se trouve. Tout est ici, je l'ai dans ma main maintenant, prêt à faire plus de transactions sur n'importe quel état que je veux accéder. C'est pourquoi l'expérience de disperser des états sur des réseaux L2 est mauvaise. Déplacer des actifs entre différentes chaînes est très délicat et cela est évident pour les utilisateurs. C'est pourquoi les réseaux L2 ne m'ont jamais vraiment intéressé.

Un autre exemple est un projet bien connu, qui possède un écosystème très intéressant et qui adopte une autre approche, à savoir l'expansion en utilisant différentes Blockchain pour différentes applications. Nous pouvons effectuer des transactions à différentes vitesses 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 également le même problème. Chaque fois que vous souhaitez utiliser différentes applications, vous devez d'abord effectuer l'opération de pontage, ce qui est subtil et évident pour les utilisateurs, puis vous pouvez utiliser cette application et faire le pont de retour. Vous vous rendrez compte que vous passez plus de temps à transférer des actifs d'une chaîne à une autre plutôt que de faire ce que vous voulez vraiment faire.

Sur Sui, notre solution consiste à établir une grande base de données, qui contient en fait 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 prochaine transaction, et les utilisateurs n'ont pas besoin de déplacer constamment l'état des actifs entre L1 et L2.

Q5 : Quelles sont les innovations clés de Sui Lutris, qui est la base du protocole Sui, permettant à Sui d'avoir des caractéristiques de haute capacité de traitement et de faible latence ?

Sui Lutris est composé de deux idées clés : (1) pour de nombreuses opérations sur la blockchain, il n'est en fait pas nécessaire d'atteindre un consensus ; (2) lorsque vous devez effectivement atteindre 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 des transactions sur un réseau distribué, deux nœuds de validation différents suivant le protocole ne se retrouveront jamais dans un état d'incohérence. Cela évite la situation où 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 ne nécessitant pas de consensus (chemin rapide), l'autre nécessitant un consensus (chemin de consensus). Lorsque l'objet que vous souhaitez manipuler n'appartient qu'à vous, par exemple votre propre personnage NFT et le chapeau que vous souhaitez combiner afin que votre personnage puisse porter le chapeau, en théorie, les autres ne devraient pas pouvoir les manipuler. Dans ces cas, Sui utilise le chemin rapide, ce qui signifie que vous pouvez manipuler vos propres objets, vous pouvez obtenir la finalité de la transaction sans attendre le consensus, garantissant que la transaction a lieu, le chapeau étant porté sur la tête de votre NFT.

Mais dans certains cas, les transactions ne concernent pas uniquement des objets qui vous appartiennent, mais qui sont partagés par de nombreuses personnes. Par exemple, s'il y a une enchère pour vendre des chapeaux, ce type d'enchère est représenté dans Sui comme un objet partagé. Les gens peuvent enchérir, la personne qui fait la meilleure offre remporte le chapeau. Cette enchère est un objet qui n'appartient pas à une seule entité, chaque personne doit pouvoir enchérir, partager et mettre à jour l'état des dernières offres, 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 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 voies de coexister et d'interagir entre des objets exclusifs appartenant à des individus spécifiques ou des objets partagés appartenant à plusieurs personnes.

Ces deux chemins différents ont des avantages différents. Le chemin rapide des objets exclusifs a une latence très faible, nécessitant moins d'une seconde, ce qui est très rapide, et peut être largement étendu. 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 font vraiment avancer les applications on-chain avec des millions de transactions quotidiennes utilisent généralement le premier chemin, et structurent largement leur application pour effectuer le maximum de transactions principalement sur des objets exclusifs, plutôt que sur des transactions partagées. D'autre part, les protocoles réalisant des travaux complexes (comme le DeFi) appliquent généralement le second 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'apps sur Sui peuvent-ils concevoir leurs apps pour profiter du chemin rapide ?

Oui, absolument. Je pense que c'est le travail central des concepteurs d'applications extensibles. Les développeurs de contrats intelligents peuvent entièrement contrôler si les objets sur lesquels ils opèrent dans le contrat sont des objets exclusifs d'une seule entité ou des objets partagés à un moment donné. Une astuce pour étendre les applications dans Sui est de s'assurer que la plupart des opérations sont essentiellement effectuées 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 bonne expérience. Les opérations nécessaires pour les jeux devraient être effectuées dans cette catégorie, et par rapport aux opérations qui nécessitent une médiation via des états partagés et des objets partagés, leur latence est très faible. Une fois cliqué, la transaction peut être immédiatement complété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 quelles transactions se trouvent 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'expansion est nécessaire, les développeurs doivent considérer dans quelle mesure cela peut être fait sans ces parties.

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

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

Q8 : La mise en ligne du réseau principal a plus de 100 jours, la performance de Sui a-t-elle confirmé vos hypothèses théoriques de recherche ? Y a-t-il quelque chose qui vous a surpris ?

Il y a plusieurs choses qui confirment la conception de Sui, mais il y a aussi certaines choses qui suscitent la réflexion. L'une d'elles est qu'à des moments où le volume des transactions est particulièrement élevé, même à un moment particulier, 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'il y a besoin de nombreuses transactions et d'une faible latence, il a été utilisé et très efficacement ! C'est facile à voir, c'est cette méthode. À ces jours-là, le volume des transactions de Sui a dépassé