# Chọn Webhook, WebSocket hoặc thăm dò RPC > Source: https://docs.blockvectra.com/vi/guides/webhook-vs-websocket/ 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](https://api.blockvectra.com/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](https://api.blockvectra.com/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](https://api.blockvectra.com/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](https://docs.blockvectra.com/vi/guides/webhook-push/#billing-and-example) | 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](https://console-api.blockvectra.com/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](https://docs.blockvectra.com/vi/guides/webhook-push/) 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](https://docs.blockvectra.com/vi/guides/webhook-push/#verify-signatures) 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](https://docs.blockvectra.com/en/guides/websocket-subscriptions/) 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`](https://docs.blockvectra.com/en/errors/#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](https://docs.blockvectra.com/en/guides/websocket-subscriptions/) để 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](https://api.blockvectra.com/v1/chains). Vượt giới hạn trả mã lỗi `-32602` ([`logs_range_too_large`](https://docs.blockvectra.com/en/errors/#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](https://docs.blockvectra.com/vi/guides/hyperevm-backfill/) và [hướng dẫn khoảng khối eth\_getLogs](https://docs.blockvectra.com/vi/guides/getlogs-block-range/) để 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](https://docs.blockvectra.com/vi/guides/choose-rpc-provider/). 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ợ](https://docs.blockvectra.com/en/guides/quicknode-alternative/). 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](https://docs.blockvectra.com/en/guides/websocket-subscriptions/) để 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](https://docs.blockvectra.com/vi/guides/hyperevm-backfill/) để 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](https://blockvectra.com/en/data/) để xem mọi bộ dữ liệu BlockVectra lập chỉ mục. * [Xem gói miễn phí và giá](https://blockvectra.com/en/pricing/#free) để kiểm tra những gì tài khoản bao gồm. * [Đăng nhập bảng điều khiển](https://console.blockvectra.com/login/?next=%2Fkeys%2F) để tạo API key.