P-Token: новый большой шаг к эффективности Solana

Введение

Один из недооцененных факторов быстрого распространения Solana — безопасный, простой и стандартизированный подход к токенам. В отличие от многих других блокчейнов, для создания токена в Solana не нужно развертывать собственный контракт. Вместо этого все операции выполняются через тщательно аудированную и проверенную на практике программу SPL Token (также известную как Tokenkeg), изначально развернутую Solana Labs. Такой подход упрощает стандартные действия, включая выпуск, сжигание и перевод токенов. Например, токен Solana можно развернуть одной командой CLI.

SPL Token — самая используемая программа в Solana после System program. За последние шесть месяцев в среднем через программу SPL Token еженедельно создавалось от 200 000 до 300 000 новых взаимозаменяемых токенов. Это в 20 раз больше, чем двумя годами ранее, в сентябре 2023 года, когда еженедельно создавалось менее 10 000 новых SPL-токенов. В целом, за исключением 2023 года, каждый год с момента запуска Solana количество выпущенных новых токенов значительно росло, как показано на диаграмме ниже.

Количество переводов SPL-токенов выросло еще заметнее. За последние три месяца еженедельное количество переводов стабильно превышало 650 миллионов и достигло пика в 867,8 миллиона в конце июля. Это в 17,5 раза больше минимального показателя в 49,4 миллиона еженедельных переводов, зафиксированного в начале августа 2023 года.

Знакомство с P-Token

P-token — оптимизированная для вычислений полноценная замена текущей программе SPL Token. Команда Anza впервые предложила ее в марте в документе SIMD-0266: эффективная программа токенов. Она значительно сокращает потребление вычислительных единиц (CU) и при этом сохраняет полную обратную совместимость с существующими SPL-токенами. 

Поскольку p-token в точности воспроизводит набор инструкций и структуру аккаунтов программы SPL Token, ее можно использовать как прямую замену. Это означает, что p-token — не новый стандарт токенов. Клиентский код продолжает работать без изменений, поэтому переход значительно повышает эффективность и не требует доработок со стороны приложений или пользователей.

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

Недавний успех проприетарных AMM в Solana демонстрирует эффект снижения вычислительных затрат и преимущества высокоэффективных программ. Например, обновления оракулов на таких платформах, как HumidiFi, были гипероптимизированы до всего 143 CU. Doppler, новая программа оракула с открытым исходным кодом от BlueShift, снижает затраты еще сильнее — до 21 CU.

Pinocchio

Буква «p» в названии p-token означает Pinocchio — разработанную Anza оптимизированную и производительную библиотеку без зависимостей для создания программ Solana. Pinocchio заменяет стандартный крейт solana-program, активно использующий типы с нулевым копированием для обработки данных инструкций и аккаунтов. При нулевом копировании данные во время чтения или записи не дублируются в новые области памяти. Вместо этого доступ к состоянию осуществляется напрямую через указатели. Такой подход существенно сокращает вычислительные затраты, поскольку исключает ненужные операции с памятью, а также снижает накладные расходы среды выполнения.

Pinocchio также поддерживает no_std. Это означает, что библиотека не зависит от стандартной библиотеки Rust и выделения памяти в куче, поскольку Solana Virtual Machine (SVM) уже предоставляет среду выполнения. Это дополнительно оптимизирует исполнение и сокращает количество зависимостей, делая программы компактнее и быстрее.

Повышение эффективности

CU измеряют стоимость выполнения в среде Solana. Самая простая операция, например сложение двух целых чисел или побитовая операция, потребляет 1 CU. Лимит составляет 200 тысяч CU на инструкцию и 1,4 миллиона CU на транзакцию.

P-Token значительно повышает эффективность, сокращая потребление CU стандартными транзакциями SPL-токенов примерно на 95% — то есть повышая эффективность в 19 раз. Более быстрое выполнение улучшает пользовательский опыт, а высвобождение вычислительных ресурсов позволяет включать в каждый блок больше транзакций и напрямую повышает пропускную способность сети.

Сегодня инструкции программы Token потребляют около 10% всех CU блока. Если сократить их стоимость до 5% от текущего уровня, p-token снизит эту долю с 10% до 0,5% и освободит еще 9,5% емкости блока для других транзакций. P-token также полезна для зависимых программ: снижение общего потребления CU и стоимости межпрограммных вызовов (CPI) улучшает компонуемость.

