Vai al contenuto

Nodo RPC

Un nodo RPC offre a wallet e applicazioni un'interfaccia richiesta-risposta per leggere dati blockchain e trasmettere transazioni. Scopri cosa può risolvere il cambio di endpoint, cosa non può risolvere e come ridurre i rischi di disponibilità, privacy e sicurezza.

Aggiornato

Solo a scopo educativo; non costituisce consulenza finanziaria. Un endpoint RPC errato o malevolo può esporre attività, restituire dati fuorvianti o interrompere l’invio delle transazioni; le operazioni su asset digitali possono causare perdite irreversibili.

Risposta diretta

Un nodo RPC è un nodo blockchain, o un servizio posto davanti a uno o più nodi, che accetta chiamate di procedura remota da wallet, explorer e applicazioni. Sulle reti compatibili con Ethereum, l’interfaccia comune è JSON-RPC. Consente al software di leggere dati del nodo, simulare chiamate, stimare il gas e inviare byte di transazioni firmate per la diffusione senza gestire un nodo proprio.

L’URL configurato nel wallet è un endpoint RPC, non la blockchain stessa. Cambiarlo può aggirare un’interruzione del provider, un nodo obsoleto, un limite di frequenza, un metodo non supportato o un problema di connessione. Non può modificare le regole di un contratto, recuperare una transazione annullata, invertire un trasferimento confermato o risolvere un arresto dell’intera rete. Il nuovo endpoint deve servire la rete e l’ID di catena previsti.

Come funziona

Il client invia una richiesta tramite un trasporto supportato, come HTTP o WebSocket. Una richiesta JSON-RPC indica il metodo, fornisce parametri e include un identificatore ripetuto nella risposta. Il nodo esegue il metodo sulla propria vista locale della catena e restituisce un risultato o un errore. Le connessioni WebSocket possono anche supportare sottoscrizioni se client ed endpoint le offrono.

I metodi di lettura hanno significati e requisiti diversi. Per esempio, eth_blockNumber riporta l’ultimo blocco noto al nodo, mentre eth_getBalance legge il saldo di un indirizzo a una determinata etichetta o numero di blocco. I risultati possono divergere temporaneamente tra nodi sani per differenze nella testa della catena, nei pool pendenti, nelle modalità di pruning o nelle estensioni. Un provider ospitato può imporre autenticazione, quote, limiti di dimensione o restrizioni di metodo che non sono regole di consenso.

In una tipica transazione, il wallet la costruisce e firma localmente, quindi invia i byte firmati con eth_sendRawTransaction. Il nodo RPC controlla la richiesta e tenta di propagare la transazione ai peer. La restituzione di un hash significa che il nodo ha accettato i byte per l’invio; non prova inclusione, successo o finalità. Inclusione e stato vanno verificati indipendentemente sulla catena corretta.

L’endpoint è quindi una dipendenza di fiducia e disponibilità. Può osservare indirizzi richiesti, informazioni IP, orari e transazioni inviate; può omettere o ritardare dati e presentare una vista obsoleta o incompleta. Le firme crittografiche impediscono di modificare di nascosto una transazione correttamente firmata, ma non rendono veritiere le risposte di lettura e non proteggono metadati non firmati o privacy.

Esempio

Un wallet può chiedere il numero del blocco a un client di esecuzione Ethereum con questa richiesta:

{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}

Una risposta valida potrebbe essere:

{"jsonrpc":"2.0","id":1,"result":"0x12ab34"}

Il risultato esadecimale è l’ultimo numero di blocco noto a quell’endpoint. Se il provider abituale va in timeout, ma un secondo endpoint affidabile restituisce un blocco più recente e l’ID di catena atteso, il cambio può ripristinare interrogazioni dei saldi e invio delle transazioni. Se entrambi mostrano la stessa ricevuta annullata, cambiare RPC non modifica quel risultato on-chain.

Rischi e controlli

  • Rete errata: un endpoint copiato può servire un’altra catena o fork. Prima di firmare, verifica da una fonte indipendente ID di catena, nome della rete, asset nativo e un blocco recente.
  • Letture false o obsolete: un endpoint difettoso o malevolo può restituire vecchi saldi, omettere log o falsare simulazioni. Confronta le letture importanti con un altro provider o nodo proprio e fissa un blocco esplicito quando serve riproducibilità.
  • Perdita di privacy: le richieste possono collegare l’attività del wallet ai metadati di rete. Evita indirizzi non necessari, esamina le politiche di conservazione e valuta un endpoint proprio affidabile quando la privacy giustifica il costo operativo.
  • Censura o ritardo: l’endpoint può rifiutare o ritardare la diffusione. Conserva l’hash firmato, controlla explorer o nodi indipendenti e usa un secondo percorso affidabile se la transazione manca. Non firmare una sostituzione senza verificare nonce ed effetti sulle commissioni.
  • Credenziali esposte: le chiavi API nel codice pubblico possono essere rubate ed esaurire le quote. Limita le chiavi per origine o servizio se possibile, tieni le credenziali privilegiate fuori dal client e ruota quelle divulgate.
  • Esposizione pericolosa del nodo: pubblicare un’interfaccia amministrativa o troppo ampia aumenta la superficie d’attacco. Associa il tuo RPC all’interfaccia locale per impostazione predefinita, esponi solo i namespace necessari, aggiungi autenticazione e controlli di rete e non esporre mai account sbloccati.
  • Inganno del wallet: un URL endpoint non richiede seed phrase o chiave privata. Rifiuta servizi che le chiedono, controlla i campi della transazione nel wallet e non identificare mai un contratto di destinazione dalla sola risposta RPC.

Errori comuni

  • “RPC è la blockchain.” È un’interfaccia verso la vista della blockchain detenuta da un nodo.
  • “Un hash significa conferma.” Di solito prova solo che l’endpoint ha accettato i byte firmati; esecuzione e finalità sono fasi separate.
  • “Cambiare RPC cambia commissioni o contratto.” Può cambiare stime o qualità di accesso, ma l’esecuzione reale dipende dalla transazione e dalle regole del protocollo.
  • “Tutti gli endpoint restituiscono gli stessi dati.” Sincronizzazione, pool pendenti, cronologia conservata, estensioni e politiche possono differire.
  • “HTTPS rende affidabile ogni risposta.” HTTPS protegge la connessione al server indicato, ma non prova che i suoi dati blockchain siano completi o corretti.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...