Qu'est-ce que WalletConnect et comment ça marche ?

Architecture du protocole de base

1. WalletConnect fonctionne comme une couche de communication décentralisée basée sur un relais entre les portefeuilles et les dApps. Il ne stocke aucune clé privée ni aucune donnée de transaction sur un serveur central.

2. Le protocole utilise un cryptage de bout en bout pour tous les messages échangés entre les appareils clients, garantissant qu'aucun tiers, y compris le relais, ne puisse déchiffrer le contenu de la charge utile.

3. Chaque session génère une clé d'appariement unique dérivée de la cryptographie à courbe elliptique, de la liaison des identités de portefeuille et dApp sans exposer de matériel sensible.

4. Les métadonnées de session, y compris l'ID de chaîne, les autorisations demandées et l'origine de la dApp, sont signées cryptographiquement par les deux parties lors de l'initialisation.

5. Tous les états de session sont conservés localement sur les appareils des utilisateurs ; le relais transmet uniquement les charges utiles chiffrées sans les interpréter ni les conserver.

Mécanismes d’intégration du portefeuille

1. Les portefeuilles mobiles intègrent les SDK WalletConnect v2 pour exposer une logique de gestion de session standardisée dans leurs environnements natifs.

2. Lors de la numérisation d'un code QR, le portefeuille analyse l'URI contenant le point de terminaison du relais, l'identifiant du sujet et la clé de chiffrement symétrique.

3. Le portefeuille établit une connexion WebSocket avec le relais désigné et s'abonne à son propre sujet d'identification de homologue tout en écoutant les demandes entrantes.

4. Dès réception d'une proposition de session, le portefeuille affiche les éléments d'interface utilisateur indiquant le nom de la dApp, le contexte du réseau et l'étendue des autorisations demandées avant de demander l'approbation de l'utilisateur.

5. Les sessions approuvées déclenchent des opérations de signature locales à l'aide de clés privées stockées sur l'appareil, avec des charges utiles signées renvoyées directement à la dApp via le canal relais.

Couches d'application de la sécurité

1. Les clés privées ne quittent jamais l'enclave sécurisée du portefeuille mobile : les opérations de signature se déroulent entièrement hors ligne au sein du environnement d'exécution en bac à sable de l'application.

2. WalletConnect applique une validation de domaine stricte en vérifiant l'origine de la dApp par rapport aux métadonnées de la proposition de session, en rejetant les sources incompatibles ou non vérifiées.

3. L'expiration d'une session limitée dans le temps empêche un accès indéfini ; Les délais d'expiration par défaut vont de 7 à 30 jours en fonction de la mise en œuvre du portefeuille.

4. La révocation de session est initiée exclusivement par le propriétaire du portefeuille via des contrôles intégrés à l'application, déclenchant une résiliation immédiate au niveau du relais.

5. Toutes les primitives cryptographiques adhèrent aux normes approuvées par le NIST, notamment secp256k1 pour la signature et AES-256-GCM pour le cryptage des messages.

Cadre de compatibilité multi-chaînes

1. WalletConnect v2 prend en charge les espaces de noms de blockchain arbitraires au-delà des chaînes compatibles EVM, permettant l'interopérabilité avec Solana, Cosmos SDK, Polkadot Substrate et Aptos.

2. Le routage des requêtes spécifiques à la chaîne est géré via des identifiants d'espace de noms intégrés dans les propositions de session, permettant aux portefeuilles d'acheminer les transactions vers des environnements d'exécution corrects.

3. Les transferts d'actifs entre chaînes sont facilités grâce à des identifiants de compte CAIP-10 standardisés, dissociant la représentation de l'adresse du portefeuille des mécanismes de consensus sous-jacents.

4. Les développeurs de portefeuille implémentent des adaptateurs sensibles à la chaîne qui traduisent les méthodes génériques WalletConnect RPC en formats de transaction spécifiques à la chaîne avant la soumission.

5. La commutation de réseau s'effectue au niveau de la session plutôt qu'à l'échelle mondiale : les utilisateurs peuvent maintenir simultanément des sessions actives simultanées sur le réseau principal Ethereum, Arbitrum et Solana.

Gestion du cycle de vie des sessions

1. Une nouvelle session commence lorsqu'une dApp lance une demande de connexion et affiche un code QR scannable contenant les paramètres de session codés.

2. Après une analyse et une approbation réussies, le portefeuille enregistre un enregistrement de session persistant avec des métadonnées cryptées stockées dans le stockage local de l'appareil.

3. Les sessions actives apparaissent dans l'interface utilisateur du portefeuille sous « Applications connectées », affichant l'horodatage de la dernière interaction, la chaîne associée et l'ensemble d'autorisations.

4. Les utilisateurs peuvent déconnecter manuellement des sessions individuelles, déclenchant un message de désactivation crypté envoyé via le relais pour informer la dApp.

5. Les sessions inactives dépassant les valeurs TTL configurées sont automatiquement purgées du stockage du portefeuille et des caches mémoire du relais.

Foire aux questions

Q : WalletConnect peut-il être utilisé sans accès à Internet sur l'appareil portefeuille ? Non. Le portefeuille et la dApp nécessitent une connectivité réseau active pour établir et maintenir des sessions WebSocket via l'infrastructure du relais.

Q : WalletConnect prend-il en charge l'intégration du portefeuille matériel ? Oui. Les appareils Ledger et Trezor intègrent WalletConnect via des applications mobiles complémentaires qui agissent comme intermédiaires entre le signataire matériel et le flux de requêtes dApp.

Q : Les clés de session WalletConnect sont-elles récupérables si l'application de portefeuille est désinstallée ? Non. Les clés de session sont stockées exclusivement dans une mémoire volatile ou dans un stockage local crypté lié à l'instance d'installation de l'application spécifique et ne peuvent pas être restaurées après la désinstallation.

Q : Comment WalletConnect empêche-t-il les attaques de phishing lors de la numérisation du code QR ? Il intègre des contrôles de vérification de l'origine où le portefeuille compare le domaine déclaré de la dApp à l'URL réelle hébergeant la page d'initiation de session, bloquant ainsi les connexions provenant de sources incompatibles.