---
title: "พื้นที่ Blob"
description: "คู่มือที่เริ่มจากการตรวจสอบพื้นที่ Blob ของ Ethereum ความจุที่เข้ารหัสและใช้งานได้ การสุ่มตรวจและการเก็บรักษาใน PeerDAS การเก็บข้อมูลชั่วคราว การสืบสร้างสถานะของ Rollup และขีดจำกัดปัจจุบันที่ขึ้นอยู่กับ fork"
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.

# พื้นที่ Blob

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

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

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

พื้นที่ Blob คือความจุแบบจำกัดและชั่วคราวของ Ethereum สำหรับความพร้อมใช้งานของข้อมูล Blob ที่มี commitment แนบมากับบล็อก พื้นที่นี้ไม่ใช่พื้นที่ประมวลผลของ EVM ไม่ใช่พื้นที่จัดเก็บของสัญญา ไม่ใช่ระบบไฟล์ถาวร และไม่ใช่โทเค็น ธุรกรรมประเภท 3 มีแฮชแบบมีเวอร์ชัน ส่วนข้อมูล Blob ที่ยืนยันความถูกต้องได้จะส่งผ่านข้อมูลส่วนพ่วงของชั้นฉันทามติหรือคอลัมน์ข้อมูล PeerDAS โดย EVM ตรวจสอบแฮชแบบมีเวอร์ชันและตรวจพิสูจน์การเปิดค่าที่จุดหนึ่งได้ แต่ไม่สามารถอ่าน payload ของ Blob โดยตรง

PeerDAS ขยาย Blob ด้วย erasure coding แบ่งเมทริกซ์ที่ขยายแล้วเป็น `128 columns` และให้โหนดเก็บรักษาและสุ่มตรวจเพียงบางส่วนแทนการบังคับให้ทุกโหนดดาวน์โหลด Blob ทุกก้อนแบบเต็ม วิธีนี้สนับสนุนการประเมินความพร้อมใช้งานในเครื่องเชิงความน่าจะเป็น ไม่ใช่หลักฐานความถูกต้องของการประมวลผล Rollup, finality ของ Ethereum ความปลอดภัยของ bridge หรือการเรียกคืนได้ถาวร ความจุเปลี่ยนตาม fork ณ `2026-08-13` mainnet ของ Ethereum หลัง Fusaka BPO2 มีเป้าหมาย `14 blobs per block` และอนุญาตสูงสุด `21` โดยธุรกรรม Blob แต่ละรายการจำกัดที่ `6 blobs`

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

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

1. กำหนดเครือข่าย บล็อกหรือสล็อต fork ที่ใช้งานและตาราง Blob-Parameter-Only รวมถึง Rollup และเวอร์ชันการสืบสร้างสถานะ ตารางเดิม `3/6`, Pectra `6/9`, ตารางปัจจุบัน `14/21`, testnet และพารามิเตอร์ในอนาคตใช้แทนกันไม่ได้
2. ระบุวัตถุการเผยแพร่ ได้แก่ ธุรกรรมประเภท 3 แฮชแบบมีเวอร์ชัน commitment และ proof ของ KZG ดัชนี Blob ต้นทาง L1 และตรวจว่า Rollup ใช้ Blob ของ Ethereum จริง ไม่ใช่ calldata หรือ DA ทางเลือก Commitment ผูกข้อมูลไว้ แต่เพียงลำพังไม่ได้พิสูจน์ว่าไบต์พร้อมใช้งาน
3. แยกหน่วยให้ชัดเจน Blob หนึ่งก้อนมี `4,096 field elements * 32 bytes = 131,072 encoded bytes` ส่วน payload ที่ไม่ถูกจำกัดโดยทั่วไปใช้ `31 bytes` ต่อ field element หรือ `126,976 usable bytes` การบีบอัด การจัดเฟรม padding, blob gas, cell ที่ขยายด้วย erasure coding และไบต์ของแอปพลิเคชันเป็นคนละปริมาณกัน
4. ตรวจสอบขีดจำกัดของตาราง ค่าเป้าหมายใช้กำกับวงจรป้อนกลับด้านราคา ไม่ใช่ความจุที่สงวนไว้ ค่าสูงสุดต่อบล็อกเป็นเพดานฉันทามติ ไม่ใช่ throughput ที่คาดหมาย ขีดจำกัด PeerDAS ที่ `6 blobs per transaction` ต่างจากค่าสูงสุดปัจจุบัน `21 blobs per block`
5. ตรวจสอบเส้นทางความพร้อมใช้งาน PeerDAS ใช้การขยายด้วย erasure coding หนึ่งมิติ cell และคอลัมน์ที่ตรวจสอบความถูกต้องได้ การเผยแพร่แบบ gossip และคำขอระหว่าง peer ภายใต้พารามิเตอร์ปัจจุบัน โหนดสุ่มตรวจอย่างน้อย `8 columns` และมีหน้าที่เก็บรักษาข้อมูล การได้รับอย่างน้อย `64 of 128 columns` ช่วยให้สร้างเมทริกซ์ที่ขยายแล้วกลับคืนได้
6. ติดตามสถานะวงจรชีวิตแยกกัน ได้แก่ commitment ถูกนำเข้าบล็อก คอลัมน์ข้อมูลถูกรับและตรวจสอบ การตรวจ DA ในเครื่องผ่าน บล็อก L1 ปลอดภัยหรือ finalized แบตช์ Rollup ถูกถอดรหัสและสืบสร้างสถานะ หน้าต่างให้บริการขั้นต่ำยังเปิด และทดสอบคลังอิสระแล้ว ความพร้อมใช้งานไม่ได้ทำให้ทุกสถานะหลังจากนั้นเป็นจริง
7. ซ้อมรับมือคอลัมน์ที่หายไป การปิดล้อมมุมมองหรือการแบ่งเครือข่าย การเผยแพร่ล่าช้า การปรับโครงสร้าง L1 ตารางหรือไคลเอนต์ไม่ตรงกัน การอัปเกรดรูปแบบ Rollup และการสูญเสียคลัง เรียกคืน สร้างใหม่ และเก็บข้อมูลที่จำเป็นก่อนหน้าต่างโปรโตคอลหมดอายุ และใช้หัวข้อค่าธรรมเนียม Blob แยกต่างหากสำหรับบัญชีต้นทุนของ batcher และผู้ใช้

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

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

- **หน่วยไบต์ของ Blob หนึ่งก้อน** ความจุที่เข้ารหัสคือ `4,096 * 32 = 131,072 bytes = 128 KiB` ส่วน payload ทั่วไปคือ `4,096 * 31 = 126,976 bytes = 124 KiB` ผลต่างคือ `4,096 bytes` หรือ `3.125%` ของความจุที่เข้ารหัส และการบีบอัดกับการจัดเฟรมของ Rollup จะลด payload ของแอปพลิเคชันลงอีก
- **ความจุปัจจุบันต่อบล็อก** ที่ค่าเป้าหมายมี `14 * 131,072 = 1,835,008 encoded bytes = 1.75 MiB` และ `14 * 126,976 = 1,777,664 usable bytes = 1.6953125 MiB` ที่ค่าสูงสุดมี `21 * 131,072 = 2,752,512 encoded bytes = 2.625 MiB` และ `21 * 126,976 = 2,666,496 usable bytes = 2.54296875 MiB` ตัวเลขเหล่านี้เป็นขีดจำกัดต่อบล็อกของ mainnet ที่ผูกกับวันที่ ก่อนการบีบอัดและการจัดเฟรม
- **ขีดจำกัดของธุรกรรมและบล็อก** ธุรกรรมที่มี `6 blobs` บรรจุ `786,432 encoded bytes = 0.75 MiB` และ `761,856 usable bytes = 0.7265625 MiB` บล็อกสูงสุด `21-blob` ต้องมีอย่างน้อย `4 transactions` เช่น `6 + 6 + 6 + 3` ส่วนบล็อกเป้าหมาย `14-blob` อาจเป็น `6 + 6 + 2` ไม่มีรูปแบบใดเป็นโควตาที่สงวนให้แต่ละ Rollup
- **หน้าต่างให้บริการและปริมาณเชิงทฤษฎี** `4,096 epochs * 32 slots * 12 seconds = 1,572,864 seconds = 18.2044444444 days` ที่ `7,200 slots per day` เชิงทฤษฎีและเป้าหมาย `14-blob` ปริมาณที่เข้ารหัสคือ `100,800 blobs per day = 12.3046875 GiB per day` ส่วนปริมาณที่ใช้ได้โดยทั่วไปคือ `11.920166015625 GiB per day` สล็อตที่พลาดและการนำเข้าบล็อกจริงทำให้ยอดที่เกิดขึ้นต่างออกไป และหน้าต่างให้บริการไม่ใช่คำรับรองการเก็บถาวร

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

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

- ใช้ fork หรือตาราง Blob-Parameter-Only ที่ล้าสมัย
- ปะปนขีดจำกัดของ mainnet, testnet หรือเครือข่ายอื่น
- ถือว่าค่าเป้าหมายเป็นความจุที่รับประกันหรือสงวนไว้
- ถือว่าค่าสูงสุดเป็น throughput ปกติที่คาดหมาย
- ปะปนขีดจำกัดหก Blob ต่อธุรกรรมกับขีดจำกัดต่อบล็อก
- ปะปนหน่วยที่เข้ารหัส ใช้งานได้ บีบอัด จัดเฟรม และ blob gas
- ละเว้น padding หรือค่าใช้จ่ายส่วนเพิ่มจากรูปแบบ Rollup
- เรียก calldata หรือ DA ทางเลือกว่าเป็นพื้นที่ Blob ของ Ethereum
- ยอมรับแฮชแบบมีเวอร์ชันที่ไม่ตรงกับ commitment ของ Blob
- ถือว่าการเปิดค่า KZG ที่ถูกต้องพิสูจน์ว่าไบต์พร้อมใช้งาน
- ถือว่าการสุ่มตรวจคือการดาวน์โหลด Blob ทุกก้อนแบบเต็มในเครื่อง
- ปะปนความพร้อมใช้งานของข้อมูลกับความถูกต้องของการเปลี่ยนสถานะ
- ปะปนการตรวจ DA ในเครื่องกับ finality ของ L1 หรือ Rollup
- สูญเสียคอลัมน์จากความล่าช้า การปิดล้อมมุมมอง การแบ่งเครือข่าย หรือ peer ที่สัมพันธ์กัน
- สร้างข้อมูลคืนหรือขอจาก peer ไม่สำเร็จแม้มีความจุตามทฤษฎี
- สูญเสียหรือสลับลำดับ commitment จากการปรับโครงสร้าง L1
- ปล่อยให้หน้าต่างให้บริการขั้นต่ำหมดก่อนการสืบสร้างสถานะหรือ challenge
- พึ่งพาคลังหรือ indexer ที่ใช้งานไม่ได้ เสียหาย หรือไม่ครบถ้วน
- การสืบสร้างสถานะของ Rollup ล้มเหลวหลังอัปเกรดการบีบอัดหรือโปรโตคอล
- ถือว่า bridge หรือการออกปลอดภัยเพียงเพราะข้อมูล Blob พร้อมใช้งาน

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

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

- พื้นที่ Blob เป็นพื้นที่จัดเก็บถาวรที่สัญญาอ่านได้เหมือน calldata
- ทุกไบต์ใน Blob ขนาด `128 KiB` เป็น payload ของแอปพลิเคชันที่ใช้ได้อย่างอิสระ
- ทุกโหนด Ethereum ดาวน์โหลดและเก็บ Blob ทุกก้อนแบบเต็มไว้อย่างถาวรภายใต้ PeerDAS
- Commitment KZG การสุ่มตรวจสำเร็จ หรือการนำเข้าบล็อกที่ finalized พิสูจน์ว่าสถานะ Rollup ถูกต้องและผู้ใช้ออกได้
- ความจุ mainnet ถูกกำหนดถาวรไว้ที่ `3/6`, `6/9` หรือตารางปัจจุบัน `14/21`

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

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

- [ค่าธรรมเนียม Blob และต้นทุนของ Rollup](/th/crypto/blob-fee-rollup-cost/)
- [การสุ่มตรวจความพร้อมใช้งานของข้อมูล](/th/crypto/data-availability-sampling/)
- [Rollup](/th/crypto/rollup/)

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

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

- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-13)
- [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://eips.ethereum.org/EIPS/eip-7594) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-13)
- [EIP-7840: Add blob schedule to EL config files](https://eips.ethereum.org/EIPS/eip-7840) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-13)
- [EIP-7892: Blob Parameter Only Hardforks](https://eips.ethereum.org/EIPS/eip-7892) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-13)
- [Checkpoint #8: Jan 2026](https://blog.ethereum.org/2026/01/20/checkpoint-8) - Ethereum Foundation Blog (เข้าถึงเมื่อ: 2026-08-13)
- [Fulu -- Data Availability Sampling Core](https://github.com/ethereum/consensus-specs/blob/master/specs/fulu/das-core.md) - Ethereum Consensus Specifications (เข้าถึงเมื่อ: 2026-08-13)
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-13)
- [Blockchain Data Storage Strategies](https://ethereum.org/developers/docs/data-availability/blockchain-data-storage-strategies/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-13)

Source: https://wiki.fcontext.com/th/crypto/blobspace/index.mdx