Данные раскрывают: задержки переводов Solana, оказывается, связаны с "подковерными играми" валидаторов?

Автор: Carlos 、 Luke Leasure

Оригинал: Solana’s block-building wars

Перевод и редакция: BitpushNews

5 января 2026 года JITO запустила публичный инструмент под названием IBRL Explorer, предназначенный для оценки поведения валидаторов при формировании блоков в Solana и выявления ранее невидимых “игр по времени” в процессе построения блоков.

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

Jito определяет оптимальное поведение при формировании блоков с точки зрения валидатора: быстрая сборка, непрерывная потоковая передача и раннее распространение состояния. Баллы IBRL — это взвешенная смесь этих трех переменных:

• Slot время (35%): если блок валидатора сформирован в пределах следующего порога — менее 550 мс после передачи другого валидатора, или в рамках последовательного slot (то есть оставшийся в ротации лидер в slot) — менее 380 мс.
• Не-голосовые транзакции (40%): когда транзакции равномерно распределены по 64 тактам slot (а не сосредоточены в последних нескольких тактах, что называется “задержка упаковки”), валидатор получает баллы. Это наиболее спорный показатель в IBRL, о чем будет подробно рассказано далее.
• Раннее голосование (25%): если как минимум 90% голосующих транзакций обрабатываются в первых 32 тактах, валидатор получает максимальный балл. Если голосование откладывается на более поздние части блока, баллы снижаются.

IBRL Explorer показывает, что у многих валидаторов наблюдается задержка при упаковке не-голосовых транзакций, а в некоторых случаях даже увеличивается время slot. Задержка упаковки откладывает распространение состояния, увеличивает дисперсию результатов выполнения, нарушая потоковую архитектуру Solana и снижая задержку сети. В результате, вместо постоянного потока данных, мы получаем всплески данных.

В идеальном блоке, как показано на примере валидатора из Helius, большинство голосовых транзакций обрабатывается в первой половине блока (“раннее распространение состояния”), а не-голосовые транзакции равномерно распределены по 64 тактам (“непрерывная потоковая передача”).

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

По словам соучредителя и CEO Jito Labs Lucas Bruder, валидаторы мотивированы ждать до последнего момента в slot, чтобы наблюдать за большим количеством входящих транзакций и выбирать те, что платят наибольшие комиссии, чтобы максимизировать награды.

Но зачем это важно пользователям? Хотя для отдельного валидатора максимизация прибыли — рациональное поведение, оно вводит скрытую цензуру, задержки распространения состояния и вынуждает следующего лидера “догонять”, замедляя всю сеть.

Более того, задержка упаковки напрямую связана с развивающейся динамикой “Order Flow Payment” (PFOF) в Solana, как уже было описано Benedict Brady. Поскольку кошельки и приложения обычно генерируют заранее маршрутизированные подписанные транзакции (например, рыночные ордера с ограничением скольжения), в заказах заложены ценные “опционы на последующую обработку”. Выгодно продавать эти опционы торговым компаниям, а вредно — проводить “срединные атаки”. В любом случае, существует мотивация замедлить подтверждение транзакций, чтобы увеличить ценность последующей обработки — именно это позволяет реализовать задержка упаковки.

Такая мотивация толкает Solana к более противоречивой рыночной структуре, ориентированной на приложения и пользователей. Это также подрывает ключевые гарантии маркет-мейкеров, особенно в части отмены и детерминированного исполнения внутри блока, что ведет к расширению спредов. Без потоковой передачи, несмотря на превосходство логики приложений, реальный рынок в реальном времени для Solana остается недостижимым.

Дебаты между Temporal и Jito

Прежде чем углубляться в то, как Solana решает эти проблемы, необходимо признать, что существует активная дискуссия о том, что такое “хорошая” сборка блоков. Основной участник Harmonic, Temporal, выразил несогласие с рамками Jito и методом оценки IBRL. Их критика заключается в том, что этот показатель встроен в определенные предпочтения дизайна, выгодные для способа формирования блоков Jito, и предполагает, что Harmonic выглядит хуже, что отражается в постоянно низких оценках валидаторов, использующих Harmonic.

По словам соучредителя Harmonic, их блоки выполняются без задержек, а фрагменты данных раскрываются только после примерно 300 мс аукциона. Такой подход дает создателям блоков достаточно времени для конкуренции и позволяет остальной части сети воспроизвести их блоки. Ниже показана визуализация блока, сформированного валидатором Harmonic, Temporal Emerald, в том же slot (391,822,619).

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

За последние 30 дней Harmonic в среднем и по медиане по доходам (приоритетные сборы + чаевые) превосходит Jito и Firedancer, принося валидаторам и стейкерам более высокие награды. Вопрос в том, является ли это превосходство результатом описанных выше игр по времени, жертвуя интересами пользователей.

Источник: https://reports.firedancer.io/

Множественные предложители (MCP) и BAM

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

Заявление Harmonic не в том, что потоковая передача не важна, а в том, что IBRL не учитывает, как Harmonic реализует ее, и может ошибочно классифицировать их аукцион как “игру по времени”. На текущем этапе у меня недостаточно технических знаний или данных, чтобы сформировать окончательное мнение, но Solana уже разрабатывает протокольное решение для устранения внутренних стимулов.

Это решение — Множественные предложители (MCP), разработанное Анатолием Яковенко и Максом Ресником. Мотивация проста: в текущей модели с одним лидером один предложитель контролирует порядок, и фактически может действовать позже других, реализуя задержку упаковки и усиливая описанную динамику PFOF. MCP устраняет монополию одного лидера, позволяя нескольким предложителям параллельно и независимо формировать кандидатные блоки. Такая архитектура предотвращает одностороннее подавление транзакций или задержку исполнения для извлечения прибыли.

Предпосылка MCP — запуск Alpenglow в основной сети. Ожидается, что Alpenglow будет запущен в 2026 году, но сроки еще не определены. Тем временем, BAM от Jito может способствовать изменениям, сделав логику сортировки аудитируемой. BAM предназначен для расширения микроструктурного пространства Solana, позволяя приложениям, требующим более тонкого контроля порядка (например, отмены ордеров на платформах perpetual), а также снижая негативные внешние эффекты MEV, такие как front-running. Ниже — схема транзакционного конвейера BAM.

BAM (Agave-BAM) уже занимает третье место среди клиентов Solana по доле стейкинга (около 12%), уступая только Agave-Jito и Frankendancer-Jito. Около 205 валидаторов уже используют BAM, что подчеркивает его быстрое распространение среди валидаторов Solana. В то время как масштаб Harmonic остается относительно небольшим — чуть более 3% доли стейка и около 20 валидаторов.

Будет интересно наблюдать за развитием конкуренции при формировании блоков в ближайшие месяцы и что это значит для рыночной структуры Solana.