# Выбор Webhooks, WebSocket или RPC-опроса > Source: https://docs.blockvectra.com/ru/guides/webhook-vs-websocket/ Используйте адресные Webhooks для доставки на HTTPS-приемник, WebSocket — для поддерживаемых подписок в реальном времени, а ограниченный опрос — когда рабочему процессу требуется собственный курсор и механизм восстановления. Создание слушателей ончейн-событий для разработчиков и AI Agent требует сопоставления архитектуры приложения с возможностями сети, гарантиями доставки, ограничениями приемника и эксплуатационными затратами. ## Матрица принятия решений В таблице ниже сопоставляются все три механизма интеграции по поддерживаемым возможностям сетей, инфраструктурным требованиям, стратегиям восстановления и моделям тарификации: | Измерение | Адресные Webhooks | Подписки WebSocket | Ограниченный RPC-опрос | | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Основной механизм** | Push-уведомление, доставляемое через HTTPS POST на публичный эндпоинт | Потоковая подписка через постоянное TLS-соединение (`wss://`) | Инициируемые клиентом пакетные или периодические запросы HTTP JSON-RPC | | **Доступность в сетях** | Все поддерживаемые сети, объявленные в [GET /v1/push/chains](https://api.blockvectra.com/v1/push/chains) | Поддерживается в Robinhood Chain (robinhood\_mainnet и robinhood\_testnet); неподдерживаемые сети имеют `ws: false` и возвращают HTTP 404 | Все поддерживаемые сети в [GET /v1/chains](https://api.blockvectra.com/v1/chains) через публичный RPC без ключа или аутентифицированный JSON-RPC | | **Требования к приемнику** | Публично доступный HTTPS-URL, действующий TLS-сертификат, ответ 2xx в пределах тайм-аута, проверка подписи HMAC SHA-256 исходного тела запроса | Исходящее клиентское TCP/TLS-соединение (`wss://`); обработка ping/pong heartbeats и задержек при переподключении | Не сохраняющий состояние HTTP-клиент или периодический воркер; хранит локальный курсор блоков | | **Доставка и порядок** | Доставка по модели как минимум один раз (at least once) с экспоненциальной задержкой повторов; приемник должен выполнять дедупликацию по `id` события или по `ref` + `type` между подписками | Строго упорядоченные фреймы в рамках одного активного сокета; уведомления сбрасываются во время отключений | Детерминированные ответы на запросы для подтвержденных высот блоков; клиент сам задает темп выполнения | | **Реорганизации сети** | Отправка управляющих уведомлений для `chain.reorg`; приемник отбрасывает замененные события перед применением канонических повторов (replay) | Уведомления о логах содержат `"removed": true` для реорганизованных логов; `newHeads` требует проверки parent hash | Клиент отслеживает непрерывность цепочки по `parentHash` между тактами опроса для обнаружения реорганизаций | | **Восстановление после сбоев** | Окно хранения на сервере позволяет выполнять replay через `POST /v1/push/subscriptions/{id}/replay`; пропуски до блока активации требуют довыгрузки через `eth_getLogs` | Очередь на стороне сервера отсутствует; клиент переподключается и довыгружает пропущенные диапазоны через `eth_getLogs` с дедупликацией по `(blockHash, transactionHash, logIndex)` | Возобновление запросов с сохраненного `last_synced_block`; разбиение на фрагменты по параметру сети `max_logs_block_range` из [GET /v1/chains](https://api.blockvectra.com/v1/chains) | | **Модель тарификации** | Ежедневная плата за группу адресов на основе наибольшего количества адресов в статусе online в течение дня по UTC, плюс CU за доставленные события данных; см. [тарификацию Webhook](https://docs.blockvectra.com/ru/guides/webhook-push/#billing-and-example) | Рукопожатие и heartbeat-сообщения не тарифицируются; `eth_subscribe` / `eth_unsubscribe` и отправленные в сокет единицы уведомлений тарифицируются в CU | Учет за каждый запрос в Compute Units: `eth_blockNumber`, `eth_call`, `eth_getLogs`; веса методов и количество CU за $1 из [GET /v1/plans](https://console-api.blockvectra.com/v1/plans), показанные ниже | | **Оптимально для** | Мониторинга депозитов пользователей, отслеживания адресов горячих кошельков, платежей мерчантов, асинхронных вебхуков событий | Потока `newHeads` и отфильтрованных логов `logs` в реальном времени, реактивных ботов, интерактивных интерфейсов в поддерживаемых сетях | Пакетной сверки, cron-задач, ETL-конвейеров, сетей без поддержки WebSocket (таких как HyperEVM) | **Действующие параметры конвертации** 1 USD = 10,000 расчетных единиц, 1 расчетная единица = 1,000 CU (1 USD = 10,000,000 CU). **Формула**: Вес в CU × 1,000,000 ÷ (10,000 × 1,000) USD. | Метод | CU за вызов | Цена за 1M вызовов (USD) | | --- | --- | --- | | `eth_blockNumber` | 1 | $0.10 | | `eth_call` | 15 | $1.50 | | `eth_getLogs` | 30 | $3.00 | | `debug_traceTransaction` | 100 | $10.00 | | `data.block` | 5 | $0.50 | ## Когда выбирать адресные Webhooks Выбирайте [Blockchain Webhook API](https://docs.blockvectra.com/ru/guides/webhook-push/), если ваш бэкенд работает как стандартный веб-сервис, способный принимать входящие HTTPS-запросы: * **Большие списки адресов**: мониторинг депозитов или выводов средств по тысячам адресов клиентов без необходимости поддерживать постоянные сокеты для каждого кошелька. * **Бессерверные или контейнеризированные приемники**: serverless-функции (AWS Lambda, Cloudflare Workers) запускаются при поступлении вебхуков и не требуют постоянного поддержания активных соединений. * **Автоматические повторные попытки и replay**: временные сбои приемника сглаживаются автоматической экспоненциальной задержкой повторов. В пределах серверного окна хранения пропущенные доставки могут быть отправлены повторно с помощью эндпоинта replay. * **Учет границы активации**: сопоставление начинается только после применения изменений подписки (`applied_from_block`). События, произошедшие до добавления адреса или во время нахождения подписки в статусе `offline`, необходимо запрашивать через исторические логи RPC. Ознакомьтесь с [процессами проверки подписи и повтора (replay)](https://docs.blockvectra.com/ru/guides/webhook-push/#verify-signatures) перед развертыванием производственных приемников вебхуков. ## Когда выбирать подписки WebSocket Выбирайте [подписки WebSocket](https://docs.blockvectra.com/ru/guides/websocket-subscriptions/), когда требуется низкая задержка и ваш процесс способен поддерживать долгоживущий исходящий сокет: * **Заголовки блоков в реальном времени**: получение потока `newHeads` по мере добавления каждого блока к вершине цепочки. * **Фильтры событий контрактов**: получение потока логов контрактов `logs` в реальном времени, соответствующих адресу или конкретному `topic0`. * **Закрытые среды**: идеально для локальных скриптов, CLI-агентов или бэкенд-сервисов за NAT или фаерволами, которые не могут предоставить входящий публичный HTTPS-порт. * **Проверка доступности сети**: WebSocket поддерживается в Robinhood Chain (слаг сети `robinhood_mainnet`, Chain ID 4663 и `robinhood_testnet`). В HyperEVM в настоящее время поддержка WebSocket отсутствует (`ws: false`); попытка подключения по WebSocket к неподдерживаемой сети возвращает HTTP 404 ([`unknown_chain`](https://docs.blockvectra.com/ru/errors/#unknown_chain)). * **Дисциплина при отключении**: уведомления WebSocket не сохраняются на сервере во время отключений. При обрыве сокета клиенты должны переподключаться со случайной экспоненциальной задержкой и довыгружать пропущенные блоки через `eth_getLogs`. Ознакомьтесь с [руководством по подпискам WebSocket](https://docs.blockvectra.com/ru/guides/websocket-subscriptions/) для изучения лимитов фильтров, ограничений на подключения (20 на ключ, 50 на аккаунт) и примеров подключения с помощью viem. ## Когда выбирать ограниченный RPC-опрос Выбирайте ограниченный опрос JSON-RPC при запуске периодических воркеров, конвейеров данных или при работе в сетях, где WebSocket недоступен: * **Сети без WebSocket**: HyperEVM (`hyperevm_mainnet`) в настоящее время предоставляет доступ по JSON-RPC HTTP, но не имеет WebSocket (`ws: false`). Опрос `eth_blockNumber` и отправка запросов `eth_getLogs` в поддерживаемых диапазонах блоков обеспечивают обработку событий HyperEVM. * **Контролируемый темп запросов**: опрос позволяет разработчикам и AI Agent регулировать частоту запросов, управлять расходом Compute Units в пределах лимитов частоты запросов на ключ и избегать разрывов сокетов во время длительных задач. Лимиты на ключ — по умолчанию 400 CU/s и всплеск (burst) 1,600 CU. * **Лимиты диапазона блоков**: аутентифицированные запросы `eth_getLogs` ограничены параметром сети `max_logs_block_range` из [GET /v1/chains](https://api.blockvectra.com/v1/chains). Превышение этого лимита возвращает код ошибки `-32602` ([`logs_range_too_large`](https://docs.blockvectra.com/ru/errors/#logs_range_too_large)). Разделяйте более широкие интервалы на последовательные фрагменты, не превышающие `max_logs_block_range` целевой сети. | Сеть | Слаг сети | max_logs_block_range (блоков) | | --- | --- | --- | | Arbitrum One | `arb_mainnet` | 1,000 | | Base | `base_mainnet` | 1,000 | | BNB Smart Chain | `bsc_mainnet` | 1,000 | | Ethereum | `eth_mainnet` | 1,000 | | Ethereum Sepolia | `eth_sepolia` | 1,000 | | HyperEVM | `hyperevm_mainnet` | 1,000 | | Polygon | `polygon_mainnet` | 1,000 | | Robinhood Chain | `robinhood_mainnet` | 1,000 | | Robinhood Chain Testnet | `robinhood_testnet` | 1,000 | Алгоритмы разбиения на фрагменты см. в [руководстве по выгрузке логов HyperEVM](https://docs.blockvectra.com/ru/guides/hyperevm-backfill/) и [руководстве по диапазону блоков eth\_getLogs](https://docs.blockvectra.com/ru/guides/getlogs-block-range/). Полный контрольный список рабочих нагрузок и тесты для самопроверки см. в руководстве [Как выбрать RPC-провайдера](https://docs.blockvectra.com/ru/guides/choose-rpc-provider/). При выборе провайдера для небольшого объема опроса [сравните провайдеров по стандартной тарификации и охвату RPC](https://docs.blockvectra.com/ru/guides/quicknode-alternative/). Сравните тарификацию по фактическому использованию со стоимостью пробных версий и подписок; расходы на уведомления и довыгрузку рассчитываются по другим метрикам, чем чтение через RPC. ## Руководства по реализации ### WebSocket в Robinhood Chain Для получения `newHeads` или отфильтрованных логов `logs` в реальном времени в Robinhood Chain следуйте [руководству по подпискам WebSocket](https://docs.blockvectra.com/ru/guides/websocket-subscriptions/) для настройки аутентификации и запросов на подписку. После отключения выполните повторное подключение с задержкой, подпишитесь заново и выполните довыгрузку пропущенных блоков с сохраненного курсора с помощью `eth_getLogs`; дедуплицируйте логи по кортежу `(blockHash, transactionHash, logIndex)`. ### Ограниченный опрос в HyperEVM Для HyperEVM (`hyperevm_mainnet`) следуйте [руководству по выгрузке логов HyperEVM](https://docs.blockvectra.com/ru/guides/hyperevm-backfill/) для настройки ограниченного опроса и восстановления. Выполняйте запросы с сохраненного курсора фрагментами в пределах `max_logs_block_range`, сохраняйте события и прогресс вместе после успешной обработки и повторяйте запросы для неполных диапазонов. Проверяйте непрерывность цепочки и сканируйте перекрывающиеся диапазоны для обработки реорганизаций. ## Следующие шаги * [Изучите каталог наборов данных](https://blockvectra.com/ru/data/), чтобы увидеть все наборы данных, индексируемые BlockVectra. * [Посмотрите бесплатный тариф и цены](https://blockvectra.com/ru/pricing/#free), чтобы узнать, что включено в ваш аккаунт. * [Войдите в консоль](https://console.blockvectra.com/login/?next=%2Fkeys%2F), чтобы создать API key.