Articles

Matériaux éducatifs et tutoriels sur Sui

Publications

harry phan65
Apr 13, 2025
Article
Mécanique de contrôle d'accès et de réception des objets
Il s'agit de la deuxième partie de la série « Les objets parent-enfant dans Sui Move ». Vous pouvez lire la partie 1 ici Contrôle d'accès aux objets transfer : :receive Mechanics Vous avez donc placé un objetXdans unPparent (en transférant X vers l'identifiant de P). Comment le récupérer ou l'utiliser ? 🤔 C'est là qu'intervient le mécanisme de réception spécial de Sui. Lorsqu'un objet est transféré à un parent, il n'apparaît pas automatiquement. Il se trouve là et appartient àP. Pour utiliser ou supprimer cet objet enfant dans une transaction, vous devez lerecevoir. Sui propose un moyen structuré de le faire à l'aide d'un ticket de réceptionet de la fonction transfer : :receive. ##Le ticket de réception Considérez la réception comme un ticket de réclamation pour un objet enfant de type T. Dans une transaction, au lieu de transmettre directement l'objet enfant (que vous ne possédez pas encore) à une fonction, vous transmettez une réception, essentiellement une référence à « l'objet portant l'ID Y qui appartient au parent X ». Cette réception est une structure Move spéciale qui contient l'ID, la version et le résumé de l'objet à recevoir. Il n'a que la capacité de dépôt, ce qui signifie qu'il peut exister de manière éphémère mais ne peut pas être stocké de manière persistante. En d'autres termes, il s'agit d'un ticket à usage unique intégré à une transaction. Comment obtenez-vous un reçu ? Généralement, en effectuant le transfert. Dans un bloc de transaction programmable (PTB), une étape peut transférer l'objetCau parentP, ce qui génère un ticket de réception que l'étape suivante peut utiliser. Si l'enfant était déjà assis chez le parent lors d'une transaction précédente, vous pouvez fournir une réception comme entrée pour une nouvelle transaction (le Sui SDK/CLI vous permet de spécifier un objet enfant par son identifiant et le parent pour générer le ticket). Important :Un objet reçu n'est pas l'objet lui-même, il ne vous en donne pas encore la propriété. Cela indique simplement que « l'objet de type T avec cet identifiant appartient à ce parent et j'ai l'intention de le prendre ». Pour récupérer réellement l'objet, vous devez appeler transfer : :receive : module example::toy_box { use sui::transfer::{Self, Receiving}; struct Toy has key { id: UID, name: vector } struct Box has key { id: UID } /// Remove a Toy child from a Box, returning the Toy to the caller. public entry fun take_toy(box: &mut Box, toy_ticket: Receiving): Toy { // Use the parent's UID and the Receiving ticket to get the Toy let toy = transfer::receive(&mut box.id, toy_ticket); // Now toy is an owned value we can return (or transfer to someone). toy } } Dans take_toy, le toy_ticket : Receiving représente un jouet qui appartient à la boîte. En appelant transfer : :receive (&mut box.id, toy_ticket), nous invoquons la logique native de Sui pour récupérer l'objet Toy hors de la boîte. Cela permet de réaliser quelques tâches essentielles : Ilvérifieau moment de l'exécution que le toy_ticket fait bien référence à un objet appartenant actuellement à la boîte (en utilisant l'UID du parent). Si quelque chose ne correspond pas (mauvais parent ou objet absent), il sera abandonné. Il renvoie ensuite l'objet Jouet réel en tant que valeur détenue dans la transaction, ce qui signifie que le Jouet est désormais sous le contrôle de notre fonction. Notez que nous avons dû transmettre &mut box.id. Sui impose que nous ayons uneréférence mutable à l'UID du parentpour appeler et recevoir. Il s'agit d'un contrôle d'accès intelligent : seul le module qui peut produire un UID &mut du parent peut autoriser la réception. En règle générale, le module de définition du type parent exposera une fonction telle que take_toy que les appels reçoivent en interne. Si le module parent n'expose aucune fonction qui donne un UID &mut (directement ou indirectement), aucun code externe ne peut récupérer ses enfants. De cette façon, le module destiné aux parents contrôle comment et quand il est possible d'accéder aux enfants. Dans l'exemple, Box possède un champ id : UID. Comme take_toy se trouve dans le même module, il peut emprunter &mut box.id. Les modules ou transactions externes peuvent appeler take_toy (box_obj, ticket) mais ils ne peuvent pas eux-mêmes appeler transfer : :receive sur Box car box.id est privé. Ce modèle garantit que seul le code autorisé peut récupérer les enfants.✅ Quid des objets imbriqués ? Si Toy était littéralement un champ à l'intérieur de Box (disons Box {id, toy : Toy}), nous n'aurions pas besoin de réception : le jouet serait accessible chaque fois que vous avez &mut Box. Mais cela signifie également qu'il est plus difficile de le retirer ou de le traiter séparément (c'est comme si cela faisait partie de la boîte). Avec les objets pour enfants, nous découplons le rangement : le jouet est séparé et doit être explicitement retiré. C'est pour cette raison que Sui exige le ticket de réception et la réception d'un appel. Cela permet de faire de la récupération de l'enfant une action autorisée. Exigence de référence mutable :Vous vous demandez peut-être pourquoi &mut UID et pas seulement &UID ? Mutable garantit que le parent est verrouillé pendant l'opération de réception, empêchant toute modification simultanée et garantissant que l'appelant a réellement le droit de modifier ce parent (ce qui implique généralement qu'il en est le propriétaire). Cela fait partie des contrôles dynamiques de propriété de Sui : en empruntant de manière modifiable l'UID du parent, Sui garantit qu'aucune autre transaction ou action parallèle ne peut interférer pendant que vous retirez l'enfant. C'est un peu comme verrouiller la porte des parents avant d'en retirer le contenu. Exemple d'utilisation dans un bloc de transaction :Supposons qu'Alice possède un objet Box et qu'elle souhaite mettre un objet Toy dans la boîte, puis peut-être Alors sors-le plus tard. Voici à quoi cela pourrait ressembler : Attachez le jouet à la boîte :**Alice appelle transfer : :public_transfer (toy, @) ; dans un PTB. Cela permet de transférer le jouet sous la boîte (nous utilisons public_transfer ici car il s'agit d'un contexte de transaction — nous y reviendrons bientôt). Maintenant, le jouet est un enfant de la boîte. -Lors de la même transaction ou d'une autre transaction, retrieve toy :Alice invoque example : :toy_box : :take_toy (box_obj,) où cette réception fait référence au jouet. Sous le capot, take_toy reçoit des appels, vérifie la relation et renvoie le Toy. Maintenant, le Toy serait une sortie de la transaction, se retrouvant généralement à l'adresse d'Alice (puisque nous l'avons renvoyé à partir d'une fonction de saisie). Principaux points à retenir : Les objets pour enfants ne sont pas accessibles par défaut ; vous avez besoin d'un ticket de réception et d'une fonction appropriée pour les sortir. Le module du parent décide de la manière dont vous pouvez récupérer (en fournissant une fonction avec &mut UID). transfer : :receive est utilisé dans le module de définition du parent pour les objets de ce module ou de ses amis. Si le type de l'enfant est défini ailleurs, vous aurez besoin d'une approche différente (entrez public_receive...). Avant de poursuivre, encore un détail : si un objet de type T n'a que la capacité clé (pas de magasin), Sui la considère comme un peu plus restreinte. De tels objets ne peuvent pas être reçus par code générique en dehors de leur module. En pratique, cela signifie que si T est une clé uniquement et devient un enfant, vous devrez gérer sa récupération dans son propre module ou dans le module du parent avec une règle personnalisée. Si T a également store, nous avons plus de flexibilité via public_receive. Explorons-la ensuite.
- Sui
2
harry phan65
Apr 12, 2025
Article
✏️ Objets parent-enfant dans Sui Move
Dans Sui Move, les objets peuvent posséder d'autres objets, tout comme les objets des comptes. Cela ouvre la voie à de nouveaux modèles de conception (et à quelques pièges) pour les développeurs. Dans ce guide, je vais décomposer les concepts d'objets parent-enfant dans Sui Move en quatre parties : 1.Introduction aux concepts parent-enfant dans Sui Move 2.Mécanique de contrôle d'accès et de réception des objets 3.Gestion intermodule des enfants avec public_receive 4.* Logique captivante et modèle de reçu de retour* À la fin, vous comprendrez comment imbriquer des objets, récupérer des objets enfants via transfer : :receive, gérer les enfants entre les modules avec public_receive et même créer des objets liés à l'âme qui renvoient en boomerang à leur propriétaire. Introduction aux concepts parent-enfant dans Sui Move ###Que sont les objets pour parents et enfants ? Dans Sui, chaque objet possède un identifiant unique et un propriétaire. Généralementle propriétaire est une adresse(comme le compte d'un utilisateur), mais le propriétaire peut aussi être un autre objet. Si l'objet A possède l'objet B, nous appelons A le parent et B l'enfant. L'enfant est propriétaire d'un objet plutôt que d'une adresse. Transfert vers des objets : Sui ne fait pas réellement la distinction entre une adresse et un identifiant d'objet. Les deux ne sont que des identifiants de 32 octets. Cela signifie que vous pouvez transférer un objet vers l'identifiant d'un autre objet de la même manière que vous le feriez vers l'adresse d'un utilisateur. Lorsque vous procédez ainsi, vous imbriquez effectivement un objet dans un objet parent. L'environnement d'exécution de Sui définit le champ du propriétaire de l'enfant sur l'identifiant du parent (au lieu d'une adresse) Alors pourquoi est-ce cool ? Parce que l'enfant conserve son propre identifiant unique et existe indépendamment dans le stockage, mais qu'il est désormais lié au parent. C'est comme si vous offriez à votre ami un objet de collection unique à conserver dans son casier : l'objet de collection conserve son identifiant et peut être suivi, mais le casier de votre ami est désormais répertorié comme son propriétaire. Il est important de faire la distinction entreObjets uniques, objets imbriqués et objets enfants : Objet unique (appartenant à l'adresse) :**Un objet normal appartenant à une adresse (par exemple, le compte d'un utilisateur). C'est le cas par défaut : pensez aux NFT, aux pièces de monnaie, etc., qui se trouvent directement dans le portefeuille de l'utilisateur. Chacune possède un identifiant unique et est de niveau supérieur en termes de stockage. Objet imbriqué (encapsulé) :Un objet qui est stocké *dans les données d'un autre objet* (par exemple, sous forme de champ dans une structure). Dans ce cas, l'objet interne est *encapsulé* etpas**ne constitue pas une entité de niveau supérieur distincte. Il n'apparaît pas par son identifiant dans le stockage global car il fait partie du contenu en octets du parent. En Sui, si vous placez un objet sous forme de champ dans un autre sans manipulation particulière, il est encapsulé. Objet enfant (appartenant à un objet) :*Un objet qui appartient à un autre objet *mais qui n'est pas directement encapsulé dans ses champs. L'enfant reste un objet de premier niveau distinct en stockage (avec son propre identifiant et ses propres données), et l'identifiant du parent est enregistré en tant que propriétaire dans les métadonnées de l'enfant. Cela signifie que vous pouvez interroger l'enfant ou y accéder par son identifiant (avec les autorisations appropriées). Il n'est pas physiquement intégré au contenu du parent, il est simplement détenu de manière logique. Pour utiliser notre analogie, c'est comme si vous aviez donné à votre ami votre objet de collection à conserver : il est toujours étiqueté et traçable individuellement, simplement rangé dans son casier. L'avantage de fabriquer un objet pour enfant (par transfert) au lieu de l'emballer est que la carte d'identité de l'enfant reste accessible de l'extérieur. Par exemple, les explorateurs ou les portefeuilles peuvent répertorier un objet enfant par identifiant, alors qu'un objet encapsulé est invisible en dehors de son parent. Les objets pour enfants conservent également des identifiants stables même lorsqu'ils passent d'un propriétaire à l'autre ou s'imbriquent dans des parents différents. C'est idéal pour des choses comme l'inventaire en chaîne ou les modèles « portefeuille dans un portefeuille », où vous souhaitez qu'un objet contenant puisse contenir de nombreux objets que d'autres peuvent encore référencer individuellement Propriété et accès : si un objet appartient à un autre objet, seul le propriétaire du parent peut généralement accéder à l'enfant ou l'utiliser. Il s'agit d'une forme d'autorisation dynamique. Par exemple, si Alice possède un objet parent P et que P possède l'enfant C, alors seule Alice (ou les transactions signées par Alice) peut manipuler C. Sui applique cette règle de sorte que posséder un parent revient à détenir les clés de tous ses enfants 🔑. Peut-être connaissez-vous : La fonction de transfert vers un objet de Sui nous donne essentiellement la propriété d'un objet semblable à un arbre. Un parent peut avoir de nombreux enfants (et ces enfants peuvent avoir leurs propres enfants, en formant une hiérarchie). Cela se fait en traitant les identifiants d'objets comme des adresses pour les transferts. Nous avons : Objets appartenant à l'adresse**(objets uniques normaux), Objets appartenant à un objet**(objets enfants, toujours de niveau supérieur mais liés à un parent), Objets encapsulés**(imbriqués dans les données d'un autre objet, pas de niveau supérieur). Dans les prochains articles, nous verrons comment récupérer ou interagir avec des objets enfants (puisqu'ils ne sont pas directement accessibles comme ceux dont l'adresse est propriétaire) et comment appliquer des règles les concernant.
- Sui
- Move
3
harry phan65
Apr 10, 2025
Article
Création d'une application de loterie NFT de nouvelle génération avec Sui Move et une interface utilisateur moderne
🧩 Création d'une application de loterie NFT de nouvelle génération avec Sui Move et une interface utilisateur moderne Il s'agit de votre guide ultime pour créer une application de loterie gamifiée alimentée par NFT à l'aide deSui Move, avec un support multi-tours, des systèmes de parrainage, une gouvernance DAO et un système de conception que la génération Z adorera. De l'architecture des contrats au flux de l'interface utilisateur, allons-y. 📦 Répartition des phases Phase 1 — Loterie de base Gameplay à plusieurs tours Billetterie NFT Système de récompenses de parrainage Vote DAO de base Phase 2 — Marché et gamification Intégration de la place de marché NFT Boosters (augmente les chances de gagner) Système Jackpot Des parachutages cachés Phase 3 — DAO et multichaînes Compatibilité inter-chaînes DAO avec propositions avancées Tarification dynamique Analyses en chaîne 🧠 Smart Contract : approfondissement de Sui Move Structure du contrat module nft_lottery_x::nft_lottery_x { use sui::object; use sui::balance::{Balance, zero}; use sui::coin::{Self, Coin}; use sui::clock::Clock; use sui::random::Random; use sui::event::emit; use sui::transfer; use sui::tx_context::TxContext; use std::option; use std::signer; const EGameNotStarted: u64 = 1000; const EGameAlreadyFinished: u64 = 1001; const EInvalidPayment: u64 = 1002; const ENoTickets: u64 = 1003; const EWinnerAlreadyChosen: u64 = 1004; const ENotWinner: u64 = 1005; public struct Game has key { id: UID, ticket_price: u64, start_time: u64, end_time: u64, total_tickets: u32, round: u32, winner: Option, balance: Balance, referral_bonus: u64, } public struct Ticket has key { id: UID, game_id: ID, ticket_number: u32, buyer: address, referrer: Option, } public struct GameCreated has copy, drop { game_id: ID, start_time: u64, end_time: u64, ticket_price: u64, } public struct TicketBought has copy, drop { game_id: ID, ticket_number: u32, buyer: address, referrer: Option, } public struct WinnerAnnounced has copy, drop { game_id: ID, winner_ticket: u32, round: u32, } public struct RewardClaimed has copy, drop { game_id: ID, ticket_number: u32, amount: u64, } public fun create_game( start_time: u64, end_time: u64, ticket_price: u64, referral_bonus: u64, ctx: &mut TxContext ) { let game = Game { id: object::new(ctx), ticket_price, start_time, end_time, total_tickets: 0, round: 1, winner: option::none(), balance: zero(), referral_bonus, }; emit(GameCreated { game_id: object::id(&game), start_time, end_time, ticket_price, }); transfer::share_object(game); } public fun buy_ticket( game: &mut Game, coin: Coin, clock: &Clock, referrer: Option, ctx: &mut TxContext ): Ticket { assert!(clock.timestamp_ms() >= game.start_time, EGameNotStarted); assert!(clock.timestamp_ms() (TicketBought { game_id: object::id(game), ticket_number: ticket.ticket_number, buyer: ticket.buyer, referrer: ticket.referrer, }); ticket } public entry fun determine_winner( game: &mut Game, rand: &Random, clock: &Clock, ctx: &mut TxContext ) { assert!(clock.timestamp_ms() >= game.end_time, EGameNotStarted); assert!(game.winner.is_none(), EWinnerAlreadyChosen); assert!(game.total_tickets > 0, ENoTickets); let mut generator = rand.new_generator(ctx); let winning_ticket = generator.generate_u32_in_range(1, game.total_tickets); game.winner = option::some(winning_ticket); emit(WinnerAnnounced { game_id: object::id(game), winner_ticket: winning_ticket, round: game.round, }); } public fun claim_reward( ticket: Ticket, game: Game, ctx: &mut TxContext ): Coin { assert!(object::id(&game) == ticket.game_id, EInvalidPayment); let ticket_num = ticket.ticket_number; assert!(game.winner.contains(&ticket_num), ENotWinner); let amount = game.balance.value(); let reward = game.balance.into_coin(ctx); emit(RewardClaimed { game_id: object::id(&game), ticket_number: ticket.ticket_number, amount, }); object::delete(object::id(&game)); reward } } Principaux points à retenir : ✅ Balancegarantit la sécurité des caractères et une manipulation correcte des pièces ✅ Optionindique clairement si un gagnant a été choisi ✅ Les événements offrent une traçabilité pour les frontends et les explorateurs 🛠 Commandes Sui CLI sui client call --package --module nft_lottery_x --function create_game --args --gas-budget 10000000 Pour acheter un billet, déterminer le gagnant ou réclamer une récompense, suivez des flux CLI similaires. 🔮 Ajouts futurs Logique de réinitialisation automatique pour le prochain round claim_reward Émettez plus d'événements tels que ReferralRewardDistributed Refactorisez les jackpots et les références dans des sous-modules Faites-moi savoir si vous voulez une partie 2 pour créer une interface utilisateur et l'intégrer sur Sui testnet !
- Sui
3
harry phan65
Apr 09, 2025
Article
Guide des transactions Sui : de la configuration à l'exécution et à la vérification
Guide des transactions Sui : de la configuration à l'exécution et à la vérification Si vous êtes curieux de connaître les détails de l'exécution de transactions sur la blockchain Sui et que vous souhaitez un guide pratique et détaillé qui vous guide à chaque étape. Dans cet article, nous allons explorer l'ensemble du processus, de la configuration de votre environnement client à la vérification des objets de votre portefeuille, en passant par le calcul des frais de gaz, la signature et l'exécution d'une transaction, et enfin la vérification de ses détails. Décomposons-le étape par étape : Qu'est-ce qui rend Sui si spécial ? 🔥 Sui propose une plate-forme hautement optimisée pour les applications décentralisées (DApps) et les contrats intelligents. Son design élégant en matière de gestion des frais de gaz et de logique de transaction en fait un terrain de jeu passionnant pour les développeurs qui cherchent à repousser les limites de la technologie Web3. N° 2. Pour commencer : configuration de l'environnement et configuration du portefeuille ⚙️ 2.1. Configuration de votre environnement client Sui Avant de vous lancer dans les transactions, assurez-vous que votre client Sui est correctement configuré. Sui prend en charge plusieurs réseaux (devnet, mainnet, testnet), et vous pouvez vérifier lequel est actif à l'aide de la commande ci-dessous : ➜ sui client envs ╭─────────┬─────────────────────────────────────┬────────╮ │ alias │ url │ active │ ├─────────┼─────────────────────────────────────┼────────┤ │ devnet │ https://fullnode.devnet.sui.io:443 │ │ │ mainnet │ https://fullnode.mainnet.sui.io:443 │ │ │ testnet │ https://fullnode.testnet.sui.io:443 │ * │ ╰─────────┴─────────────────────────────────────┴────────╯ Cela confirme que vous êtes connecté au réseau de test. Être sur le bon réseau est la première étape d'une transaction réussie. N° 2.2. Vérifier votre portefeuille actif Vérifiez ensuite l'adresse de votre portefeuille actif. Ceci est crucial car chaque transaction est liée à l'identité de votre portefeuille : ➜ sui client active-address 0x35370841d2e69b495b1e2f944a3087e4242f314e503691a00b054e0ee2a45a73 N° 2.3. Interroger des objets possédés À l'aide de l'API Suix_GetOwnedObjects, vous pouvez récupérer des informations sur les objets (comme les pièces) que vous possédez sur la blockchain. Cette commande vous permet de vérifier le solde de votre compte et les actifs disponibles pour les transactions : { "jsonrpc": "2.0", "id": 1, "method": "suix_getOwnedObjects", "params": [ "0x35370841d2e69b495b1e2f944a3087e4242f314e503691a00b054e0ee2a45a73", { "filter": { "MatchAll": [ { "StructType": "0x2::coin::Coin" } ] }, "options": { "showType": true, "showOwner": true, "showPreviousTransaction": true } } ] } Cette étape est essentielle pour vérifier que votre portefeuille contient les pièces nécessaires (dans ce cas, des pièces SUI) avant de tenter toute transaction. N° 3. Calcul du gaz : budgétisation des coûts de transaction 💸 Le gaz est le carburant qui alimente les transactions blockchain. Il est essentiel de comprendre à la fois le prix du gaz et le budget du gaz pour éviter les échecs de transaction. 3.1. Connaître le prix de l'essence Le prix actuel du gaz peut être récupéré à l'aide de l'appel d'API Suix_GetReferenceGasPrice : { "jsonrpc": "2.0", "id": 1, "method": "suix_getReferenceGasPrice", "params": [] } Si l'API renvoie « 1000 », cela signifie que chaque unité de gaz coûte 1 000 MIST. N'oubliez pas que 1 SUI est égal à 10^9 MIST, donc même de petits nombres dans MIST peuvent s'additionner lors de la budgétisation. 3.2. Établissement du budget du gaz Votre budget d'essence est la quantité maximale d'essence (en MIST) que vous êtes prêt à dépenser. Pour notre exemple, supposons que votre budget de gaz soit de 4964 000 MIST. Le coût total d'une transaction est généralement calculé comme suit : Coût total = coût de calcul + coût de stockage — Rabais d'entreposage Par exemple : • Coût de calcul : 1 000 000 MIST • Coût de stockage : 2 964 000 MIST • Rabais sur l'entreposage : 978 120 MIST Ainsi, le coût net devient 1 000 000 + 2 964 000 − 978 120 = 2 985 880 MIST. La définition précise de votre budget d'essence garantit que votre transaction dispose de suffisamment de fonds pour être exécutée avec succès. N° 4. Confectionner la transaction : une mince affaire de confiance 🔧 Avant d'envoyer une transaction en direct, il est préférable de procéder à un « essai à sec » pour détecter tout problème potentiel. Cela vous permet de valider la logique de transaction sans dépenser d'essence. #4.1. Création d'une transaction à sec Voici un exemple de fonction TypeScript qui montre comment préparer et exécuter une transaction à vide. Ce code explique comment fractionner les pièces et préparer les opérations de transfert : export const signSuiDryRunTransaction = async (requestParams: SignDryRequestParams): Promise => { const { gasPrice, privateKey, coinRefs, network, recipients } = requestParams; const keypair = Ed25519Keypair.fromSecretKey(privateKey); const tx = newTransaction(); // Configure gas payment, price, and sender tx.setGasPayment(coinRefs); tx.setGasPrice(gasPrice); tx.setSender(keypair.toSuiAddress()); // Split coins based on each recipient's amount const coins = tx.splitCoins(tx.gas, recipients.map((transfer) => transfer.amount)); recipients.forEach((transfer, index) => { tx.transferObjects([coins[index]], transfer.to); }); // Build and sign the transaction with the client const client = newSuiClient({ url: getFullnodeUrl(network) }); const bytes = await tx.build({ client }); const { signature } = await keypair.signTransaction(bytes); await verifyTransactionSignature(bytes, signature, { address: keypair.getPublicKey().toSuiAddress() }); return JSON.stringify([toBase64(bytes), signature]); }; Cette étape préliminaire est cruciale pour s'assurer que chaque détail est correct avant d'engager des fonds réels. N° 5. Signature et exécution de la transaction : tout mettre en place ✍️ Après un essai réussi, l'étape suivante consiste à signer et à envoyer votre transaction sur la blockchain. #5.1. Signature de la transaction Vous trouverez ci-dessous un exemple de fonction affiné qui signe la transaction avec le budget de gaz spécifié : const signSuiTransaction = async (requestParams: SignRequestParams): Promise => { const { gasBudget, gasPrice, privateKey, coinRefs, network, recipients } = requestParams; const keypair = Ed25519Keypair.fromSecretKey(privateKey); const tx = newTransaction(); // Set up gas parameters, including the gas budget tx.setGasPayment(coinRefs); tx.setGasPrice(gasPrice); tx.setGasBudget(gasBudget); tx.setSender(keypair.toSuiAddress()); // Split coins for each recipient const coins = tx.splitCoins(tx.gas, recipients.map((transfer) => transfer.amount)); recipients.forEach((transfer, index) => { tx.transferObjects([coins[index]], transfer.to); }); // Build the transaction and sign it const client = newSuiClient({ url: getFullnodeUrl(network) }); const bytes = await tx.build({ client }); const { signature } = await keypair.signTransaction(bytes); await verifyTransactionSignature(bytes, signature, { address: keypair.getPublicKey().toSuiAddress() }); return JSON.stringify([toBase64(bytes), signature]); }; Cette fonction intègre tous les paramètres nécessaires, y compris les détails du gaz et les destinataires, garantissant que votre transaction est signée en toute sécurité et prête à être exécutée. 5.2. Exécution de la transaction Une fois signée, la transaction est envoyée à la blockchain à l'aide du point de terminaison de l'API SUI_ExecuteTransactionBlock : curl --location 'https://fullnode.testnet.sui.io:443' \ --header 'Content-Type: application/json' \ --data '{ "jsonrpc": "2.0", "id": 1, "method": "sui_executeTransactionBlock", "params": [ "", [""], { "showInput": true, "showRawInput": true, "showEffects": true, "showEvents": true, "showObjectChanges": true, "showBalanceChanges": true }, "WaitForLocalExecution" ] }' Cet appel renvoie une réponse JSON détaillée contenant des informations telles que le résumé de la transaction, la consommation de gaz, les modifications apportées aux objets et les mises à jour du solde. N° 6. Vérifier votre transaction : Cross-Check Everything 🔍 Après avoir exécuté la transaction, il est essentiel de vérifier que tout s'est déroulé comme prévu. N° 6.1. Vérification du navigateur Vous pouvez vérifier votre transaction sur un explorateur de blockchain comme Suivision Testnet Explorer. L'explorateur affiche tous les détails des transactions dans un format visuel intuitif, ce qui permet de détecter plus facilement les problèmes. N° 6.2. Vérification de la ligne de commande Pour un audit plus détaillé, utilisez la ligne de commande : sui client tx-block -- 3FopuDy5qzKm1kLRFZCdi8Lynadym9j15NaVxzUH6nYD Cette commande fournit une ventilation complète de la transaction, y compris les détails de l'expéditeur, le paiement du gaz, les modifications apportées aux objets et l'état d'exécution. Numéro 7. Analyse de la réponse JSON : comprendre les couches d'une transaction Décompressons la réponse JSON que vous recevez après avoir exécuté votre transaction : N° 7.1. Vue d'ensemble des transactions jsonrpc & id : champs standard pour le protocole JSON-RPC. condensé : le hachage unique de la transaction (par exemple, « 3FoPudy5QZKM1KLRFZcDi8LYNADyM9J15NavxZuH6nyd »), qui est utilisé pour le suivi. TimestampMS et point de contrôle : fournissez un contexte indiquant quand la transaction a été exécutée et le point de contrôle de la blockchain à ce moment-là. N° 7.2. Contenu de la transaction Données sur l'expéditeur et le gaz : incluent l'adresse de l'expéditeur et toutes les configurations liées au gaz (paiement, prix, budget). Opérations (transactions) : la logique des transactions comprend des opérations telles que : SplitCoins : cassez une pièce de gaz en petits morceaux. TransferObjects : déplacement de segments de pièces vers les adresses de destinataire spécifiées. Signatures : les signatures cryptographiques (encodées en Base64) garantissent l'authenticité de la transaction. N° 7.3. Effets d'exécution État : le statut « Succès » confirme que la transaction a été traitée sans erreur. Consommation de gaz : détaille les coûts de calcul et de stockage ainsi que les remises applicables. Modifications d'objets : indique quels objets ont été modifiés, créés ou mis à jour à la suite de la transaction. Dépendances : répertorie les hachages de transactions associés dont dépend cette transaction. Cette ventilation granulaire est essentielle pour le débogage et l'amélioration des performances de votre DApp. N° 8. Informations pratiques pour les développeurs : conseils et points à retenir Comprendre chaque étape de ce processus vous donne les compétences nécessaires pour créer des applications Web3 sécurisées et efficaces sur Sui. Ces informations vous aident non seulement à résoudre les problèmes, mais vous permettent également d'innover en toute confiance au sein de l'écosystème Sui.
- Sui
- SDKs and Developer Tools
- Transaction Processing
3
0xduckmove135
Apr 08, 2025
Article
👀 SEAL- Je pense que la confidentialité des données Web3 est sur le point de changer
👀 SEAL est en ligne sur Sui Testnet — Je pense que la confidentialité des données Web3 est sur le point de changer Dans le Web3, il est courant d'entendre des phrases telles que* « les utilisateurs sont propriétaires de leurs données »* ou* « décentralisé par conception »*. Mais à y regarder de plus près, de nombreuses applications s'appuient toujours sur des infrastructures centralisées pour gérer les données sensibles, en utilisant des services tels qu'AWS ou Google Cloud pour la gestion des clés. Cela introduit une contradiction : la décentralisation en surface, la centralisation en dessous. Et s'il existait un moyen de gérer les secrets en toute sécurité, sans renoncer à la décentralisation ? Présentation de SEAL — Gestion décentralisée des secrets (DSM), désormais disponible sur le Sui Testnet. SEAL vise à corriger l'une des plus grandes hypocrisies du Web3 : crier à la décentralisation tout en utilisant secrètement AWS Vous me demandez peut-être : Qu'est-ce que SEAL ? SEAL est un protocole qui vous permet de gérer les données sensibles de manière sécurisée etdécentralisée, spécialement conçu pour le monde Web3. Considérez-le comme une couche de contrôle d'accès axée sur la confidentialité qui se connecte à votre DApp. Vous pouvez considérer SEAL comme une sorte de verrou programmable pour vos données. Vous ne vous contentez pas de verrouiller et de déverrouiller des éléments manuellement : vousinscrivez des politiques directement dans vos contrats intelligents, à l'aide de Move on Sui. Supposons que vous créiez une DApp où : Seuls les détenteurs de NFT peuvent débloquer un tutoriel premium Ou peut-être qu'un DAO doit voter avant que des fichiers sensibles ne soient révélés Ou vous souhaitez que les métadonnées soient verrouillées dans le temps et ne soient accessibles qu'après une date précise SEAL rend tout cela possible. Le contrôle d'accès se fait en chaîne, entièrement automatisé, aucun administrateur n'est nécessaire pour le gérer. Juste de la logique, intégrée à la blockchain. SEAL rend tout cela possible. Le contrôle d'accès se fait en chaîne, entièrement automatisé, aucun administrateur n'est nécessaire pour le gérer. Juste de la logique, intégrée à la blockchain. Un autre élément intéressant est la façon dont SEAL gère lechiffrement. Il utilise ce que l'on appelle lechiffrage à seuil, ce qui signifie qu'aucun nœud ne peut déchiffrer les données. Il faut un groupe de serveurs pour fonctionner ensemble, un peu comme en mode multi-sig, mais pour débloquer des secrets. Cela permet de répartir la confiance et d'éviter le problème habituel de point de défaillance unique. Et pour garantir la confidentialité des informations, SEAL chiffre et déchiffre toutcôté client. Vos données ne sont jamais visibles par aucun backend. Il reste entre vos mains, littéralement, sur votre appareil. et SEAL ne se soucie pas de l'endroit où vous stockez vos données. Qu'il s'agisse d'IPFS, d'Arweave, de Walrus ou d'une autre plateforme, SEAL n'essaie pas de contrôler cette partie. Il se concentre uniquement surqui est autorisé à voir quoi, et non sur où les objets sont stockés. Donc oui, il ne s'agit pas simplement d'une bibliothèque ou d'une API, c'est unecouche de confidentialité par défaut, dont l'accès est contrôlé et dont l'accès est contrôlé, pour votre DApp. SEAL comble une lacune assez critique. Décrivons cela un peu plus. Si vous créez une DApp qui traitetoute forme de données sensible(contenu sécurisé, documents utilisateur, messages cryptés, même des métadonnées NFT verrouillées dans le temps), vous rencontrerez le même problème : ➡️ Comment gérer les accès en toute sécurité, sans recourir à un service centralisé ? Sans quelque chose comme SEAL, la plupart des équipes non plus : Utilisez des outils centralisés tels qu'AWS KMS ou Firebase, ce qui va clairement à l'encontre de la décentralisation Ou essayez de corriger vous-même une logique de chiffrement à moitié cuite, qui s'avère généralement fragile et difficile à auditer https://x.com/EmanAbio/status/1908240279720841425?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1908240279720841425%7Ctwgr%5E697f93dc65359d0c8c7d64ddede66c0c4adeadf1%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.notion.so%2Fharryph%2FSEAL-Launches-on-Sui-Testnet-1cc4f8e09bb380969c0dcc627b96cc22 Aucun de ces modèles n'est bien adapté. Surtout pas lorsque vous essayez de créer des applications fiables pour plusieurs chaînes ou communautés. SEAL rend l'ensemble de ce processus modulaire et programmable. Vous définissez vos règles d'accès dans les contrats intelligents Move, et SEAL s'occupe du reste (génération de clés, approbations de déchiffrement et application des droits d'accès), le tout sans que personne n'émette manuellement des clés ou n'effectue de vérifications en arrière-plan. Mieux encore, ces règles sontauditables et immuables : une fois qu'elles sont connectées, elles suivent le contrat, pas un administrateur humain. Donc, au lieu de demander « qui doit gérer l'accès à ces données ? » il vous suffit de demander : « Quelle logique devrait définir l'accès ? » > ... et laissez la chaîne s'en occuper. Propre et évolutif. C'est ce qui rend SEAL pertinent pour bien plus que de simples « outils de sécurité » : c'est une couche de base pourtoute DApp soucieuse de la confidentialité, de la conformité ou de la logique d'accès dynamique. C'est un petit changement, mais cela change beaucoup la façon dont nous envisageons les données dans le Web3. Au lieu de chiffrer après le déploiement ou de faire appel à des services externes, vous commencez par intégrer la confidentialité et l'accès entièrement géré par une logique de contrat intelligent. Et c'est exactement ce dont Web3 a besoin en ce moment. Comment fonctionne réellement SEAL ? Nous avons expliquéce qu'est SEALetpourquoi Web3 en a besoin, voyons comment il est réellement construit sous le capot. C'est dans cette partie que les choses deviennent plus techniques, mais dans le bon sens. L'architecture est élégante une fois que vous voyez comment toutes les pièces s'emboîtent. À un niveau élevé, SEAL fonctionne en combinant lalogique d'accès en chaîneavec lagestion des clés hors chaîne, en utilisant une technique appeléeIdentity-Based Encryption (IBE). Cela permet aux développeurs de crypter les données sous forme d'identité, puis de s'appuyer sur des contrats intelligents pour définir qui est autorisé à les déchiffrer. Étape 1 : Règles d'accès dans les contrats intelligents (sur Sui) Tout commence par le contrat intelligent. Lorsque vous utilisez SEAL, vous définissez une fonction appelée seal_approve dans votre contrat Move. C'est là que vous écrivez vos conditions de déchiffrement. Par exemple, voici une règle de verrouillage temporel simple écrite dans Move : entry fun seal_approve(id: vector, c: &clock::Clock) { let mut prepared: BCS = bcs::new(id); let t = prepared.peel_u64(); let leftovers = prepared.into_remainder_bytes(); assert!((leftovers.length() == 0) && (c.timestamp_ms() >= t), ENoAccess); } Une fois déployé, ce contrat fait office de gardien. Chaque fois que quelqu'un souhaite déchiffrer des données, sa demande sera vérifiée par rapport à cette logique. Si elle passe, la clé est relâchée. Si ce n'est pas le cas, ils sont bloqués. Personne n'a besoin d'intervenir. ##Étape 2 : Chiffrement basé sur l'identité (IBE) C'est là que la magie opère. Au lieu de chiffrer les données pour une adresse de portefeuille spécifique (comme avec PGP ou RSA), SEAL utilise deschaînes d'identité, ce qui signifie que vous chiffrez selon un format tel que : 0 x adresse du portefeuille dao_voted:proposal_xyz PKGID_2025_05_01 (règle basée sur l'horodatage) ou même game_user_nft_holder Lorsque les données sont cryptées, elles se présentent comme suit : Encrypt(mpk, identity, message) mpk = clé publique principale (connue de tous) identité = le destinataire défini par la logique message = les données réelles Plus tard, si quelqu'un souhaite déchiffrer, le serveur de clés vérifie s'il correspond à la politique (via l'appel seal_approve onchain). S'il est approuvé, il renvoie une clé privée dérivée pour cette identité. Derive(msk, identity) → sk Decrypt(sk, encrypted_data) L'utilisateur peut ensuite déchiffrer le contenu localement. Le cryptage est donc effectué sans avoir besoin de savoir qui va déchiffrer à l'avance. Il vous suffit de définir les conditions, et SEAL s'occupera du reste plus tard. C'est dynamique. ##Étape 3 : Le serveur de clés — Offchain, mais pas centralisé Vous vous demandez peut-être : qui détient ces clés principales ? C'est là qu'intervient leKey Serverde SEAL. Considérez-le comme un backend qui : Contient la clé secrète principale (msk) Surveille les contrats en chaîne (comme votre logique seal_approve) N'émet des clés dérivées que si les conditions sont remplies Mais, et c'est essentiel, SEAL ne s'appuie pas sur un seul serveur de clés. Vous pouvez l'exécuter enmode seuil, où plusieurs serveurs indépendants doivent être d'accord avant qu'une clé de déchiffrement ne soit émise. Par exemple : 3 serveurs de clés sur 5 doivent approuver la demande. Cela évite les points de défaillance centraux et permet également la décentralisation au niveau de la couche de gestion clé. Mieux encore, à l'avenir, SEAL prendra en charge leMPC (calcul multipartite) et lesconfigurations basées sur des enclave(comme TEE), afin que vous puissiez obtenir des garanties encore plus strictes sans compromettre la convivialité. ##Étape 4 : Décryptage côté client Une fois la clé renvoyée à l'utilisateur, le déchiffrement proprement dit s'effectuesur son appareil. Cela signifie que : Le serveur ne voit jamais vos données Le backend ne stocke jamais de contenu déchiffré Seul l'utilisateur peut accéder au message final Il s'agit d'un modèle de confidentialité solide. Même si quelqu'un compromet la couche de stockage (IPFS, Arweave, etc.), il ne peut toujours pas lire les données sans passer la logique d'accès. Voici le modèle mental rapide : Cette structure facilite la création de dApps où les règles d'accès ne sont pas codées en dur : elles sont dynamiques, vérifiables et entièrement intégrées à votre logique de chaîne. ##L'équipe derrière SEAL SEAL est dirigé parSamczsun, une figure bien connue de la communauté de la sécurité blockchain. Ancien partenaire de recherche chez Paradigm, il a audité et sauvé plusieurs écosystèmes contre des exploits majeurs. Maintenant, il se concentre à plein temps sur l'intégration de SEAL au cœur de l'infrastructure de confidentialité de Web3. Grâce à son expérience et à sa crédibilité, SEAL n'est pas un simple outil expérimental comme les autres, mais une tentative sérieuse de rendre la confidentialité des données décentralisée à la fois pratique et évolutive. Alors que SEAL est mis en ligne sur le Sui Testnet, il apporte une nouvelle norme sur la façon dont les applications Web3 peuvent gérer les secrets. En combinant le contrôle d'accès en chaîne, le cryptage des seuils et la confidentialité côté client, SEAL offre une base plus fiable pour le traitement décentralisé des données. Que vous créiez des DApps, des DAO ou des jeux décentralisés, SEAL fournit une puissante boîte à outils pour renforcer le contrôle d'accès et protéger les données des utilisateurs sans compromettre la décentralisation. Si le Web3 veut aller de l'avant, une infrastructure sécurisée comme SEAL n'est pas facultative, elle est essentielle
- Sui
- Architecture
- SDKs and Developer Tools
4
Lokie13
Mar 16, 2025
Article
Step by step guide to create a Suiet wallet
Step by step guide to create a Suiet wallet: Download suiet extension: https://suiet.app/ After successful installation, click on the Suiet icon in your browser and select "Create New". Set a strong password to protect your wallet. Write down and save your recovery phrase in a safe place. This phrase is needed to recover your wallet if needed Done
- Sui
1
Bahador85
Mar 15, 2025
Article
Parcours en tant que développeur de contrats intelligents SUI Move
Dans l'article d'aujourd'hui, je souhaite me plonger dans une suggestion de feuille de route pour ceux qui souhaitent se lancer dans la méthode de développement SUI move. 1. Comprendre les principes fondamentaux de la blockchain Concepts fondamentaux :* Familiarisez-vous avec les concepts clés de la blockchain tels que la décentralisation, les mécanismes de consensus, les primitives cryptographiques et les contrats intelligents. Présentation de la blockchain SUI :* Découvrez ce qui rend SUI unique : son modèle de données centré sur l'objet, ses objectifs de performance et la manière dont il gère la gestion des états. 2. Apprenez le langage du mouvement Principes de base de la langue :* Commencez par les bases du langage de programmation Move. Concentrez-vous sur : Types de ressources :*Comment les ressources fonctionnent pour garantir la sécurité et la propriété. Modules et structures :*Comment définir des modules et des structures de données. Fonctions de saisie :*Comment les transactions sont exécutées via les points d'entrée désignés. Ressources recommandées : Utilisez les didacticiels, la documentation et les référentiels d'exemples de code officiels du langage Move. 3. Configurez votre environnement de développement Outils et interface de ligne de commande :* Installez la CLI SUI et configurez la chaîne d'outils Move sur votre machine locale. Environnement de test local :* Configurez un réseau de développement SUI local ou utilisez les réseaux de test disponibles. Cela vous permet d'expérimenter le déploiement et les tests de contrats intelligents avant leur mise en service. IDE et débogage :* Choisissez un environnement de développement intégré (IDE) qui prend en charge Move (par exemple, VSCode avec les extensions Move) et familiarisez-vous avec le débogage et le test de vos contrats. 4. Créez votre premier contrat simple Tutoriels pratiques :* Commencez par un projet simple, tel qu'un contrat symbolique. Cela vous permettra d'appliquer les concepts de base de Move. Explorez les modèles spécifiques à l'interface utilisateur :* Travaillez avec le modèle objet de SUI et découvrez comment les transactions sont traitées au sein de l'écosystème SUI. Documentation et exemples :* Tirez parti de la documentation pour développeurs et des exemples de projets de SUI pour comprendre les meilleures pratiques. 5. Découvrez en profondeur les fonctionnalités spécifiques à l'interface utilisateur Modèle centré sur l'objet :* Découvrez comment SUI traite les objets différemment des blockchains basées sur des comptes comme Ethereum. Modèle de gaz et de transaction :* Étudiez comment les frais de gaz sont calculés et comment l'exécution des transactions est gérée dans SUI. Gestion de l'État :* Découvrez l'approche de SUI en matière de stockage d'état, de mises à jour modulaires et de gestion du cycle de vie des objets. 6. Test, débogage et déploiement Tests unitaires et d'intégration :* Rédigez des tests pour vérifier la logique et la sécurité de vos contrats intelligents. Assurez-vous de couvrir les cas extrêmes et les vulnérabilités potentielles. Déploiement local et sur réseau de test :* Déployez vos contrats dans un environnement contrôlé pour voir comment ils fonctionnent en conditions réelles. Outillage :* Utilisez les outils de débogage et les fonctionnalités de journalisation de SUI pour itérer et améliorer votre code. 7. Meilleures pratiques en matière de sécurité et audits de code Comprenez les pièges courants :* Étudiez les failles de sécurité courantes dans les contrats intelligents (par exemple, la réentrée, les contrôles d'accès inappropriés) et la manière dont la conception de Move les atténue. Révisions de code :* Participez aux révisions de code de la communauté ou collaborez avec vos pairs pour auditer et améliorer votre code. Vérification formelle :* Explorez tous les outils de vérification formels disponibles pour Move afin de prouver mathématiquement l'exactitude de vos contrats. 8. Rejoignez la communauté des développeurs SUI Chaînes communautaires :* Communiquez avec d'autres développeurs via des forums, des chaînes Discord ou des appels communautaires. Le partage d'expériences et de défis est inestimable. Contributions au code source ouvert :* Contribuez à des projets open source ou à des référentiels de développeurs liés à SUI et Move. Restez à jour :* Suivez les blogs SUI et Move, les référentiels GitHub et les réseaux sociaux pour suivre les nouveaux développements, les mises à jour et les meilleures pratiques. 9. Explorez les sujets avancés Applications complexes :* Au fur et à mesure que vous vous sentirez plus à l'aise, expérimentez des modèles de contrats intelligents plus avancés tels que les protocoles de finance décentralisée (DeFi), les NFT ou les portefeuilles multi-signatures. Interopérabilité et intégration :* Apprenez à interagir avec d'autres contrats intelligents et à intégrer les modules SUI Move à des systèmes hors chaîne. Performances et évolutivité :* Explorez les techniques permettant d'optimiser vos contrats en termes de rapidité et de rentabilité sur la blockchain SUI. 10. Créez un portfolio et continuez à vous entraîner Projets de présentation :* Développez et documentez une série de projets qui démontrent votre compréhension et votre expertise. Apprentissage continu :* Blockchain et Move évoluent rapidement. Prenez l'habitude de l'apprentissage continu en revoyant la documentation, en participant à des ateliers et en participant à des hackathons. Boucle de rétroaction :* Utilisez les commentaires de la communauté pour affiner vos compétences et garder une longueur d'avance en matière de développement de contrats intelligents. Bien que les éléments ci-dessus soient des suggestions et ne soient pas le seul moyen de devenir développeur SUI, j'espère que cela vous sera utile. Bon codage. Bonne utilisation !
- Sui
- SDKs and Developer Tools
- Move
2
0xduckmove135
Mar 12, 2025
Article
Setting Up a Project to Test the SUI Name Service (SuiNS)
The SUI Name Service (SuiNS) is a decentralized naming system on the SUI blockchain that allows users to map human-readable names (e.g., "0xduck.sui") to blockchain addresses or other data, enhancing usability and accessibility. For developers, testing the SuiNS SDK is an essential step to ensure applications can resolve these names correctly. In this article, we’ll walk you through the process of setting up a project to test the SuiNS SDK, from preparing your development environment to querying a name record like "0xduck.sui" and understanding the results. Introduction to SUI Name Service The SUI Name Service (SuiNS) simplifies blockchain interactions by allowing users to register memorable names instead of using complex cryptographic addresses. For example, instead of sending tokens to "0x1234...abcd", you could send them to "0xduck.sui". Testing the SuiNS SDK ensures that your application can correctly interact with this system, retrieving and interpreting name records as needed. In this project, we’ll set up a Node.js environment, connect to the SUI mainnet, and write a script to query the name record for "0xduck.sui". By the end, you’ll have a working setup to explore SuiNS further. Prerequisites Before starting, ensure you have the following: Node.js (version 14 or higher) and npm (version 6 or higher) installed. Download them from nodejs.org if needed. Basic understanding of JavaScript, particularly asynchronous programming (e.g., async/await). A code editor like Visual Studio Code (VS Code) for writing and running scripts. An internet connection to install packages and connect to the SUI. Setting Up the Development Environment Let’s create a new project directory and initialize it as a Node.js project. This will provide a clean workspace for our test. Step-by-Step Instructions: Open your terminal (e.g., Command Prompt, PowerShell, or a Unix shell). Create a new directory: mkdir suins-test-project cd suins-test-project Initialize a Node.js project: Run this command to create a package.json file with default settings: npm init -y Your project is now set up with a basic structure. Installing Dependencies Run the following in your terminal: npm install @mysten/suins @mysten/sui Verify the Installation: Check that the packages are added to package.json under dependencies. You can also confirm the installed versions by running: npm list @mysten/suins @mysten/sui This should output something like: suins-test-project@1.0.0 ├── @mysten/sui@x.x.x └── @mysten/suins@y.y.y Configuring the SUI Client The SUI client connects your project to the SUI blockchain. For testing, we’ll use the mainnet. Create a Script File: In your project directory, create a file named test-suins.js: touch test-suins.js # On Unix/macOS echo. > test-suins.js # On Windows Open test-suins.js in your editor and add the following: import { getFullnodeUrl, SuiClient } from '@mysten/sui/client'; // Create a SUI client connected to the testnet const suiClient = new SuiClient({ url: getFullnodeUrl('testnet') }); Note: If you encounter an error about ES modules (e.g., "Cannot use import statement outside a module"), add "type": "module" to your package.json: { "name": "suins-test-project", "version": "1.0.0", "type": "module", ... } Testing the Name Service Now, let’s write a script to query the name record for "0xduck.sui" and log the result. import { getFullnodeUrl, SuiClient } from '@mysten/sui/client'; import { SuinsClient } from '@mysten/suins'; // Create a SUI client connected to the testnet // const suiClient = new SuiClient({ url: getFullnodeUrl('mainnet') }); const client = new SuiClient({ url: getFullnodeUrl('mainnet') }); // Create a SuiNS client using the SUI client const suinsClient = new SuinsClient({ client, network: 'mainnet', }); // Function to test the name service async function testNameService() { try { // Query the name record for 'demo.sui' const nameRecord = await suinsClient.getNameRecord('0xduck.sui'); // Log the result console.log('Name Record for "0xduck.sui":', nameRecord); } catch (error) { console.error('Error fetching name record:', error.message); } } testNameService(); In your terminal, execute: node test-suins.js
- SDKs and Developer Tools
3
Bahador85
Mar 11, 2025
Article
Suibase, a great tool to experience the SUI
As I was checking some resources for the SUI development, I faced a tool named, suibase. In my exploration on that, I found it very helpful, especially when using localnet which a local explorer will be set up on our local system. I loved it so much. as there is stated in the official website of Suibase: Suibase makes it easy to create "workdirs", each defining a distinct development environment targeting a network. It seems like virtual env in python programming. As far as I found this tool, there are many usefull functionalities which we can take benefit of: Key functionalities of Suibase include: Workdir Management: Suibase enables the creation of isolated workdirs for each network, ensuring that configurations and dependencies are maintained separately. This isolation facilitates organized and efficient development workflows. Suibase Simplified Command-Line Interface:* The tool provides scripts such as lsui, dsui, tsui, and msui, which serve as frontends to the Mysten Labs sui binaries for localnet, devnet, testnet, and mainnet, respectively. These scripts eliminate the need to manually switch environments, as they automatically execute the appropriate sui client and keystore for the targeted network. Localnet Operations:* Suibase offers commands like localnet start, localnet stop, and localnet status to manage the local network. Additionally, the localnet regen command allows developers to reset the network to its initial state, complete with predefined addresses and aliases, which is particularly useful for testing purposes. Faucet Functionality:* The localnet faucet command enables the distribution of Sui coins to specified addresses or all addresses within the localnet, facilitating testing and development activities. Independent Installation:* Suibase operates independently of other Mysten Labs installations and keystores, ensuring that it does not interfere with existing setups. This design allows Suibase to coexist safely with standard installations on the same system. By providing these features, Suibase enhances the development experience on the Sui network, offering a structured and efficient environment for building and testing applications. I recommend testing it!
- Sui
- SDKs and Developer Tools
3
Bahador85
Mar 11, 2025
Article
How to fix the SUI installation error?
When I try to install and build the SUI binary on my local system with this command: cargo install --git https://github.com/MystenLabs/sui.git --bin sui --branch devnet I face this error: Please specify a package, e.g. cargo install --git https://github.com/MystenLabs/sui.git anemo-benchmark. After some digging, I found the solution and was able to install and build it error-free and completely using some modification in the above command: For Devnet: cargo install --locked --git https://github.com/MystenLabs/sui.git sui --branch devnet For Testnet: cargo install --locked --git https://github.com/MystenLabs/sui.git sui --branch devnet This way, you can install and build SUI on your local machine and start on your way! Best of luck.
- Sui
- Move
3