---
title: "Nothing at Stake: การลงนามขัดแย้ง Slashing, Finality และความเสี่ยงจากกุญแจเก่า"
description: "Nothing at Stake คือปัญหาแรงจูงใจของ proof of stake ที่ต้นทุนส่วนเพิ่มในการสนับสนุนประวัติหลายสายอาจต่ำ ควรแยกวิเคราะห์ข้อความที่ลงโทษได้ ผลตอบแทนคาดหมาย จุดตัดของ quorum การบังคับใช้หลักฐาน การเลือก fork และสมมติฐาน weak subjectivity"
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.

# Nothing at Stake: การลงนามขัดแย้ง Slashing, Finality และความเสี่ยงจากกุญแจเก่า

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

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

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

Nothing at Stake คือปัญหาแรงจูงใจของ proof of stake หากการสร้างลายเซ็นเพิ่มมีต้นทุนต่ำและโปรโตคอลไม่กำหนดต้นทุนที่บังคับใช้ได้ต่อการสนับสนุนที่ขัดกัน Validator อาจได้ผลตอบแทนมากกว่าจากการช่วยทุกประวัติที่แข่งขันกัน แทนที่จะเลือกเพียงสายเดียว หาก Validator จำนวนมากทำตามแรงจูงใจส่วนตัวนี้ fork อาจยังได้รับการสนับสนุน การลู่เข้าอาจอ่อนลง และผู้โจมตีอาจรวบรวมลายเซ็นที่ต้องใช้ต้นทุนสูงในการสร้างซ้ำภายใต้ proof of work

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

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

Ethereum เป็นตัวอย่างที่มีประโยชน์ ไม่ใช่แม่แบบสากล ข้อกำหนดฉันทามติทำให้ข้อเสนอ 2 รายการที่ต่างกันใน slot เดียวกันลงโทษได้ และทำให้ attestation ที่เป็น Double Vote หรือ Surround Vote ลงโทษได้ การเลือก fork อาจไม่นับอิทธิพลของผู้ลงนามขัดแย้ง ขณะที่ Finality ใช้คะแนนเสียง supermajority และบทลงโทษ ตระกูล proof of stake อื่นอาจใช้การเลือกผู้นำ การเลือกเชน จุดตรวจ สมมติฐานความพร้อมใช้ หรือแบบจำลองความปลอดภัยทางการที่ต่างกัน

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

## วิธีวิเคราะห์ Nothing at Stake

1. **กำหนดบริบทโปรโตคอลให้ชัดเจน** บันทึก `protocol`, `version`, `network`, `epoch`, `slot`, `validator set` และเวลาที่สังเกต ระบุ `fork choice`, `finality gadget`, `reward rule`, `penalty rule` และ `withdrawal delay` ที่ใช้งานอยู่ คำว่า “PoS” เพียงอย่างเดียวไม่ได้กำหนดสิ่งเหล่านี้
2. **นิยามการกระทำที่ลงนาม** ระบุข้อเสนอบล็อก attestation, prevote, precommit, ใบรับรอง หรือข้อความอื่นพร้อม domain แยกข้อความ 2 รายการที่เพียงสนับสนุนลูกหลานต่างกัน ออกจาก `double proposal`, `double vote` หรือ `surround vote` ที่ลงโทษได้อย่างเป็นทางการตามกฎที่อ้าง
3. **จำลองผลตอบแทนเมื่อไม่มีบทลงโทษ** ประเมินความน่าจะเป็นของสาขา รางวัลสาขามาตรฐาน ต้นทุนเพิ่มของการลงนามและเผยแพร่ สินบน โอกาสที่พลาด และรางวัลจากข้อความขัดแย้ง เปรียบเทียบ `EV(honest)` กับ `EV(equivocate)` แทนการสรุปว่าการใช้ไฟฟ้าต่ำพิสูจน์ว่าการเบี่ยงเบนทำกำไร
4. **จำลองความเสียหายที่บังคับใช้ได้** ระบุยอดเงินที่ผูกไว้ โอกาสตรวจพบ อายุหลักฐาน เส้นทางรายงาน ความเสี่ยงด้านการรวมและการเซ็นเซอร์ บทลงโทษเริ่มต้น บทลงโทษแบบสัมพันธ์ การขับออก เวลาถอน และรายได้อนาคตที่สูญเสีย บทลงโทษในเอกสารไม่เท่ากับการบังคับใช้ `slashing evidence` ที่เชื่อถือได้
5. **แยกการเลือก fork จาก Finality** สร้างผลของคะแนนล่าสุด การลงนามขัดแย้ง และจังหวะข้อความต่อ head ใหม่ แล้วคำนวณน้ำหนักที่ต้องใช้เพื่อ justify หรือ finalize จุดตรวจ วิเคราะห์ `safety threshold` และ `liveness threshold` แยกกัน การกักคะแนนอาจหยุด Finality โดยไม่สร้าง Finality ที่ขัดแย้ง
6. **ทดสอบสมมติฐานกุญแจเก่าและการซิงค์** ระบุว่า Stake ที่ออกแล้วหยุดถูกลงโทษเมื่อใด โหนดออนไลน์จะปฏิเสธประวัติ Finality ใด โหนดใหม่หรือออฟไลน์นานได้ `weak-subjectivity checkpoint` อย่างไร และตรวจอายุพร้อมแหล่งที่มาอย่างไร นี่คือปัญหา long-range ไม่ใช่แค่ Double Vote ล่าสุด
7. **ทดสอบการดำเนินงานและการควบคุมภายใต้ความกดดัน** ทดสอบกุญแจซ้ำ โหนด failover ตัวลงนามระยะไกล การย้อนฐานข้อมูล บั๊ก Client โฮสติ้งที่สัมพันธ์กัน Staking Pool การรับฝากแบบมอบหมาย การแบ่งเครือข่าย การโจมตี eclipse และการเซ็นเซอร์หลักฐาน นับเส้นทางควบคุมและซอฟต์แวร์ที่เป็นอิสระ ไม่ใช่เพียงตัวระบุ Validator

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

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

## ตัวอย่างคำนวณ

### 1. กลยุทธ์ไร้บทลงโทษอาจจูงใจให้สนับสนุนทั้ง 2 สาขา

สมมติว่ามีเพียง 1 ใน 2 สาขาที่กลายเป็นมาตรฐาน โดยสาขา A มีความน่าจะเป็น `0.55` และสาขา B มี `0.45` ลายเซ็นบนสาขามาตรฐานได้ `1.00 unit` ส่วนลายเซ็นบนสาขาที่แพ้ได้ศูนย์ เมื่อไม่รวมบทลงโทษและต้นทุนดำเนินงานเพิ่ม การลงนามเฉพาะ A ให้ `EV(A only) = 0.55 * 1.00 = 0.55 units` การลงนามทั้งคู่ให้ `EV(sign both) = (0.55 + 0.45) * 1.00 = 1.00 unit`

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

### 2. Slashing ที่บังคับใช้ได้อาจกลับทิศผลตอบแทน

คงรางวัลรวมของสาขามาตรฐานที่ `1.00 unit` และเพิ่มสินบน `0.02 unit` สำหรับการลงนามขัดแย้ง สมมติว่าหลักฐานที่ถูกต้องถึงกลไกลงโทษด้วยความน่าจะเป็น `0.80` และความเสียหายรวมที่ระบุสาเหตุได้คือ `5.00 units` ผลตอบแทนแบบง่ายคือ `EV(equivocate) = 1.00 + 0.02 - (0.80 * 5.00) = -2.98 units` ต่ำกว่า `0.55 units` จากการลงนามเฉพาะ A

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

### 3. จุดตัดของ quorum ปกป้องความปลอดภัยแต่อาจกระทบ Liveness

พิจารณา `100 stake units` และกฎที่ต้องมีอย่างน้อย `67 units` สำหรับคะแนน Finality quorum ใดๆ 2 ชุดจะทับซ้อนกันอย่างน้อย `67 + 67 - 100 = 34 units` ดังนั้น Finality ที่ขัดแย้ง 2 สายต้องมีอย่างน้อย 34 หน่วยเข้าร่วมใบรับรอง quorum ทั้งคู่ โปรโตคอลที่ติดตามความรับผิดได้จึงทำให้จุดตัดนี้เป็นหลักฐานลงโทษได้

เกณฑ์เดียวกันมีความหมายต่อ Liveness อีกแบบ หาก `34 units` กักคะแนนที่ถูกต้อง จะเหลือเพียง `66 units` ซึ่งต่ำกว่า 67 และ Finality อาจหยุด 34 หน่วยนั้นไม่สามารถทำให้ 2 สาขา Finality ได้เอง ต้องไม่อธิบายความล้มเหลวด้านความปลอดภัย หลักฐานที่ระบุผู้รับผิดได้ และความล้มเหลวในการคืบหน้าว่าเป็นเหตุการณ์เดียวกัน

### 4. กุญแจเก่าสร้างปัญหาการซิงค์อีกประเภท

สมมติว่าโหนดออนไลน์ทำ checkpoint `epoch 39,900` เป็น Finality แล้ว ขณะที่โหนดใหม่ไม่มีสถานะที่เชื่อถือได้ ผู้โจมตีได้กุญแจที่เคยควบคุม Stake เพียงพอใกล้ `epoch 10,000` หลัง Validator เหล่านั้นออกและหลักประกันเรียกเก็บไม่ได้ แล้วสร้างประวัติทางเลือกถึง `epoch 40,000` ลายเซ็นประวัติที่ต้นทุนต่ำมีความสำคัญ แต่ Slashing ของ Validator ล่าสุดอาจไม่ยับยั้งกุญแจเก่าเหล่านี้แล้ว

โหนดออนไลน์ปฏิเสธประวัติที่ขัดกับมุมมอง Finality ของตน โหนดใหม่ต้องมี checkpoint ล่าสุดที่ยืนยันแหล่งที่มาหรือกฎโปรโตคอลเทียบเท่า เพื่อแยกประวัติก่อนตรวจสอบอย่างเป็นกลางต่อไป ด้วยเหตุนี้ weak subjectivity และเวลาถอนจึงอยู่ในการตรวจสอบ แต่ต้องแยกวิเคราะห์จากการลงนามขัดแย้งแบบสดโดย Validator ที่ยังมีหลักประกัน

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

## ความเสี่ยงและข้อผิดพลาดในการตรวจสอบ

### ข้อผิดพลาดด้านโปรโตคอลและหลักฐาน

- เรียกทุกคะแนนบน fork ที่ไม่ใช่มาตรฐานว่าลงโทษได้โดยไม่ตรวจฟิลด์ที่ลงนามและ domain ที่แน่นอน
- ปะปน fork การจัดเชนใหม่ ข้อเสนอที่พลาด คะแนนล่าช้า และการลงนามขัดแย้งที่พิสูจน์ได้เป็นเหตุการณ์เดียวกัน
- ใช้เงื่อนไข Proposer และ Attester ของ Ethereum กับโปรโตคอลที่มีข้อความหรือกฎ Finality ต่างกัน
- ละเว้นตัวตนเชน เวอร์ชัน fork, epoch หรือ slot เมื่อเปรียบเทียบลายเซ็นที่อ้างว่าขัดกัน
- สมมติว่าลายเซ็น 2 รายการพิสูจน์ความผิดได้โดยไม่มีตัวตน Validator, domain สายบรรพบุรุษ และการเข้ารหัสที่ถูกต้อง
- ปะปนอิทธิพลต่อการเลือก fork กับ justification, finalization หรือการชำระระดับแอปพลิเคชัน
- อ่านทฤษฎีบทความปลอดภัยโดยละสมมติฐานด้านการซิงค์ ความซื่อตรง ความพร้อมใช้ และคู่ต่อสู้

### ข้อผิดพลาดด้านแรงจูงใจและการบังคับใช้

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

### ข้อผิดพลาดด้านการดำเนินงาน การกระจุกตัว และการกู้คืน

- ใช้กุญแจลงนามเดียวกันบนโหนด failover โดยไม่มีการป้องกัน Slashing ที่ถาวรและใช้ร่วมกัน
- กู้ตัวลงนามหรือฐานข้อมูล Slashing จากข้อมูลสำรองเก่า แล้วสร้างความขัดแย้งที่เคยลงนามซ้ำ
- นับกุญแจ Validator เป็นผู้ดำเนินงานอิสระทั้งที่ใช้การรับฝาก Client, Cloud หรือการควบคุม Governance ร่วมกัน
- สมมติว่าผู้มอบหมาย Stake ไม่รับความเสียหายจากผู้ดำเนินงาน Pool หรือการพึ่งพา Restaking
- เชื่อถือ Explorer ผู้ให้บริการ หรือ checkpoint ที่แนบมาเพียงแหล่งเดียวเมื่อกู้โหนดที่ออฟไลน์นาน
- อ้างว่าอัตราร่วม Staking สูงพิสูจน์ความปลอดภัยโดยไม่วิเคราะห์การกระจาย เกณฑ์ และการควบคุม Stake

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

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

- **Proof of stake ไม่มีสิ่งใดเสี่ยงจริงๆ** ระบบที่ออกแบบดีอาจทำให้เงินทุนที่ผูกไว้ รางวัล และการเข้าร่วมอนาคตเสี่ยงต่อการสูญเสีย คำถามคือ ต้นทุนเหล่านี้เพียงพอและบังคับใช้ได้ต่อการเบี่ยงเบนที่เกี่ยวข้องหรือไม่
- **ทุกข้อความของ Validator บน 2 fork คือ Double Vote** การลงโทษได้ขึ้นกับฟิลด์ข้อความ domain และกฎความขัดแย้งของโปรโตคอล การอัปเดตการเลือก fork อย่างซื่อตรงต้องมีพื้นที่ให้เกิดขึ้น
- **Slashing รับประกันฉันทามติ** Slashing สร้างความรับผิดและแรงจูงใจ แต่ความปลอดภัยกับ Liveness ยังขึ้นกับเกณฑ์ เครือข่าย การใช้งาน ความปลอดภัยของกุญแจ และสมมติฐานพฤติกรรมซื่อตรง
- **Stake 1 ใน 3 ทำให้ 2 สาขา Finality ได้เอง** ในการออกแบบ Finality แบบ 2 ใน 3 ฝ่ายประมาณ 1 ใน 3 มักหยุดความคืบหน้าได้ แต่ Finality ที่ขัดแย้งต้องมี supermajority ทับซ้อนกันและการเข้าร่วมที่ลงโทษได้ในจุดตัด
- **Nothing at Stake กับการโจมตี long-range เหมือนกัน** ทั้งคู่ใช้ลายเซ็นต้นทุนต่ำ แต่แบบแรกเกี่ยวกับการสนับสนุนสดต่อสาขาที่แข่งขันกัน ส่วนแบบหลังอาจใช้กุญแจประวัติโจมตีโหนดที่ไม่มีสถานะล่าสุดที่เชื่อถือได้

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

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

- [Proof of stake](/th/crypto/proof-of-stake/)
- [Slashing](/th/crypto/slashing/)
- [กฎเลือก fork](/th/crypto/fork-choice-rule/)
- [Finality](/th/crypto/finality/)
- [การโจมตี long-range](/th/crypto/long-range-attack/)

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

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

- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (เข้าถึงเมื่อ: 2026-08-19)
- [Formal Barriers to Longest-Chain Proof-of-Stake Protocols](https://economics.princeton.edu/working-papers/formal-barriers-to-longest-chain-proof-of-stake-protocols/) - Princeton University (เข้าถึงเมื่อ: 2026-08-19)
- [Ethereum Consensus Specifications: Validator](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/validator.md) - Ethereum Foundation (เข้าถึงเมื่อ: 2026-08-19)
- [Ethereum Consensus Specifications: Beacon Chain](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (เข้าถึงเมื่อ: 2026-08-19)
- [Casper the Friendly Finality Gadget](https://eips.ethereum.org/assets/eip-2982/arxiv-1710.09437-Casper-the-Friendly-Finality-Gadget.pdf) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-19)
- [Ethereum Proof-of-Stake Attack and Defense](https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-19)
- [Weak Subjectivity](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-19)
- [Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol](https://eprint.iacr.org/2016/889) - IACR Cryptology ePrint Archive (เข้าถึงเมื่อ: 2026-08-19)

Source: https://wiki.fcontext.com/th/crypto/nothing-at-stake/index.mdx