Skip to main content
La catena conferma blocchi. Le applicazioni pongono domande come quali sono state le esecuzioni di questo conto la settimana scorsa o com’è fatto il book in questo momento: domande a cui un archivio a forma di blocchi risponde male. L’indexer è ciò che converte l’uno nell’altro. Sulla maggior parte delle catene l’indexer è un’infrastruttura critica: la catena emette eventi opachi e sono terze parti a ricostruirne il significato, quindi ciò che la tua applicazione crede dipende dall’indexer di cui si fida. Qui il passo di ricostruzione non esiste. Il kernel emette output tipizzato e attribuito — ogni cambiamento di stato è già legato alla transazione che lo ha causato — quindi l’indexer rimodella i dati invece di inferirli. Questo cambia a che cosa serve l’indexer. È un livello di servizio dei dati, non una fonte di verità. Tutto ciò che riporta può essere verificato contro la catena, e una discordanza è un bug dell’indexer, non una questione aperta.

​
Il percorso

diviso per età
Full nodeblocchi confermati come record tipizzati
Cacherecenti — in memoria
File storestorici — durevoli
Servizio datientrambi come un unico stream
Gateway → REST · WebSocketaccesso, quote, routing
Perché la separazioneSeguire la testa è leggero e sensibile alla latenza; le interrogazioni storiche sono pesanti e legate al throughput. Un backfill sullo stesso percorso fermerebbe il live.
Livello di servizio, non fonte di veritàIl kernel emette output tipizzato e attribuito, così l’indexer rimodella invece di inferire. Una discordanza con la catena è un bug dell’indexer.
Il full node è l’origine. I record di trading escono da lì in streaming come dati tipizzati, non come transazioni grezze da interpretare. Cache e file store dividono lo stream per età. I dati recenti vengono serviti dalla memoria, perché è quello che vuole la maggior parte dei consumatori e la latenza conta. I dati storici vengono scritti su archiviazione durevole su file, perché tenere tutto in memoria non è una strategia. Un consumatore che chiede qualcosa di vecchio e uno che segue la testa della catena vengono serviti da posti diversi senza che nessuno dei due se ne accorga. Il servizio dati presenta entrambi come un unico stream. Un client chiede un intervallo che parte da dove vuole; se quell’intervallo venga servito dalla cache, dai file o da entrambi non è un problema del client. Il gateway gestisce ciò che sta tra un servizio e la rete pubblica: accesso, quote e instradamento. Le interfacce REST e WebSocket sono ciò che le applicazioni usano davvero: dati di mercato, storico di ordini ed esecuzioni, posizioni, stato del conto, pagamenti di funding e sottoscrizioni in tempo reale. Vedi il riferimento API per il dettaglio a livello di endpoint.

​
Perché esiste la separazione

Un unico servizio che seguisse la testa della catena e insieme rispondesse alle interrogazioni storiche non farebbe bene né l’una né l’altra cosa. Seguire la testa è sensibile alla latenza e leggero; le interrogazioni storiche sono sensibili al throughput e pesanti, e un solo backfill di grandi dimensioni manderebbe in stallo il percorso live. Separarli significa che ricostruire lo storico di un nuovo consumatore a partire da mesi fa non degrada il feed di un market maker che segue la testa, e i due possono essere scalati in modo indipendente — cosa di cui hanno bisogno, perché i loro profili di carico non hanno nulla in comune.

​
Su che cosa ci si può appoggiare

Sicuro. Tutto ciò che l’indexer serve derivandolo da blocchi confermati: esecuzioni, ordini, posizioni, pagamenti di funding, trasferimenti, dati di mercato. Sono rimodellati a partire dall’output della catena. Non è la stessa cosa. Tutto ciò che non è ancora confermato. Un ordine accettato nel mempool non è stato ordinato, e l’indexer non ha nulla da dire al riguardo. L’assenza dall’indexer significa non ancora confermato, non rifiutato. Verificabile. Se una risposta conta abbastanza — una contestazione sul regolamento, un audit, una riconciliazione contabile — può essere verificata direttamente contro la catena invece di essere presa dall’indexer. Gestire un full node proprio è la forma più forte di questa verifica, ed è ciò che dovrebbe fare un partecipante che non può permettersi di sbagliare. Vedi Gestire un nodo.
Due consumatori che leggono lo stesso intervallo confermato devono ottenere la stessa risposta. Se così non è, la discrepanza sta nel percorso di erogazione ed è un bug da segnalare, non una proprietà intrinseca della lettura di una catena tramite un indexer.

​
Dove proseguire

Modello di stato

Che cosa legge l’indexer e quale rappresentazione fa fede.

Sviluppatori

Interfacce REST e WebSocket, SDK e strumenti.

Gestire un nodo

Verificare da solo contro la catena, e perché il set è chiuso.

Servizi di programma

Che cosa consuma questo stream per calcolare lo stato derivato dei conti.