Validators DAO выпускает Solana Stream SDK v1.1.1 и открывает исходный код стартового Rust-клиента для самых быстрых UDP Shreds

Solana Stream SDK, open-source стрим-клиент для Solana, который разрабатывают и поддерживают ELSOUL LABO B.V. (штаб-квартира: Амстердам, Нидерланды; CEO: Fumitake Kawasaki) и Validators DAO, выпустил новую версию v1.1.1. Вместе с релизом открыт исходный код стартового клиента на Rust, который напрямую работает с UDP Shreds — самым быстрым слоем сети Solana.

В этом релизе представлен практический пример, который принимает Shreds по UDP напрямую между валидаторами, без прохождения через более высокие API-слои вроде RPC, WebSocket или gRPC, а затем обрабатывает их по кратчайшему пути через восстановление и детектирование. Для сценариев, где задержка напрямую конвертируется в ценность, это даёт реальную отправную точку для работы на самом быстром слое в боевой среде.

В Solana даже одно и то же on-chain событие можно обнаружить в разное время в зависимости от того, где именно за ним наблюдать: в Shreds, Geyser gRPC или RPC / WebSocket. С точки зрения скорости обнаружения первым идёт Shreds, затем Geyser gRPC, и только после него RPC / WebSocket.

Shreds — это данные на этапе, когда фрагменты будущего блока напрямую передаются между валидаторами. Geyser gRPC отдаёт блоки, логи и обновления аккаунтов уже после того, как узел принял Shreds и внутренне их собрал. RPC / WebSocket находится ещё выше и даёт доступ к уже сохранённым и упорядоченным данным через запросы и подписки.

Shreds передаются по UDP. У UDP нет установления соединения, повторной передачи и гарантий порядка доставки, поэтому протокольные накладные расходы сведены к минимуму. В одинаковых условиях данные приходят быстрее, чем через gRPC или WebSocket, которые опираются на TCP.

Если задача — получить максимально раннее обнаружение в Solana, UDP Shreds неизбежно становится первым выбором именно из-за этих свойств передачи данных и самой архитектуры сети.

Validators DAO получил большое количество запросов по максимально быстрому обнаружению через UDP Shreds. Самый частый из них — как как можно раньше детектировать mint токенов и первые сделки на pump.fun.

Для mint и начальных сделок разница даже в десятки миллисекунд уже способна повлиять на итоговый результат. Поэтому pump.fun — очень наглядный пример, на котором ценность самого быстрого слоя проявляется особенно отчётливо и где спрос концентрируется сильнее всего. В этом релизе в стартовый код по умолчанию включена логика детектирования для pump.fun именно как отражение этой практической потребности. Это не ограничивает использование только pump.fun, а даёт реалистичный образец для воспроизведения детектирования на самом быстром слое.

При работе с UDP Shreds через систему проходит огромный объём транзакций, и значительная их часть слишком мала, чтобы иметь смысл для стратегии или UX-логики.

Стартовый код позволяет задать порог по объёму и реагировать только на транзакции выше этого значения. Такая фильтрация выполняется не через последующую проверку по RPC, а прямо на этапе оценки сразу после восстановления Shreds. Порог необязателен: если установить 0, будут детектироваться все транзакции. Пользователь сам решает, на какой объём данных реагировать в своём сценарии.

На примере выше показаны логи, где фиксируются только mint токенов и сделки, связанные с pump.fun, объёмом от 1 SOL и выше. Это иллюстрирует режим, в котором на самом быстром слое с высокой плотностью отбирается только действительно значимая информация.

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

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

Внутри обработка построена как ясная последовательность: receive → buffer → reconstruct → evaluate → output. Приём UDP, FEC-buffering, deshredding, watch-логика и вывод разделены по ответственностям и реализованы как отдельные элементы. Благодаря этому код можно сначала запустить как есть, а затем постепенно менять только те части, которые действительно нужны под конкретный сценарий.

GitHub (Solana Stream SDK): https://github.com/ValidatorsDAO/solana-stream
Rust Crate: https://crates.io/crates/solana-stream-sdk
ERPC Website: https://erpc.global/
Официальный Discord Validators DAO: https://discord.gg/C7ZQSrCkYR

Вопросы и обратная связь по Solana Stream SDK v1.1.1 и клиенту для UDP Shreds приветствуются в официальном Discord Validators DAO.