الانتقال إلى المحتوى
Financial Context Wiki

مساحة Blob

دليل يبدأ بالتحقق لفهم مساحة Blob في Ethereum، والسعة المرمزة والقابلة للاستخدام، وأخذ العينات والحيازة في PeerDAS، والاحتفاظ المؤقت، واشتقاق Rollup، والحدود الحالية المعتمدة على التفرع.

آخر تحديث

لأغراض تعليمية فقط؛ لا يشكل ذلك نصيحة استثمارية أو توصية استثمارية. قد تؤدي الاستثمارات إلى خسائر.

الإجابة المباشرة

مساحة Blob هي سعة Ethereum المحدودة والمؤقتة لتوافر بيانات Blob المرتبطة بالكتل. وهي ليست مساحة تنفيذ EVM، ولا تخزين عقد، ولا نظام ملفات دائم، ولا رمزا مميزا. تحتوي معاملة النوع 3 على تجزئات محددة الإصدار؛ وتنتقل بيانات Blob الموثقة عبر ملفات جانبية في طبقة الإجماع أو أعمدة بيانات PeerDAS. تستطيع EVM فحص التجزئة محددة الإصدار والتحقق من نقطة مفتوحة، لكنها لا تستطيع قراءة حمولة Blob مباشرة.

يوسع PeerDAS بيانات Blob بترميز محو، ويقسم المصفوفة الموسعة إلى 128 columns، ويتيح للعقد حيازة عينات فرعية وفحصها بدلا من إلزام كل عقدة بتنزيل كل Blob كاملا. يدعم ذلك حكما محليا احتماليا على التوافر، لا إثباتا لصحة تنفيذ Rollup أو نهائية Ethereum أو سلامة الجسر أو الاسترجاع الدائم. تتغير السعة حسب التفرع. في 2026-08-13، يستهدف Ethereum mainnet بعد Fusaka BPO2 مقدار 14 blobs per block ويسمح بحد أقصى 21، بينما تقتصر كل معاملة Blob على 6 blobs.

آلية العمل

  1. ثبّت الشبكة والكتلة أو الخانة والتفرع النشط وجدول Blob-Parameter-Only، إلى جانب Rollup وإصدار الاشتقاق. لا يجوز تبادل معاملات 3/6 التاريخية، أو 6/9 في Pectra، أو 14/21 الحالية، أو معاملات شبكة اختبار أو تفرع مستقبلي.
  2. حدد عنصر النشر: معاملة النوع 3، والتجزئات محددة الإصدار، والتزامات KZG وإثباتاتها، وفهارس Blob، وأصل L1، وما إذا كان Rollup قد استخدم Blob في Ethereum فعلا لا calldata أو توافر بيانات بديلا. يربط الالتزام البيانات، لكنه لا يثبت وحده أن البايتات كانت متاحة.
  3. افصل الوحدات. يحتوي Blob واحد على 4,096 field elements * 32 bytes = 131,072 encoded bytes؛ وتستخدم الحمولة غير المقيدة عادة 31 bytes لكل عنصر حقل، أي 126,976 usable bytes. الضغط والتأطير والحشو وغاز Blob والخلايا الموسعة بترميز المحو وبايتات التطبيق كميات مختلفة.
  4. تحقق من حدود الجدول. يوجه الهدف رد فعل التسعير، وليس سعة محجوزة. والحد الأقصى للكتلة سقف إجماع لا إنتاجية متوقعة. يختلف حد PeerDAS البالغ 6 blobs per transaction عن الحد الأقصى الحالي 21 blobs per block.
  5. تحقق من مسار التوافر. يستخدم PeerDAS توسعة محو أحادية البعد، وخلايا وأعمدة موثقة، وبثا وطلبات من الأقران. تفحص العقدة ما لا يقل عن 8 columns بالمعاملات الحالية وتتحمل واجبات حيازة؛ ويتيح الحصول على 64 of 128 columns على الأقل إعادة بناء المصفوفة الموسعة.
  6. تتبع حالات دورة الحياة منفصلة: إدراج الالتزام، والحصول على أعمدة البيانات والتحقق منها، ونجاح فحص DA المحلي، وأمان كتلة L1 أو نهائيتها، وفك دفعة Rollup واشتقاقها، وسريان نافذة الخدمة الدنيا، واختبار أرشيف مستقل. لا يجعل التوافر كل حالة لاحقة صحيحة.
  7. اختبر غياب الأعمدة، أو حجب الرؤية أو انقسام الشبكة، وتأخر الانتشار، وإعادة تنظيم L1، وعدم تطابق الجدول أو العميل، وترقية صيغة Rollup، وفقدان الأرشيف. استرجع البيانات اللازمة وأعد بناءها واحفظها قبل انقضاء نافذة البروتوكول، واستخدم موضوع رسوم Blob المنفصل لمحاسبة تكلفة ناشر الدفعة والمستخدم.

