---
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>

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

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

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

ไม่มี `messageId` ข้ามเชนที่ใช้ร่วมกันได้ทุกระบบ ข้อกำหนดของแต่ละโปรโตคอลเป็นผู้กำหนดการจัดเรียงข้อมูลและอัตลักษณ์ที่แน่นอน ซองข้อความที่รัดกุมมักผูกโปรโตคอลและรุ่น โดเมนต้นทางและผู้ส่งข้อความหรือผู้ปล่อยเหตุการณ์ ผู้ส่งต้นทาง nonce หรืออัตลักษณ์ธุรกรรมหรือล็อกต้นทาง โดเมนปลายทางและผู้รับ มูลค่า payload และวันหมดอายุ Wormhole, CCTP, Optimism และ ERC-5164 ใช้ฟิลด์และกลไกสถานะต่างกัน จึงนำตัวระบุมาใช้แทนกันไม่ได้

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

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

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

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

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

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

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

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

1. ตรึงโปรโตคอล รุ่นที่ติดตั้ง โดเมนต้นทางและปลายทาง ผู้ส่งข้อความหรือผู้ปล่อยเหตุการณ์ที่เชื่อถือได้ ผู้ส่ง ผู้รับ มูลค่า payload nonce หรืออัตลักษณ์เหตุการณ์ และความหมายของวันหมดอายุ
2. สร้างการเข้ารหัสตามมาตรฐานและเวกเตอร์ทดสอบ `messageId` ตามข้อกำหนดขึ้นใหม่ ปฏิเสธการต่อข้อมูลที่กำกวม ฟิลด์ที่ถูกละ และสมมติฐานที่ยืมจากบริดจ์อื่น
3. ตรวจการรวมข้อมูลต้นทางและนโยบายความเป็นที่สุดหรือการยืนยันที่กำหนด จากนั้นตรวจรากหลักฐาน องค์ประชุมลายมือชื่อ ชุดผู้ตรวจสอบหรือผู้พิทักษ์ และรุ่นให้ถูกต้อง
4. ตรวจปลายทาง ผู้รับ ผู้ส่งข้ามโดเมน มูลค่า payload และวันหมดอายุแยกจากกัน ให้ถือผู้ส่งต่อที่ยื่นข้อมูลเป็นผู้ขนส่ง ไม่ใช่ผู้มีอำนาจ
5. อ่านสถานะข้อความถาวรและเข้าสู่สถานะกำลังประมวลผลหรือใช้แล้วก่อนเรียกภายนอกที่ไม่น่าเชื่อถือ พร้อมการป้องกันการเรียกกลับซ้ำและการทดสอบพฤติกรรมเมื่อธุรกรรมย้อนกลับอย่างชัดเจน
6. กำหนดการเปลี่ยนสถานะสำเร็จ ล้มเหลว และลองใหม่ได้ พฤติกรรม nonce แบบเรียงลำดับหรือบิตแมป ความเป็นอะตอมของกลุ่ม และการบันทึกมูลค่า พิสูจน์ว่าการนำส่งซ้ำไม่ทำให้ leaf ที่สำเร็จเกิดซ้ำ
7. ทดสอบการอัปเกรด การย้ายพื้นที่จัดเก็บ การปิดจุดเข้าระบบเดิม การหมุนเวียนเพียร์ การแยกเชน และการกู้คืนฉุกเฉิน จากนั้นกระทบยอดใบรับ เหตุการณ์ สถานะที่ประมวลผลแล้ว และยอดคงเหลือปลายทาง

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

## ตัวอย่าง

- **การผูกโดเมนปลายทาง** คำสั่งสองรายการมี nonce `42` และมูลค่า `1,000` เท่ากัน แต่รายการหนึ่งมุ่งไปเชน `10` และอีกรายการมุ่งไปเชน `8453` ตัวระบุที่ไม่รวมปลายทางจะถือ `2 messages` เป็นตัวเลือกการชนกันหนึ่งรายการ ส่วนการเข้ารหัสมาตรฐานที่ผูกปลายทางจะสร้าง `2 distinct IDs` ฟังก์ชันแฮชและรูปแบบโดเมนจริงต้องมาจากโปรโตคอล
- **บิตแมปแบบไม่เรียงลำดับ** สำหรับ nonce `513` จะได้ `word = floor(513 / 256) = 2`, `bit = 513 mod 256 = 1` และ `mask = 1 << 1 = 2` ความสำเร็จครั้งแรกเปลี่ยน word ของบิตแมป `2` จาก `0` เป็น `2` รายการซ้ำพบ `2 & 2 = 2` จึงถูกปฏิเสธ ขณะที่ nonce `512` ใช้ bit `0` แยกกัน
- **การลองใหม่ไม่ใช่ผลครั้งที่สอง** ข้อความที่ยืนยันความแท้เดียวกันถูกนำส่ง `3` ครั้ง การเรียกปลายทางที่ใช้ gas `110,000` และ `125,000` ล้มเหลวและย้อนกลับ ส่วนครั้งที่สามใช้ gas `140,000` และสำเร็จหนึ่งครั้ง gas รวมคือ `110,000 + 125,000 + 140,000 = 375,000` ที่ `20 gwei` เท่ากับ `0.0075 ETH` การนำส่งเท่ากับ `3` แต่ผลทางธุรกิจที่สำเร็จเท่ากับ `1`
- **การบันทึกกลุ่มบางส่วน** leaf ที่ดำเนินการแยกกันได้ 4 รายการมี `25 + 40 + 15 + 20 = 100` หน่วย leaf `0`, `1` และ `3` สำเร็จเป็น `25 + 40 + 20 = 85` ส่วน leaf `2` ล้มเหลวและเหลือ `15` รอดำเนินการ การใช้เฉพาะรากของกลุ่มจะทำให้ `15` ติดค้าง ส่วนการลองทั้งกลุ่มใหม่โดยไม่มีสถานะราย leaf อาจทำให้ `85` เกิดซ้ำ ให้ใช้การย้อนกลับแบบอะตอมหรือสถานะที่ประมวลผลแล้วราย leaf ตามข้อกำหนด

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

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

