Comment connecter un portefeuille à une dApp ? (bases du Web3)

Comprendre les mécanismes d'intégration du portefeuille

1. Une application décentralisée s'appuie sur une identité cryptographique pour authentifier les utilisateurs et signer les transactions. Cette identité réside dans un portefeuille qui contient les clés privées et gère les signatures numériques.

2. Les portefeuilles comme MetaMask, Phantom ou Trust Wallet exposent une interface standardisée connue sous le nom d'API du fournisseur Ethereum (EIP-1193), permettant aux dApps de les détecter et de communiquer avec eux.

3. Lorsqu'une dApp s'initialise, elle vérifie la présence de window.ethereum ou d'objets fournisseurs similaires injectés par des extensions de navigateur ou des portefeuilles mobiles.

4. L'absence d'un tel objet déclenche une logique de secours, soit en incitant à l'installation, soit en suggérant un mode de connexion au portefeuille pour les utilisateurs mobiles.

5. Une fois détectée, la dApp demande l'autorisation d'accéder aux comptes de l'utilisateur à l'aide de ethereum.request({ method: 'eth_requestAccounts' }) , déclenchant une poignée de main sécurisée et approuvée par l'utilisateur.

Gestion des états et des événements de connexion

1. La connexion au portefeuille n'est pas statique : elle peut changer en raison d'un changement de compte, d'un changement de réseau ou d'une déconnexion. Les dApps doivent écouter des événements tels que 'accountsChanged' , 'chainChanged' et 'disconnect' .

2. L'événement 'accountsChanged' se déclenche lorsque l'utilisateur sélectionne un autre compte ou supprime l'accès. Il fournit un tableau de nouvelles adresses ou un tableau vide si les autorisations sont révoquées.

3. L'événement « chainChanged » signale un basculement entre les réseaux (par exemple, Ethereum Mainnet vers Sepolia). Les applications doivent recharger ou réinitialiser les instances de contrat en conséquence.

4. La déconnexion peut se produire silencieusement, en particulier après le verrouillage du portefeuille ou la désactivation de l'extension, de sorte que des contrôles de santé périodiques via ethereum.isConnected() aident à maintenir la cohérence de l'interface utilisateur.

5. La gestion persistante de l'état nécessite de stocker l'ID de chaîne et l'adresse de compte sélectionnés dans la mémoire ou dans le stockage local, mais jamais la clé privée ou la phrase de départ.

Signer des transactions sans révéler de secrets

1. Toutes les signatures de transactions ont lieu dans l'environnement du portefeuille, et non dans le contexte JavaScript de la dApp. La dApp construit des paramètres de transaction bruts et les transmet à ethereum.request({ method: 'eth_sendTransaction', params: [...] }) .

2. Le portefeuille affiche une interface utilisateur de confirmation indiquant le destinataire, la valeur, les estimations de gaz et la charge utile des données. Les utilisateurs approuvent ou rejettent sans exposer leur clé privée à aucun code externe.

3. Pour les messages hors chaîne, comme les défis de connexion ou les votes de gouvernance, la dApp utilise personal_sign ou eth_signTypedData_v4 pour demander des signatures cryptographiquement vérifiables.

4. La signature de données typées applique une séparation structurée des domaines et empêche la relecture entre les chaînes ou les applications grâce au sel et au versionnage spécifiques au domaine.

5. La vérification de la signature en chaîne ou dans les services backend s'appuie sur ecrecover ou des primitives cryptographiques équivalentes pour dériver l'adresse du signataire à partir de la signature et du hachage du message.

Protocole WalletConnect pour les scénarios mobiles et sans extension

1. WalletConnect v2 établit des sessions cryptées de bout en bout entre les dApps et les portefeuilles à l'aide de serveurs relais et d'URI de couplage. Cela évite complètement l’injection du navigateur.

2. La dApp génère une proposition de session contenant les chaînes, méthodes et métadonnées requises, puis affiche un code QR contenant un URI d'appariement.

3. L'utilisateur scanne le code QR avec une application de portefeuille compatible, telle que Rainbow ou Coinbase Wallet, qui valide la proposition avant d'approuver la session.

4. Une fois connectées, toutes les requêtes JSON-RPC transitent par le réseau de relais, avec des clés de chiffrement négociées lors du couplage et alternées par session.

5. La persistance de la session est gérée côté client ; la révocation se produit lorsque l'une ou l'autre des parties appelle session.disconnect() , invalidant toutes les clés associées et effaçant les métadonnées stockées.

Foire aux questions

Q1 : Une dApp peut-elle lire ma clé privée pendant la connexion ? A1. Non. Les portefeuilles n’exposent jamais les clés privées aux dApps. La signature s'effectue toujours dans les limites sécurisées du portefeuille.

Q2 : Pourquoi mon portefeuille demande-t-il une approbation à chaque fois que je change de réseau ? A2. Chaque chaîne compatible EVM possède son propre espace de noms et son propre chemin de dérivation de compte. Les autorisations sont limitées par chaîne, nécessitant une nouvelle approbation explicite.

Q3 : Que se passe-t-il si je vide le cache de mon navigateur après la connexion ? A3. L'état de connexion est perdu à moins que la dApp n'implémente la récupération de session via WalletConnect ou ne stocke séparément les identifiants non sensibles tels que l'adresse du portefeuille et l'ID de chaîne.

Q4 : Est-il sûr de se connecter à une dApp qui n'est pas vérifiée sur Etherscan ? A4. Non. Les dApps non vérifiées peuvent injecter des scripts malveillants ou des invites de portefeuille frauduleuses. Vérifiez toujours les adresses de contrat, vérifiez la légitimité du domaine et évitez de saisir des phrases de départ n'importe où.