Was ist Firedancer? Ein tiefer Einblick in Solana 2.0

Worum geht es in diesem Artikel?

Solana ist die schnellste Blockchain. Aber sie kann noch schneller werden. Der aktuelle Validator-Client von Solana Labs ist gut, wurde jedoch für eine schnelle Markteinführung optimiert. Mit dem Wissen aus der Rückschau, einem Neuanfang und jahrzehntelanger Erfahrung im Hochleistungsrechnen will Jump Solana noch schneller und zuverlässiger machen. Jump nutzt seine Erfahrung im Hochfrequenzhandel und entwickelt Firedancer. Es ist der leistungsstärkste Validator-Client aller Blockchains. Dafür wird der aktuelle Validator-Client von Solana vollständig in der Programmiersprache C neu geschrieben.

Dieser Artikel erklärt Validatoren und warum eine Vielfalt von Validator-Clients wichtig ist. Anschließend erfährst du, warum Jump einen neuen Validator-Client entwickelt und weshalb seine Erfahrung im Hochfrequenzhandel das Unternehmen zum perfekten Team für Firedancer macht. Danach erklären wir, was Firedancer ist, wie es funktioniert, warum es schnell ist, wie es abgesichert wird und wie der aktuelle Stand aussieht.

Am Ende dieses Artikels wirst du den neuen Validator-Client von Jump umfassend verstehen. Du kennst dann die wegweisenden Optimierungen, die ihn zum leistungsstärksten Validator-Client auf jeder Blockchain machen. Außerdem verstehst du, warum Firedancer für die Leistung und Zuverlässigkeit des Solana-Netzwerks unverzichtbar ist. Dieser Artikel enthält alles, was du über Firedancer wissen musst.

Der Abschnitt Anhang enthält eine vollständig optionale Einführung in Computerhardware und Netzwerke. Sie liefert durchschnittlichen Lesern den nötigen Kontext, um die fortgeschrittenen Hardware- und Netzwerkkonzepte in diesem Artikel zu verstehen. Wo nötig, geben wir dennoch zusätzlichen Kontext. Der Artikel soll so zugänglich sein, dass alle Solana-Nutzer Firedancer und seine Bedeutung verstehen können.

Was sind Validatoren und was bedeutet Vielfalt bei Validator-Clients?

Ein Validator ist ein Computer, der an einer Proof-of-Stake-Blockchain teilnimmt. Validatoren bilden das Rückgrat des Solana-Netzwerks. Sie verarbeiten Transaktionen und nehmen am Konsens teil. Ein Validator trägt zur Sicherheit des Netzwerks bei, indem er eine bestimmte Menge des nativen Tokens von Solana als Stake sperrt. Stell dir das wie eine Kaution vor, durch die der Validator dem Netzwerk gegenüber finanziell haftet. Dieser Anreiz sorgt dafür, dass Validatoren ihre Aufgaben korrekt und effizient ausführen, denn für ihre Beiträge erhalten sie Belohnungen. Böswillige oder fehlerhafte Aktivitäten werden hingegen bestraft. Bei Fehlverhalten wird der Stake eines Validators durch einen als Slashing bezeichneten Prozess reduziert. Daher liegt es im Interesse eines Validators, seine Aufgaben ordnungsgemäß zu erfüllen und seinen Stake zu steigern.

Validator-Clients sind Anwendungen, mit denen Validatoren ihre Aufgaben ausführen. Der Client bildet die Grundlage für Validatoren und nutzt deren kryptografisch eindeutige Identität, damit sie am Konsens teilnehmen können.

Mehrere voneinander unabhängige Clients verbessern die Fehlertoleranz, falls eine Implementierung ausfällt. Kontrolliert beispielsweise kein Client mehr als 33 % des Stakes, legt ein Absturz oder ein die Verfügbarkeit beeinträchtigender Fehler nicht das gesamte Netzwerk lahm. Führt ein Fehler in einem Client zu einem ungültigen Zustandsübergang, kann das Netzwerk einen Sicherheitsausfall vermeiden, solange weniger als 33 % des Stakes diesen Client verwenden. Der Großteil des Netzwerks bleibt dann in einem gültigen Zustand, wodurch eine Aufspaltung oder ein Fork der Blockchain verhindert wird. Eine größere Vielfalt an Validator-Clients macht das Netzwerk somit widerstandsfähiger, weil ein Fehler oder eine Schwachstelle in einem Client nicht das gesamte Netzwerk beeinträchtigt.

Die Client-Vielfalt wird anhand des Stake-Anteils pro Client und der Gesamtzahl verfügbarer Clients gemessen. Zum Zeitpunkt der Veröffentlichung dieses Artikels gibt es 1979 Validatoren im Solana-Netzwerk. Die beiden Clients, die diese Validatoren im Mainnet verwenden, stammen von Solana Labs und Jito Labs. Solana startete im März 2020 mit einem einzigen Validator-Client, den Solana Labs entwickelt hatte. Im August 2022 veröffentlichte Jito Labs einen zweiten Validator-Client. Dieser Client ist ein Fork des Codes von Solana Labs, der von Jito gepflegt und bereitgestellt wird. Der Client optimiert die Extraktion von MEV (maximal extrahierbarer Wert) innerhalb von Blöcken. Jitos Client erstellt einen Pseudo-Mempool, da Solana Blöcke ohne einen solchen streamt. Ein Mempool oder Memory Pool ist übrigens eine Warteschlange aus anstehenden und unbestätigten Transaktionen. Ein Pseudo-Mempool ermöglicht es Validatoren, diese Transaktionen zu durchsuchen, optimal zu bündeln und an Jitos Block Engine zu übermitteln.

Im Oktober 2023 entfallen 68,55 % des aktiven Stakes auf den Client von Solana Labs und 31,45 % auf Jito. Die Zahl der Validatoren, die Jitos Client verwenden, ist seit dem vorherigen Zustandsbericht der Solana Foundation um 16 % gestiegen. Die zunehmende Nutzung von Jitos Client deutet auf einen positiven Trend zu mehr Client-Vielfalt hin.

Diese Entwicklung ist erfreulich, aber noch nicht perfekt. Wichtig ist: Jitos Client ist ein Fork des Clients von Solana Labs. Jito teilt daher viele Komponenten mit der ursprünglichen Validator-Codebasis und ist potenziell anfällig für Fehler oder Exploits, die auch den Labs-Client betreffen würden. Im Idealfall wird Solana künftig mindestens vier unabhängige Validator-Clients haben. Verschiedene Teams würden diese Clients in unterschiedlichen Programmiersprachen entwickeln. Keine einzelne Implementierung hätte mehr als 33 % des Stakes, da jeder Client etwa ~25 % halten würde. Bei diesem idealisierten Aufbau gäbe es im gesamten Validator-Stack keinen Single Point of Failure.

Die Entwicklung eines zweiten unabhängigen Validator-Clients ist für diese Zukunft unverzichtbar. Jump will sie verwirklichen.

Warum entwickelt Jump einen neuen Validator-Client?

Im Mainnet von Solana kam die Blockproduktion in der Vergangenheit viermal zum Stillstand. Jedes Mal waren manuelle Korrekturen durch Hunderte Validatoren nötig. Diese Ausfälle haben Bedenken hinsichtlich der Zuverlässigkeit des Solana-Netzwerks geweckt. Jump hält das Protokoll für solide. Stattdessen führt das Unternehmen die Ausfallzeiten auf Probleme in Softwaremodulen zurück, die den Konsens beeinträchtigen. Deshalb entwickelt Jump einen neuen Validator-Client, der diese Probleme beheben soll. Das übergeordnete Ziel des Clients ist es, die Stabilität und Effizienz des Solana-Netzwerks zu verbessern.

Einen unabhängigen Validator-Client zu entwickeln, ist schwierig. Jump hat jedoch nicht zum ersten Mal ein zuverlässiges globales Netzwerk aufgebaut. Früher führten Börsenmakler Wertpapiertransaktionen, also den Kauf und Verkauf von Aktien, manuell aus. Mit dem Aufkommen elektronischer Handelsplattformen wurden Wertpapierbörsen offener. Diese Offenheit steigerte den Wettbewerb und die Automatisierung und senkte den Zeit- und Kostenaufwand für Anleger. Unter den Börsenmaklern begann ein technologisches Wettrüsten.

Trader leben für den Handel. Ein optimales Handelserlebnis erfordert kompromisslose Software-, Hardware- und Netzwerklösungen. Diese Systeme brauchen hohe maschinelle Intelligenz, geringe Echtzeitlatenz, hohen Durchsatz, hohe Anpassungsfähigkeit, hohe Skalierbarkeit, hohe Zuverlässigkeit und hohe Rechenschaftspflicht.

Standardlösungen, also Software, die ein Unternehmen direkt kaufen kann, bieten keinen Wettbewerbsvorteil. Zehnmal als Zweiter die richtige Order an eine Börse zu senden, ist eine teure Methode, Geld zu verlieren. Der harte Wettbewerb im Hochfrequenzhandel führt zu einem endlosen Entwicklungszyklus, in dem erstklassige globale Handelsinfrastruktur entsteht.

Dieses Szenario klingt vielleicht vertraut. Die Anforderungen an ein erfolgreiches Handelssystem ähneln denen einer erfolgreichen Blockchain. Blockchains müssen leistungsstarke, fehlertolerante Netzwerke mit geringer Latenz sein. Eine langsame Blockchain ist gescheiterte Technologie, die den Anforderungen moderner Unternehmensanwendungen nicht gerecht wird. Sie hemmt Innovation, Skalierbarkeit und praktischen Nutzen. Mit mehr als zwei Jahrzehnten Erfahrung bei der Skalierung globaler Netzwerke und Entwicklung leistungsstarker Systeme ist Jump das perfekte Team für einen unabhängigen Validator-Client. Kevin Bowers, Chief Science Officer bei Jump Trading, leitet diesen Prozess.

