Per gran parte della sua storia, Solana ha funzionato su una sola implementazione di validatore. Questo l'ha resa veloce ma fragile, poiché un singolo bug software poteva bloccare l'intera chain.

Firedancer risolve questo problema. Fornisce a Solana un secondo client completamente indipendente con codice separato, un linguaggio diverso e un proprio team, ovvero il modello di sicurezza multi-client che Ethereum considera uno standard di base.

Ecco come è strutturato Firedancer, a che punto si trova dopo il lancio e cosa significa per l'affidabilità e la roadmap di Solana. 👇

Cos'è Firedancer?

Firedancer è un client validatore per Solana realizzato da Jump Crypto, la divisione blockchain della società di trading Jump Trading Group. Un client validatore è il software che elabora le transazioni, produce blocchi e vota nel consenso, quindi il client eseguito da un nodo determina le performance della rete.

Jump ha avviato il progetto nel 2022 prendendo una decisione consapevole. Invece di fare il fork del software basato su Rust di Solana, ha riscritto il validatore da zero in C e C++, linguaggi che offrono un controllo minuzioso su memoria e hardware. Il nuovo client non condivide alcun codice con quello preesistente, ed è proprio questo il punto.

Il client predefinito di Solana è Agave, gestito da Anza, un team nato da una costola di Solana Labs. La variante più utilizzata è il fork ottimizzato per il MEV di Jito di Agave. Firedancer si distingue da entrambi come una build autenticamente separata, insieme a client più piccoli come Sig, Mithril e Tinydancer.

Nonostante la frequente confusione, Firedancer non è un token, un airdrop o una modifica di protocollo. Non influisce sull'emissione di SOL, sulle staking rewards o sulle regole delle transazioni. Modifica il modo in cui i validator eseguono le operazioni, senza alterare le funzioni della rete.

Come funziona Firedancer?

Firedancer tratta il validator come un insieme di componenti specializzati e isolati anziché come un unico grande programma, rimuovendo poi i costi generali del sistema operativo che limitano il throughput su larga scala.

1. Architettura basata su tile

Firedancer suddivide il lavoro del validator in processi indipendenti chiamati tile, ciascuno dei quali gestisce un compito specifico come la gestione della rete, il controllo delle firme, l'impacchettamento delle transazioni o la produzione dei blocchi. Ogni tile è associato al proprio core della CPU e comunica con gli altri tramite canali di memoria condivisa.

Agave viene eseguito come un unico processo monolitico in cui networking, esecuzione e consenso condividono la memoria. La suddivisione di Firedancer sfrutta hardware multi-core tramite parallelismo e contiene i guasti, poiché un errore in un tile difficilmente compromette l'intero validator. L'allocazione della memoria compatibile con NUMA e le strutture dati senza blocchi (lock-free) impediscono ai core di contendersi le stesse risorse.

2. Networking con bypass del kernel

Ogni pacchetto gestito da un validator standard effettua un percorso di andata e ritorno attraverso lo stack di rete del kernel Linux, il quale si blocca sotto carichi pesanti. Firedancer aggira la maggior parte di quel percorso con AF_XDP ed eBPF, leggendo i pacchetti in prossimità della scheda di rete in modo che il limite massimo sia rappresentato dall'hardware e non dal software sottostante.

Al di sopra si trova una build QUIC personalizzata denominata fd_quic e il receive-side scaling che distribuisce il traffico tra i core. Come indicato nella documentazione di Firedancer, i tile di networking non vanno mai in pausa e utilizzano il busy-polling per mantenere stabile la latenza. Il compromesso è che ciò richiede l'accesso come root durante la configurazione e hardware di rete specifico.

3. Verifica accelerata delle firme

La verifica delle firme Ed25519 è una delle operazioni più onerose per un validator su larga scala. Firedancer utilizza le istruzioni vettoriali AVX-512 per controllare le firme in batch paralleli anziché una alla volta. Gli ingegneri di Jump hanno registrato per la loro routine una velocità pari a circa 3,9 volte quella della versione scalare standard sullo stesso chip.

