Come funzionano dietro le quinte gli explorer di blockchain

Il nodo: da dove provengono i dati

Tutto inizia con un nodo, perché un nodo è l'unica cosa che sa davvero cosa dice la blockchain.

Un nodo scarica blocchi dai peer, li valida contro le regole del protocollo, e mantiene lo stato risultante. Validazione è la parola importante. Un nodo non si fida di ciò che gli viene detto; controlla ogni firma, ogni script, ogni transizione di stato. È ciò che rende una blockchain affidabile tout court, ed è il motivo per cui un nodo è costoso da far girare.

Per un explorer, il nodo deve essere più che usualmente completo. Un nodo Bitcoin predefinito elimina i vecchi dati di blocco di cui non ha più bisogno; un nodo per explorer non può, perché qualcuno chiederà di una transazione del 2013. Ha anche bisogno di un indice delle transazioni, che non è abilitato per default e che aumenta significativamente lo storage. Su Ethereum l'equivalente è un nodo archivio, che conserva lo stato storico piuttosto che solo quello attuale e che arriva a più terabyte.

Questo è il costo singolo più grande nel gestire un explorer, ed è il motivo per cui gli explorer gratuiti sono più notevoli di quanto sembrino. Blockstream regala l'accesso API a un nodo Bitcoin completamente indicizzato senza nemmeno chiedere un indirizzo email, e l'infrastruttura dietro a ciò non è economica.

L’indicizzatore: trasformare dati di verifica in dati ricercabili

Un nodo memorizza la chain in una forma ottimizzata per validare il prossimo blocco. Quella forma è quasi inutile per rispondere alle domande che le persone fanno davvero.

Consideri "qual è il saldo di questo indirizzo". Su Bitcoin non c'è un tale campo da nessuna parte. La risposta richiede di trovare ogni output non speso associato a quell'indirizzo e sommarli, il che significa aver indicizzato gli output per indirizzo fin dall'inizio. Il nodo non lo fa, perché non ne ha bisogno.

Il compito dell'indicizzatore è percorrere la chain e scriverla in un database organizzato per queste domande: transazioni per indirizzo, output per script, log per topic, token per detentore. Decodifica anche — trasformando bytecode grezzo in chiamate di funzione leggibili, risolvendo contratti di token in nomi e decimali, ricostruendo transazioni interne dalle tracce di esecuzione.

È qui che avviene l'interpretazione, e dove gli explorer divergono. Come dovrebbe il saldo di un indirizzo trattare gli output che esistono solo nella mempool? Come dovrebbe essere contato un token con comportamento di trasferimento non standard? Cosa conta come la transazione "principale" quando una singola azione utente ha prodotto un albero di ricevute su NEAR o una catena di messaggi su TON?

Ogni explorer risponde diversamente, e nessuna di quelle risposte è scritta nel protocollo. Questa è tutta la ragione per cui due explorer onesti possono mostrarle numeri diversi.

L’API e il front end

Una volta che il database esiste, servirlo è ingegneria comparativamente ordinaria. Uno strato API accetta query, applica limiti di frequenza, e restituisce JSON. Un front end chiama quell'API e rende le pagine.

Due cose su questo strato valgono la pena di essere conosciute come utente.

La prima è che il sito web e l'API sono di solito la stessa cosa sotto. Quando sfoglia mempool.space, il suo browser sta chiamando gli stessi endpoint che chiamerebbe uno sviluppatore. Questo è il motivo per cui gli explorer con buone API tendono ad avere siti web reattivi, e perché un explorer lento a caricarsi è spesso lento a causa del suo front end piuttosto che dei suoi dati.

La seconda è che lo strato API è dove vivono le decisioni commerciali. Limiti di frequenza, requisiti di chiave e livelli a pagamento risiedono tutti qui, e si sono spostati notevolmente negli ultimi due anni. Blockscout ha spostato il traffico API dietro una chiave il 1° luglio 2026; Etherscan ha ridotto la sua copertura di chain sul livello gratuito nello stesso periodo. Nessuno dei due cambiamenti ha alterato i dati sottostanti di un solo byte. Il nostro confronto delle API segue la posizione attuale, perché qualsiasi cosa scritta prima del 2026 è ora inaffidabile.

