Gulf Stream в Solana: больше мемпула — больше проблем

Практические выводы

• Термин «Gulf Stream» можно условно определить как процесс, который начинается в момент получения транзакции нодой сети и завершается, когда транзакция достигает лидера текущего слота и попадает на этап Fetch в TPU (модуле обработки транзакций).
• Solana выделяется тем, что изначально проектировалась для работы без мемпула. В отличие от более традиционных блокчейнов, которые используют gossip-протоколы для широкого распространения транзакций по сети, Solana пересылает все транзакции заранее определённому ведущему валидатору, известному как лидер, для каждого слота. Лидер меняется каждые 4 слота, а расписание лидеров заранее известно всем активным нодам сети, что обеспечивает эффективную пересылку транзакций.
• По умолчанию транзакции Solana должны содержать недавний хеш блока, который разработчики могут легко запросить с помощью простого вызова API. Недавний хеш блока действителен до 150 слотов — примерно 1 минуту. После этого он устаревает, а ссылающиеся на него транзакции удаляются сетью. Благодаря этому необработанные транзакции не задерживаются в сети. Недавние хеши блоков также помогают устранять дубликаты транзакций. Разработчики могут добавлять долговечные nonce.
• В Gulf Stream транзакции кодируются и отправляются лидеру через потоки QUIC. Переход на QUIC в конце 2022 года стал важным обновлением сети и заменил использовавшиеся ранее соединения UDP. Основной целью этого изменения было улучшить способность сети фильтровать спам. Однако переход на QUIC оказался неоднозначным решением на фоне беспрецедентной активности в Solana в течение 2024 года.
• Внедрение взвешенного по стейку качества обслуживания (SWQoS) в начале 2024 года существенно изменило путь транзакций к лидеру через Gulf Stream. Теперь лидеры отдают приоритет сообщениям о транзакциях, перенаправленным через другие валидаторы со стейком. В частности, 80% пропускной способности лидера (2 000 соединений) зарезервировано для участников со стейком, а оставшиеся 20% (500 соединений) выделены сообщениям о транзакциях от нод без стейка.
• Сейчас более 80% стейка в Solana заблокировано у валидаторов, использующих клиент Jito-Solana вместо исходного клиента Agave. Jito добавляет внепротокольный аукцион пространства блока, что дополнительно усложняет путь транзакций к лидеру. В частности, Jito Relayer добавляет 200-миллисекундный «лежачий полицейский», замедляющий поток входящих сообщений о транзакциях. Это даёт поисковикам достаточно времени для отправки пакетов транзакций.

Введение

Термин «Gulf Stream» появился в серии вводных публикаций в блоге, написанных командой основателей Solana в 2019 году. В них многие инновационные механизмы Solana получили названия, связанные с авиацией. В этих публикациях Gulf Stream определялся как «протокол Solana для пересылки транзакций без мемпула». Однако сегодня поиск термина «Gulf Stream» в кодовой базе Solana возвращает лишь одно незначительное упоминание.

В более широком контексте жизненного цикла транзакции Solana под Gulf Stream можно понимать весь процесс с момента получения транзакции нодой сети, обычно RPC-нодой, до её поступления лидеру текущего слота, то есть до этапа Fetch в TPU. Gulf Stream также можно представить как зеркальное отражение Turbine — механизма распространения блоков в Solana. Через Gulf Stream транзакции поступают лидеру, а через Turbine обработанные транзакции покидают его.

Сначала полезно определить роль RPC (Remote Procedure Call)-нод в контексте Solana. Их можно считать шлюзами для взаимодействия с сетью и чтения данных из неё. Они выступают посредниками между пользователями и валидаторами Solana. RPC-ноды используют то же программное обеспечение, что и полноценные валидаторы, но с другими настройками. Благодаря этому они могут точно симулировать транзакции и поддерживать актуальное представление о текущем состоянии — банке. Однако RPC-ноды не имеют стейка и поэтому не участвуют в консенсусе. Без стейка они не могут голосовать или создавать блоки. Это отличается от многих других блокчейнов, где валидаторы и RPC-ноды обычно выполняют одни и те же функции. В контексте Gulf Stream роль RPC можно описать так: получение транзакций по HTTP, преобразование их для передачи через QUIC (подробнее об этом далее), поиск адреса и порта текущего лидера по расписанию лидеров и пересылка транзакции текущему и следующему лидерам.

С момента запуска сети Gulf Stream получил как минимум два крупных обновления: QUIC и взвешенное по стейку QoS. Подробнее о них мы расскажем далее. Кроме того, эта часть основного протокола, вероятно, испытывала наибольшую нагрузку в последние годы из-за беспрецедентного объёма сетевого трафика Solana. Для понимания масштаба: когда валидатор становится лидером, входящий трафик может резко превысить гигабайт в секунду, поскольку вся сеть направляет ему пакеты. Обработка столь интенсивного входящего потока данных — сложнейшая инженерная задача.

