توافر البيانات
توافر البيانات (DA) هو الضمان بأن بيانات المعاملات الكامنة وراء حالة الـ rollup منشورة في مكان يمكن لأي شخص قراءته — بحيث يستطيع أي شخص أن يعيد بناء حالة الـ rollup ويتحقق منها بشكل مستقل. يعرّف الـ RDK ثلاثة أنظمة خلفية لتوافر البيانات؛ واليوم لا يُنفَّذ منها سوى native.
| النظام الخلفي | ما هو | الحالة |
|---|---|---|
native | تخزين الـ blobs على السلسلة داخل QoreChain نفسها | منفَّذ في الوحدة؛ لا توجد طريقة عامة لنشر blob بعد (انظر أدناه) |
celestia | توافر البيانات عبر IBC إلى Celestia، وهي طبقة DA معيارية مخصصة | غير منفَّذ |
both | الجمع بين native و Celestia معاً، من أجل التكرار | يتصرف تماماً مثل native اليوم |
لم يتم إنشاء أي rollup على أيٍّ من الشبكتين حتى الآن، وأنظمة توافر البيانات الخلفية منفَّذة جزئياً فقط. ترد حالة كل نظام خلفي أدناه؛ تحقق على الشبكة التجريبية qorechain-diana قبل الاعتماد على أي منها.
التوافر الأصلي (native) — تخزين الـ blobs على السلسلة
التوافر الأصلي هو مخزن الـ blobs على السلسلة داخل x/rdk: يُفهرَس كل blob بمعرّف الـ rollup وفهرس الـ blob، ويحمل التزام SHAKE-256 لبايتاته، ويُقلَّم بعد انتهاء نافذة الاحتفاظ مع الإبقاء على التزامه.
تعرّف الوحدة تخزين الـ blobs والاحتفاظ بها وتقليمها، لكن لا توجد رسالة معاملة لنشر blob في الإصدارات الحالية. وإلى أن تصدر رسالة إرسال، يجب أن تترك دفعة التسوية الحقل data_hash فارغاً — فالدفعة التي تسمّي تجزئة بيانات على rollup من نوع native أو both تُرفض لأنه لا يمكن تخزين blob مطابق لها.
المفاهيم الأساسية:
- الـ Blobs. يرتبط الـ blob بمعرّف rollup وفهرس blob.
- الالتزامات (Commitments). يحمل كل blob التزام SHAKE-256 بطول 32 بايت لبياناته، بحيث يمكن التحقق من الـ blob مقابل ما تم الالتزام به، دون الوثوق بمن خزّنه. (تستخدم الدالة المساعدة
buildDaBlob()في TypeScript حالياً SHA-256 في التجزئة، لذا فإنdataHashالخاص بها لا يطابق التزام السلسلة.) - مساحات الأسماء (Namespaces). يمكن أن تحمل الـ blobs مساحة أسماء خاصة بالـ rollup، بما يبقي بيانات كل rollup مفصولة منطقياً ضمن تخزين مشترك.
- الاحتفاظ والتقليم (Retention and pruning). يُحتفَظ بالـ blobs الأصلية لمدة
blob_retention_blocks(432,000 كتلة — نحو 16 يوماً عند زمن الكتلة الحالي للشبكة الرئيسية البالغ ≈3.2 ثانية؛ ويتغير هذا الرقم مع زمن الكتلة) ثم تُقلَّم للحفاظ على استدامة التخزين على السلسلة. بعد التقليم، تُزال بيانات الـ blob الخام بينما يُحتفَظ ببيانات التعريف الخاصة بالالتزام، بحيث يبقى الالتزام التاريخي قابلاً للتحقق رغم أن البايتات لم تعد مخزَّنة على السلسلة.
يخضع الحد الأقصى لحجم الـ blob ونافذة الاحتفاظ لمعاملات الوحدة الحية. استعلم عنها قبل أن تصمّم اعتماداً على أي حد محدد:
qorechaind query rdk config
توافر Celestia (IBC إلى Celestia)
توافر Celestia غير منفَّذ. لا يمكن للـ rollup الذي يكون نظامه الخلفي للتوافر celestia نشر البيانات (تُرجع الوحدة خطأً). يقوم التصميم المخطَّط له بنشر توافر البيانات عبر IBC إلى Celestia، وهي شبكة DA معيارية مخصصة، مع الإبقاء على ترسيخ التسوية على QoreChain؛ ولا توجد قناة IBC على أيٍّ من الشبكتين اليوم (انظر بنية الجسر). استخدم native.
كلاهما (التكرار)
يُقصد بالنظام الخلفي both أن يكتب إلى native و Celestia معاً. واليوم يتصرف both تماماً مثل native: لا تُخزَّن سوى النسخة الأصلية، ويُتخطّى النصف الخاص بـ Celestia مع تسجيل تحذير. لا تتعامل معه على أنه نسختان مستقلتان.
اختيار نظام خلفي
| إذا كنت تريد... | اختر |
|---|---|
| الخيار الأبسط والمعتمد بالكامل على السلسلة والذي يرث أمن QoreChain | native |
| نقل DA إلى طبقة معيارية مخصصة | celestia — غير منفَّذ |
| التكرار عبر مخزنين | both — مثل native اليوم |
لمعرفة كيف يندرج DA ضمن صورة التسوية الأوسع، راجع نظرة عامة على الـ Rollups. وللاطلاع على مرجع الوحدة منخفض المستوى، راجع صفحة مجموعة تطوير الـ Rollup.