Ниже в виде диаграмм и таблиц представлены данные о повышении эффективности CU инструкций p-token по сравнению с текущей программой SPL Token.

Еще одна заметная оптимизация, во многом реализованная благодаря `no_std`, — сокращение размера бинарного файла программы со 131 КБ до 95 КБ.

Дополнительные инструкции

P-token предлагает добавить в программу токенов три новые инструкции (`withdraw_excess_lamports`, `batch` и `unwrap_lamports`), которых нет в исходной программе SPL Token.

Вывод избыточных лампортов

Как и в текущей реализации SPL Token-2022, `withdraw_excess_lamports` позволяет вернуть избыточные SOL, «заблокированные» в аккаунте выпуска. Обычно это происходит, когда пользователь по ошибке отправляет лампорты на аккаунт выпуска токена.

Для вывода требуется авторизация со стороны полномочия выпуска: назначенного подписанта для стандартных аккаунтов выпуска или multisig для аккаунтов multisig. Поскольку у большинства SPL-токенов полномочие выпуска отозвано, для авторизации можно использовать сам аккаунт выпуска как подписывающее полномочие и подписать инструкцию закрытым ключом выпуска.

Среди всех аккаунтов выпуска SPL-токенов примерно 869 000 содержат больше SOL, чем минимальный порог освобождения от ренты, равный 0,0014616 SOL. В общей сложности в аккаунтах выпуска токенов заблокировано 176 961,5 SOL, что по текущему курсу составляет 36 миллионов долларов США. Наибольшие объемы SOL, заблокированные в аккаунтах выпуска токенов, обычно связаны с мемкоинами, устаревшими токенами и крупными первоклассными активами. Самый большой объем SOL, заблокированный в аккаунте выпуска одного токена, принадлежит мемкоину BOOK OF MEME ($BOME) и составляет 6 328 SOL. Внедрение p-token потенциально позволит разблокировать эти балансы и принесет неожиданную выгоду командам, стоящим за такими токенами.

Пакетное выполнение

Вторая новая инструкция — `batch`, которая упрощает взаимодействие CPI с программой p-token. Вместо многократного вызова программы токенов `batch` позволяет выполнить переменное количество инструкций токенов за один вызов. Поэтому базовые затраты CPI в 1 000 единиц возникают только один раз, а не для каждой отдельной инструкции.

В результате протоколы, использующие несколько CPI токенов в одной инструкции, значительно сокращают вычислительные затраты. Такой подход распространен в DeFi на Solana. Например, AMM может выполнить два перевода в рамках свопа, а внесение средств в пул ликвидности может включать как переводы, так и выпуск токенов. Используя `batch`, программы могут значительно экономить CU в подобных сценариях.

Развертывание лампортов

Инструкция `unwrap_lamports` (недавно добавленная в отдельном PR) позволяет напрямую переводить лампорты на целевой аккаунт без создания временных аккаунтов нативных токенов.

Ранее для развертывания лампортов из аккаунта обернутого SOL требовалось создать, а затем закрыть связанный аккаунт токена (ATA) получателя. После этого обновления лампорты можно напрямую переводить из аккаунтов нативного SOL, что упрощает процесс.

Быстрый путь для инструкций перевода

Анализ использования программы токенов в mainnet показывает высокую концентрацию вокруг инструкций перевода, на которые в совокупности приходится почти половина всей активности. Пять наиболее часто используемых инструкций:

• transfer_checked (36,33%)
• transfer (13,22%)
• close_account (12,23%)
• initialize_account3 (9,98%)
• initialize_immutable_owner (9,78%)

Такой характер использования открывает возможность дополнительно оптимизировать p-token для переводов и сократить потребление CU. Значительную часть этой работы по оптимизации выполнил Cavey из Temporal. Подробнее о подходе можно узнать в его прямой трансляции в X.

Чтобы добиться такого улучшения, p-token добавляет собственную точку входа с быстрым путем для инструкций перевода и обновляет обработчик, чтобы отдать приоритет `sync_native` и `initialize_immutable_owner`. Вместе эти изменения значительно повышают эффективность использования CU с учетом наблюдаемых сценариев.

Логирование

