Анализ: в записях о вознаграждениях Solana нет ставок комиссий, что затрудняет проверку сборов

В программном обеспечении Agave для Solana ставки комиссий не указываются в метаданных вознаграждений при использовании пользовательских счетов для сбора средств, хотя данные о выплатах за стейкинг могут оставаться видимыми. P2P.org сообщила в отчете от 30 октября, что с 8 сентября в записях о вознаграждениях за голосование и стейкинг отсутствуют сведения о комиссиях. По словам P2P.org, валидаторы продолжали взимать комиссии, а суммы вознаграждений сходились. Проблема касается сведений, необходимых для объяснения выплат, а не выявленной нехватки выплат. У P2P.org есть коммерческий интерес в этом вопросе, поскольку компания предлагает услуги стейкинга и отчетности.

Запрос на изменение Agave № 12588, принятый 20 мая, указывает, что данные не включаются после активации пользовательских счетов для сбора средств; это касается накопленных комиссий валидатора и вознаграждений по отдельным стейкам. Информация о затронутых вознаграждениях поступает пользователям через запросы к блокам и подписки. Код Agave для расчетов продолжает передавать комиссию в расчет вознаграждения, прежде чем исключить ставку из итоговой записи. Поэтому отсутствие ставки означает нехватку метаданных, а не нулевую комиссию. SIMD-0232 позволяет валидаторам направлять комиссионный доход на указанные счета для сбора средств, не меняя способ расчета комиссии за инфляционные вознаграждения.

В запросе на изменение говорится, что накопленные вознаграждения могут включать доход, направленный на счет для сбора средств, поэтому одна ставка комиссии может не описывать общую сумму должным образом. Однако реализация также удаляет ставку из записей об отдельных стейках, сокращая доступные сведения для проверки отдельного стейк-счета. Из-за отложенного применения изменений комиссий в Solana для проверки необходимы исторические ставки. Согласно SIMD-0249, вознаграждения, полученные в эпоху E, обычно рассчитываются по ставке, зафиксированной в начале эпохи E-1; расчет производится в начале эпохи E+1. В новых аккаунтах голосования может использоваться более позднее состояние аккаунта, если необходимая история за более ранний период недоступна. Поэтому последняя настройка валидатора может отличаться от ставки, применимой к более ранней выплате.

В ходе инженерного обсуждения 16 июля были выявлены сведения об эффективной комиссии и счетах для сбора средств в кэшированном состоянии среды исполнения, недоступные при обычном чтении аккаунта. Разработчики заявили, что правило задержки применения комиссии уже действует в основной сети, и обсудили отдельное решение проблемы зависимости от кэшированного состояния. Участник разработки Agave ax-x2 18 октября подал запрос на изменение RPC, пояснив, что getVoteAccounts и разобранные данные аккаунтов голосования показывают последнюю настройку, хотя при расчете вознаграждений может использоваться сохраненная ставка. В запросе предлагается добавить необязательные данные ответа об эффективной комиссии за инфляционные вознаграждения, соответствующей эпохе и слоте банка. На 30 октября запрос оставался открытым, связанная с ним реализация отсутствовала. В примере к запросу низкая отображаемая ставка сопоставлена с высокой сохраненной ставкой, однако в нем не говорится о выявленном инциденте с каким-либо валидатором и не устанавливается факт завышенного взимания комиссий.

Для проверки исторической комиссии необходимо сопоставить период вознаграждения, делегирование стейк-счета валидатору и ставку, выбранную в соответствии с применимым историческим правилом. В документации программы Jito Validator History указано, что она хранит историю комиссий и другие сведения о валидаторах максимум за 512 эпох для каждого валидатора. Инструкция копирования Jito сохраняет комиссию аккаунта голосования вместе с эпохой и слотом, однако эта запись сама по себе не устанавливает отложенную эффективную ставку для конкретной выплаты. Парсер снимков Marinade получает кэшированные сведения более прямым способом: извлекает комиссию за инфляционные вознаграждения из снимков данных об эпохах и публикует временную метку значения и счетчики резервных обращений. Marinade предупреждает, что границы архивов и старые выходные файлы без метаданных о временной метке ограничивают интерпретацию сохраненных ставок. Парсер предлагает способ восстановления данных, но не гарантирует полноту архивов для каждого аккаунта и каждой эпохи.

Методология APY Trillium оценивает доходность от инфляционных вознаграждений по росту стейк-счетов начиная с эпохи 1070, применяя проверки соответствия условиям и резервные варианты через RPC вместо отображаемой комиссии. Для более ранних эпох Trillium использует другие методы. Поэтому чистый доход может поддаваться измерению без независимой проверки комиссии, за счет которой он был получен. Если подходящих данных по аккаунту нет, Trillium считает результат неизвестным, а не нулевым. Запись о доходе, полезная держателям SOL или продуктам для стейкинга, должна связывать чистые вознаграждения с соответствующим периодом, делегированием валидатору и сведениями об эффективной комиссии, раскрывая при этом ограничения восстановления данных или выборки.

В октябрьском обсуждении состояния голосования предлагается сохранять ставки комиссий вместе с эпохами, в которые эти ставки вступают в силу. Предложение об изменении состояния голосования и открытый запрос на изменение RPC остаются возможными решениями, а не свидетельством внедренного исправления. Комиссия за инфляционные вознаграждения, комиссия MEV и распределение доходов от блоков — разные составляющие, поэтому отображение одной ставки не объяснит всю доходность стейкинга. Сентябрьский анализ вознаграждений, связанных с кредитами за голосование, также показал, что одни лишь показатели эффективности не позволяют оценить потери выплат в SOL для отдельного держателя без данных на уровне аккаунта. Чтобы проверить неуказанные ставки комиссий, держателям необходимо сопоставить выплаты с историческими сведениями, время и охват которых можно проверить.