> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbitflare.com/llms.txt > Use this file to discover all available pages before exploring further. # Что нового в v2 > Jetstream v1 против v2 с первого взгляда: что v2 добавляет по сравнению с v1 и как больше данных в потоке означает меньше RPC-вызовов и более быстрый результат. Jetstream v2 передаёт те же транзакции с низкой задержкой, что и v1, но доставляет **больше в каждом сообщении** и позволяет **управлять подпиской, пока поток открыт**. Результат: ваш клиент выполняет меньше работы, делает меньше RPC-вызовов и реагирует быстрее. ## С первого взгляда | Возможность | v1 | v2 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-----------------------------------: | :-----------------------------------: | | Поток транзакций в реальном времени | | | | Фильтры аккаунтов `include` / `exclude` / `required` | | | | Проверки ping и версии | | | | Изменение фильтров на лету, без переподключения | | | | Именованные фильтры с подтверждениями принятия / отклонения | | | | Обогащённые поля транзакции (плательщик комиссии, цена вычислительной единицы, лимит вычислительных единиц, идентификаторы программ, записываемые аккаунты, размер) | | | | Разрешённые аккаунты из таблиц поиска адресов | | | | Поток жизненного цикла слотов (alive / complete / dead) | | | | Номера последовательности в каждом сообщении для обнаружения пропусков | | | | Heartbeat-сообщения при простое | | | И v1, и v2 дают вам **декодированную** транзакцию: подписи, ключи аккаунтов, инструкции, заголовок сообщения и любые ссылки на таблицы поиска адресов. То, что v2 добавляет, — это **обогащение** поверх этого (предварительно вычисленные поля выше), плюс возможности живой подписки, слотов и контроля живости. Обогащение опционально; см. ниже. ## Больше данных, меньше RPC-вызовов С v1 вы получаете декодированную транзакцию и вычисляете остальное сами. Всё, что за пределами основных полей, — на вас: кто оплатил комиссию, какую цену вычислительной единицы она установила, какие аккаунты записываемые и какие реальные аккаунты стоят за таблицами поиска версионной транзакции. v2 может выполнить эту работу за вас. Включите обогащение, и каждая транзакция также будет нести поля ниже. | Чтобы получить… | В v1 вы… | В v2 (обогащение включено) | | --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | Полный список аккаунтов **версионной (v0)** транзакции | Делаете полный **RPC-вызов** на каждую транзакцию, чтобы получить таблицу поиска, а затем сами разрешаете индексы | Уже разрешено и включено (`loaded_writable_addresses` / `loaded_readonly_addresses`) | | Плательщик комиссии | Выводите его из ключей аккаунтов и заголовка | Включён (`fee_payer`) | | Цена вычислительной единицы и лимит вычислительных единиц | Сами разбираете инструкции compute-budget | Включены (`compute_unit_price`, `compute_limit`) | | Записываемые аккаунты | Вычисляете их из заголовка и разрешённых таблиц поиска | Включены (`writable_accounts`) | | Идентификаторы программ, которых касается транзакция | Обходите каждую инструкцию | Включены (`program_ids`) | | Размер транзакции | Реконструируете и измеряете транзакцию | Включён (`tx_size`) | `compute_unit_price` — это **цена вычислительной единицы**, значение микро-лампортов на CU из `SetComputeUnitPrice`, а не общая приоритетная комиссия. Чтобы получить общую приоритетную комиссию в лампортах, умножьте на лимит вычислительных единиц и разделите на 1 000 000: `compute_unit_price × compute_limit / 1e6`. `compute_limit` отражает только явный `SetComputeUnitLimit` (`0`, если транзакция его не задаёт). **Строка с таблицами поиска — самая важная.** Версионная транзакция не несёт свой полный список аккаунтов. Она несёт *ссылку* на он-чейн таблицу поиска плюс набор индексов. В v1, чтобы узнать, каких аккаунтов транзакция действительно касается, вы делаете полный RPC-вызов, чтобы получить эту таблицу, а затем сами разрешаете индексы, для каждой транзакции — дополнительный запрос и ответ, который намного медленнее самого потока и находится прямо на вашем критическом пути. С включённым обогащением v2 эти разрешённые адреса уже включены, так что этот поиск уходит с вашего критического пути. Остальные строки — работа, которую ваш клиент иначе повторял бы на каждой транзакции; v2 вместо этого доставляет ответы прямо в сообщении. Для версионной транзакции разрешённые адреса из таблиц поиска включены. Если какие-то из них не могут быть полностью включены, для этой транзакции устанавливается `alt_resolution_incomplete`, чтобы вы разрешили их сами (получив таблицы через RPC) — никаких скрытых пропусков. Обогащение **опционально** и по умолчанию выключено. Включайте его для каждой подписки (`include_enrichment: true` в фильтре), когда вам нужны дополнительные поля — его включение **не добавляет задержки** потоку; единственное отличие — умеренно больший размер сообщения. Оно действует на всю подписку: если хотя бы один активный фильтр его включает, каждая транзакция, которую получает сессия, обогащается. ## Управляйте потоком без переподключения В v1 вы задаёте свои фильтры один раз, в сообщении, которое открывает поток. Чтобы наблюдать за чем-то другим, вы разрываете соединение и открываете новое, теряя живой поток на время переподключения. v2 держит поток открытым и позволяет вам добавлять и удалять фильтры по ходу дела. Вы даёте каждому фильтру свой собственный `filter_id`, сервер подтверждает каждое добавление и удаление (и сообщает причину, если отклоняет какой-то), и каждая транзакция перечисляет значения `filter_id`, с которыми она совпала. Запускайте несколько фильтров на одном соединении, меняйте их на лету и всегда знайте, какой фильтр породил данную транзакцию. Аккаунтные `include` / `exclude` / `required` ведут себя точно так же, как в v1 — `required` работает по принципу **любой-из** (транзакция совпадает, если она ссылается хотя бы на один перечисленный аккаунт), а не все-из. ## Следуйте за цепочкой с помощью событий слотов v2 добавляет второй, отдельный поток, `SubscribeSlots`, аналога которому у v1 нет. Вы получаете событие, когда слот начинается (`ALIVE`), завершается (`COMPLETE`) или пропускается либо вытесняется более поздними слотами без завершения (`DEAD`), вместе с лидером и родителем этого слота. Это дешёвый способ отслеживать, где находится цепочка, вместо того чтобы выводить это из потока транзакций. ## Знайте, когда вы что-то пропустили Две вещи, которых v1 вам никогда не давал: * Каждое сообщение v2, как транзакции, так и события слотов, несёт номер `sequence`, который возрастает на единицу. Увидели пропуск — и вы знаете, что потеряли сообщение. * Когда поток транзакций затихает, v2 отправляет `Heartbeat` каждые 60 секунд, помеченный часами сервера. Это поддерживает соединение живым через тайм-ауты простоя балансировщика нагрузки и отличает тихий поток от мёртвого. ## Почему всё это складывается в более быстрый результат * **Круговой обход уходит с вашего критического пути.** В v1 разрешение таблицы поиска — это полный RPC-запрос и ответ, намного медленнее самого потока. С включённым обогащением v2 разрешённые адреса версионной транзакции приходят прямо в сообщении, так что этот вызов никогда не встаёт между приходом транзакции и вашим действием. * **Меньше работы на транзакцию с вашей стороны.** Поля обогащения приходят уже вычисленными, так что ваш клиент не выводит их заново на каждой транзакции. * **Никаких пропусков при переподключении.** Изменение фильтров на лету означает, что вы никогда не разрываете поток, чтобы переподписаться. * **Потери и зависания видны немедленно** благодаря номерам последовательности и heartbeat-сообщениям, а не выводятся постфактум. ## Что вам следует использовать Используйте **v2** для новых интеграций. Именно здесь находятся обогащение, события слотов, живые фильтры и сигналы живости, и именно сюда попадает каждая новая возможность. **v1** остаётся полностью поддерживаемым и пока не имеет **установленной даты вывода из эксплуатации**, так что существующий v1-клиент может продолжать работать как есть. Тем не менее мы призываем переходить: по мере того как всё больше трафика консолидируется на v2, это высвобождает мощности, которые мы сегодня выделяем на v1, для следующего поколения стриминга OrbitFlare. В любом случае миграция — это изменение в коде вашего клиента, а не в вашем соединении: те же эндпоинты, та же аутентификация, работающие бок о бок. ## Смотрите также Модель потоковой передачи, подключение и лучшие практики. Полная спецификация Protocol Buffer для v2, эндпоинты и генерация кода. Обзор v1, примеры клиентов и руководство по фильтрации. ## Поддержка По вопросам технической поддержки или о Jetstream v2 обратитесь в нашу службу поддержки или присоединяйтесь к нашему [сообществу в Discord](https://discord.gg/orbitflare).