เลือกระหว่าง Webhook, WebSocket หรือการโพลล์ RPC
เปรียบเทียบการแจ้งเตือนแอดเดรส, การติดตามผ่าน socket และการโพลล์แบบจำกัดขอบเขต ตามการรองรับของเชน, การกู้คืน, ข้อกำหนดของตัวรับ และการเรียกเก็บเงิน
ใช้ Webhook สำหรับแอดเดรสเพื่อนำส่งไปยังตัวรับ HTTPS, ใช้ WebSocket สำหรับการติดตามสดบนเครือข่ายที่รองรับ และใช้การโพลล์แบบจำกัดขอบเขตเมื่อเวิร์กโฟลว์ต้องการเคอร์เซอร์และการกู้คืนของตนเอง
การสร้างตัวรับฟังเหตุการณ์บนเชนสำหรับนักพัฒนาและ AI Agent จำเป็นต้องจับคู่สถาปัตยกรรมแอปพลิเคชันให้เข้ากับความสามารถของเครือข่าย, การรับประกันการนำส่ง, ข้อจำกัดของตัวรับ และต้นทุนการดำเนินงาน
Decision matrix
ตารางด้านล่างเปรียบเทียบกลไกการผสานรวมทั้งสามแบบข้ามความสามารถของเครือข่ายที่รองรับ, ข้อกำหนดด้านโครงสร้างพื้นฐาน, กลยุทธ์การกู้คืน และโมเดลการเรียกเก็บเงิน:
| Dimension | Address Webhooks | WebSocket Subscriptions | Bounded RPC Polling |
|---|---|---|---|
| Primary mechanism | การแจ้งเตือนแบบ Push ที่นำส่งผ่าน HTTPS POST ไปยัง endpoint สาธารณะ | การติดตามแบบ Pull-stream ผ่านการเชื่อมต่อ TLS แบบต่อเนื่อง (wss://) | คำขอแบทช์หรือการคิวรีตามกำหนดเวลาของ HTTP JSON-RPC ที่เริ่มต้นโดยไคลเอนต์ |
| Chain availability | ทุกเครือข่ายที่รองรับตามที่ประกาศใน GET /v1/push/chains | รองรับบน Robinhood Chain (robinhood_mainnet และ robinhood_testnet); เครือข่ายที่ไม่ให้บริการมี ws: false และส่งกลับ HTTP 404 | ทุกเครือข่ายที่รองรับใน GET /v1/chains ผ่าน public RPC แบบไม่ต้องใช้คีย์ หรือ JSON-RPC ที่มีการยืนยันตัวตน |
| Receiver requirements | HTTPS URL ที่เข้าถึงได้แบบสาธารณะ, ใบรับรอง TLS ที่ถูกต้อง, การตอบกลับ 2xx ภายในระยะเวลาหมดเวลา, การตรวจสอบลายเซ็น HMAC SHA-256 บน raw-body | การเชื่อมต่อไคลเอนต์ TCP/TLS ขาออก (wss://); จัดการ ping/pong heartbeat และการหน่วงเวลาเชื่อมต่อใหม่ | HTTP client หรือ scheduled worker แบบ stateless; จัดเก็บเคอร์เซอร์บล็อกไว้ในเครื่อง |
| Delivery & ordering | การนำส่งแบบอย่างน้อยหนึ่งครั้งพร้อม exponential retry backoff; ตัวรับต้องขจัดข้อมูลซ้ำตาม id ของเหตุการณ์ หรือตาม ref + type ข้ามการติดตาม | เฟรมที่เรียงลำดับอย่างเคร่งครัดบน socket เดียวที่ใช้งานอยู่; การแจ้งเตือนจะตกหล่นระหว่างที่หลุดการเชื่อมต่อ | การตอบกลับแบบ pull ที่กำหนดแน่นอนสำหรับความสูงของบล็อกที่ได้รับการยืนยันแล้ว; ไคลเอนต์เป็นผู้ควบคุมจังหวะการทำงาน |
| Chain reorganizations | การแจ้งเตือนควบคุมที่ส่งออกมาสำหรับ chain.reorg; ตัวรับจะละทิ้งเหตุการณ์ที่ถูกแทนที่ก่อนนำ replay แบบ canonical ไปใช้ | การแจ้งเตือน log มี "removed": true สำหรับ log ที่ถูก reorg; newHeads กำหนดให้ต้องตรวจสอบ parent hash | ไคลเอนต์ติดตามความต่อเนื่องของเชน parentHash ข้ามรอบการโพลล์เพื่อตรวจจับ reorg |
| Failure recovery | หน้าต่างการเก็บรักษาของเซิร์ฟเวอร์อนุญาตให้ replay ผ่าน POST /v1/push/subscriptions/{id}/replay; ช่องว่างก่อนบล็อกที่เปิดใช้งานต้องดึงข้อมูลย้อนหลังผ่าน eth_getLogs | ไม่มีคิวฝั่งเซิร์ฟเวอร์; ไคลเอนต์เชื่อมต่อใหม่และดึงข้อมูลย้อนหลังในช่วงที่พลาดไปผ่าน eth_getLogs โดยขจัดข้อมูลซ้ำตาม (blockHash, transactionHash, logIndex) | ทำการคิวรีต่อจาก last_synced_block ที่จัดเก็บไว้; แบ่ง chunk ตาม max_logs_block_range ของเครือข่ายจาก GET /v1/chains |
| Billing model | ค่าธรรมเนียมแอดเดรสรายวันต่อกลุ่ม อิงตามจำนวนแอดเดรสสูงสุดขณะ online ในระหว่างวัน UTC บวกด้วย CU สำหรับเหตุการณ์ข้อมูลที่นำส่งแล้ว; ดู การเรียกเก็บเงินของ Webhook | แฮนด์เชกและ heartbeat ไม่คิดค่าบริการ; eth_subscribe / eth_unsubscribe และหน่วยการแจ้งเตือน socket ที่ flush แล้วคิดค่าบริการเป็น CU | วัดปริมาณต่อคำขอเป็น Compute Units: eth_blockNumber, eth_call, eth_getLogs; น้ำหนักของเมธอดและ CU ต่อ $1 จาก GET /v1/plans แสดงอยู่ด้านล่าง |
| Best suited for | การตรวจสอบการฝากเงินของผู้ใช้, การติดตามแอดเดรส hot-wallet, การชำระเงินของร้านค้า, webhook เหตุการณ์แบบอะซิงโครนัส | newHeads สดและ logs ที่กรองแล้ว, บอทที่ทำงานตามการตอบสนอง, UI แบบโต้ตอบบนเครือข่ายที่รองรับ | การกระทบยอดแบบแบตช์, cron job, ETL pipeline, เชนที่ไม่รองรับ 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 |
When to choose address Webhooks
เลือก Blockchain Webhook API เมื่อแบ็กเอนด์ของคุณทำงานเป็นบริการเว็บมาตรฐานที่สามารถรับคำขอ HTTPS ขาเข้าได้:
- Large address lists: ตรวจสอบการฝากหรือถอนข้ามแอดเดรสลูกค้านับพันรายการโดยไม่ต้องรักษาการเชื่อมต่อ socket แบบต่อเนื่องสำหรับแต่ละกระเป๋าเงิน
- Serverless or containerized receivers: ฟังก์ชัน Serverless (AWS Lambda, Cloudflare Workers) จะเริ่มทำงานเมื่อมี webhook เข้ามา และไม่จำเป็นต้องเปิดการเชื่อมต่อทิ้งไว้ตลอดเวลา
- Automated retries and replay: การหยุดทำงานชั่วคราวของตัวรับจะได้รับการบรรเทาด้วย automatic retry backoff ภายในหน้าต่างการเก็บรักษาของเซิร์ฟเวอร์ การนำส่งที่พลาดไปสามารถส่งซ้ำได้โดยใช้ endpoint สำหรับการ replay
- Activation boundary considerations: การจับคู่จะเริ่มต้นหลังจากที่การเปลี่ยนแปลงการติดตามมีผลบังคับใช้แล้วเท่านั้น (
applied_from_block) เหตุการณ์ที่เกิดขึ้นก่อนที่จะเพิ่มแอดเดรสหรือในระหว่างที่การติดตามอยู่ในสถานะofflineต้องคิวรีผ่าน historical RPC log
ตรวจสอบ เวิร์กโฟลว์การตรวจสอบลายเซ็นและการ replay ก่อนเปิดเผยตัวรับ webhook สำหรับโปรดักชัน
When to choose WebSocket subscriptions
เลือก การติดตามผ่าน WebSocket เมื่อต้องการความหน่วงต่ำ และโปรเซสของคุณสามารถรักษาการเชื่อมต่อ socket ขาออกที่ทำงานต่อเนื่องเป็นเวลานานได้:
- Live block headers: สตรีม
newHeadsเมื่อแต่ละบล็อกถูกเพิ่มเข้าไปยัง head ของเชน - Contract event filters: สตรีม contract
logsแบบเรียลไทม์ที่ตรงกับแอดเดรสหรือtopic0ที่ระบุ - Private environments: เหมาะสำหรับสคริปต์ในเครื่อง, CLI agent หรือบริการแบ็กเอนด์ที่อยู่หลัง NAT หรือไฟร์วอลล์ซึ่งไม่สามารถเปิดเผยพอร์ต HTTPS สาธารณะขาเข้าได้
- Network availability check: WebSocket รองรับบน Robinhood Chain (สลักเครือข่าย
robinhood_mainnet, Chain ID 4663 และrobinhood_testnet) ปัจจุบัน HyperEVM ยังไม่รองรับ WebSocket (ws: false); การพยายามเชื่อมต่อ WebSocket ไปยังเชนที่ไม่ให้บริการจะส่งกลับ HTTP 404 (unknown_chain) - Disconnection discipline: การแจ้งเตือน WebSocket จะไม่ถูกเก็บรักษาไว้บนเซิร์ฟเวอร์เมื่อหลุดการเชื่อมต่อ เมื่อ socket หลุด ไคลเอนต์ต้องเชื่อมต่อใหม่ด้วย randomized exponential backoff และดึงข้อมูลบล็อกที่พลาดไปย้อนหลังผ่าน
eth_getLogs
ตรวจสอบ คู่มือการติดตามผ่าน WebSocket สำหรับขีดจำกัดของตัวกรอง, ขีดจำกัดการเชื่อมต่อ (20 การเชื่อมต่อต่อคีย์, 50 การเชื่อมต่อต่อบัญชี) และตัวอย่างการเชื่อมต่อด้วย viem
When to choose bounded RPC polling
เลือกการโพลล์ JSON-RPC แบบจำกัดขอบเขตเมื่อเรียกใช้ scheduled worker, data pipeline หรือทำงานบนเครือข่ายที่ไม่มี WebSocket:
- Networks without WebSocket: ปัจจุบัน HyperEVM (
hyperevm_mainnet) ให้บริการการเข้าถึง JSON-RPC ผ่าน HTTP แต่ไม่มี WebSocket (ws: false) การโพลล์eth_blockNumberและการคิวรีeth_getLogsภายในช่วงบล็อกที่รองรับช่วยรองรับการประมวลผลเหตุการณ์ของ HyperEVM - Controlled query pacing: การโพลล์ช่วยให้นักพัฒนาและ AI Agent สามารถควบคุมความถี่ของคำขอ, จัดการการใช้ Compute Unit เทียบกับขีดจำกัดอัตราต่อคีย์ และหลีกเลี่ยงปัญหา socket หลุดระหว่างการทำงานที่ใช้เวลานาน ขีดจำกัดต่อคีย์ — ค่าเริ่มต้นคือ 400 CU/s และ burst 1,600 CU
- Block range limits: คำขอ
eth_getLogsที่ยืนยันตัวตนจะถูกจำกัดโดยmax_logs_block_rangeของเครือข่ายจาก GET /v1/chains การเกินขีดจำกัดนี้จะส่งกลับรหัสข้อผิดพลาด-32602(logs_range_too_large) ให้แบ่งช่วงที่กว้างกว่าออกเป็น chunk ต่อเนื่องกันโดยไม่เกินmax_logs_block_rangeของเครือข่ายเป้าหมาย
| เชน | Slug เชน | 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 |
ดู คู่มือการดึงข้อมูล log ของ HyperEVM ย้อนหลัง และ คู่มือช่วงบล็อก eth_getLogs สำหรับอัลกอริทึมการแบ่ง chunk
สำหรับรายการตรวจสอบเวิร์กโหลดและแบบทดสอบตนเองฉบับสมบูรณ์ เริ่มต้นที่ วิธีเลือกผู้ให้บริการ RPC
เมื่อเลือกผู้ให้บริการสำหรับการโพลล์ในปริมาณน้อย เปรียบเทียบผู้ให้บริการสำหรับการเรียกเก็บเงินและความครอบคลุมของ RPC มาตรฐาน เปรียบเทียบการเรียกเก็บเงินตามการใช้งานกับค่าใช้จ่ายช่วงทดลองใช้และการสมัครสมาชิก; ค่าใช้จ่ายในการแจ้งเตือนและการดึงข้อมูลย้อนหลังใช้มิเตอร์คนละตัวกับการอ่านผ่าน RPC
คู่มือการเชื่อมต่อ
WebSocket บน Robinhood Chain
สำหรับ newHeads สด หรือ logs ที่กรองแล้วบน Robinhood Chain โปรดทำตาม คู่มือการติดตามผ่าน WebSocket สำหรับการยืนยันตัวตนและคำขอการติดตาม หลังจากการหลุดการเชื่อมต่อ ให้เชื่อมต่อใหม่ด้วย backoff สมัครรับข้อมูลใหม่ และดึงข้อมูลบล็อกที่พลาดไปย้อนหลังจากเคอร์เซอร์ที่บันทึกไว้ด้วย eth_getLogs; ขจัด log ที่ซ้ำกันตาม (blockHash, transactionHash, logIndex)
การโพลล์แบบจำกัดขอบเขตบน HyperEVM
สำหรับ HyperEVM (hyperevm_mainnet) โปรดทำตาม คู่มือการดึงข้อมูล log ของ HyperEVM ย้อนหลัง สำหรับการโพลล์แบบจำกัดขอบเขตและการกู้คืน คิวรีจากเคอร์เซอร์ที่บันทึกไว้เป็น chunk ภายใน max_logs_block_range, บันทึกเหตุการณ์และความคืบหน้าไว้ด้วยกันหลังจากการประมวลผลสำเร็จ และลองใหม่สำหรับช่วงที่ไม่สมบูรณ์ ตรวจสอบความต่อเนื่องของเชนและสแกนช่วงที่ทับซ้อนกันเพื่อจัดการกับ reorg
ขั้นตอนถัดไป
- เลือกดูสารบบชุดข้อมูล เพื่อดูทุกชุดข้อมูลที่ BlockVectra ทำดัชนี
- ดูแผนบริการฟรีและราคา เพื่อตรวจสอบสิ่งที่บัญชีของคุณได้รับ
- เข้าสู่ระบบคอนโซล เพื่อสร้าง API key
อัปเดตล่าสุด: