Écrit par : Réseau Sui

Sui est une chaîne publique L1 repensée et construite à partir des premiers principes, visant à fournir aux créateurs et aux développeurs une plateforme de développement capable d'héberger le prochain milliard d'utilisateurs du Web3. Les applications sur Sui sont basées sur le langage de contrat intelligent Move et sont évolutives horizontalement, permettant aux développeurs de prendre en charge un large éventail de développements d'applications rapidement et à faible coût. Le réseau principal Sui a été officiellement lancé le 3 mai 2023.

Cet article servira de référence rapide aux développeurs sur les meilleures pratiques sur Sui Network.

Déplacer les connaissances générales

Apprenez-en davantage sur les mises à niveau des packages et écrivez du code convivial pour la mise à niveau.

Les packages sont immuables et le code du package vulnérable peut être appelé pour toujours. La solution consiste à ajouter une protection au niveau de l'objet. Si vous mettez à niveau un package de P vers P', les autres packages et clients qui dépendent de P continueront à utiliser P au lieu de se mettre automatiquement à jour vers P'. Par conséquent, le code qui dépend à la fois du package et du client doit être mis à jour pour pointer explicitement vers P'. Les packages qui devraient être étendus par des packages dépendants peuvent éviter de rompre leurs extensions précédentes à chaque mise à niveau en fournissant une interface (immuable) conforme à la norme dans toutes les versions. En prenant le pont inter-chaînes Wormhole comme exemple, les messages sont envoyés via Wormhole en tant que pont. Pour générer un package d'extension pour l'envoi de messages, vous pouvez utiliser l'instruction prepare_message dans n'importe quelle version du package Wormhole pour générer un MessageTicket et le client. Le code qui envoie le message doit transmettre le MessageTicket à publi_message dans le dernier package de version. Les fonctions publiques ne peuvent pas être supprimées ou modifiées, mais les fonctions publiques (amies) le peuvent. Vous êtes libre d'utiliser les fonctions publiques (ami) ou uniquement visibles par vous-même, à moins que vous ne souhaitiez rendre la fonction de la bibliothèque maintenant publique pour toujours. Vous ne pouvez pas supprimer des types de structure, ajouter de nouveaux champs (bien que vous puissiez ajouter des champs dynamiques) ou mettre à niveau de nouvelles fonctionnalités. Réfléchissez bien lorsque vous ajoutez de nouveaux types, une fois ajoutés, ils sont là pour toujours !

Utilisez des collections vectorielles (telles que vector, VecSet, VecMap, PriorityQueue), avec un maximum de 1 000 éléments de données.

Les collections qui utilisent la prise en charge des champs dynamiques (telles que Table, Bag, ObjectBag, ObjectTable, LinkedTable) sont utilisées pour toute collection permettant à des tiers d'ajouter des collections plus grandes et des collections de taille inconnue. Les objets Sui Move ont une taille maximale de 250 Ko - toute tentative de création d'un objet plus grand entraînera l'abandon de la transaction. Veuillez vous assurer que votre objet ne dépasse pas la taille de la collection prise en charge par le vecteur.

Si votre fonction f nécessite un paiement de la part de l'appelant, par exemple via SUI, utilisez la fonction fun f(payment: Coin) au lieu de la fonction fun f(payment: &mut Coin, montant: u64). C'est plus sûr pour l'appelant car il sait exactement combien payer et n'a pas besoin de s'appuyer sur la fonction f pour extraire le montant correct.

Aucune petite optimisation de la consommation de gaz n’est requise. Lors du calcul du coût sur Sui, il est arrondi au seau le plus proche, de sorte que seules des fluctuations très brusques provoqueront des changements de gaz. Surtout si votre offre se situe déjà dans la fourchette de prix la plus basse, elle ne peut pas être moins chère. Veuillez vous référer à l'image ci-dessous pour plus de détails.

Suivez les conventions de codage Move pour obtenir un style cohérent.

Composabilité Utilisez la norme d'affichage pour personnaliser la façon dont vos objets apparaissent dans les portefeuilles, les applications et les navigateurs. Évitez d'utiliser la fonction "self-transfer" - il est possible à tout moment de renvoyer obj depuis la fonction courante au lieu d'écrire transfer::transfer(obj, tx_context::sender(ctx)), ce qui permet à l'appelant ou au bloc de transaction programmable (bloc de transaction programmable) utilise obj. Test Utilisez sui::test_scenario` pour simuler un scénario de test avec plusieurs transactions et plusieurs expéditeurs. Utilisez sui::test_utilsmodule pour de meilleurs messages de correction d'erreur avec les tests assert_eq, l'impression de débogage avec print et la destruction de tests uniquement avec destroy . Utilisez sui move test --coverage pour calculer les informations de couverture de code lors des tests, et utilisez sui move cover source --module pour afficher les lignes non couvertes surlignées en rouge. Si possible, il est recommandé de régler la couverture à 100 %. Applications Pour des performances optimales et une cohérence des données, les applications doivent soumettre des requêtes d'écriture et de lecture sur le même nœud complet. Dans le SDK TS, cela signifie que l'application doit utiliser l'API signTransactionBlock du portefeuille, puis soumettre la transaction en appelant execute_transactionBlock sur le nœud complet de l'application, plutôt que d'utiliser l'API signAndExecuteTransactionBlock du portefeuille. Cela garantit la cohérence de l'écriture avant lecture : les lectures à partir du nœud complet de l'application refléteront immédiatement les écritures de la transaction, plutôt que d'attendre un point de contrôle. Pour réduire la latence, si votre application a besoin de savoir qu'une transaction a été confirmée, mais n'a pas besoin de voir immédiatement les effets de la transaction ou de lire les objets/événements écrits par la transaction, utilisez executeTransactionBlock avec "showEffects": false et " showEvents": faux . Les applications doivent mettre en cache les données fréquemment lues localement plutôt que de les récupérer fréquemment à partir du nœud complet. Dans la mesure du possible, utilisez des blocs de transactions programmables pour combiner les fonctionnalités en chaîne existantes plutôt que de publier un nouveau code de contrat intelligent. Les blocs de transactions programmables permettent un traitement par lots à grande échelle et une composition hétérogène, réduisant encore davantage les frais de gaz déjà faibles. Les applications doivent laisser le budget du gaz, le prix du gaz et la sélection des pièces au portefeuille, ce qui offrira au portefeuille une plus grande flexibilité, et il est de la responsabilité du portefeuille de tester la transaction pour s'assurer qu'elle n'échoue pas. Signature Ne signez jamais deux transactions simultanées qui touchent le même objet exclusif, soit en utilisant l'objet exclusif séparément, soit en attendant la fin d'une transaction avant d'envoyer la transaction suivante. La violation de cette règle peut amener le client à tergiverser, verrouillant les objets exclusifs impliqués dans les deux transactions jusqu'à la fin de l'époque en cours. Toute commande client sui qui initie une transaction (par exemple, publication client sui, appel client sui) peut accepter l'indicateur --serialize-output pour générer une transaction base64 à signer. Sui prend en charge plusieurs schémas de signature pour la signature des transactions, y compris les multi-signatures natives.