Warum ist die Lichtgeschwindigkeit zu langsam?

Kevin Bowers hat ausführlich darüber gesprochen, dass selbst die Lichtgeschwindigkeit zu langsam ist. Die Lichtgeschwindigkeit ist eine endliche Konstante und begrenzt auf natürliche Weise die Zahl der Berechnungen, die ein einzelner Transistor verarbeiten kann. Bits werden derzeit durch Elektronen dargestellt, die sich durch Transistoren bewegen. Das Shannon-Kapazitätstheorem, also die maximale Menge fehlerfreier Daten, die über einen Kanal übertragen werden kann, begrenzt die Zahl der durch einen Transistor übertragenen Bits. Aufgrund fundamentaler Gesetze der Physik und Informationstheorie hängt die Rechengeschwindigkeit davon ab, wie schnell sich ein Elektron durch Materie bewegen und wie viele Daten übertragen werden können. Wenn Supercomputer an ihre Grenzen stoßen, werden diese Einschränkungen deutlich. Daraus ergibt sich ein „dramatisches Missverhältnis zwischen der Fähigkeit von Computern, Zahlen zu verarbeiten, und ihrer Fähigkeit, Zahlen zu transportieren.“

Nimm als Beispiel eine Intel Core i9 13900K CPU. Sie hat 24 x86-Kerne mit einem Basistakt von 2,2 GHz und einem maximalen Turbotakt von 5,8 GHz. Im ungünstigsten Fall müsste Licht eine Gesamtstrecke von ~52,0 mm über diese CPU zurücklegen. Die Manhattan-Distanz der CPU, also der entlang rechtwinkliger Achsen gemessene Abstand zwischen zwei Punkten, beträgt ~73,6 mm. Beim maximalen Turbotakt von 5,8 GHz kann Licht in Luft ~51,7 mm zurücklegen. Das bedeutet, dass ein Signal innerhalb eines einzigen Taktzyklus fast einmal zwischen zwei beliebigen Punkten auf der CPU hin- und zurückgelangen kann.

In Wirklichkeit ist die Situation deutlich schlechter. Diese Berechnungen verwenden die Lichtgeschwindigkeit in Luft, obwohl sich die Signale durch Siliziumdioxid (SiO2) bewegen. In einem Taktzyklus bei 5,8 GHz kann Licht in Siliziumdioxid ~26,2 mm zurücklegen. In Silizium (Si) schafft es bei 5,8 GHz nur ~15,0 mm – etwas mehr als die Hälfte der langen Kante der CPU.

Das Firedancer-Team argumentiert, dass es bei den jüngsten technologischen Fortschritten in der Datenverarbeitung eher darum ging, mehr Kerne in einer CPU unterzubringen, statt diese schneller zu machen. Wer mehr Leistung brauchte, sollte einfach mehr Hardware kaufen. Das funktioniert vorerst, solange der Durchsatz der Engpass ist. Der eigentliche Engpass ist jedoch die Lichtgeschwindigkeit. Diese natürliche Grenze lähmt die Entscheidungsfindung. Keine einzelne Optimierung zahlt sich sofort aus, weil ein System aus vielen Komponenten besteht und keine davon gut optimiert ist. Die nicht optimierten Teile werden sich mit der Zeit verschlechtern, weil ihnen weniger Rechenleistung zur Verfügung steht. Was also nun?

Im Hochleistungsrechnen gilt: Irgendwann muss alles optimiert werden. Das Ergebnis sind Systeme für den produktiven Handel und die quantitative Forschung, die weltweit an den Grenzen von Physik und Informationstheorie arbeiten. Dazu gehören maßgeschneiderte Netzwerk-Switching-Technologien ebenso wie sperrfreie Algorithmen, die mit Blick auf diese physikalischen Grenzen entwickelt wurden. Jump ist ebenso sehr ein Technologie- wie ein Handelsunternehmen. An der Grenze zwischen Science-Fiction und Realität und angesichts der auffälligen Ähnlichkeiten zwischen den aktuellen Herausforderungen von Jump und Solana entwickelt Jump Firedancer.

Was ist Firedancer?

Firedancer ist ein neuer, vollständig unabhängiger Validator-Client, den das Firedancer-Team in der Programmiersprache C entwickelt. Seine modulare Architektur, minimale Abhängigkeiten und umfangreiche Tests machen Firedancer besonders zuverlässig. Er schreibt die drei funktionalen Komponenten des Clients von Solana Labs weitgehend neu: Netzwerk, Laufzeit und Konsens. Jede Ebene wird für maximale Leistung optimiert, sodass die Kapazität des Clients nur durch die Hardware des Validators begrenzt wird. Derzeit stoßen Validatoren hingegen aufgrund ineffizienter Software an Leistungsgrenzen. Mit Firedancer skaliert Solana entsprechend der Bandbreite und Hardware.

Firedancer verfolgt diese Ziele:

• Das Solana-Protokoll dokumentieren und standardisieren (am Ende soll eine Person allein anhand der Dokumentation einen Solana-Validator erstellen können, ohne den Rust-Code des Validators lesen zu müssen)
• Die Vielfalt der Validator-Clients erhöhen
• Die Leistung des Ökosystems verbessern

Wie funktioniert Firedancer?

Modulare Architektur

Firedancer unterscheidet sich durch seine charakteristische modulare Architektur von aktuellen Solana-Validator-Clients. Anders als der Rust-Validator-Client von Solana Labs, der als einzelner Prozess läuft, besteht Firedancer aus zahlreichen separaten Linux-C-Prozessen, die als Tiles bezeichnet werden. Ein Tile ist ein Prozess mit etwas Arbeitsspeicher. Diese Tile-Architektur ist grundlegend für die Funktionsweise von Firedancer und seinen Ansatz für Robustheit und Effizienz.

Ein Prozess ist eine Instanz eines laufenden Programms. Er ist ein grundlegender Bestandteil moderner Betriebssysteme und bildet die Ausführung einer Reihe von Anweisungen ab. Jeder Prozess verfügt über eigenen Arbeitsspeicher und eigene Ressourcen, die das Betriebssystem zuweist. Er arbeitet unabhängig von anderen Prozessen. Ein Prozess ist wie ein eigenständiger Arbeiter in einer großen Fabrik, der mit eigenen Werkzeugen und einem eigenen Arbeitsbereich eine bestimmte Aufgabe erledigt.

In Firedancer ist jedes Tile ein separater Prozess mit einer festgelegten Aufgabe. Das QUIC-Tile verarbeitet beispielsweise eingehenden QUIC-Datenverkehr und leitet die gekapselten Transaktionen an das Verify-Tile weiter. Das Verify-Tile prüft Signaturen. Entsprechend hat jedes weitere Tile seine eigene Aufgabe. Diese Tiles arbeiten unabhängig und parallel und tragen gemeinsam zur Gesamtfunktion des Systems bei. Separate Linux-Prozesse ermöglichen kleine, unabhängige Fehlerbereiche. Das bedeutet, dass Probleme in einem Tile nur minimale Auswirkungen – oder einen kleinen „Explosionsradius“ – auf das Gesamtsystem haben. Dieser Ansatz unterscheidet sich vom Rust-Client von Solana Labs, da ein einzelner Fehlerpunkt nicht sofort den gesamten Validator gefährden kann.

Ein entscheidender Vorteil der Firedancer-Architektur besteht darin, dass sich jedes Tile innerhalb weniger Sekunden ohne Ausfallzeit ersetzen und aktualisieren lässt. Das steht in starkem Kontrast zum Rust-Client von Solana Labs, der vor Aktualisierungen vollständig heruntergefahren werden muss. Der Unterschied beruht auf der fehlenden Stabilität der ABI (Application Binary Interface) von Rust. Sie verhindert spontane Aktualisierungen in einer reinen Rust-Umgebung. C-Prozesse profitieren dagegen von der Binärstabilität des C-Laufzeitmodells und reduzieren aktualisierungsbedingte Ausfallzeiten erheblich. Das funktioniert, weil die Tiles den Validator-Zustand in verschiedenen Arbeitsbereichen verwalten. Diese gemeinsam genutzten Speicherobjekte bleiben bestehen, solange der Validator eingeschaltet ist. Nach einem Neustart oder einer Aktualisierung kann jedes Tile die Verarbeitung nahtlos an der vorherigen Stelle fortsetzen.

Insgesamt basiert Firedancer auf einer NUMA-fähigen, Tile-basierten Architektur. Im nächsten Abschnitt erklären wir, was das bedeutet. Vorerst genügt: Sie stellt jedem Thread dedizierte Hardwareressourcen zur Verfügung. In dieser Architektur wird pro Tile ein CPU-Kern verwendet. Der hochleistungsfähige Nachrichtenaustausch zwischen den Tiles ist auf Speicherlokalität, Ressourcenanordnung und Komponentenlatenzen optimiert.

Netzwerkverarbeitung

Die Netzwerkverarbeitung von Firedancer ist darauf ausgelegt, die hohen Anforderungen des Solana-Netzwerks zu bewältigen, wenn es auf Geschwindigkeiten von mehreren Gigabit pro Sekunde skaliert. Dieser Prozess gliedert sich in ein- und ausgehende Aktivitäten.

