Fast während seiner gesamten Geschichte lief Solana auf einer einzigen Validator-Implementierung. Das machte es schnell, aber anfällig, da ein einzelner Software-Bug die gesamte Chain lahmlegen konnte.

Firedancer behebt dieses Problem. Es gibt Solana einen zweiten, vollständig unabhängigen Client mit separatem Code, einer anderen Sprache und einem eigenen Team, dem Multi-Client-Sicherheitsmodell, das Ethereum als Standard ansieht.

Hier erfahren Sie, wie Firedancer aufgebaut ist, wo es nach dem Launch steht und was es für die Zuverlässigkeit und Roadmap von Solana bedeutet. 👇

Was ist Firedancer?

Firedancer ist ein Validator-Client für Solana, entwickelt von Jump Crypto, dem Blockchain-Arm der Handelsfirma Jump Trading Group. Ein Validator-Client ist die Software, die Transaktionen verarbeitet, Blöcke produziert und beim Konsens abstimmt, sodass der Client, den ein Node ausführt, die Leistung des Netzwerks bestimmt.

Jump begann das Projekt im Jahr 2022 und traf eine bewusste Entscheidung. Statt Solanas Rust-basierte Software zu forken, wurde der Validator von Grund auf in C und C++ neu geschrieben, Sprachen, die eine präzise Kontrolle über Speicher und Hardware ermöglichen. Der neue Client teilt keinen Code mit dem bisherigen, was genau der Sinn der Sache ist.

Solanas Standard-Client ist Agave, gewartet von Anza, einem aus Solana Labs ausgegliederten Team. Die am häufigsten genutzte Variante ist das MEV-optimierte Fork von Jito für Agave. Firedancer hebt sich von beiden als ein wirklich separates Build ab, neben kleineren Clients wie Sig, Mithril und Tinydancer.

Trotz häufiger Verwechslungen ist Firedancer kein Token, kein airdrop und keine Protokolländerung. Es berührt weder die SOL-Ausgabe noch staking-Belohnungen oder Transaktionsregeln. Es ändert die Art und Weise, wie Validatoren ausgeführt werden, ohne zu verändern, was das Netzwerk tut.

Wie funktioniert Firedancer?

Firedancer behandelt den Validator als eine Reihe spezialisierter, isolierter Komponenten anstelle eines großen Programms und entfernt dann den Betriebssystem-Overhead, der den Durchsatz im großen Maßstab begrenzt.

1. Kachelbasierte Architektur

Firedancer unterteilt die Validator-Arbeit in unabhängige Prozesse, sogenannte Tiles, von denen jedes eine Aufgabe wie Netzwerkverarbeitung, Signaturprüfungen, Transaktionsbündelung oder Blockproduktion übernimmt. Jedes Tile ist an seinen eigenen CPU-Kern gebunden und kommuniziert über Shared-Memory-Kanäle mit den anderen.

Agave läuft als ein einzigiger monolithischer Prozess, bei dem Netzwerk, Ausführung und Konsens den Arbeitsspeicher gemeinsam nutzen. Die Aufteilung von Firedancer nutzt Multicore-Hardware durch Parallelisierung und fängt Ausfälle ab, da ein Fehler in einem Tile selten den gesamten Validator lahmlegt. NUMA-bewusste Speicherplatzierung und lockfreie Datenstrukturen verhindern, dass sich Kerne um dieselben Ressourcen streiten.

2. Kernel-Bypass-Networking

Jedes Paket, das ein Standardvalidator verarbeitet, durchläuft den Netzwerkstack des Linux-Kernels im Round-Trip-Verfahren, was bei hoher Last zu Engpässen führt. Firedancer überspringt diesen Pfad größtenteils mit AF_XDP und eBPF und liest Pakete direkt in der Nähe der Netzwerkkarte ein, sodass das Limit durch die Hardware und nicht durch die vorgeschaltete Software vorgegeben wird.

Darüber befindet sich eine benutzerdefinierte QUIC-Implementierung namens fd_quic sowie eine empfangsseitige Skalierung (Receive-Side Scaling), die den Datenverkehr auf die Kerne verteilt. Laut der Firedancer-Dokumentation schlafen die Netzwerk-Tiles niemals und nutzen Busy-Polling, um die Latenz stabil zu halten. Der Nachteil ist, dass hierfür während der Einrichtung Root-Zugriff und spezifische Netzwerkhardware erforderlich sind.

3. Beschleunigte Signaturverifizierung

