Während des größten Teils seiner Geschichte Solana auf einer einzigen Validator-Implementierung. Das machte das System zwar schnell, aber auch anfällig, da ein einziger Softwarefehler die gesamte Blockchain zum Stillstand bringen konnte.

Firedancer hier Firedancer . Es verschafft Solana zweiten, völlig eigenständigen Client mit separatem Code, einer anderen Programmiersprache und einem eigenen Team – ein Multi-Client-Sicherheitsmodell, Ethereum als Standard Ethereum .

Hier erfährst du, wie Firedancer aufgebaut Firedancer , wo es nach dem Start steht und was dies für die Zuverlässigkeit und die Roadmap Solana bedeutet. 👇

Was ist Firedancer?

Firedancer ist ein Validator-Client für Solana von Jump Crypto, dem Blockchain-Zweig des Handelsunternehmens Jump Trading Group, Solana . Ein Validator-Client ist die Software, die Transaktionen verarbeitet, Blöcke erzeugt und im Konsens abstimmt. Daher entscheidet der Client, den ein Knoten ausführt, über die Leistung des Netzwerks.

Jump startete das Projekt im Jahr 2022 und traf eine bewusste Entscheidung. Anstatt die auf Rust basierende Software Solana zu forken, schrieb das Team den Validator von Grund auf in C und C++ neu – Sprachen, die eine präzise Kontrolle über Speicher und Hardware ermöglichen. Der neue Client hat keinerlei Code mit dem bisherigen gemeinsam, und genau darum geht es.

Der Standard-Client Solana ist Agave, der von Anza gepflegt wird, einem aus Solana hervorgegangenen Team. Die am häufigsten verwendete Variante ist Jito MEV Fork von Agave. Firedancer als eigenständiger Build von beiden ab, ebenso wie kleinere Clients wie Sig, Mithril und Tinydancer.

Auch wenn dies oft verwechselt wird: Firedancer weder ein Token noch airdrop noch eine Protokolländerung. Es hat keinerlei Auswirkungen auf SOL , staking oder die Transaktionsregeln. Es verändert lediglich die Funktionsweise der Validatoren, ohne die grundlegende Funktionsweise des Netzwerks zu verändern.

Wie funktioniert Firedancer ?

Firedancer den Validator als eine Reihe spezialisierter, isolierter Komponenten statt als ein einziges großes Programm und beseitigt so den Overhead des Betriebssystems, der den Durchsatz bei Skalierung begrenzt.

1. Kachelbasierte Architektur

Firedancer die Validator-Aufgaben in unabhängige Prozesse, sogenannte „Tiles“, von denen jeder eine bestimmte Aufgabe übernimmt, wie beispielsweise Netzwerkkommunikation, Signaturprüfungen, Transaktionsbündelung oder Blockerstellung. Jede „Tile“ ist an einen eigenen CPU-Kern gebunden und kommuniziert mit den anderen über Shared-Memory-Kanäle.

Agave läuft als ein einziger monolithischer Prozess, in dem Netzwerkfunktionen, Ausführung und Konsensbildung denselben Speicher nutzen. Die Aufteilung Firedancer nutzt die Vorteile von Multi-Core-Hardware durch Parallelität und begrenzt Ausfälle, da ein Fehler in einem Tile selten den gesamten Validator lahmlegt. NUMA-bewusste Speicherplatzierung und sperrfreie Datenstrukturen verhindern, dass sich die Kerne um dieselben Ressourcen streiten.

2. Netzwerkkommunikation ohne Kernel-Einbindung

Jedes Paket, das ein Standard-Validator verarbeitet, durchläuft den Netzwerkstack des Linux-Kernels, der unter hoher Last zusammenbricht. Firedancer den größten Teil dieses Weges mithilfe von AF_XDP und eBPF und liest die Pakete direkt an der Netzwerkkarte aus, sodass die Hardware die Obergrenze darstellt und nicht die davor liegende Software.

Darüber hinaus gibt es eine maßgeschneiderte QUIC-Implementierung namens „fd_quic“ sowie eine Skalierung auf der Empfängerseite, die den Datenverkehr auf die Kerne verteilt. Laut der Firedancer gehen die Netzwerk-Tiles nie in den Ruhezustand, sondern führen ständig Abfragen durch, um die Latenz konstant zu halten. Der Nachteil ist, dass hierfür während der Einrichtung Root-Zugriff sowie spezielle Netzwerkhardware erforderlich sind.

3. Beschleunigte Signaturprüfung