Bei eingehenden Aktivitäten geht es hauptsächlich darum, Transaktionen von Nutzern zu empfangen. Die Leistung von Firedancer ist entscheidend, da Konsensnachrichten verloren gehen können, wenn ein Validator bei der Paketverarbeitung zurückfällt. Die aktuelle Betriebsbandbreite eines Solana-Knotens liegt bei ~0,2 Gbps, während die größte aufgezeichnete Spitze auf einem Jump-Knoten ~40 GBps betrug. Diese Bandbreitenspitze zeigt, dass eine robuste und skalierbare Lösung für die Eingangsverarbeitung nötig ist.

Zu den ausgehenden Aktivitäten gehören das Packen und Erstellen von Blöcken sowie das Senden von Shreds. Jeder dieser Schritte ist für den sicheren und effizienten Betrieb des Solana-Netzwerks entscheidend. Die Leistung dieser Aufgaben wirkt sich nicht nur auf den Durchsatz, sondern auch auf die allgemeine Zuverlässigkeit des Netzwerks aus.

Firedancer soll frühere Schwächen in Solanas Peer-to-Peer-Schnittstelle zur Verarbeitung von Transaktionen beheben. Ein großes Problem dieser Schnittstelle war in der Vergangenheit die fehlende Überlastungssteuerung für eingehende Transaktionen. Das führte am 14. September 2021 (17 Stunden) und am 30. April 2022 (7 Stunden) zu erheblichen Netzwerkausfällen.

Als Reaktion darauf hat Solana mehrere Netzwerk-Upgrades eingeführt, um hohe Transaktionslasten zuverlässig zu bewältigen. Firedancer folgt diesem Ansatz und setzt für seine Flusskontrolle auf QUIC. QUIC ist ein gemultiplextes Transportnetzwerkprotokoll und bildet die Grundlage von HTTP/3. Es spielt eine zentrale Rolle beim DDoS-Schutz und bei der Verwaltung des Netzwerkverkehrs. Allerdings übersteigen die Kosten in manchen Fällen den Nutzen. In Verbindung mit spezialisierter Hardware in Rechenzentren zur Abwehr von DDoS-Angriffen beseitigt QUIC den Anreiz, das Netzwerk mit Transaktionen zu überfluten.

Die 151-seitige QUIC-Spezifikation machte die Entwicklung erheblich komplexer. Da keine bestehende C-Bibliothek die Anforderungen des Teams an Lizenzierung, Leistung und Zuverlässigkeit erfüllte, entwickelte das Firedancer-Team eine eigene Implementierung. Die QUIC-Implementierung von Firedancer mit dem Spitznamen fd_quic führt optimierte Datenstrukturen und Algorithmen ein, um Speicherzuweisungen zu minimieren und eine Erschöpfung des Arbeitsspeichers zu verhindern.

Der maßgeschneiderte Netzwerk-Stack von Firedancer bildet den Kern seiner Verarbeitungsleistung. Der Stack wurde von Grund auf entwickelt, um Receive-Side Scaling (RSS) zu nutzen. RSS ist eine Form des hardwarebeschleunigten Netzwerklastenausgleichs, bei der der Netzwerkverkehr auf verschiedene CPU-Kerne verteilt wird, um die Netzwerkverarbeitung stärker zu parallelisieren. Jeder CPU-Kern verarbeitet mit minimalem Overhead einen Teil des eingehenden Datenverkehrs. Dieser Ansatz übertrifft den herkömmlichen softwarebasierten Lastenausgleich, da keine komplexen Scheduler, Sperren oder atomaren Operationen erforderlich sind.

Firedancer führt ein neues Framework für den Nachrichtenaustausch ein, mit dem sich eine Anwendung aus hochleistungsfähigen Tiles zusammensetzen lässt. Diese Tiles können das Kernel-Networking, das durch seine Socket-basierte Struktur eingeschränkt ist, mithilfe von AF_XDP umgehen. AF_XDP ist eine Adressfamilie, die für die leistungsstarke Paketverarbeitung optimiert wurde. Mit AF_XDP kann Firedancer direkt aus den Puffern der Netzwerkschnittstelle lesen.

Dieses Tile-System ermöglicht verschiedene Konzepte des Hochleistungsrechnens im Firedancer-Stack. Dazu gehören:

• NUMA-Unterstützung - NUMA (Non-Uniform Memory Access) ist eine Speicherarchitektur, bei der ein Prozessor schneller auf seinen eigenen Arbeitsspeicher als auf den Arbeitsspeicher eines anderen Prozessors zugreifen kann. Da Firedancer NUMA berücksichtigt, kann der Client den Arbeitsspeicher in Multiprozessorkonfigurationen effizient verwalten. Das ist für die Verarbeitung großer Transaktionsmengen wichtig, weil es die Nutzung der verfügbaren Hardwareressourcen optimiert.
• Cache-Lokalität - Cache-Lokalität bezeichnet die Nutzung von Daten, die sich bereits in einem Cache in Prozessornähe befinden. In der Regel handelt es sich um eine komplexe Form zeitlicher Lokalität, also kürzlich abgerufene Daten. Der Fokus auf Cache-Lokalität bedeutet bei Firedancer, dass Netzwerkdaten mit minimaler Latenz und maximaler Geschwindigkeit verarbeitet werden.
• Sperrfreie Parallelität - Sperrfreie Parallelität bezeichnet Algorithmen, die keine Sperrmechanismen wie Mutexe benötigen, um gleichzeitige Vorgänge zu verwalten. Dadurch kann Firedancer mehrere Netzwerkvorgänge parallel ausführen, ohne dass Sperren Verzögerungen verursachen. Sperrfreie Parallelität verbessert die Fähigkeit von Firedancer, viele Transaktionen gleichzeitig zu verarbeiten.
• Große Seitengrößen - Große Seitengrößen in der Speicherverwaltung erleichtern die Verarbeitung von Datensätzen, da sie Abfragen der Seitentabelle und eine mögliche Speicherfragmentierung reduzieren. Für Firedancer bedeutet das eine effizientere Speicherverwaltung. Das hilft bei der Verarbeitung großer Mengen an Netzwerkdaten.

Build-System

Das Build-System von Firedancer folgt einer Reihe von Leitprinzipien, die Zuverlässigkeit und Konsistenz gewährleisten. Es minimiert externe Abhängigkeiten und behandelt alle am Build-Prozess beteiligten Werkzeuge ebenfalls als Abhängigkeiten. Dazu gehört, jede Abhängigkeit einschließlich der Compiler auf eine exakte Version festzulegen. Ein entscheidender Aspekt dieses Systems ist die Isolierung der Umgebung während der Build-Schritte. Diese Umgebungsisolierung verbessert die Portabilität, da die Systemumgebung den Build-Prozess nicht beeinflusst.

Wie ist Firedancer so schnell?

Fortschrittliche Datenparallelität

Firedancer nutzt für kryptografische Aufgaben wie die Verifizierung von ED25519-Signaturen die fortschrittliche Datenparallelität moderner Prozessoren. Moderne CPUs bieten Single-Instruction-Multiple-Data-Anweisungen (SIMD), um mehrere Datenelemente gleichzeitig zu verarbeiten. Außerdem sind sie dafür optimiert, mehrere Anweisungen pro CPU-Zyklus auszuführen. Im Hinblick auf Fläche, Zeit und Energie ist es meist effizienter, eine einzelne Anweisung parallel auf ein Array oder einen Vektor von Datenelementen anzuwenden. Verbesserungen bei der parallelen Datenverarbeitung können den Durchsatz daher stärker steigern als eine höhere reine Verarbeitungsgeschwindigkeit.

Firedancer nutzt Datenparallelität unter anderem, um die Berechnung von Signaturverifizierungen zu optimieren. So lassen sich Arrays oder Vektoren von Datenelementen gleichzeitig verarbeiten, um den Durchsatz zu maximieren und die Latenz zu minimieren. Im Zentrum dieser ED25519-Implementierung steht die Arithmetik in Galois-Körpern. Diese Form der Arithmetik eignet sich besonders für kryptografische Algorithmen und binäre Berechnungen. In Galois-Körpern werden Operationen wie Addition, Subtraktion, Multiplikation und Division so definiert, dass sie zur binären Struktur von Computersystemen passen. Hier ist ein Beispiel für einen durch 23 definierten Galois-Körper:

Das einzige Problem: ED25519 verwendet einen durch 2255-19 definierten Galois-Körper. Stell dir die Körperelemente als Zahlen von 0 bis 2255-19 vor. So sehen die grundlegenden Operationen aus:

• x + y → schriftliche Addition mod 2255-19
• x - y → schriftliche Subtraktion mod 2255-19
• x * y → schriftliche Multiplikation mod 2255-19
• 1/x → x hoch 2255-21 mod 2255-19

Addition, Subtraktion und Multiplikation entsprechen nahezu uint256_t-Arithmetik (also Arithmetik mit vorzeichenlosen Ganzzahlen, bei der der größte Wert 2256-1 beträgt). Die Division ist schwer zu berechnen. Handelsübliche CPUs und GPUs unterstützen keine uint256_t-Arithmetik, geschweige denn „Fast-uint256_t-Arithmetik“ oder eine außergewöhnlich schwierige, ungewöhnliche Division. Bei der Implementierung und hochperformanten Ausführung dieser Arithmetik kommt es darauf an, wie gut wir sie emulieren können.

