Per gran parte della sua storia, Solana con un'unica implementazione di validatore. Ciò la rendeva veloce ma vulnerabile, poiché un singolo bug nel software poteva bloccare l'intera catena.

Firedancer il problema. Offre Solana secondo client completamente indipendente, con un codice separato, un linguaggio diverso e un proprio team: il modello di sicurezza multi-client Ethereum come punto di riferimento.

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

Cos'è Firedancer?

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

Jump ha avviato il progetto nel 2022 e ha preso una decisione ponderata. Anziché creare un fork Solana software Solana basato su Rust, ha riscritto il validatore da zero in C e C++, linguaggi che consentono un controllo preciso sulla memoria e sull'hardware. Il nuovo client non condivide alcun codice con quello esistente, ed è proprio questo il punto.

Il client predefinito Solana è Agave, gestito da Anza, un team nato da Solana . La variante più utilizzata è il fork di Agave MEVJito. Firedancer da entrambi in quanto build completamente autonoma, insieme a client più piccoli come Sig, Mithril e Tinydancer.

Nonostante la frequente confusione, Firedancer non Firedancer un token, airdrop né una modifica al protocollo. Non influisce SOL , staking né sulle regole delle transazioni. Modifica il modo in cui operano i validatori, senza alterare il funzionamento della rete.

Come funziona Firedancer ?

Firedancer il validatore come un insieme di componenti specializzati e isolati anziché come un unico grande programma, eliminando così il sovraccarico del sistema operativo che limita la produttività su larga scala.

1. Architettura basata su tessere

Firedancer il lavoro dei validatori in processi indipendenti denominati "tile", ciascuno dei quali gestisce un'attività specifica, come la gestione della rete, la verifica delle firme, il raggruppamento delle transazioni o la creazione dei blocchi. Ogni tile è associato a un proprio core della CPU e comunica con gli altri tramite canali di memoria condivisa.

Agave funziona come un unico processo monolitico in cui rete, esecuzione e consenso condividono la memoria. L'architettura a partizioni Firedancer sfrutta l'hardware multi-core attraverso il parallelismo e limita gli effetti dei guasti, poiché un errore in un singolo blocco raramente causa il malfunzionamento dell'intero validatore. Il posizionamento della memoria ottimizzato per NUMA e le strutture dati lock-free impediscono ai core di contendere le stesse risorse.

2. Reti con bypass del kernel

Ogni pacchetto gestito da un validatore standard compie un percorso di andata e ritorno attraverso lo stack di rete del kernel Linux, che va in tilt sotto carico elevato. Firedancer gran parte di quel percorso grazie ad AF_XDP ed eBPF, leggendo i pacchetti a livello della scheda di rete, così che il limite massimo è dato dall'hardware e non dal software a monte.

A livello superiore si trova un'implementazione personalizzata di QUIC denominata fd_quic, insieme a un sistema di scalabilità lato ricezione che distribuisce il traffico tra i vari core. Secondo la Firedancer , i moduli di rete non entrano mai in stato di sospensione, ma effettuano un polling continuo per mantenere costante la latenza. Il rovescio della medaglia è che ciò richiede l'accesso come root durante la configurazione e hardware di rete specifico.

3. Verifica accelerata della firma

La verifica delle firme Ed25519 è una delle operazioni più dispendiose in termini di risorse per un validatore su larga scala. Firedancer le istruzioni vettoriali AVX-512 per verificare le firme in batch paralleli anziché una alla volta. Gli ingegneri di Jump hanno misurato che la loro routine è circa 3,9 volte più veloce della versione scalare standard sullo stesso chip.

4. Propagazione dei blocchi

Firedancer ottimizza Firedancer Turbine, il meccanismo di propagazione dei blocchi Solana, e la sua codifica a cancellazione, in modo che i dati vengano distribuiti in modo efficiente anche sotto carico. Grazie a questi miglioramenti a livello di rete e crittografia, il client raggiunge una velocità di trasmissione ben superiore a quella offerta dal software originale.

Frankendancer contro Firedancer

I due nomi vengono spesso confusi, quindi è importante capire la differenza. Frankendancer è un ibrido: integra il codice di rete e di produzione dei blocchi Firedancer nel runtime Rust e nel meccanismo di consenso di Agave, consentendo ai validatori di adottare parte dell'architettura senza dover fare affidamento su un codice di consenso non testato.

Frankendancer è approdato mainnet 2024 e ha iniziato a riscuotere un vero successo nel corso del 2025. Poiché si affida ad Agave per l'esecuzione e il consenso, le sue prestazioni sono limitate da tale runtime e non risolve completamente il problema del "single-client", dato che ogni nodo dipende ancora dal consenso di Agave.

Full Firedancer tale dipendenza. Implementa l'intera pipeline di validazione, compresi il consenso e l'esecuzione, in un codice indipendente scritto in C e C++. È proprio questa versione a fornire Solana vero e proprio secondo client e un dominio di errore separato da Agave.

Mainnet della Mainnet e la sua diffusione

Jump Crypto ha annunciato ilmainnet completomainnet Firedancer il 12 dicembre 2025 in occasione Solana ad Abu Dhabi. A quel punto, il client era già in funzione da circa 100 giorni in produzione su un piccolo gruppo di validatori, avendo generato senza intoppi oltre 50.000 blocchi. Il team ha prima condotto un audit di sicurezza pubblico, supportato da un programma di bug bounty da 1 milione di dollari.

L'implementazione è stata volutamente graduale, anziché avvenire con un passaggio netto. L'ingegnere fondatore Ritchie Patel ha dichiarato a CoinDesk nel maggio 2026 che il client aveva gestito decine di milioni di transazioni mentre l'adozione si espandeva con cautela.

Nella prima metà del 2026, la Firedancer era in esecuzione su circa il 20% o più dei validatori attivi, mentre il client completo deteneva una quota a due cifre nella fascia bassa dello staking SOL. Il fork Agave Jito detiene ancora la maggioranza, quindi ci vorranno ancora anni prima di arrivare a una rete multi-client equilibrata. SOL circa il 6% dopo il lancio e il set di validatori sat 840 nodi, in calo rispetto al picco di oltre 1.300.

Perché la diversità della clientela è importante

Il record di interruzioni Solana spiega l'attenzione suscitata. L'analisi Helius sui tempi di inattività della rete attribuisce cinque dei sette principali blocchi del sistema a bug dei validatori o dei client, piuttosto che alla struttura del consenso. Quando circa il 90% dello stake utilizza un unico software, un singolo errore di programmazione può bloccare la produzione di blocchi, indipendentemente dalla velocità apparente della catena.

Ethereum lo Ethereum fin dall'inizio e considera la diversificazione dei client una regola di sicurezza, puntando a mantenere la quota di ogni singolo client al di sotto di un terzo della potenza di consenso. Un client che superi tale soglia può rallentare la finalizzazione; se supera i due terzi, potrebbe finalizzare blocchi non validi. Solana una concentrazione molto maggiore, con quasi il 90% su un unico client.

Firedancer le carte in tavola. Non condividendo né codice né linguaggio con Agave, un bug di memoria nell'allocatore Rust di Agave non dovrebbe interessare il codice C++ Firedancer, e i due sistemi possono andare in errore in modo indipendente. La rete può sopravvivere a un bug catastrofico in entrambi i sistemi, purché lo stake sia distribuito in modo tale che nessun client possa mettere offline una maggioranza qualificata in un colpo solo.

Questo è anche l'argomento chiave a livello istituzionale. I team che si occupano della gestione dei rischi vogliono sapere cosa succede in caso di problemi, e la presenza di due clienti indipendenti viene interpretata in modo molto diverso da loro. Con JPMorgan che sta organizzando un'emissione di commercial paper su Solana State Street che sta preparando un fondo di liquidità tokenizzato per la rete, la riduzione del rischio legato a un unico cliente risponde a una delle principali obiezioni alla creazione di una finanza regolamentata su questa piattaforma.

La roadmap SolanaFiredancer, Alpenglow e Solana

Firedancer una delle due parti di un aggiornamento più ampio, e spesso viene confuso con l'altra parte. Alpenglow è un nuovo motore di consenso sviluppato da Anza che sostituisce Proof of History e TowerBFT e punta a una finalizzazione di circa 150 millisecondi. Firedancer un client; Alpenglow è un protocollo di consenso. I validatori lo hanno approvato ed è attualmente in fase di test in vista mainnet prevista per la fine del 2026.

Anche i limiti di potenza di calcolo sono importanti. Solana aumentato la potenza di calcolo per blocco grazie a proposte come la SIMD-0256, che ha portato il limite massimo oltre i 60 milioni di unità, e si sta discutendo di ulteriori aumenti. Limiti più elevati sottopongono l'hardware dei validatori a un carico maggiore, ed è proprio questa pressione che l'architettura Firedancer è stata progettata per assorbire.

Entrambe le squadre stanno inoltre pianificando la sicurezza post-quantistica. Nell'aprile 2026, Anza e il Firedancer hanno scelto, indipendentemente l'uno dall'altro, Falcon, uno schema di firma selezionato dal NIST le cui firme compatte si adattano a una rete ad alta velocità senza comprometterne le prestazioni.

Requisiti Firedancer

Le prime notizie sostenevano che Firedancer reso la convalida più economica. È successo invece il contrario. Il sistema favorisce le macchine con un numero elevato di core e apparecchiature di rete specifiche, e l'aumento dei limiti di calcolo Solana ha alzato l'asticella, anziché abbassarla.

Le previsioni degli operatori per il 2026 indicano un andamento della produzione simile:

• CPU: un chip a 12 core e 24 thread a 2,8 GHz rappresenta lo standard minimo, ma i sistemi di validazione di produzione puntano a configurazioni con oltre 24 core a 3,5 GHz e oltre. I modelli AMD EPYC come il 9354 e il 9355 sono i più diffusi nelle configurazioni a socket singolo, per evitare la latenza tra socket.
• AVX-512: Indispensabile per la crittografia accelerata. Senza di esso, i vantaggi in termini di verifica delle firme vengono meno.
• RAM: circa 384 GB – 512 GB di memoria ECC, ben al di sopra delle stime precedenti, per gestire blocchi più grandi e lo stato degli account.
• Archiviazione: unità NVMe Gen4 o Gen5 di livello enterprise, con il sistema operativo su un disco separato rispetto ledger .
• Rete: un collegamento simmetrico da 10 Gbps e una scheda di rete compatibile con XDP, elementi indispensabili per il funzionamento del design con bypass del kernel.
• Ottimizzazione: disattivare l'Hyper-Threading, isolare i core dallo scheduler del kernel e impostare l'affinità della CPU in modo che ogni tile disponga di un proprio core. Considerare tutti questi requisiti come imprescindibili.

Firedancer un'infrastruttura di livello professionale progettata per hardware potente. Non rende la gestione di un nodo lighter più economica.

Perché Jump Building si chiama Firedancer?

La motivazione di Jump affonda le sue radici nella sua attività principale. Jump Trading Group ha dedicato vent'anni alla realizzazione di sistemi a bassa latenza in grado di gestire enormi volumi di dati con ritardi minimi, e Firedancer questa filosofia a un validatore. Patel ha descritto il client come un vero e proprio motore di trading, mentre il responsabile scientifico Kevin Bowers ha guidato le prime dimostrazioni di throughput.

L'obiettivo dichiarato è garantire affidabilità e prestazioni per Solana, una rete in cui Jump ha investito molto. Anche il denaro ha la sua parte. I validatori traggono profitto dal valore massimo estraibile (MEV), ovvero il guadagno derivante dall'ordinamento delle transazioni all'interno dei blocchi, e MEV Solana è ormai un vero e proprio business. Firedancer direttamente MEV , poiché questa risiede principalmente in varianti come Jito, ma un client più veloce e stabile rafforza l'infrastruttura su cui fanno affidamento gli operatori MEV.

Rischi e questioni aperte

Firedancer un importante traguardo ingegneristico e mainnet suo mainnet solleva tante domande quante sono le risposte che fornisce. Tenetele bene a mente.

• Prestazioni nei benchmark vs. throughput effettivo: TPS di oltre 1 milione TPS deriva da demo controllate. mainnet effettivo mainnet è molto più basso, dell'ordine delle migliaia, e i benchmark non dicono molto sul comportamento in presenza di carichi ostili o di divisioni della rete.
• Migrazione graduale: il passaggio a un nuovo client richiede un impegno concreto in termini di ottimizzazione hardware e gestione operativa, e Agave vanta anni di mainnet Firedancer ancora Firedancer eguagliare. Gli operatori più prudenti preferiranno attendere, quindi lo spostamento degli stake avverrà gradualmente.
• Il rischio legato alla dipendenza da un unico cliente persiste: finché una quota sufficiente di token non passerà a clienti indipendenti, un bug nel software dominante basato su Agave potrebbe ancora bloccare la catena. La diversificazione è utile solo quando la distribuzione è realmente equilibrata.
• Nuovo codice: una riscrittura completa in C e C++ comporta dei rischi legati alla gestione della memoria e alla concorrenza; per questo motivo il lancio è stato preceduto da una lunga fase di verifica e da un programma di ricompense. L'esiguo numero di casi di produzione lascia spazio a possibili sorprese.
• Pressione verso la centralizzazione: le caratteristiche tecniche complesse favoriscono gli operatori professionali e i grandi data center, mentre le regole sulla concentrazione degli stake previste dal Programma di delega Solana potrebbero far concentrare la convalida in un numero ristretto di attori con maggiori risorse finanziarie.
• Nessun investimento diretto: non esiste Firedancer , pertanto l'esposizione avviene tramite SOL, con la consueta volatilità delle criptovalute, indipendentemente da eventuali aggiornamenti specifici.

Considerazioni Finali

Firedancer i termini del Solana . La rete ha sempre puntato sulla velocità, e la velocità era reale, ma sat un unico punto di errore del software che causava ripetute e imbarazzanti interruzioni del servizio. Un secondo client indipendente rappresenta la soluzione strutturale, ed è stato implementato in versione definitiva nel dicembre 2025.

TPS di 1 milione TPS continuerà a fare notizia, ma in realtà è l'aspetto meno interessante. Il vero cambiamento sta nel fatto che Solana dispone Solana di un percorso credibile verso la resilienza multi-client, quella che consente alle istituzioni di considerarla un'infrastruttura operativa piuttosto che un esperimento veloce ma fragile.

La vera incognita è l'implementazione su larga scala. Lo stake deve essere migrato, il nuovo codice deve resistere per anni a condizioni avverse e i requisiti hardware non devono portare a una ricentralizzazione silenziosa dell'insieme dei validatori. Firedancer Solana aveva bisogno; che la rete riesca a trarne il massimo vantaggio dipenderà dall'implementazione.