---
title: "ความเสี่ยงด้านความพร้อมใช้งานของผู้ส่งต่อข้ามเชน"
description: "ความเสี่ยงด้านความพร้อมใช้งานของผู้ส่งต่อคือความเสี่ยงที่ข้อความข้ามเชนซึ่งยืนยันความแท้แล้วไม่ถูกนำส่งหรือดำเนินการที่ปลายทางทันเวลา โดยต้องแยกความเป็นที่สุดต้นทาง ความพร้อมของหลักฐาน การนำส่ง การดำเนินการปลายทาง และการบันทึกสินทรัพย์ออกจากกัน"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ความเสี่ยงด้านความพร้อมใช้งานของผู้ส่งต่อข้ามเชน

> จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้

<a id="answer"></a>

## คำตอบโดยตรง

ความเสี่ยงด้านความพร้อมใช้งานของผู้ส่งต่อข้ามเชนคือความเสี่ยงที่ข้อความซึ่งถูกต้องและยืนยันความแท้แล้วไม่ถูกยื่นหรือดำเนินการที่ปลายทางทันเวลา โดยทั่วไปผู้ส่งต่อทำหน้าที่ขนส่งข้อความและหลักฐานหรือข้อมูลกำกับ ไม่ได้ทำให้เหตุการณ์ต้นทางเป็นที่สุดหรืออนุญาต payload ฉันทามติต้นทาง การสร้างหลักฐานหรือคำรับรอง การตรวจสอบที่ปลายทาง และการดำเนินการของผู้รับเป็นสิ่งที่ต้องพึ่งพาแยกจากกัน

การนำส่งล่าช้าในขั้นแรกเป็นปัญหาความพร้อมใช้งาน ไม่ใช่หลักฐานว่าสินทรัพย์ถูกขโมย แต่ความล่าช้าอาจสร้างต้นทุนเงินทุน ทำให้พลาดเส้นตาย ตั๋วหมดอายุ สภาพคล่องใช้ไม่ได้ หรือเกิดความสูญเสียถาวรตามกฎของผลิตภัณฑ์ ในทางกลับกัน ใบรับต้นทางและป้าย `Pending` บนหน้าจอไม่ได้พิสูจน์ว่าปัญหาอยู่ที่ผู้ส่งต่อ เพราะต้นทางอาจยังไม่เป็นที่สุด หลักฐานอาจยังไม่มี ปลายทางอาจหยุดชั่วคราว gas อาจไม่พอ หรือผู้รับอาจย้อนกลับ

การนำส่งแบบไม่จำกัดผู้ยื่นขึ้นอยู่กับแต่ละโปรโตคอล Hyperlane และ Wormhole อธิบายเส้นทางที่บุคคลที่สามนำส่งข้อความซึ่งยืนยันความแท้แล้วได้ ขณะที่การติดตั้งอื่นจำกัดผู้ดำเนินการ ผู้เรียกที่ปลายทาง หรือฟังก์ชันกู้คืน การเปิดให้ยื่นไม่ได้ทำให้ผู้ส่งต่อแก้ payload ที่ยืนยันความแท้แล้วได้ และการใส่ผู้ส่งต่อใน allowlist ไม่ใช้แทนการตรวจสอบปลายทางหรือการป้องกันการใช้ซ้ำ

<a id="mechanism"></a>

## กลไกการทำงาน

วงจรชีวิตที่มีประโยชน์แยก `source submitted`, `source finalized`, `proof pending`, `ready`, `destination submitted`, `failed/retryable`, `executed` และ `expired/cancelled` ป้ายเหล่านี้ใช้เพื่อการวิเคราะห์ แต่ละโปรโตคอลมีฟิลด์บนเชนของตนเอง การถอนใน OP Stack ข้อความเผาแล้วสร้างของ CCTP, VAA ของ Wormhole และข้อความ Hyperlane มีกฎหลักฐาน เวลา ค่าธรรมเนียม และการลองใหม่ต่างกัน

ขั้นแรกให้พิสูจน์ว่าการกระทำต้นทางล็อก เผา หรือส่งมูลค่าจริง และบรรลุความเป็นที่สุดที่กำหนด จากนั้นพิสูจน์ว่าราก ลายมือชื่อผู้ตรวจสอบ VAA ของผู้พิทักษ์ หรือคำรับรองที่คาดไว้พร้อมใช้และเป็นปัจจุบัน หลังจากนั้นจึงตรวจว่าผู้ส่งต่อเห็นข้อความ ยอมรับนโยบายค่าธรรมเนียม สร้างข้อมูลกำกับถูกต้อง และยื่นไปยังสัญญาปลายทางที่แน่นอนหรือไม่