Die Implementierung von Firedancer zerlegt die Arithmetik, indem sie Zahlen flexibler betrachtet. Wenden wir die Prinzipien der schriftlichen Division und Multiplikation an, bei denen Überträge von einer Spalte zur nächsten weitergegeben werden, können wir diese Spalten parallel verarbeiten. Am schnellsten lässt sich diese Arithmetik emulieren, wenn ein uint256_t als sechs 43-Bit-Ziffern mit einem 9-Bit-„Übertrag“ dargestellt wird. Dadurch können CPUs vorhandene 64-Bit-Operationen nutzen, während genug Platz für Übertragsbits bleibt. Diese Anordnung der Zahlen reduziert häufige Übertragsweitergaben und ermöglicht Firedancer, große Zahlen effizienter zu verarbeiten.

Diese Implementierung nutzt Datenparallelität, indem sie die arithmetischen Berechnungen als parallelisierte Spaltensummen neu organisiert. Die parallele Verarbeitung der Spalten beschleunigt die gesamte Berechnung, da sie einen sonst sequenziellen Engpass in eine parallelisierbare Aufgabe verwandelt. Firedancer verwendet außerdem vektorisierte Befehlssätze wie AVX512 und dessen IFMA-Erweiterung (AVX512-IFMA). Mit diesen Befehlssätzen lässt sich die oben beschriebene Arithmetik in Galois-Körpern schneller und effizienter verarbeiten.

Die AVX512-beschleunigte Implementierung von Firedancer ist schnell. Auf einem einzelnen Kern eines Icelake-Servers mit 2,3 GHz erreicht sie pro Kerntakt mehr als die doppelte Leistung der Breakpoint-Demo von 2022. Die Implementierung bietet eine 100-prozentige Auslastung der Vektor-Lanes und massive Datenparallelisierung. Das Firedancer-Team zeigt damit erneut eindrucksvoll: Aufgrund der durch die Lichtgeschwindigkeit verursachten Verzögerungen ist es viel einfacher, unabhängige Aufgaben parallel auszuführen, als eine Aufgabe nach der anderen abzuarbeiten – selbst mit speziell entwickelter Hardware.

FPGAs für schnelle Netzwerkkommunikation nutzen

CPUs können pro Kern etwa ~30.000 Signaturverifizierungen pro Sekunde verarbeiten. Sie sind zwar energieeffizient, reichen für große Workloads aber nicht aus. Diese Einschränkung entsteht durch ihre sequenzielle Verarbeitung. GPUs steigern diese Kapazität auf etwa ~1 Million Verifizierungen pro Sekunde und Kern. Allerdings werden sie durch ihren hohen Stromverbrauch von rund ~300 W pro Einheit und die inhärente Latenz der Batch-Verarbeitung ausgebremst.

FPGAs sind die bessere Alternative. Sie erreichen den Durchsatz von GPUs, verbrauchen mit etwa 50 W pro FPGA aber deutlich weniger Strom. Auch ihre Latenz liegt unter den zehn Millisekunden von GPUs. Mit einer Latenz von ~200 Mikrosekunden bieten FPGAs eine wesentlich reaktionsschnellere Lösung für die Echtzeitverarbeitung. Anders als GPUs mit ihrer Batch-Verarbeitung verarbeiten FPGAs in Firedancer jede Transaktion einzeln als Stream. Durch den Einsatz von FPGAs erzielt Firedancer einen beeindruckenden Durchsatz von 8 Millionen Signaturen pro Sekunde bei einem Leistungsbudget von weniger als 400 W für 8 FPGAs.

Das Team präsentierte den Prozess zur Verifizierung von ED25519-Signaturen in Firedancer auf der Breakpoint 2022. Dieser Prozess umfasste mehrere Phasen, darunter die SHA-512-Berechnung in einer reinen RTL-Pipeline sowie verschiedene Prüfungen und Berechnungen in einer eigens entwickelten ECC-CPU-Prozessor-Pipeline. Im Grunde schrieb das Firedancer-Team einen Compiler und einen Assembler für den eigenen Prozessor, übernahm den Python-Code aus dem RFC (Request for Comments), führte ihn mit operatorüberladenen Objekten aus, um Maschinencode zu erzeugen, und führte diesen Maschinencode anschließend auf der ECC-CPU aus.

Wichtig ist, dass Firedancer einen Formfaktor im Stil eines AWS-Beschleunigers nutzt, um Robustheit und Netzwerkkonnektivität auszubalancieren. Diese Wahl löst Probleme bei der direkten Netzwerkanbindung – einer Funktion, die Cloud-Anbieter häufig einschränken. So integriert Firedancer seine fortschrittlichen Funktionen nahtlos innerhalb der Grenzen cloudbasierter Infrastruktur.

Verschiedene Operationen benötigen realen physischen Raum, nicht nur konzeptionellen Datenraum. Firedancer berücksichtigt das, indem es physische Komponenten strategisch nah beieinander und wiederverwendbar anordnet. Diese Konfiguration maximiert die Effizienz des FPGA. So erreicht Firedancer 8 Mio. TPS mit einem sieben Jahre alten FPGA in einer acht Jahre alten Maschine.

Reed-Solomon-Codierung für die Netzwerkkommunikation optimieren

Die grundlegende Herausforderung der Netzwerkkommunikation besteht darin, neue Transaktionen weltweit zu verbreiten. Die Punkt-zu-Punkt-Struktur des Internets, begrenzte Bandbreite und Latenzprobleme erschweren traditionelle Ansätze wie die direkte Übertragung über das Netzwerk. Die Verteilung von Daten in einer Ring- oder Baumstruktur löst diese Probleme teilweise, reicht aber nicht aus, da Datenpakete während der Übertragung verloren gehen können.

Die Reed-Solomon-Codierung löst diese Probleme elegant. Sie fügt der Datenübertragung Redundanz hinzu (also Paritätsinformationen), um verlorene Pakete wiederherzustellen. Das Konzept beruht auf dem Prinzip, dass zwei Punkte eine Gerade definieren und zwei beliebige Punkte auf dieser Geraden die ursprünglichen Datenpunkte wiederherstellen können. Indem man aus den Datenpunkten ein Polynom bildet und verschiedene Punkte dieser Funktion auf separate Pakete verteilt, lassen sich die ursprünglichen Daten rekonstruieren, solange der Empfänger mindestens zwei Pakete erhält.

Wir bilden ein Polynom, weil die traditionelle Geradengleichung (y = mx + b) rechenintensiv ist. Firedancer nutzt Lagrange-Polynome, eine spezielle Methode zur Konstruktion von Polynomen, um die Berechnung zu beschleunigen. Sie vereinfachen die Erstellung des Polynoms, das für die Reed-Solomon-Codierung benötigt wird. Außerdem wandeln sie den Prozess in ein effizienteres Matrix-Vektor-Produkt um, das auch für Polynome höherer Ordnung funktioniert. Diese Matrix ist stark strukturiert. Ihre Muster wiederholen sich rekursiv, sodass die erste Zeile des Musters die gesamte Matrix bestimmt. Dank dieser Struktur lässt sich alles schneller multiplizieren. Firedancer nutzt zur Multiplikation mit dieser Matrix einen in einem Artikel von 2016 vorgestellten O(n log n)-Ansatz, den schnellsten bekannten theoretischen Ansatz für die Reed-Solomon-Codierung. Im Vergleich zu traditionellen Methoden lassen sich Paritätsinformationen damit effizient berechnen:

• Mehr als ~120 Gbit/s/Kern bei der RS-Codierung
• Bis zu ~50 Gbit/s/Kern bei der RS-Decodierung
• Diese Werte werden mit den derzeitigen ~8 Gbit/s/Kern bei der RS-Codierung (rust-rse) verglichen

Mit diesem optimierten Ansatz für die Reed-Solomon-Codierung kann Firedancer Paritätsinformationen 14-mal schneller als mit traditionellen Methoden berechnen. Das ermöglicht eine schnelle und zuverlässige Codierung und Decodierung von Daten – entscheidend für hohen Durchsatz und niedrige Latenz auf globaler Ebene.

Wie wird Firedancer abgesichert?

Chancen

Alle Validatoren verwenden derzeit Software, die auf dem ursprünglichen Validator-Client basiert. Wenn Firedancer sich vom Solana-Labs-Client unterscheidet, kann es die Client- und Lieferkettenvielfalt von Solana verbessern. Dazu gehört, ähnliche Abhängigkeiten zu verwenden und den Client in Rust zu entwickeln.

Die Validator-Clients von Solana Labs und Jito laufen als einzelner Prozess. Eine monolithische Anwendung nachträglich abzusichern, sobald sie in Produktion läuft, ist schwierig. Validatoren mit diesen Clients müssten für spontane Sicherheitsupdates in reinem Rust heruntergefahren werden. Das Firedancer-Team kann seinen neuen Client dagegen von Anfang an mit einer sicheren Architektur entwickeln.

Firedancer profitiert außerdem von bisherigen Erfahrungen. Solana Labs entwickelte den Validator-Client in einem Startup-Umfeld. In diesem schnelllebigen Umfeld musste Labs schnell handeln, um das Produkt rasch auf den Markt zu bringen. Das schuf schlechte Voraussetzungen für die weitere Entwicklung. Das Firedancer-Team kann analysieren, was Labs und Teams anderer Chains getan haben, und fragen, was sie anders machen würden, wenn sie einen Validator-Client von Grund auf neu entwickeln könnten.

Herausforderungen