4. Propagazione dei blocchi

Firedancer ottimizza anche Turbine, il meccanismo di propagazione dei blocchi di Solana, e la relativa erasure coding affinché i dati si diffondano in modo efficiente sotto carico. Insieme ai miglioramenti nella rete e nella crittografia, è così che il client spinge il throughput ben oltre i livelli registrati dal software originale.

Frankendancer vs Firedancer

I due nomi vengono continuamente confusi, perciò comprendere la differenza è fondamentale. Frankendancer è un sistema ibrido: integra il codice di networking e di produzione dei blocchi di Firedancer nel runtime Rust e nel consenso di Agave, consentendo ai validator di adottare parte dell'architettura senza dover affidarsi a codice di consenso non testato.

Frankendancer ha raggiunto la mainnet nel 2024 e ha ottenuto una reale diffusione nel corso del 2025. Poiché si affida ad Agave per l'esecuzione e il consenso, le sue prestazioni sono limitate da quel runtime e non risolve completamente il problema del singolo client, dato che ogni nodo dipende ancora dal consenso di Agave.

Il Firedancer completo rimuove questa dipendenza. Implementa l'intera pipeline del validator, inclusi consenso ed esecuzione, in una codebase indipendente in C e C++. Questa versione è ciò che offre a Solana un vero secondo client e un dominio di errore separato da Agave.

Il lancio della mainnet e l'adozione

Jump Crypto ha annunciato il lancio completo della mainnet di Firedancer il 12 dicembre 2025 in occasione di Solana Breakpoint ad Abu Dhabi. A quel punto il client era già attivo in produzione su un piccolo gruppo di validator da circa 100 giorni, producendo in modo impeccabile oltre 50.000 blocchi. Il team ha condotto preliminarmente un audit di sicurezza pubblico supportato da una bug bounty da 1 milione di dollari.

Il rilascio è stato condotto in modo deliberatamente graduale anziché con un passaggio netto. Il fondatore e ingegnere Ritchie Patel ha dichiarato a CoinDesk a maggio 2026 che il client aveva elaborato decine di milioni di transazioni mentre l'adozione si espandeva con cautela.

Nella prima metà del 2026, la famiglia Firedancer veniva eseguita su circa il 20 percento o più dei validator attivi, mentre il client completo deteneva una quota a due cifre basse del SOL staked. Il fork Agave di Jito detiene ancora la maggioranza, di conseguenza una rete multi-client bilanciata richiederà ancora diversi anni. Il valore di SOL è aumentato di circa il 6 percento dopo il lancio e il set di validator si è attestato intorno agli 840 nodi, in calo rispetto al picco di oltre 1.300.

Perché la diversità dei client è importante

La cronologia delle interruzioni di Solana spiega l'attenzione su questo tema. L'analisi dei periodi di inattività della rete condotta da Helius attribuisce cinque delle sette principali interruzioni a bug del validator o del client piuttosto che alla progettazione del consenso. Quando circa il 90 percento dello stake è gestito da un unico software, un singolo errore di codifica può bloccare la produzione dei blocchi indipendentemente dalla velocità percepita della blockchain.

Ethereum lo ha imparato in anticipo e considera la diversità dei client una regola di sicurezza fondamentale, ponendosi l'obiettivo di mantenere qualsiasi singolo client al di sotto di un terzo della potenza di consenso. Un client che supera tale soglia può bloccare la finalizzazione; se supera i due terzi, potrebbe finalizzare blocchi non validi. Solana è partita con un livello di concentrazione molto più elevato, prossimo al 90 percento su un unico client.

