---
title: "เวลาบล็อก"
description: "เวลาบล็อกอาจหมายถึง slot ที่กำหนดไว้ ช่วงเวลาเป้าหมายของ proof-of-work หรือช่วงห่างที่สังเกตระหว่างบล็อกแคนนอนิคัล คู่มือนี้อธิบายวิธีวัดแต่ละเวลาโดยไม่สับสนกับการบรรจุ การยืนยัน หรือ 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.

# เวลาบล็อก

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

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

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

เวลาบล็อกไม่ใช่นาฬิกาจับเวลาสากลหนึ่งเดียว ใน proof-of-work คำนี้มักหมายถึงเป้าหมายระยะยาวของกระบวนการมาถึงของบล็อกแบบสุ่ม ใน proof-of-stake ที่อิง slot อาจหมายถึงระยะเวลาที่กำหนดไว้สำหรับโอกาสเสนอ block ส่วนช่วงห่างที่สังเกตระหว่างบล็อกแคนนอนิคัลสองบล็อกเป็นอีกค่าหนึ่ง และการบรรจุธุรกรรม ความลึกของการยืนยัน และ finality ต่างมีนาฬิกาแยกกัน

บน mainnet Ethereum ปัจจุบันแบ่งเวลาเป็น `12-second slots` โดยมี `32 slots` ต่อ epoch ผู้เสนออาจพลาด slot ทำให้บล็อกที่ผลิตติดกันห่าง `24 seconds`, `36 seconds` หรือมากกว่าได้ แม้ระยะเวลา slot ยังคงเป็น `12 seconds` ส่วนใน Bitcoin ค่า `600 seconds` คือช่วงเฉลี่ยเป้าหมายที่ระบบความยากใช้ ไม่ใช่เส้นตายของบล็อกถัดไป

ต้องระบุเชน เครือข่าย fork หน้าต่างสังเกต และนาฬิกาเสมอ timestamp ในส่วนหัวเป็นข้อมูลโปรโตคอล ไม่จำเป็นต้องเป็นเวลาที่ทุกโหนดได้รับบล็อก ช่วงเวลาที่สั้นลงอาจทำให้มีโอกาสบรรจุเร็วขึ้น แต่ไม่ได้รับประกัน throughput สูงขึ้น ค่าธรรมเนียมต่ำลง รีออร์แกไนซ์น้อยลง หรือ finality เร็วขึ้นด้วยตัวมันเอง

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

## วิธีการทำงาน

1. ระบุเชน เครือข่าย layer, fork ที่ใช้งาน head แคนนอนิคัล โหนดหรือผู้ให้บริการ RPC และหน้าต่างสังเกต UTC บันทึกแฮชบล็อกแทนการถือว่าความสูงเพียงอย่างเดียวเป็นตัวระบุที่ไม่ซ้ำ
2. กำหนดเมตริกก่อนคำนวณ ได้แก่ ช่วงเป้าหมายของโปรโตคอล ระยะเวลา slot ที่กำหนดไว้ ผลต่าง timestamp ของบล็อกแคนนอนิคัลที่ติดกัน ผลต่างเวลารับในเครื่อง ความหน่วงในการบรรจุธุรกรรม ความลึกของการยืนยัน หรือเวลา finality
3. เก็บแฮช แฮช parent ความสูงหรือ slot, timestamp โปรโตคอล และเวลารับแบบ monotonic ในเครื่องของแต่ละบล็อก เก็บ slot ที่พลาด บล็อก stale และบล็อกที่ถูกรีออร์แกไนซ์เป็น state ชัดเจนแทนการลบทิ้งเงียบๆ
4. ไล่สายบรรพบุรุษแคนนอนิคัล คำนวณช่วงห่างที่ติดกัน และเผยแพร่จำนวนตัวอย่าง หน้าต่าง ค่าเฉลี่ย มัธยฐาน เปอร์เซ็นไทล์ ค่าต่ำสุด ค่าสูงสุด และอัตรา slot ที่พลาด ค่าเฉลี่ยเดียวอธิบายการกระจายเวลารอที่เบ้ไม่ได้
5. ใช้แบบจำลองฉันทามติ สำหรับ Ethereum ให้แยก slot, epoch, head และ checkpoint แบบ safe กับ finalized สำหรับ Bitcoin ให้แยก `600-second target`, การมาถึงแบบสุ่มที่ขึ้นกับ hash rate, chainwork, หน้าต่างปรับความยาก `2,016-block` และกฎความถูกต้องของ timestamp
6. แยกความหน่วงของผู้ใช้ออกเป็นการ broadcast การรอใน mempool ท้องถิ่นหรือ sequencer การเสนอบล็อก การเผยแพร่ การบรรจุแบบแคนนอนิคัล การยืนยัน สถานะ safe หรือ finalized และการประมวลผลของ bridge, exchange หรือแอปพลิเคชัน
7. ตรวจเทียบโหนดอิสระและทดสอบ clock skew, ช่องว่าง RPC, ผู้เสนอที่พลาด การเปลี่ยน hash rate, การแบ่งเครือข่าย รีออร์แกไนซ์ finality ล่าช้า sequencer หยุดทำงาน และพารามิเตอร์ fork เปลี่ยน ก่อนกำหนด SLA

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

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

