Solana: Validatoren bremsen Regel zur Transaktionsreihenfolge

SIMD-0649, ein vorgeschlagener Solana-Mechanismus zur Prüfung der Transaktionsreihenfolge, endete am 25. September ohne Zusammenführung. Der Entwurf hätte es Validatoren erlaubt, einen Block abzulehnen, wenn nicht ausgenommene Transaktionen innerhalb eines Entry-Batches gegen die Gebührenpriorität verstießen. Er hätte nicht festgelegt, welche Transaktionen in den Block gelangen, Batch-Grenzen bestimmt oder eine slotweite Prioritätswarteschlange geschaffen.

Warum das wichtig ist

Nach dem Vorschlag könnte ein Leader weiterhin Transaktionen auswählen, sie auf spätere Batches verschieben und festlegen, wie diese Batches gebildet werden. Eine Transaktion mit höherer Priorität in einem späteren Batch würde nicht vor einer Transaktion mit niedrigerer Priorität in einem früheren Batch stehen. Damit wäre die Regel enger gefasst als Best Execution und würde Blockproduzenten erheblichen Ermessensspielraum lassen.

Der vorgeschlagene Score basiert auf der Belohnung des Leaders für die Aufnahme einer Transaktion, geteilt durch deren angeforderte Kosten nach dem Vorab-Ausführungs-Kostenmodell. Er umfasst die Prioritätsgebühr und den nicht verbrannten Anteil der Basisgebühr und ist daher nicht einfach eine Rangfolge nach der vom Nutzer angegebenen Gebühr. Transaktionen mit gleicher Priorität könnten in beliebiger Reihenfolge erscheinen, während einfache Vote-Transaktionen ausgenommen wären.

Auswirkungen auf den Markt

Der Entwurf würde Tradern und Validatoren eine überprüfbare Möglichkeit geben festzustellen, ob Transaktionen im selben Batch der vorgegebenen Reihenfolge folgten. Um triviale Batches zu begrenzen, müsste jeder Batch außer dem letzten mindestens zwei FEC-Sets umfassen, also nach der Regel mit fester Größe 64 Data Shreds. Für den letzten Batch würde die Mindestgröße weiterhin nicht gelten.

Diese Absicherung würde nicht jede Möglichkeit einer bevorzugten Behandlung beseitigen. Prüfer bezweifelten, dass Leader Batches strategisch schließen könnten, während der Vorschlag ihnen auch erlaubt, eigene Transaktionen über Prioritätsgebühren zu bevorzugen. Der Entwurf wirft außerdem Fragen zur Latenz bei teilweise empfangenen Daten auf. Allerdings belegt weder eine gemessene Batch-Verteilung noch eine Schätzung der Verzögerung, wie stark die Regel die Ausführung im Mainnet verändern würde. Ein überarbeiteter Vorschlag müsste von den Clients unterstützt werden und belegen, dass sich regelmäßig mehrere relevante konkurrierende Transaktionen in einem Batch befinden.