Как устроены потоки данных и протоколы Solana (Shreds, gRPC, WS, UDP)
Когда вы думаете о том, как ускорить своё Solana-приложение или торговую стратегию, первым делом стоит прояснить не код и не характеристики сервера.
Начать стоит с двух базовых вопросов.
Во-первых, насколько далеко вы находитесь от тех валидаторов Solana, которые для вас важны?
В каком регионе фактически живёт ваше приложение и сколько миллисекунд занимает путь до валидатора оттуда? Именно это расстояние лежит в основе всего. Если расстояние выбрано неправильно, никакая оптимизация программного обеспечения или оборудования не раскроет ту производительность, которая в принципе возможна.
Во-вторых, где находится валидатор-лидер в данный момент?
Когда лидер во Франкфурте, узлы рядом с Франкфуртом получают структурное преимущество. Когда лидер в Токио, выигрывают узлы рядом с Токио. Лидеры Solana сменяют друг друга по всему миру от слота к слоту, поэтому при однорегиональной конфигурации всегда будут временные окна, где вы физически оказываетесь в проигрышной точке.
На практике это означает, что реалистичная стратегия почти всегда должна быть многорегиональной.
Если разместить инфраструктуру сразу во Франкфурте, Амстердаме, Нью-Йорке, Чикаго, Токио и Сингапуре, становится возможно наблюдать за сетью из региона, который близок к текущему или следующему лидеру в любом временном диапазоне.
Только поняв этот физический и временной контекст, имеет смысл переходить к самим потокам данных Solana. В этой статье мы сосредоточимся на трёх вариантах, с которыми чаще всего сталкиваются разработчики:
- WebSocket (WS)
- Geyser gRPC
- Shredstream (UDP Shreds)
Нас интересует, на каком этапе каждый из них видит данные, как именно он их передаёт и для каких задач действительно подходит.
Цель не в том, чтобы выбрать вариант только потому, что «название звучит быстро», а в том, чтобы понять, как работает сама Solana и как поведение протоколов связано с производительностью приложения и UX.
На каком этапе появляются разные виды данных в Solana
Первый шаг — понять, в какой момент в конвейере обработки Solana становятся видны разные типы данных.
Если упростить, для рассуждений о производительности удобно выделить три стадии.
Первая стадия — это Shreds.
Валидаторы обмениваются Shreds по UDP, собирая из них блоки. В этот момент по сети ещё идут данные, которые не оформлены в окончательный блок. Если вы подключаетесь именно к этому слою, вы видите изменения в сети максимально рано. Но цена за это — необходимость проектировать систему с учётом потерь пакетов и данных, приходящих не по порядку.
Вторая стадия — Geyser gRPC.
После того как валидатор получил Shreds, собрал и подтвердил блок, он может отдать результат в структурированном виде через плагины Geyser. Именно так и появляются потоки Geyser gRPC: они передают блоки, журналы, обновления учётных записей и другие события. По времени это на шаг позже Shreds, но сами данные уже организованы и удобны для приложений.
Третья стадия — HTTP RPC и WebSocket.
Когда данные проходят через Geyser и внутреннюю обработку узла и попадают в его хранилище, они становятся доступны через JSON-RPC и уведомления WebSocket. Методы вроде
getBalance и getProgramAccounts, а также подписки на журналы работают уже с этим сохранённым состоянием. С точки зрения момента получения данных это ещё позже, чем у Geyser, и именно этот «верхний публичный уровень API» знаком большинству приложений.Если коротко:
- Shreds — это сырые данные почти в момент распространения
- Geyser gRPC — структурированные данные после подтверждения блока
- RPC / WebSocket — уже сохранённое состояние, доступное по запросу
Именно то, за каким из этих слоёв вы наблюдаете, определяет, насколько рано можно увидеть изменение в сети. И уже одно это создаёт большой разрыв в производительности.
Транспортные особенности: UDP, gRPC, WebSocket и TLS
Момент получения данных — это одна ось. Вторая ось — способ их доставки.
Shreds используют UDP.
У UDP маленькие заголовки и нет этапа установки соединения. Он не гарантирует повторную доставку и порядок пакетов, зато сводит накладные расходы протокола к минимуму. Для таких данных, как Shreds, которые и так распространяются между множеством валидаторов с резервированием, именно такая простота и нужна.
Geyser gRPC работает поверх TCP и использует бинарный протокол.
Потоковый RPC, сжатие заголовков и двоичное кодирование позволяют передавать данные заметно эффективнее, чем типичный HTTP+JSON. Поэтому gRPC хорошо подходит для постоянного потребления структурированных событий в серверных системах, мониторинге и аналитических конвейерах.
WebSocket обычно работает поверх TCP плюс TLS и передаёт данные в JSON.
Его главное преимущество — прямая совместимость с браузерами и стандартным веб-стеком, поэтому WS повсюду используется в dApps и лёгких ботах. Минус в том, что текстовый JSON надо парсить, а заголовки и шифрование добавляют накладные расходы. Среди этих трёх подходов WebSocket чаще всего оказывается самым тяжёлым.
Отдельно свою стоимость добавляет TLS.
Если вы используете https, wss или gRPC-TLS, для каждого соединения требуется рукопожатие, а данные нужно шифровать и расшифровывать. Для обычных веб-приложений это чаще всего приемлемо. Но в стратегиях, где на UX или PnL влияют десятки миллисекунд, эти накладные расходы уже становятся заметными.
Важно понимать:
- Когда именно вы видите данные (Shreds / Geyser / RPC)
- И как именно они доставляются (UDP / gRPC / WebSocket / TLS)
это две разные вещи, но обе напрямую влияют на итоговую задержку и UX.
Как соотносятся момент получения данных и транспорт по скорости
Если сложить эти два слоя, картина становится довольно понятной.
С точки зрения момента получения данных:
- Самыми ранними идут Shreds
- Затем идёт Geyser gRPC
- Затем RPC / WebSocket
С точки зрения транспорта:
- Самым лёгким и быстрым остаётся UDP
- Затем идёт gRPC поверх TCP с эффективной двоичной потоковой передачей
- WebSocket с JSON и TLS обычно самый тяжёлый
Если сравнивать при одинаковом регионе, одинаковом железе и одинаковом сетевом маршруте, технический порядок скорости выглядит так:
- UDP (Shreds)
- gRPC (Geyser)
- WebSocket (уведомления JSON-RPC)
Но на практике смотреть только на задержку нельзя. Нужно учитывать ещё надёжность, требования к корректности, стоимость разработки и ту сложность, которую команда реально готова переварить.
Почему на практике путь чаще WS > gRPC > UDP
Во многих реальных проектах порядок внедрения потоков данных почти противоположен их «чистой» скорости:
- Сначала WebSocket
- Потом Geyser gRPC
- Потом Shreds / UDP
Это абсолютно закономерно.
Shreds (UDP) действительно самый быстрый слой, но он требует изначально проектировать систему с учётом пропусков, нарушенного порядка поступления данных и шума в потоке.
Нельзя исходить из того, что каждый пакет обязательно дойдёт и что всё придёт идеально в линию. Приходится закладывать сверку данных, обработку пропусков и устойчивость к шуму. Взамен вы получаете минимальную задержку, но и заметный рост сложности.
Geyser gRPC отдаёт уже подтверждённые и структурированные данные, сформированные внутри узла.
Из-за этого его намного проще использовать. Событийно-ориентированные серверные системы, системы оповещения, ончейн-аналитика и индексаторы отлично строятся на Geyser, потому что он даёт хороший баланс между скоростью, надёжностью и стоимостью внедрения. Для многих команд это естественный второй шаг после схем только на WebSocket.
Преимущество WebSocket в том, что его можно напрямую использовать в браузерах и стандартной веб-инфраструктуре.
Клиентские части dApp и небольшие сервисы могут использовать его с привычными инструментами и библиотеками, а примеров и документации очень много. Поэтому для первого запуска продукта WebSocket часто оказывается самым рациональным вариантом, особенно если вы уже решили проблему расстояния до валидаторов.
То есть в теории скорость идёт так: UDP > gRPC > WS.
А на практике внедрение чаще идёт так: WS > gRPC > UDP.
Обе логики нужно учитывать, а выбирать следует не «самое быстрое название», а вариант, соответствующий текущей стадии проекта и его целям.
Как Shreds и Geyser gRPC работают вместе
Как только команда перестаёт просто «подкручивать скорость» и начинает учитывать разницу даже в десятки миллисекунд, главный вопрос меняется: как правильно комбинировать Shreds и Geyser gRPC.
Shreds нужны, чтобы заметить событие первыми.
Если вы получаете Shreds рядом с текущим лидером, можно увидеть изменения в сети на десятки или даже сотни миллисекунд раньше, чем тот, кто смотрит только на Geyser или RPC. Для стратегий, где этот разрыв напрямую превращается в PnL, это критично. Но при этом приходится мириться с шумом и строить систему с его учётом.
Geyser gRPC нужен, чтобы подтверждать картину и принимать решения на устойчивых данных.
В момент подтверждения блока Geyser отдаёт журналы, изменения учётных записей и другие структурированные события. На их основе удобно строить основную логику стратегии, механизмы управления рисками, индексаторы и мониторинг. Он медленнее Shreds, зато данные в нём намного проще интерпретировать.
Поэтому в реальных системах часто используется такая схема:
- Shreds отвечают за раннее обнаружение возможностей и максимально быструю сборку транзакций-кандидатов
- Geyser gRPC параллельно используется для проверки блоков и журналов, а также для основной логики и мониторинга
Такое распределение ролей позволяет снижать задержку, не теряя опору на данные, которые удобно проверять и интерпретировать.
TLS, общие эндпоинты и выделенные узлы
До сих пор мы предполагали, что базовый узел и сеть одинаковы. Но в реальности есть ещё одно существенное различие: работаете вы с общим эндпоинтом или с выделенным узлом.
Общий эндпоинт используется сразу многими клиентами.
Он выставлен в публичный интернет и всегда проходит через защищённый периметр. Поэтому шифрование обязательно, отключить TLS нельзя. Для обычных dApps это нормально, но в HFT-подобных задачах каждая лишняя миллисекунда уже заметна.
Выделенный узел закреплён за одним клиентом.
Поскольку доступ можно ограничить по IP и изолировать среду, появляется возможность отказаться от TLS и использовать обычный HTTP или gRPC без шифрования. Кроме того, процессор, память, дисковый ввод-вывод и пропускная способность сети больше не делятся с соседями, а значит задержка не «прыгает» из-за чужих нагрузок.
Если Shreds, Geyser gRPC и RPC работают на выделенных узлах, весь этот стек живёт в изолированной среде без соседних клиентов и без накладных расходов TLS.
Именно это позволяет выделенным конфигурациям достигать диапазона задержки, куда общие эндпоинты по своей природе выйти не могут, даже на том же оборудовании.
Общие узлы существуют для того, чтобы давать хорошую производительность большому числу пользователей.
Выделенные узлы нужны там, где действительно надо дойти до предельной скорости.
Многорегиональная инфраструктура и выделенные Shreds (пересылка по UDP)
Пока лидеры Solana продолжают сменять друг друга по всему миру, однорегиональная конфигурация не сможет быть самой быстрой везде и всегда.
Именно здесь на сцену выходят многорегиональные конфигурации Shreds.
Dedicated Shreds (Premium Shreds, Standard Shreds, Metal Shreds, Limited Editions и другие серии) сочетают:
- Максимально быструю доставку Shreds по UDP
- Выделенные серверы с минимальным джиттером
Если развернуть выделенные потоки Shreds сразу во Франкфурте, Амстердаме, Нью-Йорке, Чикаго, Токио и Сингапуре, можно получать Shreds из ближайшего к лидеру региона независимо от того, где он находится в данный момент.
Обычная рабочая схема здесь такова: система одновременно подписывается на несколько потоков Shreds из разных регионов и реагирует только на тот, который пришёл первым.
Это снижает влияние задержки на магистральных маршрутах и региональной перегрузки и позволяет на практике приблизиться к состоянию «почти всегда близко к лидеру».
Чтобы выделенные Shreds в нескольких регионах было проще внедрить, ERPC предлагает скидки за использование нескольких регионов:
- 2 региона: скидка 5%
- 3 региона: скидка 8%
- 5 регионов: скидка 10%
- Все регионы: скидка 15%
Это позволяет поставить самые производительные уровни Shreds (например, Premium или Metal) в наиболее конкурентных регионах, а в вспомогательных точках использовать более доступные варианты, но всё равно сохранить широкое покрытие.
Shared Shredstream Bundles как доступный путь к Shreds
Прежде чем переходить на полностью выделенные Shreds во всех регионах, часто полезно пройти промежуточный этап через многорегиональный Shared Shredstream.
Shared Shredstream Bundles дают доступ к общим потокам Shreds из нескольких регионов по одному плану.
Внутри такой схемы данные всё равно приходят из слоя Shreds (UDP), а до клиента доходят в виде gRPC. То есть источник остаётся «ранним»: данные видны на один этап раньше, чем в Geyser gRPC, но пользоваться ими проще благодаря удобству потоковой передачи gRPC.
Если выстроить слои по времени, получится так:
- Dedicated Shreds через пересылку по UDP — самый быстрый слой
- Shared Shredstream — gRPC-поток, построенный поверх Shreds
- Geyser gRPC — следующий уровень, соответствующий этапу подтверждения блока
Shared Shredstream Bundles включают добавление IP-адресов в список разрешённых, 10 подключений и автоматическую маршрутизацию к ближайшему периферийному узлу. Это позволяет недорого получить данные на основе Shreds сразу в Азии, Европе и Северной Америке.
Поэтому вместо резкого перехода к выделенным Shreds во всех регионах можно действовать поэтапно:
- Начать с Shared Shredstream Bundle и получить реальный опыт работы с данными на основе Shreds
- Собрать логи и данные о производительности, чтобы понять, где это действительно меняет результат
- Перевести самые важные регионы на выделенные Shreds, когда для этого уже есть данные и экономическое обоснование
Практические шаги по стадиям развития
Если собрать всё вместе, становится проще мыслить не технологиями, а этапами.
На первом этапе важно выбрать правильный регион и минимальное расстояние, а затем строить dApp или бота на RPC и WebSocket.
Уже один только правильный выбор региона часто заметно улучшает UX ещё до внедрения Shreds или gRPC. Для старта продукта WebSocket — вполне рациональный выбор, особенно в клиентской части.
На втором этапе имеет смысл добавить Geyser gRPC для серверной части, мониторинга и аналитики.
Geyser gRPC позволяет эффективно получать блоки, журналы и события учётных записей и строить на них индексаторы, системы оповещения и внешние API. Он обеспечивает хороший баланс скорости, надёжности и стоимости разработки, поэтому для многих команд становится естественным «вторым шагом».
На третьем этапе стоит подключать Shreds и пересылку по UDP там, где разница в задержке напрямую влияет на PnL или UX.
Развёртывание выделенных Shreds сразу в нескольких регионах и использование скидок позволяют выйти в диапазон задержки, который требуется для HFT, MEV и стратегий нулевого (0-го) слота, без необходимости сразу проектировать всю систему с нуля.
Суть не в том, что «UDP теоретически быстрее, значит нужен только UDP».
Суть в том, чтобы понимать собственную стадию проекта и экономику и только после этого решать, где инвестиции в Shreds и выделенную инфраструктуру действительно дают эффект.
Bundle и VPS от ERPC как основа
Планы Bundle ERPC изначально построены как единая основа:
- RPC (HTTP / WebSocket)
- Geyser gRPC
- Shared Shredstream gRPC
Всё это объединено в одной системе.
Это позволяет продолжать использовать RPC и WebSocket как основной рабочий интерфейс и параллельно экспериментировать с Geyser gRPC и Shredstream в той же сети.
Поскольку всё работает на общей инфраструктуре, решения можно принимать по реальным измерениям, а не по ожиданиям.
Эту основу можно дополнить VPS в той же сети ERPC, включая планы EPYC VPS и Premium Ryzen VPS.
Так можно в одном месте оптимизировать:
- Расстояние до валидаторов Solana
- Набор потоков данных (WS, gRPC, Shreds)
- Производительность оборудования
На практике удобный путь выглядит так: сначала выбрать нужные регионы и развернуть базовую связку Bundle + VPS, а затем включать более быстрые слои — Geyser, Shared Shreds и выделенные Shreds — по мере роста задач и бюджета.
Итог: производительность Solana строится на моменте получения данных, транспорте и расстоянии
Производительность и UX в Solana-приложении складываются из нескольких вещей одновременно:
- Где физически стоят ваши серверы
- Насколько близко вы к лидеру в нужные временные окна
- На каком этапе вы получаете данные
- Через какой транспорт и протокол они приходят
- Как поверх этого реагирует бизнес-логика
Расстояние и положение лидеров — это базовый слой. Поверх него идут:
- Shreds как самый ранний источник
- Geyser gRPC как слой структурированных подтверждённых данных
- RPC / WebSocket как API-доступ к сохранённому состоянию
А по способу доставки вы выбираете между:
- UDP
- gRPC поверх TCP
- WebSocket поверх TCP с JSON и TLS
Выбирать поток данных или протокол только по названию или маркетинговому тезису недостаточно.
Важно подбирать архитектуру под свой сценарий использования по трём осям сразу: моменту получения данных, характеристикам транспорта и расстоянию до нужных валидаторов.
ERPC и Validators DAO дают для этого сеть, оптимизированную для Solana, сервисы RPC, gRPC и Shredstream, VPS-линейку и скидки на выделенные Shreds в нескольких регионах, чтобы такие архитектуры можно было строить с экономически оправданными затратами и развивать их по мере роста потребностей.
Если вы хотите обсудить архитектуру потоков данных, оптимизацию сетевого расстояния или комбинацию выделенных Shreds, Shared Shredstream Bundles, планов Bundle и VPS, можно обратиться через Discord Validators DAO.
- ERPC: https://erpc.global/ru
- SLV: https://slv.dev/ru
- Epics DAO: https://epics.dev/ru
- Validators DAO Discord: https://discord.gg/C7ZQSrCkYR