Le riorganizzazioni, e perché un explorer può essere brevemente sbagliato

Su una chain proof-of-work, due miner possono produrre blocchi validi quasi nello stesso momento. Entrambi si propagano, parti diverse della rete ne vedono uno diverso per primo, e per un breve periodo ci sono due versioni concorrenti della storia recente. La rete risolve questo seguendo qualunque chain accumuli più lavoro, e il blocco perdente viene orfanato.

Le transazioni nel blocco orfanato non sono perse — di solito tornano alla mempool e vengono incluse in un blocco successivo — ma per alcuni minuti un explorer potrebbe averle mostrate come confermate in un blocco che non esiste più.

Questa è la ragione reale per cui i conteggi di conferme contano. Una conferma su Bitcoin non è una garanzia; è una probabilità che migliora rapidamente con ogni blocco successivo. Sei conferme è una convenzione scelta perché riorganizzazioni più profonde di quella sono estremamente rare, non perché sei sia un numero magico.

Chain diverse gestiscono questo diversamente. Ethereum proof-of-stake ha finalità esplicita dopo due epoch. L'XRP Ledger non ha fork nel senso ordinario, perché un ledger si chiude con accordo oppure non si chiude. I rollup hanno invece la distinzione sequencer-contro-regolamento. La nostra guida sulle conferme copre qual è la domanda equivalente su ogni chain.

Il ritardo di indicizzazione, e come individuarlo

Un indicizzatore deve tenere il passo con la chain. Quando rimane indietro — a causa di carico, un bug, un vincolo di risorse, o una chain che produce blocchi più velocemente di quanto il deployment fosse dimensionato per — l'attività recente semplicemente non appare.

Questo è indistinguibile da una transazione che non esiste, motivo per cui causa così tanto allarme non necessario. Qualcuno le invia un pagamento, lei controlla, l'explorer non mostra nulla, e la conclusione ragionevole è che qualcosa sia andato storto.

Il controllo richiede dieci secondi. Trovi l'ultima altezza di blocco riportata dall'explorer e la confronti con un secondo explorer o con il proprio RPC pubblico della chain. Se è indietro di migliaia di blocchi, quel deployment è in ritardo e tutto ciò che le mostra sull'attività recente è obsoleto.

Questo conta soprattutto sulle istanze Blockscout, perché chiunque può farne girare una e la qualità varia enormemente tra un deployment ben dotato di risorse e uno che qualcuno ha configurato diciotto mesi fa. Conta sugli explorer multi-chain che coprono reti di nicchia per la stessa ragione. Raramente conta sui grandi explorer commerciali, che sono ben finanziati precisamente perché l'uptime è il loro prodotto.

Cosa significa questo per come ne legge uno

Tre conclusioni derivano dal comprendere lo stack, e sono il valore pratico di aver letto fin qui.

Un explorer è un rendering, non la chain. Quando è in disaccordo con la sua aspettativa, le possibilità sono: la chain dice qualcosa che non si aspettava, l'indicizzatore ha interpretato qualcosa diversamente da come farebbe lei, o l'indice è obsoleto. Solo la prima riguarda davvero la blockchain, ed è la meno comune delle tre.

L'open source vale un peso reale. Con Blockscout, mempool.space o Esplora può leggere il codice e risolvere una domanda su come è stata derivata una cifra. Con un explorer chiuso può solo fidarsene. È per questo che la nostra valutazione lo premia.

Far girare il proprio elimina ogni strato di dubbio. Il suo nodo, il suo indice, le sue risposte, e nessuno impara cosa ha chiesto. Il costo è reale — centinaia di gigabyte e giorni di sincronizzazione per Bitcoin, terabyte per Ethereum — e la nostra guida all'auto-hosting è onesta su chi dovrebbe e chi non dovrebbe preoccuparsene.