Tendance
Découvrez les publications les plus populaires.
Publications
1968- Article0xduckmove257PourSuiApr 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
8 
ArticleFoksa225PourPeera MetaJul 25, 2022How to create an account
To create an account on the Peeranha website you need to log in first. Peeranha supports four wallets you can log in with: Torus, MetaMask, WalletConnect, and Coinbase. Note: If you are new to Web3 we recommend you to use Torus. Log in with Torus Click Log in. Select the checkbox I agree to the Terms and Conditions and Privacy Policy. Choose Torus in the pop-up window. Select any of the suggested ways you want to sign in or enter your email address. You are now logged in and have an account. In your profile section, you can add more detailed information about yourself and track your progress and achievements. To edit your profile, click Profile and select Edit. Enter all the information that you want to be visible in your profile.
- tutorial
5- Questions et Réponses avec des Expertsloth.broke110PourPolygonMar 31, 2025
Vous utilisez heimdallcli dans une configuration de réseau local dockerisée ?
heimdallcliJ'essaie d'utiliser au matic-clisein de mon réseau dockerisé local que j'ai configuré à l'aide de. Mon objectif principal est d'envoyer une proposition en utilisant cette commande :heimdallcli tx gov submit-proposal param-change {pathToProposalJSONFile} --validator-id {validatorID} --chain-id {chainID}. Cependant, je rencontre une erreur qui indique : « Le fichier de configuration « heimdall-config » est introuvable dans « /var/lib/heimdall/config » ». Le répertoire de configuration ne semble pas exister dans l'environnement Docker, bien que je puisse voir des journaux qui suggèrent que Heimdall fonctionne. Comment puis-je résoudre ce problème et faire heimdallclifonctionner la commande ?
- Polygon PoS
54Meilleure réponse 
ArticleFoksa225PourPeera MetaJul 08, 2022How to make a post
Making posts on Peeranha is easy. Follow the simple steps: Log in to your profile with any available wallets. Click the New post button. Select a community from the dropdown list where you want to make a post. Choose Post Type: Discussion, Expert, Tutorial. Note: Read carefully the requirements for each post type, to be sure that your post is published in the correct section. Enter your question in the Title field. To get a more detailed answer, give more details about what you would like to know in the Body field. In the Preview section, you may check how your post looks before publishing it. Select tags that suit your post most. Note: Tags help other users to find relevant information quickly. Click Post. Your post is published and soon you will get relevant answers from the other users.
- tutorial
5- Articleharry phan381PourSuiApr 24, 2025
Gestion des enfants multimodule avec public_receive
Il s'agit de la troisième partie de la série « Les objets parent-enfant dans Sui Move ». Parfois, vos types de parents et d'enfants sont définis dans différents modules ou même dans différents packages. Par exemple, vous pouvez disposer d'un objet Warehouse générique qui peut stocker n'importe quel type d'objets Parcel. Le module Warehouse souhaite extraire un enfant de colis, mais le type de colis est défini ailleurs. Dans de tels cas, nous utilisons transfer : :public_receive, qui est le cousin intermodule de receive. ###recevoir contre public_receve Comme nous l'avons vu, transfer : :receive ne peut être appelé que dans le module qui définit T (ou un ami) car il ne nécessite pas T : store. Le vérificateur de bytecode Move garantit en fait que dans tout appel à recevoir, le type T provient du module en cours. Il s'agit d'une restriction de sécurité pour les objets dotés uniquement d'une clé. transfer : :public_receive est une variante qui requierce T : key + store mais permet de recevoir en dehors du module de T. En d'autres termes, si le type d'objet possède la capacité de stockage (ce qui signifie qu'il est autorisé à exister librement dans le stockage global), alors n'importe quel module (avec l'UID &mut du parent) peut le recevoir en utilisant public_receive. C'est parfait pour les cas où le module du parent est différent de celui de l'enfant. Pourquoi avoir besoin d'un magasin ? Parce que stockez les marques indiquant que l'objet peut être conservé en toute sécurité et transmis en dehors de son module de définition. Les objets à clé uniquement peuvent avoir des invariants personnalisés que le module d'origine souhaite appliquer lors du transfert/de la réception ; en les excluant de public_receive, Sui oblige les développeurs à les gérer dans le module (comme nous le verrons avec les objets liés à l'âme). Si un objet a un stockage, il est plus permissif, et Sui autorise une logique générique de transfert/réception pour le gérer en externe. ###Exemple : modules séparés pour les parents et les enfants Illustrons avec un scénario simple : un entrepôt qui stocke des objets Parcel. Le type de colis est défini dans son propre module et l'entrepôt dans un autre. Nous allons montrer comment Warehouse peut recevoir un colis enfant à l'aide de public_receive. module demo::parcel { // Child module use sui::object::{Self, UID}; use sui::tx_context::{Self, TxContext}; /// A parcel object that can be stored in a Warehouse. /// It has both key and store, so it can be transferred across modules. struct Parcel has key, store { id: UID, contents: vector } public entry fun create_parcel(contents: vector, ctx: &mut TxContext): Parcel { Parcel { id: object::new(ctx), contents } } } module demo::warehouse { // Parent module use sui::transfer::{Self, Receiving, public_receive}; use demo::parcel::{Self, Parcel}; use sui::object::{UID}; use sui::tx_context::{Self, TxContext}; struct Warehouse has key { id: UID, location: address } public entry fun create_warehouse(location: address, ctx: &mut TxContext): Warehouse { Warehouse { id: object::new(ctx), location } } /// Receive a Parcel that was sent to this Warehouse. /// Returns the Parcel to the caller (transferred to caller's address). public entry fun withdraw_parcel( warehouse: &mut Warehouse, parcel_ticket: Receiving, ctx: &mut TxContext ): Parcel { // Using public_receive because Parcel is defined in another module and has store let parcel = public_receive(&mut warehouse.id, parcel_ticket) oai_citation_attribution:27‡docs.sui.io oai_citation_attribution:28‡github.com; // Transfer the parcel to the transaction sender (so the caller gets ownership) transfer::transfer(parcel, tx_context::sender(ctx)); // We return nothing because we've transferred the Parcel out to the caller. } } Découvrons ce qui se passe dans withdraw_parcel : Nous appelons public_receive (&mut warehouse.id, parcel_ticket). Comme Parcel a la capacité de stocker, cet appel est autorisé même si nous ne sommes pas dans le module Colis. En principe, cela effectue les mêmes vérifications et extractions que la réception, mais cela est autorisé entre les modules car store indique que cela peut être fait en toute sécurité. https://github.com/MystenLabs/sui/blob/main/crates/sui-framework/packages/sui-framework/sources/transfer.move#:~:text=public%20fun%20public_receive,T%3E%29%3A%20T Nous transférons ensuite immédiatement le colis reçu à l'adresse de l'appelant (tx_context : :sender (ctx)). Cette étape garantit que le colis quitte l'entrepôt et est envoyé à l'utilisateur qui a initié le retrait. Nous aurions également pu simplement renvoyer Parcel à partir de la fonction, et Sui le traiterait comme une sortie appartenant à l'adresse de l'appelant (puisqu'il s'agit d'une sortie de fonction d'entrée). Faire un transfert explicite est plus détaillé, mais cela permet de comprendre ce qui se passe (et nous permet de faire toutes les vérifications avant de libérer l'objet). Pourquoi inclure le point de vente dans le colis ? Si Parcel n'avait pas la capacité de stockage (c'est-à-dire s'il n'avait que la clé), l'appel public_receive dans demo : :warehouse ne serait pas compilé — Sui impose que T possède un store pour public_receive. Dans ce cas, nous serions obligés de récupérer le colis en utilisant receive dans le module de colis lui-même (ou en utilisant une relation d'amitié), ce qui complique la conception intermodule. En ajoutant store à Parcel, nous disons en fait que « cet objet peut être déplacé et reçu librement par des modules externes », ce que nous voulons pour un modèle de conteneur générique. Modèle d'appel de fonction :Pour les utiliser dans une transaction, le flux serait le suivant : 1.Dépôt (transfert vers un objet) :Appelez transfer : :public_transfer (parcel_obj, @warehouse_id) pour envoyer un colis dans un entrepôt. Cela indique que le propriétaire du colis est l'entrepôt. (Nous utilisons public_transfer ici car il se trouve en dehors du module Parcel et Parcel a une boutique. Dans le module du colis, un simple transfert fonctionnerait également.) Retirer (recevoir un retour) :Plus tard, appelez withdraw_parcel (warehouse_obj, Receiving (parcel_id,...)). La réception peut être obtenue par le SDK en faisant référence à l'identifiant du colis et à la dernière version. La fonction appellera public_receive puis vous transférera le colis. Après l'appel withdraw_parcel, le propriétaire du colis revient à une adresse (la vôtre). Il s'agit donc à nouveau d'un objet appartenant à une adresse normale. L'entrepôt n'en est plus propriétaire. Considérations relatives à l'intermodule :Notez que le module Warehouse devait connaître le type de colis (nous utilisons demo : :parcel : :Parcel). En effet, nous saisissons explicitement la réception comme réception. Si vous vouliez un conteneur véritablement générique pouvant recevoir n'importe quel type d'objet, vous devrez utiliser des génériques ou une approche différente (éventuellement des champs dynamiques avec effacement de type). Mais dans la plupart des cas d'utilisation, vous saurez à quels types d'enfants vous attendez. Pourquoi public_receive au lieu de simplement appeler receive ? Si nous essayions transfer : :receive (&mut warehouse.id, parcel_ticket) dans le module warehouse, le vérificateur Move le rejetterait car Parcel n'est pas défini dans demo : :warehouse. Sui fournit le public_receive comme moyen privilégié de le faire avec une vérification de capacité supplémentaire (nécessitant un magasin). De même, Sui a transfer vs public_transfer, freeze_object vs public_freeze_object, etc., suivant le même schéma : les versions public_ sont destinées à être utilisées en dehors du module de définition et nécessitent un stockage. N' oubliez pas l'autorisation des parents :Même avec public_receive, vous avez toujours besoin de &mut warehouse.id. Nous l'avons obtenu car withdraw_parcel se trouve dans le module de Warehouse et accepte &mut Warehouse. Ainsi, seule une personne capable de l'appeler (le propriétaire de l'entrepôt) peut retirer le colis. Si le module d'entrepôt ne fournissait pas une telle fonction publiquement, personne ne pourrait non plus appeler public_receive en externe sur ses enfants. Ainsi, le cross-module ne contourne pas le contrôle du parent ; il permet simplement au code du parent de fonctionner avec des enfants de types qu'il n'a pas définis. Remarque sur la capacité de stockage : Le fait de donner un magasin d'objets le rend plus flexible mais légèrement moins restreint. Tout module avec la référence parent peut l'extraire à l'aide de public_receive. Si vous souhaitezrestreindrela manière dont un objet est récupéré (par exemple, appliquer une logique personnalisée ou empêcher une extraction facile), vous pouvez délibérément en faire une clé uniquement. Nous en verrons un exemple avec les objets liés à l'âme. Dans ces cas, vous pouvez implémenter une fonction de réception personnalisée au lieu de vous fier à public_receive. Pour résumer cette partie : public_receive est votre ami pour la gestion des objets enfants définis dans d'autres modules, à condition que ces objets puissent être stockés. Il vous permet de créer des systèmes multimodules (comme notre Entrepôt/Colis) tout en respectant la propriété et le contrôle d'accès. N'oubliez pas d'inclure le store sur les types d'enfants et d'utiliser public_transfer lorsque vous les envoyez à un parent depuis l'extérieur de son module.
- Sui
- Architecture
5 Bot AMM dans l'écosystème Sui
Quelles sont les principales caractéristiques et fonctionnalités des robots AMM au sein de l'écosystème Sui ? Comment améliorent-ils les mécanismes de trading traditionnels et quels avantages offrent-ils aux utilisateurs utilisant les protocoles DeFi sur le réseau Sui ? Dois-je en construire un ou je peux utiliser Turbos Finance par exemple
- Sui
52Meilleure réponse- Article0xduckmove257PourSuiApr 25, 2025
Récapitulatif : la vidéo peut dynamiser votre parcours Sui Dev
Soyons réalistes, si vous avez déjà construit surSui, vous avez probablement heurté des murs. Qu'il s'agisse d'identifier des objets cryptés, de jongler avec des CLI ou de créer des réseaux locaux, c'est comme se préparer à un combat de boss avant même d'avoir écrit votre première ligne de logique métier. Lors d'un récent atelier organisé dans le cadre de la série Road to Overflow, Moven de la Fondation Dubhe a expliqué comment fonctionne Dubhe Engine, quels problèmes il résout et en quoi c'est bien plus qu'un simple outil, c'est un mouvement en pleine croissance. Lien vidéo : https://www.youtube.com/watch?v=CHkOS-TYehM Le problème : outillage fragmenté, configuration lourde Moven a débuté par une véritable discussion sur le paysage actuel des développeurs Sui : Les nouveaux arrivants sont confrontés à une courbe d'apprentissage ardue : configuration de portefeuilles, récupération de jetons de test, packages d'échafaudage, apprentissage de la syntaxe Move, création de réseaux de test locaux, configuration de SDK, etc. Même les développeurs expérimentés perdent du temps à effectuer des tâches de configuration répétitives au lieu de se concentrer sur la véritable logique DApp. Les bases de code deviennent rapidement monolithiques : des fichiers .move volumineux et désordonnés contenant des structures de données, des constructeurs, des assistants et des fonctions de saisie sont tous entassés. En résumé : l'écosystème se développe rapidement, mais les outils n'ont pas suivi le rythme jusqu'à présent. ##La solution : la génération de code basée sur un schéma Au cœur deDubhe Enginese trouve une idée clé : ledéveloppement axé sur le schéma. Avec un seul fichier de configuration (d.config.ts), les développeurs peuvent définir : Leurs structures de données en chaîne Évènements Erreurs Types personnalisés (même des vecteurs 2D de structures auto-définies !) À partir de là, une commande (pnpm dub schema:gen) génère automatiquement un package Move entièrement structuré et une intégration frontend, avec : Structure de fichiers modularisée Composabilité en chaîne (via des importations depuis les packages publiés par Sui) Configuration, génération, déploiement et prise en charge du frontend Localnet (prêt pour Next.js) C'est vous qui écrivez la logique.Dubhegère le passe-partout. ##* ⏱️ Impact réel : 80 % de code répétitif en moins* Lors d'expériences internes, des projets générés par Dubb ont montré que seulement* 20 % du code*devait être écrit manuellement, le reste étant constitué d'échafaudages générés automatiquement via des schémas. Cela signifie un prototypage plus rapide, moins de bugs et plus de temps pour vous concentrer sur l'essentiel : la valeur fondamentale de votre application ##Un moteur d'écosystème de développement Dubb ne s'arrête pas aux échafaudages. Movin l'a clairement indiqué : il s'agit d'une infrastructure pour une nouvelle économie des développeurs. Voici comment évolue la communauté Dubb Engine : Subventions sur le gaz :**Pour les nouveaux constructeurs qui expérimentent Dubb Task Bounties :**Comme les « bons premiers numéros » de GitHub, mais avec des récompenses Niveau de gouvernance (D-OS) :**Vote en chaîne pour la priorisation des projets Support Launchpad :**Aider les projets arrivés à maturité à obtenir un financement DApp Staking :**Les utilisateurs peuvent miser des jetons D pour soutenir leurs DApps préférés et voter sur les décisions relatives à la feuille de route Cette boucle de feedback alimente l'ensemble de l'écosystème Sui : plus de développeurs → plus d'applications → plus d'utilisateurs → plus de développeurs.
- Architecture
- SDKs and Developer Tools
5 How to access and manage nested structs and dynamic fields in Move?
How to access and manage nested structs and dynamic fields in Move?
- Sui
- Move
56Meilleure réponse
ArticleFoksa225PourPeera MetaJul 25, 2022How to answer posts
Providing answers on Peeranha is easy, but at the same time, it is a responsible task. Remember that your correct answers help other users to find solutions to their challenges. To provide an answer, follow the simple steps: Log in to your profile with any available wallets. Select a post that you would like to answer. Use the Body field to provide an answer. In the Preview section, you may check how your answer looks before publishing it. Click Post answer. Your answer is posted and it will help some of the users to solve their issues.
- tutorial
4- Questions et Réponses avec des Experts
PourAnkrJan 25, 2023How do I become Ankr node provider?
Hey! Can I physically run Nod Ankr? What kind of set-up do I need? Or is the only way to become Ankr node provider is described in this question.
- Node Provider
42
