Автор: Carlos, Luke Leasure
Оригинальное название: Solana’s block-building wars
Компиляция и редактирование: BitpushNews
5 января 2026 года JITO представила общедоступный инструмент под названием IBRL Explorer, предназначенный для измерения поведения валидаторов Solana при упаковке блоков и раскрытия ранее невидимой «игры со временем» в построении блоков.
Сначала нам нужно понять некоторый контекст о рыночной структуре Solana. Solana была разработана как потоковая система: в идеале, пока блок строится, лидер постоянно распространяет фрагменты данных (т.е. небольшие пакеты данных). Это поведение направлено на минимизацию задержки обработки транзакции (интервал между получением валидатором транзакции и её обработкой). Однако, является ли конвейер транзакций Solana truly непрерывным, на самом деле зависит от того, как валидаторы собирают свои блоки.
Jito с точки зрения валидатора определяет оптимальное поведение при упаковке блоков: быстрое построение, непрерывная потоковая передача, раннее распространение состояния. Балл IBRL от Jito представляет собой взвешенную смесь этих трёх переменных:
-
Время слота (35%): Валидатор получает более высокий балл, если его блок построен в пределах следующих порогов: слот, принятый от другого валидатора (handover slot) — менее 550 мс, или как непрерывный слот (т.е. любой оставшийся слот в очереди лидера) — менее 380 мс.
-
Упаковка неголосующих транзакций (40%): Валидатор получает бонусные баллы, когда транзакции равномерно распределены по 64 тикам слота (а не когда большинство неголосующих транзакций втискивается в последние несколько тиков слота, т.е. «отложенная упаковка»). Это самая спорная переменная в балле IBRL, которая будет объяснена подробнее далее.
-
Раннее голосование (25%): Валидатор получает полный балл, когда не менее 90% голосующих транзакций обрабатываются в первых 32 тиках. Балл уменьшается, если голосование откладывается на более позднюю часть блока.
IBRL Explorer показывает, что многие валидаторы практикуют отложенную упаковку неголосующих транзакций, в некоторых случаях даже увеличивая время слота. Отложенная упаковка задерживает распространение состояния, увеличивает дисперсию результатов выполнения, нарушает потоковый дизайн Solana и, следовательно, увеличивает сетевую задержку. Вместо постоянного потока данных вы получаете единовременный выброс данных.
В оптимальном блоке, как в примере от валидатора Helius ниже, большинство голосующих транзакций обрабатывается в первой половине блока («раннее распространение состояния»), а неголосующие транзакции относительно равномерно распределены по 64 тикам слота («непрерывная потоковая передача»).
По словам соучредителя и генерального директора Jito Labs Лукаса Брудера (Lucas Bruder), валидаторы имеют стимул ждать до последнего момента слота, чтобы наблюдать за большим количеством входящих транзакций, выбирать транзакции с самыми высокими комиссиями и, таким образом, максимизировать вознаграждение.
Но почему пользователям должно быть это важно? Хотя максимизация прибыли для отдельного валидатора является рациональным поведением, такое поведение вводит неявную цензуру, задерживает распространение состояния и вынуждает следующего лидера «догонять», тем самым замедляя всю сеть.
Что более важно, отложенная упаковка также напрямую связана с emerging динамикой «платежей за поток ордеров» (PFOF) в Solana, как outlined Бенедиктом Брэди (Benedict Brady) в этой статье. Поскольку кошельки и приложения часто генерируют предварительно маршрутизированные подписанные транзакции (т.е. рыночные ордера с ограничением проскальзывания), в ордера встроены ценные опционы на «бэкраннинг» (backrunning). Выгодно для пользователя — продать это право на бэкраннинг трейдинговым фирмам, в то время как экстракционная практика — это проведение «сэндвич-атак». В любом случае, существует мотивация замедлить обработку транзакций, чтобы увеличить ценность бэкраннинга, чего и добивается отложенная упаковка.
Такие стимулы подталкивают Solana к более враждебной рыночной структуре для приложений и пользователей. Это также подрывает ключевые гарантии, на которые полагаются маркет-мейкеры, особенно в отношении отмены внутри блока и детерминированного исполнения, что приводит к увеличению спредов. Без потоковой передачи, как бы хороша ни была логика приложения, настоящие рынки в реальном времени останутся недостижимыми для Solana.
Дебаты между Temporal и Jito
Прежде чем углубляться в то, как Solana может решить эту проблему, необходимо признать, что ведётся активная дискуссия о том, что такое «хорошее» построение блоков. Ключевой контрибьютор Harmonic, Temporal, оспорил framework Jito и методологию оценки IBRL. Их критика заключается в том, что этот балл внедряет определённые дизайнерские предпочтения, которые благоприятствуют способу построения блоков Jito и по умолчанию заставляют Harmonic выглядеть хуже, что отражается в consistently низких баллах валидаторов, работающих на Harmonic.
По словам соучредителя Harmonic, блоки Harmonic выполняются непрерывно без задержек, но фрагменты данных释放 (выпускаются) только после завершения аукциона, который длится около 300 мс. Этот метод даёт сборщику блока достаточно времени для конкуренции, а также остальной части сети достаточно времени для воспроизведения блока Harmonic. Визуализация ниже показывает тот же слот (391,822,619) от валидатора Temporal Emerald, работающего на Harmonic.
В контексте того, как распространяется блок (верхний график), выполнение Harmonic выглядит равномерно распределённым во времени. Другими словами, сборщик блока continuously строит блок через параллельное построение блоков, а транзакции сконцентрированы только в последних тиках (нижний график), потому что это момент resolution аукциона.
За последние 30 дней Harmonic превзошёл и Jito, и Firedancer по среднему и медианному общему доходу за блок (приоритетная комиссия + чаевые), тем самым принося более высокое вознаграждение валидаторам и стейкерам. Открытым остаётся вопрос, достигается ли это превосходство за счёт пользователей посредством описанной выше игры со временем.
Источник: https://reports.firedancer.io/
Многоконкурентные предложения (MCP) и BAM
После изложения обеих точек зрения остаётся верным одно: непрерывная потоковая передача至关重要 (чрезвычайно важна).
Утверждение Harmonic заключается не в том, что потоковая передача не важна, а в том, что IBRL не улавливает, как Harmonic её реализует, и может ошибочно классифицировать его аукционный механизм как «игру со временем». На данном этапе у меня нет достаточной технической背景ной информации или данных, чтобы сформировать чёткое мнение, но Solana уже разрабатывает внутрипротокольное решение, предназначенное для решения проблемы базовых стимулов.
Это решение — Многоконкурентные предложения (MCP), архитектура, разработанная Анатолием Яковенко (Anatoly Yakovenko) и Максом Ресником (Max Resnick). Мотивация проста: в современной модели с одним лидером один предлагающий контролирует ordering и может фактически действовать позже других, что позволяет осуществлять отложенную упаковку и усиливает описанную выше PFOF-подобную динамику. MCP устраняет монополию единственного лидера, позволяя нескольким предлагающим параллельно и независимо строить candidate блоки. Такая архитектура предотвращает возможность единоличного лидера подавлять транзакции или задерживать исполнение для извлечения прибыли.
Тем не менее, prerequisite для MCP является запуск Alpenglow в основной сети. Ожидается, что Alpenglow выйдет в 2026 году, но график remains uncertain. Тем временем, BAM от Jito может способствовать изменениям, делая логику ordering аудируемой. BAM aims расширить микроструктурное пространство проектирования Solana, позволяя приложениям, требующим более тонкого контроля ordering (например, приоритетная обработка ордеров на отмену на площадках perpetual contracts),同时也 помогая减轻 негативные внешние эффекты MEV, такие как front-running. На диаграмме ниже outlined конвейер транзакций BAM.
Стоит следить за тем, как будут развиваться конкурентные динамики построения блоков в ближайшие месяцы и что это будет означать для рыночной структуры Solana.
