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

ความพร้อมใช้งานของข้อมูล

คู่มือที่เริ่มจากการตรวจสอบการเผยแพร่และการเรียกคืนข้อมูล commitment ความถูกต้อง finality การสุ่มตัวอย่าง การเก็บรักษา คลังข้อมูล การอนุมานสถานะ rollup และการกู้คืนที่ทำได้จริง

อัปเดต

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

คำตอบโดยตรง

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

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

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

  1. นิยามข้อกล่าวอ้างก่อนวัด โดยระบุชุดข้อมูล blob namespace หรือวัตถุข้อมูลที่เข้ารหัสให้แน่นอน โปรโตคอลและรุ่น ผู้ใช้ข้อมูลเป้าหมาย งานอนุมาน ตรวจสอบ หรือออกจากระบบที่ต้องทำ และช่วงเวลาความพร้อมใช้งาน การทักท้วง และการกู้คืน ข้อมูลครบถ้วนหมายถึงข้อมูลที่เพียงพอตามโปรโตคอลนั้น ไม่ใช่สำเนาธุรกรรมทุกแห่งแบบไร้นิยาม
  2. ตรึงเส้นทางและหลักฐานการเผยแพร่ ได้แก่ เชนชำระราคา เชน DA เฉพาะ calldata, blob sidecar, commitment ภายนอก หรือใบรับรองคณะกรรมการ รหัสบล็อก slot และ batch การเข้ารหัสและบีบอัด commitment รวมถึงสัญญาหรือบริดจ์ที่นำข้อมูลไปใช้ การเผยแพร่ในที่หนึ่งไม่ได้พิสูจน์ว่าผู้ตรวจสอบอีกแห่งตรวจข้อมูลนั้น
  3. ทดสอบการผูกข้อมูลและการสร้างใหม่โดยอิสระ ดึงไบต์โดยไม่ใช้ API ของโครงการ ตรวจ hash, KZG หรือ commitment อื่นและข้อมูลอ้างอิงการรวมไว้ ตรวจ framing กับ erasure coding ถอดรหัส batch และสร้างอินพุตที่ใช้อนุมานสถานะซ้ำ commitment ที่ถูกต้องแต่ไม่มีไบต์ไม่ถือว่าสร้างข้อมูลใหม่สำเร็จ
  4. ทำแผนผังโมเดลการยอมรับ บันทึกว่า full node ดาวน์โหลดวัตถุหรือไม่ light node สุ่มส่วนแบ่งข้อมูลที่ยืนยันตัวตนแล้วหรือไม่ validator มีหน้าที่เก็บข้อมูลหรือไม่ หรือคณะกรรมการความพร้อมใช้งานของข้อมูลลงนามใบรับรองตามเกณฑ์ ระบุสมมติฐานด้านการสุ่ม การลบ ความเป็นอิสระของ peer เกณฑ์ stake กุญแจ และ eclipse ตลอดจนสิ่งที่สัญญาชำระราคาหรือบริดจ์ตรวจจริง
  5. ติดตามสถานะและนาฬิกาแยกกัน ได้แก่ ส่งแล้ว รวมไว้แล้ว พร้อมใช้ในช่วงโปรโตคอล ไคลเอนต์อิสระเรียกคืนได้ ถอดรหัสหรืออนุมานแล้ว การดำเนินการถูกต้อง ปลอดภัย final แล้ว และเก็บถาวรแล้ว proof ความถูกต้องอาจยืนยันการคำนวณภายใต้ข้อจำกัดได้ ขณะที่ข้อมูลสำหรับการอนุมานหรือดำเนินงานโดยอิสระยังไม่พร้อมใช้
  6. วัดการเก็บรักษา การเริ่มต้นโหนด และเศรษฐศาสตร์ บันทึกขั้นต่ำในการให้บริการของโปรโตคอล พฤติกรรมการลบ ผู้ให้บริการคลังและ snapshot ข้อกำหนดของโหนดใหม่ ไบต์ดิบและเข้ารหัส overhead ราคาต่อหน่วย ต้นทุน proof และธุรกรรม เพดานความจุ เงินอุดหนุน และต้นทุน fallback การเรียกคืนระยะยาวเป็นการพึ่งพาเพิ่มเติมหลัง DA ชั่วคราวหมดอายุ
  7. ซ้อมเหตุขัดข้อง ทดสอบการปกปิดข้อมูล การให้บริการแบบเลือกปฏิบัติ ตัวอย่างที่สัมพันธ์กันหรือถูก eclipse การสูญเสียคณะกรรมการ DA หยุดหรือ fork เชนชำระราคาจัดระเบียบใหม่ frame หาย คลังสูญหาย sequencer เซ็นเซอร์ และค่าธรรมเนียมพุ่ง ตรวจว่า safe halt, forced inclusion, retry, fallback, การสร้างใหม่ และ exit ทำได้จริงด้วยซอฟต์แวร์ ข้อมูล และค่าแก๊สจริง แล้วเก็บ commitment ใบรับธุรกรรม และหลักฐานคลังอิสระ

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

  • หน่วยต้นทุนข้อมูลที่ถูกต้อง หนึ่ง batch มี 400,000 bytes ครอบคลุม 2,000 transactions และมีราคา $0.00002 per byte ค่าข้อมูล DA คือ 400,000 * $0.00002 = $8 per batch หรือ $8 / 2,000 = $0.004 per transaction หากราคาต่อหน่วยเพิ่มสิบเท่าเป็น $0.00020 per byte ต้นทุนจะเป็น $80 per batch และ $0.040 per transaction ไม่ใช่ $0.04 per batch ตัวเลขนี้ไม่รวมการดำเนินการ proof, overhead ของธุรกรรม การเก็บถาวร และส่วนต่าง
  • ช่วงให้บริการของโปรโตคอลไม่ใช่คำมั่นเก็บถาวร ช่วงคำขอขั้นต่ำของ EIP-4844 คือ 4,096 epochs เมื่อมี 32 slots per epoch และ 12 seconds per slot จะเท่ากับ 4,096 * 32 * 12 = 1,572,864 seconds หรือ 1,572,864 / 86,400 = 18.2044444444 days นี่คือขั้นต่ำของโปรโตคอลในโมเดลนี้ ไม่ใช่การรับประกันว่าผู้ให้บริการรายหนึ่งจะเก็บ blob หนึ่งไว้ตลอดไป
  • ความน่าจะเป็นของการสุ่มแบบจำลอง สมมติเพื่ออธิบายเท่านั้นว่าผู้โจมตีปกปิด 50% ของส่วนแบ่งข้อมูลที่ขยายแล้วซึ่งถูกสุ่มอย่างสม่ำเสมอ และตัวอย่างยืนยันตัวตน 30 ตัวเป็นอิสระและสุ่มแบบคืนกลับ ความน่าจะเป็นที่ทุกตัวอย่างพลาดส่วนที่ถูกปกปิดคือ 0.5^30 = 0.0000000009313225746 ดังนั้นความน่าจะเป็นในการตรวจพบคือ 99.9999999069% นี่ไม่ใช่การรับประกันบริการของ PeerDAS ที่ใช้งานจริงหรือเครือข่ายอื่น เพราะ peer ที่สัมพันธ์กัน การสุ่มลำเอียง พารามิเตอร์การเข้ารหัส และการโจมตีแบบปรับตัวเปลี่ยนผลลัพธ์ได้
  • เกณฑ์คณะกรรมการไม่เท่ากับการเรียกคืนได้ในขณะนี้ สมมติคณะกรรมการ DA ต้องใช้ลายเซ็น 5-of-7 หากสมาชิกสามรายไม่พร้อม จะเหลือเพียง 4 ราย จึงสร้างใบรับรองตามเกณฑ์ใหม่ไม่ได้ ใบรับรองเดิมที่มี 5 signatures พิสูจน์ว่าเกณฑ์ได้ให้การรับรองตามกฎของตน ไม่ได้พิสูจน์ว่าผู้ใช้รายหนึ่งเรียกคืนไบต์ได้ตอนนี้ การดำเนินการถูกต้อง หรือการชำระราคา final แล้ว

