Comment configurer un portefeuille Soulbound Token (SBT) ? (Identité en chaîne)

Comprendre les exigences du portefeuille de jetons Soulbound

1. Un portefeuille Soulbound Token n'est pas une application autonome mais un portefeuille compatible Ethereum qui prend en charge les normes EIP-4973 et EIP-5639.

2. Les utilisateurs doivent détenir une adresse Ethereum avec suffisamment d'ETH pour couvrir les frais de gaz pour l'enregistrement de l'identité en chaîne et la frappe SBT.

3. Le portefeuille doit permettre l'interaction avec les contrats intelligents déployés sur le réseau principal ou les L2 pris en charge tels que Base, Arbitrum ou Optimism.

4. Les portefeuilles d'extension de navigateur comme MetaMask ou les portefeuilles mobiles comme Rainbow sont largement utilisés en raison de leur prise en charge des configurations RPC personnalisées et de l'interaction contractuelle.

5. La gestion des clés privées reste essentielle : les SBT sont non transférables mais liés en permanence à l'adresse de signature, ce qui rend la perte de clé irréversible pour l'ancrage de l'identité.

Déploiement ou connexion à un contrat de registre d'identité

1. Les développeurs ou les utilisateurs lancent la configuration de l'identité en interagissant avec un contrat de registre tel que celui de Gitcoin Passport ou du Biconomy Identity Hub.

2. Le contrat de registre valide les attestations hors chaîne (par exemple, activité GitHub, collection POAP, adhésion à DAO) avant d'émettre un SBT en chaîne.

3. Certains registres exigent la soumission d'une preuve basée sur la signature via la signature de données typées EIP-712, que les portefeuilles modernes gèrent de manière native.

4. Les contrats peuvent appliquer des mécanismes de révocation via une pause contrôlée par la gouvernance ou des clés de révocation au niveau du certificateur, bien que la plupart des implémentations actuelles donnent la priorité à l'immuabilité.

5. Les portefeuilles doivent être configurés pour reconnaître l'interface ERC-1155 ou ERC-721A du SBT afin d'afficher les jetons dans la vue des actifs sans recourir à des indexeurs centralisés.

Intégration des SBT dans les flux d'authentification dApp

1. Les applications Web3 utilisent les événements de connexion au portefeuille pour récupérer le solde SBT de l'utilisateur via eth_getBalance et eth_call vers la fonction balanceOf du contrat de jeton.

2. Les applications vérifient la propriété du SBT en vérifiant si l'adresse de l'appelant possède au moins un identifiant de jeton correspondant à un schéma requis (par exemple, « DAO Contributor v1 » ou « Gitcoin Steward Badge »).

3. Des preuves sans connaissance comme les zk-SNARK peuvent être générées hors chaîne pour prouver la possession de SBT sans révéler les identifiants de jeton – des outils comme Semaphore ou Risc0 permettent cette intégration.

4. Les bibliothèques frontales telles que Wagmi ou Viem résument les appels de bas niveau, permettant aux développeurs d'interroger les métadonnées SBT à l'aide de tokenURI et de restituer les attributs d'informations d'identification directement dans les interfaces utilisateur.

5. Les clés de session ou les protocoles d'accès délégués comme EIP-5792 sont parfois superposés aux SBT pour permettre des autorisations limitées dans le temps tout en préservant la liaison d'identité à long terme.

Gestion des sources d'attestation et de l'hygiène des informations d'identification

1. Les utilisateurs connectent manuellement des comptes sociaux, des fournisseurs de messagerie ou des identifiants décentralisés (DID) à des services d'attestation comme Verax ou Clique pour générer des réclamations vérifiables.

2. Chaque attestation correspond à une instance SBT unique créée dans le cadre d'un contrat dédié : deux émetteurs ne partagent pas la même adresse contractuelle, sauf coordination explicite.

3. Les interfaces de portefeuille affichent souvent les scores de réputation des émetteurs dérivés de l'exactitude des attestations historiques, mesurées en chaîne via des événements slashing ou des défis communautaires.

4. Les SBT en double ou en conflit provenant d'émetteurs non fiables peuvent déclencher des avertissements frontaux, invitant les utilisateurs à vérifier leur provenance avant d'accorder l'accès à des protocoles à enjeux élevés.

5. Les graphiques d'identité en chaîne émergent de manière organique à mesure que les portefeuilles regroupent les SBT à travers les chaînes, avec des ponts multicouches synchronisant les événements d'émission via des protocoles canoniques de transmission de messages.

Foire aux questions

Q : Puis-je importer une adresse Ethereum existante dans un nouveau portefeuille et conserver mes SBT ? R : Oui. Étant donné que les SBT sont liés à l'adresse (et non au logiciel de portefeuille), tout portefeuille contrôlant la clé privée reflétera tous les jetons associés une fois connecté au réseau approprié.

Q : Les portefeuilles matériels comme Ledger prennent-ils en charge les interactions SBT ? R : Oui, à condition que le micrologiciel prenne en charge la signature EIP-712 et que l'interface du portefeuille (par exemple, Ledger Live ou MyEtherWallet) autorise les appels de contrat personnalisés au registre SBT.

Q : Est-il possible de conserver des SBT sur plusieurs chaînes simultanément ? R : Oui. Chaque chaîne maintient son propre déploiement de contrat SBT. Une adresse peut contenir des SBT distincts mais sémantiquement équivalents sur Ethereum, Polygon et Arbitrum, chacun gouverné indépendamment.

Q : Que se passe-t-il si je perds l'accès à mon portefeuille mais que je récupère la phrase de départ plus tard ? R : Tous les SBT restent ancrés à l’adresse. La récupération rétablit le contrôle total sur ces jetons, y compris la possibilité de les présenter comme informations d'identification ou de répondre aux signaux de révocation.