Die Überprüfung von Ed25519-Signaturen ist bei großen Datenmengen eine der rechenintensivsten Aufgaben eines Validators. Firedancer AVX-512-Vektorbefehle, um Signaturen nicht einzeln, sondern parallel in Stapeln zu prüfen. Die Ingenieure von Jump haben gemessen, dass ihre Routine auf demselben Chip etwa 3,9-mal so schnell ist wie die standardmäßige skalare Version.

4. Blockausbreitung

Firedancer optimiert Firedancer „Turbine“, Solana Mechanismus zur Blockweitergabe, sowie dessen Erasure-Codierung, sodass Daten unter Last effizient verteilt werden. In Verbindung mit den Verbesserungen im Netzwerkbereich und bei der Kryptografie erreicht der Client auf diese Weise einen Durchsatz, der weit über den der ursprünglichen Software hinausgeht.

Frankendancer gegen Firedancer

Die beiden Namen werden ständig verwechselt, daher ist der Unterschied wichtig. Frankendancer ist ein Hybrid: Es bindet den Netzwerk- und Blockerzeugungscode Firedancer in die Rust-Laufzeitumgebung und den Konsensmechanismus von Agave ein, sodass Validatoren einen Teil der Architektur übernehmen können, ohne ungeprüftem Konsenscode vertrauen zu müssen.

Frankendancer wurde mainnet eingeführt und gewann im Laufe des Jahres 2025 zunehmend an Bedeutung. Da es sich bei der Ausführung und Konsensfindung auf Agave stützt, ist seine Leistung durch diese Laufzeit begrenzt, und es löst das Problem des „Single-Client“ nicht vollständig, da jeder Knoten weiterhin vom Konsens von Agave abhängig ist.

Full Firedancer diese Abhängigkeit Firedancer . Es implementiert die gesamte Validator-Pipeline – einschließlich Konsens und Ausführung – in einer eigenständigen C- und C++-Codebasis. Diese Version verschafft Solana echten zweiten Client und einen von Agave getrennten Ausfallbereich.

Mainnet und dessen Verbreitung

Jump Crypto kündigte am 12. Dezember 2025 auf Solana in Abu Dhabimainnet vollständigenmainnet an. Bis dahin war der Client bereits seit etwa 100 Tagen im Stillen in der Produktion auf einer kleinen Validatorengruppe gelaufen und hatte dabei über 50.000 Blöcke fehlerfrei generiert. Zuvor hatte das Team ein öffentliches Sicherheitsaudit durchgeführt, das durch ein Bug-Bounty-Programm in Höhe von 1 Million US-Dollar unterstützt wurde.

Die Einführung erfolgte bewusst schrittweise und nicht als plötzlicher Umstieg. Der Gründungsingenieur Ritchie Patel erklärte gegenüber CoinDesk im Mai 2026, dass der Client bereits mehrere zehn Millionen Transaktionen abgewickelt habe, während die Akzeptanz vorsichtig ausgebaut wurde.

Bis zur ersten Hälfte des Jahres 2026 lief die Firedancer auf etwa 20 Prozent oder mehr der aktiven Validatoren, wobei der Vollclient einen Anteil im niedrigen zweistelligen Bereich an SOL gestakten SOL hielt. Jito Agave-Fork hält nach wie vor die Mehrheit, sodass ein ausgewogenes Multi-Client-Netzwerk noch Jahre entfernt ist. SOL nach dem Start SOL rund 6 Prozent, und die Anzahl der Validatoren sat 840 Knoten, nach einem Höchststand von über 1.300.

Warum die Vielfalt der Kunden wichtig ist

Solana Ausfallbilanz erklärt das große Interesse. Die Analyse Helius zu den Ausfallzeiten des Netzwerks führt fünf von sieben größeren Ausfällen auf Fehler bei Validatoren oder Clients zurück und nicht auf das Konsensdesign. Wenn etwa 90 Prozent der Stakeholder dieselbe Software verwenden, kann ein einziger Programmierfehler die Blockproduktion zum Erliegen bringen, ganz gleich, wie schnell die Blockchain auch erscheinen mag.

Ethereum dies früh Ethereum und betrachtet die Vielfalt der Clients als Sicherheitsmaßnahme, wobei angestrebt wird, den Anteil eines einzelnen Clients unter einem Drittel der Konsensleistung zu halten. Ein Client, der diesen Wert überschreitet, kann die Finalität verzögern; bei einem Anteil von über zwei Dritteln könnte er fehlerhafte Blöcke finalisieren. Solana einer weitaus stärkeren Konzentration, bei fast 90 Prozent auf einen einzigen Client.