Firedancer cambia la situazione. Poiché non condivide alcun codice o linguaggio con Agave, un bug di memoria nell'allocatore Rust di Agave non dovrebbe estendersi alla codebase C++ di Firedancer e i due sistemi possono fallire in modo indipendente. La rete è in grado di sopravvivere a un bug catastrofico in uno dei due client, a condizione che lo stake sia distribuito in modo tale che nessun singolo client possa disattivare una supermaggioranza contemporaneamente.

Questa è anche la proposta commerciale per le istituzioni. I team di gestione del rischio vogliono sapere cosa succede quando qualcosa si rompe, e due client indipendenti appaiono molto diversi ai loro occhi. Con JPMorgan che sta organizzando un' emissione di carta commerciale su Solana e State Street che prepara un fondo di liquidità tokenizzato per la rete, eliminare il rischio legato a un singolo client risponde a una delle principali obiezioni alla creazione di finanza regolamentata su di essa.

Firedancer, Alpenglow e la roadmap di Solana

Firedancer rappresenta la metà di un aggiornamento più ampio, e spesso viene confuso con l'altra metà. Alpenglow è un nuovo motore di consenso di Anza che sostituisce Proof of History e TowerBFT, puntando a una finalità vicina ai 150 millisecondi. Firedancer è un client; Alpenglow è un protocollo di consenso. I validatori lo hanno approvato ed è in fase di test in vista di un'attivazione sulla mainnet prevista per la fine del 2026.

Anche i limiti di calcolo sono importanti. Solana ha aumentato la capacità di calcolo per blocco tramite proposte come la SIMD-0256, che ha portato il limite massimo oltre i 60 milioni di Unit, e ulteriori incrementi sono attualmente oggetto di dibattito. Limiti più elevati mettono a dura prova l'hardware dei validatori, esattamente la pressione che l'architettura di Firedancer è stata progettata per assorbire.

Entrambi i team si stanno inoltre preparando per la sicurezza post-quantum. Nell'aprile 2026, Anza e il team di Firedancer hanno scelto separatamente Falcon, uno schema di firma selezionato dal NIST le cui firme compatte si adattano a una rete ad alta velocità di trasmissione senza compromettere le performance.

Requisiti hardware di Firedancer

I primi articoli sostenevano che Firedancer avrebbe reso la validazione più economica. È accaduto esattamente il contrario. Premia macchine con un alto numero di core e componenti di rete specifici, e i crescenti limiti di calcolo di Solana hanno alzato l'asticella, non l'hanno abbassata.

Le guide per gli operatori per il 2026 convergono su un profilo di produzione simile:

• CPU: Un chip a 12 core e 24 thread a 2,8 GHz è il minimo sindacale, ma i validatori di produzione puntano a 24 o più core a 3,5 GHz e oltre. I componenti AMD EPYC come il 9354 e il 9355 dominano nelle configurazioni a singolo socket per evitare la latenza tra i socket.
• AVX-512: Obbligatorio per la crittografia accelerata. Senza di esso, i vantaggi nella verifica delle firme svaniscono.
• RAM: Circa da 384 GB a 512 GB di memoria ECC, ben al di sopra delle indicazioni precedenti, per blocchi più grandi e stato degli account.
• Storage: Unità NVMe Gen4 o Gen5 di livello enterprise, con il sistema operativo su un disco separato rispetto ai dati del ledger.
• Rete: Un collegamento simmetrico da 10 Gbps e una scheda di rete compatibile con XDP, di cui il design con bypass del kernel necessita per funzionare correttamente.
• Ottimizzazione: Disattiva l'hyperthreading, isola i core dallo scheduler del kernel e imposta l'affinità della CPU in modo che ogni tile gestisca il proprio core. Considera tutto ciò come un requisito fondamentale.

Firedancer è un'infrastruttura di livello professionale progettata per hardware performante. Non rende l'esecuzione di un nodo più leggera o economica.

Perché Jump sta costruendo Firedancer?

