Webhook blockchain, WebSocket và thăm dò: chọn quy trình

So sánh thông báo địa chỉ, đăng ký socket và thăm dò có giới hạn theo hỗ trợ chuỗi, khôi phục, yêu cầu bộ nhận và tính phí.

Dùng Webhook địa chỉ để gửi tới bộ nhận HTTPS, WebSocket cho đăng ký trực tiếp được hỗ trợ và thăm dò có giới hạn khi quy trình cần con trỏ và khả năng khôi phục riêng.

Xây dựng bộ theo dõi sự kiện trên chuỗi cho nhà phát triển và AI Agent đòi hỏi kiến trúc ứng dụng phù hợp với khả năng mạng, bảo đảm gửi sự kiện, ràng buộc bộ nhận và chi phí vận hành.

Bảng lựa chọn

Bảng bên dưới so sánh cả ba cơ chế tích hợp theo khả năng mạng được hỗ trợ, yêu cầu hạ tầng, chiến lược khôi phục và mô hình tính phí:

Tiêu chí	Webhook địa chỉ	Đăng ký WebSocket	Thăm dò RPC có giới hạn
Cơ chế chính	Thông báo Push gửi bằng HTTPS POST tới endpoint công khai	Đăng ký luồng nhận qua kết nối TLS duy trì liên tục (`wss://`)	Lô HTTP JSON-RPC hoặc truy vấn theo lịch do client khởi tạo
Chuỗi khả dụng	Toàn bộ mạng được hỗ trợ khai báo trong GET /v1/push/chains	Hỗ trợ trên Robinhood Chain (robinhood_mainnet và robinhood_testnet); mạng không được phục vụ có `ws: false` và trả HTTP 404	Toàn bộ mạng được hỗ trợ trong GET /v1/chains qua RPC công khai không cần key hoặc JSON-RPC có xác thực
Yêu cầu bộ nhận	URL HTTPS truy cập công khai, chứng chỉ TLS hợp lệ, phản hồi 2xx trong thời hạn, xác minh chữ ký HMAC SHA-256 của body gốc	Kết nối client TCP/TLS đi ra (`wss://`); xử lý heartbeat ping/pong và backoff khi kết nối lại	HTTP client không trạng thái hoặc worker theo lịch; lưu con trỏ khối cục bộ
Gửi và thứ tự	Gửi ít nhất một lần với backoff thử lại theo cấp số nhân; bộ nhận phải loại trùng theo `id` sự kiện, hoặc theo `ref` + `type` giữa các đăng ký	Frame được sắp thứ tự nghiêm ngặt trên một socket đang hoạt động; thông báo bị mất khi ngắt kết nối	Phản hồi truy vấn xác định cho độ cao khối đã xác nhận; client điều chỉnh nhịp thực thi
Tái tổ chức chuỗi	Phát thông báo điều khiển cho `chain.reorg`; bộ nhận loại bỏ sự kiện bị thay thế trước khi áp dụng phát lại từ chuỗi chuẩn	Thông báo log có `"removed": true` cho log bị tái tổ chức; `newHeads` cần kiểm tra hash khối cha	Client theo dõi tính liên tục của chuỗi qua `parentHash` giữa các lần thăm dò để phát hiện tái tổ chức
Khôi phục lỗi	Cửa sổ lưu giữ máy chủ cho phép phát lại qua `POST /v1/push/subscriptions/{id}/replay`; khoảng trống trước khối kích hoạt cần truy xuất bổ sung bằng `eth_getLogs`	Không có hàng đợi phía máy chủ; client kết nối lại và truy xuất khoảng bị bỏ lỡ bằng `eth_getLogs`, loại trùng theo `(blockHash, transactionHash, logIndex)`	Tiếp tục truy vấn từ `last_synced_block` đã lưu; chia phần theo `max_logs_block_range` của mạng từ GET /v1/chains
Mô hình tính phí	Phí địa chỉ hằng ngày theo nhóm, dựa trên số địa chỉ lớn nhất khi trực tuyến trong ngày UTC, cộng CU cho sự kiện dữ liệu đã gửi; xem tính phí Webhook	Handshake và heartbeat không tính phí; `eth_subscribe` / `eth_unsubscribe` và đơn vị thông báo socket đã flush tính phí bằng CU	Đo lường mỗi yêu cầu bằng Compute Unit: `eth_blockNumber`, `eth_call`, `eth_getLogs`; trọng số phương thức và CU mỗi $1 từ GET /v1/plans, được hiển thị bên dưới
Phù hợp nhất cho	Giám sát tiền nạp người dùng, theo dõi địa chỉ ví nóng, thanh toán người bán, Webhook sự kiện bất đồng bộ	`newHeads` trực tiếp và `logs` đã lọc, bot phản ứng theo sự kiện, giao diện tương tác trên mạng được hỗ trợ	Đối chiếu theo lô, cron job, pipeline ETL, chuỗi không hỗ trợ WebSocket (chẳng hạn HyperEVM)

