Les enregistrements de récompenses de Solana laissent les stakers avec un vide dans les données des frais de validateur

Les paiements de staking de Solana peuvent rester visibles tandis que les frais de validateur, ou commission, qui les sous-tendent deviennent plus difficiles à vérifier. Agave laisse le champ du taux de commission vide dans les métadonnées de récompense lorsque des collecteurs personnalisés sont actifs, rendant la vérification des frais dépendante de l'état historique du validateur ainsi que des SOL reçus.

Dans un rapport du 30 octobre, le fournisseur de staking P2P.org a déclaré que l'enregistrement de la commission avait disparu à la fois des récompenses de vote et de staking depuis le 8 septembre. Il a indiqué que la commission continuait d'être facturée et que les montants des récompenses étaient toujours réconciliés. Le problème de rapport concerne la preuve expliquant un paiement, plutôt qu'un déficit identifié dans ce paiement.

P2P.org vend des services de staking et de reporting, ce qui lui confère un intérêt commercial dans la question.

Le taux derrière une récompense peut provenir d'une époque antérieure

Le changement a été explicite dans la demande de tirage Agave #12588, fusionnée le 20 mai. Cela rend le champ de commission vide après l'activation de la fonctionnalité de collecteur personnalisé, couvrant les récompenses de commission de validateur accumulées et les récompenses de mise individuelles. La PR décrit les charges de récompense orientées vers l'extérieur utilisées par les requêtes de blocs et les abonnements.

Un champ vide ne signifie pas qu'un validateur n'a pas facturé de commission. Cela signifie que ce morceau de métadonnées est indisponible. Le code de calcul actuel d'Agave passe toujours la commission dans le calcul des récompenses avant de la supprimer dans l'enregistrement des récompenses.

Les collecteurs personnalisés servent un objectif distinct. SIMD-0232, la spécification du protocole pour la fonctionnalité, permet aux validateurs de diriger les revenus de commission vers des comptes de collecte désignés. Il laisse explicitement le calcul de la commission d'inflation inchangé tout en définissant de nouvelles règles de collecte.

La justification de la PR est qu'une récompense accumulée peut combiner des revenus dirigés vers un collecteur, rendant un taux de commission unique inapproprié pour cet agrégat. La mise en œuvre supprime également le taux pour les récompenses de mise individuelles. Cela supprime une pièce de preuve pratique même lorsqu'un détenteur examine un compte de mise.

Les commissions historiques sont importantes car Solana retarde l'effet des mises à jour de taux à travers ses périodes de récompense, appelées époques. Selon la règle SIMD-0249, la séquence normale pour les récompenses gagnées dans l'époque E est : capturer le taux au début de E−1, gagner des récompenses pendant E, puis calculer ces récompenses au début de E+1. Les nouveaux comptes de vote ont des solutions de repli vers un état ultérieur lorsque l'historique du compte précédent n'existe pas.

Ce timing sépare le taux visible dans l'état de compte le plus récent d'un validateur du taux pertinent à une période de récompense particulière. Utiliser le paramètre le plus récent pour expliquer un paiement plus ancien peut sélectionner la mauvaise entrée.

Cette préoccupation de visibilité précède le rapport d'octobre. Une discussion d'ingénierie du 16 juillet a décrit les valeurs de commission et de collecteur effectives conservées dans l'état d'exécution mis en cache que les utilisateurs ne pouvaient pas inspecter via une lecture de compte ordinaire. Les développeurs ont déclaré que la règle de retard de commission était déjà active sur le mainnet et ont discuté de l'adresse de la dépendance à l'état mis en cache séparément.

Le contributeur d'Agave ax-x2 a soulevé la même distinction pratique dans une demande RPC du 18 octobre. Le problème indique que getVoteAccounts et les données de compte de vote analysées montrent le dernier paramètre tandis que le calcul des récompenses peut utiliser un taux enregistré. Il demande une réponse optionnelle contenant la commission d'inflation effective, son époque et le slot de la banque.

