Für Trader bleibt Solanas Ausführung schwer vorhersehbar

Solanas SIMD-0649-Pull-Request wurde am Freitag, 25. September, ohne Merge geschlossen. Damit tritt vorerst keine neue Regel zur Transaktionsreihenfolge in Kraft, und die Vorhersagbarkeit der Ausführung auf Solana bleibt für Trader ungeklärt.

SIMD-0649 bleibt ohne Merge

Der Vorschlag hätte Validatoren erlaubt, einen Block abzulehnen, wenn Transaktionen innerhalb eines einzelnen Entry-Batches nicht in nicht steigender Prioritätsreihenfolge aufgezeichnet sind. Entschieden hätte die Regel damit nicht, welche Transaktionen überhaupt in den Block gelangen, und eine nachträgliche Umsortierung war ebenfalls nicht vorgesehen.

Gleich priorisierte Transaktionen hätten in beliebiger Reihenfolge erscheinen können, einfache Vote-Transaktionen wären von der Prüfung ausgenommen gewesen. Die Priorität selbst berechnet sich laut Entwurf aus dem Reward, den ein Leader für die Aufnahme einer Transaktion erhält, geteilt durch die angeforderten Kosten nach dem Pre-Execution-Kostenmodell – wobei der Reward die Priority Fee sowie den unverbrannten Anteil der Base Fee umfasst.

Warum die Leader-Auswahl entscheidend bleibt

Selbst mit der vorgeschlagenen Prüfung hätten Blockproduzenten – die sogenannten Leader – weiterhin frei entschieden, welche Transaktionen sie aufnehmen, welche sie in spätere Batches verschieben und wo sie Batchgrenzen ziehen. Eine höher priorisierte Transaktion in einem späteren Batch wäre dadurch nicht automatisch vor eine niedriger priorisierte Transaktion in einem früheren Batch gerutscht.

Um zu verhindern, dass Leader die Regel durch winzige Batches aushebeln, sollte jeder Batch außer dem letzten mindestens zwei Forward-Error-Correction-Sets umfassen – nach der im Entwurf genutzten festen Größe entspricht das mindestens 64 Data-Shreds. Der letzte Batch eines Slots wäre von dieser Mindestgröße ausgenommen geblieben, hätte aber weiterhin der Reihenfolgeprüfung unterlegen. Ein Reviewer merkte am 23. September an, dass ein Leader Batches weiterhin gezielt schließen könnte, um konkurrierende Transaktionen zu trennen, und forderte aktuelle Daten zu Batchgrößen nach Scheduler, Client und Marktbedingungen sowie Sensitivitätstests für andere Mindestwerte. Solche Messdaten liegen bislang nicht vor, weder Agave noch Firedancer haben eine gemessene Verteilung ihrer tatsächlichen Batchgrößen veröffentlicht, obwohl beide Clients laut Entwurf Batches von etwa zwei FEC-Sets anstreben. Der Vorschlag fügt sich damit in eine Reihe technischer Anpassungen ein, zu denen auch das laufende Alpenglow-Testnet zur schnelleren Finalität zählt.

Offene Folgen für Handel und Ausführung

Selbst in überarbeiteter Form hätte die Prüfung lediglich die relative Reihenfolge nicht ausgenommener Transaktionen innerhalb desselben Batches über verschiedene Validator-Clients hinweg nachvollziehbarer gemacht. Eine Garantie gegen bevorzugte Behandlung, MEV oder Slippage wäre sie nicht gewesen, weil Leader weiterhin Auswahl und Batchgrenzen kontrollieren und eigene Transaktionen über Priority Fees an sich selbst bevorzugen könnten.

Ein im August diskutiertes Latenzproblem betraf zudem Firedancers Praxis, teilweise empfangene Daten bereits zu verarbeiten. Der revidierte Entwurf hätte Validatoren erlaubt, Transaktionen bei Eingang zu vergleichen und auszuführen und den Block erst bei einem späteren Prüffehler ungültig zu erklären – gemessene Werte zu möglichen Broadcast-Verzögerungen bei niedriger Auslastung liegen dazu allerdings nicht vor. Ob eine künftige Version diese Lücken schließt, hängt letztlich davon ab, wie oft konkurrierende Transaktionen überhaupt denselben Batch teilen und ob eine Mindestgröße das tatsächliche Leader-Verhalten verändert. Bis dahin bleibt die Frage, wie berechenbar Ausführung auf Solana tatsächlich ist, technisch offen.