Больше мемпула — больше проблем

Исходное определение Gulf Stream от команды основателей подчёркивает отсутствие мемпула. Мемпул — буквально «пул памяти» — можно определить как набор транзакций, отправленных пользователями и ожидающих обработки сетью. Пока они находятся в открытом доступе, эти транзакции обычно не шифруются и не скрываются. Они распространяются по всей сети с помощью gossip-протокола. В зависимости от сети подписанные транзакции потенциально могут оставаться в мемпуле неограниченно долго, пока не будут выполнены условия их исполнения. Особенно это касается транзакций, для которых комиссия — цена за единицу вычислений — установлена значительно ниже обычного диапазона рыночных ставок. В крайних случаях исполнение таких транзакций может занять дни или недели, если условия сети не способствуют их включению в блок.

В Solana такой сценарий невозможен: здесь не только отсутствует нативная концепция мемпула, но и все сообщения о транзакциях должны содержать недавний хеш блока. Разработчики могут легко запросить недавний хеш блока с помощью вызова JSON RPC API к методу getLatestBlockhash. Этот хеш блока встраивается в сообщение о транзакции и действителен до 150 слотов, то есть примерно 1 минуту, поскольку целевая длительность каждого слота составляет 400 миллисекунд. Через 150 слотов хеш блока устаревает, и ссылающиеся на него транзакции удаляются сетью. По умолчанию RPC-ноды пытаются пересылать транзакции каждые 2 секунды, но после истечения срока действия недавнего хеша блока транзакция удаляется и гарантированно никогда не будет исполнена ончейн.

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

Система Gulf Stream в Solana возможна благодаря тому, что всем активным нодам всегда заранее известно расписание лидеров. Ноды обновляют расписания лидеров каждый раз, когда высота слота пересекает границу эпохи, то есть примерно каждые 2 дня. Расписание лидеров для эпохи вычисляется на основе состояния реестра в начале предыдущей эпохи. Алгоритм его формирования выглядит так:

• Периодически использовать высоту тика Proof of History (PoH), то есть монотонно возрастающий счётчик, как начальное значение стабильного псевдослучайного алгоритма.
• На этой высоте получить из банка выборку всех аккаунтов со стейком и идентификаторами лидеров, которые голосовали в пределах заданного кластером количества тиков. Эта выборка называется активным набором.
• Отсортировать активный набор по весу стейка.
• Использовать случайное начальное значение, чтобы выбрать ноды с учётом веса стейка и сформировать взвешенный по стейку порядок.
• Этот порядок вступает в силу через заданное кластером количество тиков.

Источник: официальная документация Solana

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

Распределение ресурсов с учётом стейка регулярно используется в основном протоколе Solana, включая вознаграждения за голосование, деревья Turbine, расписания лидеров и gossip-сеть*. Gulf Stream также использует взвешивание по стейку, о чём мы расскажем далее.

Примечание о QUIC

Первым крупным обновлением Gulf Stream стал переход в конце 2022 года на сетевой протокол QUIC для передачи лидеру сообщений о транзакциях. Обновление было вызвано перебоями в работе сети из-за DDoS-атак и спам-транзакций, которые перегружали блокчейн во время выпуска NFT. После полной интеграции QUIC в Mainnet-Beta в версии 1.13.4 стабильность сети повысилась.

Ранее Solana использовала сетевой протокол UDP (User Datagram Protocol) для отправки транзакций от RPC-нод текущему лидеру. UDP быстр и эффективен, но не устанавливает соединение и не поддерживает ни управление потоком, ни подтверждение получения. Поэтому он не предоставляет эффективных способов предотвращать или ограничивать злоупотребления. Чтобы контролировать сетевой трафик, протокол приёма транзакций валидатором, то есть этап Fetch в TPU, был заново реализован на основе QUIC.

QUIC, первоначально разработанный Google в 2012 году, стремится объединить лучшие свойства TCP и UDP. Он обеспечивает быструю асинхронную связь, как UDP, но при этом поддерживает защищённые сессии и расширенные механизмы управления потоком, как TCP. Это позволяет ограничивать отдельные источники трафика, чтобы сеть могла сосредоточиться на обработке настоящих транзакций. QUIC также поддерживает отдельные потоки: если одна транзакция удаляется, она не блокирует остальные. Google был основной движущей силой внедрения QUIC в Web2. Соединения с серверами Google устанавливаются через QUIC, поэтому многие приложения Google работают на его основе, включая Hangouts, Gmail и YouTube. Стоит отметить, что QUIC — не аббревиатура, а фактическое название протокола.

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

Взвешенное по стейку качество обслуживания (SWQoS)