การดำเนินการปลายทางมีรูปแบบความล้มเหลวของตนเอง ได้แก่ เชนหรือซีเควนเซอร์หยุดทำงาน RPC ล้าสมัย สัญญาหยุดชั่วคราว รุ่นผู้รับผิด gas ไม่พอ nonce แบบเรียงลำดับติดขัด หมดอายุ หรือแอปพลิเคชันย้อนกลับ แฮชธุรกรรมเป็นเพียงข้อมูลอ้างอิงการยื่น การเสร็จสมบูรณ์ต้องมีใบรับที่สำเร็จ สถานะประมวลผลของโปรโตคอล เหตุการณ์หรือการเปลี่ยนสถานะของผู้รับ อัตลักษณ์โทเคนที่ถูกต้อง และผลต่อยอดคงเหลือตามคาดภายใต้ความเป็นที่สุดปลายทางที่กำหนด

การส่งต่อด้วยตนเองไม่ใช่ปุ่มกู้ภัยที่ใช้ได้เสมอ ทำได้ต่อเมื่อโปรโตคอลที่ติดตั้งเปิดจุดเข้าระบบที่เข้าเกณฑ์ มีข้อความและหลักฐานต้นฉบับที่แน่นอน ผู้เรียกได้รับอนุญาต ข้อความยังไม่ถูกใช้และไม่หมดอายุ และผู้เรียกจ่าย gas กับมูลค่าที่ปลายทางได้ ให้จำลองการเรียกปลายทางอย่างเป็นทางการ ห้ามสร้างการล็อกหรือเผาที่ต้นทางใหม่เพียงเพื่อแก้ข้อความแรกที่ยังไม่ทราบสาเหตุ

การลองใหม่ต่างจากการใช้ซ้ำ การลองใหม่ตามเอกสารจะยื่นข้อความมาตรฐานเดิมอีกครั้งหลังผลที่ปลายทางล้มเหลว สถานะใช้แล้วหรือ nonce ที่ถูกต้องอนุญาตผลสำเร็จได้ไม่เกินหนึ่งครั้ง ผู้ส่งต่อหลายรายอาจแข่งกันและสิ้นเปลือง gas แม้การป้องกันการใช้ซ้ำยังรักษาความปลอดภัย การยกเลิกงานในเครื่องไม่สามารถเรียกคืนธุรกรรมปลายทางที่เผยแพร่หรือรวมในบล็อกแล้ว

ใช้ขั้นตอนดังต่อไปนี้:

1. ตรึงโปรโตคอล lane และรุ่นที่ติดตั้ง โดเมนและสัญญาต้นทางกับปลายทาง ธุรกรรมและล็อกต้นทาง ID ข้อความหรือ nonce การกระทำต่อสินทรัพย์ จำนวนดิบ ผู้รับ และวันหมดอายุ
2. ตรวจใบรับและเหตุการณ์ต้นทาง แล้วใช้กฎการยืนยันหรือความเป็นที่สุดของเชนและโปรโตคอลนั้น ตรวจอัตลักษณ์บล็อกและสถานะการจัดระเบียบใหม่แทนการเชื่อหน้าจอ
3. ค้นหาหลักฐาน VAA คำรับรอง จุดตรวจ หรือรากตามที่โปรโตคอลกำหนด ตรวจสถานะต้นทาง รุ่น ชุดผู้ลงนาม ความพร้อมใช้ และสถานะยกเลิกหรือหมดอายุ
4. ตรวจสุขภาพเชนปลายทาง รุ่นผู้ส่งข้อความและผู้รับ สถานะหยุดชั่วคราว nonce หรือสถานะประมวลผล ข้อกำหนดข้อความก่อนหน้า เส้นตาย และ gas ประจำเครือข่ายที่ต้องใช้
5. ระบุว่าการนำส่งเปิดให้ทุกคน อยู่ใน allowlist หรือจำกัดผู้เรียก สำหรับเส้นทางด้วยตนเองที่เข้าเกณฑ์ ให้สร้างและจำลอง payload หลักฐาน และการเรียกปลายทางอย่างเป็นทางการเดิมทุกประการ
6. ปรับ limit และราคา gas ส่วนเพิ่มอัตราแลกเปลี่ยน เพดานค่าธรรมเนียม refund และค่าประมาณวันหมดอายุให้ใหม่ ยื่นหรือลองข้อความเดิมอีกครั้ง จัดการการแข่งกันของรายการซ้ำและรายการแทน แล้วเก็บใบรับปลายทาง
7. กระทบยอด escrow หรือการเผาต้นทาง หนี้สินระหว่างทาง การสร้าง ปลดล็อก หรือเรียกที่ปลายทาง ค่าธรรมเนียมโปรโตคอลและ gas refund และสถานะสุดท้าย ยกระดับผ่านช่องทางตามเอกสารโดยไม่เปิดเผย seed phrase หรือกุญแจส่วนตัว

