---
title: "Proof of History: ลำดับที่บันทึก Tick, Slot และขอบเขตของฉันทามติ"
description: "Proof of History คือนาฬิกาเชนแฮชแบบลำดับของ Solana ซึ่งทำให้ตรวจสอบลำดับที่ผู้ผลิตบล็อกบันทึกและจำนวนการคำนวณได้ แต่ไม่ได้พิสูจน์เวลาจริง ความเป็นธรรมของลำดับธุรกรรม การเลือกฟอร์ก หรือ finality โดยลำพัง"
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.

# Proof of History: ลำดับที่บันทึก Tick, Slot และขอบเขตของฉันทามติ

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

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

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

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

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

ขอบเขตของหลักฐานนี้จำกัด หาก Entry ผูกข้อมูล d หลังสถานะ h2 ก็จะคำนวณสถานะถัดไป h3 = H(h2 || d) ไม่ได้หากไม่มีข้อมูลนั้น หลักฐานจึงแสดงว่าผู้สร้างรู้ d ก่อนคำนวณ h3 และตรึงตำแหน่งของ d เทียบกับเอาต์พุตภายหลัง แต่ไม่แสดงว่าวาลิเดเตอร์แต่ละรายได้รับ d เมื่อใด ผู้นำเรียงตามลำดับที่ได้รับหรือไม่ d สะท้อนเหตุการณ์ภายนอกจริงหรือไม่ หรือ Entry นั้นกลายเป็นส่วนหนึ่งของประวัติมาตรฐานหรือไม่

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

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

## วิธีวิเคราะห์ Proof of History

1. **แก้ไขบริบทของเครือข่ายและซอฟต์แวร์** บันทึกเครือข่าย, แฮชต้นกำเนิด, สล็อต, ยุค, Agave หรือเวอร์ชันไคลเอ็นต์อื่น และการสังเกต เวลา. อ่านค่าที่ใช้งานอยู่ เช่น hashes_per_tick, ticks_per_slot และ ns_per_slot อย่านำเข้าค่าคงที่จากบทความเก่าหรือคลัสเตอร์อื่น
2. **สร้างเชนแฮชใหม่** เริ่มจากสถานะก่อนหน้าที่เชื่อถือได้ แล้วตรวจสอบ num_hashes, แฮชผลลัพธ์ และรายการธุรกรรมของแต่ละ Entry ใน Agave รหัสของ Entry ขึ้นกับ Entry ก่อนหน้า และเมื่อมีธุรกรรมก็ขึ้นกับแฮชที่ได้จากลายเซ็นของธุรกรรมเหล่านั้น
3. **ตรวจสอบ Tick และตำแหน่ง Slot** ตรวจสอบ Tick Entry จำนวนแฮชที่คาดไว้ Tick height และ Tick height สูงสุดตามกฎของ Bank และ Recorder โดย Recorder ใช้ ticks_per_slot ที่กำหนดไว้เพื่อแมป Tick height ไปยัง Slot ซึ่งเป็นช่วงของโปรโตคอล ไม่ใช่หลักฐานอิสระจากนาฬิกาภายนอก
4. **แยกแยะความแตกต่างจากการมาถึง** ความมุ่งมั่นพิสูจน์ให้เห็นว่าอินพุตเป็นที่รู้จักไม่ช้ากว่าการแทรกลงในลำดับนั้น หากต้องการอ้างสิทธิ์ขอบเขตล่าง ให้ระบุการอ้างอิงกลับที่ลงนามแล้วในสถานะ PoH ก่อนหน้า ขอบเขตทั้งสองไม่ได้พิสูจน์ลำดับที่เห็นครั้งแรกทั่วโลก ความเป็นธรรมของ mempool หรือการประทับเวลา UTC ที่เชื่อถือได้
5. **แยกการสร้างจากการตรวจสอบ** วัดการผลิตตามลำดับบนเชนการขึ้นต่อกันเดียว จากนั้นวัดการเล่นซ้ำโดยใช้ขอบเขตของเซ็กเมนต์ที่ได้รับการตรวจสอบสิทธิ์และคอร์ที่มีอยู่ รายงานแฮชทั้งหมด เวลาแฝงของเส้นทางวิกฤต งานตรวจสอบโดยรวม และสมมติฐานเกี่ยวกับขอบเขตข้อมูล แทนที่จะบอกว่าเพียงการตรวจสอบนั้น "รวดเร็ว"
6. **ติดตามเส้นทางที่เป็นเอกฉันท์** ระบุผู้นำตามกำหนดการ สถานะธนาคาร การโหวต การล็อกเอาต์ กฎตัวเลือกทางแยก สถานะที่รูตหรือสรุปแล้ว และระดับความมุ่งมั่น เชน PoH ที่ถูกต้องยังคงเป็นของทางแยกที่สูญเสียไป และเครื่องนับที่ดูยาวขึ้นเพียงอย่างเดียวก็ไม่ใช่ใบรับรองที่เป็นเอกฉันท์
7. **เน้นความขัดแย้งกับกรณีปฏิบัติการและการดำเนินการ** การสอบถามผู้นำการทดสอบ การละเว้นธุรกรรมและการเรียงลำดับใหม่ ข้ามช่อง พาร์ติชัน ฮาร์ดแวร์ที่เร็วกว่าหรือปรับเทียบไม่ถูกต้อง เครื่องหมายที่ไม่ถูกต้อง การนับ, การเล่นซ้ำล่าช้า, ความไม่พร้อมใช้งานของบัญชีแยกประเภท, ความแตกต่างของไคลเอนต์ และตัวดำเนินการหรือการควบคุมโครงสร้างพื้นฐานที่สัมพันธ์กัน

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

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