Firedancer die Gleichung. Da es weder Code noch Sprache mit Agave teilt, sollte ein Speicherfehler im Rust-Allokator von Agave keinen Einfluss auf die C++-Codebasis Firedancer haben, und beide Systeme können unabhängig voneinander ausfallen. Das Netzwerk kann einen katastrophalen Fehler in einem der beiden Systeme überstehen, solange die Einsätze so verteilt sind, dass kein einzelner Client die überwiegende Mehrheit auf einmal offline schalten kann.

Das ist auch das institutionelle Argument. Risikomanagement-Teams wollen wissen, was passiert, wenn etwas schiefgeht, und zwei unabhängige Kunden werden von ihnen ganz anders bewertet. Da JPMorgan eine Commercial-Paper-Emission auf Solana arrangiert Solana State Street einen tokenisierten Liquiditätsfonds für das Netzwerk vorbereitet, wird durch die Reduzierung des Einzelkundenrisikos ein wesentlicher Einwand gegen den Aufbau regulierter Finanzdienstleistungen auf dieser Plattform ausgeräumt.

Firedancer, Alpenglow und Solana Roadmap

Firedancer nur die eine Hälfte eines größeren Upgrades, und viele verwechseln es mit der anderen Hälfte. Alpenglow ist eine neue Konsens-Engine von Anza, die Proof of History und TowerBFT ersetzt und eine Finalität von etwa 150 Millisekunden anstrebt. Firedancer ein Client; Alpenglow ist ein Konsensprotokoll. Die Validatoren haben es genehmigt, und es befindet sich derzeit in der Testphase, bevor es voraussichtlich im Laufe des Jahres 2026 mainnet .

Auch die Rechenleistungsgrenzen spielen eine Rolle. Solana die pro Block zulässige Rechenleistung durch Vorschläge wie SIMD-0256 erhöht, wodurch die Obergrenze auf über 60 Millionen Einheiten angehoben wurde; weitere Erhöhungen werden derzeit diskutiert. Höhere Grenzwerte belasten die Hardware der Validatoren stärker – genau diese Belastung soll die Architektur Firedancer auffangen.

Beide Teams planen zudem für die Post-Quanten-Sicherheit. Im April 2026 entschieden sich Anza und das Firedancer unabhängig voneinander für Falcon, ein vom NIST ausgewähltes Signaturschema, dessen kompakte Signaturen sich für ein Netzwerk mit hohem Durchsatz eignen, ohne die Leistung zu beeinträchtigen.

Systemanforderungen für Firedancer

In ersten Berichten hieß es, Firedancer die Validierung kostengünstiger machen. Das Gegenteil war der Fall. Es begünstigt Maschinen mit hoher Kernanzahl und bestimmte Netzwerkgeräte, und die steigenden Rechenleistungsgrenzen Solana haben die Messlatte höher gelegt, nicht niedriger.

Die Prognosen der Betreiber für das Jahr 2026 gehen von einem ähnlichen Produktionsprofil aus:

• CPU: Ein Chip mit 12 Kernen und 24 Threads bei 2,8 GHz ist die Mindestanforderung, doch die Validationssysteme zielen auf 24 oder mehr Kerne bei 3,5 GHz und mehr ab. AMD-EPYC-Prozessoren wie der 9354 und der 9355 dominieren in Systemen mit einem Sockel, um Latenzzeiten zwischen den Sockeln zu vermeiden.
• AVX-512: Unverzichtbar für die beschleunigte Kryptografie. Ohne diese Funktion gehen die Vorteile bei der Signaturprüfung verloren.
• RAM: Etwa 384 GB bis 512 GB ECC-Speicher, deutlich mehr als in früheren Vorgaben angegeben, für größere Blöcke und den Kontostatus.
• Speicher: Enterprise-NVMe-Laufwerke der Generation 4 oder 5, wobei das Betriebssystem auf einer anderen Festplatte als ledger gespeichert ist.
• Netzwerk: Eine symmetrische 10-Gbit/s-Verbindung und eine XDP-fähige Netzwerkkarte, die für das Funktionieren des Kernel-Bypass-Designs unerlässlich sind.
• Optimierung: Deaktivieren Sie Hyper-Threading, trennen Sie die Kerne vom Kernel-Scheduler und legen Sie die CPU-Affinität so fest, dass jeder Tile einen eigenen Kern zugewiesen bekommt. Behandeln Sie all diese Punkte als zwingende Vorgaben.

Firedancer eine professionelle Infrastruktur, die für leistungsfähige Hardware entwickelt wurde. Der Betrieb eines Knotens wird dadurch weder lighter kostengünstiger.

Warum entwickelt Jump Firedancer?

