Le plus nouveau
Restez informé des dernières publications.
Publications
2358
Déconstruire l'architecture de Sui : les deux moteurs de Narwhal et Bullshark
Les performances de la blockchain Sui (finalité quasi instantanée et évolutivité horizontale massive) ne sont pas magiques. Ils sont le résultat d'une architecture méticuleusement conçue qui s'écarte fondamentalement des conceptions monolithiques de chaînes de blocs. Au cœur de cette innovation se trouve un système sophistiqué qui sépare intelligemment la soumission des transactions du consensus, en utilisant deux composants clés : Narwhal et Bullshark. Pour vraiment comprendre ce qui rend Sui si puissant, nous devons déconstruire son architecture et voir comment ces éléments s'assemblent pour résoudre les principaux défis liés à la performance de la blockchain. L'objectif architectural : sortir du goulot d'étranglement du consensuel Les blockchains traditionnelles imposent chaque transaction, aussi simple soit-elle, par le biais d'un mécanisme de consensus mondial (comme le Proof-of-Work ou le Proof-of-Stake standard). Ce processus est intrinsèquement lent et nécessite beaucoup de communication, car chaque nœud du réseau doit se mettre d'accord sur l'ordre total exact de toutes les transactions. C'est le principal goulot d'étranglement qui limite la vitesse et fait grimper les coûts. Les architectes de Sui se sont rendu compte que la plupart des transactions ne nécessitaient pas cette approche autoritaire. Un simple transfert d'actifs entre particuliers ne dépend d'aucune autre transaction simultanée. L'objectif architectural principal de Sui était donc d'isoler le consensus et de ne l'utiliser qu'en cas d'absolue nécessité. Cela a conduit à un système de traitement à double chemin basé sur un moteur de mémorisation et de consensus révolutionnaire. Le grand fossé : transactions simples et transactions complexes La première étape et la plus critique du cycle de vie des transactions de Sui est le triage. Lorsqu'un utilisateur soumet une transaction, le réseau analyse immédiatement les objets avec lesquels il a l'intention d'interagir. Cette analyse classe la transaction selon l'un des deux chemins. • Transactions simples (objets détenus) : ce chemin concerne les transactions qui concernent uniquement des « objets détenus », c'est-à-dire des actifs contrôlés par une seule adresse. Les exemples incluent l'envoi de jetons SUI, le transfert d'un NFT ou l'utilisation d'un consommable dans un jeu que vous possédez. Ces transactions sont causalement indépendantes des autres. Ils ne nécessitent aucun ordre par rapport aux actions des autres utilisateurs. Pour cela, Sui utilise un processus léger appelé Byzantine Consistent Broadcast ou « voie rapide ». La transaction est envoyée à des validateurs, qui vérifient indépendamment sa validité et la signent. Une fois que l'expéditeur a atteint un quorum de signatures (un certificat), la transaction est définitive. L'ensemble de ce processus contourne le consensus formel et atteint sa finalité en moins d'une seconde. • Transactions complexes (objets partagés) : ce chemin est réservé aux transactions impliquant des « objets partagés », des objets sur lesquels plusieurs utilisateurs peuvent lire et écrire simultanément. Pensez au pool de liquidités d'une bourse décentralisée, à un compteur partagé dans un jeu multijoueur ou à un contrat d'enchère gouvernemental. Dans ces cas, l'ordre des opérations est crucial. Si deux utilisateurs tentent de se retirer du même pool en même temps, le réseau doit s'entendre pour déterminer qui était le premier. Pour ces transactions, Sui utilise son moteur de consensus complet : Narwhal et Bullshark. Le moteur de consensus : une plongée approfondie dans Narwhal et Bullshark Lorsqu'une transaction nécessite une commande, elle est envoyée au nouveau mécanisme de consensus de Sui. Ce moteur est unique car il dissocie la responsabilité de garantir la disponibilité des données (le mempool) de la responsabilité de convenir d'un ordre spécifique de ces données (le protocole de consensus). Le narval : le pool de mémoire à haut débit • Qu'est-ce que c'est : Narwhal est le protocole mempool du réseau. Son travail consiste à diffuser de manière fiable les transactions à tous les validateurs et à les regrouper en lots ordonnés, mais sans s'entendre pour l'instant sur une séquence de validation croisée de ces lots. • Comment ça fonctionne : chaque validateur gère son propre « travailleur » Narwhal qui reçoit les transactions. Ce travailleur les regroupe en un lot, crée une « collection » et diffuse cette collection aux « primaires » Narwhal de tous les autres validateurs. Les principaux collectent ces lots auprès de tous les validateurs et s'assurent qu'ils sont disponibles sur le réseau. Narwhal est basé sur une structure de graphe acyclique dirigé (DAG). Chaque lot fait référence aux lots précédents, créant ainsi un graphique de causalité. • Le problème qu'il résout : les mempools traditionnels sont souvent chaotiques et inefficaces, ce qui entraîne du spam sur le réseau et de mauvaises performances. Narwhal est un moteur à débit incroyablement élevé spécialement conçu pour résister aux attaques par déni de service (DoS) et garantir que tous les validateurs ont accès au même ensemble de transactions en attente sans être submergés. Il agit comme une couche de tri et de distribution hautement efficace et résiliente. Bullshark : le consensus efficace basé sur le DAG • Ce que c'est : Bullshark est le protocole de consensus par défaut qui fonctionne en plus du graphique structuré des lots de transactions fourni par Narwhal. (Une version antérieure appelée Tusk peut également être utilisée). • Fonctionnement : pendant que Narwhal construit le DAG, Bullshark le « parcourt » pour déterminer une commande totale définitive pour les lots de transactions. Il y parvient avec une charge de communication nettement inférieure à celle des protocoles BFT traditionnels. Au lieu de procéder à plusieurs tours de vote pour chaque bloc, Bullshark exploite les liens de causalité déjà établis dans le Narwhal DAG. Un leader propose une commande, et les validateurs votent simplement pour la confirmer. Si un leader est lent ou défectueux, le protocole peut rapidement passer au leader suivant dans un délai minimal, ce qui le rend très robuste. • Le problème qu'il résout : les protocoles de consensus standard tels que Tendermint nécessitent une communication synchrone intense entre tous les nœuds pour s'accorder sur chaque bloc, ce qui limite la vitesse. En utilisant le DAG fourni par Narwhal, Bullshark peut commander des transactions en moins d'étapes de communication, ce qui permet un consensus plus rapide et un débit plus élevé pour les transactions complexes qui en ont besoin. Tout mettre en place : le parcours d'une transaction • Soumission : un utilisateur signe et soumet une transaction. • Triage : les validateurs inspectent les objets de la transaction. • Voie A (voie rapide) : si elle ne concerne que des objets détenus, la transaction est diffusée, signée par un quorum de validateurs et finalisée. Fin du voyage. • Parcours B (chemin consensuel) : s'il s'agit d'un objet partagé, la transaction est soumise au mempool Narwhal. • Mempool/DAG : les travailleurs de Narwhal regroupent la transaction et la diffusent, créant ainsi un DAG de lots accessible à tous les validateurs. • Consensus : le protocole Bullshark fonctionne selon ce DAG, convenant d'une commande finale et totale des lots. • Exécution : une fois commandée, la transaction est exécutée par tous les validateurs et ses effets sont finalisés. Fin du voyage. Conclusion : une architecture conçue pour la performance L'architecture de Sui est une masterclass en matière d'efficacité technique. En refusant de traiter toutes les transactions de la même manière, il crée un système capable de gérer la grande majorité des actions simples des utilisateurs avec une rapidité sans précédent. Pour les interactions les plus complexes nécessitant une coordination, il déploie un moteur DAG de pointe qui dissocie la disponibilité des données de leur commande afin d'optimiser le débit. Cette conception à double moteur, alimentée par la voie rapide pour les transactions simples et la combinaison Narwhal/Bullshark pour les transactions complexes, permet à Sui de s'affranchir du moule traditionnel de la blockchain et d'offrir les performances requises pour un web3 véritablement évolutif et convivial3.
- Architecture
0+15
Erreur Sui Move - Impossible de traiter la transaction Aucune pièce de gaz valide n'a été trouvée pour la transaction
Quand je fais ça : //Séparer le paiement de la pièce principale const [PaymentCoin] = TX.SplitCoins ( tx.object (PrimaryCoin.CoinObjectId), [tx.pure.u64 (montant de paiement requis)] ) ; //Utilisez la pièce originale pour le paiement de l'essence TX.setGasPayment ([{ ID de l'objet : PrimaryCoin.CoinObjectID, version : PrimaryCoin.version, résumé : PrimaryCoin.Digest }]) ; Tx. Budget gazier fixe (10_000_000) ; Il se plaint du fait que les objets mutables ne peuvent pas apparaître plus d'une fois dans une transaction. Lorsque je supprime le paiement du gaz, il se plaint « Impossible de traiter la transaction » Aucune pièce de gaz valide n'a été trouvée pour la transaction. ». Ma fonction de contrat accepte 0,01 sui en échange d'un NFT
- Sui
- Transaction Processing
- Move
02
Procédure conceptuelle : votre première interaction avec un objet Sui
Visualisons comment cela fonctionne sans écrire une seule ligne de code. •Création (frappe) :Imaginez que vous jouez à un jeu et que vous gagnez une « épée légendaire ». Le contrat intelligent du jeu exécute une fonction qui crée un nouvel objet Sword. Cet objet possède des attributs tels que 100 dégâts, sa rareté : « Légendaire » et, surtout, un identifiant unique lui est attribué et son champ propriétaire est défini sur l'adresse de votre portefeuille. •Transfert : vous décidez de vendre l'épée à votre ami David. Vous signez une transaction qui dit : « Prenez l'objet avec l'ID 0x123... (l'épée) et transférez sa propriété à l'adresse de David. » Parce que vous êtes le seul à posséder l'épée, il s'agit d'une transaction simple. Il est envoyé aux validateurs, qui vérifient rapidement votre propriété, approuvent la modification et la finalisent en quelques millisecondes sans avoir besoin d'un consensus complet du réseau. •Modification : l'objet Sword peut avoir une fonction appelée upgrade (). Vous pouvez appeler cette fonction, qui peut consommer un objet « Pierre à aiguiser » que vous possédez également, pour modifier l'attribut de dégâts de l'objet Sword de 100 à 110. Encore une fois, puisque vous possédez les deux objets, il s'agit d'une transaction simple qui s'exécute rapidement. Conclusion : Construire pour l'avenir Sui n'est pas une amélioration progressive ; c'est un changement de paradigme. En passant d'une route à voie unique encombrée à une autoroute à plusieurs voies, il offre les performances nécessaires à la généralisation du Web3. Son modèle centré sur l'objet, associé à la sécurité du langage Move et à un mécanisme de gaz convivial, crée un environnement dans lequel les développeurs peuvent créer des applications complexes à haute fréquence, telles que des jeux en chaîne, des réseaux sociaux et des systèmes DeFi en temps réel qui n'étaient tout simplement pas possibles auparavant. Pour les utilisateurs, cela se traduit par une expérience plus rapide, moins chère et plus sûre, comblant enfin le fossé entre la promesse du web3 et la facilité d'utilisation fluide du web2.
- Sui
0
Une plongée en profondeur dans la blockchain Sui : bien plus qu'une simple couche 1
Dans un univers de blockchains de couche 1 en pleine expansion, il est facile de se perdre dans le bruit des promesses marketing et du jargon technique. Les nouveaux arrivants et même les passionnés de cryptographie chevronnés se demandent souvent : « Qu'est-ce qui rend celui-ci différent ? » En ce qui concerne la blockchain Sui, la réponse n'est pas une modification mineure ou une légère amélioration ; il s'agit de repenser fondamentalement la façon dont une blockchain devrait être conçue pour servir la prochaine génération d'applications décentralisées. Cet article présentera la philosophie de base de Sui, explorera les problèmes qu'elle vise à résoudre et illustrera pourquoi son modèle unique centré sur l'objet représente une avancée significative. **Le problème : s'affranchir des chaînes du traitement séquentiel ** Depuis des années, le monde de la blockchain est dominé par le modèle « basé sur les comptes », popularisé par Ethereum. Dans ce modèle, l'ensemble du réseau est essentiellement constitué d'un ordinateur géant partagé. Chaque transaction, qu'il s'agisse d'un simple transfert de jetons entre deux personnes ou d'une interaction complexe avec un protocole DeFi, doit être traitée dans un ordre spécifique. C'est ce que l'on appelle le traitement séquentiel. Imaginez une banque avec un seul caissier. Peu importe que vous souhaitiez simplement déposer un chèque ou que vous demandiez un prêt commercial complexe ; tout le monde doit faire la même ligne et être servi un par un. C'est précisément le goulot d'étranglement qui afflige les blockchains traditionnelles. Cela entraîne plusieurs problèmes critiques : • Débit faible : le réseau ne peut traiter que le nombre de transactions que le « guichet unique » peut traiter au cours d'une période donnée. • Latence élevée : votre simple transaction peut se retrouver bloquée derrière une transaction massive et gourmande en calculs, ce qui entraîne de longs délais d'attente. • Frais de gaz volatils : lorsque la ligne devient trop longue (forte demande du réseau), les utilisateurs sont contraints de faire des offres les uns contre les autres et de payer des frais exorbitants pour attirer l'attention du caissier. Cela rend de nombreuses applications, en particulier dans les domaines des jeux et des réseaux sociaux, non viables sur le plan économique. La solution de Sui : la révolution centrée sur l'objet Les développeurs de Sui, dont beaucoup venaient du projet avancé de blockchain Diem de Meta, ont reconnu que cette ligne de fichier unique n'était pas nécessaire. Ils ont posé une question simple mais profonde : « Pourquoi deux transactions totalement indépendantes devraient-elles s'attendre ? » Si Alice envoie un billet de concert NFT à Bob et que Charlie fabrique séparément une épée dans un jeu vidéo, ces deux événements n'ont aucun impact l'un sur l'autre. Ils ne concernent pas les mêmes données. Alors pourquoi devraient-ils être contraints de suivre un ordre séquentiel ? Cette idée a conduit au modèle centré sur l'objet de Sui. Au lieu d'un registre partagé unique (le modèle de compte), Sui voit le monde comme une collection d'objets programmables. Un objet peut être n'importe quoi : une pièce, un NFT, un personnage de jeu, une position DeFi ou un profil de réseau social. Chaque objet possède un identifiant unique au monde et est contrôlé par un propriétaire. La conséquence révolutionnaire de ce modèle est l'exécution parallèle de transactions. Pour en revenir à notre analogie avec les banques, Sui est comme une banque comptant des milliers de caissiers. Si votre transaction ne concerne que des objets que vous possédez (par exemple, le transfert de votre propre argent), vous pouvez vous rendre à n'importe quel guichet disponible sans attendre dans la file d'attente principale. C'est la « voie rapide ». Ce n'est que lorsqu'une transaction implique un objet partagé (comme un dépôt dans un pool d'investissement central utilisé par de nombreuses personnes) qu'elle doit passer par un processus de commande plus formel. **Principaux facteurs de différenciation qui redéfinissent l'expérience utilisateur Ce changement architectural permet la mise en place de plusieurs fonctionnalités uniques qui répondent directement aux problèmes des anciennes blockchains.** • Scalabilité massive grâce au parallélisme : en traitant la grande majorité des transactions en parallèle, Sui peut atteindre un débit théorique mesuré en centaines de milliers de transactions par seconde (TPS). Cette évolutivité horizontale signifie qu'à mesure que de nouveaux validateurs (ordinateurs) sont ajoutés au réseau, sa capacité augmente, de la même manière que l'ajout de serveurs à une application Web2. • Frais de gaz constamment bas et prévisibles : le modèle de gaz de Sui est conçu pour être stable. La capacité du réseau n'étant pas un goulot d'étranglement permanent, les guerres du gaz sont largement atténuées. En outre, Sui fait la distinction entre le coût d'exécution et le coût du stockage des données. Les utilisateurs paient une redevance unique pour stocker leurs objets en chaîne, créant ainsi un « fonds de stockage » qui indemnise les futurs validateurs pour le coût de conservation de ces données. Cela se traduit par des coûts de transaction plus prévisibles, ce qui est crucial pour les développeurs qui créent des entreprises durables. • Sécurité renforcée avec Sui Move : Sui utilise une version puissante du langage de programmation Move, spécialement conçu pour la gestion sécurisée des actifs numériques. Contrairement à d'autres langages de contrats intelligents où les actifs sont représentés sous forme d'entrées dans un registre, dans Move, un actif comme une pièce est une véritable ressource. Le système de types du langage garantit qu'il ne peut pas être dupliqué ou supprimé accidentellement, éliminant ainsi des classes entières de bogues et d'exploits courants au niveau du compilateur.
- Sui
0Move Language : le moteur des contrats intelligents de Sui
Lorsque vous entendez parler de construire sur Sui, un mot revient à plusieurs reprises :Déplacer. Il ne s'agit pas simplement d'un langage de contrat intelligent comme un autre, mais d'un modèle de programmation axé sur la sécurité conçu pour empêcher les bogues et les exploits qui ont affecté d'autres blockchains. Si vous souhaitez créer des applications robustes, sûres et performantes sur Sui, il est essentiel de comprendre Move. À la base, Move traite les actifs numériques comme des objets du monde réel. Si vous possédez une tasse, vous ne pouvez pas la « cloner » accidentellement en deux tasses ou oublier où vous l'avez mise : la propriété est toujours explicite. C'est ce que l'on appelle laprogrammation orientée ressources, et c'est l'une des plus grandes forces de Move. Cela garantit que les jetons, les NFT et autres actifs ne peuvent pas être dupliqués ou perdus sans que votre code ne le rende très intentionnel. Sur Sui, Move bénéficie d'une mise à niveau. Le modèle d'objet de Sui étend les capacités de Move en vous permettant de stocker des données directement dans des objets, de les transmettre entre transactions et de les muter en toute sécurité sans toucher à un état indépendant. Cela signifie que vous pouvez concevoir des applications qui évoluent horizontalement, en traitant les données de différents utilisateurs en parallèle, sans vous heurter à des goulots d'étranglement mondiaux. Un autre avantage important est letypage statique fort. Move vous oblige à définir exactement ce qui peut et ne peut pas arriver à vos données avant même que le code ne soit exécuté. Si votre contrat tente d'envoyer un jeton à une adresse non valide ou de modifier un objet immuable, il ne sera pas compilé. Bien que cela puisse sembler strict au début, cela réduit considérablement les erreurs d'exécution et les risques de sécurité. Les développeurs qui découvrent Move sont souvent confrontés à une courbe d'apprentissage, surtout s'ils utilisent Solidity ou JavaScript. Le passage de l'état d'esprit « variables et équilibres » à « objets et propriété » peut prendre du temps. Un bon point de départ est d'explorer les exemples officiels de Move de Sui, de bricoler de petits modules et d'expérimenter des transferts d'objets. Une fois que vous en avez compris la propriété et les capacités, tout le reste commence à fonctionner. En pratique, la philosophie de conception de Move vous évite des catégories entières d'erreurs coûteuses. Au lieu de s'appuyer sur des audits externes pour détecter les logiques dangereuses après le déploiement, le langage lui-même permet d'empêcher la compilation de ces erreurs. Combiné au haut débit et à l'exécution basée sur les objets de Sui, Move ouvre la porte à des applications décentralisées plus complexes, interactives et sûres que celles que la plupart des chaînes peuvent prendre en charge. En vous appuyant sur les principes de Move, à savoir traiter les actifs comme des ressources uniques, construire avec une saisie efficace et tirer parti de l'exécution parallèle de Sui, vous pouvez créer des contrats à la fois puissants et fiables. Dans le monde du Web3, c'est un sérieux avantage concurrentiel.
- Move
0
Le rôle du consensus en Sui
À la base, une blockchain est une machine à accords géante. Chaque nœud doit se mettre d'accord sur ce qui s'est passé, dans quel ordre et à qui appartient quoi. C'est ce qu'on appelle leconsensus, et c'est l'épine dorsale de la confiance dans un réseau décentralisé. Sui adopte une nouvelle approche à cet égard, en optimisant la vitesse, l'évolutivité et l'efficacité. Dans la plupart des blockchains, toutes les transactions, qu'elles soient simples ou complexes, passent par le même processus de consensus rigoureux. C'est comme si tout le monde attendait dans la même file de sécurité de l'aéroport, qu'ils transportent un seul sac à dos ou un conteneur entier. Sui change cela avec unsystème de transaction bimodal. Voici comment cela fonctionne : •Transactions simples— Si une transaction ne touche que des objets possédés (appartenant à un seul utilisateur), elle n'a pas besoin d'un consensus total. Sui utilise plutôt un mécanisme plus rapide appeléByzantine Consistent Broadcast. Cela permet de régler les transactions presque instantanément sans impliquer l'ensemble du réseau pour les commander. •Transactions complexes— Si une transaction implique des objets partagés (accessibles à plusieurs utilisateurs), Sui utiliseNarwhal & Bullshark, son protocole de consensus avancé. Cela garantit que tout le monde est d'accord sur l'ordre exact des événements, évitant ainsi tout risque de double dépense ou de mises à jour contradictoires. La beauté de cette conception réside dans le fait que le réseau ne gaspille pas de ressources pour commander des transactions qui n'ont pas besoin d'être commandées. En évitant le consensus dans de nombreux cas courants, Sui peut traiter beaucoup plus de transactions en parallèle que les chaînes traditionnelles. Pourquoi est-ce important ? •Latence réduite— Les joueurs d'un jeu peuvent améliorer leurs personnages instantanément sans avoir à attendre l'intégralité du réseau. •Débit élevé— Une application DeFi peut gérer des milliers de transferts de jetons indépendants en même temps. •Rentabilité— Les utilisateurs paient moins cher en gaz car le réseau n'est pas enlisé par des cycles de consensus inutiles. Imaginez un marché de jeux où des centaines de joueurs achètent et vendent des objets simultanément. Sur la plupart des blockchains, chaque transaction serait alignée, l'une après l'autre. Sur Sui, si les transactions ne concernent pas la même ressource partagée, elles peuvent toutes être confirmées en parallèle, comme des dizaines de stations de paiement en libre-service au lieu d'un seul caissier. Ce modèle de consensus hybride est l'une des plus grandes innovations de Sui. C'est pourquoi le réseau peut gérer des millions de transactions quotidiennes sans effort, tout en préservant la sécurité et la confiance.
- Sui
- Transaction Processing
0Le rôle du consensus en Sui
À la base, une blockchain est une machine à accords géante. Chaque nœud doit se mettre d'accord sur ce qui s'est passé, dans quel ordre et à qui appartient quoi. C'est ce qu'on appelle leconsensus, et c'est l'épine dorsale de la confiance dans un réseau décentralisé. Sui adopte une nouvelle approche à cet égard, en optimisant la vitesse, l'évolutivité et l'efficacité. Dans la plupart des blockchains, toutes les transactions, qu'elles soient simples ou complexes, passent par le même processus de consensus rigoureux. C'est comme si tout le monde attendait dans la même file de sécurité de l'aéroport, qu'ils transportent un seul sac à dos ou un conteneur entier. Sui change cela avec unsystème de transaction bimodal. Voici comment cela fonctionne : •Transactions simples— Si une transaction ne touche que des objets possédés (appartenant à un seul utilisateur), elle n'a pas besoin d'un consensus total. Sui utilise plutôt un mécanisme plus rapide appeléByzantine Consistent Broadcast. Cela permet de régler les transactions presque instantanément sans impliquer l'ensemble du réseau pour les commander. •Transactions complexes— Si une transaction implique des objets partagés (accessibles à plusieurs utilisateurs), Sui utiliseNarwhal & Bullshark, son protocole de consensus avancé. Cela garantit que tout le monde est d'accord sur l'ordre exact des événements, évitant ainsi tout risque de double dépense ou de mises à jour contradictoires. La beauté de cette conception réside dans le fait que le réseau ne gaspille pas de ressources pour commander des transactions qui n'ont pas besoin d'être commandées. En évitant le consensus dans de nombreux cas courants, Sui peut traiter beaucoup plus de transactions en parallèle que les chaînes traditionnelles. Pourquoi est-ce important ? •Latence réduite— Les joueurs d'un jeu peuvent améliorer leurs personnages instantanément sans avoir à attendre l'intégralité du réseau. •Débit élevé— Une application DeFi peut gérer des milliers de transferts de jetons indépendants en même temps. •Rentabilité— Les utilisateurs paient moins cher en gaz car le réseau n'est pas enlisé par des cycles de consensus inutiles. Imaginez un marché de jeux où des centaines de joueurs achètent et vendent des objets simultanément. Sur la plupart des blockchains, chaque transaction serait alignée, l'une après l'autre. Sur Sui, si les transactions ne concernent pas la même ressource partagée, elles peuvent toutes être confirmées en parallèle, comme des dizaines de stations de paiement en libre-service au lieu d'un seul caissier. Ce modèle de consensus hybride est l'une des plus grandes innovations de Sui. C'est pourquoi le réseau peut gérer des millions de transactions quotidiennes sans effort, tout en préservant la sécurité et la confiance. Si vous êtes prêt, je peux maintenant lireArticle 4 — Move Language : Powering Sui's Smart Contractsafin que nous ayons les quatre premiers complètement peaufinés.
- Sui
- Architecture
- SDKs and Developer Tools
- Transaction Processing
- Security Protocols
0Comprendre le modèle centré sur l'objet de Sui
La plupart des blockchains considèrent les jetons et les états des contrats intelligents comme des entrées dans un grand livre partagé, mais Sui renverse la situation. Au lieu de travailler avec un énorme État mondial, Sui est construit autour d'objets, des éléments de données autonomes qui vivent en chaîne et peuvent être détenus, transférés ou modifiés. Pensez à des objets tels que des colis dans un bureau de poste. Chacun possède un identifiant unique, un propriétaire défini et un contenu spécifique. Le travail de la blockchain consiste à s'assurer que ces colis ne peuvent pas être volés, dupliqués ou modifiés sans le consentement du propriétaire. Dans Sui, un objet peut être n'importe quoi : une pièce de monnaie, un NFT, un personnage de jeu, un terrain dans un métaverse ou même la structure de données interne d'un contrat intelligent. Il existe deux principaux types d'objets dans Sui : •Objets possédés : ils appartiennent à une adresse spécifique. Seule cette adresse (ou ses contrats intelligents autorisés) peut les modifier. •Objets partagés : accessibles à plusieurs utilisateurs. Cela nécessite un ordre des transactions et un consensus plus stricts, car plusieurs personnes peuvent interagir avec elles en même temps. La véritable magie vient du design deMove, axé sur les ressources. Dans Sui, les objets sont stockés en tant que ressources, ce qui signifie qu'ils ne peuvent pas être copiés ou supprimés accidentellement. Si vous transférez un objet, l'original disparaît : pas de doublons, pas d'entrées fantômes. Cela permet de garantir la sécurité et la prévisibilité du système. Lorsque vous envoyez une transaction en Sui, vous dites essentiellement : « Je veux prendre cet objet, y faire quelque chose et en produire une nouvelle version ». La blockchain vérifie que vous êtes bien propriétaire de l'objet et que votre action est autorisée, puis met à jour l'état en conséquence. Pour les développeurs, cette approche change la donne. Cela signifie : • Vous pouvez concevoir des applications où chaque actif est un citoyen de première classe, et pas seulement une ligne de base de données. • Les transactions impliquant des objets non liés peuvent être exécutées en parallèle, ce qui rend le réseau beaucoup plus rapide que les chaînes traditionnelles. • Des objets de jeu complexes, des positions DeFi ou des informations d'identité peuvent exister sous forme d'objets sécurisés et transférables. Voici un exemple rapide : imaginez que vous créez une place de marché pour les épées du jeu. Chaque épée est un objet doté de caractéristiques telles que la puissance d'attaque, la durabilité et la rareté. Lorsqu'un joueur améliore son épée, il remplace l'ancien objet par un nouvel objet dont les statistiques sont mises à jour. La blockchain garantit que seul le propriétaire légitime peut effectuer ce changement, et personne d'autre ne peut dupliquer l'épée. Comprendre ce modèle centré sur l'objet est essentiel pour créer des applications véritablement interactives et évolutives sur Sui. Cela vous permet de passer de la « mise à jour des variables d'un contrat global » à la « transmission d'actifs similaires à ceux du monde réel de manière sécurisée et vérifiable ».
- Sui
- Architecture
0
Feuille de route 2025 de Sui : innovations techniques pour une adoption massive
Sui, lancé en 2023, est sur le point d'être adopté en masse avec sa feuille de route 2025. Avec 2,2 milliards de dollars de TVL et 8 millions de portefeuilles, le jeton SUI de Sui anime son écosystème. Aperçu de Sui : Les plus de 120 000 TPS et les faibles frais de Sui permettent de diffuser des DApps sur le marché de masse. zkLogin et le sponsoring de gaz stimulent l'adoption, tandis que Mysticeti v2 améliore les performances. Architecture : Le modèle centré sur l'objet et Mysticeti prennent en charge le traitement parallèle, la mise à l'échelle horizontale garantissant les capacités futures. La complexité peut ralentir l'adoption par les développeurs. SDK et outils pour développeurs : Les SDK et les réseaux de test de Sui rationalisent le développement, tandis que Move garantit la sécurité. Le Move Registry améliorera la composabilité et favorisera son adoption. Traitement des transactions : l'exécution parallèle et la finalité inférieure à la seconde prennent en charge les DApps à grande échelle. Mysticeti v2 réduira la latence, améliorant ainsi l'adoption par les utilisateurs. Protocoles de sécurité : Les règles de propriété de Move et le BFT de Mysticeti garantissent la confiance. Les portefeuilles zkLogin et eDDSA favorisent une adoption sécurisée pour les utilisateurs traditionnels. NFT : les NFT dynamiques permettent des applications évolutives, avec des frais peu élevés qui stimulent l'engagement. SuiBridge étendra l'adoption inter-chaînes, améliorant ainsi les marchés. Move : la conception sécurisée de Move prend en charge les futures DApps, SuiVim optimisant l'exécution. Le Move Registry favorisera l'adoption par les développeurs en 2025. La feuille de route 2025 de Sui tire parti des innovations techniques pour une adoption massive, façonnant ainsi l'avenir du Web3.
- Sui
- Architecture
- Transaction Processing
0Concevoir des transactions Sui économes en gaz — Un guide pratique
Sui est déjà connue pour ses frais de gaz très bas par rapport à de grands noms comme Ethereum ou Solana, mais « bas » ne signifie pas « gratuit ». Si vous créez une application à grande échelle, en particulier une application qui gère des milliers de transactions par jour, même une infime inefficacité dans chaque transaction finira par vous coûter cher. Beaucoup de développeurs tombent dans le piège de la pensée suivante : * « Si je regroupe toutes mes actions dans une seule transaction importante, ce sera plus efficace. » * En Sui, ce n'est pas toujours vrai. Chaque fois que vous ajoutez d'autresobjets d'entrée(les actifs de la chaîne que votre transaction lit ou modifie), la complexité augmente. Cela peut faire dépasser le budget d'essence de votre transaction ou provoquer des erreurs de « panne de gaz », en particulier lors de la gestion d'opérations en vrac. ####Étape 1 : Profil avant d'optimiser La première étape vers l'efficacité énergétique consiste à comprendre votre consommation actuelle. Sui vous offre un moyen simple de le faire à l'aide du --gas-budgetdrapeau de la CLI. En simulant vos transactions pour différents budgets de gaz, vous pouvez voir la quantité de gaz dont elles ont réellement besoin. Cela vous permet de déterminer si une seule « méga-transaction » consomme beaucoup plus d'essence qu'elle ne le devrait. Par exemple : sui client call --function my_function \ --module my_module \ --package \ --args \ --gas-budget 2000 Si vous voyez la transaction échouer à moins que vous ne définissiez un budget d'essence énorme, c'est votre drapeau rouge. ####Étape 2 : décomposer les transactions importantes Au lieu de tout regrouper en une seule fois, divisez-le en petits groupes logiques. Supposons que votre DApp crée de nouveaux NFT, les transfère aux utilisateurs et mette à jour certaines métadonnées, le tout en une seule transaction. Il s'agit de trois opérations distinctes, chacune avec ses propres lectures et écritures d'objets. Une meilleure approche : Transaction 1 → Créer des NFT Transaction 2 → Transférer des NFT Transaction 3 → Mettre à jour les métadonnées En les séparant, vous réduisez le nombre d'objets en entrée à chaque étape, ce qui réduit les risques d'atteindre la limite de gaz ou d'erreurs de version de l'objet. ####Étape 3 : signatures par lots dans le SDK Si vous utilisez le SDK Sui JavaScript, il existe un joyau caché : vous pouvez signerplusieurs actions dans un lot, puis les envoyer ensemble. Cela permet d'économiser du gaz en évitant les vérifications répétées des signatures, qui peuvent s'accumuler dans les situations de volume élevé. Le processus est simple : Créez plusieurs blocs de transactions en mémoire. Signez-les tous en même temps. Envoyez-les en un seul appel RPC. Mais il y a un hic : vous devezactualiser l'état de votre objetjuste avant d'exécuter le lot. Si le numéro de version d'un objet change alors que votre transaction est en attente, celle-ci échouera. ####Étape 4 : Utiliser des données immuables pour les constantes Voici une optimisation subtile mais puissante : les données immuables (objets qui ne changent jamais après leur création) sonten lecturegratuitement**dans Sui. Si vous stockez les mêmes valeurs à plusieurs reprises dans des objets modifiables, tels que des prix par défaut, des options de configuration ou des identifiants de référence, vous faites en sorte que vos transactions soient inutiles. Au lieu de cela : Stockez ces constantes en tant qu'objets immuables une seule fois. Référencez-les dans vos transactions au lieu de les copier à chaque fois. Ainsi, vos transactions ne gaspillent pas d'énergie à lire ou à écrire les mêmes données à plusieurs reprises. ####Étape 5 : Gardez un état d'esprit économe en essence L'optimisation pour le gaz ne consiste pas seulement à économiser quelques centimes ; il s'agit de rendre votre DAppplus fiable. Lorsque vos transactions sont allégées, elles échouent moins souvent, s'exécutent plus rapidement et sont plus faciles à déboguer. Au fil du temps, ces économies s'accumulent, à la fois en termes d'argent et en termes de fluidité de l'expérience utilisateur. Principaux points à retenir : Profilez les transactions avant de les optimiser. Divisez les grosses transactions en plus petites. Signatures par lots à économiser lors de vérifications répétées. Stockez les constantes comme immuables pour éviter des coûts de gaz inutiles. Actualisez toujours l'état des objets avant d'envoyer une transaction. Maîtrisez ces habitudes dès le début et vous éviterez de douloureux problèmes de desquamation plus tard. Les frais peu élevés de Sui sont un cadeau, mais seulement si vous les traitez avec respect.
- Sui
- SDKs and Developer Tools
- Transaction Processing
0
