---
title: "การยืนยันบล็อก"
description: "คู่มือที่เริ่มจากการตรวจสอบความลึกของการยืนยันใน PoW สถานะ safe และ finalized ใน PoS การแทนที่ธุรกรรมใน mempool การจัดระเบียบเชนใหม่ และนโยบายเครดิตเงินฝากของแพลตฟอร์ม"
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>

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

การยืนยันบล็อกคือข้อความที่ขึ้นกับผู้สังเกตและโปรโตคอลว่า ธุรกรรมถูกรวมไว้ในบล็อกบนเชนที่ผู้สังเกตถือว่าเป็น canonical ในขณะนั้น ตามหลักการนับแบบรวมที่ Bitcoin Core ใช้กันทั่วไป บล็อกที่รวมธุรกรรมจะนับเป็นการยืนยันครั้งที่หนึ่ง เมื่อความสูงที่รวมธุรกรรมคือ `h` และความสูงของเชนที่ดีที่สุดคือ `H` ความลึกจะเท่ากับ `H - h + 1` บางบริการแสดงเฉพาะบล็อกที่สืบทอดต่อมาเป็น `H - h` จึงต้องระบุหลักการนับให้ชัดเจน

ความลึกของ Proof-of-Work ช่วยลดความเสี่ยงจากการจัดระเบียบเชนใหม่ภายใต้สมมติฐานที่ระบุไว้ แต่ไม่มีจุดมหัศจรรย์ที่ทำให้เกิด finality อย่างสมบูรณ์ ระบบ Proof-of-Stake อาจแสดงสถานะที่โปรโตคอลกำหนดโดยตรง Ethereum แยก `latest`, `safe` และ `finalized` ออกจากกัน จำนวนบล็อก slot หรือนาทีที่กำหนดตายตัวไม่สามารถใช้แทนป้ายสถานะเหล่านี้ได้ สถานะที่แพลตฟอร์มตรวจพบ เครดิตให้ ซื้อขายได้ และถอนได้ เป็นนโยบายภายในคนละขั้น แม้จะถึงเกณฑ์ของเชนแล้วก็ตาม

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

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

1. ระบุเชนและเครือข่าย สินทรัพย์ ตัวระบุธุรกรรม โหนดหรือ API เวลาที่สังเกต โมเดลฉันทามติ และหลักการนับ ตรวจสอบผู้รับ จำนวนเงิน และ memo หรือ tag ก่อนถือว่าแฮชที่ตรงกันคือการชำระเงินที่ต้องการ
2. แยกสถานะลงนามแล้ว เผยแพร่แล้ว ได้รับการยอมรับจาก mempool ภายในของโหนดหนึ่ง และกระจายไปในเครือข่ายออกจากกัน Mempool เป็นมุมมองตามนโยบาย ไม่ใช่คิวฉันทามติส่วนกลาง ตรวจสอบสถานะค่าธรรมเนียม ธุรกรรมบรรพบุรุษที่ยังไม่ยืนยัน Replace-by-Fee หรือการแทนที่ด้วย nonce เดิม และการใช้จ่ายที่ขัดแย้งกัน
3. ตรวจสอบการรวมธุรกรรมด้วยแฮชและความสูงของบล็อก ดัชนีธุรกรรม และลำดับบรรพบุรุษของเชน canonical ไม่ใช่ดูเพียงความสูงหรือป้ายจาก block explorer สำหรับเชนแบบบัญชี ให้ตรวจสอบสถานะ receipt, log และการเปลี่ยนแปลง state ที่เกิดขึ้นจริงด้วย เพราะการประมวลผลที่รวมในบล็อกยังอาจ revert ได้
4. ใช้โมเดลฉันทามติให้ถูกต้อง สำหรับ PoW ให้ระบุหลักการนับ คำนวณความลึก และเปรียบเทียบมุมมองอิสระต่อเชนที่ดีที่สุดกับงานสะสม สำหรับ PoS ให้สอบถามสถานะ head, safe, justified หรือ finalized ที่โปรโตคอลกำหนด อย่าอนุมานจากระยะห่างของบล็อกหรือ slot ที่กำหนดตายตัว
5. ติดตามวงจรชีวิตเป็นสถานะที่ชัดเจน ได้แก่ สร้างแล้ว เผยแพร่แล้ว mempool ภายในยอมรับแล้ว รวมในบล็อกแล้ว มีความลึกแบบ canonical หรือสถานะ safe/finalized ถูกจัดระเบียบใหม่ รวมใหม่ ถูกแทนที่ หรือขัดแย้งกัน การจัดระเบียบเชนใหม่ไม่ได้รับประกันว่าธุรกรรมเดิมจะกลับเข้า mempool ทุกแห่ง
6. แยกบัญชีของแพลตฟอร์มออกเป็น ตรวจพบแล้ว ถึงเกณฑ์เครือข่ายแล้ว เครดิตแล้ว ซื้อขายได้ และถอนได้ ใช้นโยบายปัจจุบันของแพลตฟอร์มที่เจาะจงตามสินทรัพย์ เครือข่าย จำนวนเงิน และภาวะเหตุขัดข้อง การบำรุงรักษา การกำกับดูแล และการตรวจสอบโดยเจ้าหน้าที่อาจเพิ่มความล่าช้าอีกชั้นหนึ่ง
7. เปรียบเทียบโหนดหรือผู้ให้บริการอิสระ และติดตามต่อไปจนถึงสถานะที่กำหนด บันทึกแฮช ความสูง เวลา ป้าย RPC และ snapshot ของนโยบาย พร้อมซักซ้อมกรณีแทนที่ การจัดระเบียบใหม่ finality ล่าช้า โหนดล้าสมัย bridge relay และแพลตฟอร์มหยุดให้บริการ

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

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

