Memilih Webhook, WebSocket, atau Polling RPC
Bandingkan notifikasi alamat, langganan socket, dan polling berbatas berdasarkan dukungan chain, pemulihan, persyaratan penerima, serta penagihan.
Gunakan Webhook alamat untuk pengiriman ke penerima HTTPS, WebSocket untuk langganan langsung yang didukung, dan polling berbatas ketika alur kerja memerlukan kursor serta pemulihan sendiri.
Membangun pendengar peristiwa on-chain untuk pengembang dan AI Agent memerlukan kesesuaian arsitektur aplikasi dengan kemampuan jaringan, jaminan pengiriman, batasan penerima, dan biaya operasional.
Matriks keputusan
Tabel berikut membandingkan ketiga mekanisme integrasi berdasarkan kemampuan jaringan yang didukung, persyaratan infrastruktur, strategi pemulihan, dan model penagihan:
| Dimensi | Webhook Alamat | Langganan WebSocket | Polling RPC Berbatas |
|---|---|---|---|
| Mekanisme utama | Notifikasi push dikirim melalui HTTPS POST ke endpoint publik | Langganan aliran tarik melalui koneksi TLS persisten (wss://) | Batch JSON-RPC HTTP atau kueri terjadwal yang dimulai klien |
| Ketersediaan chain | Semua jaringan yang didukung dan dinyatakan dalam GET /v1/push/chains | Didukung di Robinhood Chain (robinhood_mainnet dan robinhood_testnet); jaringan yang tidak dilayani memiliki ws: false dan mengembalikan HTTP 404 | Semua jaringan yang didukung dalam GET /v1/chains melalui RPC publik tanpa API key atau JSON-RPC terautentikasi |
| Persyaratan penerima | URL HTTPS yang dapat diakses publik, sertifikat TLS valid, respons 2xx dalam batas waktu, verifikasi tanda tangan HMAC SHA-256 body mentah | Koneksi klien TCP/TLS keluar (wss://); menangani heartbeat ping/pong dan backoff penyambungan kembali | Klien HTTP tanpa state atau worker terjadwal; menyimpan kursor blok lokal |
| Pengiriman dan urutan | Pengiriman setidaknya sekali dengan backoff percobaan ulang eksponensial; penerima harus melakukan deduplikasi berdasarkan id peristiwa, atau ref + type lintas langganan | Frame berurutan secara ketat pada satu socket aktif; notifikasi hilang selama koneksi terputus | Respons tarik deterministik untuk tinggi blok terkonfirmasi; klien mengatur ritme eksekusi |
| Reorganisasi chain | Notifikasi kontrol diterbitkan untuk chain.reorg; penerima membuang peristiwa yang diganti sebelum menerapkan replay kanonis | Notifikasi log membawa "removed": true untuk log yang terkena reorg; newHeads memerlukan pemeriksaan hash induk | Klien melacak kesinambungan chain parentHash antarputaran polling untuk mendeteksi reorg |
| Pemulihan kegagalan | Jendela retensi server memungkinkan replay melalui POST /v1/push/subscriptions/{id}/replay; celah sebelum blok aktivasi memerlukan backfill eth_getLogs | Tidak ada antrean sisi server; klien menyambung kembali dan melakukan backfill rentang yang terlewat melalui eth_getLogs dengan deduplikasi berdasarkan (blockHash, transactionHash, logIndex) | Melanjutkan kueri dari last_synced_block yang disimpan; membagi potongan berdasarkan max_logs_block_range jaringan dari GET /v1/chains |
| Model penagihan | Biaya alamat harian per grup, berdasarkan jumlah alamat terbesar saat online selama hari UTC, ditambah CU untuk peristiwa data terkirim; lihat penagihan Webhook | Handshake dan heartbeat tidak ditagih; eth_subscribe / eth_unsubscribe serta unit notifikasi socket yang telah dikirim ditagih dalam CU | Setiap permintaan diukur dalam Compute Units: eth_blockNumber, eth_call, eth_getLogs; bobot metode dan CU per $1 dari GET /v1/plans, ditampilkan di bawah |
| Paling cocok untuk | Pemantauan deposit pengguna, pelacakan alamat hot wallet, checkout pedagang, Webhook peristiwa asinkron | newHeads langsung dan logs terfilter, bot reaktif, UI interaktif pada jaringan yang didukung | Rekonsiliasi batch, cron job, pipeline ETL, chain tanpa dukungan WebSocket (seperti HyperEVM) |
Parameter Konversi Aktif
1 USD = 10,000 unit penagihan, 1 unit penagihan = 1,000 CU (1 USD = 10,000,000 CU).
Rumus: Bobot CU × 1,000,000 ÷ (10,000 × 1,000) USD.
| Metode | CU per panggilan | Harga per 1M panggilan (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 |
Kapan memilih Webhook alamat
Pilih Blockchain Webhook API ketika backend Anda berjalan sebagai layanan web standar yang dapat menerima permintaan HTTPS masuk:
- Daftar alamat besar: Pantau deposit atau penarikan di ribuan alamat pelanggan tanpa mempertahankan socket persisten per dompet.
- Penerima serverless atau dalam kontainer: Fungsi serverless (AWS Lambda, Cloudflare Workers) aktif saat menerima Webhook masuk dan tidak perlu mempertahankan koneksi terus-menerus.
- Percobaan ulang dan replay otomatis: Gangguan sementara penerima ditangani dengan backoff percobaan ulang otomatis. Dalam jendela retensi server, pengiriman yang terlewat dapat dikirim ulang menggunakan endpoint replay.
- Pertimbangan batas aktivasi: Pencocokan hanya dimulai setelah perubahan langganan diterapkan (
applied_from_block). Peristiwa yang terjadi sebelum alamat ditambahkan atau saat langgananofflineharus dikueri melalui log RPC historis.
Tinjau verifikasi tanda tangan dan alur replay sebelum membuka penerima Webhook produksi.
Kapan memilih langganan WebSocket
Pilih Langganan WebSocket ketika latensi rendah diperlukan dan proses Anda dapat mempertahankan socket keluar yang berjalan lama:
- Header blok langsung: Lakukan streaming
newHeadssaat setiap blok ditambahkan ke head chain. - Filter peristiwa kontrak: Lakukan streaming
logskontrak secara real-time yang cocok dengan alamat atautopic0tertentu. - Lingkungan privat: Cocok untuk skrip lokal, Agent CLI, atau layanan backend di balik NAT atau firewall yang tidak dapat membuka port HTTPS publik untuk koneksi masuk.
- Pemeriksaan ketersediaan jaringan: WebSocket didukung di Robinhood Chain (slug jaringan
robinhood_mainnet, Chain ID 4663, danrobinhood_testnet). HyperEVM saat ini tidak mendukung WebSocket (ws: false); mencoba koneksi WebSocket ke chain yang tidak dilayani mengembalikan HTTP 404 (unknown_chain). - Disiplin saat koneksi terputus: Notifikasi WebSocket tidak disimpan di server selama pemutusan koneksi. Saat socket terputus, klien harus menyambung kembali dengan backoff eksponensial acak dan melakukan backfill blok yang terlewat melalui
eth_getLogs.
Tinjau panduan Langganan WebSocket untuk batas filter, batas koneksi (20 per API key, 50 per akun), dan contoh koneksi viem.
Kapan memilih polling RPC berbatas
Pilih polling JSON-RPC berbatas ketika menjalankan worker terjadwal, pipeline data, atau bekerja pada jaringan tanpa WebSocket:
- Jaringan tanpa WebSocket: HyperEVM (
hyperevm_mainnet) saat ini menyediakan akses JSON-RPC HTTP tetapi tanpa WebSocket (ws: false). Pollingeth_blockNumberdan kuerieth_getLogsdalam rentang blok yang didukung memungkinkan pemrosesan peristiwa HyperEVM. - Ritme kueri terkendali: Polling memungkinkan pengembang dan AI Agent mengatur frekuensi permintaan, mengelola konsumsi Compute Unit terhadap batas laju per API key, dan menghindari socket terputus saat tugas berjalan lama. Batas per API key — default adalah 400 CU/dtk dan burst 1,600 CU.
- Batas rentang blok: Kueri
eth_getLogsterautentikasi dibatasi olehmax_logs_block_rangejaringan dari GET /v1/chains. Melebihi batas ini mengembalikan kode error-32602(logs_range_too_large). Bagi interval lebih lebar menjadi potongan berurutan yang tidak melebihimax_logs_block_rangejaringan tujuan.
| Rantai | Slug rantai | max_logs_block_range (blok) |
|---|---|---|
| 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 |
Lihat panduan backfill log HyperEVM dan panduan rentang blok eth_getLogs untuk algoritme pembagian potongan.
Untuk daftar pemeriksaan beban kerja lengkap dan pengujian mandiri, mulai dengan Cara memilih penyedia RPC.
Saat memilih penyedia untuk polling bervolume rendah, bandingkan penyedia untuk penagihan dan cakupan RPC standar. Bandingkan penagihan penggunaan dengan biaya uji coba dan langganan; biaya notifikasi dan backfill menggunakan meter berbeda dari pembacaan RPC.
Panduan implementasi
WebSocket di Robinhood Chain
Untuk newHeads langsung atau logs terfilter di Robinhood Chain, ikuti panduan Langganan WebSocket untuk autentikasi dan permintaan langganan. Setelah koneksi terputus, sambungkan kembali dengan backoff, berlangganan kembali, dan lakukan backfill blok yang terlewat dari kursor tersimpan dengan eth_getLogs; deduplikasi log berdasarkan (blockHash, transactionHash, logIndex).
Polling berbatas di HyperEVM
Untuk HyperEVM (hyperevm_mainnet), ikuti panduan backfill log HyperEVM untuk polling berbatas dan pemulihan. Kueri dari kursor tersimpan dalam potongan yang tidak melebihi max_logs_block_range, simpan peristiwa dan kemajuan secara persisten bersama-sama setelah pemrosesan berhasil, lalu coba ulang rentang yang belum lengkap. Periksa kesinambungan chain dan pindai rentang tumpang tindih untuk menangani reorg.
Langkah selanjutnya
- Jelajahi direktori dataset untuk melihat setiap dataset yang diindeks BlockVectra.
- Lihat paket gratis dan harga untuk memeriksa apa yang termasuk dalam akun Anda.
- Masuk ke konsol untuk membuat API key.
Terakhir diperbarui: