Solana könnte einen Turbo-Boost erhalten, da Firedancer auf Block-Beschränkungen abzielt

Der Leistungsschub von Solana erhielt diese Woche frischen Schwung, als Ingenieure hinter Firedancer, dem von Jump vorangetriebenen alternativen Hochleistungs-Validator-Client, ein neues Solana Improvement Document (SIMD-0370) einreichten, um die Block-Level-Compute-Unit (CU)-Begrenzung des Netzwerks zu entfernen – eine Änderung, die ihrer Meinung nach nach Alpenglow überflüssig ist und sich bei Nachfragespitzen sofort in höherem Durchsatz und geringerer Latenz niederschlagen würde.

Nächster Turbo-Boost für Solana

Der Pull Request, verfasst vom "Firedancer Team" und am 24.09.2025 eröffnet, wird ausdrücklich als "Post-Alpenglow"-Vorschlag dargestellt. In Alpenglow senden Wählerknoten eine SkipVote, wenn sie einen vorgeschlagenen Block nicht innerhalb der zugewiesenen Zeit ausführen können. Da langsame Blöcke automatisch übersprungen werden, argumentieren die Autoren, dass eine separate protokollerzwungene CU-Obergrenze pro Block unnötig ist.

"In Alpenglow senden Wählerknoten eine SkipVote, wenn sie einen Block nicht rechtzeitig ausführen können... Dieses SIMD entfernt daher die Durchsetzung der Block-Compute-Unit-Begrenzung", heißt es in dem Dokument, das die Begrenzung unter den aktualisierten Planungsregeln als überflüssig beschreibt.

Über die technische Sauberkeit hinaus schlagen die Autoren eine schärfere wirtschaftliche Ausrichtung vor. Die aktuelle Block-Level-CU-Begrenzung, so argumentieren sie, bricht Anreize, indem sie die Kapazität über das Protokoll statt über Hardware- und Software-Verbesserungen begrenzt. Die Entfernung würde es Produzenten ermöglichen, Blöcke bis zu dem zu füllen, was ihre Maschinen sicher verarbeiten und verbreiten können, und damit den Wettbewerb bei Clients und Hardware in den Vordergrund rücken.

"Die Kapazität des Netzwerks wird nicht durch die Fähigkeiten der Hardware, sondern durch die willkürliche Block-Compute-Unit-Begrenzung bestimmt", schreiben sie, bevor sie darlegen, warum die Aufhebung dieser Begrenzung die Anreize sowohl für Validator-Clients als auch für Programmentwickler neu ausrichten würde.

Frühe Code-Review-Kommentare von Kernbeitragenden und Client-Teams unterstreichen sowohl die kurzfristigen Auswirkungen auf die Benutzer als auch die Grenzen der Änderung. Ein Prüfer fasste den praktischen Vorteil zusammen: "Die Entfernung der Begrenzung hat heute greifbare Vorteile für das Ökosystem und die Endbenutzer... ohne auf die zukünftige Architektur des Netzwerks warten zu müssen." Ein anderer betonte, dass einige Block-Einschränkungen bestehen bleiben würden, und verwies auf eine "maximale Shred-Begrenzung", während andere vorschlugen, dass das Netzwerk wahrscheinlich vorerst die CU-Begrenzungen pro Transaktion beibehalten und jede Änderung dort als separate, weiterreichende Diskussion behandeln sollte.

Sicherheits- und Lebendigkeit-Überlegungen stehen im Vordergrund. Prüfer forderten den Vorschlag auf, explizit zu erläutern, warum die Sicherheit auch dann gewahrt bleibt, wenn ein Block zu schwer ist, um rechtzeitig verbreitet zu werden; die Alpenglow-Antwort ist, dass solche Blöcke einfach nicht eingestimmt werden, d.h. sie werden übersprungen – wodurch der Fortschritt ohne Bestrafung des Netzwerks aufrechterhalten wird. Die Firedancer-Autoren stimmen zu, dass die entscheidende Leitplanke die Uhr und das Verbreitungsbudget ist, nicht eine statische CU-Obergrenze.

Der Vorschlag befasst sich auch mit einem häufigen Anliegen in Durchsatzdiskussionen: Koordination. Wenn ein Block-Produzent die Hardware aggressiv aufrüstet, während andere zurückbleiben, riskiert das Netzwerk dann Fluktuation durch übersprungene Blöcke? Ein Prüfer stellt fest, dass übermäßig ehrgeizige Produzenten sich bereits selbst kalibrieren, da verpasste Blöcke verpasste Belohnungen bedeuten, was die Blockgröße natürlich auf das begrenzt, was Peers rechtzeitig akzeptieren können. Das Dokument argumentiert weiter, dass mit dem Wegfall der CU-Begrenzung Marktkräfte die Kapazität regeln: Produzenten und Client-Teams, die Ausführung, Vernetzung und Planung optimieren, werden mehr Blöcke und Gebühren gewinnen und die Grenzen nach außen verschieben, wenn die Nachfrage es rechtfertigt.

Entscheidend ist, dass SIMD-0370 zukunftskompatibel ist. Laufende Designs für mehrere gleichzeitige Vorschlagende – ein langfristiger Fahrplanpunkt für Solana – gehen manchmal von einer Blockbegrenzung aus und manchmal nicht. Prüfer betonen, dass die Entfernung der aktuellen Begrenzung spätere Architekturen mit gleichzeitigen Vorschlagenden nicht ausschließt; sie entblockiert einfach Verbesserungen, die "heute realisiert werden können".

Während die GitHub-Diskussion die technischen Details liefert, hat auch Anza – das Solana-Client-Team hinter Agave – den Vorschlag auf sozialen Kanälen verstärkt, was auf eine breite Aufmerksamkeit des Client-Teams für die Änderung und ihre benutzerseitigen Auswirkungen hindeutet.

Was würde sich für Benutzer und Entwickler ändern, wenn SIMD-0370 ausgeliefert wird? In Spitzenzeiten – Airdrops, Mints, Marktvolatilität – könnten Blöcke mehr Rechenleistung tragen, solange sie innerhalb der Slot-Zeit ausgeführt und verbreitet werden können, was potenziell den nachhaltigen Durchsatz erhöht und Gebührenspitzen glättet.

Für Solana-Entwickler könnten höhere Spielräume und stärkere Anreize für Client/Hardware-Optimierung die Tail-Latenz für anspruchsvolle Workloads reduzieren, wenn auch mit der fortlaufenden Notwendigkeit, Programme für Parallelität und Lokalität zu optimieren. Für Validatoren würde sich der Wettbewerbsvorteil noch stärker in Richtung Ausführungseffizienz, Netzwerkleistung und intelligente Block-Building-Richtlinien verschieben, die Gebühreneinnahmen gegen das Risiko abwägen, einen Block zu produzieren, der so schwer ist, dass er übersprungen wird.

Wie bei allen SIMDs unterliegt die Änderung der Community-Überprüfung, Implementierung und Koordination der Bereitstellung über Validator-Clients hinweg. Aber die Richtung ist klar. Nach Alpenglow glauben Solanas Designer, dass das Slot-Zeit-Budget der eigentliche Begrenzer ist.

Zum Zeitpunkt der Drucklegung wurde Solana bei 205,38 $ gehandelt.