- **หลักการนับ** ธุรกรรม Bitcoin อยู่ในบล็อก canonical `h = 900,000` และปลายเชนที่ดีที่สุดอยู่ที่ `H = 900,005` ความลึกแบบรวมคือ `900,005 - 900,000 + 1 = 6 confirmations` ส่วนหน้าจอที่นับเฉพาะบล็อกที่สืบทอดต่อมาจะแสดง `900,005 - 900,000 = 5` ความแตกต่างนี้เป็นเรื่องคำศัพท์ หากทั้งสองค่าหมายถึงแฮชบล็อกและลำดับบรรพบุรุษเดียวกัน
- **การจัดระเบียบใหม่และการรวมใหม่** ธุรกรรมมี `1 confirmation` ในบล็อก `900,000` จากนั้นบล็อกนั้นออกจากเชนที่ดีที่สุด และธุรกรรมกลับเป็น `0` หากยังใช้ได้และไม่มีธุรกรรมขัดแย้ง หากรวมใหม่ที่ `900,003` และปลายเชนถึง `900,006` ความลึกแบบรวมคือ `900,006 - 900,003 + 1 = 4 confirmations` แต่ถ้าธุรกรรมขัดแย้งที่ได้รับการยืนยันเข้ามาแทน Bitcoin Core อาจรายงานจำนวนการยืนยันติดลบ
- **ป้าย PoS ไม่ใช่จำนวนบล็อก** สมมติว่าธุรกรรม Ethereum อยู่ใน execution block `20,000,000` ขณะที่โหนดหนึ่งรายงาน `latest = 20,000,020`, `safe = 20,000,012` และ `finalized = 19,999,980` โดยทั้งหมดอยู่ในลำดับบรรพบุรุษเดียวกัน ความลึกเชิงตัวเลขจาก latest คือ `20,000,020 - 20,000,000 + 1 = 21` ธุรกรรมอยู่ในสถานะ safe แต่ยังไม่ finalized ต้องตรวจสอบลำดับแฮชและป้ายฉันทามติของไคลเอนต์ เพราะความสูงเพียงอย่างเดียวไม่เพียงพอ
- **เกณฑ์ของเชนเทียบกับเครดิตของแพลตฟอร์ม** นโยบายของแพลตฟอร์มกำหนด `6 confirmations` เงินฝากในบล็อก `900,000` อยู่ที่ `5/6` เมื่อปลายเชนเป็น `900,004` และถึง `6/6` ที่ `900,005` หากแพลตฟอร์มกำหนด `15-minute compliance hold` ต่อจากนั้น สิทธิ์ตามเชนกับเวลาที่เครดิต ซื้อขาย หรือถอนได้ยังเป็นคนละสถานะ ช่วงพักนี้ไม่ใช่การยืนยันครั้งที่เจ็ด

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

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

- ตรวจสอบผิดเชน เครือข่าย หรือสินทรัพย์
- ใช้แฮชธุรกรรม ผู้รับ memo หรือ tag ผิด
- ถือว่าธุรกรรมที่ลงนามแล้วแต่ยังไม่เผยแพร่กำลังรอการยืนยัน
- ถือว่า mempool ของโหนดเดียวเป็นสถานะของทั้งเครือข่าย
- มองข้ามการปฏิเสธตามนโยบาย การนำออก หรือการไม่กระจายธุรกรรม
- มองข้ามการแทนที่แบบ RBF, nonce เดิม หรือธุรกรรมขัดแย้ง
- อ่านธุรกรรมบรรพบุรุษ ธุรกรรมลูก หรือค่าธรรมเนียมแบบแพ็กเกจที่ยังไม่ยืนยันผิด
- สับสนระหว่างการนับแบบรวมกับการนับเฉพาะบล็อกที่สืบทอดต่อมา
- เชื่อถือโหนดที่ล้าสมัย กำลังซิงก์ หรือถูกแยกออกจากเครือข่าย
- เปรียบเทียบความสูงโดยไม่ตรวจสอบแฮชบล็อกและลำดับบรรพบุรุษ
- สูญเสียการยืนยันจากการจัดระเบียบ PoW ใหม่ระยะสั้น
- ถือว่าความลึกคงที่ให้ความปลอดภัยสมบูรณ์สำหรับทุกมูลค่าและคู่ปรับ
- สับสนระหว่างเวลาที่ผ่านไป slot, epoch และจำนวนบล็อกที่ผลิต
- ถือว่าบล็อก head ของ PoS อยู่ในสถานะ safe
- ถือว่าบล็อก safe อยู่ในสถานะ finalized
- มองข้าม finality ที่ล่าช้าขณะที่เชนยังผลิตบล็อก
- ถือว่าการประมวลผลที่รวมแล้วแต่ revert เป็นความสำเร็จของแอปพลิเคชัน
- สับสนระหว่าง log ของโทเค็นหรือ UI ของ explorer กับ state ที่เกิดขึ้นจริง
- ถือว่าการตรวจพบ เครดิต สิทธิ์ซื้อขาย และสิทธิ์ถอนของแพลตฟอร์มเป็นสถานะเดียวกัน
- ถือว่าการยืนยันบนเชนต้นทางคือการเสร็จสิ้นของ bridge ผู้ออกสินทรัพย์ หรือกระบวนการปลายทาง

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

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

- แฮชธุรกรรมที่ค้นหาได้หรือรายการใน mempool ภายในหมายถึงได้รับการยืนยันแล้ว
- หลักการนับหนึ่งแบบและเกณฑ์หกการยืนยันใช้ได้กับทุกเชน จำนวนเงิน และบริการ
- การจ่ายค่าธรรมเนียมสูงขึ้นทำให้บล็อกถัดไปหรือ finality ของ PoS มาถึงเร็วขึ้น
- จำนวนบล็อกหรือ slot ของ Ethereum ที่กำหนดตายตัวเท่ากับ `safe` หรือ `finalized`
- การรวมในเชนหรือ finality รับประกันว่าการประมวลผลสัญญาสำเร็จ รายละเอียดผู้รับถูกต้อง แพลตฟอร์มให้เครดิต หรือ bridge ทำงานเสร็จ

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

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

- [Mempool](/th/crypto/mempool/)
- [Bitcoin](/th/crypto/bitcoin/)
- [Finality](/th/crypto/finality/)

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

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

- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (เข้าถึงเมื่อ: 2026-08-13)
- [Payment Processing](https://developer.bitcoin.org/devguide/payment_processing.html) - Bitcoin Developer Documentation (เข้าถึงเมื่อ: 2026-08-13)
- [gettransaction](https://developer.bitcoin.org/reference/rpc/gettransaction.html) - Bitcoin Developer Documentation (เข้าถึงเมื่อ: 2026-08-13)
- [BIP 125: Opt-in Full Replace-by-Fee Signaling](https://bips.dev/125/) - Bitcoin Improvement Proposals (เข้าถึงเมื่อ: 2026-08-13)
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-13)
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-13)
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-13)
- [Cryptocurrency deposit processing times](https://support.kraken.com/articles/203325283-cryptocurrency-deposit-processing-times) - Kraken Support (เข้าถึงเมื่อ: 2026-08-13)

Source: https://wiki.fcontext.com/th/crypto/block-confirmation/index.mdx