أمثلة محلولة

  • وحدات بايت Blob واحد. السعة المرمزة هي 4,096 * 32 = 131,072 bytes = 128 KiB. والحمولة الاعتباطية العامة هي 4,096 * 31 = 126,976 bytes = 124 KiB. الفرق 4,096 bytes، أي 3.125% من السعة المرمزة؛ ويقلل ضغط Rollup وتأطيره حمولة التطبيق أكثر.
  • السعة الحالية لكل كتلة. عند الهدف، تكون 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. تغير الخانات الفائتة والإدراج الفعلي الإجمالي المحقق، ولا تمثل نافذة الخدمة وعدا بأرشيف دائم.

المخاطر

  • تطبيق تفرع أو جدول Blob-Parameter-Only قديم.
  • خلط حدود mainnet أو شبكة اختبار أو شبكة أخرى.
  • اعتبار الهدف سعة مضمونة أو محجوزة.
  • اعتبار الحد الأقصى إنتاجية متوقعة اعتيادية.
  • الخلط بين حد ست وحدات Blob للمعاملة وحد الكتلة.
  • الخلط بين الوحدات المرمزة والقابلة للاستخدام والمضغوطة والمؤطرة وغاز Blob.
  • إغفال الحشو أو مصروف صيغة Rollup.
  • تصنيف calldata أو DA بديل على أنه مساحة Blob في Ethereum.
  • قبول تجزئة محددة الإصدار لا تطابق التزام Blob.
  • اعتبار فتح KZG صالحا دليلا على توافر البايتات.
  • اعتبار أخذ العينات تنزيلا محليا كاملا لكل Blob.
  • الخلط بين توافر البيانات وصحة انتقال الحالة.
  • الخلط بين فحص DA محلي ونهائية L1 أو Rollup.
  • فقدان الأعمدة بسبب التأخير أو الحجب أو الانقسام أو ترابط الأقران.
  • فشل إعادة البناء أو طلب الأقران رغم السعة الاسمية.
  • فقدان الالتزام أو إعادة ترتيبه في إعادة تنظيم L1.
  • انتهاء نافذة الخدمة الدنيا قبل الاشتقاق أو الطعن.
  • الاعتماد على أرشيف أو مفهرس غير متاح أو تالف أو ناقص.
  • فشل اشتقاق Rollup بعد ترقية الضغط أو البروتوكول.
  • افتراض سلامة الجسر أو الخروج لمجرد توافر بيانات Blob.

مفاهيم خاطئة شائعة

  • مساحة Blob تخزين دائم تستطيع العقود قراءته مثل calldata.
  • كل بايت في Blob بحجم 128 KiB حمولة تطبيق غير مقيدة.
  • تنزل كل عقدة Ethereum كل Blob كاملا وتحفظه دائما في PeerDAS.
  • يثبت التزام KZG أو نجاح العينة أو نهائية الإدراج صحة حالة Rollup وقدرة المستخدم على الخروج.
  • سعة mainnet ثابتة دائما عند 3/6 أو 6/9 أو الجدول الحالي 14/21.

موضوعات ذات صلة

المصادر

التنقل

ابحث في الويكي...