ข้ามไปยังเนื้อหา
Financial Context Wiki

พื้นที่ Blob

คู่มือที่เริ่มจากการตรวจสอบพื้นที่ Blob ของ Ethereum ความจุที่เข้ารหัสและใช้งานได้ การสุ่มตรวจและการเก็บรักษาใน PeerDAS การเก็บข้อมูลชั่วคราว การสืบสร้างสถานะของ Rollup และขีดจำกัดปัจจุบันที่ขึ้นอยู่กับ fork

อัปเดต

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

คำตอบโดยตรง

พื้นที่ 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

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

  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 และผู้ใช้

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

  • หน่วยไบต์ของ 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 สล็อตที่พลาดและการนำเข้าบล็อกจริงทำให้ยอดที่เกิดขึ้นต่างออกไป และหน้าต่างให้บริการไม่ใช่คำรับรองการเก็บถาวร

ความเสี่ยง

  • ใช้ 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 พร้อมใช้งาน

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

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

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

แหล่งข้อมูล

การนำทาง

ค้นหาในวิกิ...