Obwohl Firedancer sich vom Solana-Labs-Client unterscheidet, muss es dessen Verhalten genau nachbilden. Andernfalls entsteht ein Sicherheitsrisiko, da Inkompatibilitäten Konsensfehler verursachen könnten. Dieses Risiko lässt sich mindern, indem ein Teil des Stakes Anreize erhält, beide Clients zu nutzen, während Firedancer über einen längeren Zeitraum unter 33 % des gesamten Stakes bleibt. Unabhängig davon muss das Firedancer-Team den vollständigen Funktionsumfang des Protokolls implementieren – egal, wie schwierig eine korrekte und sichere Umsetzung ist. Alles muss auf Firedancer abgestimmt sein. Das Team kann den Code daher nicht isoliert entwickeln, sondern muss ihn mit der Funktionalität des Labs-Clients abgleichen. Fehlende Spezifikationen und Dokumentation verschärfen das Problem und zwingen Firedancer, ineffiziente Konstruktionen aus dem Protokoll zu übernehmen.

Das Firedaner-Team muss außerdem beachten, dass es seinen neuen Client in C entwickelt. C bietet nicht nativ die Garantien für Speichersicherheit, die Sprachen wie Rust bereitstellen. Ein Hauptziel der Firedancer-Codebasis ist es, Speichersicherheitslücken seltener zu machen und ihre Auswirkungen zu begrenzen. Dieses Ziel erfordert besondere Aufmerksamkeit, weil Firedancer sich schnell entwickelt. Firedancer muss das Entwicklungstempo halten, ohne solche Fehler einzuführen. Beim OS-Sandboxing werden die Tiles vom OS isoliert. Tiles dürfen nur auf Ressourcen zugreifen und Systemaufrufe ausführen, die sie für ihre Aufgabe benötigen. Da Tiles einen klar definierten Zweck haben und das Firedancer-Team den größten Teil des Client-Codes entwickelt hat, werden die Berechtigungen eines Tiles nach dem Prinzip der geringsten Rechte auf das Nötigste beschränkt.

Mehrschichtige Verteidigung implementieren

Jede Software wird irgendwann eine Sicherheitslücke enthalten. Ausgehend von der Annahme, dass Software Fehler haben wird, begrenzt Firedancer die möglichen Auswirkungen jeder einzelnen Schwachstelle. Dieser Ansatz heißt Defense in Depth, also mehrschichtige Verteidigung. Dabei schützen verschiedene Sicherheitsmaßnahmen ein Asset. Kompromittiert ein Angreifer einen Teil des Systems, verhindern zusätzliche Maßnahmen, dass die Bedrohung den gesamten Stack betrifft. Firedancer soll den Übergang von einer Schwachstelle zu einem Exploit erschweren. Für einen Angreifer wäre es beispielsweise schwierig, eine Speichersicherheitslücke auszunutzen.

Denn die Abwehr solcher Angriffe ist gut erforscht. Die umfangreiche Forschung zur Speichersicherheit in C hat zahlreiche Härtungstechniken und Compiler-Funktionen hervorgebracht, die das Team für Firedancer nutzt. Selbst wenn ein Angreifer bewährte Branchenpraktiken umgehen könnte, wäre es schwierig, mit dem Exploit das System zu kompromittieren. Dafür sorgen die Tile-Isolation und das OS-Sandboxing.

Die Tile-Isolation ergibt sich aus der parallelen Architektur von Firedancer. Jedes Tile hat einen klaren, einzigen Zweck, da es als eigener Linux-Prozess ausgeführt wird. Ein QUIC-Tile verarbeitet beispielsweise eingehenden QUIC-Datenverkehr und leitet die darin enthaltenen Transaktionen an das Verify-Tile weiter. Das Verify-Tile übernimmt anschließend die Signaturverifizierung. QUIC- und Verify-Tile kommunizieren über eine Shared-Memory-Schnittstelle (Linux-Prozesse können darüber Daten austauschen). Diese Shared-Memory-Schnittstelle zwischen zwei Tiles dient als Isolationsgrenze. Hätte das QUIC-Tile einen Fehler, durch den ein Angreifer beim Verarbeiten eines schädlichen QUIC-Pakets beliebigen Code ausführen könnte, wären andere Tiles davon nicht betroffen. In einem monolithischen Prozess wäre das System sofort kompromittiert. Nutzt ein Angreifer diese Schwachstelle bei mehreren Validatoren aus, könnte er dem gesamten Netzwerk schaden. Er könnte möglicherweise die Leistung des QUIC-Tiles beeinträchtigen, doch das Design von Firedancer beschränkt ihn auf dieses Tile.

Beim OS-Sandboxing werden die Tiles vom OS isoliert. Tiles dürfen nur auf Ressourcen zugreifen und Systemaufrufe ausführen, die sie für ihre Aufgabe benötigen. Da Tiles einen klar definierten Zweck haben und fast der gesamte Code vom Firedancer-Team entwickelt wurde, werden die Berechtigungen eines Tiles nach dem Prinzip der geringsten Rechte auf das Nötigste beschränkt. Tiles befinden sich in eigenen Linux-Namespaces und sehen daher nur einen begrenzten Teil des Systems. Diese eingeschränkte Sicht verhindert, dass ein Tile auf den Großteil des Dateisystems, das Netzwerk oder andere Prozesse im selben System zugreift. Namespaces schaffen eine auf Sicherheit ausgerichtete Grenze. Ein Angreifer mit einem Kernel-Exploit zur Rechteausweitung könnte sie jedoch weiterhin umgehen. Die Systemaufruf-Schnittstelle ist der letzte Angriffsvektor im Kernel, den Tiles erreichen können. Zum Schutz verwendet Firedancer seccomp-BPF, um Systemaufrufe zu filtern, bevor der Kernel sie verarbeitet. Der Client kann Tiles auf eine ausgewählte Gruppe von Systemaufrufen beschränken. In einigen Fällen lassen sich auch die Parameter von Systemaufrufen filtern. Das ist wichtig, weil Firedancer so sicherstellen kann, dass Lese- und Schreibaufrufe nur bestimmte Dateideskriptoren verwenden.

Ein integriertes Sicherheitsprogramm implementieren

Firedancer wird mit einem umfassenden Sicherheitsprogramm entwickelt, das in jeder Entwicklungsphase fest verankert ist. Das Sicherheitsprogramm des Clients beruht auf einer fortlaufenden Zusammenarbeit zwischen Entwicklungs- und Sicherheitsteams und setzt einen neuen Standard für sichere Blockchain-Technologie.

Der Prozess beginnt mit einer Self-Service-Infrastruktur für Fuzzing. Fuzzing ist eine Technik, die automatisch Abstürze oder Fehlerzustände erkennt, die auf Schwachstellen hinweisen. Dazu wird jede Komponente, die nicht vertrauenswürdige Benutzereingaben akzeptiert, einem Stresstest unterzogen. Das umfasst die P2P-Schnittstelle (Parser) und die virtuelle SBPF-Maschine. OSS-Fuzz stellt bei Codeänderungen eine kontinuierliche Fuzz-Abdeckung sicher. Das Sicherheitsteam hat außerdem eine eigene ClusterFuzzer-Instanz für kontinuierliches, abdeckungsgesteuertes Fuzzing eingerichtet. Entwickler und Sicherheitsingenieure tragen auch Fuzzing-Harnesses bei (spezielle Versionen von Unit-Tests für sicherheitskritische Komponenten). Entwickler können zudem neue Fuzz-Tests hinzufügen, die automatisch übernommen und ausgeführt werden. Das Ziel: Alle Teile werden intensiv getestet, bevor sie in die nächste Phase wechseln.

Interne Code-Reviews helfen dabei, Fehler zu erkennen, die den Tools entgangen sind. In dieser Phase liegt der Fokus auf Komponenten mit hohem Risiko und großen potenziellen Auswirkungen. Die Phase dient als Feedbackmechanismus für das gesamte Sicherheitsprogramm. Das Team wendet alle gewonnenen Erkenntnisse an und nutzt diese Reviews, um die Fuzzing-Abdeckung zu verbessern, neue Prüfungen der statischen Analyse für bestimmte Fehlerklassen einzuführen und sogar umfangreiche Code-Refactorings umzusetzen, die komplexe Angriffsvektoren strukturell beseitigen. Externe Sicherheitsprüfungen durch führende Branchenexperten und ein aktives Bug-Bounty-Programm ergänzen diese internen Reviews vor und nach dem Launch.

Firedancer wurde außerdem umfangreichen Stresstests in verschiedenen Testnetzwerken unterzogen. Diese Testnetzwerke werden Angriffen und Ausfällen ausgesetzt, darunter duplizierte Nodes, ausgefallene Netzwerkverbindungen, Paketfluten und Konsensverletzungen. Die Netzwerke bewältigen dabei deutlich höhere Lasten als in jedem realistischen Mainnet-Szenario.

Das führt uns zur Frage: Wie ist der aktuelle Stand von Firedancer?

Wie ist der aktuelle Stand von Firedancer und was ist Frankendancer?

Das Firedancer-Team entwickelt Firedancer schrittweise, um den Validator-Client zu modularisieren. Das entspricht seinen Zielen für Dokumentation und Standardisierung. Dieser Ansatz hält Firedancer mit den neuesten Entwicklungen von Solana auf dem aktuellen Stand. So entstand Frankendancer. Frankendancer ist ein hybrides Client-Modell, bei dem das Firedancer-Team seine entwickelten Komponenten in die bestehende Infrastruktur des Validator-Clients integriert. Dieser Entwicklungsprozess ermöglicht es, neue Funktionen schrittweise zu verbessern und zu testen.

Frankendancer ist wie ein Sportwagen mitten im Straßenverkehr. Die Leistung steigt, wenn weitere Komponenten entwickelt und Engpässe beseitigt werden. Dieser modulare Entwicklungsprozess schafft eine anpassbare und flexible Validator-Umgebung. Entwickler können bestimmte Komponenten ihres Validator-Clients ändern oder ersetzen, um ihn an ihre Anforderungen anzupassen.

Was läuft tatsächlich?

