Победа в игре на миллисекунды: шреды, LaserStream и преимущество в Solana

Что такое шреды?

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

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

Эти шреды представляют части данных транзакций до их объединения в блок. Размер каждого шреда составляет около 1,2 КБ. Он оптимизирован под максимальный размер передаваемого блока данных (MTU) стандартных сетевых пакетов, чтобы обеспечить молниеносную доставку без фрагментации. 

Существует два типа шредов:

Шреды данных

Шреды данных содержат основные данные транзакций из блока, разделенные на части фиксированного размера. В них входят сериализованные пакеты записей — группы транзакций, перед которыми для эффективной обработки указывается их количество.

Шреды кодирования

Шреды кодирования обеспечивают избыточность с помощью стирающего кодирования Рида — Соломона — метода прямой коррекции ошибок, который создает данные четности. Благодаря этому можно восстановить отсутствующие или поврежденные шреды. Шреды кодирования вместе со шредами данных объединяются в наборы прямой коррекции ошибок (FEC), обычно в сбалансированном соотношении, например 32 шреда данных к 32 шредам кодирования. Это позволяет выдержать потерю до 50% пакетов. Лидеры могут изменять это соотношение с учетом состояния сети, сохраняя высокую надежность.

Как шреды распространяются в Solana?

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

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

Перемешивание с учетом веса стейка отдает приоритет доставке валидаторам с более крупным стейком. Сначала Turbine сортирует валидаторов по объему их стейка, то есть по весу стейка. Валидаторы с большим стейком размещаются в начале списка и после детерминированного перемешивания обычно оказываются на более ранних уровнях дерева, ближе к лидеру. Чем меньше переходов, тем ниже задержка. Поэтому валидаторы с большим стейком получают шреды раньше.   

Примечание: в будущем после внедрения Alpenglow Turbine будет заменен на Rotor. Даже после этих изменений стейк валидатора продолжит влиять на выбор пиров, которым валидаторы передают данные.

Как шреды повторно собираются в блоки?

Получив шреды, валидатор сначала проверяет их подписи, чтобы подтвердить подлинность, а затем использует стирающее кодирование Рида — Соломона для восстановления отсутствующих или поврежденных шредов данных из доступных шредов кодирования в наборе FEC. 

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

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

Почему шреды важны? 

Шреды важны, потому что сокращают окно реакции в сети, где время имеет решающее значение. 

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

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

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

Если вам нужно преимущество шредов по задержке без создания такого конвейера, Preprocessed Transactions объединит их за вас и передаст подписанные транзакции через WebSocket на 8 мс раньше уровня подтверждения processed.

Однако такой «ранний просмотр» ожидающих транзакций и обновлений аккаунтов дает непревзойденное преимущество и напрямую повышает долю успешных операций в конкурентных сценариях.

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

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

Иерархия задержки шредов

Важно учитывать, что задержка шредов различается в зависимости от источника.

Валидаторы с большим стейком

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

Валидаторы со стейком

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

Валидаторы без стейка

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

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

Глобальная вариативность 

Важно, что Turbine не зависит от местоположения. Глобальное распространение может усиливать вариативность задержки, поскольку физическое расстояние и состояние сети добавляют задержки помимо переходов Turbine. 

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

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

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

Потоковая передача данных в Solana

Разработчикам, которым нужна потоковая передача данных Solana в реальном времени, доступно несколько вариантов. У каждого есть свои компромиссы по задержке, надежности и сложности:

Webhooks

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

Хотя Webhooks отличаются высокой надежностью и используются многими известными компаниями в Solana, они отправляют уведомления после подтверждения транзакции. Поэтому Webhooks могут отставать от данных уровня шредов на сотни миллисекунд и оказываются слишком медленными для операций, критичных к задержке, таких как высокочастотный трейдинг или ликвидации.

Стандартные WebSockets

JSON RPC API Solana поддерживает подписки WebSocket, например accountSubscribe для изменений аккаунтов, logSubscribe для журналов транзакций и programSubscribe для событий программ. WebSockets поддерживают постоянное соединение между клиентом и RPC-провайдером и передают обновления сразу после обработки транзакций и изменений аккаунтов. WebSockets работают в обоих направлениях и подходят для мониторинга определенных аккаунтов или событий в реальном времени, одновременно сокращая накладные расходы на опрос.

Однако, как и Webhooks, WebSockets доставляют данные после повторной сборки шредов, то есть на уровнях подтверждения processed, confirmed или finalized (commitment levels). В зависимости от уровня подтверждения это добавляет от 400 мс до 30 секунд задержки. 

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

Enhanced WebSockets

Enhanced WebSockets значительно превосходят стандартные WebSockets благодаря нескольким оптимизациям производительности и расширенным возможностям фильтрации. Улучшенный разбор событий и снижение шума делают их удобнее для разработчиков при использовании в рабочей среде.

Enhanced WebSockets могут снизить задержку по сравнению со стандартными WebSockets и отлично подходят для обычных приложений потоковой передачи. Например, при потоковой передаче данных Pump AMM через Enhanced WebSockets заметна разница в производительности по сравнению как со стандартными WebSockets, так и с Webhooks. 

Однако Enhanced WebSockets по-прежнему доставляют данные только после повторной сборки шредов. Это ограничивает их пользу для приложений, где важна каждая миллисекунда. Кроме того, несмотря на улучшения, в них нет автоматического воспроизведения и переключения при сбое, поэтому пропуски приходится обрабатывать вручную. 

Yellowstone gRPC

Yellowstone gRPC — протокол потоковой передачи данных с низкой задержкой от валидатора к клиенту, который может предоставлять доступ к данным на уровне шредов. Благодаря этому он значительно быстрее WebSockets и Webhooks, поскольку может быстрее доставлять обновления для соответствующего уровня подтверждения. 

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

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

1. Инфраструктурная нагрузка

Чтобы использовать весь потенциал Yellowstone gRPC, вам нужна собственная выделенная нода. Для этого требуются доступ к оборудованию, правильная настройка, постоянное управление этим оборудованием и профильные знания для устранения любых проблем с ним.

2. Вариативность задержки

То, что Yellowstone gRPC может доставлять данные на уровне шредов, не означает, что он будет делать это оптимально. Задержка зависит от провайдера и от того, сопряжена ли ваша выделенная нода с источниками, оптимизированными для шредов, то есть валидаторами с большим стейком. При сопряжении с валидаторами со средним или малым стейком они не будут стабильно попадать на первый уровень Turbine, поэтому многие шреды по-прежнему будут приходить к вам позже.

3. Риски отказа

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

4. Требования к ресурсам

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

Долгое время Yellowstone gRPC был основным сервисом для многих команд, которым требовалась потоковая передача данных Solana в реальном времени. Он быстрый и подходит опытным пользователям, но без парка выделенных нод по всему миру с его помощью сложно обеспечить стабильное глобальное покрытие с низкой задержкой.

LaserStream

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

LaserStream обеспечивает это благодаря следующим возможностям:

• Прием из нескольких источников: LaserStream принимает шреды с минимальной задержкой и стабильно превосходит конкурентов по всему миру.
• Глобальное покрытие: LaserStream доступен в нескольких регионах по всему миру, поэтому разработчики могут использовать ближайшую к своей инфраструктуре конечную точку. Для резервирования в каждом регионе работает несколько серверов с автоматическим переключением при сбое.
• Без пропусков: Воспроизведение исторических данных в LaserStream позволяет разработчикам повторно получать данные блокчейна за последние 48 часов. Это помогает обрабатывать отключения и обеспечивать непрерывность данных. 
• Удобство для разработчиков: LaserStream может напрямую заменить Yellowstone gRPC — без миграций, нового синтаксиса и лишних сложностей.

Иными словами, LaserStream — масштабируемое, низколатентное и отказоустойчивое развитие Yellowstone gRPC и WebSockets. Он стабильно предоставляет ончейн-события сразу после их появления в сети, не требуя миллионов в стейке или самостоятельной эксплуатации высокопроизводительной инфраструктуры. 

LaserStream — самый простой способ использовать возможности шредов для потоковой передачи данных Solana со сверхнизкой задержкой.

Клиенты и производительность

Для LaserStream доступны клиенты на Go, Rust и JavaScript/TypeScript. Эти клиенты автоматически воспроизводят данные после отключений, постоянно отслеживая, какой слот уже был передан. Если по какой-либо причине соединение прервется, клиент автоматически подключится снова и возобновит потоковую передачу с последнего обработанного слота.

Клиент LaserStream для JavaScript особенно интересен тем, что использует нативные привязки Rust. Благодаря этому его пропускная способность достигает 1,3 ГБ/с. Это в 40 раз больше, чем у текущего клиента Yellowstone gRPC для JavaScript, максимальная скорость которого составляет 30 МБ/с. 

По мере дальнейшего масштабирования Solana клиент Yellowstone gRPC для JavaScript будет с трудом справляться с нагрузкой. Запас производительности клиента LaserStream для JavaScript позволяет вашему приложению безопасно масштабироваться вместе с сетью по мере роста спроса. 

Реальные результаты

DFlow, DEX-агрегатор с низкой задержкой, недавно интегрировал LaserStream для снабжения своего ценового механизма данными. Решение об интеграции было обусловлено возможностью глобального масштабирования без забот о выделенных нодах и экономией инженерных ресурсов, которые можно направить на маршрутизацию и бизнес-логику. 

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

Более быстрая потоковая передача уже сегодня.

Миллисекунды — это не просто задержка, а возможность. С LaserStream вы не просто успеваете за сетью. Вы опережаете ее. 

Нужны данные с задержкой менее секунды для торговли, ликвидаций или оракулов? Используйте LaserStream и получите доступ к самым быстрым данным Solana. 

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

Дополнительные ресурсы

• LaserStream
• Модуль шредов Agave
• Спецификация шредов Solana