<a id="example"></a>

## ตัวอย่าง

- **แจกแจงความล่าช้าตามขั้น** ความเป็นที่สุดต้นทางใช้ `12 minutes` การสร้างหลักฐานหรือคำรับรอง `8 minutes` คิวผู้ส่งต่อ `35 minutes` และการรวมที่ปลายทาง `5 minutes` เวลาตั้งแต่ต้นจนจบคือ `12 + 8 + 35 + 5 = 60 minutes` มีเพียงคิว `35-minute` ที่เป็นความพร้อมใช้งานของการนำส่ง ส่วน `20 minutes` แรกและ `5 minutes` สุดท้ายอยู่ในความรับผิดชอบของส่วนอื่น
- **ค่าประมาณ gas ปลายทางไม่เพียงพอ** limit gas คือ `300,000` ที่ `25 gwei` ค่าประมาณคือ `300,000 * 25 * 10^-9 = 0.0075 ETH` เมื่อดำเนินการ `60 gwei` ต้องใช้ `0.018 ETH` จึงขาด `0.018 - 0.0075 = 0.0105 ETH` การจ่าย gas ต้นทางเพิ่มไม่จำเป็นต้องเติมเงินให้การดำเนินการปลายทาง
- **ผู้ส่งต่อซ้ำเสีย gas ไม่ใช่เงินต้น** ผู้ส่งต่อสามรายยื่นข้อความ `100,000 USDC` เดียวกัน ผู้ชนะใช้ `180,000 gas * 30 gwei = 0.0054 ETH` ธุรกรรมที่แพ้สองรายการย้อนกลับหลังใช้รายการละ `70,000 gas * 30 gwei = 0.0021 ETH` gas ส่งต่อรวมคือ `0.0054 + 0.0021 + 0.0021 = 0.0096 ETH` ขณะที่สถานะป้องกันการใช้ซ้ำที่ถูกต้องยอมให้เกิดผล `100,000 USDC` หนึ่งครั้ง ไม่ใช่ `300,000 USDC`
- **ติดตามหนี้สินระหว่างทาง** เส้นทางล็อกแล้วสร้างล็อก `25 ETH` แต่การเรียกปลายทางล้มเหลว: escrow คือ `+25 ETH` ปริมาณสินทรัพย์ที่ห่อคือ `+0 ETH` และหนี้สินระหว่างทางคือ `25 ETH` การลองข้อความเดิมใหม่สำเร็จทำให้ escrow คงที่ `25 ETH` เพิ่มปริมาณสินทรัพย์ที่ห่อเป็น `25 ETH` และลดหนี้สินระหว่างทางเป็น `0 ETH` การฝากต้นทางใหม่ `25 ETH` จะทำให้ escrow เป็น `50 ETH` และเกิดภาระผูกพันสองรายการแทน

<a id="risks"></a>

## ความเสี่ยง

- ธุรกรรมต้นทางยังรอดำเนินการหรือย้อนกลับ แต่หน้าจอรายงานว่าส่งแล้ว
- มีการดำเนินการตามเหตุการณ์ต้นทางก่อนมีความเป็นที่สุดเพียงพอ
- การจัดระเบียบต้นทางใหม่ลบหรือเปลี่ยนเหตุการณ์
- ไม่มีข้อมูลหลักฐาน คำรับรอง จุดตรวจ หรือลายมือชื่อ
- มีการใช้รากหรือชุดผู้ลงนามที่ล้าสมัย ผิด หรือถูกยกเลิก
- กุญแจหรือบริการผู้ส่งต่อใน allowlist ไม่พร้อมใช้
- เข้าใจผิดว่าการนำส่งแบบไม่จำกัดผู้ยื่นรับประกันความรวดเร็ว
- เข้าใจผิดว่าจุดเข้าระบบจำกัดผู้เรียกเป็นเส้นทางด้วยตนเองสาธารณะ
- เชนปลายทาง ซีเควนเซอร์ RPC หรือตัวทำดัชนีไม่พร้อมใช้หรือล้าสมัย
- ผู้ส่งข้อความหรือผู้รับปลายทางหยุดชั่วคราว
- การอัปเกรดผู้รับหรือที่อยู่ไม่ตรงทำให้การเรียกย้อนกลับ
- limit gas ปลายทางต่ำเกินไป
- สมมติฐานค่าประมาณ gas อัตราแลกเปลี่ยน เพดานค่าธรรมเนียม หรือ refund ล้าสมัย
- กระเป๋าเงินดิจิทัลไม่มีสินทรัพย์ gas ประจำเครือข่ายปลายทางที่ถูกต้อง
- ข้อความ ตั๋ว หลักฐาน หรือเส้นตายดำเนินการหมดอายุ
- ช่องว่าง nonce แบบเรียงลำดับกีดขวางข้อความถัดไป
- ตรรกะลองใหม่หรือสถานะใช้แล้วเปิดให้เกิดซ้ำหรือขัดขวางการกู้คืน
- การแข่งกันยื่นซ้ำ ยกเลิก หรือแทนที่ทำให้สิ้นเปลือง gas
- ช่องทางสนับสนุนปลอมส่งสัญญา หลักฐาน หรือ calldata ที่เป็นอันตราย
- มีการกระทบยอดการล็อกหรือเผาต้นทาง สิทธิเรียกร้องระหว่างทาง ผลปลายทาง ค่าธรรมเนียม และ refund ผิด