ความเสี่ยง

  • ตรวจเชน batch, blob, namespace หรือรุ่นโปรโตคอลผิด
  • สับสน commitment หรือใบรับรองกับไบต์ข้อมูลต้นทาง
  • ถือว่าการเรียกคืนจากจุดเดียวในขณะนี้คือความพร้อมใช้ทั่วทั้งโปรโตคอล
  • ถือว่าความพร้อมใช้งานของข้อมูลเป็น proof ความถูกต้องของการดำเนินการ
  • ถือว่าความพร้อมใช้งานหรือความถูกต้องคือ finality ของฉันทามติ
  • อ้างอิงบล็อกชำระราคาที่ล้าสมัย ไม่ปลอดภัย หรือถูกจัดระเบียบใหม่
  • พลาดช่วงเก็บรักษาของโปรโตคอลก่อนดึงข้อมูล
  • พึ่งคลัง snapshot ตัวทำดัชนี หรือ API ของโครงการเพียงแห่งเดียว
  • ยอมรับ framing การบีบอัด หรือ erasure coding ที่ผิดรูป
  • ไม่ตรวจ hash, KZG หรือ commitment อื่น
  • สุ่มส่วนแบ่งข้อมูลน้อยเกินไปสำหรับโมเดลภัยคุกคามที่ระบุ
  • สมมติว่าตัวอย่าง peer หรือกลุ่ม custody เป็นอิสระทั้งที่สัมพันธ์กัน
  • ถูก eclipse attack การเลือก peer แบบลำเอียง หรือการให้บริการแบบเลือกปฏิบัติ
  • ใช้พารามิเตอร์ erasure หรือเกณฑ์สร้างใหม่ไม่ตรงกับผู้ตรวจสอบ
  • พึ่งคณะกรรมการ DA ที่สมรู้ร่วมคิดหรือไม่พร้อมทำงาน
  • ปล่อยให้สัญญาบริดจ์หรือชำระราคายอมรับวัตถุที่อ่อนกว่าที่ผู้ใช้คาด
  • สูญเสียข้อมูลจาก sequencer ปกปิด เซ็นเซอร์ หรือ frame ของ batch หาย
  • พบ DA หยุด fork จัดระเบียบใหม่ หรือไคลเอนต์อัปเกรดไม่เข้ากัน
  • พบว่า forced inclusion, fallback, การกู้คืน หรือ exit ทำไม่ได้จริง
  • ประเมินความจุ ค่าธรรมเนียมพุ่ง overhead ค่าคลัง หรือการสิ้นสุดเงินอุดหนุนต่ำเกินไป

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

  • proof ความถูกต้องทำให้ไม่ต้องมีความพร้อมใช้งานของข้อมูล
  • commitment หรือ proof แบบ KZG พิสูจน์ว่าเรียกใช้ไบต์ครบทั้งหมดได้
  • การรวมไว้ในบล็อกที่ final แล้วหมายถึงเรียกคืนข้อมูลได้ถาวร
  • ป้าย on-chain, blob, DA เฉพาะ หรือการสุ่มตรวจให้ความปลอดภัยแบบเดียวกันโดยอัตโนมัติ
  • ตัวอย่างมากขึ้นหรือต้นทุนต่ำลงเพียงอย่างเดียวพิสูจน์ว่าแบบ DA หนึ่งเหนือกว่า

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

แหล่งข้อมูล

การนำทาง

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