---
title: "การโจมตี Stake Grinding: การบิดเบือนความสุ่มของ Proof of Stake"
description: "Stake grinding ค้นหาผลลัพธ์ที่เอื้อประโยชน์จากคีย์ บล็อก หรือส่วนร่วมความสุ่มที่อนุญาต เพื่อเพิ่มโอกาสได้รับเลือกในอนาคต บทความนี้อธิบายเส้นทางโจมตี ความได้เปรียบ และการป้องกันเฉพาะโปรโตคอล"
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.

# การโจมตี Stake Grinding: การบิดเบือนความสุ่มของ Proof of Stake

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

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

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

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

Grinding เป็นกลุ่มการโจมตี ในการบดบล็อกหรือ seed ผู้ผลิตเปลี่ยนเนื้อหาหรือบรรพบุรุษที่อนุญาตเมื่อแฮชผลลัพธ์ถูกใช้สร้างความสุ่มในอนาคต การบดคีย์สร้างคีย์จำนวนมากก่อนลงทะเบียนและเก็บเฉพาะตัวตนที่มีสิทธิ์เหมาะสม ส่วนการเปิดเผยแบบเลือกจะระงับหรือเผยแพร่ commitment, reveal, ลายเซ็น หรือบล็อกหลังทราบผลต่อ seed แล้ว

แฮช ฟังก์ชันสุ่มที่ตรวจสอบได้ (VRF) หรือ commit-reveal เพียงอย่างเดียวไม่ทำให้กระบวนการทั้งหมดปราศจากอคติ ความปลอดภัยขึ้นกับผู้เลือกอินพุต เวลาที่ทราบสิทธิ์ จำนวนทางเลือก การยกเลิกให้สิทธิ์เลือกเพิ่มหรือไม่ และช่วงเวลาที่แยก seed จากผู้นำที่มันเลือก ต้องตรวจสอบเวอร์ชันโปรโตคอลที่แน่นอน

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

## เส้นทางการโจมตีและวิเคราะห์

1. **ตรึงกฎการเลือก** บันทึกเครือข่าย เวอร์ชัน epoch หรือรอบ snapshot ของ Stake การสร้าง seed การทดสอบสิทธิ์ fork choice รางวัล และบทลงโทษ
2. **แจกแจงตัวเลือกของฝ่ายตรงข้าม** รวมคีย์ก่อนลงทะเบียน ลำดับธุรกรรมที่ถูกต้อง ฟิลด์เสริม parent ผู้สมัคร การเผยแพร่ reveal และการยกเลิก โดยสนใจเฉพาะสิ่งที่เปลี่ยนสถานะหรือ seed ที่ยอมรับ
3. **วัดงบการค้นหา** ประเมินจำนวนผู้สมัครก่อนกำหนด ความเป็นอิสระ และต้นทุนการคำนวณ รางวัลที่เสีย เงินฝาก ความล่าช้า หรือการกระทำที่ถูก slash ได้
4. **เชื่อม seed กับอำนาจในอนาคต** ระบุระยะล่วงหน้าในการเลือก proposer หรือคณะกรรมการ ผู้โจมตีเห็นผลก่อน commit หรือไม่ และผลที่ดีเปิดโอกาส grinding ใหม่หรือไม่
5. **ประเมินการยอมรับและการสะสม** ผู้สมัครต้องผ่านกฎการเปลี่ยนสถานะ เวลา ลายเซ็น และ fork choice สร้างแบบจำลองที่มีสถานะ ไม่สมมติว่าทุกรอบเป็นอิสระ
6. **ทดสอบการป้องกันแต่ละชนิด** Seed หน่วงเวลา, VRF, กฎลงทะเบียน, บทลงโทษ, threshold beacon และฟังก์ชันหน่วงเวลาที่ตรวจสอบได้รองรับความสามารถและสมมติฐานต่างกัน

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

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

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

สมมติโปรโตคอลอย่างง่ายให้ผู้โจมตีมีโอกาส `10%` เป็น proposer คนถัดไป หากมี seed คงที่หนึ่งค่า โอกาสคือ `0.10` แต่ข้อบกพร่องทำให้ประเมิน seed ที่ถูกต้องและเป็นอิสระ `20` ค่าแทบไม่มีต้นทุน แล้วเลือกเผยแพร่หนึ่งค่า

โอกาสที่อย่างน้อยหนึ่งค่าจะเลือกผู้โจมตีคือ `1 - (1 - 0.10)^20` หรือประมาณ `87.8%` ไม่ได้แปลว่าผู้โจมตีถือ Stake `87.8%` แต่โปรโตคอลเผลอให้จับสลาก `20` ครั้งและเลือกหลังเห็นผล

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

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

## การป้องกันและรายการตรวจสอบ

### การสร้างความสุ่ม

- สร้างความสุ่มจากอินพุตที่ commit ก่อนผู้เข้าร่วมจะรู้หรือควบคุมการมอบหมายได้
- แยกเวลาของส่วนร่วม commitment, reveal และการใช้ เพื่อไม่ให้ผู้นำค้นหา seed ของผู้สืบทอดได้ราคาถูก
- คำนึงถึงผู้เปิดเผยคนสุดท้าย เพราะ commit-reveal ยังถูกบิดเบือนได้หากการระงับเปิดทางให้เลือกผล
- ใช้ threshold หรือ distributed beacon พร้อมสมมติฐานชัดเจนเรื่องความซื่อสัตย์ liveness การกู้คืน และสมาชิก

