Perché conta un explorer open source
Un explorer è un'interpretazione. Legge una chain, decide come aggregarla, e rende il risultato. Ognuna di quelle decisioni potrebbe essere sbagliata, e con un explorer chiuso non ha modo di controllare — o si fida dell'output o fa girare un nodo e riconcilia a mano.
Con Blockscout legge l'indicizzatore. Quando un saldo sembra sbagliato, può trovare il codice che l'ha calcolato. Quando due explorer non sono d'accordo, può vedere cosa uno dei due sta facendo diversamente. Questo non è un beneficio teorico: gli explorer non concordano sui saldi di token più spesso di quanto le persone presumano, di solito su come gestiscono contratti non standard che emettono eventi di trasferimento irregolari.
La seconda ragione è economica. Etherscan decide quali chain supporta, e quella decisione è commerciale. Un nuovo rollup non può semplicemente comprarsi un posto nella lista. Blockscout significa che una chain può avere un explorer credibile il giorno in cui viene lanciata facendone girare uno, e questo l'ha resa lo standard de facto per l'intero ecosistema di rollup.
Il cambio di chiave API, e cosa ha rotto
Il 1° luglio 2026, Blockscout ha spostato il traffico API su una Pro API con chiave. Il codice che chiamava istanze ospitate anonimamente ha smesso di funzionare.
Il livello gratuito non è avaro — circa 100.000 crediti al giorno a cinque richieste al secondo, il che copre comodamente la maggior parte degli usi non commerciali. Ma il cambiamento conta per una ragione specifica che non ha nulla a che fare con il volume: un'API con chiave non può essere chiamata da codice browser. Qualsiasi cosa che chiamava un'istanza Blockscout direttamente da un front end ora ha bisogno di un server in mezzo.
Questo è lo stesso vincolo che Etherscan ha sempre avuto, ed è perché il numero di API di explorer genuinamente chiamabili da browser continua a restringersi. I sopravvissuti sono Blockstream, mempool.space, Blockchair e 3xpl. La nostra comparazione API traccia lo stato attuale, perché è ormai cambiato due volte in diciotto mesi.
L'unico lato positivo: se fa auto-hosting, nulla di questo si applica. La sua istanza, le sue regole, nessuna chiave.
La qualità delle istanze varia, ed è la vera insidia
Il più grande punto di forza di Blockscout crea il suo problema più comune. Poiché chiunque può far girare un'istanza, l'explorer su cui atterra per una data chain potrebbe essere gestito dal team Blockscout, dalla fondazione della chain, da un fornitore di infrastruttura terzo, o da una singola persona che l'ha configurato diciotto mesi fa.
I sintomi di un'istanza trascurata sono riconoscibili: ritardo di indicizzazione di diverse migliaia di blocchi, saldi di token che non si riconciliano, verifica di contratto che fallisce su input valido, o una vecchia release con bug corretti ancora presenti. Nulla di questo riflette sul software; tutto riflette su quella distribuzione.
Due controlli rapidi prima di fidarsi di un'istanza. Confronti la sua ultima altezza di blocco contro l'RPC della chain stessa o un secondo explorer — un divario di più di pochi blocchi significa che è indietro. E cerchi l'indicatore di versione nel piè di pagina; una release vecchia di ben più di un anno è un avvertimento.
| Sintomo | Causa probabile | Cosa fare |
|---|---|---|
| Transazioni recenti mancanti | Indicizzatore in ritardo rispetto alla punta della chain | Controlli l'altezza della punta contro l'RPC della chain; attenda o usi un'altra istanza |
| Il saldo di token sembra sbagliato | Eventi di trasferimento non standard, o una re-indicizzazione incompleta dei token | Faccia un controllo incrociato su un secondo explorer prima di agire |
| La verifica rifiuta una fonte valida | Versione del compilatore non disponibile su quell'istanza | Provi Sourcify, o verifichi su un'istanza gestita diversamente |
| Il contratto appare non verificato altrove | La verifica è per istanza, non globale | Riverifichi su ogni istanza di cui ha bisogno |
Verifica di contratto, e dove è in ritardo
Blockscout verifica i contratti correttamente — Solidity appiattito, input JSON standard, fonte multi-parte, Vyper, e integrazione con Sourcify, il repository di verifica decentralizzato. Meccanicamente è solido.
Il divario è la copertura, ed è un effetto di rete piuttosto che un fallimento tecnico. Quando un progetto si distribuisce sulla mainnet Ethereum verifica su Etherscan, perché è lì che le persone guarderanno. Può o non può anche verificare su Blockscout. Il risultato è che un contratto può apparire verificato su uno e non verificato sull'altro, il che sembra allarmante e di solito non significa nulla.
L'integrazione Sourcify è la contromossa interessante, perché la verifica Sourcify è portabile — verifichi una volta, e qualsiasi explorer che legge Sourcify può mostrare la fonte. Questa è l'architettura giusta, e sta lentamente guadagnando terreno. Sui rollup, dove Blockscout è spesso l'unico explorer, la copertura è naturalmente molto migliore.
Farlo girare lei stesso
Questo è il caso d'uso per cui Blockscout è effettivamente costruito, e si vede. Lo stack è l'indicizzatore, un database PostgreSQL e l'applicazione web Phoenix, con configurazioni Docker Compose pubblicate per le configurazioni comuni.
Lei fornisce un nodo archivio per la chain. Quello è il vero costo e supera di gran lunga tutto il resto — un nodo archivio della mainnet Ethereum è un impegno multi-terabyte. Per un rollup giovane con una storia breve è interamente trattabile, il che è precisamente perché i rollup adottano questo pattern: la chain è piccola, l'explorer è gratuito, ed è in funzione prima che arrivi il primo utente.
Per un individuo, l'auto-hosting di Blockscout per la mainnet Ethereum è un'impresa seria e probabilmente la scelta sbagliata. Otterscan contro un nodo Erigon è molto più leggero se l'obiettivo è ricerche private per sé stesso. La nostra guida all'auto-hosting le confronta su disco, memoria e tempo di configurazione.