Die Verifizierung von Ed25519-Signaturen ist bei hoher Auslastung eine der aufwendigsten Aufgaben eines Validators. Firedancer nutzt AVX-512-Vektorinstruktionen, um Signaturen in parallelen Batches anstatt nacheinander zu prüfen. Die Ingenieure von Jump haben ihre Routine auf demselben Chip mit etwa dem 3,9-Fachen der Geschwindigkeit der Standard-Skalarversion gemessen.

4. Block-Propagation

Firedancer optimiert zudem Turbine, den Block-Propagation-Mechanismus von Solana, sowie dessen Erasure Coding, damit sich Daten unter Last effizient verteilen. Zusammen mit den Leistungssteigerungen bei Netzwerk und Kryptografie treibt der Client den Durchsatz auf diese Weise weit über das hinaus, was die ursprüngliche Software zeigte.

Frankendancer vs Firedancer

Die beiden Namen werden ständig verwechselt, weshalb der Unterschied wichtig ist. Frankendancer ist ein Hybrid: Er verbindet den Netzwerk- und Blockproduktionscode von Firedancer mit Agaves Rust-Runtime und dem Konsens, sodass Validatoren einen Teil der Architektur übernehmen können, ohne ungetestetem Konsenscode vertrauen zu müssen.

Frankendancer erreichte 2024 das mainnet und gewann 2025 spürbar an Zugkraft. Da er für Ausführung und Konsens auf Agave zurückgreift, wird seine Leistung durch diese Runtime begrenzt, und er löst das Problem des einzelnen Clients nicht vollständig, da nach wie vor jeder Node vom Konsens von Agave abhängt.

Der vollständige Firedancer lässt diese Abhängigkeit entfallen. Er implementiert die gesamte Validator-Pipeline, einschließlich Konsens und Ausführung, in der unabhängigen C- und C++-Codebasis. Genau diese Version verschafft Solana einen echten zweiten Client und eine von Agave getrennte Fehlerdomäne.

Der mainnet-Start und die Einführung

Jump Crypto gab den vollständigen mainnet-Start von Firedancer am 12. Dezember 2025 auf der Solana Breakpoint in Abu Dhabi bekannt. Bis dahin war der Client bereits etwa 100 Tage lang unauffällig im Produktionsbetrieb bei einer kleinen Validator-Gruppe gelaufen und hatte über 50.000 Blöcke fehlerfrei produziert. Das Team hatte zuvor ein öffentliches Sicherheitsaudit durchgeführt, das von einem Bug Bounty in Höhe von 1 Million US-Dollar unterstützt wurde.

Die Einführung erfolgt bewusst langsam und nicht durch einen abrupten Wechsel. Der Gründungsingenieur Ritchie Patel erklärte gegenüber CoinDesk im Mai 2026, dass der Client zig Millionen Transaktionen verarbeitet habe, während die Einführung sorgfältig ausgeweitet wurde.

In der ersten Hälfte des Jahres 2026 lief die Firedancer-Familie auf rund 20 Prozent oder mehr der aktiven Validatoren, wobei der vollständige Client einen niedrigen zweistelligen Anteil an gestaktem SOL hielt. Jitos Agave-Fork hält nach wie vor die Mehrheit, sodass ein ausgewogenes Multiclient-Netzwerk noch Jahre entfernt ist. SOL stieg nach dem Start um rund 6 Prozent, und das Validator-Set lag bei fast 840 Nodes, was einen Rückgang von einem Höchststand von über 1.300 darstellt.

Warum Client-Diversität wichtig ist

Solanas Ausfallhistorie erklärt diese Aufmerksamkeit. Eine Analyse der Netzwerkausfälle durch Helius führt fünf von sieben größeren Stillständen auf Validator- oder Client-Fehler anstatt auf das Konsensdesign zurück. Wenn rund 90 Prozent des Stakes auf derselben Software laufen, kann ein einzelner Programmierfehler die Blockproduktion einfrieren, unabhängig davon, wie schnell die Chain wirkt.

Ethereum hat dies früh gelernt und betrachtet Client-Diversität als Sicherheitsregel, wobei angestrebt wird, jeden einzelnen Client unter einem Drittel der Konsensleistung zu halten. Ein Client oberhalb dieses Wertes kann die Finalisierung blockieren; über zwei Dritteln könnte er fehlerhafte Blöcke finalisieren. Solana startete deutlich konzentrierter, mit fast 90 Prozent auf einem einzigen Client.

Firedancer ändert diese Rechnung. Da er keinen Code und keine Sprache mit Agave teilt, sollte ein Speicherfehler im Rust-Allokator von Agave nicht die C++-Codebasis von Firedancer erreichen, und beide können unabhängig voneinander ausfallen. Das Netzwerk kann einen katastrophalen Fehler in einem der beiden verkraften, solange der Stake so verteilt ist, dass kein Client eine Supermajority gleichzeitig offline nehmen kann.

Dies ist auch das Argument für institutionelle Investoren. Risikoteams wollen wissen, was passiert, wenn etwas ausfällt, und zwei unabhängige Clients vermitteln ihnen ein völlig anderes Bild. Da JPMorgan eine Commercial-Paper-Emission auf Solana arrangiert und State Street einen tokenisierten Liquiditätsfonds für das Netzwerk vorbereitet, beseitigt die Beseitigung des Risikos eines einzelnen Clients ein wesentliches Einwand gegen den Aufbau regulierter Finanzanwendungen dort.

Firedancer, Alpenglow und die Roadmap von Solana

Firedancer ist die eine Hälfte eines größeren Upgrades, und oft wird er fälschlicherweise mit der anderen Hälfte gleichgesetzt. Alpenglow ist eine neue Konsens-Engine von Anza, die Proof of History sowie TowerBFT ersetzt und eine Finalisierung von nahezu 150 Millisekunden anstrebt. Firedancer ist ein Client, während Alpenglow ein Konsensprotokoll darstellt. Validatoren haben dem zugestimmt, und es befindet sich vor einer für den späteren Verlauf des Jahres 2026 erwarteten mainnet-Aktivierung in der Testphase.

Auch Rechenlastgrenzen spielen eine Rolle. Solana hat das Rechenvolumen pro Block durch Vorschläge wie SIMD-0256 angehoben, womit die Obergrenze auf über 60 Millionen Units gesteigert wurde, und weitere Erhöhungen werden diskutiert. Höhere Limits belasten die Validator-Hardware stärker, was exakt dem Druck entspricht, für dessen Abfederung die Architektur von Firedancer entwickelt wurde.

Beide Teams planen zudem für post-quantum-Sicherheit. Im April 2026 einigten sich Anza und das Firedancer-Team unabhängig voneinander auf Falcon, ein vom NIST ausgewähltes Signaturverfahren, dessen kompakte Signaturen zu einem Netzwerk mit hohem Durchsatz passen, ohne die Leistung zu beeinträchtigen.

Firedancer Hardware-Anforderungen

Frühe Berichte behaupteten, Firedancer würde das Validieren günstiger machen. Das Gegenteil ist eingetreten. Das System belohnt Maschinen mit hoher Kernanzahl und spezielle Netzwerk-Hardware, und die steigenden Rechenlimits von Solana haben die Messlatte nach oben verschoben, nicht nach unten.

Betreiber-Leitfäden für 2026 konvergieren bei einem ähnlichen Produktionsprofil:

• CPU: Ein Chip mit 12 Kernen, 24 Threads und 2,8 GHz bildet die Untergrenze, aber Produktions-Validatoren zielen auf 24 oder mehr Kerne bei 3,5 GHz und darüber ab. AMD-EPYC-Prozessoren wie der 9354 und 9355 dominieren in Single-Socket-Konfigurationen, um Latenzen zwischen verschiedenen Sockets zu vermeiden.
• AVX-512: Obligatorisch für die beschleunigte Kryptografie. Ohne diese fallen die Gewinne bei der Signaturverifizierung weg.
• RAM: Etwa 384 GB bis 512 GB ECC-Speicher, deutlich über älteren Empfehlungen, für größere Blöcke und den Account-Status.
• Speicher: Enterprise-NVMe-Gen4- oder Gen5-Laufwerke, wobei das Betriebssystem auf einem separaten Datenträger von den Ledger-Daten liegt.
• Netzwerk: Eine symmetrische 10-Gbps-Verbindung und eine XDP-fähige Netzwerkkarte, die das Kernel-Bypass-Design voraussetzt, um überhaupt zu funktionieren.
• Tuning: Hyperthreading deaktivieren, Kerne vom Kernel-Scheduler isolieren und die CPU-Affinität so einsetzten, dass jeder Tile seinen eigenen Kern besitzt. Betrachten Sie all dies als harte Anforderungen.

Firedancer ist professionelle Infrastruktur, die für leistungsfähige Hardware gebaut wurde. Sie macht das Betreiben eines Nodes weder leichter noch günstiger.

Warum baut Jump Firedancer?

