Analisi: i record delle ricompense di Solana omettono le commissioni, complicando i controlli

Il software Agave di Solana omette le commissioni dai metadati delle ricompense quando sono attivi collector personalizzati, anche se i pagamenti dello staking possono restare visibili. P2P.org ha affermato in un rapporto del 30 ottobre che nei record delle ricompense di voto e staking mancavano le voci relative alle commissioni dall'8 settembre. P2P.org ha detto che i validatori hanno continuato ad applicare commissioni e che gli importi delle ricompense tornavano. Il problema riguarda le prove necessarie a spiegare i pagamenti, non un ammanco individuato nei pagamenti stessi. P2P.org ha un interesse commerciale nella questione, poiché il provider offre servizi di staking e rendicontazione.

La pull request di Agave #12588, integrata il 20 maggio, specifica che l'omissione avviene dopo l'attivazione dei collector personalizzati e riguarda le commissioni accumulate dai validatori e le singole ricompense dello staking. Le informazioni sulle ricompense interessate raggiungono gli utenti tramite interrogazioni e sottoscrizioni ai blocchi. Il codice di calcolo di Agave continua a fornire la commissione al calcolo della ricompensa prima di escludere l'aliquota dal record risultante. L'assenza dell'aliquota indica quindi metadati mancanti, non una commissione pari a zero. SIMD-0232 consente ai validatori di indirizzare i proventi delle commissioni verso conti di raccolta designati senza modificare il calcolo delle commissioni sull'inflazione.

La pull request spiega che le ricompense accumulate possono combinare proventi indirizzati a un collector, per cui un'unica aliquota potrebbe non descrivere adeguatamente il totale. Tuttavia, l'implementazione rimuove l'aliquota anche dai singoli record delle ricompense dello staking, riducendo le prove disponibili per verificare un singolo conto di staking. Il ritardo con cui Solana applica le modifiche alle commissioni rende necessarie le aliquote storiche per la verifica. In base a SIMD-0249, le ricompense maturate durante l'epoch E usano normalmente un'aliquota registrata all'inizio di E-1; il calcolo avviene all'inizio di E+1. I nuovi conti di voto possono usare uno stato successivo del conto quando la cronologia precedente necessaria non è disponibile. Di conseguenza, l'impostazione più recente di un validatore può differire dall'aliquota applicabile a un pagamento precedente.

Il 16 luglio una discussione tecnica ha individuato informazioni sulle commissioni effettive e sui collector nello stato di runtime memorizzato nella cache, non visibili nelle normali letture dei conti. Gli sviluppatori hanno affermato che la regola sul ritardo delle commissioni era già in funzione sulla rete principale e hanno discusso di come risolvere separatamente la dipendenza dallo stato memorizzato nella cache. Il collaboratore di Agave ax-x2 ha presentato il 18 ottobre una richiesta RPC spiegando che getVoteAccounts e i dati analizzati dei conti di voto mostrano l'impostazione più recente, mentre i calcoli delle ricompense possono usare un'aliquota salvata. La richiesta propone una risposta facoltativa che mostri la commissione effettiva sull'inflazione, l'epoch pertinente e lo slot della bank. Il 30 ottobre la richiesta era ancora aperta e non era collegata ad alcuna implementazione. L'esempio della richiesta abbina un'aliquota visualizzata bassa a un'aliquota salvata alta, ma non segnala alcun episodio osservato che coinvolga un validatore né dimostra che siano state applicate commissioni eccessive.

Per controllare una commissione storica occorre abbinare il periodo della ricompensa, la delega del conto di staking al validatore e l'aliquota scelta secondo la regola storica applicabile. La documentazione del programma Validator History di Jito descrive dati storici sulle commissioni e su altri aspetti dei validatori, relativi a un massimo di 512 epoch per validatore. L'istruzione di copia di Jito registra la commissione di un conto di voto insieme all'epoch e allo slot, ma questa rilevazione da sola non dimostra quale fosse l'aliquota effettiva ritardata per un determinato pagamento. L'analizzatore di snapshot di Marinade accede più direttamente alle informazioni memorizzate nella cache, estraendo le commissioni sull'inflazione dagli snapshot epoch-stakes e pubblicando la data di riferimento del valore e i contatori di fallback. Marinade avverte che i confini degli archivi e i file di output meno recenti, privi dei metadati sulla data di riferimento, limitano l'interpretazione delle aliquote memorizzate. L'analizzatore offre una tecnica di ricostruzione, non la garanzia che gli archivi siano completi per ogni conto ed epoch.

La metodologia APY di Trillium misura i rendimenti da inflazione attraverso la crescita dei conti di staking a partire dall'epoch 1070, applicando controlli di idoneità e fallback RPC anziché basarsi sulle commissioni visualizzate. Per gli epoch precedenti, Trillium usa altri metodi. Gli utili netti possono quindi essere misurabili anche senza verificare in modo indipendente la commissione che li ha generati. Trillium considera la mancanza di prove adeguate sui conti come un risultato sconosciuto, non come zero. Un registro dei proventi utile ai possessori di SOL o ai prodotti di staking collegherebbe le ricompense nette al periodo pertinente, alla delega al validatore e alle prove sulla commissione effettiva, indicando i limiti della ricostruzione o del campionamento.

Una discussione di ottobre sullo stato di voto propone di conservare le aliquote delle commissioni insieme agli epoch in cui diventano effettive. La proposta sullo stato di voto e la richiesta RPC ancora aperta restano rimedi proposti, non prove di una correzione già implementata. Le commissioni sull'inflazione, le commissioni MEV e la condivisione dei ricavi dei blocchi sono componenti distinte: rendere visibile un'aliquota non spiegherebbe quindi l'intero rendimento dello staking. Anche l'analisi di settembre dei crediti di voto legati alle ricompense ha stabilito che le sole misurazioni delle prestazioni non permettevano di quantificare la perdita di pagamenti in SOL per un singolo possessore senza prove a livello di conto. Chi detiene SOL e verifica le commissioni omesse deve collegare i pagamenti a prove storiche di cui sia possibile verificare tempistica e copertura.