Un endpoint RPC wallet est le service réseau grâce auquel un wallet lit l’état de la blockchain, estime les frais, simule des appels et diffuse des transactions signées. Il ne reçoit normalement ni phrase de récupération ni clé privée : la signature doit rester dans le wallet. Il occupe néanmoins une position privilégiée. Il peut associer une adresse IP aux comptes consultés, voir une transaction avant son arrivée dans le mempool public, retarder les réponses ou fournir de fausses données de chaîne. Choisir un RPC relève donc de la confidentialité et de l’intégrité, pas seulement des performances.
Ce guide décrit la frontière JSON-RPC des wallets compatibles avec Ethereum, les contrôles utiles en production et l’arbitrage entre nœud local et fournisseur tiers. Les exemples concernent les réseaux EVM, mais le modèle de confiance est général : un serveur distant répond pour un logiciel susceptible de contrôler des actifs importants.
RPC wallet : le rôle réel de l’endpoint
JSON-RPC est un protocole de requête-réponse. Le client envoie un objet JSON contenant version, méthode, paramètres et identifiant ; le serveur renvoie un résultat ou une erreur structurée. Parmi les méthodes EVM courantes figurent eth_chainId, eth_getBalance, eth_call, eth_estimateGas, eth_getTransactionCount, eth_sendRawTransaction et eth_getTransactionReceipt. La référence JSON-RPC d’Ethereum décrit l’interface attendue.
La séparation entre lecture et signature est fondamentale. Un wallet bien conçu construit la transaction localement, affiche réseau, destinataire et montant, signe sur l’appareil, puis transmet uniquement la transaction sérialisée. Le RPC peut la refuser ou la censurer, mais ne peut modifier les champs signés sans invalider la signature. En revanche, il peut influencer l’écran précédent en mentant sur le solde, les frais, les métadonnées d’un token, une simulation ou le dernier bloc.
Les endpoints HTTP ressemblent souvent à https://provider.example/v3/project-id. Les endpoints WebSocket utilisent wss:// et gardent un canal ouvert pour les nouveaux blocs ou journaux. Un wallet peut joindre un nœud local sur http://127.0.0.1:8545. Ce port est une convention, jamais une preuve d’identité.
Confidentialité de l’adresse IP et des métadonnées
Le contenu d’une transaction peut être public sans que le schéma des requêtes le soit. Le fournisseur peut journaliser IP source, heure, clé de projet, user-agent, réseau demandé, adresses placées dans les appels de solde ou de logs et transaction brute au moment de la diffusion. Des requêtes répétées peuvent relier des adresses que la blockchain ne rapproche pas clairement. Opérateur mobile, VPN, proxy inverse et résolveur DNS ajoutent d’autres observateurs potentiels.
Un wallet non custodial n’est donc pas automatiquement privé. La clé reste locale, mais la découverte des comptes et l’actualisation du portefeuille peuvent révéler un ensemble d’adresses. Le dossier CryptoRoad sur les outils de confidentialité crypto et leurs contraintes de conformité complète ce modèle de menace.
La réduction du risque commence par la minimisation. Désactivez la télémétrie inutile et consultez la politique de conservation. VPN ou Tor masque l’IP résidentielle, mais pas une corrélation fondée sur une clé API ou un profil stable. Un nœud local supprime le tiers RPC, tandis que ses connexions pair-à-pair produisent encore des métadonnées.
Endpoints malveillants et limites de la signature
Un endpoint malveillant ne peut forger une signature, mais peut orienter la décision. Il peut falsifier solde, nonce, gas et eth_call, censurer une diffusion ou servir un fork. Des métadonnées de token non vérifiées créent un affichage trompeur. Contrat ou calldata choisis par le serveur rendent une signature opaque particulièrement dangereuse.
TLS authentifie le serveur certifié et protège le transport, sans le rendre honnête. Le domaine d’un attaquant peut avoir un certificat valide. Comparez l’hôte à la documentation officielle, jamais à une publicité ou un message privé.
La confirmation finale doit afficher le réseau, la destination, la valeur et l’action décodée. Pour une opération importante, contrôlez le contrat par une autre source et utilisez un hardware wallet dont l’écran fiable montre des détails utiles. Le comparatif CryptoRoad des wallets custodial, non custodial, hot et cold précise la frontière de signature ; aucun appareil ne peut corriger un contexte mensonger que l’utilisateur approuve.
Chain ID, bloc genesis et fraîcheur
Le premier contrôle technique porte sur eth_chainId. Ethereum mainnet renvoie 0x1 en hexadécimal ; chaque autre réseau possède son identifiant. La configuration du wallet doit correspondre à la réponse et au réseau visé. Le chain ID limite les replays entre réseaux compatibles EIP-155, mais ne constitue pas une identité complète : une chaîne privée ou hostile peut déclarer une valeur connue.
Comparez aussi checkpoint fiable, hauteur actuelle et hash finalisé avec une source indépendante. Vérifiez que la hauteur avance et la synchronisation est terminée. Une réponse de solde prouve peu : l’endpoint peut être cohérent, mais obsolète, isolé ou sur le mauvais réseau.
L’application doit refuser une divergence de chain ID plutôt que basculer silencieusement. Elle doit imposer une ancienneté maximale aux données de frais et aux en-têtes. Si deux fournisseurs indépendants divergent sur un bloc finalisé, arrêtez les signatures et enquêtez ; retenir la réponse la plus rapide ne résout rien.
TLS, authentification et exposition maîtrisée
Utilisez HTTPS ou WSS dès que la connexion quitte la machine. Validez normalement les certificats, actualisez le magasin de confiance du système et ne contournez jamais un avertissement. Les clés API appartiennent à un coffre de secrets ou à une configuration dédiée, pas au dépôt, aux captures d’écran ou au frontend lorsqu’elles doivent rester confidentielles. Dans un wallet côté client, certains identifiants sont visibles : restreignez origine, méthode, chaîne, débit et quota si possible.
Un nœud autohébergé ne doit pas exposer ses espaces privilégiés sur Internet. La documentation RPC de Geth distingue transports et API ; les méthodes administratives, personnelles et de debug exigent des contrôles stricts. Écoutez sur loopback ou réseau privé, placez l’accès distant derrière VPN ou proxy authentifié, filtrez par pare-feu et n’autorisez que les méthodes indispensables. N’exposez jamais un compte déverrouillé par RPC.
L’authentification décide qui entre ; l’autorisation, ce qu’il peut appeler. Limites de débit et logs minimisés contiennent les abus. En cas de fuite, faites tourner la clé et recherchez le trafic anormal.
Nœud local ou fournisseur tiers : aide à la décision
| Solution | Atouts | Contraintes et risques | Usage adapté |
|---|---|---|---|
| Nœud complet local | Vérification directe ; aucun journal RPC tiers ; contrôle des méthodes | Stockage, bande passante, mises à jour, supervision et synchronisation ; métadonnées P2P | Forte valeur, équipes et besoins de confidentialité |
| Endpoint dédié géré | Capacité stable, support, contrôles d’accès et métriques | Requêtes observées ; risques de clé, de coût et de confiance | Applications en production |
| Endpoint public partagé | Mise en route rapide sans compte | Quotas, garanties faibles, journalisation inconnue et congestion | Tests peu risqués et données publiques |
| Plusieurs fournisseurs indépendants | Disponibilité et recoupement | Complexité, exposition accrue et upstream commun possible | Systèmes dotés de règles de quorum |
Un nœud local vérifie bien seulement s’il est sain. Client ancien, base bloquée ou API ouverte peuvent être pires qu’un fournisseur sérieux. Le choix dépend de la valeur, de la confidentialité et de la maintenance. Comprendre le fonctionnement de l’état Ethereum distingue auto-vérification et confiance déplacée.
Failover sans élargissement silencieux de la confiance
Le failover doit être une politique, non une liste aléatoire d’URL. Définissez endpoint principal, solutions sous administrations différentes, critères de santé et méthodes pouvant être rejouées automatiquement. Une lecture de hauteur bascule facilement. Les simulations, demandes de signature et diffusions exigent plus de prudence, car le fournisseur de secours voit de nouvelles métadonnées et peut répondre différemment.
Fixez le chain ID attendu pour chaque endpoint. Mesurez latence, erreurs, fraîcheur et accord des blocs finalisés. Un circuit breaker écarte temporairement un service défaillant ; un backoff exponentiel borné évite les boucles. Conservez l’identifiant des requêtes dans les logs. Ne rediffusez pas sans fin : un timeout peut signifier que la transaction a été acceptée mais que la réponse s’est perdue. Recherchez d’abord son hash.
Un quorum aide seulement avec des sources indépendantes. Plusieurs marques peuvent partager le même upstream : documentez propriété et dépendances.
Scénario pratique : un transfert de tokens important
Un opérateur prépare un transfert mainnet. Le fournisseur indique un solde anormal et un gas dix fois supérieur. Il faut s’arrêter, pas ignorer l’alerte.
- S’arrêter avant la signature et relever nom d’hôte, heure, chain ID, dernier bloc et erreurs, sans copier de secret.
- Contrôler
eth_chainId, la synchronisation et le dernier bloc finalisé depuis un fournisseur séparé ou un nœud local sain. - Lire le solde par
eth_callsur le contrat vérifié et comparer adresse et décimales avec la source officielle du token. - Construire le transfert, décoder le calldata, vérifier montant et destinataire sur l’écran matériel, puis simuler via deux sources.
- Diffuser une seule fois, conserver le hash et suivre le reçu. La checklist pour envoyer des cryptos complète les contrôles d’adresse et de réseau.
Un désaccord sur les frais pending suit la politique prévue. Un conflit sur état finalisé, contrat ou chaîne bloque l’opération ; l’urgence ne prime jamais sur l’intégrité.
Tester un endpoint avant de lui faire confiance
Commencez par {"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}. Récupérez ensuite le dernier bloc, comparez timestamp et hash, interrogez un compte ou contrat connu et testez une méthode invalide. Mesurez plusieurs échantillons. Pour WebSocket, vérifiez reconnexion, événements manqués et doublons.
Utilisez un wallet de test séparé et une transaction de faible valeur sur le vrai réseau cible. Contrôlez nonce, champs de frais, réponse de diffusion et reçu. Les réseaux de développement valident la logique ; le guide MetaMask pour exécuter une devnet est utile, mais ne reproduit ni confiance ni congestion de mainnet.
Les sondes doivent alerter sur changement de chain ID, retard de blocs, hashes finalisés divergents, expiration TLS, erreurs d’authentification, latence et méthodes inattendues. Ne confondez pas les interfaces : l’API RPC de Kubo IPFS possède ses propres règles d’exposition et n’est pas un endpoint Ethereum JSON-RPC.
Erreurs fréquentes et réponse à incident
Les erreurs courantes sont la première URL trouvée, HTTP non sécurisé, une clé committée, tous les espaces activés, un chain ID divergent ignoré et le failover pris pour preuve. Préservez les preuves minimales en protégeant adresses et secrets.
En cas de manipulation suspectée, arrêtez de signer et déconnectez l’endpoint. Conservez heures, hôtes, échantillons, hashes et configuration. Faites tourner les clés, révoquez les jetons exposés, examinez application et navigateur, puis comparez l’état avec un nœud reconnu. Si une approbation hostile a été signée, déplacez les actifs restants depuis un appareil sain lorsque c’est sûr et révoquez les allowances. Transmettez au fournisseur des preuves précises.
Ne saisissez jamais la phrase de récupération dans une page de « réparation ». Une panne RPC ne la réclame pas. Si une transaction signée a été retenue, rediffusez exactement la même transaction brute via un endpoint fiable ; ne signez un remplacement qu’après analyse du nonce et des frais.
Checklist et conclusion
- Confirmer l’hôte officiel, le certificat HTTPS/WSS et le chain ID.
- Comparer fraîcheur et hash finalisé avec une source indépendante.
- Comprendre les journaux d’IP, d’adresses, de clé projet et de transaction.
- Garder la signature locale et vérifier réseau, contrat, destinataire, valeur et calldata.
- Limiter identifiants, origines, méthodes, quotas, interfaces et pare-feu.
- Définir failover, retry et quorum avant une panne.
- Tester avec un wallet séparé et une faible valeur ; superviser en continu.
- Préparer rotation des clés, conservation des preuves et rediffusion sûre.
Un RPC wallet n’est ni un simple tuyau ni le dépositaire de la clé privée. C’est une source d’état, un canal de diffusion et un observateur de métadonnées. La configuration doit suivre la valeur exposée : nœud local maintenu pour une vérification forte, fournisseurs gouvernés pour la simplicité ou sources indépendantes avec règles explicites de désaccord. Dans tous les cas, authentifiez le transport, fixez la chaîne, vérifiez l’état critique, minimisez les données et arrêtez-vous lorsque les sources fiables divergent.
