---
title: "การโจมตีระยะไกลในระบบ PoS: คีย์ในอดีต ความเสี่ยงระหว่างเริ่มต้นระบบ และจุดตรวจสอบ"
description: "การโจมตีระยะไกลในระบบ PoS นำเสนอประวัติทางเลือกที่ลงนามด้วยอำนาจของผู้ตรวจสอบในอดีต เรียนรู้ว่าโหนดประเภทใดมีความเสี่ยง ผู้โจมตีต้องสร้างสิ่งใดขึ้นใหม่ และจุดตรวจสอบภาวะอัตวิสัยแบบอ่อนกับกฎการซิงค์เฉพาะโปรโตคอลช่วยจำกัดความเสี่ยงอย่างไร"
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.

# การโจมตีระยะไกลในระบบ PoS: คีย์ในอดีต ความเสี่ยงระหว่างเริ่มต้นระบบ และจุดตรวจสอบ

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

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

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

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

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

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

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

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

## เส้นทางการโจมตีและการตรวจสอบ

1. **เลือกจุดแยกเชนเก่า** ผู้โจมตีระบุสถานะในอดีตที่อำนาจของผู้ตรวจสอบเปลี่ยนผ่านไปแล้ว หรือยากที่โหนดใหม่จะยืนยันแหล่งที่มาได้อย่างเป็นอิสระ
2. **รวบรวมอำนาจลงนามในอดีตให้เพียงพอ** หลังผู้ตรวจสอบออกจากระบบ คีย์อาจถูกซื้อ ขโมย เก็บไว้ กู้คืนจากข้อมูลสำรอง หรือรั่วไหลผ่านระบบลงนามที่ถูกเจาะ น้ำหนักและประเภทข้อความที่ต้องใช้ขึ้นอยู่กับโปรโตคอล การมีคีย์เก่าของผู้เสนอบล็อกเพียงคีย์เดียวจึงไม่ได้เพียงพอโดยอัตโนมัติ
3. **สร้างประวัติทางเลือกที่ถูกต้องตามโปรโตคอล** ผู้โจมตีสร้างบล็อก คะแนนเสียง ใบรับรอง และการเปลี่ยนชุดผู้ตรวจสอบที่ผ่านการตรวจสอบประวัติของไคลเอนต์ฝ่ายเหยื่อ อย่างไรก็ตาม การเปลี่ยนสถานะที่ไม่ถูกต้อง โดเมนผิด เวลาที่เป็นไปไม่ได้ หรือหลักฐานที่ขาดหาย ยังทำให้เชนแยกเป็นโมฆะได้
4. **ต่อและนำเสนอเชนแยก** การสร้างลายเซ็นด้วยต้นทุนต่ำอาจช่วยให้ผู้โจมตีเติมประวัติได้ยาว แต่จำนวนบล็อกเพียงอย่างเดียวไม่ใช่ตัวตัดสิน เชนสาขานั้นต้องชนะหรือหลบผ่านกระบวนการคัดเลือกที่โหมดการซิงค์ดังกล่าวใช้จริง
5. **ควบคุมมุมมองตอนเริ่มต้นระบบ** เหยื่อถูกแยกออกจากจุดตรวจสอบล่าสุดที่ยืนยันแหล่งที่มาแล้วหรือหลักฐานจาก peer สุจริต และเห็นประวัติทางเลือกเป็นตัวเลือกเดียวหรือตัวเลือกที่ดูดีกว่า
6. **ทำให้ระบบปลายทางนำข้อมูลไปใช้** หากโหนดยอมรับสถานะผิด RPC กระเป๋าสินทรัพย์ดิจิทัล ตัวจัดทำดัชนี ตัวเฝ้าติดตามบริดจ์ หรือแอปพลิเคชัน อาจรายงานยอดคงเหลือ เหตุการณ์ และสมาชิกผู้ตรวจสอบที่ถูกต้องตามโปรโตคอลบนเชนแยกของผู้โจมตี แม้เครือข่ายที่ทำงานอยู่จะติดตามอีกเชนหนึ่ง

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

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

## ตัวอย่างแบบละเอียด

สมมติว่าชุดผู้ตรวจสอบ `V_old` ควบคุมเชน PoS สมมติ ณ epoch `120,000` หลายปีต่อมา น้ำหนักในอดีตมากกว่า `2/3` ออกจากระบบแล้วและไม่อยู่ภายใต้บทลงโทษของโปรโตคอลอีก ผู้โจมตีได้คีย์เก่าเหล่านั้นและเริ่มประวัติที่ขัดแย้งทันทีหลังจุดตรวจสอบ `C_old`

บนเชนสาขาที่สร้างขึ้น ผู้โจมตีลงนามคะแนนเสียงตามที่โปรโตคอลสมมตินี้กำหนด เปลี่ยนสมาชิกผู้ตรวจสอบในเวลาต่อมา และดำเนินประวัติจนถึง epoch `420,000` เครือข่ายสุจริตก็มาถึง epoch `420,000` เช่นกัน ดังนั้นหมายเลข epoch ที่เท่ากันหรือไฟล์ที่ยาวกว่าไม่ได้บอกโหนดที่กำลังเริ่มต้นระบบว่าสาขาใดเป็นเชนหลักที่ชุมชนและการใช้งานจริงยอมรับ แม้แต่การพิจารณาว่าเชนสาขาที่สร้างขึ้นนั้นรับได้หรือไม่ก็ขึ้นอยู่กับกฎทุกข้อของโปรโตคอลตลอดประวัติศาสตร์

โหนด `N_live` เคยเห็นจุดตรวจสอบจริง `C_recent` ซึ่งยืนยันขั้นสุดท้ายแล้ว ณ epoch `419,936` เนื่องจากเชนแยกของผู้โจมตีไม่ได้สืบทอดจาก `C_recent` โหนด `N_live` จึงปฏิเสธ ในทางกลับกัน โหนด `N_new` เริ่มจากบล็อกกำเนิด เชื่อมต่อเฉพาะ peer ของผู้โจมตี และไม่มีหลักยึดล่าสุดที่ยืนยันแหล่งที่มาแล้ว หากโปรโตคอลและโหมดการซิงค์ไม่อาจแยกประวัติทั้งสองด้วยหลักฐานภายในเพียงอย่างเดียว โหนดนี้อาจยอมรับเชนสาขาของผู้โจมตี

การส่งคู่ข้อมูลที่ยืนยันแล้ว `C_recent = (root, 419,936)` ให้ `N_new` จะเปลี่ยนขอบเขตการตัดสินใจ ไคลเอนต์ต้องกำหนดให้เส้นทางการซิงค์มีจุดตรวจสอบนี้ตรงกันทุกประการ และหยุดอย่างปลอดภัยหากทำไม่ได้ ค่า epoch และเกณฑ์ `2/3` ในตัวอย่างนี้ใช้แสดงการออกแบบที่อาศัยการยืนยันขั้นสุดท้ายรูปแบบหนึ่ง ไม่ใช่พารามิเตอร์สากลของ PoS หรือค่าปัจจุบันของเครือข่ายใดที่ระบุชื่อ

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

## มาตรการควบคุมและรายการตรวจสอบ

### การออกแบบโปรโตคอล

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

### การเริ่มต้นและการดำเนินงานโหนด

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

### การนำข้อมูลไปใช้ในแอปพลิเคชัน

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

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

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

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

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

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

- [การยืนยันขั้นสุดท้าย](/th/crypto/finality/)
- [กฎการเลือกเชน](/th/crypto/fork-choice-rule/)
- [Proof of Stake](/th/crypto/proof-of-stake/)
- [คิวการออกและถอนสินทรัพย์ของผู้ตรวจสอบ](/th/crypto/validator-exit-withdrawal-queue/)
- [ภาวะอัตวิสัยแบบอ่อน](/th/crypto/weak-subjectivity/)

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

## แหล่งที่มา

- [ภาวะอัตวิสัยแบบอ่อนของ Ethereum](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-21)
- [ข้อกำหนดฉันทามติ Ethereum: คู่มือภาวะอัตวิสัยแบบอ่อน](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/weak-subjectivity.md) - Ethereum Foundation (เข้าถึงเมื่อ: 2026-08-21)
- [การโจมตีและการป้องกันระบบ Proof of Stake ของ Ethereum](https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-21)
- [Casper กลไกยืนยันขั้นสุดท้ายแบบเป็นมิตร](https://arxiv.org/abs/1710.09437) - arXiv (เข้าถึงเมื่อ: 2026-08-21)
- [Ouroboros Genesis: บล็อกเชน Proof of Stake ที่ประกอบร่วมกันได้และรองรับความพร้อมใช้งานแบบพลวัต](https://eprint.iacr.org/2018/378) - IACR Cryptology ePrint Archive (เข้าถึงเมื่อ: 2026-08-21)
- [การออกแบบ Ouroboros Genesis](https://ouroboros-consensus.cardano.intersectmbo.org/docs/references/miscellaneous/genesis_design/) - Intersect (เข้าถึงเมื่อ: 2026-08-21)

Source: https://wiki.fcontext.com/th/crypto/long-range-attack/index.mdx