Un endpoint RPC wallet è il servizio di rete attraverso cui un wallet legge lo stato della blockchain, stima le commissioni, simula le chiamate e trasmette transazioni già firmate. Di norma non riceve seed phrase o chiave privata: la firma deve restare nel wallet. L’endpoint occupa comunque una posizione privilegiata. Può associare un indirizzo IP agli account consultati, vedere una transazione prima del mempool pubblico, ritardare le risposte o fornire dati di chain falsi. Scegliere un RPC è quindi una decisione di privacy e integrità, non una semplice impostazione di velocità.
Questa guida chiarisce il confine JSON-RPC usato dai wallet compatibili con Ethereum, i controlli necessari in produzione e il compromesso tra nodo locale e provider terzo. Gli esempi riguardano reti EVM, ma il modello di fiducia è più generale: un server remoto risponde per conto di un software che può controllare asset di valore.
RPC wallet: cosa fa davvero l’endpoint
JSON-RPC è un protocollo richiesta-risposta. Il client invia un oggetto JSON con versione, metodo, parametri e identificatore; il server restituisce un risultato o un errore strutturato. Tra i metodi EVM comuni ci sono eth_chainId, eth_getBalance, eth_call, eth_estimateGas, eth_getTransactionCount, eth_sendRawTransaction ed eth_getTransactionReceipt. La documentazione JSON-RPC di Ethereum definisce l’interfaccia prevista.
La separazione tra lettura e firma è fondamentale. Un wallet ben progettato costruisce la transazione in locale, mostra rete, destinatario e importo, firma sul dispositivo e invia soltanto la transazione serializzata. L’RPC può rifiutarla o censurarla, ma non può cambiare importo o destinatario firmati senza invalidare la firma. Può però influenzare ciò che appare prima della conferma, mentendo su saldo, gas, metadati del token, esito di una simulazione o ultimo blocco.
Gli endpoint HTTP assumono spesso la forma https://provider.example/v3/project-id; quelli WebSocket usano wss:// e mantengono un canale persistente per nuovi blocchi o log. Un wallet può collegarsi anche a un nodo locale su http://127.0.0.1:8545. La porta è una convenzione, non una prova di identità o sicurezza.
Privacy di IP e metadati
Anche se le transazioni sono pubbliche, il modello delle interrogazioni non lo è. Il provider può registrare IP sorgente, orario, project key, user agent, chain richiesta, indirizzi inseriti nelle chiamate di saldo o log e transazione grezza al momento del broadcast. Richieste ripetute possono collegare indirizzi che la blockchain non associa in modo evidente. Operatore mobile, VPN, reverse proxy e resolver DNS aggiungono possibili punti di osservazione.
Un wallet non custodial, dunque, non è automaticamente privato. La chiave resta locale, ma discovery degli account e aggiornamento del portafoglio possono rivelare un cluster di indirizzi. Per inquadrare minacce e limiti normativi è utile la guida CryptoRoad su privacy crypto, strumenti e uso legittimo.
La mitigazione parte dalla minimizzazione. Disattiva la telemetria inutile e leggi la policy di conservazione. VPN o Tor nascondono l’IP domestico, ma non la correlazione tramite API key o richieste ricorrenti. Un nodo locale elimina il provider RPC, pur lasciando metadati nelle connessioni peer.
Endpoint malevoli e limiti della firma
Un endpoint malevolo non può creare una firma valida, ma può condizionare la decisione. Può falsare saldo, nonce, gas ed eth_call, censurare il broadcast o servire un fork. Metadati token non verificati producono importi ingannevoli. Contratti o calldata scelti dal server rendono pericolosa una firma opaca.
TLS autentica il server certificato e protegge il trasporto, ma non lo rende onesto. Anche il dominio di un attaccante può avere un certificato valido. Confronta l’host con la documentazione ufficiale, non con annunci o messaggi diretti.
La conferma finale deve mostrare rete, destinazione, valore e azione decodificata reali. Per operazioni importanti, verifica il contratto da una seconda fonte e usa un hardware wallet il cui display affidabile presenti dettagli significativi. Il confronto CryptoRoad tra wallet custodial, non custodial, hot e cold spiega il confine della firma; nessun dispositivo, però, corregge un contesto ingannevole che l’utente approva.
Chain ID, genesis e freschezza dei dati
Il primo controllo tecnico è eth_chainId. Ethereum mainnet restituisce 0x1 in esadecimale; le altre reti hanno ID differenti. Il valore configurato nel wallet deve coincidere con risposta e rete desiderata. Il chain ID limita il replay tra reti compatibili con EIP-155, ma non prova da solo l’identità: una chain privata o malevola può dichiarare volontariamente un valore noto.
Confronta inoltre checkpoint, altezza corrente e hash finalizzato con una fonte indipendente. Verifica che l’altezza avanzi e il sync sia concluso. Una risposta di saldo non basta: l’endpoint può essere coerente ma vecchio, isolato o sulla chain sbagliata.
L’applicazione dovrebbe rifiutare un chain ID difforme, senza cambiare rete in silenzio. Deve inoltre imporre un’età massima a fee data e header. Se due provider indipendenti divergono sull’hash di un blocco finalizzato, interrompi le firme e indaga: scegliere la risposta più veloce non risolve il conflitto.
TLS, autenticazione ed esposizione sicura
Per ogni collegamento esterno all’host usa HTTPS o WSS. Verifica normalmente i certificati, mantieni aggiornato il trust store del sistema e non aggirare mai un avviso disattivando i controlli. Le API key vanno in un secret store o in configurazioni separate, non nel repository, negli screenshot o nel frontend se il provider le considera riservate. Nei wallet client-side alcuni identificatori sono inevitabilmente visibili: limita origine, metodi, chain, rate e quota quando possibile.
Un nodo self-hosted non deve esporre namespace privilegiati su Internet. La documentazione RPC di Geth distingue trasporti e API; metodi amministrativi, personal e debug richiedono controlli stretti. Associa l’interfaccia a loopback o rete privata, proteggi l’accesso remoto con VPN o reverse proxy autenticato, applica firewall e abilita solo i metodi necessari. Non esporre mai via RPC un account sbloccato.
L’autenticazione decide chi entra; l’autorizzazione cosa può chiamare. Rate limit e log minimizzati contengono abusi e aiutano la diagnosi. Ruota subito una chiave trapelata e cerca traffico anomalo.
Nodo locale o provider terzo: tabella decisionale
| Opzione | Vantaggi | Vincoli e rischi | Quando sceglierla |
|---|---|---|---|
| Nodo full locale | Verifica diretta; nessun log RPC esterno; controllo dei metodi | Storage, banda, aggiornamenti, monitoraggio e tempo di sync; restano i metadati peer | Asset elevati, team e attività sensibili alla privacy |
| Endpoint gestito dedicato | Capacità stabile, supporto, ACL e metriche | Il provider osserva le richieste; rischio credenziali, costi e fiducia nei dati | Applicazioni di produzione con presidio operativo |
| Endpoint pubblico condiviso | Avvio rapido e nessun account | Rate limit, garanzie deboli, log ignoti e congestione | Test a basso rischio e dati pubblici |
| Provider indipendenti multipli | Disponibilità e confronto | Più complessità; più esposizione; upstream comuni possibili | Sistemi con regole di quorum esplicite |
Il nodo locale verifica bene solo se è sano: client obsoleto, database bloccato o API aperta possono essere peggiori di un provider serio. La scelta dipende da valore, privacy e capacità di manutenzione. Capire come Ethereum rappresenta lo stato distingue verifica autonoma e fiducia spostata.
Failover senza ampliare la fiducia in silenzio
Il failover deve essere una policy, non un elenco casuale di URL. Definisci endpoint primario, alternative sotto controllo amministrativo diverso, criteri di salute e metodi ammessi al retry automatico. Letture come l’altezza del blocco possono migrare facilmente. Prompt di firma e broadcast richiedono cautela: il fallback cambia chi vede i metadati e può produrre simulazioni differenti.
Fissa il chain ID atteso per ogni endpoint. Misura latenza, errori, freschezza e accordo sui blocchi finalizzati. Usa circuit breaker per escludere temporaneamente un servizio guasto, backoff esponenziale limitato e identificatori di richiesta nei log. Non trasmettere la stessa operazione all’infinito: un timeout può indicare che il provider l’ha accettata ma ha perso la risposta. Cerca prima il transaction hash.
Il quorum aiuta solo con fonti davvero indipendenti. Marchi diversi possono condividere l’upstream: documenta proprietà e dipendenze.
Scenario pratico: preparare un trasferimento importante
Un operatore di tesoreria deve inviare token su Ethereum mainnet. Il provider predefinito segnala un saldo insolitamente basso e una stima gas dieci volte superiore al normale. La risposta corretta non è continuare a cliccare finché l’avviso scompare.
- Fermarsi prima della firma e annotare hostname, ora, chain ID, ultimo blocco ed errori, senza copiare segreti.
- Controllare
eth_chainId, stato di sync se disponibile e ultimo blocco finalizzato tramite provider separato o nodo locale sano. - Leggere il saldo con
eth_callsul contratto verificato e confrontare indirizzo e decimali con la fonte ufficiale del token. - Costruire il trasferimento, decodificare il calldata, verificare importo e destinatario sul display hardware e simulare con due fonti.
- Trasmettere una volta, salvare il transaction hash e seguirne la receipt. La checklist per inviare crypto senza errori completa i controlli su rete e indirizzo.
Se la divergenza riguarda solo il gas pending, si applica la fee policy prevista. Se riguarda stato finalizzato, codice del contratto o identità della chain, l’operazione resta bloccata. L’urgenza operativa non giustifica la rimozione di un controllo d’integrità.
Testare un endpoint prima di fidarsi
Inizia con una richiesta read-only: {"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}. Recupera poi l’ultimo blocco, confronta timestamp e hash, interroga un account o contratto noto e prova la gestione degli errori con un metodo inesistente. Misura più campioni, non una sola latenza. Su WebSocket verifica riconnessione, eventi persi e duplicati.
Usa un wallet di test separato e una transazione di valore minimo sulla rete realmente interessata. Controlla nonce, campi fee, risposta al broadcast e receipt. Le reti di sviluppo servono per la logica: la guida MetaMask su come eseguire una devnet è utile, ma non riproduce fiducia e congestione di mainnet.
I probe automatici devono avvisare su cambio del chain ID, ritardo dei blocchi, hash finalizzati divergenti, scadenza TLS, errori di autenticazione, latenza e metodi inattesi. Non confondere interfacce diverse: la Kubo RPC API di IPFS ha regole proprie e non è un endpoint Ethereum JSON-RPC.
Errori comuni e risposta agli incidenti
Errori tipici sono scegliere il primo URL, usare HTTP, inserire API key nel codice, abilitare tutti i namespace, ignorare chain ID difformi e considerare il failover una prova. Conserva evidenze minime proteggendo indirizzi e credenziali.
Se sospetti manipolazione, interrompi le firme e scollega l’endpoint. Conserva orari, hostname, campioni di risposta, hash e configurazione. Ruota le chiavi, revoca token esposti, controlla applicazione e browser e confronta lo stato tramite un nodo noto. Se hai firmato un’approvazione malevola, trasferisci gli asset residui da un dispositivo integro quando è sicuro e revoca le allowance. Invia al provider evidenze precise e monitora gli indirizzi coinvolti.
Non inserire mai la seed phrase in una pagina di “riparazione”: un guasto RPC non richiede parole di recupero. Se una transazione firmata è stata trattenuta, ritrasmetti lo stesso raw transaction tramite endpoint affidabile; non firmare una sostituzione finché non comprendi nonce e commissioni.
Checklist e conclusione
- Conferma hostname ufficiale, certificato HTTPS/WSS e chain ID atteso.
- Confronta freschezza e hash finalizzato con una fonte indipendente.
- Comprendi quali metadati IP, account, project key e transazione vengono registrati.
- Mantieni la firma locale e verifica rete, contratto, destinatario, importo e calldata.
- Limita credenziali, origini, metodi, quote, interfacce e firewall.
- Definisci failover, retry e quorum prima di un’interruzione.
- Testa con wallet separato e valore minimo; monitora continuamente.
- Prepara una procedura per rotazione, evidenze e rebroadcast sicuro.
Un RPC wallet non è né un tubo innocuo né il custode della chiave privata. È una fonte di stato, un canale di trasmissione e un osservatore di metadati. La configurazione migliore proporziona i controlli al valore: nodo locale mantenuto per verifica forte, provider governati per praticità o fonti indipendenti con regole esplicite di disaccordo. In ogni modello valgono le stesse abitudini: autenticare il trasporto, fissare la chain, verificare lo stato critico, minimizzare i dati e fermarsi quando fonti affidabili divergono.
