Solanas Vorschlag SIMD-0649, der die Reihenfolge von Transaktionen innerhalb einzelner Batches nachvollziehbar machen sollte, ist am 25. September ohne Merge geschlossen worden. Die Regel hätte Validatoren erlaubt, einen Block abzulehnen, wenn Transaktionen innerhalb eines Batches nicht nach Gebührenpriorität sortiert waren. Wer die Transaktionen überhaupt in den Block aufnimmt und wo ein Batch beginnt oder endet, bleibt weiterhin Sache des jeweiligen Leaders.
Das Wichtigste im Überblick:
- SIMD-0649 wurde am 25. September ohne Merge geschlossen, laut CryptoSlate blieb der Vorschlag damit in der Diskussion.
- Die Regel hätte nur die Reihenfolge innerhalb eines Batches geprüft, nicht die Auswahl der Transaktionen für einen Block.
- Leader behalten volle Kontrolle darüber, welche Transaktionen aufgenommen werden und wo Batch-Grenzen verlaufen.
- Fehlende Daten zu aktuellen Batch-Größen lassen offen, wie stark sich die Regel auf reale Handelsergebnisse auswirken würde.
SIMD-0649 bleibt ohne Merge
Der Vorschlag zielte auf ein konkretes Problem: Innerhalb eines Batches sollten nicht-befreite Transaktionen in absteigender Prioritätsreihenfolge erscheinen müssen. Ein Validator, der den Block nachvollzieht, hätte die aufgezeichnete Reihenfolge mit der berechneten Priorität abgleichen und einen Verstoß als ungültigen Block werten können. Die Regel hätte Transaktionen also nicht nachträglich umsortiert, sondern lediglich die bereits empfangene Reihenfolge geprüft.
Transaktionen mit gleicher Priorität hätten in beliebiger Reihenfolge stehen dürfen, einfache Vote-Transaktionen wären ausgenommen gewesen. Die Prioritätsbewertung selbst basiert laut dem Entwurf auf der Belohnung, die ein Leader für die Aufnahme einer Transaktion erhält, geteilt durch die angeforderten Kosten im vorab kalkulierten Kostenmodell. Diese Belohnung setzt sich aus der Priority Fee und dem nicht verbrannten Anteil der Grundgebühr zusammen – eine differenziertere Größe als eine simple Rangfolge nach genannter Gebühr.
Wichtig ist, was die Regel nicht geleistet hätte: Sie hätte keine einzige Prioritätswarteschlange für einen gesamten Slot geschaffen und keine Garantie für die bestmögliche Ausführung gegeben.
Warum die Begrenzung für Trader wichtig ist
Für Trader, die versuchen vorherzusagen, wo ihre Order landet, macht dieser Unterschied den entscheidenden Unterschied. Ein Leader kann weiterhin frei wählen, welche Transaktionen er aufnimmt, eine Transaktion in einen späteren Batch verschieben oder die Batch-Grenzen selbst festlegen. Eine Transaktion mit höherer Priorität in einem späteren Batch würde deshalb nicht automatisch vor eine niedriger priorisierte Transaktion in einem früheren Batch rücken – die Prüfung greift nur innerhalb desselben Batches.
Um zu verhindern, dass Leader die Regel durch winzige Batches aushöhlen, sollte jeder Batch außer dem letzten mindestens zwei sogenannte Forward-Error-Correction-Sets (FEC-Sets) umfassen – nach der im Entwurf beschriebenen festen Größenregel entspricht das mindestens 64 Datenshreds. Diese Grundeinheiten der Blockübertragung hängen eng mit Solanas Slot-Struktur und Transaktionsverarbeitung zusammen, wie sie auch in der Erklärung zu Solanas 350-Millisekunden-Blockzeit beschrieben wird.
Der Entwurf nennt als Zielgröße für die Clients Agave und Firedancer Batches von rund zwei FEC-Sets, liefert aber keine gemessene Verteilung darüber, wie oft aktuelle Leader tatsächlich kleinere Batches produzieren. Ein Prüfer forderte in einer Review vom 23. September genau diese Daten – aufgeschlüsselt nach Scheduler, Client und Marktbedingungen – sowie einen Sensitivitätstest für unterschiedliche Mindestgrößen. Belege dafür, dass ein Leader diese Taktik bereits im Mainnet genutzt hat, um konkurrierende Transaktionen bewusst zu trennen, liegen laut CryptoSlate nicht vor.
Was als Nächstes zu beobachten ist
Die Schließung am 25. September folgte auf einen Aufruf zu weiterer Diskussion und zusätzlicher Unterstützung durch Client-Entwickler. Ob eine überarbeitete Version der Regel etwas bewirkt, hängt davon ab, wie oft konkurrierende Transaktionen mit vergleichbarer Priorität überhaupt im selben Batch landen – und ob die Mindestgröße das Verhalten der Leader tatsächlich verändert. Ohne die fehlenden Batch-Daten lässt sich dieser Effekt derzeit nicht beziffern.
SIMD-0649 würde zudem nicht verhindern, dass ein Leader eigene Transaktionen bevorzugt, indem er sich selbst Priority Fees zahlt – diese Gebühren fließen laut Entwurf an den Leader zurück, während der verbrannte Teil der Grundgebühr ein realer Kostenfaktor bleibt. Die Regel ist damit ausdrücklich keine Garantie gegen Vorzugsbehandlung, MEV oder Slippage. Eine im August aufgeworfene Latenzsorge – dass die Prüfung auf einen vollständigen Batch warten müsse – wurde im überarbeiteten Entwurf entschärft: Validatoren dürfen Transaktionen vergleichen und ausführen, sobald sie eintreffen, und den Block erst nachträglich für ungültig erklären, falls ein späterer Abgleich scheitert. Wie stark dadurch mögliche Übertragungsverzögerungen bei geringem Durchsatz entstehen, wird in den vorliegenden Quellen nicht beziffert.
Warum Sie 99Bitcoins vertrauen können
99Bitcoins wurde 2013 gegründet und verfügt über ein Team von Experten, deren Erfahrung bis in die Anfänge der Kryptozeit zurückreicht.
Wöchentliche Recherche
100k+Monatliche Leser
Experten
2000+Krypto-Projekte unter die Lupe genommen
