Что такое Preconfirmations (Preconfs) в Solana?

Жизненный цикл транзакции внутри лидера

Ниже намеренно узко рассматривается жизненный цикл транзакции внутри лидера в контексте Preconfirmations и наблюдаемости. Полное описание жизненного цикла транзакции в Solana приведено в нашем техническом обзоре виртуальной машины Solana (SVM).

До лидера

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

На этом этапе транзакцию видят только отправитель и RPC-нода или сервис доставки транзакций, который передает ее текущему и следующим лидерам. 

На этой стадии судьбу транзакции определить невозможно. 

Этап 1: прием и SigVerify

Модуль обработки транзакций (TPU) лидера принимает входящие транзакции в виде пакетов, десериализует их, проверяет подписи и отбрасывает дубликаты. При высокой нагрузке некорректные пакеты и спам-транзакции отбрасываются до потребления дополнительных ресурсов.

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

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

Этап 2: планировщик

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

По сути, планировщик проводит транзакции через три основных этапа:

1. Буферизация и приоритизация

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

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

2. Планирование 

Управляющий цикл в контроллере планировщика последовательно извлекает из контейнера транзакции с наивысшим приоритетом, проверяет конфликты блокировок аккаунтов и объединяет транзакции в пакеты для исполнения.

Начиная с Agave 2.3, используется алгоритм greedy scheduler. Он заменил прежнюю архитектуру prio-graph после того, как тестирование показало, что жадный подход формирует блоки с меньшими накладными расходами.

3. Передача 

Запланированный пакет передается через канал исполняющему воркеру. Теперь лидер выделил этой транзакции реальные ресурсы: поток воркера, блокировки аккаунтов и место в формируемом блоке.

На этом этапе транзакция все еще ожидает исполнения. Лидер намерен ее исполнить, но исполнение еще не началось, поэтому сообщать результат пока нельзя. Preconfirmations появляются на следующем этапе.

Чем архитектура планировщика Firedancer отличается от Agave?

Firedancer достигает того же момента с помощью немного другой архитектуры. Вместо потоков с общей памятью Firedancer использует изолированные tiles, связанные очередями в общей памяти, а логика планирования находится в pack tile. 

Pack tile хранит все ожидающие транзакции, отслеживает аккаунты, занятые каждым bank tile, и выбирает неконфликтующие транзакции с максимальными комиссиями. Затем он формирует из них микроблоки и передает их bank tiles для исполнения. 

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

Этап 3: исполнение

Воркеры в Agave или bank tiles в Firedancer исполняют запланированный пакет транзакций в текущем bank: загружают аккаунты, запускают программы и фиксируют результаты.

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

Именно в этот момент отправляется Preconfirmation. Лидер передает каждую транзакцию сразу после ее исполнения вместе со статусом — до записи результатов в entry и задолго до того, как данные блока покинут машину.

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

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

Однако Preconfirmation не позволяет определить, станет ли блок с транзакцией каноническим. Этот блок еще не разбит на shreds, не распространен и за него не проголосовали. 

Поэтому Preconfirmations — это сигнал, а не гарантия.

Этап 4: Proof of History и entries

Исполненные пакеты записываются в поток Proof of History для создания entries — хешированных пакетов транзакций, встроенных в проверяемые часы лидера. Entries — нативный формат реестра, но на этом этапе они существуют только на машине лидера.

Для всех, кроме лидера, наблюдаемость фактически равна нулю.

Обратите внимание: Proof of History будет удален в обновлении Alpenglow, поскольку Rotor и Votor устранят необходимость в децентрализованных часах в Solana. Модель Preconfirmations не изменится: лидеры по-прежнему будут исполнять транзакции до их распространения, поэтому самым ранним наблюдаемым сигналом останутся локальные результаты исполнения у лидера. 

Этап 5: разделение на shreds и рассылка

Entries нарезаются на shreds — фрагменты размером с MTU, к которым применяется кодирование с исправлением стираний для устойчивости к потерям. Эти shreds подписываются и рассылаются через взвешенное по стейку дерево Turbine.

Именно здесь наблюдаемость становится полной. Shreds — первый артефакт конкретного блока, покидающий машину лидера. Поэтому все остальные продукты раннего доступа к данным в Solana, включая потоки shreds, начинают работу на этом этапе. Восстановление транзакций из shreds работает быстро относительно уровней подтверждения RPC, но медленнее Preconfirmation, поскольку лидер исполняет транзакцию еще до появления shreds. 