## ตัวอย่างการทำงาน

### 1. การแทรกข้อมูลแก้ไขตำแหน่งที่บันทึกไว้

พิจารณา h1 = H(h0) จากนั้นพิจารณา h2 = H(h1) ผู้ผลิตแทรกข้อผูกพันที่ได้รับจากธุรกรรม d และคำนวณ h3 = H(h2 || d) ตามด้วย h4 = H(h3) ใครก็ตามที่เล่นซ้ำการดำเนินการเดียวกันสามารถตรวจสอบได้ว่าเชนที่บันทึกไว้ส่ง d ระหว่าง h2 และ h3 และ h4 ขึ้นอยู่กับผลลัพธ์

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

### 2. การเล่นซ้ำกลุ่มจะช่วยลดเวลาแฝง ไม่ใช่งานรวม

สมมติว่าช่วงเวลาที่บันทึกไว้มี 1,000,000 แฮช และจุดตรวจสอบที่ได้รับการรับรองความถูกต้องแบ่งออกเป็น 10 ส่วนของ 100,000 แฮช ด้วยคอร์ที่เพียงพอ สามารถเล่นซ้ำสิบเซ็กเมนต์ได้พร้อมกัน ดังนั้นเวลาแฝงในการตรวจสอบนาฬิกาแขวนอาจเข้าใกล้ระยะเวลาของเซ็กเมนต์หนึ่งบวกกับโอเวอร์เฮด

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

### 3. เลขคณิตแบบขีดและสล็อตขึ้นอยู่กับการกำหนดค่า

สมมติการกำหนดค่าที่แสดงด้วย hashes_per_tick = 100,000 และ ticks_per_slot = 8 ช่องที่แฮชแบบเต็มจะมีแฮช 100,000 * 8 = 800,000 โดยมีขอบเขตการทำเครื่องหมายหลังจากแต่ละช่วงเวลาที่กำหนดค่าไว้ การเปลี่ยนพารามิเตอร์ตัวใดตัวหนึ่งจะเปลี่ยนการแมป ตัวอย่างนี้ไม่ใช่ค่าคงที่ mainnet ปัจจุบัน

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

### 4. ลำดับที่บันทึกไว้ไม่ใช่ลำดับการมาถึงหรือขั้นสุดท้าย

สมมติว่าธุรกรรม A เข้าถึงผู้นำก่อนธุรกรรม B แต่ผู้นำบันทึก B ใกล้นับ 300,000 และ A ใกล้นับ 450,000 PoH ที่ถูกต้องพิสูจน์ว่า B นำหน้า A ในลำดับที่สร้างขึ้นนั้น ไม่ได้พิสูจน์ว่า B มาถึงก่อน ว่าการสั่งซื้อนั้นยุติธรรม หรือผู้นำคนอื่นปฏิบัติตามคำสั่งเดียวกัน

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

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

## ความเสี่ยงและความล้มเหลวในการตรวจสอบ

### ข้อผิดพลาดด้านการเข้ารหัสและการกำหนดเวลา

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

### ข้อผิดพลาดฉันทามติและโปรโตคอล