В начале 2024 года взвешенное по стейку качество обслуживания (SWQoS) было внедрено как механизм защиты от спама и атак Сивиллы. Эта система позволяет лидерам отдавать приоритет сообщениям о транзакциях, направленным через валидаторы со стейком. Валидаторы с более крупным стейком получают пропорционально большую пропускную способность для передачи лидеру пакетов с сообщениями о транзакциях. Это эффективно ограничивает атаки Сивиллы со стороны нод без стейка или с небольшим стейком. Такое разделение возможно благодаря проверке IP-адресов через QUIC: валидаторы могут назначать приоритеты и ограничивать трафик для конкретных соединений.

С помощью SWQoS валидаторы могут предоставлять RPC-нодам в аренду свою пропускную способность, взвешенную по стейку. Взамен RPC-ноды получают более широкую полосу пропускания и могут повысить долю транзакций, включаемых в блоки. В частности, 80% пропускной способности лидера (2 000 соединений) зарезервировано для взвешенного по стейку QoS, а оставшиеся 20% (500 соединений) выделены сообщениям о транзакциях от других нод. Эта стратегия напоминает платные полосы на автомагистрали, где водители платят за возможность объехать пробку.

Сейчас минимальный объём стейка для получения статуса участника со стейком составляет 0,04% от общего стейка. На момент написания общий стейк равен 384 миллионам SOL, поэтому минимальное требование составляет 15 360 SOL.

SWQoS существенно повлиял на экосистему Solana: повысил требования к пересылке транзакций лидеру и снизил эффективность спам-атак. Это изменение стимулировало приложения с высоким трафиком вертикально интегрировать свои операции. Запуская собственные ноды валидаторов, приложения могут получить привилегированный доступ к лидеру и тем самым улучшить обработку транзакций. Helius управляет одним из ведущих валидаторов сети по объёму стейка, что помогает нам обеспечить включение большего числа транзакций. Подробнее о стейкинге с нами можно узнать в подробном руководстве здесь.

«Лежачий полицейский» Jito

Нельзя не упомянуть Jito: на момент написания статьи более 80% стейка сети использует клиент валидатора Jito, который дополнительно усложняет типичный путь транзакций к лидеру. Клиент валидатора Jito-Solana (Github) — это форк клиента Agave (Github), изначально созданного Solana Labs. Он добавляет внепротокольный аукцион пространства блока и позволяет валидаторам получать дополнительные экономические стимулы в виде чаевых.

Полный анализ клиента Jito выходит за рамки этой статьи, поэтому мы рассмотрим только его влияние на прохождение обычных транзакций через Gulf Stream. У транзакций есть два возможных маршрута: от RPC к связанному валидатору, а затем к текущему лидеру — маршрут, взвешенный по стейку; либо напрямую к лидеру — маршрут через открытое соединение. В обоих случаях, если лидер использует клиент Jito-Solana, транзакции сначала отправляются в Jito-Relayer (Github) — программное обеспечение с открытым исходным кодом, которое выполняет роль прокси-маршрутизатора транзакций.

Другие ноды сети ничего не знают о Jito-Relayer. Они просто отправляют транзакции на адрес и порт, которые лидер решил объявить через gossip-сеть как ingress_socket. Ретранслятор задерживает транзакции на 200 миллисекунд перед пересылкой лидеру. Этот механизм «лежачего полицейского» замедляет поток входящих сообщений о транзакциях и позволяет эффективно проводить аукционы с дискретным временем. Через 200 миллисекунд ретранслятор оптимистично выпускает транзакции независимо от результатов аукциона.

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

Подробнее можно узнать в нашей вводной статье о MEV в Solana в блоге Helius здесь.

Заключение

В этой статье мы рассмотрели различные аспекты Gulf Stream в Solana, включая сетевой протокол QUIC, взвешенное по стейку QoS и конфигурацию валидатора Jito. Мы сравнили Gulf Stream с более традиционной архитектурой мемпула и описали преимущества подхода Solana: более высокую эффективность и меньшую задержку.

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

Solana не стоит на месте, и весь протокол, включая Gulf Stream, ждёт интересное будущее. Поэтому разработчикам стоит ожидать множества новых обновлений и оптимизаций.

Спасибо, что дочитали до конца! Присоединяйтесь к нашему сообществу в Discord, подписывайтесь на нас в X или на нашу рассылку ниже.

Большое спасибо Jacob Creech и 0xIchigo за рецензирование предыдущих версий этой статьи.

Дополнительные материалы

• Gulf Stream: протокол Solana для пересылки транзакций без мемпула
• QUIC: мультиплексированный транспорт поверх UDP
• Полное руководство по HTTP/3 и QUIC
• Подборка ссылок о SWQoS
• Руководство по взвешенному по стейку качеству обслуживания в Solana
• Обучение валидаторов Solana: взвешенное по стейку QoS
• Документация Jito Relayer
• Асинхронное исполнение и конечная архитектура

‍