Frankendancer implementiert alle Netzwerkfunktionen eines Solana-Validators:

• Eingehend: QUIC, TPU, Sigverify, Dedup
• Ausgehend: Block-Packing, Shreds erstellen/signieren/senden (Turbine)

Frankendancer verwendet den hochperformanten C-Netzwerkcode von Firedancer zusammen mit dem Rust-Runtime- und Konsenscode von Solana Labs.

Die Architektur von Frankendancer ist auf die Optimierung für High-End-Hardware ausgelegt. Sie unterstützt einfache Standard-Cloud-Hosts mit üblichen Linux-Betriebssystemen, doch das Firedancer-Team optimiert Frankendancer für Server mit vielen Kernen. Langfristig soll bereits in der Cloud verfügbare Hardware genutzt werden, um Effizienz und Leistung zu steigern. Der Client unterstützt mehrere gleichzeitige Verbindungen, Hardwarebeschleunigung, randomisiertes Flow Steering zur Lastverteilung (also zur gleichmäßigen Verteilung des Netzwerkverkehrs) und zahlreiche Prozessgrenzen für zusätzliche Sicherheit zwischen den Komponenten.

Technische Effizienz ist ein Grundpfeiler von Frankendancer. Das System vermeidet Speicherallokationen und atomare Operationen im kritischen Pfad. Bei der Initialisierung werden alle Allokationen für NUMA optimiert. Dieses Design maximiert Effizienz und Leistung. Systemkomponenten lassen sich außerdem asynchron und aus der Ferne prüfen. Zusammen mit der flexiblen Verwaltung von Tiles – asynchrones Starten, Stoppen und Neustarten – macht das das System robuster und anpassungsfähiger.

Wie leistungsfähig ist Frankendancer?

Frankendancer kann auf der eingehenden Netzwerkseite pro Tile 1.000.000 Transaktionen pro Sekunde (TPS) verarbeiten. Da jedes Tile einen CPU-Kern nutzt, skaliert diese Leistung linear mit der Anzahl der verwendeten Kerne. Frankendancer erreichte diesen Wert mit nur vier Kernen und lastete dabei eine Netzwerkkarte (NIC) mit 25 Gbit/s vollständig aus.

Mit seinen Turbine-Optimierungen hat Frankendancer ausgehende Netzwerkoperationen deutlich verbessert. Heutige Standard-Node-Hardware erreicht 6 Gbit/s pro Tile. Dazu gehören erhebliche Geschwindigkeitssteigerungen beim Shredding, also beim Aufteilen und Versenden von Blockdaten an Validatoren im Netzwerk. Verglichen mit heutigen Standard-Nodes von Solana erhöht Frankendancer die Shredding-Geschwindigkeit ohne Merkle-Bäume um ~22 % und mit Merkle-Bäumen auf fast das Doppelte. Das verbessert die aktuelle Blockverteilung und Transaktionsaufnahme heutiger Validatoren massiv.

Die Netzwerkleistung von Firedancer zeigt, dass das Hardwarelimit erreicht ist. Mit heutiger Standardhardware für Validatoren erzielt Firedancer die maximal mögliche Leistung. Das ist ein wichtiger technischer Meilenstein und demonstriert, dass der Client extreme Workloads effizient und zuverlässig bewältigen kann.

Frankendancer läuft live im Testnet

Frankendancer ist derzeit im Testnet gestakt, stimmt ab und produziert Blöcke. Es arbeitet kompatibel mit ~2900 anderen Validatoren von Solana Labs und Jito zusammen. Diese Live-Bereitstellung demonstriert die robuste Leistung von Firedancer auf handelsüblicher Hardware. Aktuell läuft es auf einem Equinix-Metal-Server vom Typ m3.large.x86 mit einer AMD EPYC 7513 CPU. Viele andere Validatoren verwenden denselben Servertyp. Er bietet eine kosteneffiziente Lösung mit standortabhängigen On-Demand-Preisen. Die Preise reichen von 3,10 bis 4,65 US-Dollar pro Stunde.

Die Fortschritte von Firedancer auf dem Weg zum Mainnet-Launch eröffnen mehrere Möglichkeiten für Node-Hardware:

• Aktuelle Validator-Hardware kann pro Node eine deutlich höhere Leistungskapazität bieten
• Dank der Effizienz von Firedancer können Validatoren günstigere Hardware mit niedrigeren Spezifikationen verwenden und dabei ein ähnliches Leistungsniveau halten
• Das Design von Firedancer ermöglicht es, Fortschritte bei Hardware und Bandbreite zu nutzen

Diese Entwicklungen und weitere Initiativen wie Wiredancer (die Experimente des Firedancer-Teams mit Hardwarebeschleunigung) sowie eine modulare, Rust-basierte Runtime/SVM machen Firedancer zu einer zukunftsorientierten Lösung.

Die Fortschritte von Firedancer stoßen außerdem Diskussionen darüber an, ob Validatoren den Solana-Labs-Client parallel zu Firedancer in einem als Side-Caring bezeichneten Prozess ausführen könnten. Dieser Ansatz könnte die Verfügbarkeit des Netzwerks maximieren, indem er die Stärken beider Clients nutzt und die möglichen Auswirkungen von Problemen in einem Client auf das gesamte Netzwerk begrenzt. Zudem entsteht die Frage, ob Projekte wie Jito einen Fork von Firedancer in Betracht ziehen würden. Das könnte zu weiteren Optimierungen bei der MEV-Extraktion und der Effizienz der Transaktionsverarbeitung führen. Die Zukunft wird es zeigen.

Fazit

Entwickler betrachten Operationen meist als Verbraucher von Datenraum statt physischem Raum. Da die Lichtgeschwindigkeit eine natürliche Grenze setzt, führt diese Annahme zu langsamen Systemen, die ihre Hardware nicht richtig optimieren. In einem stark umkämpften und kompetitiven Umfeld dürfen wir Solana nicht einfach mit mehr Hardware ausstatten und eine bessere Leistung erwarten. Wir müssen optimieren. Firedancer revolutioniert, wie Validator-Clients aufgebaut sind und arbeiten. Das Firedancer-Team entwickelt einen zuverlässigen, hochgradig modularen und leistungsstarken Validator-Client und bereitet Solana damit auf die breite Nutzung vor.

Egal, ob du gerade erst mit der Entwicklung beginnst oder Solana durchschnittlich nutzt: Du solltest Firedancer und seine Bedeutung verstehen. Diese technologische Meisterleistung verbessert die derzeit schnellste und leistungsfähigste Blockchain auf dem Markt noch weiter. Solana ist als globale Zustandsmaschine mit hohem Durchsatz und niedriger Latenz konzipiert. Firedancer ist ein großer Schritt, um diese Ziele zu perfektionieren.

Wenn du bis hierhin gelesen hast: Danke, Anon! Trag unten unbedingt deine E-Mail-Adresse ein, damit du keine Neuigkeiten zu Solana verpasst. Willst du tiefer einsteigen? Tritt unserem Discord bei und entwickle noch heute die Zukunft auf der leistungsfähigsten Blockchain.

Zusätzliche Ressourcen und weiterführende Literatur

• Website von Jump
• Firedancer-Repository auf GitHub
• Breakpoint 2023: Firedancer-Update
• Breakpoint 2023: Firedancer absichern
• Breakpoint 2023: Schnelle Reed-Solomon-Codierung für die Netzwerkkommunikation
• Breakpoint 2023: FPGA mit 8 Mio. TPS
• Technischer Meilenstein von Firedancers fd_quic
• Upgrades des Solana-Netzwerks

Anhang

Einführung in Computerhardware und Netzwerke

Ein Computer ist eine Maschine, die sich so programmieren lässt, dass sie Abfolgen arithmetischer oder logischer Operationen automatisch ausführt. Diese Operationen reichen von der Automatisierung einfacher Berechnungen bis zur komplexen Datenverarbeitung. Im Kern kombiniert ein Computer Hardware- und Softwarekomponenten, um Anweisungen auszuführen und Daten zu verwalten. Die Hardware umfasst die physischen Komponenten. Zur Software gehören Programme und Betriebssysteme, die der Hardware vorgeben, wie sie arbeiten soll.

Nützliche Berechnungen erfordern im Allgemeinen vier Ressourcen: Rechenleistung, Arbeitsspeicher, Datenträgerspeicher und Netzwerk. Die Rechenarbeit übernehmen hauptsächlich CPUs, GPUs und möglicherweise FPGAs. Sie sind extrem schnell und können Milliarden Operationen pro Sekunde ausführen. Der Zugriff auf RAM ist in der Regel langsamer als eine Berechnung in der CPU. Datenträgerspeicher bietet eine langfristige Speicherlösung für Berechnungen. Der Zugriff auf Daten in Solid-State-Laufwerken (SSDs) und Festplattenlaufwerken (HDDs) ist jedoch wesentlich langsamer als CPU-Operationen. SSDs sind oft Tausende Male langsamer, HDDs Zehntausende Male. Das Netzwerk, einschließlich Internet und lokaler Netzwerke, ist noch langsamer. Es kann mehr als eine Million Mal langsamer als die CPU sein.

Du musst diese Geschwindigkeitsunterschiede verstehen, um die Designprinzipien und Effizienzüberlegungen bei Hochleistungsanwendungen wie Firedancer nachvollziehen zu können. Die Rechengeschwindigkeit der CPU bildet die Basis. Arbeitsspeicher, Datenträgerspeicher und Netzwerkzugriff verursachen jeweils zusätzliche Verzögerungen, wobei ihre Geschwindigkeit in dieser Reihenfolge abnimmt.