La demande est restée ouverte le 30 octobre, sans mise en œuvre liée. Son exemple d'un taux affiché bas aux côtés d'un taux enregistré élevé illustre un modèle possible ; il n'identifie pas un incident de validateur observé ni n'établit une surfacturation.

Lier un paiement historique à sa commission nécessite donc plus que le reçu : la période de récompense, la délégation du compte de mise à un validateur et le taux sélectionné par la règle historique applicable. Ces enregistrements doivent décrire le même paiement. Une observation de commission historique provenant de la mauvaise limite est toujours le mauvais taux.

Les outils historiques peuvent aider à connecter le paiement et le taux

Le programme d'historique des validateurs de Jito documente jusqu'à 512 époques d'histoire par validateur, y compris la commission. Son instruction de copie lit la commission à partir d'un compte de vote et enregistre l'époque et le créneau. Cela peut préserver les observations historiques, mais l'instruction seule n'établit pas qu'une observation est égale au taux effectif retardé utilisé pour un paiement particulier.

Le parseur de snapshot du protocole de mise Marinade documente un chemin plus direct vers l'état mis en cache utilisé pour la sélection de la commission. Il extrait la commission d'inflation des snapshots de mises d'époque et publie l'ancienneté de la valeur, ainsi que des compteurs de secours.

Ces détails comptent autant que le taux lui-même. Marinade met en garde contre les limites d'archive et les anciens fichiers de sortie sans métadonnées d'ancienneté. Un nombre stocké sans son contexte de capture ne peut pas être supposé en toute sécurité représenter le taux effectif. Le parseur documenté fournit une méthode de reconstruction, plutôt qu'une garantie qu'une archive complète est disponible pour chaque compte et époque.

Le fournisseur de données Trillium adopte une approche différente pour mesurer ce que les délégués ont gagné. Sa méthodologie APY décrit la mesure du retour d'inflation à partir de la croissance du compte de mise à partir de l'époque 1070, en utilisant des vérifications d'éligibilité et des secours RPC sans se fier à la commission affichée. Les époques antérieures utilisent des méthodes différentes.

Cette distinction est utile : mesurer les gains nets peut rester possible même lorsque la commission appliquée est absente d'un enregistrement de récompense. Mais mesurer le retour ne vérifie pas indépendamment la commission qui l'a produite. Trillium distingue également un résultat inconnu de zéro lorsque des preuves de compte appropriées sont manquantes.

Pour un détenteur de SOL ou un produit de mise, un enregistrement de revenu utile relierait la récompense nette à sa période, à la délégation du validateur et aux preuves de commission effective. Lorsque la reconstruction ou l'échantillonnage est impliqué, cet enregistrement doit également préciser ses limites de couverture.

Il existe des propositions pour faciliter la connexion. Une discussion sur l'état de vote d'octobre envisage de stocker les taux de commission aux côtés des époques où ils prennent effet. La demande RPC ouverte cherche à avoir une vue du taux effectif déjà utilisé par le runtime. Les deux restent des remèdes proposés dans ces enregistrements ; aucun n'établit un correctif déployé.

La portée compte également. La commission d'inflation, la commission MEV et le partage des revenus de bloc sont des composants séparés. Restaurer la visibilité sur un taux ne suffirait pas à expliquer chaque partie d'un retour de mise.

La couverture de CryptoSlate en septembre sur les crédits de vote liés aux récompenses a fait une distinction connexe : les mesures de performance ne pouvaient pas être converties en perte de paiement SOL d'un détenteur individuel sans preuve au niveau du compte. Le reporting de commission nécessite la même prudence quant à ce qu'une mesure prouve réellement.

Un enregistrement de récompense qui omet sa commission appliquée laisse un détenteur avec plus de travail : relier le paiement au bon taux historique, en utilisant des preuves dont le timing et la couverture peuvent être vérifiés. P2P.org dit que les récompenses se réconcilient. Expliquer la commission derrière ces récompenses nécessite ce lien supplémentaire.

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.