---
title: "สถาปัตยกรรมบล็อกเชนแบบโมดูลาร์"
description: "คู่มือวิเคราะห์การแยกหน้าที่ด้านการประมวลผล การจัดลำดับ ความพร้อมใช้งานของข้อมูล ฉันทามติ การรับรองผล หลักฐาน บริดจ์ การกำกับดูแล และการเก็บถาวรตามความเชื่อมโยงของระบบ"
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>

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

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

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

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

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

1. ระบุระบบที่ติดตั้งจริง ได้แก่ chain ID ของเชนประมวลผลและเชนรับรองผล เวอร์ชันโปรโตคอล เครื่องเสมือน สัญญา ที่อยู่บริดจ์และสินทรัพย์ รูปแบบความพร้อมใช้งานของข้อมูล ผู้ดำเนินการ ผู้ดูแล และบล็อกหรือเวลาที่สังเกต การจัดประเภททางการตลาดทดแทนการตั้งค่าที่ติดตั้งจริงไม่ได้
2. สร้างตารางหน้าที่ แยกการรับและจัดลำดับธุรกรรม การประมวลผลแบบกำหนดผลแน่นอน ข้อผูกพันสถานะและหลักฐานหรือข้อพิพาทข้อผิดพลาด การเผยแพร่ DA และฉันทามติ การยอมรับและภาวะสิ้นสุดของระบบรับรองผล บริดจ์และข้อความข้ามโดเมน การอัปเกรดและหยุดชั่วคราว ตลอดจนการเก็บประวัติ บันทึกส่วนที่ทับซ้อนแทนการบังคับให้หนึ่งหน้าที่อยู่ในหนึ่งเลเยอร์
3. ติดตามธุรกรรมและแบตช์หนึ่งรายการตั้งแต่ต้นจนจบ ได้แก่ ข้อมูลลงนาม ใบรับจากซีเควนเซอร์หรือโหนดภายใน การประมวลผลตามลำดับ แบตช์ที่เข้ารหัสและบีบอัด การเผยแพร่ผ่าน calldata, blob หรือ DA ภายนอก การอ้างสถานะและหลักฐานหรือข้อพิพาท ภาวะสิ้นสุดของระบบรับรองผล และการประมวลผลข้อความหรือการถอน เก็บแฮช เวอร์ชัน ใบรับ และเวลาไว้ทุกจุดเชื่อมต่อ
4. ระบุวัตถุที่ตรวจสอบและสมมติฐานความไว้วางใจแต่ละรายการ แยกข้อผูกพันข้อมูลออกจากไบต์ แยกความพร้อมใช้ในช่วงเวลาของโปรโตคอลออกจากการดึงข้อมูลภายหลัง แยกความถูกต้องของการประมวลผลออกจากภาวะสิ้นสุดของฉันทามติ และแยกบัญชีบริดจ์ออกจากสภาพคล่องของสินทรัพย์ ระบุว่าใครสามารถประมวลผลซ้ำ พิสูจน์ คัดค้าน ตรวจพิจารณา อัปเกรด หยุด หรือระงับแต่ละวัตถุ
5. สร้างบัญชีความจุและค่าธรรมเนียมใหม่ วัดไบต์ดิบและไบต์บีบอัด การใช้พื้นที่แบตช์ ราคา DA ค่าใช้จ่ายหลักฐานและการรับรองผล ค่าประมวลผลและผู้ดำเนินการ gas ของบริดจ์ และค่าธรรมเนียมสภาพคล่อง การจัดสรรเฉลี่ยต่อแบตช์ไม่เท่ากับค่าธรรมเนียมจริงของผู้ใช้หรือต้นทุนส่วนเพิ่มของธุรกรรมอีกหนึ่งรายการ
6. ทดสอบความล้มเหลวแทนการอ่านเฉพาะปริมาณงานในเส้นทางปกติ หยุดซีเควนเซอร์ ผู้โพสต์แบตช์ ผู้พิสูจน์ ผู้คัดค้าน บริการ DA, RPC ของระบบรับรองผล และรีเลย์บริดจ์ ทดสอบการบังคับบรรจุ การอนุมานอย่างอิสระ การสร้างข้อมูลใหม่ หลักฐานหรือข้อพิพาท การลองใหม่ การออก และการกู้คืนจากคลังถาวรภายใต้ความแออัดและขอบเขตการอัปเกรด
7. กระทบยอดกับหลักฐานมาตรฐาน จับคู่ใบรับการประมวลผลและรากสถานะกับข้อผูกพันแบตช์ การบรรจุ DA สถานะหลักฐานหรือเกม ภาวะสิ้นสุดของระบบรับรองผล ข้อความบริดจ์ และยอดสินทรัพย์สุดท้าย ทบทวนความเชื่อมโยงอีกครั้งหลังการจัดระเบียบเชนใหม่ การเปลี่ยนพารามิเตอร์ การอัปเกรดสัญญา หรือการย้าย DA

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

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

