Le plus nouveau
Restez informé des dernières publications.
Publications
1817- ArticlePourSuiApr 09, 2025
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
1 Staking in Sui Wallet : pouvez-vous effectuer un retrait à tout moment ?
Je me demandais si je parie dans le portefeuille Sui, puis-je retirer ma mise à tout moment ou y a-t-il une période de déverrouillage ?
- Transaction Processing
01Que se passe-t-il si je ne réclame pas d'ETH via Sui bridge ?
J'ai utilisé le pont Sui pour transférer des ETH mais je ne les ai pas encore réclamés car les frais sont assez élevés. Que se passera-t-il si je ne le réclame pas ?
- Sui
00Que se passe-t-il si je ne réclame pas d'ETH via Sui bridge ?
J'ai utilisé le pont Sui pour transférer des ETH mais je ne les ai pas encore réclamés car les frais sont assez élevés. Que se passera-t-il si je ne le réclame pas ?
- Sui
00- Article0xduckmove120PourSuiApr 08, 2025
👀 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
1 Comment s'assurer que seul le propriétaire d'un NFT peut le transférer dans un contrat ?
Salut tout le monde ! Je travaille à la mise en œuvre d'un contrat NFT et je souhaite m'assurer que seul le propriétaire légitime du NFT peut le transférer. J'ai cette fonction pour transférer : public fun transfer( nft: DevNetNFT, recipient: address, _: &mut TxContext ) { transfer::public_transfer(nft, recipient) } Cette vérification est-elle effectuée dans le cadre public_transferde la méthode ou dois-je ajouter une logique supplémentaire ?
- Move CLI
03Comment récupérer des valeurs depuis ObjectTable à l'aide de champs dynamiques ?
dynamicFieldObjectJ'essaie de récupérer des valeurs à partir d'un ObjectTable à l'aide de champs dynamiques depuis le frontend, mais je rencontre une erreur avec. L'erreur indiqueUnexpected arg String("gms") for the expected type Struct(MoveStructLayout...). Comment puis-je obtenir le type correct pour la valeur et éviter cette erreur ?
- Move CLI
- Move
03Comment déposer des jetons SUI du réseau SUI vers Binance ?
Je souhaite envoyer mes jetons SUI sur mon compte Binance. J'ai essayé d'utiliser un pont-portail mais c'est confus. J'ai entendu dire que pour ce faire, je devais convertir les jetons SUI en SUI USDC avant de faire le pont. Comment le faire correctement sans utiliser le portique ? De plus, une fois sur Binance, comment puis-je convertir SUI en USDC ou USDT si cela ne me le permet pas directement ?
- Sui
02Comment résoudre les problèmes d'installation et de démarrage du service Heimdall ?
J'essaie d'installer et de démarrer le service Heimdall sur mon serveur Ubuntu, mais je rencontre des erreurs. Au départ, j'ai rencontré une erreur de script avant la suppression lors de l'installation, indiquant que « heimdalld.service » n'était pas chargé. Plus tard, après la réinstallation, le service n'a pas pu être démarré car il n'a pas été trouvé. Quelqu'un peut-il m'aider à résoudre ces problèmes ?
- Polygon Edge
04Comment tester une fonction avec un paramètre de réception dans Sui ?
J'essaie de tester la receive_objectfonction avec un Receivingparamètre dans Sui en me basant sur la documentation de ce lien. Au départ, j'ai créé un test en utilisant l'exemple, mais j'ai du mal à faire en sorte que l'argument envoyé soit un Receivingtype. J'ai également essayé d'indiquer le type de réception, mais j'ai rencontré des erreurs. Quelqu'un pourrait-il m'aider à tester correctement cette fonction ?
- Move CLI
- Move
04
- Que se passe-t-il si je ne réclame pas d'ETH via Sui bridge ?00
- Que se passe-t-il si je ne réclame pas d'ETH via Sui bridge ?00
- Est-il facile d'apprendre à bouger après la solidité ?00
- Est-il rentable de créer des services dapps (comme des jeux) sur Sui ?00
- Le meilleur endroit pour apprendre à bouger pour les débutants ?00
Gagne ta part de 1000 Sui
Gagne des points de réputation et obtiens des récompenses pour avoir aidé la communauté Sui à se développer.
- 2565
- 1780
- 402
- 397
- 369
- 345
- 328
- 296
- 294
- 289