- ตัวระบุไม่รวมเชนหรือโดเมนปลายทาง
- ตัวระบุไม่รวมผู้ส่งข้อความหรือผู้ปล่อยเหตุการณ์ต้นทาง
- โดเมนไม่มีรุ่นโปรโตคอลหรือรุ่นข้อความ
- ขอบเขต nonce ชนกันระหว่างผู้ส่งหรือการติดตั้ง
- การเข้ารหัสแบบอัดแน่นที่กำกวมทำให้ชุดฟิลด์ต่างกันชนกัน
- การแยกเชนหรือ chain ID ที่ใช้ซ้ำทำให้โดเมนเก่ากลับมาใช้ได้
- เหตุการณ์ต้นทางถูกรับก่อนมีความเป็นที่สุดเพียงพอแล้วถูกจัดออกจากเชนหลัก
- มีการยอมรับรากหลักฐาน ชุดผู้ตรวจสอบ หรือชุดผู้พิทักษ์ที่ผิด
- โดเมนลายมือชื่อเก่ายังใช้ได้หลังอัปเกรด
- พื้นที่จัดเก็บพร็อกซีเสียหายจนรีเซ็ตหรือทำให้สถานะข้อความทับซ้อนกัน
- การย้ายข้อมูลละเว้นข้อความที่ใช้แล้วหรือยังเปิดจุดเข้าระบบเดิม
- มีการทำเครื่องหมายสถานะหลังเรียกภายนอกเท่านั้น จึงเปิดให้เรียกกลับซ้ำ
- การเรียกที่ล้มเหลวถูกทำเครื่องหมายว่าสำเร็จและลองใหม่ไม่ได้
- การเรียกที่สำเร็จไม่ถูกบันทึกและสร้างผลทางเศรษฐกิจซ้ำ
- nonce แบบเรียงลำดับที่หายไปกีดขวางข้อความถัดไปทั้งหมด
- การคำนวณ word, bit หรือการยกเลิกในบิตแมปผิด
- สถานะรากของกลุ่มขัดกับการประมวลผลบางส่วนราย leaf
- การลองใหม่ทำให้ leaf ที่สำเร็จแล้วเกิดซ้ำ
- มีการอ่านหน่วยของเส้นตาย วันหมดอายุ หรือนาฬิกาปลายทางผิด
- มีการเข้าใจผิดว่า allowlist ผู้ส่งต่อคือการอนุญาตข้อความ

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

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

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

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

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

- [บริดจ์ข้ามเชน](/th/crypto/cross-chain-bridge/)
- [บริดจ์หลัก](/th/crypto/canonical-bridge/)
- [ความล้มเหลวของผู้ส่งต่อข้ามเชน](/th/crypto/bridge-relayer-liveness-risk/)

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

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

- [ERC-5164: Cross-Chain Execution](https://eips.ethereum.org/EIPS/eip-5164) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-13)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-13)
- [CCTP Technical Guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Developers (เข้าถึงเมื่อ: 2026-08-13)
- [Interop message passing overview](https://docs.optimism.io/app-developers/guides/interoperability/message-passing) - Optimism Documentation (เข้าถึงเมื่อ: 2026-08-13)
- [VAAs](https://docs.wormhole.com/protocol/infrastructure/vaas/) - Wormhole Docs (เข้าถึงเมื่อ: 2026-08-13)
- [Security Considerations](https://docs.soliditylang.org/en/latest/security-considerations.html) - Solidity Documentation (เข้าถึงเมื่อ: 2026-08-13)
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - ethereum.org (เข้าถึงเมื่อ: 2026-08-13)
- [Upgrading smart contracts](https://docs.openzeppelin.com/contracts/5.x/learn/upgrading-smart-contracts) - OpenZeppelin Docs (เข้าถึงเมื่อ: 2026-08-13)

Source: https://wiki.fcontext.com/th/crypto/bridge-message-replay-protection/index.mdx