Zentrale Verarbeitungseinheit (CPU)

Die CPU, also die zentrale Verarbeitungseinheit, ist der Grundpfeiler der Computerfunktionalität – sie ist das Gehirn der Maschine. Die CPU führt Softwareanweisungen aus, nimmt Berechnungen vor und trifft auf Grundlage ihrer Eingaben Entscheidungen. Dazu verarbeitet sie binäre Signale, also Folgen aus Nullen und Einsen. Jede eindeutige Folge von Binärcodes entspricht einer bestimmten Anweisung, die die CPU interpretiert und ausführt. Sie verarbeitet diese Anweisungen nacheinander und schließt eine Operation ab, bevor sie mit der nächsten beginnt. Diese sequenzielle Verarbeitung von Anweisungen ist für die Rolle der CPU entscheidend. Sie bestimmt, wie die CPU komplexe Berechnungen ausführt und anhand ihrer Eingaben Entscheidungen trifft.

Moderne CPUs haben oft mehrere Kerne. Das bedeutet, dass ein einzelner Chip mehrere Verarbeitungseinheiten enthält, die als Kerne bezeichnet werden. Jeder Kern kann Anweisungen unabhängig ausführen und ermöglicht dadurch die parallele Verarbeitung von Aufgaben. Eine Mehrkernarchitektur verbessert die Fähigkeit der CPU, Operationen gleichzeitig zu verarbeiten, und erhöht die Gesamtleistung deutlich. Innerhalb jedes Kerns werden Operationen jedoch weiterhin sequenziell verarbeitet. CPUs eignen sich deshalb gut für komplexe, sequenzielle Aufgaben, sind aber bei großen Mengen einfacherer, paralleler Aufgaben ineffizient.

CPUs verfügen außerdem über Caches – kleine Hochgeschwindigkeitsspeicher innerhalb der CPU. Diese Caches speichern häufig verwendete Daten und Anweisungen. Dadurch lassen sie sich schneller abrufen als aus dem RAM. Üblicherweise gibt es mehrere Cache-Ebenen (L1, L2, L3 und manchmal L4), die sich in Größe und Geschwindigkeit unterscheiden. Auf den kleinsten und schnellsten L1-Cache greift die CPU zuerst zu. Sind die benötigten Daten dort nicht vorhanden, prüft sie den größeren, etwas langsameren L2-Cache und so weiter. Dieses hierarchische Cache-System verkürzt die Wartezeit der CPU auf Daten aus dem RAM und erhöht die gesamte Verarbeitungsgeschwindigkeit. Eine effiziente Cache-Nutzung hat weitreichende Auswirkungen auf Anwendungen wie Firedancer, bei denen die Entfernung zwischen CPU und RAM die Leistung beeinträchtigen kann. Das ist besonders für unsere Betrachtung der Lichtgeschwindigkeit und des Einsatzes von FPGAs relevant.

Nebenbei bemerkt: Der Begriff „x86“ bezeichnet eine CPU-Familie, die einer bestimmten, ursprünglich von Intel entwickelten Architektur folgt. Diese Architektur ist für ihre Kompatibilität mit einer großen Bandbreite an Software bekannt, da die meisten verkauften Desktop- und Laptop-Computer auf der x86-Architekturfamilie basieren.

Grafikprozessor (GPU)

Die GPU ist ein spezialisierter Prozessor, der ursprünglich entwickelt wurde, um das Rendern von Bildern und Videos für Computergrafiken zu beschleunigen. Ihre Hauptaufgabe besteht darin, die Grafikleistung zu verwalten und zu verbessern. Das gilt besonders für Aufgaben, die hochauflösende Darstellungen und komplexe Grafikberechnungen erfordern, etwa Videospiele oder 3D-Modellierung.

Im Laufe der Zeit hat sich die GPU über ihren ursprünglichen Zweck hinaus weiterentwickelt. Aufgrund ihrer Architektur sind GPUs heute für ein breiteres Spektrum an Datenverarbeitungsaufgaben unverzichtbar. Ihre Fähigkeit zur effizienten Parallelverarbeitung eignet sich für Anwendungen, die große Datensätze gleichzeitig verarbeiten müssen. In der Blockchain-Technologie werden GPUs häufig für das Mining von Kryptowährungen eingesetzt. Sie eignen sich dafür besonders gut, weil sie parallele Arbeitslasten kryptografischer Berechnungen effizienter als eine CPU verarbeiten können.

Arbeitsspeicher (RAM)

RAM ist der Kurzzeitspeicher eines Computers. Er speichert Daten, die gerade verwendet oder verarbeitet werden. Dort „merkt“ sich die CPU, woran sie aktuell arbeitet, und hält relevante Informationen für den schnellen Zugriff und die Verarbeitung bereit.

RAM mit Error-Correcting Code (ECC) kann häufige Arten interner Datenbeschädigungen erkennen und korrigieren. Diese Funktion ist in Umgebungen entscheidend, in denen die Datengenauigkeit wichtig ist, etwa bei wissenschaftlichen Berechnungen, Finanztransaktionen oder Blockchain-Nodes. ECC-RAM kann kleinere Fehler in den gespeicherten Daten automatisch erkennen und beheben. Zusätzliche Hardware in den RAM-Modulen prüft dafür die gespeicherten Daten.

Nicht-ECC-RAM ist der häufiger verwendete Speichertyp in Standardcomputern und Endgeräten. Ihm fehlen zwar die Fehlerkorrekturfunktionen von ECC-RAM, dafür ist er im Allgemeinen schneller und günstiger. Nicht-ECC-RAM wird aufgrund seiner Kosteneffizienz und des relativ geringen Risikos von Datenfehlern bei üblichen Desktop-Anwendungen bevorzugt.

Datenträgerspeicher

Datenträgerspeicher bewahrt Daten langfristig auf, selbst wenn ein Computer ausgeschaltet ist. Es gibt zwei primäre Arten von Datenträgerspeichern: Festplattenlaufwerke (HDDs) und Solid-State-Laufwerke (SSDs).

HDDs sind ältere Laufwerke, die Daten auf magnetischen Scheiben speichern, den sogenannten Plattern. Diese Platter werden mit Magnetköpfen kombiniert, die meist an einem beweglichen Aktuatorarm befestigt sind. Ein Lese-/Schreibkopf an diesem Arm greift auf die Daten zu, während sich die Scheibe dreht. Aufgrund ihrer mechanischen Funktionsweise – drehende Scheiben und bewegliche Köpfe – sind HDDs relativ langsam im Vergleich zu SSDs. Sie bieten jedoch mehr Speicherkapazität zu einem niedrigeren Preis. Dadurch sind sie eine kosteneffiziente Lösung für Massenspeicher.

SSDs speichern Daten dagegen in Flash-Speicher. Flash-Speicher ist eine elektronische, nichtflüchtige Speicherlösung, die gelöscht und neu programmiert werden kann. Anders als bei HDDs sind dabei keine beweglichen Teile erforderlich. Stattdessen speichern miteinander verbundene Flash-Speicherchips die Daten. SSDs sind schneller als HDDs, weil sie sofort auf Daten zugreifen können. Sie müssen weder darauf warten, dass sich eine Scheibe dreht, noch dass ein Lese-/Schreibkopf die Daten findet. Diese Geschwindigkeit macht SSDs zu einer hervorragenden Wahl für Anwendungen, bei denen ein schneller Datenabruf entscheidend ist. Pro Gigabyte kosten sie jedoch mehr als HDDs.

Daneben gibt es NVMe-SSDs (Non-Volatile Memory Express). Diese SSDs sind darauf ausgelegt, ihr Hochgeschwindigkeitspotenzial über den Peripheral-Component-Interconnect-Express-Bus (PCIe) eines Computers auszuschöpfen. NVMe-Laufwerke bieten deutlich höhere Geschwindigkeiten und geringere Latenzen als herkömmliche SSDs. Sie eignen sich ideal für intensive Arbeitslasten wie Hochfrequenzhandel und Blockchain-Anwendungen, bei denen die schnelle Verarbeitung und Abfrage von Daten entscheidend ist. NVMes haben zwar einen höheren Preis, entwickeln sich aber zunehmend zum Standard für Hochleistungsrechner.

Mainboard

Quelle: Diagramm eines Gigabyte X570 Elite aus einem Reddit-Beitrag auf r/buildapc

Das Mainboard eines Computers ist eine große Leiterplatte, die die einzelnen Computerkomponenten miteinander verbindet und ihre Kommunikation ermöglicht. Zu diesen Komponenten gehören CPU, GPU, RAM, Speichergeräte und Peripheriegeräte wie Tastaturen und Mäuse.

Das Mainboard ist der zentrale Knotenpunkt aller Aktivitäten. Es stellt sicher, dass sämtliche Komponenten effektiv miteinander kommunizieren können. Außerdem spielt es eine entscheidende Rolle bei der Stromverteilung, indem es Elektrizität vom Netzteil zu allen wichtigen Komponenten leitet. Das Mainboard sorgt dafür, dass jede Komponente die für ihren Betrieb erforderliche Energie erhält.

Das Mainboard verwaltet den Datenfluss innerhalb des Systems. Es steuert die Weiterleitung von Daten von der CPU zum RAM zur Verarbeitung, vom RAM zu Speichergeräten zur Speicherung und von der GPU zu den Bildschirmausgängen für die visuelle Darstellung. Außerdem beherbergt das Mainboard das BIOS (Basic Input/Output System) des Systems. Das BIOS ist für die Systemsteuerung und -überwachung unverzichtbar. Es initialisiert und testet die Hardware eines Computers beim Start. Darüber hinaus überwacht es den Zustand des Systems, darunter Temperatur, Spannung und Lüfterdrehzahlen.