С появлением p-token остается открытым вопрос о сохранении текущего механизма логирования. Последняя версия предложения рекомендует удалить логи. В Solana логи — основной механизм извлечения из программ данных для отладки, мониторинга и событий. В существующей программе токенов логи минимальны и ограничиваются выводом названия выполняемой инструкции. Например:

Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA invoke [1],
Program log: Instruction: TransferChecked,
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA consumed 6281 of 7738 compute units,
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA success

Однако эта, казалось бы, короткая строка лога `Instruction: <name>` стоит около 103 вычислительных единиц. На практике эти накладные расходы могут потреблять почти столько же ресурсов, сколько сама инструкция. Например, при простом переводе на логирование приходится около 40% от общего объема необходимых вычислений.

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

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

Аудит

Аудит программы p-token уже проводится, чтобы гарантировать полную обратную совместимость и безопасность. Для внедрения p-token должна строго соответствовать точным инструкциям и структуре аккаунтов текущей программы Token и полностью воспроизводить ее поведение. Любое отклонение создаст риск, поэтому проводятся всестороннее тестирование и независимые аудиты.

Аудиторы Neodyme провели тестирование эквивалентности, дважды повторно выполнив каждую транзакцию mainnet за последние месяцы: сначала с исходной программой токенов, а затем с p-token. Результаты подтвердили идентичность выходных данных и одновременно продемонстрировали значительную экономию CU.

Согласно их анализу, с 3 по 11 августа 2025 года p-token могла бы сократить накладные расходы на 8,9 триллиона CU при включенном логировании и на 9,14 триллиона CU при отключенном. Это соответствует экономии 12,0% и 12,3% от общего использования пространства блоков соответственно.

Сейчас p-token проходит второй аудит у Zellic и формальную верификацию у Runtime Verification.

Развертывание

План развертывания p-token предусматривает поэтапный подход. Сначала завершаются аудит, фаззинг и формальная верификация. Затем валидаторы голосуют по вопросу внедрения p-token и формального принятия SIMD 266. После этого функция p-token будет развернута в кластере и помещена за переключатель функций.

Сначала программа будет развернута в указанном аккаунте (ptokN…UkkZ2). После активации переключателя функций на границе эпохи среда выполнения на всех валидаторах заменит существующую программу токенов (Tokenkeg…VQ5DA) новой реализацией с помощью Upgradable Loader v3.

Альтернативный подход — развернуть программу p-token по новому адресу, что потребует ручной миграции от пользователей и приложений. Однако этот вариант не предпочтителен, поскольку он, скорее всего, замедлит внедрение и уменьшит общую пользу: многие пользователи не захотят переходить или сделают это не сразу.

Экономический эффект

Внедрение p-token — одно из ряда улучшений, которые могут значительно увеличить общую емкость Solana и позволить включать больше транзакций в каждый блок. Среди других важных обновлений — удвоение пространства блока до 100 миллионов CU и повышение лимита CU на аккаунт с фиксированных 12 миллионов до 40% блока.

Сейчас один аккаунт ограничен 12 миллионами CU на блок. Как показано на приведенной ниже диаграмме от Anza, самый востребованный аккаунт в каждом блоке часто достигает этого лимита. Даже одна p-token усложнит достижение этого лимита аккаунтами и сократит частоту узких мест для активно используемого состояния.

Сегодня почти все транзакции включают либо приоритетную комиссию, либо чаевые Jito, чтобы стимулировать валидаторов включить их в блок. Поскольку приоритет определяется комиссией за CU, транзакция p-token, потребляющая меньше CU, при прочих равных должна получать более высокий приоритет за ту же комиссию или чаевые. Однако поскольку обновление p-token принесет пользу всем транзакциям SPL-токенов, его общее влияние на приоритизацию транзакций еще предстоит оценить.

Заключение

Если p-token пройдет голосование по управлению, ее внедрение станет важным шагом к повышению эффективности и масштабируемости Solana. Радикально сокращая вычислительные затраты и упрощая взаимодействия CPI, она укрепляет основу самой используемой программы сети и одновременно увеличивает общую емкость блоков. В случае успеха p-token может стать образцом для разработки оптимизированных с помощью Pinocchio версий других широко используемых программ, включая программу Associated Token Account (ATA) и даже System program. Это откроет путь к более быстрой и эффективной среде выполнения.

Дополнительные ресурсы

• Репозиторий p-token — GitHub
• Репозиторий Pinocchio — GitHub
• Библиотека программ Solana (SPL) — GitHub
• Калькулятор экономии SOL с p-Token — SendAI