Jumps Motivation lässt sich auf sein Tagesgeschäft zurückführen. Die Jump Trading Group hat zwei Jahrzehnte damit verbracht, Systeme mit geringer Latenz zu entwickeln, die große Datenmengen mit minimaler Verzögerung bewegen, und Firedancer wendet diese Kultur auf einen Validator an. Patel hat den Client als ähnlich agierend wie eine echte Handels-Engine beschrieben, und der leitende Wissenschaftler Kevin Bowers leitete die frühen Durchsatz-Demos.

Das erklärte Ziel sind Zuverlässigkeit und Leistung für Solana, ein Netzwerk, in das Jump stark investiert ist. Geld spielt dabei ebenfalls eine Rolle. Validatoren verdienen am maximal extrahierbaren Wert (MEV), dem Gewinn aus der Transaktionssortierung innerhalb von Blöcken, und Solanas MEV-Markt ist mittlerweile ein echtes Geschäft. Firedancer ändert die MEV-Ökonomie nicht direkt, da diese hauptsächlich in Varianten wie Jitos zu finden ist, aber ein schnellerer, stabilerer Client stärkt die Infrastruktur, auf die MEV-bewusste Betreiber vertrauen.

Risiken und offene Fragen

Firedancer ist eine ernsthafte ingenieurtechnische Leistung, und seine Ankunft im mainnet wirft ebenso viele Fragen auf, wie sie beantwortet. Behalten Sie diese Aspekte im Auge.

• Benchmark vs. Live-Durchsatz: Der Wert von über 1 Million TPS stammt aus kontrollierten Demos. Der reale mainnet-Durchsatz liegt weitaus niedriger, im Tausenderbereich, und Benchmarks sagen wenig über das Verhalten unter adversarialer Last oder bei Netzwerk-Splits aus.
• Langsame Migration: Das Wechseln von Clients erfordert echten Aufwand bei Hardware-Tuning und Betrieb, und Agave kann auf eine jahrelange mainnet-Historie verweisen, die Firedancer noch nicht bieten kann. Vorsichtige Betreiber werden abwarten, weshalb sich der stake schrittweise verschiebt.
• Anhaltendes Risiko eines einzelnen Clients: Solange nicht genügend stake zu unabhängigen Clients abwandert, könnte ein Bug in der dominanten Agave-basierten Software die Blockchain nach wie vor zum Erliegen bringen. Diversität hilft erst dann, wenn die Verteilung wirklich ausgewogen ist.
• Neuer Code: Ein von Grund auf in C und C++ geschriebener Code bringt eigene Speicher- und Konkurrenzrisiken mit sich, weshalb der Launch auf eine lange Audit- und Bug-Bounty-Phase folgte. Eine dünne Produktionshistorie lässt Raum für Überraschungen.
• Zentralisierungsdruck: Das anspruchsvolle Hardware-Profil begünstigt professionelle Betreiber und große Rechenzentren, und Regeln zur stake-Konzentration im Solana Foundation Delegation Program könnten die Validierung in Richtung weniger, besser finanzierter Akteure drängen.
• Keine direkte Investition: Es gibt keinen Firedancer-Token, weshalb das Exposure über SOL läuft – inklusive der üblichen Krypto-Volatilität, unabhängig von einem einzelnen Upgrade.

Fazit

Firedancer verändert den Kern der Debatte über Solana. Das Netzwerk hat stets Geschwindigkeit verkauft, und diese Geschwindigkeit war real, allerdings basierte sie auf einem einzelnen Software-Fehlerausgangspunkt, der wiederholte, peinliche Ausfälle verursachte. Ein zweiter, unabhängiger Client ist die strukturelle Lösung, und er ist im Dezember 2025 in Form einer produktionsreifen Version erschienen.

Die Zahl von 1 Million TPS wird zwar weiterhin für Schlagzeilen sorgen, ist jedoch der uninteressanteste Teil. Der echte Wandel besteht darin, dass Solana nun über einen glaubwürdigen Weg zu einer Multi-Client-Resilienz verfügt – jene Art von Widerstandskraft, die es Institutionen ermöglicht, das Netzwerk als Produktionsinfrastruktur zu behandeln und nicht als schnelles, aber anfälliges Experiment.

Die Ausführung im großen Maßstab bleibt die offene Frage. stake muss migrieren, der neue Code muss jahrelange adverse Bedingungen überstehen und die Hardware-Anforderungen dürfen das Validator-Set nicht klammheimlich erneut zentralisieren. Firedancer gibt Solana die Architektur, die es brauchte; ob das Netzwerk den vollen Nutzen daraus zieht, hängt vom Rollout ab.