Solanas Vorschlag zur Gebührenreihenfolge in Batches geht zurück zur Debatte

Serguey Asael Shinder28 September 2026, 07:302 Min. Lesezeit

Ein Vorschlag, die Reihenfolge von Transaktionen in Solana-Blöcken teilweise per Konsens durchzusetzen, geht zurück in die Diskussion. SIMD-0649, am 21. September von Max Resnick eingereicht, machte aus einer Diskussion vom August einen formellen Vorschlag: Innerhalb jedes Entry-Batches sollten Transaktionen in nicht steigender Prioritätsreihenfolge stehen, und ein Block, der das verletzt, wäre ungültig. Am 25. September wurde der Pull-Request ohne Zusammenführung geschlossen, mit dem Vermerk: "Geschlossen bis zu weiterer Diskussion. Wir brauchen hier mehr Zustimmung von Client-Entwicklern."

Der Entwurf ist enger als "Prioritätsreihenfolge für den ganzen Block". Solana zeichnet Transaktionen in Einträgen auf, die zu Batches gruppiert sind. Validatoren, die einen Block nachspielen, würden prüfen, dass nicht ausgenommene Transaktionen innerhalb jedes Batches nach einem festgelegten Prioritätswert geordnet sind, und den Block andernfalls ablehnen; Transaktionen gleicher Priorität dürften in beliebiger Reihenfolge stehen, einfache Vote-Transaktionen wären ausgenommen. Der Wert beruht auf der Belohnung, die ein Leader für die Aufnahme erhält, geteilt durch die angeforderten Kosten, als Ganzzahl berechnet, damit alle Clients dasselbe Ergebnis erhalten. Damit Leader die Regel nicht durch winzige Batches aushöhlen, müsste jeder Batch außer dem letzten mindestens zwei Forward-Error-Correction-Sets umfassen.

Ebenso wichtig ist, was der Vorschlag dem Leader überlässt. Der Blockproduzent würde weiterhin entscheiden, welche Transaktionen aufgenommen werden, wo Batches beginnen und enden und welche Transaktionen auf einen späteren Batch verschoben werden. Eine Transaktion hoher Priorität in einem späteren Batch würde nicht vor eine niedrigere in einem früheren rücken.

Was das bedeutet

Das Argument für die Regel ist Überprüfbarkeit: Eine gemeinsame Prüfung ließe jeden nachvollziehen, ob ein Leader Transaktionen innerhalb eines Batches konsistent geordnet hat, gleich welchen Validator-Client oder Scheduler er nutzt. Die Grenze liegt darin, dass Entscheidungen über Aufnahme und Batch-Grenzen, in denen viel vom Wert der Reihenfolge steckt, beim Leader bleiben.

Das Schließen des Pull-Requests ist ein Verfahrensschritt, keine Ablehnung. Konsensänderungen brauchen bei Solana die Zustimmung der Teams, die seine Validator-Clients bauen, und die Maintainer bitten darum, bevor der Vorschlag weitergehen kann.