Analyse: Solana-Belohnungsdatensätze lassen Kommissionssätze aus und erschweren Gebührenprüfungen

Die Solana-Software Agave lässt Kommissionssätze in Belohnungsmetadaten aus, wenn benutzerdefinierte Sammelkonten aktiv sind, obwohl Staking-Auszahlungen weiterhin sichtbar sein können. P2P.org erklärte in einem Bericht vom 30. Oktober, dass seit dem 8. September Einträge zu Kommissionssätzen in Datensätzen zu Abstimmungs- und Staking-Belohnungen fehlten. P2P.org zufolge erhoben die Validatoren weiterhin Provisionen, und die Belohnungsbeträge gingen rechnerisch auf. Das Problem betrifft die Belege, die zur Erklärung von Auszahlungen benötigt werden, nicht einen festgestellten Auszahlungsausfall. P2P.org hat ein kommerzielles Interesse an dem Thema, da der Anbieter Staking- und Reporting-Dienstleistungen vermarktet.

Der Agave-Pull-Request #12588, der am 20. Mai zusammengeführt wurde, beschreibt, dass die Sätze nach der Aktivierung benutzerdefinierter Sammelkonten ausgelassen werden. Betroffen sind angesammelte Validator-Provisionen und individuelle Staking-Belohnungen. Die betroffenen Belohnungsinformationen erreichen Nutzer über Blockabfragen und Abonnements. Agaves Berechnungscode führt den Kommissionssatz weiterhin der Belohnungsberechnung zu, bevor er ihn aus dem resultierenden Datensatz ausschließt. Ein fehlender Satz weist daher auf fehlende Metadaten hin und nicht auf eine Provision von null. SIMD-0232 erlaubt Validatoren, Provisionserträge auf festgelegte Sammelkonten umzuleiten, ohne die Berechnung der Inflationsprovision zu ändern.

Der Pull-Request erläutert, dass angesammelte Belohnungen Erträge zusammenfassen können, die auf ein Sammelkonto umgeleitet wurden, sodass ein einzelner Kommissionssatz die Gesamtsumme möglicherweise nicht angemessen beschreibt. Die Implementierung entfernt den Satz jedoch auch aus den Belohnungen einzelner Staking-Positionen und verringert damit die verfügbaren Belege zur Prüfung eines einzelnen Staking-Kontos. Da Solana Änderungen an Kommissionssätzen verzögert anwendet, sind historische Sätze für die Überprüfung erforderlich. Nach SIMD-0249 werden Belohnungen, die während Epoche E verdient wurden, normalerweise anhand eines Satzes berechnet, der zu Beginn von E-1 erfasst wurde; die Berechnung erfolgt zu Beginn von E+1. Für neu erstellte Vote-Konten kann ein späterer Kontostand herangezogen werden, wenn der erforderliche frühere Verlauf nicht verfügbar ist. Die aktuelle Einstellung eines Validators kann daher von dem Satz abweichen, der für eine frühere Auszahlung galt.

Eine technische Diskussion vom 16. Juli stellte fest, dass effektive Kommissions- und Sammelkonto-Informationen im zwischengespeicherten Laufzeitstatus vorhanden waren, die gewöhnliche Kontoabfragen jedoch nicht offenlegten. Entwickler erklärten, die Regel zur verzögerten Anwendung des Kommissionssatzes sei im Mainnet bereits aktiv, und diskutierten, die Abhängigkeit vom zwischengespeicherten Status separat zu beseitigen. Der Agave-Mitwirkende ax-x2 reichte am 18. Oktober einen RPC-Antrag ein. Darin wurde erläutert, dass getVoteAccounts und geparste Vote-Kontodaten zwar die jüngste Einstellung offenlegen, die Belohnungsberechnung jedoch einen gespeicherten Satz verwenden kann. Der Antrag schlägt eine optionale Antwort vor, die die effektive Inflationsprovision, die betreffende Epoche und den Bank-Slot anzeigt. Am 30. Oktober war der Antrag noch offen und es war keine Implementierung damit verknüpft. Das Beispiel im Antrag stellt einen niedrigen angezeigten Satz einem hohen gespeicherten Satz gegenüber, nennt jedoch keinen beobachteten Validator-Vorfall und belegt keine überhöhten Gebühren.

Zur Prüfung einer historischen Provision müssen der Belohnungszeitraum, die Delegation des Staking-Kontos an einen Validator und der nach der jeweils geltenden historischen Regel ausgewählte Satz miteinander abgeglichen werden. Das Validator-History-Programm von Jito dokumentiert Provisionen und weitere Validator-Historien für bis zu 512 Epochen je Validator. Jitos Kopieranweisung erfasst die Provision eines Vote-Kontos zusammen mit Epoche und Slot; diese Beobachtung belegt allein jedoch nicht den verzögert wirksamen Satz für eine bestimmte Auszahlung. Marinades Snapshot-Parser greift direkter auf die zwischengespeicherten Informationen zu, indem er die Inflationsprovision aus Epoch-Stakes-Snapshots extrahiert und den Datenstand sowie Fallback-Zähler veröffentlicht. Marinade weist darauf hin, dass Grenzen von Archivdaten und ältere Ausgabedateien ohne Metadaten zum Datenstand die Interpretation gespeicherter Sätze einschränken. Der Parser bietet eine Methode zur Rekonstruktion, aber keine Gewähr für vollständige Archive für jedes Konto und jede Epoche.

Die APY-Methodik von Trillium misst Inflationsrenditen anhand des Wachstums von Staking-Konten ab Epoche 1070 und verwendet dabei Eignungsprüfungen und RPC-Fallbacks statt des angezeigten Kommissionssatzes. Für frühere Epochen nutzt Trillium andere Methoden. Nettoerträge können daher weiterhin messbar sein, ohne dass die Provision, aus der diese Erträge hervorgingen, unabhängig überprüft wird. Trillium behandelt fehlende geeignete Kontobelege als unbekanntes Ergebnis und nicht als null. Ein für SOL-Inhaber oder Staking-Produkte nützlicher Ertragsdatensatz würde Nettoerträge mit dem relevanten Zeitraum, der Validator-Delegation und Belegen zum effektiven Kommissionssatz verknüpfen und zugleich Einschränkungen bei Rekonstruktion oder Stichproben offenlegen.

Eine Diskussion im Oktober über den Vote-State schlägt vor, Kommissionssätze zusammen mit den Epochen zu speichern, ab denen sie wirksam werden. Der Vorschlag zum Vote-State und der offene RPC-Antrag sind weiterhin vorgeschlagene Abhilfemaßnahmen und kein Beleg für eine implementierte Lösung. Inflationsprovision, MEV-Provision und die Beteiligung an Blockerlösen sind unterschiedliche Bestandteile; die Sichtbarkeit eines Satzes würde daher nicht eine gesamte Staking-Rendite erklären. Eine Berichterstattung im September über an Belohnungen geknüpfte Vote-Credits stellte ebenfalls fest, dass sich Verluste bei den SOL-Auszahlungen einzelner Inhaber allein anhand von Leistungsmessungen nicht beziffern lassen, wenn kontobezogene Belege fehlen. Inhabern, die ausgelassene Kommissionssätze prüfen, müssen Auszahlungen mit historischen Belegen abgleichen, deren zeitliche Zuordnung und Abdeckung überprüfbar sind.