Ein Solana-Vorschlag zur Standardisierung der Transaktionsreihenfolge innerhalb von Batches ist vorerst nicht weitergekommen. SIMD-0649 hätte Validatoren verpflichtet zu prüfen, ob Transaktionen entsprechend ihrer Gebührenpriorität angeordnet sind. Welche Transaktionen in einen Block aufgenommen werden und wo einzelne Batches beginnen oder enden, wäre jedoch weiterhin den Blockproduzenten überlassen geblieben. Der Pull Request wurde am 25. September 2026 geschlossen, ohne in den Code übernommen zu werden. Die vorgesehenen Regeln gelten damit nicht. Da belastbare Daten zu den aktuellen Batch-Größen fehlen, bleibt außerdem offen, ob der Vorschlag die Ausführung von Transaktionen tatsächlich berechenbarer gemacht hätte.
SIMD-0649 prüft die Reihenfolge innerhalb eines Batches
Solana strukturiert die Daten eines Blocks in Batches. Nach dem Vorschlag hätten Transaktionen innerhalb desselben Batches grundsätzlich von der höchsten zur niedrigsten Priorität angeordnet werden müssen. Ausgenommen wären bestimmte Transaktionen gewesen. Validatoren hätten die aufgezeichnete Reihenfolge bei der erneuten Verarbeitung eines Blocks geprüft und einen Block bei einem Verstoß als ungültig zurückgewiesen. Eine nachträgliche Umsortierung nach dem Empfang war nicht vorgesehen.
Transaktionen mit gleicher Priorität hätten in beliebiger Reihenfolge erscheinen können. Einfache Abstimmungstransaktionen wären von der Regel ausgenommen gewesen. Die vorgeschlagene Prioritätskennzahl hätte sich zudem nicht unmittelbar aus der von einem Nutzer eingegebenen Gebühr ergeben. Stattdessen sollte die Vergütung des Blockproduzenten für die Aufnahme einer Transaktion durch die im Kostenmodell vor der Ausführung angeforderten Kosten geteilt werden. Ein Multiplikator sowie Schutzvorkehrungen für den Nenner sollten zusammen mit Ganzzahlarithmetik für konsistente Ergebnisse über verschiedene Clients hinweg sorgen.
Nach den vorgesehenen Gebührenregeln hätte die Vergütung sowohl die Prioritätsgebühr als auch den nicht verbrannten Anteil der Grundgebühr umfasst. Bei einer Annahme hätte die Regel eine einheitliche Prüfung ermöglicht, ob nicht ausgenommene Transaktionen in demselben Batch konsistent angeordnet waren. Die Autoren sahen darin eine Möglichkeit, die Transaktionsreihenfolge zwischen verschiedenen Validator-Clients und Scheduler-Systemen zu vergleichen. Die Regel hätte aber nicht festgelegt, ob eine Transaktion überhaupt in den Block aufgenommen werden muss.
Blockproduzenten behalten Kontrolle über Aufnahme und Batch-Grenzen
SIMD-0649 hätte keine einheitliche Prioritätswarteschlange für einen gesamten Slot geschaffen. Blockproduzenten hätten weiterhin selbst entscheiden können, welche Transaktionen aufgenommen, in spätere Batches verschoben und an welcher Stelle die Batch-Grenzen gezogen werden. Dadurch könnten konkurrierende Transaktionen in unterschiedlichen Batches landen und somit gar nicht unter die vorgesehene Reihenfolgenprüfung fallen. Eine Transaktion mit höherer Priorität in einem späteren Batch hätte nicht automatisch Vorrang vor Transaktionen aus einem früheren Batch erhalten.
Der Vorschlag wäre damit enger gefasst gewesen als Regeln für die Reihenfolge über den gesamten Slot und hätte keine optimale Ausführung garantiert. Vorgesehen war deshalb eine Mindestgröße für Batches. Sie sollte verhindern, dass Blockproduzenten die Prüfung durch eine Aufteilung in sehr kleine Gruppen mit nur wenigen vergleichbaren Transaktionen abschwächen.
Mit Ausnahme des letzten Batches hätte jeder Batch mindestens zwei Forward-Error-Correction-Sets (FEC-Sets) umfassen müssen. Ein FEC-Set besteht aus Data Shreds, aus denen sich die Blockdaten zusammensetzen. Nach der im Vorschlag festgelegten Größe entsprechen zwei Sets mindestens 64 Data Shreds. Für den letzten Batch hätte die Reihenfolgenprüfung weiterhin gegolten. Die Mindestgröße wäre dort jedoch entfallen, weil ein Slot enden kann, bevor der Batch vollständig gefüllt ist.
Fehlende Daten zu Batch-Größen erschweren die Bewertung
In einem Review-Kommentar vom 23. September wurde darauf hingewiesen, dass ein Blockproduzent einen Batch auch bei einer Mindestgröße beenden könnte, wenn dies dazu beiträgt, konkurrierende Transaktionen voneinander zu trennen. Der Verfasser forderte aktuelle Daten zu den Batch-Größen, aufgeschlüsselt nach Scheduler, Client und Marktbedingungen. Außerdem wurde vorgeschlagen zu testen, wie sich unterschiedliche Mindestgrößen auf die Ergebnisse auswirken.
Die Kommentare stellten damit die praktische Reichweite der Regel infrage. Sie lieferten jedoch keinen Hinweis darauf, dass Blockproduzenten diese Vorgehensweise bereits im Mainnet genutzt hätten.
Der Vorschlag erklärte, dass Agave und Firedancer Batches von ungefähr zwei FEC-Sets anstreben. Weder SIMD-0649 noch die Review-Kommentare enthielten jedoch eine Verteilung der heute tatsächlich erzeugten Batch-Größen. Deshalb lässt sich nur schwer beziffern, wie stark die Mindestgröße den regulären Blockbetrieb beeinflusst oder in welchem Umfang sie den Spielraum der Produzenten bei der Festlegung von Batch-Grenzen einschränken würde.
Latenz und Prioritätsgebühren bleiben offene Punkte
Eine Diskussion im August hatte auf ein mögliches Latenzproblem hingewiesen. Wenn Validatoren auf einen vollständigen Batch warten müssten, könnte dies die Fähigkeit von Firedancer beeinträchtigen, eintreffende Daten unmittelbar erneut abzuspielen. Ein überarbeiteter Entwurf hätte Validatoren erlaubt, Transaktionen schrittweise zu vergleichen und auszuführen. Ein Block wäre zurückgewiesen worden, sobald sich später ein Verstoß gegen die Reihenfolge ergeben hätte.
Bei geringem Transaktionsaufkommen könnte die Verpflichtung, bis zum Erreichen der Mindestgröße von zwei FEC-Sets zu warten, allerdings zusätzliche Verzögerungen bei der Übertragung verursachen. Messungen zu dieser Latenz lagen in den verfügbaren Unterlagen nicht vor.
Der Vorschlag hätte außerdem nicht verhindert, dass ein Blockproduzent eigene Transaktionen bevorzugt, indem er sich selbst eine Prioritätsgebühr zahlt. SIMD-0649 hielt fest, dass Prioritätsgebühren an den Blockproduzenten fließen, während der verbrannte Anteil der Grundgebühr als Kosten bestehen bleibt. Eine Prüfung der Reihenfolge auf Batch-Ebene hätte daher für sich genommen weder eine bevorzugte Behandlung eigener Transaktionen noch Maximum Extractable Value (MEV) oder Slippage ausgeschlossen.
SIMD-0649 wurde am 25. September geschlossen. Weitere Fortschritte wären von zusätzlichen Diskussionen und der Unterstützung durch die Entwickler der Clients abhängig. Für Händler bleibt entscheidend, wie viele tatsächlich miteinander konkurrierende Transaktionen im selben Batch landen und ob eine Mindestgröße das Verhalten der Blockproduzenten verändert. Bis entsprechende Daten vorliegen, bietet der Vorschlag zwar eine Möglichkeit, die relative Reihenfolge innerhalb eines Batches zu überprüfen. Welche Auswirkungen dies auf die tatsächliche Ausführung hätte, bleibt jedoch offen.