SOLANA·HUB
EN

Firedancer und Frankendancer: Solanas zweiter Validator-Client erklärt

Jump Trading Group entwickelt Firedancer als komplett neuen Solana-Validator-Client in C. Frankendancer ist die Hybrid-Zwischenstufe. Was die zwei voneinander unterscheidet, was schon im Mainnet läuft und was 2026 ansteht.

SOLANA·HUB ·

Solana läuft seit Jahren auf einem einzigen Validator-Client. Firedancer ist der erste echte Zweit-Client — und sein bloßes Existieren macht das Netzwerk strukturell stabiler.

In einfachen Worten: Stell dir vor, ein Flugzeug hat zwei völlig unabhängig voneinander gebaute Triebwerke — von verschiedenen Teams, mit verschiedenem Werkzeug. Wenn ein Design-Fehler ein Triebwerk trifft, läuft das andere einfach weiter. Genau das leistet Firedancer für Solana: Ein zweites Validator-Programm, das von einem anderen Team in einer anderen Programmiersprache gebaut wurde. Trifft ein Bug die eine Implementierung, hält die andere das Netzwerk am Laufen. Das Netzwerk wird dadurch nicht schneller — es wird widerstandsfähiger. Frankendancer ist die aktuelle Zwischenstufe, bei der das neue Netzwerk-Modul von Firedancer bereits produktiv läuft, während Runtime und Konsens noch aus dem alten System stammen.

Kernidee

Solana hatte seit dem Mainnet-Start 2020 nur einen einzigen Validator-Client (Agave). Ein einzelner Client bedeutet: ein einziger Bug kann das gesamte Netzwerk gefährden. Firedancer — gebaut von Jump Trading Group in C, unabhängig von Agaves Rust-Codebase — schließt diese Lücke. Nicht durch mehr Geschwindigkeit, sondern durch echte Unabhängigkeit: zwei Implementierungen, die denselben Fehler höchstwahrscheinlich nicht gleichzeitig haben. Die Hybrid-Zwischenstufe heißt Frankendancer (Hybrid aus altem Agave + neuem Firedancer-Network-Layer) — sie läuft bereits produktiv im Mainnet.

Worum es geht

Solana hat seit dem Mainnet-Launch 2020 mit einem einzigen Validator-Client-Codebase gearbeitet — dem Solana-Labs-Validator, der inzwischen als Agave von Anza weiterentwickelt wird. Seit mehreren Jahren baut Jump Trading Group an einem komplett unabhängigen Zweit-Client: Firedancer. Zwischenstufe ist Frankendancer — ein Hybrid aus Firedancer-Network-Layer und Agave-Runtime-plus-Consensus.

Dieser Artikel erklärt, was die zwei voneinander unterscheidet, welche Solana-Schichten Firedancer ersetzt, wie der aktuelle Stand 2026 aussieht und wie das mit Alpenglow zusammenspielt.

Keine Finanzberatung. Dieser Artikel beschreibt technische Validator-Software.

Wer Firedancer baut und warum

Jump Trading Group ist eine der weltweit größten Trading-Firmen. Sie hat über zwei Jahrzehnte ein high-capacity, low-latency Trading-Netzwerk aufgebaut. Aus dieser Erfahrung ist Firedancer entstanden — ein Validator-Client, der die gleichen High-Performance-Patterns auf Solana anwendet.

Aus den Firedancer-Docs: “Over the past twenty years, Jump has built a high-capacity, high-reliability, low-latency global network to support our trading and address many of the scaling problems that Solana is currently facing.”

Das Projekt wird von der Solana Foundation finanziell unterstützt. Jump selbst commitet bedeutende Entwickler-Ressourcen.

Architektur — die drei Solana-Schichten

Ein Solana-Validator besteht aus drei funktionalen Blöcken:

  1. Network-Layer — Empfangen und Versenden von Transaktionen und Shreds (Datenblöcke für Turbine-Distribution), Gossip, Turbine/Rotor-Distribution
  2. Runtime — Ausführung der Transaktionen, Solana Virtual Machine (SVM; die Rechenmaschine für Smart Contracts)
  3. Consensus — Voting, Block-Finalisierung (heute TowerBFT, mit Alpenglow-Migration Votor; Votor = neues schnelleres Abstimmungsprotokoll)

Firedancer’s Ziel ist, alle drei Blöcke in C neu zu schreiben. Aktuell ist nur der Network-Layer code-complete und unter Audit — die Runtime- und Consensus-Blöcke sind “in heavy development” (Stand laut Firedancer-Docs).

Frankendancer: die Hybrid-Stufe

Da Pure Firedancer noch nicht vollständig ist, gibt es Frankendancer als Übergangs-Lösung.

Frankendancer = Firedancer-Network + Agave-Runtime-und-Consensus. Network-Pakete werden vom Firedancer-C-Code verarbeitet, sobald Transaktionen in den Block-Production-Pfad eintreten, übernimmt Agave-Rust-Code.

Konkret ersetzt Frankendancer in Agave laut Docs:

  • den kompletten Networking-Stack (TPU/QUIC = Protokoll für schnelle Transaktions-Übermittlung, Shred-Reception, Repair)
  • die Block-Production-Komponenten beim aktiven Leader-Slot (Leader = der Validator, der gerade einen Block produziert)

Was dabei bleibt:

  • Runtime (Transaktions-Ausführung, SVM)
  • Konsens-Logik (Voting, Finalisierung)
  • Account-Storage

Frankendancer-Versionen folgen dem Schema v0.xxx.yyyyy. Die erste Full-Firedancer-Version wird 1.x sein.

Welche Hardware Frankendancer aktuell verlangt

Aus den Firedancer-Docs Getting-Started:

Minimum:

  • 24-Core AMD oder Intel CPU mit über 2,8 GHz
  • 256 GB RAM
  • 2 TB PCI-Gen3-NVMe-SSD mit hoher Lebensdauer

Empfohlen:

  • 32-Core CPU mit über 3 GHz, AVX512-Support
  • 512 GB RAM mit ECC
  • Getrennte Disks für Accounts und Ledger
  • 1 Gigabit pro Sekunde Bandbreite

Die Anforderungen entsprechen weitgehend Agave-Validator-Anforderungen, weil Frankendancer noch auf der Agave-Runtime aufsetzt. Erklärtes Ziel der Firedancer-Roadmap: diese Anforderungen schrittweise zu senken, damit mehr unabhängige Operators teilnehmen können.

Wie Firedancer mit Alpenglow zusammenpasst

Eine häufige Verwechslung: Firedancer und Alpenglow sind unterschiedliche Schichten.

  • Firedancer ist die Validator-Software (welcher Code läuft auf dem Server)
  • Alpenglow ist das Konsens-Protokoll (wie Validators sich auf finalisierte Blocks einigen)

Alpenglow kann theoretisch von beiden Clients (Agave und Firedancer) implementiert werden. Anza arbeitet aktuell daran, Alpenglow in Agave produktiv zu machen — Anza-CEO Brennan Watt schreibt im Anza26-Roadmap-Post: “In 2026, our focus is on shifting Alpenglow out of development clusters and onto mainnet in Q3.”

Sobald Alpenglow auf Mainnet aktiv ist, müsste auch Firedancer eine Alpenglow-kompatible Consensus-Implementation einbauen, um Pure-Firedancer fertig zu stellen. Wir gehen in einem separaten Artikel auf Alpenglow im Detail ein — siehe Alpenglow erklärt.

Status 2026 — was läuft und was kommt

Stand Mai 2026 lässt sich aus den public Source-Materialien folgender Stand zusammenfassen:

  • Frankendancer im Mainnet: ein wachsender Anteil der Validators fährt Frankendancer. Konkrete Stake-Anteile veröffentlicht der Firedancer-Status-Tracker und Solana-Beach.
  • Pure Firedancer: Network-Layer code-complete und unter Audit, Runtime und Consensus in heavy development. Eine konkrete Mainnet-Migrations-Timeline für Pure Firedancer hat das Jump-Team in den public Docs nicht angegeben.
  • Alpenglow-Mainnet: laut Anza-Roadmap für Q3 2026 geplant — separates Protokoll-Update, läuft parallel zur Firedancer-Migration.
  • Anza-Roadmap 2026 umfasst mehrere weitere Initiativen wie XDP-Shred-Transmission, Block-Limits auf 100M Compute Units, direct memory mapping in der SVM und Slot-Zeiten unter 400ms — diese sind Agave-Optimierungen, nicht Firedancer-spezifisch.

Sicherheits-Modell

Firedancer setzt auf zwei Sicherheits-Strategien:

  • Sandbox-Isolation: der Validator läuft mit stark eingeschränkten System-Calls. Inspiriert von Browser-Sandbox-Modellen.
  • Code-Diversität: weil Firedancer in C und Agave in Rust geschrieben ist, gehen Bugs in Library- oder Dependency-Layer mit hoher Wahrscheinlichkeit nur einen der beiden Clients gleichzeitig.

Aus den Docs: “As nodes are distributed more evenly among several independent codebases, the overall network will become more robust against any one bug.”

Was sich für Validators und Endnutzer ändert

Reines Reporting der dokumentierten Effekte:

Validators: Wahl zwischen Agave und Frankendancer (perspektivisch Pure Firedancer). Wechsel zu Frankendancer erfordert Build aus Source (keine pre-built Binaries), Hardware bleibt im Agave-Bereich.

Anwendungs-Entwickler: keine direkten Software-Änderungen. Performance-Verbesserungen durch Frankendancer-Networking sind transparent.

Endnutzer und Wallet-Betreiber: keine direkten Aktionen. Wenn ein größerer Validator-Anteil auf Firedancer migriert, könnten Slot-Zeiten und Block-Production-Robustheit messbar profitieren.

Was das für dich heißt

Firedancer ist kein Feature, das du als Nutzer direkt anfasst. Es wirkt im Hintergrund: Je mehr Validators auf Frankendancer und später Pure Firedancer wechseln, desto robuster wird das Netzwerk gegen Software-Fehler. Client-Diversität (zwei unabhängige Implementierungen im Live-Betrieb) ist ein Qualitätsmerkmal des Netzwerks — ähnlich wie redundante Systeme in der Infrastruktur. Für Staking-Entscheidungen und DeFi-Nutzung ändert sich im Alltag nichts Unmittelbares. Der langfristige Effekt ist eine stabilere Basis für alle darauf aufbauenden Anwendungen.

Selbst sicher umsetzen? Dieser Artikel erklärt das Konzept. Den geordneten Schritt-für-Schritt-Weg — Wallet, Sicherheit, Staking, DeFi, DACH-Steuern — gibt dir der Solana-Guide.

Quellen

Verwandte SolanaHub-Artikel:

Verwandte Glossar-Begriffe:

#solana #firedancer #frankendancer #jump-crypto #validator #anza #performance #infrastructure