Analyse : les données de récompenses de Solana omettent les taux de commission, compliquant la vérification des frais

Le logiciel Agave de Solana omet les taux de commission des métadonnées des récompenses lorsque des collecteurs personnalisés sont actifs, même si les versements de staking peuvent rester visibles. P2P.org a indiqué dans un rapport du 30 octobre que les enregistrements des récompenses de vote et de staking ne comportaient plus d'entrées de commission depuis le 8 septembre. P2P.org a précisé que les validateurs continuaient de prélever des commissions et que les montants des récompenses concordaient. Le problème concerne les éléments nécessaires pour expliquer les versements, et non un déficit de versement identifié. P2P.org a un intérêt commercial dans cette question, puisque le fournisseur propose des services de staking et de reporting.

La demande de fusion Agave #12588, intégrée le 20 mai, précise que l'omission se produit après l'activation de collecteurs personnalisés et concerne les commissions cumulées des validateurs ainsi que les récompenses individuelles de staking. Les informations concernées sur les récompenses sont accessibles aux utilisateurs par des requêtes sur les blocs et des abonnements. Le code de calcul d'Agave continue d'intégrer la commission au calcul des récompenses avant d'exclure le taux de l'enregistrement qui en résulte. L'absence de taux indique donc des métadonnées manquantes, et non une commission de zéro. SIMD-0232 permet aux validateurs d'acheminer les revenus de commission vers des comptes de collecte désignés sans modifier le calcul de la commission d'inflation.

La demande de fusion explique que les récompenses cumulées peuvent inclure des revenus acheminés vers un collecteur, de sorte qu'un taux de commission unique peut ne pas décrire adéquatement le total. Toutefois, l'implémentation supprime aussi le taux des récompenses individuelles de staking, réduisant les éléments disponibles pour vérifier un compte de staking donné. Le délai d'application des changements de commission sur Solana rend nécessaires les taux historiques pour effectuer cette vérification. Selon SIMD-0249, les récompenses acquises pendant l'époque E utilisent normalement un taux enregistré au début de E-1, le calcul intervenant au début de E+1. Les nouveaux comptes de vote peuvent utiliser l'état ultérieur du compte lorsque l'historique antérieur requis n'est pas disponible. Le dernier paramétrage d'un validateur peut donc différer du taux applicable à un versement antérieur.

Une discussion technique du 16 juillet a identifié des informations sur les commissions effectives et les collecteurs dans l'état d'exécution mis en cache, auxquelles les lectures ordinaires de comptes ne donnaient pas accès. Les développeurs ont indiqué que la règle de délai des commissions était déjà appliquée sur le réseau principal et ont évoqué la possibilité de traiter séparément la dépendance à l'état mis en cache. Le contributeur d'Agave ax-x2 a soumis le 18 octobre une demande concernant l'API RPC, expliquant que getVoteAccounts et les données analysées des comptes de vote exposent le dernier paramétrage, alors que les calculs de récompenses peuvent utiliser un taux enregistré. La demande propose une réponse facultative indiquant la commission d'inflation effective, l'époque concernée et le numéro de slot du bank. Au 30 octobre, la demande était toujours ouverte et aucune implémentation n'y était liée. L'exemple fourni associe un taux affiché faible à un taux enregistré élevé, mais ne fait état d'aucun incident observé impliquant un validateur et n'établit aucune surfacturation.

La vérification d'une commission historique nécessite de faire correspondre la période de récompense, la délégation du compte de staking au validateur et le taux retenu selon la règle historique applicable. La documentation de Jito sur son programme Validator History indique que celui-ci conserve l'historique des commissions et d'autres informations sur les validateurs sur une période allant jusqu'à 512 époques par validateur. L'instruction de copie de Jito enregistre la commission d'un compte de vote ainsi que l'époque et le slot, mais cette observation ne suffit pas à établir le taux effectif différé applicable à un versement donné. L'analyseur d'instantanés de Marinade accède plus directement aux informations mises en cache en extrayant la commission d'inflation des instantanés d'epoch-stakes et en publiant la date de référence de la valeur ainsi que des compteurs de valeurs de repli. Marinade avertit que les limites des archives et l'absence de métadonnées de date de référence dans les anciens fichiers de sortie limitent l'interprétation des taux enregistrés. L'analyseur propose une méthode de reconstitution, mais ne garantit pas que les archives soient complètes pour chaque compte et chaque époque.

La méthodologie APY de Trillium mesure les rendements liés à l'inflation à partir de la croissance des comptes de staking depuis l'époque 1070, en appliquant des contrôles d'éligibilité et des solutions de repli RPC plutôt qu'en se fondant sur la commission affichée. Trillium utilise d'autres méthodes pour les époques antérieures. Les gains nets peuvent donc rester mesurables sans vérification indépendante de la commission qui les a générés. Trillium considère qu'une absence d'éléments adaptés au niveau du compte donne un résultat inconnu, et non nul. Un relevé de revenus utile aux détenteurs de SOL ou aux produits de staking relierait les récompenses nettes à la période concernée, à la délégation au validateur et aux éléments attestant la commission effective, tout en indiquant les limites de la reconstitution ou de l'échantillonnage.

Une discussion d'octobre sur l'état de vote propose de conserver les taux de commission avec les époques auxquelles ils deviennent effectifs. La proposition concernant l'état de vote et la demande RPC toujours ouverte restent des solutions envisagées, et ne prouvent pas qu'une correction a été déployée. La commission d'inflation, la commission MEV et le partage des revenus des blocs sont des composantes distinctes ; rendre visible un taux ne permettrait donc pas d'expliquer l'ensemble du rendement du staking. Les informations publiées en septembre sur les crédits de vote liés aux récompenses ont également établi que les mesures de performance ne suffisaient pas à quantifier les pertes de versement en SOL d'un détenteur sans éléments au niveau du compte. Pour vérifier les taux de commission omis, les détenteurs doivent relier les versements à des données historiques dont le calendrier et la couverture peuvent être vérifiés.