- **ต้นทุนแบตช์และการบีบอัด.** แบตช์หนึ่งมีธุรกรรม `5,000` รายการ ข้อมูลดิบ `2,400 KB` และข้อมูลหลังบีบอัด `300 KB` อัตราส่วนการบีบอัดคือ `2,400 / 300 = 8.0x` และจำนวนไบต์ลดลง `87.5%` หาก DA มีต้นทุน `0.020 ETH` และค่าใช้จ่ายร่วมด้านหลักฐานกับการรับรองผลเป็น `0.005 ETH` ต้นทุนร่วมเฉลี่ยคือ `(0.020 + 0.005) / 5,000 = 0.000005 ETH/tx` เมื่อเพิ่มต้นทุนการประมวลผลและผู้ดำเนินการ `0.000020 ETH/tx` จะได้ `0.000025 ETH/tx` ตัวเลขนี้เป็นการจัดสรร ไม่ใช่ใบเรียกเก็บที่รับประกัน
- **ขอบเขตของแบบจำลองสุ่มตัวอย่าง.** ในแบบจำลองเพื่อการเรียนรู้ ฝ่ายตรงข้ามระงับชิ้นข้อมูล `25%` และไคลเอนต์สุ่มตัวอย่างแบบสม่ำเสมอโดยอิสระพร้อมคืนตัวอย่าง `20` ครั้ง โอกาสไม่พบชิ้นข้อมูลที่ถูกระงับเลยคือ `0.75^20 = 0.003171211939 = 0.3171211939%` และโอกาสตรวจพบคือ `99.6828788061%` เพียร์ที่มีความสัมพันธ์กัน การให้บริการแบบปรับตัว การเข้ารหัสลบข้อมูล และกฎสุ่มตัวอย่างจริงอาจทำให้แบบจำลองง่ายนี้ใช้ไม่ได้
- **ความปลอดภัยและความพร้อมทำงานของคณะกรรมการ.** คณะกรรมการ DA แบบ `5-of-7` สร้างการรับรองตามเกณฑ์ใหม่ได้เมื่อสมาชิกไม่พร้อมใช้งานไม่เกิน `2` ราย หากไม่พร้อม `3` ราย จะเหลือเพียง `4 < 5` ภายใต้กฎเพื่อการเรียนรู้ที่ตรวจเฉพาะลายเซ็น การควบคุมผู้ลงนามที่ได้รับอนุญาต `5` รายก็ผ่านเกณฑ์ได้ ใบรับรองยังไม่พิสูจน์ว่ามีสำเนาถาวรห้าชุด ผู้ใช้ดึงไบต์ได้ในขณะนี้ หรือการประมวลผลและการรับรองผลถูกต้อง
- **หลายช่วงเวลาและการออกอย่างรวดเร็ว.** การยืนยันเบื้องต้นเพื่อการเรียนรู้มาถึงใน `2 seconds` แบตช์เผยแพร่หลัง `8 minutes` และภาวะสิ้นสุดของระบบรับรองผลเกิดขึ้นอีก `13 minutes` ต่อมา เวลารวมที่แม่นยำคือ `21 minutes 2 seconds` หากการถอนแบบออปทิมิสติกเพิ่มเวลาสมมติ `7 days` เวลารวมเป็น `10,101 minutes 2 seconds` บริดจ์เร็วที่คิด `0.15%` จาก `10,000 USDC` หัก `15 USDC` และส่งมอบ `9,985 USDC` ความเร็วนี้เพิ่มสมมติฐานด้านบริดจ์ ผู้ให้สภาพคล่อง และการจัดระเบียบเชนใหม่ ไม่ได้ทำให้เวลาของโปรโตคอลสั้นลง

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

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

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

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

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

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

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

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

- [เลเยอร์ 2](/th/crypto/layer2/)
- [ความพร้อมใช้งานของข้อมูล](/th/crypto/data-availability/)
- [โรลอัป](/th/crypto/rollup/)

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

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

- [Scaling](https://ethereum.org/developers/docs/scaling/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-13)
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-13)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-13)
- [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-13)
- [Zero-knowledge rollups](https://ethereum.org/developers/docs/scaling/zk-rollups/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-13)
- [Rollup Node](https://specs.optimism.io/protocol/rollup-node.html) - OP Stack Specification (เข้าถึงเมื่อ: 2026-08-13)
- [Derivation](https://specs.optimism.io/protocol/derivation.html) - OP Stack Specification (เข้าถึงเมื่อ: 2026-08-13)
- [LazyLedger: A Distributed Data Availability Ledger With Client-Side Smart Contracts](https://arxiv.org/abs/1905.09274) - arXiv (เข้าถึงเมื่อ: 2026-08-13)

Source: https://wiki.fcontext.com/th/crypto/modular-blockchain/index.mdx