توافر البيانات
توافر البيانات (DA) هو الضمان بأن بيانات المعاملات الكامنة وراء حالة الـ rollup منشورة في مكان يمكن لأي شخص قراءته — بحيث يستطيع أي شخص أن يعيد بناء حالة الـ rollup ويتحقق منها بشكل مستقل. يدعم الـ RDK ثلاثة أنظمة خلفية لتوافر البيانات.
| النظام الخلفي | ما هو |
|---|---|
native | تخزين الـ blobs على السلسلة داخل QoreChain نفسها |
celestia | توافر البيانات عبر IBC إلى Celestia، وهي طبقة DA معيارية مخصصة |
both | الجمع بين native و Celestia معاً، من أجل التكرار |
أنظمة توافر البيانات الخلفية جزء من الـ RDK الذي يتطور بنشاط. تعامل مع ملاحظات النضج أدناه على أنها نية تصميمية وتحقق منها على الشبكة التجريبية qorechain-diana قبل الاعتماد على أي نظام خلفي في الإنتاج.
التوافر الأصلي (native) — تخزين الـ blobs على السلسلة
يخزّن التوافر الأصلي بيانات معاملات الـ rollup على شكل blobs مباشرة على QoreChain. يُلتزَم بكل blob ويكون قابلاً للعنونة بحيث يمكن استرجاع البيانات الكامنة وراء دفعة التسوية والتحقق منها على السلسلة.
المفاهيم الأساسية:
- الـ Blobs. تُنشَر بيانات معاملات الـ rollup على شكل blobs لتوافر البيانات، كل منها مرتبط بمعرّف rollup وفهرس blob.
- الالتزامات (Commitments). يحمل كل blob التزاماً (تجزئة لبيانات الـ blob) بحيث يمكن التحقق من الـ blob مقابل ما تم الالتزام به، دون الوثوق بمن خزّنه.
- مساحات الأسماء (Namespaces). يمكن أن تحمل الـ blobs مساحة أسماء خاصة بالـ rollup، بما يبقي بيانات كل rollup مفصولة منطقياً ضمن تخزين مشترك.
- الاحتفاظ والتقليم (Retention and pruning). يُحتفَظ بالـ blobs الأصلية لفترة محدودة ثم تُقلَّم للحفاظ على استدامة التخزين على السلسلة. بعد التقليم، تُزال بيانات الـ blob الخام بينما يُحتفَظ ببيانات التعريف الخاصة بالالتزام، بحيث يبقى الالتزام التاريخي قابلاً للتحقق رغم أن البايتات لم تعد مخزَّنة على السلسلة.
يخضع الحد الأقصى الدقيق لحجم الـ blob ونافذة الاحتفاظ لمعاملات الوحدة الحية. استعلم عنها قبل أن تصمّم اعتماداً على أي حد محدد:
qorechaind query rdk config
التوافر الأصلي هو الخيار الأبسط — فهو يبقي كل شيء داخل QoreChain، موروثاً أمن السلسلة المضيفة والتشفير المقاوم للحوسبة الكمومية، مقابل استهلاك تخزين السلسلة المضيفة.
توافر Celestia (IBC إلى Celestia)
يقوم النظام الخلفي celestia بنشر توافر البيانات عبر IBC إلى Celestia، وهي شبكة DA معيارية مخصصة. وهذا ينقل تخزين الـ blobs عن QoreChain إلى طبقة DA مبنية لهذا الغرض مع الإبقاء على ترسيخ التسوية على QoreChain.
توافر Celestia تكامل في طور النضج. في الإصدار الحالي ينبغي التعامل معه على أنه غير مهيّأ بعد للإنتاج — تحقق من سلوكه على الشبكة التجريبية، وفضّل native أو both حيثما تحتاج إلى ضمان مستقر اليوم.
كلاهما (التكرار)
يكتب النظام الخلفي both إلى native و Celestia معاً، مما يوفر تكراراً عبر مخزن على السلسلة وطبقة DA معيارية خارجية. اختر both عندما تريد أوسع سطح توافر وتكون مستعداً لتحمّل تكلفة تخزين البيانات في مكانين.
ولأن مسار Celestia ما زال في طور النضج، تعامل مع both على أنه native-مع-تكرار-قيد-الإنجاز بدلاً من ضمان بأن نسختين مستقلتين تماماً مستقرّتان اليوم. تأكد من السلوك الحالي على الشبكة التجريبية.
اختيار نظام خلفي
| إذا كنت تريد... | اختر |
|---|---|
| الخيار الأبسط والمعتمد بالكامل على السلسلة والموروث لأمن QoreChain | native |
| نقل DA إلى طبقة معيارية مخصصة (في طور النضج) | celestia |
| أقصى سطح توافر مع التكرار (في طور النضج) | both |
لمعرفة كيف يندرج DA ضمن صورة التسوية الأوسع، راجع نظرة عامة على الـ Rollups. وللاطلاع على مرجع الوحدة منخفض المستوى، راجع صفحة مجموعة تطوير الـ Rollup.