Далее валидаторы воспроизводят блок, голосуют, а транзакции последовательно проходят уровни подтверждения processed, confirmed и finalized. 

Какое место Preconfirmations занимают на шкале задержки?

Preconfirmations — самый быстрый сигнал в Solana по сравнению со всеми остальными, включая необработанные и декодированные shreds, LaserStream и другие методы потоковой передачи данных. 

Однако Preconfs лучше рассматривать как ступень на шкале задержки, где каждая ступень обменивает определенную степень полноты или достоверности на более раннее наблюдение.

От самого раннего к самому позднему:

Из этой таблицы следуют два вывода. 

Во-первых, все эти сигналы дополняют друг друга, а не служат прямой заменой.

Например, Preconfirmations сообщают о только что исполненной лидером транзакции еще до того, как о ней узнает сеть, а сообщение LaserStream показывает произошедшее с полным набором метаданных.

Рабочим системам обычно нужны оба источника: они реагируют на Preconfirmations и используют последующие сигналы для проверки.  

Во-вторых, интервалы между ступенями неодинаковы.

Переход от processed-потоков к shreds экономит несколько миллисекунд, а переход от shreds к Preconfirmations пропускает оставшуюся часть конвейера производства блока — запись entries, разделение на shreds и распространение. Точка наблюдения перемещается от первого публичного артефакта блока к результатам, существующим только внутри лидера. 

В результате Preconfirmations примерно на 5–50 миллисекунд быстрее shreds. 

Модель доверия Preconfirmations: сигнал, а не гарантия

Все, что обещает Preconfirmation, можно выразить одним предложением: лидер исполнил эту транзакцию с таким результатом. Из этого же предложения следует все, чего Preconf не обещает.

Исполненная транзакция еще не является попавшей в сеть: содержащий ее блок не разбит на shreds, не распространен и за него не проголосовали. Этот блок все еще может быть пропущен или исключен из-за форка до подтверждения сетью. Почти все транзакции с Preconfirmation успешно попадают ончейн. Однако любая система, реагирующая на Preconfirmations, должна проверять результат другими средствами наблюдения, прежде чем считать его окончательным.

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

Если сервисам необходим непрерывный охват как абсолютная гарантия, при возникновении пробелов следует переключаться на LaserStream или Shred Delivery.

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

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

Например, ликвидационному боту не нужна безошибочная гарантия попадания транзакции, за нарушение которой можно применить слешинг. Ему нужно узнать результат конкретной транзакции на несколько миллисекунд раньше конкурентов.

Как работают Helius Preconfirmations?

Helius Preconfirmations доставляются через одну подписку WebSocket. Клиент может подключиться к нашей конечной точке Gatekeeper (то есть wss://beta.helius-rpc.com) и отправить запрос preconfSubscribe:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "preconfSubscribe",
  "params": [
    {
      "failed": false,
      "regionInclude": ["ewr", "fra"],
      "accountInclude": ["TARGET_WALLET_ADDRESS"],
      "accountExclude": [],
      "accountRequired": []
    }
  ]
}

Фильтры применяются на стороне сервера по аккаунтам (include, exclude, required), региону и статусу. Поддерживаются таблицы поиска (LUT), поэтому подписчик получает и оплачивает только запланированные транзакции, относящиеся к его стратегии. 

Поскольку Preconfirmations отправляются после исполнения, фильтр статуса работает с фактическими результатами: failed: false. Это означает, что неудачные транзакции никогда не передаются и не тарифицируются.

Тарификация основана на кредитах и соответствует другим подпискам Helius WebSocket: 10 кредитов за сообщение и одно сообщение на каждую переданную транзакцию. Функция доступна на планах Professional и выше. 

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

Формат намеренно минималистичен: фиксированный заголовок можно декодировать за наносекунды без разбора JSON в критическом пути. Единственный JSON, необходимый при таком обмене, — удобное подтверждение подписки. 

Обратите внимание, что Preconfirmation — лишь половина операции. Возможность первым увидеть транзакцию важна, только если ответ тоже попадет в сеть первым. Поэтому мы также запустили Sender Max — самый производительный уровень Helius Sender.