- บล็อก Ethereum ผลิตที่ slot `1,000` และ `1,003` ผลต่าง timestamp ตามกำหนดคือ `(1,003 - 1,000) * 12 = 36 seconds` โดย slot `1,001` และ `1,002` ถูกพลาด ความสูงบล็อกเพิ่มหนึ่งบล็อกที่ผลิต แต่หมายเลข slot เพิ่มสาม
- ใน `300 slots` หน้าต่างตามกำหนดคือ `300 * 12 = 3,600 seconds` หากผลิต `294 canonical blocks` จะมี `6 missed slots` อัตราส่วนการผลิตคือ `294 / 300 = 98%` อัตราหน้าต่างคือ `294 / 3,600 = 0.0816666667 blocks/second` และส่วนกลับคือ `12.2448979592 seconds/block` นี่เป็นสถิติของหน้าต่าง ไม่ใช่คำรับรอง
- หนึ่ง epoch ของ Ethereum คือ `32 * 12 = 384 seconds = 6.4 minutes` และสอง epoch ยาว `768 seconds = 12.8 minutes` เสียงโหวต checkpoint กับการมีส่วนร่วมเป็นตัวกำหนด finality ดังนั้นเลขคำนวณนี้ไม่ใช่ SLA finality คงที่ ปัจจุบัน Ethereum อธิบาย finality ปกติไว้ที่ประมาณ `15 minutes`
- ภายใต้แบบจำลองการมาถึงแบบเอ็กซ์โพเนนเชียลอย่างง่ายของ Bitcoin ซึ่งมีค่าเฉลี่ย `600 seconds` ความน่าจะเป็นที่จะไม่มีบล็อกใน `1,200 seconds` คือ `e^(-1,200/600) = e^-2 = 13.5335283237%` ดังนั้นความน่าจะเป็นที่จะมีอย่างน้อยหนึ่งบล็อกคือ `86.4664716763%` หน้าต่างเป้าหมายความยากคือ `2,016 * 600 = 1,209,600 seconds = 14 days` ไม่มีตัวเลขใดกำหนดเวลาของบล็อกรายบล็อก

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

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