Die Motivation hinter Jump geht auf das Kerngeschäft des Unternehmens zurück. Die Jump Trading Group hat zwei Jahrzehnte damit verbracht, Systeme mit geringer Latenz zu entwickeln, die riesige Datenmengen mit minimaler Verzögerung transportieren, und Firedancer diese Philosophie auf einen Validator. Patel hat den Client als eine Art echte Handelsplattform beschrieben, und der Chefwissenschaftler Kevin Bowers leitete die ersten Durchsatz-Demonstrationen.

Das erklärte Ziel ist Zuverlässigkeit und Leistung für Solana, ein Netzwerk, in das Jump stark investiert ist. Auch Geld spielt dabei eine Rolle. Validatoren verdienen am „Maximal Extractable Value“ – dem Gewinn, der durch die Reihenfolge der Transaktionen innerhalb von Blöcken entsteht –, und Solana MEV ist mittlerweile ein echtes Geschäft. Firedancer MEV Firedancer direkt, da diese hauptsächlich in Varianten wie Jito zum Tragen kommt, aber ein schnellerer, stabilerer Client stärkt die Infrastruktur, auf die sich MEV Betreiber verlassen.

Risiken und offene Fragen

Firedancer eine beachtliche technische Meisterleistung, und sein mainnet wirft ebenso viele Fragen auf, wie er beantwortet. Behalten Sie diese im Blick.

• Benchmark vs. Live-Durchsatz: TPS über 1 Million TPS stammt aus kontrollierten Demos. mainnet tatsächliche mainnet liegt weit darunter, im vierstelligen Bereich, und Benchmarks sagen wenig über das Verhalten unter angreifender Last oder bei Netzwerk-Splits aus.
• Langsame Migration: Der Wechsel des Clients ist mit erheblichem Aufwand bei der Hardware-Optimierung und im Betrieb verbunden, und Agave blickt auf mainnet jahrelange mainnet zurück, mit Firedancer noch Firedancer mithalten Firedancer . Vorsichtige Betreiber werden abwarten, sodass sich die Stake-Verteilung nur allmählich verschiebt.
• Anhaltendes Risiko durch eine einzige Client-Gruppe: Solange nicht genügend Anteile auf unabhängige Clients übergehen, könnte ein Fehler in der marktbeherrschenden Agave-basierten Software die Blockchain weiterhin lahmlegen. Vielfalt hilft erst dann, wenn die Verteilung wirklich ausgewogen ist.
• Neue Codebasis: Eine von Grund auf in C und C++ neu geschriebene Codebasis birgt gewisse Risiken hinsichtlich Speicherverwaltung und Parallelität, weshalb der Start erst nach einer umfassenden Prüfung und einem Bug-Bounty-Programm erfolgte. Da es bislang nur wenige Produktionsdaten gibt, sind Überraschungen nicht auszuschließen.
• Zentralisierungsdruck: Das anspruchsvolle Hardware-Profil begünstigt professionelle Betreiber und große Rechenzentren, und die Regeln zur Stake-Konzentration im Delegationsprogramm Solana könnten dazu führen, dass die Validierung zunehmend auf eine kleinere Zahl besser finanzierter Akteure konzentriert wird.
• Keine direkte Investition: Da es keinen Firedancer gibt, erfolgt das Engagement über SOL, wobei die übliche Kryptowährungsvolatilität unabhängig von einzelnen Upgrades besteht.

Fazit

Firedancer die Ausrichtung der Solana . Das Netzwerk hat schon immer mit Geschwindigkeit geworben, und diese Geschwindigkeit war auch real, doch es sat einem einzigen Software-Fehlerpunkt sat , der wiederholt zu peinlichen Ausfällen führte. Ein zweiter unabhängiger Client ist die strukturelle Lösung, und dieser wurde im Dezember 2025 in der Produktionsversion eingeführt.

TPS 1 Million TPS wird weiterhin für Schlagzeilen sorgen, doch das ist der am wenigsten interessante Aspekt. Der eigentliche Wandel besteht darin, dass Solana einen glaubwürdigen Weg zu einer Ausfallsicherheit für mehrere Clients eingeschlagen hat – eine Ausfallsicherheit, die es Institutionen ermöglicht, die Plattform als Produktionsinfrastruktur zu betrachten und nicht als schnelles, aber anfälliges Experiment.

Die Frage ist, ob dies in großem Maßstab umsetzbar ist. Stake muss migriert werden, der neue Code muss jahrelangen widrigen Bedingungen standhalten, und die Hardwareanforderungen dürfen nicht dazu führen, dass die Validatorengruppe stillschweigend wieder zentralisiert wird. Firedancer Solana Architektur, die es brauchte; ob das Netzwerk den vollen Nutzen daraus ziehen kann, hängt von der Einführung ab.