Für das Design von Firedancer spielt die Architektur des Mainboards eine zentrale Rolle. Die Nähe zwischen CPU und RAM wirkt sich erheblich auf die Leistung aus, da kürzere Distanzen die Datenübertragung beschleunigen. Diese Distanz ist für Anwendungen wie Firedancer entscheidend, die einen hohen Durchsatz und eine niedrige Latenz erfordern. Deshalb passen eine NUMA-bewusste Architektur und der potenzielle Einsatz von FPGAs zu Firedancers Anforderungen an eine optimierte Speicherzuweisung und Verarbeitungseffizienz. Was NUMA-bewusst bedeutet und was FPGAs sind, behandeln wir später in diesem Artikel.

Betriebssysteme, virtuelle Maschinen und Optimierungen auf Kernel-Ebene

Ein Betriebssystem (OS) ist die zentrale Software, die Hardware und Software in einem Computer verwaltet. Es dient als Vermittler und ermöglicht die Interaktion zwischen dem Benutzer und der Computerhardware. Es stellt eine Oberfläche für die Interaktion mit dem System bereit und weist verschiedenen Anwendungen Ressourcen zu und verwaltet sie. Bekannte Beispiele sind Windows, macOS und Linux.

Der Kernel bildet das Herzstück jedes Betriebssystems. Er ist eine entscheidende Komponente, die direkt mit der Systemhardware interagiert. Der Kernel hat die vollständige Kontrolle über alles im System. Er verwaltet die Speicherzuweisung, die Prozessplanung und Ein-/Ausgabeanfragen. Da er auf dieser niedrigen Ebene arbeitet, spielt der Kernel eine zentrale Rolle für die Leistung und Stabilität des Systems.

Systemaufrufe (Syscalls) bilden die Schnittstelle zwischen Benutzeranwendungen und dem Kernel. Muss eine Anwendung eine Operation ausführen, die Zugriff auf eine Systemressource erfordert – etwa das Lesen einer Datei oder das Senden von Netzwerkdaten –, führt sie einen Syscall aus. Der Kernel übernimmt dann die angeforderte Operation für die Anwendung. Dieser Mechanismus sorgt für einen kontrollierten Zugriff auf Systemressourcen und gewährleistet so die Sicherheit und Stabilität des Systems.

Virtuelle Maschinen (VMs) sind Softwareemulationen physischer Computer. Sie bilden die vollständige Funktionalität eines physischen Computers in einer isolierten Umgebung nach und laufen dabei auf einem Hypervisor. Das ist eine Software, die virtuelle Umgebungen auf einem Host-Rechner erstellt und verwaltet. VMs bieten durch Isolation mehr Sicherheit sowie Ressourceneffizienz und Flexibilität für Tests und Entwicklung.

Im Zusammenhang mit Firedancer ist es entscheidend, diese Konzepte zu verstehen. Firedancer nutzt mehrere Optimierungen auf Kernel-Ebene, um die Leistung zu steigern:

• Große statische Zuweisung: Firedancer minimiert dynamische Speicherzuweisungen durch große statische Zuweisungen, also gemeinsam genutzte Speicherbereiche, auf die andere Prozesse zugreifen können. Dabei wird der Speicher einmal zugewiesen und anschließend wiederverwendet. Das reduziert den Aufwand häufiger Zuweisungen und Freigaben.
• Umgehung von Standardbibliotheken: Funktionen aus Standardbibliotheken fügen oft zusätzliche Abstraktionsebenen hinzu und können bei bestimmten Operationen weniger effizient sein. Firedancer umgeht diese Standardbibliotheken und führt Syscalls direkt aus. Darauf gehen wir genauer ein, wenn wir Firedancers Tile-Architektur und die Optimierung seiner Netzwerkleistung behandeln.

Firedancer versucht, Syscalls und Interaktionen mit dem OS so weit wie möglich zu vermeiden, da diese Operationen Aufgaben erheblich verlangsamen.

Ingress und Egress

Ingress und Egress bezeichnen den Datenfluss in ein Computersystem oder Netzwerk hinein und aus ihm heraus.

Ingress bezeichnet den Eingang von Daten in ein System. Der allgemeine Begriff umfasst verschiedene Aktivitäten, etwa das Empfangen von Daten aus dem Internet, das Annehmen von Benutzereingaben oder das Erfassen von Informationen über Sensoren in IoT-Geräten (Internet of Things). Bei Netzwerksystemen wie Servern oder Blockchains umfasst Ingress wichtige Aufgaben wie den Empfang von Transaktionsanfragen, Benutzerabfragen oder eingehenden Datenströmen, die verarbeitet oder gespeichert werden müssen. Die effiziente Verarbeitung eingehender Daten ist für die Reaktionsfähigkeit und Funktionalität des Systems entscheidend.

Egress bezeichnet die aus einem System ausgehenden Daten. Dazu gehören das Online-Senden von Informationen, das Erzeugen von Antworten auf Benutzeranfragen und die Übertragung verarbeiteter Daten an andere Systeme. Bei vernetzten Systemen umfasst Egress das Senden validierter Transaktionen, die Übertragung von Blockchain-Updates und das Senden von Daten an externe Speicherorte. Die korrekte Verwaltung ausgehender Daten ist entscheidend, um Informationen richtig zu verteilen und eine effektive Kommunikation des Systems mit anderen Teilen des Netzwerks sicherzustellen.

Pipelines und Datenparallelität

Stell dir eine Pipeline wie ein Fließband in einer Fabrik vor. Sie zerlegt einen komplexen Prozess in kleinere, sequenzielle Stufen. Jede Pipeline-Stufe führt eine bestimmte Operation aus. Dieser Ansatz ist bei wiederholten oder kontinuierlichen Verarbeitungsaufgaben äußerst effizient – ähnlich wie eine Blockchain fortlaufend Transaktionen verarbeitet.

Datenparallelität verfolgt einen anderen Ansatz: Mehrere Elemente werden gleichzeitig, aber unabhängig voneinander verarbeitet. Es ist, als hätte die Fabrik mehrere Fließbänder zur Datenverarbeitung. Das ist bei Aufgaben effektiv, die sich in kleinere Teilaufgaben zerlegen lassen. Für Blockchains und insbesondere Systeme wie Firedancer ist Datenparallelität entscheidend, um Transaktionen oder Datenverarbeitungsaufgaben gleichzeitig zu bearbeiten. Firedancers Fähigkeiten zur Parallelverarbeitung maximieren den Rechendurchsatz und verkürzen die Verarbeitungszeiten.

Stell dir jede Pipeline-Stufe als eigenständige Arbeitsstation in einer Fabrik vor. Jede Arbeitsstation kann unabhängig und gleichzeitig arbeiten. Während eine Stufe einen Teil der Daten verarbeitet, kann die nächste Stufe gleichzeitig an einem anderen Teil arbeiten. So können mehrere Pipeline-Stufen zur selben Zeit aktiv sein, was den Durchsatz deutlich erhöht. Firedancer kombiniert die sequenzielle Effizienz von Pipelines mit der gleichzeitigen Verarbeitungsleistung der Parallelität, um große Transaktionsvolumen zu verarbeiten.

Field-Programmable Gate Array (FPGA)

Field-Programmable Gate Arrays (FPGAs) sind vielseitige integrierte Schaltungen, die sich nach der Herstellung programmieren oder neu konfigurieren lassen. Diese Schaltungen bieten eine Anpassungsfähigkeit, die herkömmliche Hardwarekomponenten nicht erreichen. Sie bestehen aus einem großen Raster miteinander verbundener, programmierbarer Logikblöcke, die jeweils verschiedene digitale Funktionen ausführen können. Dieses Design macht FPGAs besonders flexibel und effizient für Anwendungen, bei denen Geschwindigkeit, Parallelverarbeitung und Anpassungsfähigkeit entscheidend sind.

Ein typisches FPGA besteht aus winzigen programmierbaren Elementen, die durch programmierbare Leitungen miteinander verbunden sind. Dieses komplexe Netzwerk aus Komponenten und Verbindungen ermöglicht es, verschiedene Bereiche des Chips für bestimmte Aufgaben zu programmieren. Dadurch entsteht eine vollständig angepasste Verarbeitungsumgebung.

FPGAs zeichnen sich bei der Parallelverarbeitung aus, weil sie diese kleinen programmierbaren Elemente gleichzeitig nutzen. Ihre Struktur ermöglicht effiziente Pipelines, in denen Daten kontinuierlich durch die Verarbeitungsstufen fließen. Eine gut konzipierte Pipeline entkoppelt den Durchsatz des Systems von der Latenz. Obwohl eine solche Pipeline für die Ausgabe möglicherweise länger als eine herkömmliche CPU benötigt, kann das System mehrere eingehende Datenströme gleichzeitig verarbeiten. Die Latenz einzelner Operationen beeinflusst den gesamten Datenfluss kaum – ähnlich wie Wasser, das durch einen Schlauch fließt.

Für Firedancer bieten FPGAs einen erheblichen Vorteil. Sie können Daten-Pipelines direkt mit Netzwerken verbinden. FPGAs verarbeiten Netzwerkverkehr effizienter als herkömmliche Konfigurationen, bei denen GPUs für die Datenübertragung auf CPUs angewiesen sind. Die direkte Konnektivität und die Möglichkeit, individuelle Verarbeitungslösungen zu erstellen, etwa Soft-Prozessoren auf dem FPGA-Fabric, machen sie für die Entwicklung eines leistungsstarken Validator-Clients unverzichtbar.

‍