Sui (SUI) : Comment fonctionnent les frais de gaz et de stockage
Sui est une blockchain à preuve d'enjeu déléguée dont l'état en chaîne est organisé en objets identifiés de manière unique. SUI est son actif natif, son jeton de gaz et de jalonnement. Cette page se concentre sur le fonctionnement des frais de gaz et de stockage de SUI et sur les vérifications que les utilisateurs doivent effectuer avant d'envoyer des fonds, de payer des frais ou d'utiliser le réseau.
Examinez une transaction Sui en identifiant les objets, les appels Move, la pièce de gaz et les changements de propriété qu'elle contient.
Objet :
Sui
Mode de marché :
Snapshot uniquement
Actif de frais :
SUI
Fuseau horaire :
UTC
Cette page ne vérifie pas un objet ID, un package, un validateur, un type de jeton ou une transaction et ne fournit pas de conseils en investissement.
Propriété du contenu : Équipe éditoriale de BitcoinToolkitRéférences techniques : documentation officielle du protocole et des développeurs.Approche de révision : les explications techniques sont vérifiées par rapport aux sources primaires et mises à jour lorsque le réseau ou l'actif change.Dernière revue du contenu : Dernier test d'intégration des données :
Comment fonctionnent les frais de gaz et de stockage SUI
Une transaction fournit une ou plusieurs pièces SUI pour le gaz et déclare un budget.
Flux de travail Sui, de la première décision de l'utilisateur à un résultat vérifié.
Calcul et stockage
Le gaz couvre les opérations de calcul et de stockage. Le prix du gaz interagit avec le calcul utilisé, tandis que les frais de stockage reflètent les données écrites sur la chaîne. Les remises de stockage peuvent restituer une partie des frais de stockage précédemment payés lorsque des données éligibles sont supprimées, de sorte que le changement de solde final peut différer d'une simple multiplication du gaz utilisé.
La pièce de gaz est elle-même un objet et peut être modifiée lors du paiement. Un utilisateur transférant un autre jeton a toujours besoin de gaz SUI dépensable. Le budget est une volonté maximale de payer, pas une garantie que chaque commande est sûre ou qu'une application congestionnée se terminera.
Estimer avant de signer
Les applications doivent utiliser les prix de référence actuels du gaz et les résultats de simulation ou d'exécution à sec, puis préserver une marge pour les changements d'état. Les utilisateurs doivent distinguer le gaz du SUI transféré, des dépôts d'objets, des frais d'application et de l'impact sur le prix du swap. Un budget insuffisant ou un objet obsolète peut échouer même si le portefeuille affiche un total de SUI suffisant.
La prochaine étape Sui
Sui stocke les actifs et l'état des applications sous forme d'objets avec des identifiants, des versions et une propriété explicite.
Des objets au lieu d'un compte générique
Chaque objet Sui a un ID unique, une version, un propriétaire et des métadonnées décrivant son utilisation la plus récente. Les objets Move contiennent des données d'application typées, tandis que les objets de package contiennent du bytecode Move publié. Un package n'est pas la même chose qu'un portefeuille ou un solde de jeton, et un nom de package familier n'est pas une preuve que son ID est canonique.
Les objets appartenant à une adresse peuvent être autorisés par l'adresse de contrôle. Les objets peuvent également appartenir à d'autres objets, être partagés pour un accès coordonné, être immuables ou être enveloppés dans un autre objet. Ces formes affectent la transférabilité et l'exécution. Un résumé de portefeuille qui ne liste que les montants de pièces peut masquer les changements d'objets qu'un appel d'application effectuera.
Les versions empêchent les utilisations conflictuelles
La version d'un objet change lorsque l'objet est modifié. Les transactions référencent des entrées spécifiques, ce qui permet au système de détecter les tentatives d'utilisation de versions obsolètes ou déjà consommées. Les utilisateurs qui réessayent une action d'application échouée doivent reconstruire à partir de l'état actuel de l'objet plutôt que de signer à plusieurs reprises une ancienne charge utile de transaction.
Un bloc de transactions programmables peut combiner plusieurs commandes et passer des résultats entre elles comme une seule action atomique.
Commandes, entrées et effets
Une transaction Sui identifie les objets d'entrée, les valeurs pures, un objet de gaz et des commandes telles que les transferts, les divisions de pièces, les fusions de pièces ou les appels Move. Les commandes peuvent alimenter les résultats dans des commandes ultérieures. La transaction complète réussit de manière atomique ou ses changements d'état prévus ne sont pas validés, bien que le gaz puisse toujours être facturé pour le traitement.
Les packages Move définissent les types et fonctions qui peuvent opérer sur les objets. Les règles de capacité et les signatures de fonctions contraignent si un objet peut être copié, supprimé, stocké ou utilisé comme clé. Les portefeuilles doivent afficher chaque appel de package et chaque transfert d'objet ; les utilisateurs doivent être prudents lorsqu'une interface réduit une transaction multi-commandes à un seul libellé de bouton vague.
Chemins d'exécution possédés et partagés
Les transactions utilisant uniquement des objets détenus indépendamment peuvent éviter l'ordonnancement global lorsque leurs dépendances sont claires. Les objets partagés nécessitent un ordonnancement par consensus afin que les utilisateurs concurrents s'accordent sur la séquence des changements. Cette différence prend en charge l'exécution parallèle mais ne garantit pas que chaque transaction ait la même latence.
Sui combine la preuve d'enjeu déléguée avec un consensus conçu pour un ordonnancement à faible latence de l'activité des objets partagés.
Ce sur quoi les validateurs s'accordent
Les validateurs traitent les transactions et participent au protocole de consensus Mysticeti. La délégation d'enjeu contribue au pouvoir de vote des validateurs et aux récompenses selon les règles actuelles du réseau. Le consensus ordonne l'activité qui nécessite une séquence commune, en particulier les transactions d'objets partagés, tandis que la propriété des objets permet aux transactions plus simples d'utiliser des chemins optimisés.
L'exécution finale ne certifie pas qu'un package est digne de confiance ou qu'un objet a une valeur économique. Elle confirme que le réseau a accepté la transaction selon les règles du protocole. Les applications doivent attendre les effets de transaction requis par leur flux de travail et doivent les vérifier à partir d'un nœud complet actuel ou d'un service RPC.
Limites du jalonnement
Déléguer SUI expose les utilisateurs à la performance des validateurs, au calendrier des récompenses et aux règles du protocole. Cela ne donne pas le contrôle des packages d'application ni ne protège contre une demande de signature malveillante. Les décisions de validation et de jalonnement doivent utiliser les données réseau actuelles plutôt que les taux historiques.
L'exécution centrée sur les objets récompense un examen plus détaillé des transactions.
Liste de contrôle des transactions
Vérifiez le mainnet, l'expéditeur, l'objet de gaz, le budget de gaz, les identifiants de package, les objets d'entrée, les appels d'objets partagés, les divisions de pièces, les transferts et la propriété résultante. Confirmez le type de jeton et l'adresse du package au lieu de faire confiance à un ticker. Reconstruisez les transactions obsolètes à partir des versions actuelles des objets.
Gardez SUI disponible pour le gaz.
Inspectez chaque commande programmable.
Vérifiez les identifiants de package et de type de jeton.
Traitez la simulation comme une estimation, pas comme un audit.
Ce que les utilisateurs de Sui doivent vérifier et pourquoi cette conception diffère
Comparez Aptos pour voir une autre implémentation de Move avec un modèle d'état différent. Les développeurs doivent consulter la documentation actuelle des packages et des transactions Sui. Parcourez le répertoire des outils pour les validateurs et convertisseurs généraux plutôt que de traiter une page de marché comme un inspecteur d'objets.
FAQ sur l'utilisation du réseau Sui
Qu'est-ce qu'un objet Sui ?
Il s'agit d'une unité d'état on-chain identifiée de manière unique, avec une version, un propriétaire et des données typées.
Qui paie les frais de transaction Sui ?
Les pièces SUI paient les frais de gaz liés au calcul et au stockage.
Pourquoi les objets partagés sont-ils différents ?
L'accès concurrent nécessite un ordre réseau, tandis que les objets détenus indépendamment peuvent utiliser des chemins d'exécution plus directs.
Que dois-je vérifier avant une transaction Sui ?
Vérifiez la destination officielle, le réseau actuel, la représentation de l'actif, le montant, le destinataire et les permissions demandées. Les transactions opèrent sur des objets détenus, partagés ou immuables via des packages Move. La propriété de l'objet détermine si une transaction peut utiliser un chemin à faible latence ou doit être ordonnée par consensus. Après confirmation, inspectez le solde résultant ou l'état du protocole au lieu de vous fier uniquement à un message de succès du portefeuille.
Limites connues
Les calendriers de gaz, le comportement des packages et le logiciel de consensus peuvent changer.
La simulation ne peut pas prouver qu'un package Move est sûr.
La page ne vérifie pas un objet, un package, un type de jeton ou un validateur.
Méthodologie des données de marché
La page utilise un instantané agrégé CoinGecko SUI/USD. Aucun graphique d'échange n'est rendu pour cette entité.
Source de l'instantané du marché
Données de marché agrégées CoinGecko (SUI/USD)
Cache
Le cache de l'instantané est d'environ 60 secondes.
Gestion des échecs
Les données mises en cache vérifiées sont étiquetées Cached ou Delayed. Les valeurs manquantes restent indisponibles.