Sender Max направляет отправку — одну транзакцию или атомарный пакет до четырех транзакций — по всем доступным высокоскоростным маршрутам и помещает ее в буфер приоритетных чаевых, отдающий предпочтение самым высоким чаевым. Минимальный размер чаевых — 0,001 SOL.

Получайте сигналы с preconfSubscribe, доставляйте транзакции с Sender Max.  

Что можно создать с помощью Preconfirmations?

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

Снайпинг

Создание новых пулов и запуск токенов становятся видимыми сразу после исполнения развертывающей транзакции внутри лидера. Снайпер, использующий Preconfirmations, реагирует, пока наблюдатели за shreds еще ждут первые фрагменты блока. 

Копитрейдинг

Движения целевого кошелька появляются в потоке Preconfirmations в момент их исполнения лидером. Фильтрация по адресу цели с помощью accountInclude превращает поток в специализированный зеркальный канал и позволяет увидеть движения раньше других копитрейдеров.

Ликвидации

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

Маркетмейкинг и propAMMs

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

Во всех случаях Preconfirmations сдвигают момент реакции стратегии с «после того, как узнает сеть» на «в момент исполнения лидером».

Зарабатывайте на пересылке Preconfirmations

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

Чем больше участвующего стейка, тем шире охват. Заинтересованные валидаторы могут связаться с нами и найти дополнительную информацию в нашей документации по Preconfirmations для валидаторов. 

Чем Ethereum Preconfs отличаются от Solana Preconfs?

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

Ethereum Preconfirmations

В Ethereum Preconfirmations — в исследовательской литературе их часто называют based preconfs; эту архитектуру впервые сформулировал Justin Drake в 2023 году — представляют собой обязательства по включению. До начала своего слота предлагающая сторона обещает включить транзакцию в будущий блок, а обещание подкрепляется экономическим механизмом, например слешингом. 

Существует несколько действующих реализаций: 

• MEV-Commit от Primev — маркетплейс, где кошельки, поисковые агенты и intent-протоколы предлагают поставщикам исполнения (то есть сборщикам блоков и секвенсорам) плату за обязательства
• ETHGas — экономически обеспеченная сеть Preconfirmation
• Bolt от Chainbound, предлагающий не требующие разрешений обязательства предлагающей стороны, совместимые с MEV-Boost

Главные особенности Ethereum Preconfirmations:

• Они относятся к вашей собственной транзакции
• Выдаются до исполнения
• Оптимизированы для определенности

Ethereum Preconfirmations гарантируют попадание вашей транзакции еще до того, как оно фактически произойдет.

Ethereum требуется этот механизм из-за способа построения блоков. Большинство предлагающих сторон в последний момент передают построение блока через аукцион MEV-Boost, поэтому до завершения аукциона нельзя достоверно обещать ничего, связанного с блоком. Однако в Solana такого разрыва никогда не было. Расписание лидеров известно заранее, мемпул отсутствует, а один лидер непрерывно принимает, упорядочивает, исполняет и передает свой блок в пределах слота. Ранний сигнал, который Ethereum приходится создавать с помощью экономической инфраструктуры, изначально существует в конвейере производства блоков Solana — его нужно было лишь открыть.

Solana Preconfirmations

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

Главные особенности Solana Preconfirmations:

• Охватывают транзакции всех пользователей
• Отправляются после исполнения
• Оптимизированы для минимальной задержки

Solana Preconfirmations позволяют увидеть исполненные транзакции на несколько миллисекунд раньше, чем их обнаружит сеть через shreds или запросы RPC со стандартными уровнями подтверждения.

Ближайший аналог Ethereum Preconfirmation для резервирования места в блоке в Solana — маркетплейс вычислительных единиц Raiku для Ahead-of-Time (AOT) Transactions, позволяющий приложениям гарантированно резервировать включение в будущие блоки.

Заключение

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

Если вы создаете систему, чувствительную к задержке — для снайпинга, копитрейдинга, ликвидаций, маркетмейкинга или поиска возможностей, — подпишитесь через preconfSubscribe, настройте фильтры для нужных аккаунтов, реагируйте на сигналы с помощью Sender Max и проверяйте результат стандартными средствами подтверждения.

Полное описание подписки, формат сообщений и примеры интеграции доступны в нашей документации по Preconfirmations.