Análisis: Solana omite las tasas de comisión en los registros de recompensas y complica su verificación

El software Agave de Solana omite las tasas de comisión de los metadatos de recompensas cuando hay recolectores personalizados activos, aunque los pagos de staking pueden seguir siendo visibles. P2P.org dijo en un informe del 30 de octubre que los registros de recompensas por voto y staking carecían de entradas de comisiones desde el 8 de septiembre. P2P.org afirmó que los validadores siguieron cobrando comisiones y que los importes de las recompensas cuadraban. El problema afecta a las pruebas necesarias para explicar los pagos, no a un déficit de pagos identificado. P2P.org tiene un interés comercial en el asunto porque el proveedor ofrece servicios de staking y de generación de informes.

La solicitud de cambios de Agave #12588, incorporada el 20 de mayo, especifica la omisión tras la activación de recolectores personalizados, tanto para las comisiones acumuladas de los validadores como para las recompensas de participaciones individuales. La información afectada sobre las recompensas llega a los usuarios mediante consultas y suscripciones a bloques. El código de cálculo de Agave sigue incluyendo la comisión en el cálculo de las recompensas antes de excluir la tasa del registro resultante. Por tanto, que no aparezca una tasa indica que faltan metadatos, no que la comisión cobrada sea cero. SIMD-0232 permite a los validadores dirigir los ingresos por comisiones a cuentas de cobro designadas sin cambiar el modo en que se calcula la comisión por inflación.

La solicitud de cambios explica que las recompensas acumuladas pueden combinar ingresos dirigidos a un recolector, por lo que una sola tasa de comisión quizá no describa adecuadamente el total. Sin embargo, la implementación también elimina la tasa de las recompensas de participaciones individuales, lo que reduce las pruebas disponibles para verificar una cuenta de participación concreta. El retraso de Solana en la aplicación de cambios de comisión hace necesarias las tasas históricas para la verificación. Según SIMD-0249, las recompensas obtenidas durante la época E normalmente usan una tasa registrada al inicio de E-1; el cálculo se realiza al inicio de E+1. Las cuentas de voto recién creadas pueden usar el estado posterior de la cuenta cuando no se dispone del historial anterior requerido. En consecuencia, la configuración más reciente de un validador puede diferir de la tasa aplicable a un pago anterior.

Un debate de ingeniería del 16 de julio identificó información sobre comisiones efectivas y recolectores en el estado de ejecución en caché, que las lecturas ordinarias de cuentas no podían revelar. Los desarrolladores dijeron que la regla de retraso de las comisiones ya operaba en la red principal y analizaron cómo resolver por separado la dependencia del estado en caché. El colaborador de Agave ax-x2 presentó el 18 de octubre una solicitud para RPC en la que explicaba que getVoteAccounts y los datos analizados de las cuentas de voto muestran la configuración más reciente, aunque los cálculos de recompensas pueden usar una tasa guardada. La solicitud propone una respuesta opcional que muestre la comisión efectiva por inflación, la época pertinente y el intervalo del banco. El 30 de octubre, la solicitud seguía abierta y no tenía una implementación vinculada. El ejemplo de la solicitud combina una tasa mostrada baja con una tasa guardada alta, pero no identifica ningún incidente observado con un validador ni demuestra que se hayan cobrado comisiones excesivas.

Verificar una comisión histórica requiere cotejar el período de la recompensa, la delegación del validador de la cuenta de participación y la tasa elegida según la regla histórica aplicable. La documentación del programa Validator History de Jito describe el historial de comisiones y otros datos de los validadores, con una cobertura de hasta 512 épocas por validador. La instrucción de copia de Jito registra la comisión de una cuenta de voto junto con la época y el intervalo, pero esa observación por sí sola no demuestra cuál era la tasa efectiva con el retraso aplicable a un pago concreto. El analizador de instantáneas de Marinade accede de forma más directa a la información en caché: extrae la comisión por inflación de las instantáneas de epoch-stakes y publica la antigüedad del dato y los contadores de valores alternativos. Marinade advierte que los límites de los archivos históricos y la falta de metadatos sobre la antigüedad en los archivos de salida más antiguos limitan la interpretación de las tasas almacenadas. El analizador ofrece una técnica de reconstrucción, no garantiza que existan archivos completos para todas las cuentas y épocas.

La metodología de APY de Trillium mide los rendimientos por inflación mediante el crecimiento de las cuentas de participación desde la época 1070, aplicando comprobaciones de elegibilidad y alternativas de consulta RPC en lugar de la comisión mostrada. Trillium usa otros métodos para épocas anteriores. Por tanto, los ingresos netos pueden seguir midiéndose sin verificar de forma independiente la comisión que los generó. Trillium considera que la falta de pruebas adecuadas en la cuenta arroja un resultado desconocido, no cero. Un registro de ingresos útil para los titulares de SOL o los productos de staking vincularía las recompensas netas con el período pertinente, la delegación del validador y las pruebas de la comisión efectiva, y revelaría los límites de la reconstrucción o el muestreo.

Una discusión de octubre sobre el estado de voto propone conservar las tasas de comisión junto con las épocas en que entran en vigor. La propuesta sobre el estado de voto y la solicitud RPC abierta siguen siendo soluciones propuestas, no pruebas de que se haya implementado una corrección. La comisión por inflación, la comisión de MEV y el reparto de los ingresos por bloques son componentes distintos, por lo que hacer visible una tasa no explicaría el rendimiento total del staking. La cobertura de septiembre sobre los créditos de voto vinculados a las recompensas también estableció que las mediciones de rendimiento, por sí solas, no podían cuantificar la pérdida de pagos en SOL de un titular concreto sin pruebas a nivel de cuenta. Para comprobar las tasas de comisión omitidas, los titulares deben relacionar los pagos con pruebas históricas cuyos plazos y cobertura puedan verificarse.