Як обрати RPC-провайдера
Оцінюйте вартість методів RPC, діапазони журналів, безкоштовні кредити, ліміти швидкості, покриття мереж, Push та Data API, автентифікацію та доступ для агентів за допомогою тестів робочого навантаження.
Обирайте RPC-провайдера за вартістю та надійністю виконання вашого фактичного завдання: спочатку перевірте мережі, методи та історичне покриття, а потім виміряйте кількість запитів, пропускну здатність і відновлення.
Зафіксуйте мережі, методи, фіксовані блоки, добовий розподіл трафіку, пікову кількість одночасних запитів і залежності від сповіщень або наборів даних, необхідні вашому застосунку чи AI-агенту. Загальнодоступні значення BlockVectra нижче отримані з GET /v1/plans та GET /v1/chains; зробіть новий запит перед прийняттям рішення. Покриття даних отримано з GET /v1/status. Декларація в API є відправною точкою для тестування, а не вимірюванням затримки чи SLA.
Оцініть BlockVectra для підтримуваних читань контрактів з тарифікацією за використання на основі методів, обмежених бекфілів журналів HyperEVM до 1,000 блоків на один автентифікований запит або багатомережевих сповіщень для адрес через одну підписку самообслуговування та один HTTPS-отримувач. Читання контрактів використовують поточну вагу eth_call у таблиці методів нижче; адресо-дні Push та доставлені події мають окремі тарифи. Оберіть робочий процес під ваше завдання: тарифікація читання контрактів, бекфіли журналів HyperEVM або сповіщення для адрес та ємність. Ціни та ліміти перевірено за планами та мережами станом на 2026-10-09; підтвердьте покриття за допомогою актуальних API та запустіть відповідний тест для необхідних блоків, повних результатів і шляху відновлення.
Ціни на методи та розрахункові одиниці
Сама лише кількість запитів не визначає вартість навантаження. Фіксуйте розрахункову вагу кожного методу, конвертацію в USD, включені кредити, плату за перевищення ліміту та будь-яку плату за підписку або додаткові послуги. Кредити, CU та одиниці запиту (request units) потребують індивідуального перерахунку перед порівнянням провайдерів.
Поточна вага методів і базові ціни BlockVectra зчитуються з публічного ендпоінта планів під час збирання сторінки:
Активні параметри конвертації
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 |
Push у режимі самообслуговування підтримує до 1,000,000 адрес на підписку. Для 10,000,000 / 100,000,000 адрес на підписку, зв'яжіться з нами, щоб підключити ємність.
Вартість завдань і частота запитів BlockVectra Бюджет key за замовчуванням: 400 CU/s.
| Метод | Приклади викликів | CU за виклик | Вартість завдання (USD) | Запитів/с за бюджетом CU для key |
|---|---|---|---|---|
eth_call | 1,000,000 | 15 | $1.50 | 26 |
eth_getLogs | 100,000 | 30 | $0.30 | 13 |
Вартість завдань є ціною за прейскурантом до врахування безкоштовних кредитів, газу та додаткових послуг. Частота запитів дорівнює key_defaults.cu_per_sec ÷ CU методу та передбачає, що цей key використовує лише цей метод. Ліміти безкоштовних акаунтів та інший трафік можуть знизити доступну частоту; ці цифри є перерахунком бюджету, а не виміряною пропускною здатністю.
workload_cu = sum(calls_for_method × current_method_cu_weight)
cu_per_usd = pricing.units_per_usd × pricing.cu_per_unit
list_cost_usd = workload_cu / cu_per_usd
paid_compute_usd = max(0, workload_cu − available_free_cu) / cu_per_usdБазові ціни не включають безкоштовні кредити, газ, додаткові послуги та роботи з міграції. Розрізняйте регулярну квоту та пробний період, що закінчується, а також ціну додаткових кредитів і середню вартість включених запитів. Перевірте правила тарифікації, щоб дізнатися, які відповіді споживають CU.
Самостійне тестування: відтворіть невелику репрезентативну комбінацію методів із фіксованими блоками та зафіксуйте успішні виклики, повторні спроби й оплачувані помилки. Порівняйте зміну використання в акаунті з розрахунком за вагою методів. Закладіть у бюджет кількість запитів, які повернули повний результат, враховуючи пагінацію та бекфіли. Дивіться Тарифікація читань у CU для деталей конвертації.
Діапазони журналів та історичний стан
Для eth_getLogs перевірте діапазон блоків, обмеження розміру результату та підтримку фільтрів для конкретної мережі та плану. Широкий діапазон корисний лише за умови повноти відповіді. Автентифіковані діапазони BlockVectra отримані з каталогу мереж:
| Мережа | Слаг мережі | 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 |
Історичні журнали та історичне виконання контрактів — це різні можливості. Для eth_call перевірте state_window_blocks; для читань без ключа також перевірте public.history_blocks. Відсутнє або нульове (null) поле вказує на невизначеність, а не на необмежену історію. Дивіться історичний стан EVM.
Самостійне тестування: оберіть фіксований інтервал із відомим контрактом і темами (topics), розділіть його за заявленим діапазоном і порівняйте об'єднання результатів із дрібнішими запитами, що перекриваються. Видаліть дублікати за хешем блоку, хешем транзакції та індексом журналу, а також перевірте межі інтервалу. Окремо виконайте читання того самого контракту на нещодавньому фіксованому блоці та на найстарішому блоці, необхідному вашому застосунку; зафіксуйте фактичний результат або помилку JSON-RPC. Протестуйте щільні та розріджені інтервали й порахуйте повторні спроби. Дотримуйтесь діапазон журналів і відновлення для збереження контрольних точок прогресу.
Безкоштовні кредити, ліміти швидкості та піковий трафік
Поточний циклічний бюджет BlockVectra та кількість викликів, яку він може покрити, розраховуються на основі планів:
Безкоштовний план вимагає реєстрації облікового запису та використання API key; усі ключі одного облікового запису ділять у середньому 25 викликів на секунду (дозволені короткі сплески). Наприкінці кожного 30-денного циклу баланси нижче 30,000,000 CU поповнюються до 30,000,000 CU.
| Метод | Вага CU | Приблизно викликів / цикл | Приблизно / день | Прайс-лист / 1M викликів |
|---|---|---|---|---|
eth_blockNumber | 1 | 30,000,000 | 1,000,000 | $0.10 |
eth_getBlockByNumber | 5 | 6,000,000 | 200,000 | $0.50 |
eth_getBalance | 10 | 3,000,000 | 100,000 | $1.00 |
eth_call | 15 | 2,000,000 | 66,666 | $1.50 |
eth_getLogs | 30 | 1,000,000 | 33,333 | $3.00 |
debug_traceTransaction | 100 | 300,000 | 10,000 | $10.00 |
data.block | 5 | 6,000,000 | 200,000 | $0.50 |
data.address_balances | 25 | 1,200,000 | 40,000 | $2.50 |
data.dex_prices | 15 | 2,000,000 | 66,666 | $1.50 |
data.transaction_trace | 200 | 150,000 | 5,000 | $20.00 |
Ліміт викликів для безкоштовного акаунта: до 25 викликів на секунду, спільно для всіх ключів облікового запису, усіх мереж і Data API. Для кожного ключа також діють ліміти cu_per_sec та burst_cu. Відповідне циклічне поповнення доводить безкоштовний баланс до цільового значення; воно не надає додаткової повної квоти. Перше платне поповнення зупиняє циклічні поповнення, зберігаючи залишкові безкоштовні CU. Дивіться правила безкоштовного плану.
Розрізняйте щоденні квоти, баланси циклів, запити/с, CU/с, ємність burst та одночасні запити. Сама по собі оплата додаткового використання не збільшує пропускну здатність для окремого ключа.
Самостійне тестування: використовуйте автентифікований ключ і невеликий обмежений пакет запитів із темпом і кількістю одночасних з'єднань, необхідними вашому завданню, у межах лімітів акаунта. Зафіксуйте статус HTTP, помилку JSON-RPC, перцентилі затримки та завершені виклики. Зупиняйтеся в разі вичерпання квоти; використовуйте обмежену експоненційну затримку (backoff) при тротлінгу та зберігайте прогрес. Повторіть тест із вибіркою змішаних методів, оскільки високовартісні методи споживають більше бюджету CU/с. Порівняйте пікове навантаження зі стабільним трафіком і враховуйте використання інших ключів при перевірці спільного ліміту акаунта.
Покриття мереж, методів і протоколів
Використовуйте каталог мереж, щоб перевірити ідентифікатор мережі, jsonrpc, methods.allow, methods.deny, public.methods, ws та subscriptions. Назва мережі не гарантує доступності кожного методу або протоколу. Методи без ключа та автентифіковані методи можуть мати різні ліміти.
Самостійне тестування: скопіюйте public.url обраної мережі та викличте метод із public.methods. Для наведеного нижче прикладу з Ethereum перевірте ID мережі, а потім виконайте необхідні методи застосунку з автентифікованим ключем і тими самими фіксованими блоками. Перевіряйте як правила заборони (deny), так і дозволу (allow); зіставляйте хеші блоків при порівнянні результатів між різними ендпоінтами.
curl --fail-with-body -sS --max-time 15 https://api.blockvectra.com/v1/eth_mainnet/public \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'Це перевіряє публічний метод, а не архівне покриття чи автентифіковану пропускну здатність. Якщо вашому застосунку потрібні сокети, протестуйте необхідну підписку, відключення та шлях відновлення з'єднання в мережі, яка декларує підтримку ws. Дивіться підписки WebSocket.
Доставка Push та індексовані дані
Для сповіщень щодо адрес перевірте декларацію push для мережі та її налаштування підтверджень. BlockVectra може відстежувати один і той самий набір адрес у кількох підтримуваних мережах в одній підписці з одним HTTPS-отримувачем; зіставте ліміти для самообслуговування та enterprise з кількістю ваших адрес. Для запитів до Data API перевірте набори даних та індексований діапазон у GET /v1/status. Індексовані записи не передбачають довільного історичного виконання контрактів. Опитування через RPC (polling), повідомлення WebSocket, доставлені події Push та відстежувані адресо-дні використовують різні розрахункові метрики; розраховуйте кожен необхідний робочий процес на основі відповідних коефіцієнтів у планах.
Самостійне тестування: для Push використовуйте контрольований вами HTTPS-отримувач, перевірте підписи та протестуйте обробку дублікатів, повторні спроби й повторне відтворення подій з контрольованої вами адреси. Для Data API надішліть запит на відому індексовану транзакцію або переказ, порівняйте її хеш блоку з даними RPC, пройдіть усю пагінацію та збережіть курсор перед відновленням. Зафіксуйте прогалини в покритті та кількість оплачуваних подій чи викликів. Використовуйте Webhook Push, Webhook проти WebSocket та довідник Data API для вибору відповідного шляху відновлення.
Автентифікація та доступ для агентів
Перевірте, чи може ваш клієнт безпечно передавати ключ, знаходити машиночитну документацію, створювати акаунт і відновлюватися після помилок. BlockVectra RPC приймає ключ у шляху за адресою POST /v1/{chain}/{api_key} або в заголовку x-api-key за адресою POST /v1/{chain}. Data API використовує x-api-key. Зберігайте ключі в серверному середовищі та уникайте їх потрапляння до клієнтського коду браузера, логів і повідомлень у чатах.
Розробники та AI-агенти використовують однакові ціни та ліміти. Програмна реєстрація описує створення акаунта на основі гаманця, а посібник для агентів надає документацію та точки входу MCP. Агенти можуть поповнювати баланс використання акаунта стейблкоїнами через документований процес поповнення без щомісячної підписки на RPC. Мережі поповнення, токени та мінімальні суми повертаються в GET /v1/topup/status.
Самостійне тестування: налаштуйте клієнт так, щоб він визначив мережу та метод, прочитав документацію, завантажив ключ зі свого середовища та виконав один обмежений автентифікований запит. Перевірте як статус HTTP, так і JSON-RPC error. Перевірте відповідь за відсутності ключа без логування облікових даних. Переконайтеся, що клієнт зберігає прогрес у разі недостатнього балансу, зчитує підтримувану мережу й токен для поповнення та дотримується документованого процесу поповнення; етапи створення акаунта та оплати мають використовувати акаунти під вашим контролем. Не вважайте підключення MCP до документації доказом того, що агент здатний виконати автентифікований виклик RPC.
Фіксація рішення
Ведіть короткий звіт про результати: джерело та дата вибірки; мережа й метод; хеш фіксованого блоку; повнота результату; загальна кількість викликів і повторних спроб; доступна квота; вартість платного завдання; затримка й тротлінг; прогалини в історії та протоколах; кроки відновлення; трудовитрати на міграцію. Якщо робоче навантаження вимагає контрактної підтримки або SLA, отримайте відповідні умови окремо від цих тестів API.
Коли ваше робоче навантаження визначено, порівняйте показники з конкретними провайдерами:
- Порівняйте з конкретними провайдерами: вартість обчислень та діапазони журналів.
- Порівняйте з конкретними провайдерами: пробний період та тарифікація за підпискою.
- Порівняйте з конкретними провайдерами: вартість запитів HTTPS.
- Порівняйте з конкретними провайдерами: щоденні та циклічні бюджети.
- Порівняйте з конкретними провайдерами: включені запити та перевищення ліміту.
Востаннє оновлено:
Розуміння ціноутворення CU
За поточними опублікованими тарифами eth_call коштує 15 CU за виклик, або $1.50 за мільйон викликів до застосування доступних безкоштовних кредитів; отримайте актуальні дані з API планів для оцінки вашого навантаження.
Сторінка активів гаманця
Створіть сторінку активів гаманця з ненульовими балансами токенів ERC-20, історією переказів токенів та пакетними метаданими. Перевіряйте покриття мереж, пагінуйте результати та масштабуйте цілочисельні суми за кількістю десяткових знаків.