Peera.

Explorer

Connectez-vous aux communautés et découvrez de nouvelles idées.

Sui.X.Peera.

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.

Communautés

Filtrer :Toutes les blockchains

Prime

  • Xavier.eth.Peera.
    Xavier.eth313
    PourSuiJun 27, 2025
    +15

    Échec de la transaction Sui : objets réservés pour une autre transaction

    Je rencontre un problème persistant JsonRpcErrorlorsque j'essaie d'exécuter des transactions sur Sui. L'erreur indique que les objets sont réservés pour une autre transaction, même si j'ai implémenté un traitement séquentiel des transactions avec des retards. JsonRpcError: Failed to sign transaction by a quorum of validators because one or more of its objects is reserved for another transaction. Other transactions locking these objects: AV7coSQHWg5vN3S47xada6UiZGW54xxUNhRv1QUPqWK (stake 33.83) 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 J'ai essayé : Exécution séquentielle des transactions (en attente de la fin de la transaction précédente) Ajout de délais de 3 secondes entre les transactions Et j'obtiens toujours la même erreur. Utilisation de Sui RPC pour la soumission des transactions. Le même identifiant d'objet apparaît plusieurs fois dans la liste de verrouillage. Une erreur se produit même avec un séquençage minutieux des transactions. Qu'est-ce qui fait que les objets sont « réservés » pour d'autres transactions ? Comment puis-je vérifier correctement si un objet est disponible avant de l'utiliser dans une transaction ? Existe-t-il des bonnes pratiques pour gérer les verrous d'objets dans Sui ? Cela pourrait-il être lié au calendrier de finalité de la transaction ? Quelqu'un a-t-il déjà rencontré ce problème ? Toute information sur la gestion appropriée des objets dans les transactions Sui serait grandement appréciée !

    2
    5
  • Xavier.eth.Peera.
    Xavier.eth313
    PourSuiJun 17, 2025
    +15

    Comment les contraintes de capacité interagissent-elles avec les champs dynamiques dans des collections hétérogènes ?

    Je suis en train de créer une place de marché qui doit gérer plusieurs types d'actifs avec des exigences de capacité différentes, et je me suis posé quelques questions fondamentales concernant le système de types de Move. Je souhaite stocker différents types de ressources dans la même collection, mais leurs fonctionnalités sont différentes : NFT classiques : key + store(transférables) Jetons Soulbound : key uniquement (non transférables) Actifs personnalisés avec restrictions de transfert public struct Marketplace has key { id: UID, listings: Bag, // Want to store different asset types here } // This works for transferable assets public fun list_transferable( marketplace: &mut Marketplace, asset: T, price: u64 ) { /* ... */ } // But how to handle soulbound assets? public fun list_soulbound( // No store ability marketplace: &mut Marketplace, asset_ref: &T, // Can only take reference price: u64 ) { /* How do I store metadata about this? */ } Questions clés : Compétences requises : lors de l'utilisationdynamic_field::add(), en a-t-on Vtoujours besoin store au moment de la compilation ? Les types de wrapper peuvent-ils contourner ce problème ? Stockage hétérogène : un seul sac peut-il stocker des objets dotés de différents ensembles de capacités (key + store + copyvskey + store) et les gérer différemment lors de l'exécution ? Sécurité des types : étant donné que les champs dynamiques permettent d'effacer les caractères, comment puis-je garantir la sécurité des types lors de la récupération des valeurs ? Quel est le modèle de stockage des métadonnées de type ? Modèle de témoin : comment fonctionnent les contraintes de capacité avec les types de fantômes ? Puis-je stocker Assetet stocker Assetdans la même collection et extraire les informations de type ultérieurement ? Construire un système dans lequel les NFT, les jetons soul bound et les actifs restreints nécessitent tous des fonctionnalités de marché, mais avec une sémantique de transfert différente. J'ai essayé des types de wrapper, plusieurs collections par ensemble de capacités, un stockage de métadonnées de type séparé. Chacune comporte des compromis entre la sécurité du type, les coûts du gaz et la complexité.

    0
    5
  • Peera Admin.Peera.
    Peera Admin37
    PourSuiMay 29, 2025
    +10

    Pourquoi BCS exige-t-il un ordre de champs exact pour la désérialisation alors que les structures Move ont des champs nommés ?

    Pourquoi BCS exige-t-il un ordre de champs exact pour la désérialisation alors que les structures Move ont des champs nommés ? J'ai approfondi le codage/décodage BCS dans Move, en particulier pour la communication inter-chaînes et le traitement des données hors chaîne. En parcourant les exemples de la documentation de Sui Move, j'ai rencontré un comportement qui semble contre-intuitif et j'essaie de comprendre les décisions de conception sous-jacentes. Selon la spécification BCS, « il n'y a pas de structures dans BCS (puisqu'il n'y a pas de types) ; la structure définit simplement l'ordre dans lequel les champs sont sérialisés ». Cela signifie que lors de la désérialisation, nous devons utiliser peel_*les fonctions exactement dans le même ordre que la définition du champ de structure. Mes questions spécifiques : Justification de la conception : pourquoi BCS exige-t-il une correspondance exacte de l'ordre des champs alors que les structures Move ont des champs nommés ? Ne serait-il pas plus robuste de sérialiser les noms de champs à côté des valeurs, de la même manière que le JSON ou d'autres formats auto-descriptifs ? Interaction entre types génériques : La documentation mentionne que « les types contenant des champs de type générique peuvent être analysés jusqu'au premier champ de type générique ». Considérez cette structure : struct ComplexObject has drop, copy { id: ID, owner: address, metadata: Metadata, generic_data: T, more_metadata: String, another_generic: U } Comment fonctionne exactement la désérialisation partielle ici ? Puis-je désérialiser jusqu'à more_metadata et ignorer les deux champs génériques, ou est-ce que le premier champ générique (generic_data) bloque complètement la poursuite de la désérialisation ? Cohérence entre les langues : lorsque vous utilisez la bibliothèque JavaScript @mysten /bcs pour sérialiser les données qui seront consommées par les contrats Move, que se passe-t-il si : Je réorganise accidentellement les champs de l'objet JavaScript ? La définition de la structure Move change l'ordre des champs lors d'une mise à niveau du contrat ? J'ai des structures imbriquées avec leurs propres paramètres génériques ? Implications pratiques : dans les systèmes de production, comment les équipes gèrent-elles l'évolution du schéma BCS ? Versiez-vous vos schémas BCS ou vous attendez-vous à ce que l'ordre des champs de structure soit immuable une fois déployé ?

    5
    3

Le plus nouveau

  • Bekky.Peera.
    Bekky180
    PourSuiJul 24, 2025

    Sui en 2029 : futur leader ou candidat de niche ?

    Alors que Sui Network se fraie un chemin dans le paysage concurrentiel de la couche 1, la question brûlante demeure :Rejoindra-t-il l'élite de la blockchain ou restera-t-il un acteur spécialisé ? Cette analyse se décompose comme suit : 📊 La position actuelle de Sui sur le marché ⚔️ Batailles clés contre des chaînes rivales 🚀 Facteurs de croissance critiques 🔮 Deux futurs plausibles ##1. Fondation Sui 2024 Points forts actuels : Plus de 200 millions de dollars de TVL sur les protocoles DeFi Écosystème de jeu émergent (Panzerdogs, Bushi) Avantage technique : finalité inférieure à la seconde, frais inférieurs à 0,001$ Défis à venir : ▸ Suit Ethereum/Solana dans l'activité des développeurs ▸ A besoin de dApps innovantes pour égaler la popularité de ses concurrents ▸ Doit prouver son évolutivité en cas d'adoption massive ##2. Parcours vers le top 5 des dominants Des ruptures d'écosystème sont nécessaires DeFi :**Un protocole de niveau Uniswap Jeux :** Titre AAA avec plus d'un million de joueurs Entreprise :**Partenariat majeur avec un fournisseur de cloud Douves techniques à entretenir Supporte une capacité de plus de 100 000 TPS Pontage Ethereum/Solana sans faille Adoption avancée de l'abstraction des comptes Évolution de la tokenomique Des rendements de jalonnement compétitifs par rapport à l'ETH/SOL Mécanismes de pression déflationniste Solutions de garde institutionnelle ##3. Barrages routiers potentiels Développeur Mindshare Battles Taux d'adoption de Move par rapport à Solidity/Rust Migration de talents depuis Ethereum L2s Menaces concurrentielles | Chaîne | Avantage | | -------| -----------| | Solana | Traction commerciale | | Aptos | Offres d'entreprise | | Sei | Trading focus | Wildcards réglementaires Risques liés à la classification des jetons SUI Obstacles de conformité pour les applications DeFi ##4. Matrice de projection 2029 Meilleur cas (Top 5) : Capitalisation boursière de plus de 50 milliards de dollars 2 ou 3 DApps de premier plan Moteur d'adoption institutionnel Étui de base (Top 15) : Évaluation de 10 à 20 milliards de dollars Solide dans 1 à 2 secteurs verticaux (par exemple, pour les jeux vidéo) Chaîne de deuxième niveau fiable Dans le pire des cas (niche) : Valorisation inférieure à 5 milliards de dollars Éclipsé par ses rivaux Attrition des développeurs ##5. Les facteurs déterminants Le destin de Sui dépend de l'exécution : Développement d'applications Killer Adoption par les entreprises Liquidité inter-chaînes Décentralisation durable Lecycle de construction 2024-2025s'avérera décisif. ##Perspective finale Sui possède les bases techniques nécessaires à l'excellence, mais fait face à une concurrence féroce. Son avenir se situe probablement entre : Optimiste :**Solana de nouvelle génération Pessimiste :**Algorand suivant À votre tour : ▸ Où voyez-vous le classement de Sui en 2029 ? ▸ Quel est son défi décisif ?

    0
  • Opiiii.Peera.
    Opiiii103
    PourSuiJul 24, 2025

    Comment mettre en œuvre un système de gouvernance utilisant le modèle centré sur les objets de Sui ?

    *Je construis un DAO sur Sui et je souhaite utiliser des objets pour la gouvernance. Quelle est la meilleure façon de structurer la logique des votes et des propositions dans Move ? *

    0
    0
  • Ramirez.Peera.
    Ramirez125
    PourSuiJul 24, 2025

    Comment transférer l'USDC de Metamask vers Sui Wallet ?

    J'ai de l'USDC dans mon portefeuille Metamask et j'essaie de comprendre comment le retirer vers un portefeuille Sui. Puis-je simplement l'envoyer directement ou dois-je utiliser une méthode spécifique, telle que l'échange ou le pontage ? Toute orientation serait appréciée !

    0
    1