Le motivazioni di Jump derivano dalla sua attività principale. Jump Trading Group ha trascorso due decenni a sviluppare sistemi a bassa latenza in grado di spostare enormi volumi di dati con un ritardo minimo, e Firedancer applica questa cultura a un validatore. Patel ha descritto il client come un vero e proprio motore di trading, e il capo scienziato Kevin Bowers ha guidato le prime demo sulle performance.

L'obiettivo dichiarato è l'affidabilità e le prestazioni per Solana, una rete in cui Jump ha investito pesantemente. Anche il denaro fa la sua parte. I validatori guadagnano dal maximal extractable value, il profitto derivante dall'ordinamento delle transazioni all'interno dei blocchi, e il mercato del MEV di Solana è ormai un business concreto. Firedancer non modifica direttamente la tokenonomics del MEV, poiché questa risiede principalmente in varianti come quella di Jito, ma un client più veloce e stabile rafforza l'infrastruttura su cui fanno affidamento gli operatori orientati al MEV.

Rischi e questioni aperte

Firedancer è un notevole risultato ingegneristico e l'arrivo sulla mainnet solleva tanti interrogativi quanti ne risolve. Tieni a mente questi aspetti.

• Benchmark vs Throughput effettivo: La cifra di oltre 1 milione di TPS deriva da demo controllate. Il vero throughput della mainnet è nettamente inferiore, nell'ordine delle migliaia, e i benchmark dicono poco sul comportamento sotto carico avverso o in caso di partizioni della rete.
• Migrazione lenta: Passare a nuovi client richiede un impegno reale nell'ottimizzazione dell'hardware e nelle operazioni, e Agave vanta anni di storia sulla mainnet che Firedancer non può ancora eguagliare. Gli operatori più prudenti aspetteranno, quindi lo stake si sposterà gradualmente.
• Rischio residuo legato a un singolo client: Finché una quantità sufficiente di stake non si sposterà verso client indipendenti, un bug nel software dominante basato su Agave potrebbe comunque bloccare la chain. La diversificazione è utile solo quando la distribuzione è realmente bilanciata.
• Nuova codebase: Una riscrittura da zero in C e C++ comporta rischi intrinseci legati alla memoria e alla concorrenza, motivo per cui il lancio è stato preceduto da lunghi audit e programmi di bug bounty. Una cronologia di produzione limitata lascia spazio a imprevisti.
• Pressione alla centralizzazione: Il profilo hardware esigente favorisce gli operatori professionisti e i grandi data center, e le regole di concentrazione dello stake all'interno del programma di delega della Solana Foundation potrebbero indirizzare la validazione verso un numero inferiore di attori, dotati di maggiori finanziamenti.
• Nessun investimento diretto: Non esiste un token Firedancer, quindi l'esposizione avviene tramite SOL, con la consueta volatilità crypto a prescindere da qualsiasi singolo aggiornamento.

Considerazioni finali

Firedancer cambia il senso del dibattito su Solana. La rete ha sempre puntato sulla velocità, e la velocità era reale, ma poggiava su un unico punto di vulnerabilità software che ha causato blackout ripetuti e imbarazzanti. Un secondo client indipendente rappresenta la soluzione strutturale, ed è arrivato in versione di produzione a dicembre 2025.

Il numero di 1 milione di TPS continuerà ad attirare l'attenzione dei media, ma è l'aspetto meno interessante. Il vero cambiamento è che ora Solana dispone di una via credibile verso la resilienza multi-client, quella che permette alle istituzioni di considerarla un'infrastruttura di produzione piuttosto che un esperimento veloce ma fragile.

L'esecuzione su larga scala è il vero punto interrogativo. Il stake deve migrare, il nuovo codice deve sopravvivere ad anni di condizioni avverse e le richieste hardware non devono centralizzare silenziosamente il set di validatori. Firedancer fornisce a Solana l'architettura di cui aveva bisogno; la misura in cui la rete trarrà pieno vantaggio dipenderà dall'implementazione.