Краткий обзор

1. Agave оставляет метаданные о комиссии пустыми при использовании пользовательских коллекторов, даже несмотря на то, что расчет вознаграждения по-прежнему использует коэффициент.
2. Текущие настройки валидатора могут отличаться от исторических значений, которые важны для расчета вознаграждения за стейкинг в определенную эпоху.
3. Jito и Marinade предоставляют инструменты для работы с историческими данными, в то время как предлагаемые изменения RPC направлены на обеспечение более четкой информации об эффективной комиссии.

Информация о выплатах за стейкинг в Solana может оставаться доступной, в то время как проверка комиссии, лежащей в основе этих выплат, становится более сложной. Agave оставляет поле, содержащее информацию о коэффициенте комиссии, пустым в метаданных о вознаграждениях, когда активны пользовательские коллекторы, что делает проверку комиссии зависимой как от исторических данных о состоянии валидатора, так и от полученного количества SOL.

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

Компания P2P.org предоставляет услуги по стейкингу и отчетности, что создает коммерческий интерес к данной проблеме.

Коэффициент, лежащий в основе вознаграждения, может быть получен из предыдущей эпохи

Изменение было четко указано в запросе на внесение изменений в Agave #12588, который был принят 20 мая. Он делает поле комиссии пустым после активации функции пользовательских коллекторов, охватывая накопленные комиссии валидатора и индивидуальные вознаграждения за стейкинг. В описании этого изменения говорится о структуре данных, используемой для запросов блоков и подписок, которая передает информацию о вознаграждениях.

Пустое поле не означает, что валидатор не взимал комиссию. Это означает, что эта часть метаданных недоступна. Текущий код расчета в Agave по-прежнему передает информацию о комиссии в процесс расчета вознаграждения, прежде чем скрывать ее в записи о вознаграждении.

Пользовательские коллекторы служат другой цели. SIMD-0232, спецификация протокола для этой функции, позволяет валидаторам направлять доход от комиссии на определенные счета коллекторов. Он явно оставляет расчет инфляционной комиссии без изменений, определяя при этом новые правила для коллекторов.

Обоснование этого изменения заключается в том, что совокупное вознаграждение может включать доход, направленный на коллектор, что делает единый коэффициент комиссии неадекватным для этой совокупной суммы. Реализация также скрывает коэффициент для индивидуальных вознаграждений за стейкинг. Это удаляет удобный элемент доказательства, даже когда владелец просматривает один счет для стейкинга.

Комиссия, учитываемая исторической системой, важна, поскольку Solana откладывает применение изменений в ставках в течение периодов начисления вознаграждений, называемых "эпохами". Согласно правилу SIMD-0249, обычная последовательность начисления вознаграждений за эпоху E выглядит следующим образом: фиксируется ставка в начале эпохи E-1, вознаграждения начисляются в течение эпохи E, а затем эти вознаграждения рассчитываются в начале эпохи E+1. Новые учетные записи для голосования имеют механизмы отката к более ранним состояниям, когда история этих учетных записей отсутствует.

Такая временная разница разделяет ставку, отображаемую в последнем состоянии учетной записи валидатора, и ставку, актуальную для определенного периода начисления вознаграждений. Использование самой новой информации для объяснения более ранней выплаты может привести к выбору неверных данных.

Эта проблема, связанная с видимостью информации, существовала еще до отчета, опубликованного в октябре. В обсуждении, проведенном 16 июля, речь шла об эффективных значениях комиссии и сборщика, хранящихся во временной памяти, к которым пользователи не могли получить доступ обычным способом чтения учетной записи. Разработчики заявили, что правило задержки комиссии уже действует в основной сети, и предложили решить проблему зависимости от временной памяти отдельно.

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

Запрос оставался открытым 30 октября, без каких-либо связанных реализаций. Пример, приведенный в запросе, демонстрирующий низкую отображаемую ставку и высокую сохраненную ставку, иллюстрирует возможную ситуацию, но не указывает на конкретный инцидент с валидатором или завышение платежей.

Таким образом, для сопоставления исторической выплаты с ее комиссией требуется больше, чем просто получение информации о выплате: необходим период начисления вознаграждений, делегирование учетной записи стейкинга валидатору и ставка, выбранная в соответствии с применимым историческим правилом. Все эти записи должны описывать одну и ту же выплату. Историческое значение комиссии, полученное с неправильной границы, все равно будет неверным.

Инструменты для работы с историческими данными могут помочь связать выплату и ставку.

Программа [Validator History Program] от Jito (https://www.jito.network/docs/stakenet/validator-history/program-overview/) хранит до 512 эпох истории для каждого валидатора, включая информацию о комиссии. Инструкция копирования считывает комиссию из учетной записи для голосования и записывает эпоху и номер блока. Это позволяет сохранять исторические данные, но сама инструкция не гарантирует, что полученное значение соответствует задержанной эффективной ставке, используемой для конкретной выплаты.

Протокол стейкинга Marinade предоставляет инструмент для анализа снимков данных, который позволяет получить доступ к кэшированным данным, используемым для определения размера комиссии. Он извлекает информацию о размере инфляционной комиссии из снимков данных за определенные эпохи и публикует информацию о времени получения этих данных, а также дополнительные параметры.

Эти детали важны не меньше, чем сама ставка. Marinade предупреждает о границах архивов и устаревших файлах, не содержащих метаданные о времени получения данных. Нельзя безопасно предполагать, что число, хранящееся без информации о контексте его получения, соответствует фактической ставке. Представленный инструмент предоставляет метод восстановления данных, а не гарантию наличия полного архива для каждого аккаунта и эпохи.

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

Это различие важно: оценка чистой прибыли может быть возможна даже в тех случаях, когда информация о примененной комиссии отсутствует в записи о вознаграждении. Однако, оценка доходности не подтверждает самостоятельно размер комиссии, которая ее сформировала. Trillium также различает неизвестный результат и ноль, когда отсутствуют необходимые данные об аккаунте.

Для владельца SOL или продукта для стейкинга полезной записью о доходах была бы запись, связывающая чистую прибыль с периодом, валидатором, которому была делегирована доля, и информацией о фактической комиссии. В случаях, когда используются методы восстановления или выборки данных, эта запись также должна четко указывать на ограничения охвата.

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

Область применения также имеет значение. Инфляционная комиссия, комиссия за MEV и распределение дохода от блоков – это отдельные компоненты. Восстановление информации об одной ставке не позволит полностью объяснить все составляющие доходности от стейкинга.

В статье CryptoSlate, опубликованной в сентябре, делается аналогичное замечание: для преобразования показателей производительности в фактические убытки от выплат в SOL для конкретного владельца необходимы данные на уровне аккаунта. Отчетность о комиссиях требует такой же тщательности в определении того, что именно показывает измерение.

Запись о вознаграждении, в которой отсутствует информация о примененной комиссии, создает дополнительные трудности для владельца: необходимо связать выплату с соответствующей исторической ставкой, используя данные, время получения и охват которых можно проверить. P2P.org утверждает, что вознаграждения должны быть согласованы. Для объяснения комиссии, лежащей в основе этих вознаграждений, необходима эта дополнительная связь.