Solanas Entwickler-Community hat den Pull Request für SIMD-0649 am 25. September ohne Merge geschlossen – damit bleibt die geplante Regel gegen unfaire Transaktionsreihenfolgen vorerst auf Eis, obwohl sie ursprünglich als Schritt zu mehr Fairness beim Trading auf Solana galt.
Doch selbst wenn der Vorschlag angenommen worden wäre, hätte er die Kontrolle der Blockproduzenten kaum eingeschränkt. Sogenannte Leader hätten weiterhin bestimmt, welche Transaktionen überhaupt in einen Block gelangen und wo die Grenzen der einzelnen Batches verlaufen – genau das Detail, das die Reform am Ende relativiert.
SIMD-0649 scheitert vorerst an der Governance-Abstimmung
Der Vorschlag hätte Validatoren erlaubt, einen Block abzulehnen, wenn nicht ausgenommene Transaktionen innerhalb eines Entry-Batches nicht in nicht steigender Prioritätsreihenfolge stehen. Die Regel hätte also nicht bestimmt, welche Transaktionen überhaupt in den Block gelangen, sondern nur, in welcher Reihenfolge sie innerhalb eines bereits gebildeten Batches erscheinen dürfen.
Ein Validator hätte beim Replay des Blocks die aufgezeichneten Prioritäten verglichen und einen Verstoß als ungültigen Block gewertet. Eine nachträgliche Umsortierung eingegangener Transaktionen war dagegen nie Teil des Designs. Transaktionen mit identischer Priorität hätten in beliebiger Reihenfolge stehen dürfen, einfache Vote-Transaktionen wären ohnehin ausgenommen gewesen.
Die Prioritätsbewertung selbst basiert auf der Belohnung, die ein Leader für die Aufnahme einer Transaktion erhält, geteilt durch deren angeforderte Kosten im Pre-Execution-Kostenmodell. Der Entwurf sah dafür eine ganzzahlige Berechnung mit Multiplikator und einer Einheiten-Sicherung im Nenner vor, damit unterschiedliche Validator-Clients zum selben Ergebnis kommen. Wie schwierig sich solche Governance-Reformen in dezentralen Netzwerken gestalten, wenn geringe Beteiligung und Interessenkonflikte auf beiden Seiten stehen, zeigt sich auch an anderer Stelle im Zusammenspiel von Solanas Governance-Prozessen.
Warum die Regel keine slotweite Fairness garantiert
Selbst im Erfolgsfall hätte SIMD-0649 den Leadern erhebliche Spielräume gelassen. Sie hätten weiterhin frei entscheiden können, welche Transaktionen sie aufnehmen, welche sie auf einen späteren Batch verschieben und wo genau die Batch-Grenzen verlaufen – Entscheidungen, die darüber bestimmen, ob zwei konkurrierende Transaktionen überhaupt jemals demselben Ordnungstest unterliegen.
Symbolische Darstellung eines Blockchain-Netzwerks.
Eine höher priorisierte Transaktion in einem späteren Batch wäre demnach nicht automatisch vor einer niedriger priorisierten Transaktion in einem früheren Batch eingeordnet worden. Eine einheitliche Prioritätswarteschlange für den gesamten Slot hätte der Vorschlag also nicht geschaffen, sondern lediglich eine engere, batch-interne Prüfung.
Um das offensichtlichste Schlupfloch zu schließen, hätten nicht finale Batches mindestens zwei Forward-Error-Correction-Sets umfassen müssen, unter der beschriebenen festen FEC-Größe also mindestens 64 Data-Shreds. Der letzte Batch eines Slots wäre von dieser Mindestgröße ausgenommen geblieben, hätte aber weiterhin die Reihenfolgeprüfung erfüllen müssen. Gleichzeitig hätte die Regel einen Leader nicht daran gehindert, eigene Transaktionen über Prioritätsgebühren zu bevorzugen – der Entwurf beschreibt diese Gebühren ausdrücklich als Rückfluss an den Leader, während der verbrannte Anteil der Grundgebühr Kosten bleibt. Wie eng die wirtschaftlichen Anreize der Solana-Validatoren mit solchen Gebührenmechaniken verknüpft sind, erklärt auch, warum Leader kaum freiwillig auf ihre Diskretion verzichten. Solche Fragen erinnern an technische Ansätze gegen MEV und Front-Running bei Ethereum, wo ähnliche Zielkonflikte zwischen Validator-Anreizen und Handelsqualität diskutiert werden.
Welche Daten für einen Neustart fehlen
Am 23. September verlangte ein Reviewer aktuelle Batch-Größen, aufgeschlüsselt nach Scheduler, Client und Marktbedingungen, sowie einen Sensitivitätstest für unterschiedliche Mindestgrößen. Beide Forderungen sind Einwände gegen die praktische Reichweite der Regel – nicht Belege dafür, dass Leader das beschriebene Schlupfloch auf dem Mainnet bereits ausgenutzt hätten.
Der Entwurf nennt zwar ungefähre Zielwerte von Agave und Firedancer für Batches von rund zwei FEC-Sets, doch weder der Vorschlag noch die Review liefern eine gemessene Verteilung, wie oft heutige Leader tatsächlich kleinere Batches produzieren. Ohne diese Daten lässt sich der Effekt der Mindestgröße auf die normale Blockproduktion nicht beziffern.
Eine Prüfung, die auf einen vollständigen Batch wartet, könnte zudem bei niedriger Netzwerkauslastung zusätzliche Verzögerung bei der Weiterleitung verursachen – wie groß diese Verzögerung ausfallen würde, messen die vorliegenden Quellen nicht. Sollte eine überarbeitete Version von SIMD-0649 künftig vorankommen, wird ihr tatsächlicher Nutzen für Trader davon abhängen, wie oft konkurrierende Transaktionen überhaupt denselben Batch teilen und ob die Mindestgröße das Verhalten der Leader in der Praxis verändert.
Zuletzt aktualisiert am 28. September 2026