<a id="misconceptions"></a>

## ความเข้าใจผิดที่พบบ่อย

- **ผู้ส่งต่อยืนยันความแท้ของข้อความ** การนำส่งพาหลักฐานมา ตัวตรวจสอบปลายทางและแอปพลิเคชันต่างหากที่บังคับกฎต้นทาง ผู้ส่ง payload และการใช้ซ้ำ
- **ผู้ส่งต่อหยุดทำงานหมายความว่าสินทรัพย์สูญหายแล้วหรือถูกคืนอัตโนมัติ** ผลแรกคือความล่าช้า ส่วนผลจากการหมดอายุ การกู้คืน ความสามารถชำระหนี้ และ refund ขึ้นอยู่กับผลิตภัณฑ์
- **การส่งต่อแบบไม่จำกัดผู้ยื่นหมายความว่าใครก็แก้ payload ได้หรือรับประกันการดำเนินการทันที** การยืนยันความแท้ป้องกันการแก้ไข ขณะที่หลักฐาน gas เชน และความพร้อมของผู้รับยังควบคุมความพร้อมใช้งาน
- **การลองใหม่ทุกครั้งทำให้สร้างสินทรัพย์ซ้ำ** การลองใหม่ที่ถูกต้องใช้ข้อความเดียวและอนุญาตผลสำเร็จหนึ่งครั้ง ส่วนการโอนต้นทางใหม่สร้างภาระผูกพันใหม่
- **แฮชธุรกรรมปลายทางหรือป้ายเสร็จบนหน้าจอพิสูจน์การรับ** ต้องยืนยันใบรับสำเร็จ สถานะประมวลผล เหตุการณ์ผู้รับ ยอดคงเหลือ อัตลักษณ์โทเคน และความเป็นที่สุดที่กำหนด

<a id="related"></a>

## หัวข้อที่เกี่ยวข้อง

- [บริดจ์ข้ามเชน](/th/crypto/cross-chain-bridge/)
- [การป้องกันการใช้ข้อความข้ามเชนซ้ำ](/th/crypto/bridge-message-replay-protection/)
- [บริดจ์หลัก](/th/crypto/canonical-bridge/)

<a id="sources"></a>

## แหล่งข้อมูล

- [Relayer](https://docs.hyperlane.xyz/docs/protocol/agents/relayer) - Hyperlane Documentation (เข้าถึงเมื่อ: 2026-08-13)
- [Mailbox](https://docs.hyperlane.xyz/docs/protocol/core/mailbox) - Hyperlane Documentation (เข้าถึงเมื่อ: 2026-08-13)
- [VAAs](https://docs.wormhole.com/protocol/infrastructure/vaas/) - Wormhole Docs (เข้าถึงเมื่อ: 2026-08-13)
- [Executor Framework](https://docs.wormhole.com/protocol/infrastructure/relayers/executor-framework/) - Wormhole Docs (เข้าถึงเมื่อ: 2026-08-13)
- [Withdrawals](https://specs.optimism.io/protocol/withdrawals.html) - OP Stack Specification (เข้าถึงเมื่อ: 2026-08-13)
- [Cross Domain Messengers](https://specs.optimism.io/protocol/messengers.html) - OP Stack Specification (เข้าถึงเมื่อ: 2026-08-13)
- [CCTP Technical Guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Developers (เข้าถึงเมื่อ: 2026-08-13)
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - ethereum.org (เข้าถึงเมื่อ: 2026-08-13)

Source: https://wiki.fcontext.com/th/crypto/bridge-relayer-liveness-risk/index.mdx