- การเรียกฉันทามติ PoH, Proof of Stake, Tower BFT, การเลือกตั้งผู้นำ, การเลือกทางแยก และขั้นสุดท้ายเป็นกลไกเดียวกัน
- สมมติว่าลำดับที่ถูกต้องซึ่งมีจำนวนสูงสุดจะต้องเป็นแบบบัญญัติโดยไม่ต้องตรวจสอบคะแนนโหวตและตัวเลือกทางแยก state.
- การรักษารายการที่เล่นซ้ำในเครื่องตามที่ได้รับการยืนยัน รูท หรือสรุปโดยไม่ต้องตรวจสอบซีแมนทิกส์ความมุ่งมั่นที่ร้องขอ
- การใช้ค่าประวัติ hashes_per_tick, ticks_per_slot หรือระยะเวลาของสล็อตเป็นค่าคงที่ปัจจุบันสากล
- ไม่สนใจช่องที่ข้าม การหมุนเวียนผู้นำ พาร์ติชัน ความคลุมเครือและความแตกต่างของเวอร์ชันไคลเอนต์เมื่อสร้างลำดับใหม่
- การเปรียบเทียบการนับจากทางแยกที่ไม่เกี่ยวข้องหรือสถานะเริ่มต้นราวกับว่าพวกมันอยู่ในลำดับการตรวจสอบสิทธิ์เดียว
- สมมติว่าการบล็อกแฮชล่าสุดของธุรกรรมเป็นเพียงการประทับเวลานาฬิกาแขวนแทนที่จะเป็นบริบทความถูกต้องของโปรโตคอล

### ข้อผิดพลาดในการดำเนินการ ประสิทธิภาพ และการควบคุม

- การสร้างแฮชการเปรียบเทียบเพียงอย่างเดียว โดยไม่สนใจการดำเนินการ การตรวจสอบลายเซ็น เล่นซ้ำ แบนด์วิธ และพื้นที่เก็บข้อมูล
- การเทียบเคียงความขนานของเซกเมนต์ทางทฤษฎีกับการตรวจสอบความถูกต้องของตัวตรวจสอบความถูกต้องที่สังเกตได้ภายใต้ CPU, I/O และการช่วงชิงหน่วยความจำ
- ไม่สนใจความล้มเหลวในการตรวจสอบความถูกต้องของTick เครื่องบันทึกหยุดทำงาน การธนาคารล่าช้า ช่องว่างบัญชีแยกประเภท ความน่าเชื่อถือของสแน็ปช็อต และสถานะที่เสียหาย
- การนับข้อมูลประจำตัวของวาลิเดเตอร์เป็นอิสระเมื่อ ไคลเอนต์ โฮสติ้ง เครือข่าย โครงสร้างพื้นฐานผู้นำ หรือการควบคุมมีการแชร์
- สมมติว่าฮาร์ดแวร์ที่เร็วกว่าจะลบเวลาแฝงของเครือข่าย การสูญเสียแพ็กเก็ต การเซ็นเซอร์ การปฏิเสธการให้บริการ หรือความเสี่ยงในการกระจุกตัวของสเตก
- การนำเสนอระยะเวลาสล็อตเป้าหมาย การประมาณการปริมาณงาน หรือเกณฑ์มาตรฐานเก่าเพื่อเป็นการรับประกันระดับบริการ

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

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

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

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

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

- [กลไกที่เป็นเอกฉันท์](/th/crypto/consensus-mechanism/)
- [Proof of Stake](/th/crypto/proof-of-stake/)
- [วาลิเดเตอร์](/th/crypto/validator/)
- [กฎการเลือกฟอร์ก](/th/crypto/fork-choice-rule/)
- [เวลาบล็อก](/th/crypto/block-time/)

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

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

- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (เข้าถึง: 2026-08-19)
- [Solana: A New Architecture for a High Performance Blockchain](https://solana.com/solana-whitepaper.pdf) - Solana (เข้าถึง: 2026-08-19)
- [Tower BFT: Solana's High Performance Implementation of PBFT](https://solana.com/news/tower-bft--solana-s-high-performance-implementation-of-pbft) - Solana (เข้าถึงได้: 2026-08-19)
- [Agave Entry Module](https://github.com/anza-xyz/agave/blob/master/entry/src/entry.rs) - Anza (เข้าถึงได้: 2026-08-19)
- [Agave Proof-of-History Recorder](https://github.com/anza-xyz/agave/blob/master/poh/src/poh_recorder.rs) - Anza (เข้าถึงได้: 2026-08-19)
- [Agave Bank Runtime](https://github.com/anza-xyz/agave/blob/master/runtime/src/bank.rs) - Anza (เข้าถึง: 2026-08-19)
- [Transaction Confirmation and Expiration](https://solana.com/developers/cookbook/transactions/confirmation) - Solana (เข้าถึงได้: 2026-08-19)
- [Verifiable Delay Functions](https://eprint.iacr.org/2018/601) - IACR Cryptology ePrint Archive (เข้าถึง: 2026-08-19)

Source: https://wiki.fcontext.com/th/crypto/proof-of-history/index.mdx