Sans réponse

  • Opiiii.Peera.
    Opiiii103
    PourSuiJul 24, 2025

    Comment mettre en œuvre un système de gouvernance utilisant le modèle centré sur les objets de Sui ?

    *Je construis un DAO sur Sui et je souhaite utiliser des objets pour la gouvernance. Quelle est la meilleure façon de structurer la logique des votes et des propositions dans Move ? *

    0
    0
  • shamueely.Peera.
    shamueely359
    PourSuiJul 22, 2025

    The Sui Stack: Building A Future Where We Don’t Have to Trust, We Can Verify

    Sui’s recent post featuring Evan Cheng, Co-Founder & CEO of Mysten Labs, is more than just another project update—it’s a deliberate reveal of how far the Sui Stack has matured and how it’s setting the standard for Layer 1 blockchain infrastructure. What Evan articulates in the video is a clear expression of what many of us building in crypto already understand: that performance, scalability, and developer accessibility aren’t just features they’re requirements for real world blockchain adoption. And Sui has built those into its core from the ground up. The Sui Stack stands out because it solves foundational pain points. Move, the language powering Sui, isn’t just secure it’s asset-native. This changes the game for tokenization, identity, and ownership. Every asset on Sui is treated as a first-class citizen, making composability, modularity, and verifiability more intuitive and robust. From an architectural standpoint, Sui introduces a powerful data model that avoids the bottlenecks of account-based chains. Objects are separate from accounts, meaning parallel execution can happen at scale, without compromising security or decentralization. This unlocks true horizontal scaling a crucial advantage when you’re talking about global, user-facing applications like games, social networks, and digital commerce. What I appreciate most about this update is how Mysten Labs continues to push for transparency. This isn’t just a roadmap or a PR stunt it’s a builder focused breakdown of where the tech is and where it’s headed. For developers, you get a framework built around object-centric programming. For enterprise and protocol teams, you get predictable throughput, finality under 2 seconds, and lower gas volatility this makes designing user first experiences on-chain much more viable. The video underscores why Sui is leading in innovation: zkLogin integration, verifiable off-chain computation, dynamic fields, and programmable transaction blocks these aren’t surface level features. They’re part of a long-term vision for chain utility and flexibility. And with Mysten Labs’ background in systems engineering and their involvement in Diem (formerly Libra), you know this vision is backed by some of the sharpest minds in blockchain R\&D. If you’re serious about building in Web3 whether infrastructure, consumer apps, or modular tooling, Sui gives you a complete foundation to build with purpose, scale with confidence, and deploy with clarity. I’ve followed Sui’s evolution from testnet to mainnet, and this update validates what many of us have known for a while: this chain isn’t just ready it’s redefining what readiness looks like in blockchain. Let’s keep the conversation going check https://x.com/SuiNetwork/status/1945910251720720794 for more. what parts of the Sui Stack are you most excited to build with next?

    0
    0
  • BitcoinADUK.Peera.
    BitcoinADUK10
    PourThe GraphMar 14, 2025

    GRT Token - qu'en pensez-vous ?

    The Graph (GRT) est un protocole décentralisé conçu pour indexer et interroger les données des blockchains, à commencer par Ethereum. Il permet aux développeurs de créer et de publier des API ouvertes, appelées sous-graphes, qui rendent les données de la blockchain facilement accessibles pour les applications décentralisées (DApps). Le jeton natif, GRT, est utilisé au sein du réseau par des participants tels que les indexeurs, les curateurs et les délégués afin de garantir la sécurité économique et l'intégrité des données interrogées. Au 14 mars 2025, GRT se négociait à environ 0,094$, avec un volume de transactions sur 24 heures d'environ 36 millions de dollars. Ce prix actuel reflète une baisse significative par rapport à son sommet historique de 2,84$, indiquant une tendance à la baisse au cours des dernières années. La trajectoire des prix du GRT a été influencée par divers facteurs, notamment les avancées technologiques, l'évolution de la réglementation et des indicateurs macroéconomiques plus généraux. Ces éléments ont collectivement contribué à la baisse de valeur observée au fil du temps. Veuillez noter que les marchés des cryptomonnaies sont très volatils et que les performances passées ne garantissent pas les résultats futurs. Il est essentiel de mener des recherches approfondies et de tenir compte de votre situation financière avant de prendre toute décision d'investissement.

    0
    0

Tendance

  • Vens.sui.Peera.
    Vens.sui216
    PourSuiApr 29, 2025

    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

    9
    3
  • 0xduckmove.Peera.
    0xduckmove1096
    PourSuiApr 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

    8
  • MarlKey.Peera.
    MarlKey61
    PourSuiApr 30, 2025

    Est-ce le seul moyen de publier des packages Move via un EOA ?

    Je suppose qu'il n'y a aucun moyen sur Sui chain car il n'y a pas de module sur la chaîne qui publie des packages.

    7
    3