Thông số quy đổi hiện tại

1 USD = 10,000 đơn vị thanh toán, 1 đơn vị thanh toán = 1,000 CU (1 USD = 10,000,000 CU).

Công thức: Trọng số CU × 1,000,000 ÷ (10,000 × 1,000) USD.

Phương thức	CU mỗi lệnh gọi	Giá cho mỗi 1M lệnh gọi (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

Khi nào chọn Webhook địa chỉ

Chọn Blockchain Webhook API khi backend chạy dưới dạng dịch vụ web tiêu chuẩn có thể nhận yêu cầu HTTPS đi vào:

Danh sách địa chỉ lớn: Giám sát nạp hoặc rút tiền trên hàng nghìn địa chỉ khách hàng mà không duy trì socket liên tục cho từng ví.
Bộ nhận serverless hoặc trong container: Hàm serverless (AWS Lambda, Cloudflare Workers) khởi chạy khi Webhook đến và không cần duy trì kết nối liên tục.
Thử lại và phát lại tự động: Sự cố bộ nhận tạm thời được giảm thiểu bằng backoff thử lại tự động. Trong cửa sổ lưu giữ máy chủ, có thể gửi lại thông báo bị bỏ lỡ bằng endpoint phát lại.
Lưu ý ranh giới kích hoạt: Việc khớp chỉ bắt đầu sau khi thay đổi đăng ký được áp dụng (applied_from_block). Sự kiện xảy ra trước khi thêm địa chỉ hoặc khi đăng ký offline phải được truy vấn qua log RPC lịch sử.

Xem quy trình xác minh chữ ký và phát lại trước khi mở bộ nhận Webhook production ra ngoài.

Khi nào chọn đăng ký WebSocket

Chọn Đăng ký WebSocket khi cần độ trễ thấp và tiến trình có thể duy trì socket đi ra lâu dài:

Header khối trực tiếp: Nhận luồng newHeads khi mỗi khối được thêm vào đầu chuỗi.
Bộ lọc sự kiện hợp đồng: Nhận luồng logs hợp đồng thời gian thực khớp địa chỉ hoặc topic0 cụ thể.
Môi trường riêng tư: Phù hợp cho script cục bộ, CLI Agent hoặc dịch vụ backend sau NAT hay tường lửa không thể mở port HTTPS công khai đi vào.
Kiểm tra khả năng mạng: WebSocket được hỗ trợ trên Robinhood Chain (slug mạng robinhood_mainnet, Chain ID 4663, và robinhood_testnet). HyperEVM hiện không hỗ trợ WebSocket (ws: false); thử kết nối WebSocket tới chuỗi không được phục vụ trả HTTP 404 (unknown_chain).
Xử lý ngắt kết nối: Thông báo WebSocket không được giữ trên máy chủ qua các lần ngắt kết nối. Khi socket mất kết nối, client phải kết nối lại với backoff cấp số nhân có ngẫu nhiên hóa và truy xuất bổ sung khối bị bỏ lỡ qua eth_getLogs.

Xem hướng dẫn Đăng ký WebSocket để biết giới hạn lọc, giới hạn kết nối (20 mỗi key, 50 mỗi tài khoản) và ví dụ kết nối viem.

Khi nào chọn thăm dò RPC có giới hạn

Chọn thăm dò JSON-RPC có giới hạn khi chạy worker theo lịch, pipeline dữ liệu hoặc hoạt động trên mạng không có WebSocket:

Mạng không có WebSocket: HyperEVM (hyperevm_mainnet) hiện cung cấp truy cập JSON-RPC HTTP nhưng không có WebSocket (ws: false). Thăm dò eth_blockNumber và truy vấn eth_getLogs trong khoảng khối được hỗ trợ cho phép xử lý sự kiện HyperEVM.
Kiểm soát nhịp truy vấn: Thăm dò cho phép nhà phát triển và AI Agent kiểm soát tần suất yêu cầu, quản lý tiêu thụ Compute Unit theo giới hạn tốc độ mỗi key và tránh mất kết nối socket trong tác vụ chạy lâu. Giới hạn mỗi key — mặc định là 400 CU/s và burst 1,600 CU.
Giới hạn khoảng khối: Truy vấn eth_getLogs có xác thực bị giới hạn bởi max_logs_block_range của mạng từ GET /v1/chains. Vượt giới hạn trả mã lỗi -32602 (logs_range_too_large). Chia khoảng rộng hơn thành các phần liên tiếp không vượt max_logs_block_range của mạng đích.

Chuỗi	Slug chuỗi	max_logs_block_range (khối)
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

Xem hướng dẫn truy xuất bổ sung log HyperEVM và hướng dẫn khoảng khối eth_getLogs để biết thuật toán chia phần.

Để có danh sách kiểm tra tác vụ đầy đủ và tự kiểm tra, bắt đầu với Cách chọn nhà cung cấp RPC.

Khi chọn nhà cung cấp cho thăm dò ít lưu lượng, so sánh nhà cung cấp theo tính phí RPC tiêu chuẩn và phạm vi hỗ trợ. So sánh tính phí theo sử dụng với chi phí dùng thử và thuê bao; thông báo và truy xuất bổ sung dùng cách đo phí khác với truy vấn đọc RPC.

Hướng dẫn triển khai

WebSocket trên Robinhood Chain

Với newHeads trực tiếp hoặc logs đã lọc trên Robinhood Chain, làm theo hướng dẫn Đăng ký WebSocket để xác thực và gửi yêu cầu đăng ký. Sau khi ngắt kết nối, kết nối lại với backoff, đăng ký lại và truy xuất bổ sung khối bị bỏ lỡ từ con trỏ đã lưu bằng eth_getLogs; loại trùng log theo (blockHash, transactionHash, logIndex).

Thăm dò có giới hạn trên HyperEVM

Với HyperEVM (hyperevm_mainnet), làm theo hướng dẫn truy xuất bổ sung log HyperEVM để thăm dò có giới hạn và khôi phục. Truy vấn từ con trỏ đã lưu theo phần trong max_logs_block_range, lưu bền vững sự kiện và tiến độ cùng nhau sau khi xử lý thành công, và thử lại khoảng chưa hoàn thành. Kiểm tra tính liên tục của chuỗi và quét khoảng chồng lấn để xử lý tái tổ chức.

Các bước tiếp theo

Duyệt danh mục bộ dữ liệu để xem mọi bộ dữ liệu BlockVectra lập chỉ mục.
Xem gói miễn phí và giá để kiểm tra những gì tài khoản bao gồm.
Đăng nhập bảng điều khiển để tạo API key.

Chọn Webhook, WebSocket hoặc thăm dò RPC