### สิทธิ์และตัวตน

- ผูกคีย์ VRF และ Stake กับ snapshot ก่อนรู้ seed มิฉะนั้นการสร้างคีย์ออฟไลน์จะเป็น key grinding
- แยกโดเมนตาม chain เวอร์ชัน รอบ บทบาท และวัตถุประสงค์เพื่อป้องกันการใช้หลักฐานข้ามบริบท
- ใช้สิทธิ์แบบส่วนตัวเมื่อเหมาะสม โดยเข้าใจว่าลดการเล็งเป้าล่วงหน้าแต่ไม่แก้ seed ที่มีอคติ
- จำกัดการเปลี่ยนตัวตนราคาถูก และกำหนดการเข้าร่วมของ Stake ที่มอบหมาย pool และ validator set ที่เปลี่ยนไป

### เศรษฐศาสตร์และการดำเนินงาน

- ประเมินบล็อกและรางวัลที่เสีย เงินทุนที่ล็อก equivocation ที่ตรวจพบ และโทษสัมพันธ์ อย่าเรียกทุกตัวเลือกที่ชอบด้วยกฎว่า slashable
- เฝ้าดูส่วนร่วม reveal ที่ล้มเหลว ผู้สมัครผิดปกติ ความถี่ proposer และความหลากหลายซอฟต์แวร์ในช่วงที่มีนัยสำคัญ
- แยกความสุ่มสำคัญจาก builder, relay หรือการเรียงธุรกรรมตามดุลพินิจ เว้นแต่พิสูจน์แล้วว่าไม่เป็นอันตราย
- ทดสอบ fallback กลไกที่ไร้อคติเฉพาะเมื่อทุกฝ่ายตอบอาจแลกด้วยความล้มเหลวด้าน liveness

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

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

- **แฮชสุ่ม จึง grinding ไม่ได้** แฮชที่คาดเดาไม่ได้สำหรับอินพุตคงที่ยังถูกบิดเบือนได้เมื่อเลือกจากหลายอินพุต
- **VRF กำจัด grinding ทั้งหมด** มันพิสูจน์เอาต์พุต แต่คีย์ seed เวลาลงทะเบียน และการเผยแพร่แบบเลือกยังเป็นคนละปัญหา
- **Commit-reveal ไร้อคติโดยอัตโนมัติ** ผู้เข้าร่วมคนสุดท้ายอาจเลือกระหว่าง reveal กับยกเลิกหากไม่ทำให้ตัวเลือกนี้เป็นกลาง
- **ต้องมี Stake ส่วนใหญ่** ส่วนน้อยที่ได้ลองราคาถูกหลายครั้งเพิ่มโอกาสได้ แต่ความล้มเหลวด้านความปลอดภัยต้องมีเงื่อนไขอื่น
- **การเสนอหลายครั้งติดกันพิสูจน์การบิดเบือน** ความสุ่มทำให้เกิดชุดต่อเนื่อง จึงต้องมีแบบจำลองสถิติและหลักฐานเทคนิค
- **Grinding กับ nothing at stake เหมือนกัน** อย่างแรกบิดเบือนความสุ่มหรือสิทธิ์ อย่างหลังเกี่ยวกับแรงจูงใจให้สนับสนุนประวัติที่แข่งขันกัน

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

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

- [Proof of stake](/th/crypto/proof-of-stake/)
- [ผู้ตรวจสอบ](/th/crypto/validator/)
- [แฮชเชิงเข้ารหัส](/th/crypto/cryptographic-hash/)
- [กฎ Fork choice](/th/crypto/fork-choice-rule/)
- [Nothing at stake](/th/crypto/nothing-at-stake/)

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

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

- [คริปโทเคอร์เรนซีที่ไม่มี Proof of Work](https://arxiv.org/abs/1406.5694) - arXiv (เข้าถึง: 2026-08-21)
- [Ouroboros: โปรโตคอลบล็อกเชน Proof of Stake ที่พิสูจน์ความปลอดภัยได้](https://eprint.iacr.org/2016/889) - IACR Cryptology ePrint Archive (เข้าถึง: 2026-08-21)
- [Ouroboros Praos: โปรโตคอล Proof of Stake แบบกึ่งซิงโครนัสที่ปลอดภัยต่อการปรับตัว](https://eprint.iacr.org/2017/573) - IACR Cryptology ePrint Archive (เข้าถึง: 2026-08-21)
- [Algorand: การขยายขนาดข้อตกลงแบบไบแซนไทน์สำหรับคริปโทเคอร์เรนซี](https://doi.org/10.1145/3132747.3132757) - ACM (เข้าถึง: 2026-08-21)
- [ข้อกำหนดฉันทามติ Ethereum: Beacon Chain](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (เข้าถึง: 2026-08-21)

Source: https://wiki.fcontext.com/th/crypto/stake-grinding-attack/index.mdx