L'architettura Voyager di Celestia supera i 21 milioni di TPS in un benchmark su 100 milioni di account
Punti chiave
- •L'architettura Voyager di Celestia avrebbe sostenuto oltre 21 milioni di trasferimenti tra account al secondo durante test che coinvolgevano 100 milioni di account.
- •Voyager si discosta dall'esecuzione parallela eseguendo la sua funzione di transizione di stato centrale su un singolo thread, con l'obiettivo di mantenere prevedibile l'accesso alla memoria e aumentare l'efficienza del processore.
- •Il sistema coordina i suoi componenti tramite un ring buffer condiviso derivato dalla libreria di messaggistica LMAX Disruptor, riducendo i colli di bottiglia legati alla sincronizzazione.
- •L'elaborazione delle transazioni è organizzata in fasi pipeline indipendenti, tra cui journaling, esecuzione, scrittura su database e pubblicazione della data availability, con un batching che può combinare fino a 128 slot del ring buffer.
- •Celestia ha presentato il benchmark come prova della scalabilità applicativa dedicata, pur notando che l'adozione pratica dipende da fattori come requisiti hardware, sicurezza, decentralizzazione e carichi di lavoro reali.

Celestia, il progetto alla rete di data availability modulare dello stesso nome, ha annunciato che la sua architettura blockchain Voyager ha dimostrato la capacità di sostenere più di 21 milioni di trasferimenti tra account al secondo (TPS) durante test di prestazioni che coinvolgevano 100 milioni di account. Il benchmark è stato raggiunto utilizzando transazioni di pagamento generate casualmente, un risultato che secondo il progetto evidenzia il potenziale delle architetture blockchain applicative dedicate a supportare operazioni finanziarie di alto volume.
Il traguardo riflette un approccio architetturale incentrato sulla riduzione dell'overhead di coordinamento, sul miglioramento dell'efficienza del processore e sull'ottimizzazione dell'elaborazione delle transazioni tra i diversi componenti di sistema. Invece di affidarsi ai convenzionali metodi di esecuzione parallela, Voyager impiega una pipeline di elaborazione coordinata progettata per minimizzare le dipendenze tra i singoli componenti, presentando un potenziale percorso per scalare l'infrastruttura blockchain per applicazioni di pagamento ad alta frequenza.
L'architettura a ring buffer riduce il coordinamento di sistema
Le prestazioni di Voyager si basano su una filosofia di design che separa i componenti di sistema e minimizza le dipendenze dirette tra essi. Invece di consentire ai componenti di comunicare tramite meccanismi di sincronizzazione condivisi o mutex lock, l'architettura utilizza un ring buffer comune derivato dal modello LMAX Disruptor. L'LMAX Disruptor è una libreria open source di messaggistica inter-thread sviluppata originariamente per LMAX Exchange, una piattaforma di trading finanziario, per sostenere un elevato throughput transazionale con bassa latenza.
Il ring buffer funge da meccanismo di coordinamento attraverso il quale i diversi componenti di elaborazione scambiano i dati delle transazioni. Questa disposizione riduce la necessità di sincronizzazioni frequenti tra i thread e contribuisce a limitare i colli di bottiglia prestazionali legati al coordinamento.
L'architettura segue inoltre un modello di prestazioni in cui il throughput complessivo del sistema dipende dal componente di elaborazione più lento. Minimizzando le interazioni non necessarie tra i componenti, Voyager punta a migliorare l'efficienza operativa e a rendere i colli di bottiglia più facili da identificare.
I suoi principali elementi architetturali includono il ring buffer condiviso, una funzione di transizione di stato single-thread, operazioni disco e di rete batch, e meccanismi di backpressure progettati per controllare il consumo di memoria.
L'elaborazione single-thread migliora l'efficienza della CPU
Una delle decisioni di design più rilevanti di Voyager è l'uso di una funzione di transizione di stato (STF) single-thread, che si discosta dalle architetture blockchain che dipendono in modo pesante dall'esecuzione parallela delle transazioni. La STF esegue le operazioni essenziali per l'aggiornamento dello stato della blockchain, tra cui la verifica dei saldi degli account, l'applicazione dei trasferimenti e la generazione delle modifiche di stato risultanti.
Invece di distribuire queste operazioni su più thread di esecuzione, Voyager le esegue su un singolo thread di elaborazione per mantenere pattern di accesso alla memoria prevedibili. L'approccio è volto a evitare il degrado delle prestazioni che si verifica quando più thread competono per risorse di memoria condivise.
Il sistema sfrutta inoltre l'esecuzione fuori ordine a livello di processore e il caching dei dati per migliorare l'efficienza computazionale. Queste tecniche consentono al processore di eseguire le istruzioni in modo più efficace, riducendo i ritardi associati al recupero di informazioni richieste di frequente.
Limitando la competizione tra i thread di elaborazione, Voyager punta a mantenere prestazioni di esecuzione costanti anche quando gestisce volumi di transazioni estremamente elevati.
Elaborazione pipeline e operazioni batch
Voyager organizza l'elaborazione delle transazioni in più fasi, tra cui journaling, esecuzione, scrittura su database e pubblicazione della data availability. Ogni fase opera in modo indipendente comunicando con gli altri componenti tramite il ring buffer condiviso, consentendo a diversi batch di transazioni di attraversare fasi separate simultaneamente invece di richiedere che l'intero sistema completi un'operazione prima di iniziarne un'altra.
L'architettura incorpora il batching su due livelli: i singoli slot del ring buffer possono contenere più transazioni, mentre i componenti di elaborazione a valle possono combinare fino a 128 slot prima di sottoporre le proprie operazioni.
Celestia ha spiegato la rationale del design in un post su X del 12 novembre 2026:
Most chains have attempted to scale by parallelizing execution. Voyager takes the opposite approach with the core state transition function running on a single core. This works because the execution isn't the bottleneck, memory access is.
— Celestia (@celestia), 12 novembre 2026 (https://x.com/celestia/status/2120928085277331607?ref_src=twsrc%5Etfw)
Questo approccio riduce la frequenza delle attività ad alta intensità di risorse, tra cui la sincronizzazione del journal e gli invii al database. L'elaborazione di batch più grandi può abbassare l'overhead operativo e migliorare il throughput complessivo.
Voyager incorpora inoltre meccanismi di backpressure per prevenire un consumo eccessivo di memoria. Quando i componenti a valle subiscono ritardi, l'elaborazione a monte viene rallentata per mantenere un carico di lavoro gestibile ed evitare che le risorse di sistema vengano sopraffatte.
Implicazioni per la scalabilità della blockchain
Il benchmark riportato evidenzia il potenziale delle architetture blockchain specializzate, progettate attorno a carichi di lavoro specifici anziché a requisiti di esecuzione general-purpose. I sistemi di pagamento ad alta frequenza richiedono un'infrastruttura capace di elaborare grandi volumi di transazioni mantenendo prestazioni prevedibili e aggiornamenti di stato affidabili.
La fase conclusiva della pipeline, la pubblicazione della data availability, si collega inoltre al ruolo più ampio di Celestia come rete di data availability modulare, in cui mantenere i dati delle transazioni recuperabili per la verifica è una preoccupazione centrale del design.
Le architetture blockchain convenzionali possono incontrare limitazioni quando l'esecuzione delle transazioni, le operazioni di archiviazione e la comunicazione di rete competono per le risorse di sistema. Voyager prova ad affrontare queste sfide attraverso la separazione dei componenti, il batching coordinato e un'elaborazione dello stato ottimizzata.
Combinando un ring buffer condiviso, un'esecuzione dello stato single-thread e pipeline di elaborazione indipendenti, l'architettura Voyager di Celestia punta a ridurre i colli di bottiglia computazionali supportando al contempo un throughput transazionale eccezionalmente elevato.
Il risultato di 21 milioni di TPS riportato rappresenta un traguardo prestazionale significativo per il progetto. Tuttavia, l'adozione pratica dipenderà anche da fattori come le condizioni di rete, i requisiti hardware, la sicurezza, la decentralizzazione e le prestazioni sotto carichi di lavoro transazionali reali.
Lo sviluppo si aggiunge agli sforzi in corso nel settore per migliorare la scalabilità della blockchain, in particolare per le applicazioni di pagamento che richiedono una capacità transazionale estremamente elevata.