SIMD-0677 soll fünf Epochen Validator-Provision on-chain festhalten
Serguey Asael Shinder2 Min. LesezeitEin neues Solana Improvement Document, SIMD-0677, schlägt vor, jedem Vote-Konto eines Validators eine kurze Provisionshistorie hinzuzufügen. Der Entwurf, am 30. September von Umar Bhatty eröffnet und mit dem Status „Idea“ versehen, ist eine Kernänderung, die das Format Vote Account V4 aus SIMD-0185 erweitert.
Das Problem. SIMD-0249, im Mainnet-Beta seit Epoche 991 aktiv, verzögert jede Provisionsänderung um eine volle Epoche: Inflationsbelohnungen einer Epoche werden mit der Provision berechnet, die zu Beginn der vorherigen Epoche im Vote-Konto stand. SIMD-0123 wendet dieselbe Regel auf die Provision aus Blockeinnahmen an. Damit wurde verhindert, dass Validatoren die Provision kurz vor der Ausschüttung anheben – doch laut Entwurf hat sich verändert, was das Vote-Konto aussagt. Die beiden Provisionsfelder zeigen nun die Sätze, die zwei Epochengrenzen später gelten, falls sich nichts ändert, nicht die gerade berechneten. Die tatsächlich wirksamen Sätze existieren nur in den Epoch-Stakes-Schnappschüssen im Speicher jedes Validators und sind über kein Konto, keine Sysvar und keinen Syscall lesbar.
Das hat laut Vorschlag drei Folgen. Ein On-Chain-Programm kann die wirksame Provision eines Validators nicht kennen, obwohl Stake-Pools und Bewertungssysteme für Liquid Staking Validatoren auch danach auswählen. Off-Chain lässt sich der wahre Satz nur rekonstruieren, wenn man das Konto an jeder der letzten beiden Grenzen erfasst hat. Und ein Validator kann die Verzögerung weiter ausnutzen: Provision anheben, eine Epoche halten, wieder senken – jeder einzelne Schnappschuss wirkt unauffällig, und on-chain wird die Abfolge nirgends festgehalten. Der Autor schreibt, das von ihm betriebene Bewertungssystem führe dafür eine eigene Historie mit zehn Einträgen, gepflegt über einen Crank, der jede Epoche laufen muss.
Das Design. VoteStateV4 bekäme ein Feld commission_history. An jeder Epochengrenze schreibt die Runtime einen Eintrag – die Epochennummer sowie die Provision für Inflationsbelohnungen und für Blockeinnahmen in Basispunkten, die für sie gilt – und behält die letzten fünf. Jeder Eintrag belegt 12 Byte, das Feld also höchstens 68 Byte, und die feste Kontogröße von 3.762 Byte bleibt unverändert, weil V4 durch das Entfernen älterer Felder Platz frei gemacht hat. Schreiben darf nur die Runtime; Validatoren können die Einträge also nicht fälschen.
Der Autor versteht das als Übergangslösung. Ein separater Vorschlag, SIMD-0511, würde die stakegewichteten Epochendaten umfassender offenlegen, aber erst nach der Konsensänderung Alpenglow und nur für die zugelassenen Validatoren.
Was das bedeutet
Der Vorschlag steht ganz am Anfang und kann sich ändern oder liegen bleiben. Sein Wert liegt darin, eine Lücke zu benennen, die die Verzögerung der Provision geschaffen hat: Die Zahl, die Delegierende am dringendsten brauchen, zeigt die Kette nicht. Würde er angenommen, könnten Stake-Pools ihre eigenen Cranks aufgeben und ein einziges Konto lesen.