- ใช้เชน เครือข่าย layer, fork หรือพารามิเตอร์ในอดีตผิด
- เปรียบเทียบ slot ที่กำหนดไว้กับเป้าหมาย proof-of-work หรือช่วงห่างบล็อกที่สังเกต
- ถือว่าเป้าหมายโปรโตคอลหรือค่าเฉลี่ยตัวอย่างรับประกันเวลารอสูงสุด
- เลือกหน้าต่างสังเกตสั้น เงียบ หรือคัดมาเพื่อสนับสนุนข้อสรุป
- ถือว่า timestamp ของส่วนหัวบล็อกคือเวลาผลิตหรือรับจริงที่แม่นยำ
- ผสมนาฬิกาของผู้สังเกตที่เวลาในเครื่องไม่ตรงกัน
- ตัด slot ที่พลาดออกหรือสับสนระหว่างบล็อกว่างที่ผลิตกับ slot ที่พลาด
- รวมบล็อก stale หรือบล็อกที่ถูกรีออร์แกไนซ์ในชุดช่วงห่างแคนนอนิคัล
- นับการเปลี่ยนความสูงโดยไม่ตรวจแฮช parent และสายบรรพบุรุษ
- ซ่อนช่องว่าง RPC, indexer, websocket หรือ log ในเครื่องเป็นพฤติกรรมเครือข่าย
- รายงานค่าเฉลี่ยโดยไม่มีมัธยฐาน เปอร์เซ็นไทล์ ช่วง และจำนวนตัวอย่าง
- สับสนระหว่างเวลารอ mempool หรือ sequencer กับเวลาผลิตบล็อก
- สับสนระหว่างการบรรจุครั้งแรกหรือหนึ่งการยืนยันกับ finality ทางเศรษฐกิจ
- แปลงจำนวนการยืนยันเป็นจำนวนนาทีตายตัว
- ถือว่า `10-minute target` ของ Bitcoin เป็น SLA การชำระเงินหรือขุด
- มองข้ามการเปลี่ยน hash rate, ความล่าช้าในการปรับความยาก และขอบเขต timestamp ของผู้ขุด
- มองข้ามแรงกดดันด้านการเผยแพร่ การตรวจสอบ และ fork ชั่วคราวเมื่อช่วงสั้นลง
- ถือว่า `12-second slot` ของ Ethereum รับประกันบล็อกที่ไม่ว่าง
- ถือว่าบล็อก sequencer ของ L2 คือการเผยแพร่ settlement หรือ finality บน L1
- สรุป TPS ค่าธรรมเนียม ความปลอดภัย หรือการกระจายศูนย์จากเวลาบล็อกเพียงอย่างเดียว

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

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

- **ทุก slot ของ Ethereum มีบล็อก** slot เป็นโอกาสเสนอ ผู้เสนอที่พลาดหรือการเผยแพร่ล้มเหลวอาจทำให้ว่าง
- **Bitcoin ผลิตหนึ่งบล็อกทุกสิบนาทีพอดี** สิบนาทีคือเป้าหมายความยากและพารามิเตอร์ค่าเฉลี่ยของแบบจำลอง เวลารอแต่ละครั้งแตกต่างกันมาก
- **timestamp ของบล็อกคือเวลาที่ทุกโหนดได้รับบล็อก** timestamp โปรโตคอลกับ log การมาถึงในเครื่องมีผู้สร้าง ข้อจำกัด และนาฬิกาต่างกัน
- **การลดเวลาบล็อกครึ่งหนึ่งเพิ่ม TPS ที่ปลอดภัยเป็นสองเท่า และลดค่าธรรมเนียมหรือ finality ครึ่งหนึ่งโดยอัตโนมัติ** ความจุ ภาระงาน ความต้องการ การเผยแพร่ และเสียงโหวตฉันทามติยังเป็นข้อจำกัดอิสระ
- **บล็อก L2 ที่เร็วมี finality ของ Ethereum แล้ว** การบรรจุโดย sequencer การเผยแพร่ข้อมูลบน L1 การบรรจุแคนนอนิคัลบน L1 และ finality เป็นคนละ state

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

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

- [จำนวนการยืนยันบล็อก](/th/crypto/block-confirmation/)
- [การรีออร์แกไนซ์เชน](/th/crypto/chain-reorg/)
- [Finality](/th/crypto/finality/)

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

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

- [บล็อก](https://ethereum.org/developers/docs/blocks/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-18)
- [การเสนอบล็อก](https://ethereum.org/developers/docs/consensus-mechanisms/pos/block-proposal/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-18)
- [Proof-of-stake](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-18)
- [Finality ใน slot เดียว](https://ethereum.org/roadmap/single-slot-finality/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-18)
- [Beacon Chain](https://ethereum.github.io/consensus-specs/specs/phase0/beacon-chain/) - Ethereum Consensus Specs (เข้าถึงเมื่อ: 2026-08-18)
- [Bitcoin: ระบบเงินสดอิเล็กทรอนิกส์แบบ peer-to-peer](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (เข้าถึงเมื่อ: 2026-08-18)
- [บล็อกเชน](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin Developer Documentation (เข้าถึงเมื่อ: 2026-08-18)
- [ข้อมูลอ้างอิงบล็อกเชน](https://developer.bitcoin.org/reference/block_chain.html) - Bitcoin Developer Documentation (เข้าถึงเมื่อ: 2026-08-18)

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