# เลือกระหว่าง Webhook, WebSocket หรือการโพลล์ RPC > Source: https://docs.blockvectra.com/th/guides/webhook-vs-websocket/ ใช้ Webhook สำหรับแอดเดรสเพื่อนำส่งไปยังตัวรับ HTTPS, ใช้ WebSocket สำหรับการติดตามสดบนเครือข่ายที่รองรับ และใช้การโพลล์แบบจำกัดขอบเขตเมื่อเวิร์กโฟลว์ต้องการเคอร์เซอร์และการกู้คืนของตนเอง การสร้างตัวรับฟังเหตุการณ์บนเชนสำหรับนักพัฒนาและ AI Agent จำเป็นต้องจับคู่สถาปัตยกรรมแอปพลิเคชันให้เข้ากับความสามารถของเครือข่าย, การรับประกันการนำส่ง, ข้อจำกัดของตัวรับ และต้นทุนการดำเนินงาน ## เมทริกซ์การตัดสินใจ ตารางด้านล่างเปรียบเทียบกลไกการผสานรวมทั้งสามแบบข้ามความสามารถของเครือข่ายที่รองรับ, ข้อกำหนดด้านโครงสร้างพื้นฐาน, กลยุทธ์การกู้คืน และโมเดลการเรียกเก็บเงิน: | มิติการเปรียบเทียบ | Address Webhooks | การติดตามผ่าน WebSocket | การโพลล์ RPC แบบจำกัดขอบเขต | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **กลไกหลัก** | การแจ้งเตือนแบบ Push ที่นำส่งผ่าน HTTPS POST ไปยัง endpoint สาธารณะ | การติดตามแบบ Pull-stream ผ่านการเชื่อมต่อ TLS แบบต่อเนื่อง (`wss://`) | คำขอแบทช์หรือการคิวรีตามกำหนดเวลาของ HTTP JSON-RPC ที่เริ่มต้นโดยไคลเอนต์ | | **ความพร้อมใช้งานของเชน** | ทุกเครือข่ายที่รองรับตามที่ประกาศใน [GET /v1/push/chains](https://api.blockvectra.com/v1/push/chains) | รองรับบน Robinhood Chain (robinhood\_mainnet และ robinhood\_testnet); เครือข่ายที่ไม่ให้บริการมี `ws: false` และส่งกลับ HTTP 404 | ทุกเครือข่ายที่รองรับใน [GET /v1/chains](https://api.blockvectra.com/v1/chains) ผ่าน public RPC แบบไม่ต้องใช้คีย์ หรือ JSON-RPC ที่มีการยืนยันตัวตน | | **ข้อกำหนดของตัวรับ** | HTTPS URL ที่เข้าถึงได้แบบสาธารณะ, ใบรับรอง TLS ที่ถูกต้อง, การตอบกลับ 2xx ภายในระยะเวลาหมดเวลา, การตรวจสอบลายเซ็น HMAC SHA-256 บน raw-body | การเชื่อมต่อไคลเอนต์ TCP/TLS ขาออก (`wss://`); จัดการ ping/pong heartbeat และการหน่วงเวลาเชื่อมต่อใหม่ | HTTP client หรือ scheduled worker แบบ stateless; จัดเก็บเคอร์เซอร์บล็อกไว้ในเครื่อง | | **การนำส่งและลำดับ** | การนำส่งแบบอย่างน้อยหนึ่งครั้งพร้อม exponential retry backoff; ตัวรับต้องขจัดข้อมูลซ้ำตาม `id` ของเหตุการณ์ หรือตาม `ref` + `type` ข้ามการติดตาม | เฟรมที่เรียงลำดับอย่างเคร่งครัดบน socket เดียวที่ใช้งานอยู่; การแจ้งเตือนจะตกหล่นระหว่างที่หลุดการเชื่อมต่อ | การตอบกลับแบบ pull ที่กำหนดแน่นอนสำหรับความสูงของบล็อกที่ได้รับการยืนยันแล้ว; ไคลเอนต์เป็นผู้ควบคุมจังหวะการทำงาน | | **การ Reorganize ของเชน** | การแจ้งเตือนควบคุมที่ส่งออกมาสำหรับ `chain.reorg`; ตัวรับจะละทิ้งเหตุการณ์ที่ถูกแทนที่ก่อนนำ replay แบบ canonical ไปใช้ | การแจ้งเตือน log มี `"removed": true` สำหรับ log ที่ถูก reorg; `newHeads` กำหนดให้ต้องตรวจสอบ parent hash | ไคลเอนต์ติดตามความต่อเนื่องของเชน `parentHash` ข้ามรอบการโพลล์เพื่อตรวจจับ reorg | | **การกู้คืนจากความล้มเหลว** | หน้าต่างการเก็บรักษาของเซิร์ฟเวอร์อนุญาตให้ 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](https://api.blockvectra.com/v1/chains) | | **โมเดลการเรียกเก็บเงิน** | ค่าธรรมเนียมแอดเดรสรายวันต่อกลุ่ม อิงตามจำนวนแอดเดรสสูงสุดขณะ online ในระหว่างวัน UTC บวกด้วย CU สำหรับเหตุการณ์ข้อมูลที่นำส่งแล้ว; ดู [การเรียกเก็บเงินของ Webhook](https://docs.blockvectra.com/en/guides/webhook-push/#billing-and-example) | แฮนด์เชกและ heartbeat ไม่คิดค่าบริการ; `eth_subscribe` / `eth_unsubscribe` และหน่วยการแจ้งเตือน socket ที่ flush แล้วคิดค่าบริการเป็น CU | วัดปริมาณต่อคำขอเป็น Compute Units: `eth_blockNumber`, `eth_call`, `eth_getLogs`; น้ำหนักของเมธอดและ CU ต่อ $1 จาก [GET /v1/plans](https://console-api.blockvectra.com/v1/plans) แสดงอยู่ด้านล่าง | | **เหมาะสมที่สุดสำหรับ** | การตรวจสอบการฝากเงินของผู้ใช้, การติดตามแอดเดรส 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 | ## เมื่อใดควรเลือก Address Webhooks เลือก [Blockchain Webhook API](https://docs.blockvectra.com/en/guides/webhook-push/) เมื่อแบ็กเอนด์ของคุณทำงานเป็นบริการเว็บมาตรฐานที่สามารถรับคำขอ 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](https://docs.blockvectra.com/en/guides/webhook-push/#verify-signatures) ก่อนเปิดเผยตัวรับ webhook สำหรับโปรดักชัน ## เมื่อใดควรเลือกการติดตามผ่าน WebSocket เลือก [การติดตามผ่าน WebSocket](https://docs.blockvectra.com/en/guides/websocket-subscriptions/) เมื่อต้องการความหน่วงต่ำ และโปรเซสของคุณสามารถรักษาการเชื่อมต่อ 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`](https://docs.blockvectra.com/en/errors/#unknown_chain)) * **Disconnection discipline**: การแจ้งเตือน WebSocket จะไม่ถูกเก็บรักษาไว้บนเซิร์ฟเวอร์เมื่อหลุดการเชื่อมต่อ เมื่อ socket หลุด ไคลเอนต์ต้องเชื่อมต่อใหม่ด้วย randomized exponential backoff และดึงข้อมูลบล็อกที่พลาดไปย้อนหลังผ่าน `eth_getLogs` ตรวจสอบ [คู่มือการติดตามผ่าน WebSocket](https://docs.blockvectra.com/en/guides/websocket-subscriptions/) สำหรับขีดจำกัดของตัวกรอง, ขีดจำกัดการเชื่อมต่อ (20 การเชื่อมต่อต่อคีย์, 50 การเชื่อมต่อต่อบัญชี) และตัวอย่างการเชื่อมต่อด้วย viem ## เมื่อใดควรเลือกการโพลล์ RPC แบบจำกัดขอบเขต เลือกการโพลล์ 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](https://api.blockvectra.com/v1/chains) การเกินขีดจำกัดนี้จะส่งกลับรหัสข้อผิดพลาด `-32602` ([`logs_range_too_large`](https://docs.blockvectra.com/en/errors/#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 ย้อนหลัง](https://docs.blockvectra.com/en/guides/hyperevm-backfill/) และ [คู่มือช่วงบล็อก eth\_getLogs](https://docs.blockvectra.com/en/guides/getlogs-block-range/) สำหรับอัลกอริทึมการแบ่ง chunk สำหรับรายการตรวจสอบเวิร์กโหลดและแบบทดสอบตนเองฉบับสมบูรณ์ เริ่มต้นที่ [วิธีเลือกผู้ให้บริการ RPC](https://docs.blockvectra.com/en/guides/choose-rpc-provider/) เมื่อเลือกผู้ให้บริการสำหรับการโพลล์ในปริมาณน้อย [เปรียบเทียบผู้ให้บริการสำหรับการเรียกเก็บเงินและความครอบคลุมของ RPC มาตรฐาน](https://docs.blockvectra.com/en/guides/quicknode-alternative/) เปรียบเทียบการเรียกเก็บเงินตามการใช้งานกับค่าใช้จ่ายช่วงทดลองใช้และการสมัครสมาชิก; ค่าใช้จ่ายในการแจ้งเตือนและการดึงข้อมูลย้อนหลังใช้มิเตอร์คนละตัวกับการอ่านผ่าน RPC ## คู่มือการเชื่อมต่อ ### WebSocket บน Robinhood Chain สำหรับ `newHeads` สด หรือ `logs` ที่กรองแล้วบน Robinhood Chain โปรดทำตาม [คู่มือการติดตามผ่าน WebSocket](https://docs.blockvectra.com/en/guides/websocket-subscriptions/) สำหรับการยืนยันตัวตนและคำขอการติดตาม หลังจากการหลุดการเชื่อมต่อ ให้เชื่อมต่อใหม่ด้วย backoff สมัครรับข้อมูลใหม่ และดึงข้อมูลบล็อกที่พลาดไปย้อนหลังจากเคอร์เซอร์ที่บันทึกไว้ด้วย `eth_getLogs`; ขจัด log ที่ซ้ำกันตาม `(blockHash, transactionHash, logIndex)` ### การโพลล์แบบจำกัดขอบเขตบน HyperEVM สำหรับ HyperEVM (`hyperevm_mainnet`) โปรดทำตาม [คู่มือการดึงข้อมูล log ของ HyperEVM ย้อนหลัง](https://docs.blockvectra.com/en/guides/hyperevm-backfill/) สำหรับการโพลล์แบบจำกัดขอบเขตและการกู้คืน คิวรีจากเคอร์เซอร์ที่บันทึกไว้เป็น chunk ภายใน `max_logs_block_range`, บันทึกเหตุการณ์และความคืบหน้าไว้ด้วยกันหลังจากการประมวลผลสำเร็จ และลองใหม่สำหรับช่วงที่ไม่สมบูรณ์ ตรวจสอบความต่อเนื่องของเชนและสแกนช่วงที่ทับซ้อนกันเพื่อจัดการกับ reorg ## ขั้นตอนถัดไป * [เลือกดูสารบบชุดข้อมูล](https://blockvectra.com/en/data/) เพื่อดูทุกชุดข้อมูลที่ BlockVectra ทำดัชนี * [ดูแผนบริการฟรีและราคา](https://blockvectra.com/en/pricing/#free) เพื่อตรวจสอบสิ่งที่บัญชีของคุณได้รับ * [เข้าสู่ระบบคอนโซล](https://console.blockvectra.com/login/?next=%2Fkeys%2F) เพื่อสร้าง API key