Вибір між вебхуками, WebSocket або опитуванням RPC
Порівняння сповіщень для адрес, підписок через сокети та обмеженого опитування за підтримкою мереж, відновленням, вимогами до отримувача та тарифікацією.
Використовуйте вебхуки для адрес для доставки на HTTPS-отримувач, WebSocket — для підтримуваних підписок у реальному часі, та обмежене опитування — коли робочий процес потребує власного курсора та відновлення.
Побудова слухачів ончейн-подій для розробників та AI-агентів вимагає узгодження архітектури застосунку з можливостями мережі, гарантіями доставки, обмеженнями отримувача та операційними витратами.
Матриця рішень
У наведеній нижче таблиці порівнюються всі три механізми інтеграції за підтримуваними можливостями мережі, вимогами до інфраструктури, стратегіями відновлення та моделями тарифікації:
| Критерій | Вебхуки для адрес | Підписки через WebSocket | Обмежене опитування RPC |
|---|---|---|---|
| Основний механізм | Push-сповіщення, що доставляються через HTTPS POST на публічний ендпоінт | Підписка на потік через постійне з'єднання TLS (wss://) | Пакетні або заплановані HTTP JSON-RPC запити, що ініціюються клієнтом |
| Доступність у мережах | Усі підтримувані мережі, зазначені в GET /v1/push/chains | Підтримується на Robinhood Chain (robinhood_mainnet та robinhood_testnet); непідтримувані мережі мають ws: false та повертають HTTP 404 | Усі підтримувані мережі в GET /v1/chains через публічний RPC без ключа або автентифікований JSON-RPC |
| Вимоги до отримувача | Публічно доступна URL-адреса HTTPS, дійсний сертифікат TLS, відповідь 2xx у межах таймауту, перевірка підпису сирого тіла HMAC SHA-256 | Вихідне клієнтське з'єднання TCP/TLS (wss://); обробка пульсу ping/pong та затримка перед повторним підключенням | Безстанний HTTP-клієнт або запланований воркер; зберігає локальний курсор блоку |
| Доставка та порядок | Доставка «щонайменше один раз» з експоненціальною затримкою повторних спроб; отримувач повинен дедуплікувати за id події або за ref + type між підписками | Суворо впорядковані фрейми в межах одного активного сокета; сповіщення втрачаються під час розриву з'єднання | Детерміновані pull-відповіді для підтверджених висот блоків; клієнт самостійно регулює швидкість виконання |
| Реорганізації мережі | Керуючі сповіщення надсилаються для chain.reorg; отримувач відкидає замінені події перед застосуванням канонічних повторних відтворень | Сповіщення логів містять "removed": true для реорганізованих логів; newHeads вимагає перевірки хешу батьківського блоку | Клієнт відстежує неперервність ланцюжка parentHash між тактами опитування для виявлення реорганізацій |
| Відновлення після збоїв | Серверне вікно збереження дозволяє повторне відтворення через POST /v1/push/subscriptions/{id}/replay; прогалини до блоку активації вимагають заповнення через eth_getLogs | Немає черги на боці сервера; клієнт перепідключається та відновлює пропущені діапазони через eth_getLogs із дедуплікацією за (blockHash, transactionHash, logIndex) | Відновлює запити зі збереженого last_synced_block; розбиває діапазон на частини відповідно до max_logs_block_range мережі з GET /v1/chains |
| Модель тарифікації | Щоденна плата за групу адрес на основі найбільшої кількості адрес під час перебування онлайн за добу UTC, плюс CU за доставлені події даних; див. Тарифікація вебхуків | Рукостискання та перевірки пульсу не тарифікуються; eth_subscribe / eth_unsubscribe та скинуті одиниці сповіщень сокета тарифікуються в CU | Оплата за кожен запит у Compute Units: eth_blockNumber, eth_call, eth_getLogs; вага методів та CU за $1 з GET /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 |
Коли обирати вебхуки для адрес
Обирайте Blockchain Webhook API, коли ваш бекенд працює як стандартний вебсервіс, здатний приймати вхідні HTTPS-запити:
- Великі списки адрес: моніторинг депозитів або виведення коштів на тисячах адрес клієнтів без підтримки постійних сокетів для кожного гаманця.
- Serverless або контейнеризовані отримувачі: безсерверні функції (AWS Lambda, Cloudflare Workers) запускаються під час отримання вебхуків і не потребують підтримки постійного з'єднання.
- Автоматичні повторні спроби та відтворення: короткочасні збої отримувача згладжуються автоматичними повторними спробами з експоненціальною затримкою. У межах серверного вікна збереження пропущені доставки можна отримати повторно за допомогою ендпоінта відтворення.
- Врахування межі активації: зіставлення починається лише після застосування змін підписки (
applied_from_block). Події, що відбулися до додавання адреси або під час перебування підписки в статусіoffline, потрібно запитувати через історичні логи RPC.
Ознайомтеся з перевіркою підпису та процесами повторного відтворення перед розгортанням отримувачів вебхуків у продакшені.
Коли обирати підписки через WebSocket
Обирайте Підписки через WebSocket, коли потрібна низька затримка і ваш процес може підтримувати довготривалий вихідний сокет:
- Заголовки блоків у реальному часі: потокова трансляція
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). - Дисципліна відключення: сповіщення WebSocket не зберігаються на сервері під час розриву з'єднання. Коли сокет закривається, клієнти повинні перепідключитися з рандомізованою експоненціальною затримкою та заповнити пропущені блоки через
eth_getLogs.
Перегляньте Посібник із підписок через WebSocket щодо лімітів фільтрів, обмежень з'єднань (20 на ключ, 50 на акаунт) та прикладів підключення за допомогою viem.
Коли обирати обмежене опитування RPC
Обирайте обмежене опитування JSON-RPC під час запуску запланованих воркерів, конвеєрів даних або роботи в мережах, де WebSocket недоступний:
- Мережі без WebSocket: HyperEVM (
hyperevm_mainnet) наразі надає доступ до JSON-RPC через HTTP, але не підтримує WebSocket (ws: false). Опитуванняeth_blockNumberта запитиeth_getLogsу підтримуваних діапазонах блоків забезпечують обробку подій HyperEVM. - Контрольована швидкість запитів: опитування дозволяє розробникам та AI-агентам регулювати частоту запитів, керувати споживанням Compute Units у межах лімітів швидкості на кожен ключ та уникати обривів сокета під час довготривалих завдань. Ліміти на ключ — за замовчуванням 400 CU/s і burst 1,600 CU.
- Ліміти діапазону блоків: автентифіковані запити
eth_getLogsобмежені значеннямmax_logs_block_rangeмережі з GET /v1/chains. Перевищення цього ліміту повертає код помилки-32602(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 та посібнику з діапазонів блоків eth_getLogs.
Повний контрольний список робочих навантажень та самотестування див. у посібнику Як обрати RPC-провайдера.
Обираючи провайдера для опитування з низьким обсягом трафіку, порівняйте провайдерів за тарифікацією стандартного RPC та покриттям. Порівняйте тарифікацію за фактичне використання з вартістю пробних періодів та підписок; витрати на сповіщення та відновлення використовують інші одиниці обліку, ніж читання RPC.
Посібники з реалізації
WebSocket на Robinhood Chain
Для отримання newHeads або відфільтрованих logs у реальному часі на Robinhood Chain дотримуйтесь інструкцій з Посібника з підписок через WebSocket щодо автентифікації та запитів на підписку. Після відключення перепідключіться із затримкою, відновіть підписку та довантажте пропущені блоки зі збереженого курсора за допомогою eth_getLogs; дедуплікуйте логи за (blockHash, transactionHash, logIndex).
Обмежене опитування на HyperEVM
Для HyperEVM (hyperevm_mainnet) дотримуйтесь інструкцій з посібника із заповнення логів HyperEVM щодо обмеженого опитування та відновлення. Виконуйте запити зі збереженого курсора частинами в межах max_logs_block_range, зберігайте події та прогрес разом після успішної обробки і повторюйте спроби для незавершених діапазонів. Перевіряйте неперервність ланцюжка та скануйте діапазони, що перекриваються, для обробки реорганізацій.
Наступні кроки
- Переглянути каталог наборів даних, щоб ознайомитися з кожним набором даних, який індексує BlockVectra.
- Ознайомитися з безкоштовним планом та цінами, щоб дізнатися, що включено у ваш акаунт.
- Увійти в консоль, щоб створити API key.
Востаннє оновлено: