مجموعة تطوير الـ Rollup
توفّر وحدة x/rdk مجموعة شاملة لتطوير الـ Rollup (RDK) تتيح للمطورين نشر عمليات rollup خاصة بالتطبيقات على QoreChain. وهي تدعم أربعة نماذج للتسوية، وأوضاع متعددة للمُسلسِل (sequencer)، وخلفيات قابلة للتوصيل لإتاحة البيانات، وتحسينًا للإعداد بمساعدة الذكاء الاصطناعي.
نماذج التسوية
تدعم QoreChain RDK أربعة أوضاع متمايزة للتسوية — optimistic وzk وbased وsovereign — لكل منها افتراضات ثقة مختلفة، وخصائص نهائية مختلفة، ومتطلبات إثبات مختلفة.
التسوية التفاؤلية (Optimistic)
تفترض عمليات الـ rollup التفاؤلية أن المعاملات صحيحة افتراضيًا وتعتمد على إثباتات الاحتيال لحل النزاعات.
- نظام الإثبات: إثباتات احتيال تفاعلية
- نافذة الطعن: 7 أيام (604,800 ثانية)، قابلة للإعداد لكل rollup
- سند الطعن: 1,000 QOR (1,000,000,000 uqor) — مطلوب لتقديم طعن بإثبات احتيال
- النهائية: مؤجلة حتى انتهاء نافذة الطعن دون وجود طعن صحيح
- النهائية التلقائية: يُنهي الـ
EndBlockerالدفعات تلقائيًا بمجرد انقضاء نافذة الطعن دون نزاع
دورة حياة الدفعة:
Submitted → [challenge window expires] → Finalized
Submitted → [fraud proof submitted] → Challenged → Rejected
تسوية ZK (المعرفة الصفرية)
توفّر عمليات الـ rollup من نوع ZK إثباتات صحة تشفيرية تضمن صحة الانتقال بين الحالات.
- نظام الإثبات: SNARK (Groth16، PLONK) أو STARK (شفّاف، دون إعداد موثوق)
- النهائية: فورية عند التحقق من الإثبات — لا حاجة لنافذة طعن
- الحد الأقصى لحجم الإثبات: 1 MB (1,048,576 بايت)
- عمق التكرار: عمق تجميع الإثباتات قابل للإعداد (الافتراضي: 1)
- مستوى النضج: في الإصدار الحالي، تستخدم تسوية ZK تحققًا وهميًا (stub) يقبل أي إثبات غير فارغ. أما التحقق الكامل من إثباتات SNARK/STARK فهو ترقية مخطّطة وينبغي اعتباره غير مهيأ بعد للإنتاج.
دورة حياة الدفعة:
Submitted + valid proof → Finalized (instant)
التسوية المعتمدة على الطبقة الأولى (Based)
تفوّض عمليات الـ rollup من نوع based تسلسل المعاملات إلى مقترحي الطبقة الأولى (QoreChain)، فترث ضمانات الحيوية ومقاومة الرقابة الخاصة بالسلسلة المضيفة.
- نظام الإثبات: لا يلزم — مقترحو الطبقة الأولى هم مصدر الحقيقة
- المُسلسِل: يجب استخدام وضع المُسلسِل
based(مفروض عبر التحقق) - النهائية: تأكيد بكتلتين على QoreChain
- تأخير الإدراج: عدد كتل قابل للإعداد قبل الإدراج القسري لمعاملات الـ rollup
- مشاركة رسوم الأولوية: نسبة قابلة للإعداد من رسوم الأولوية تُدفع لمقترحي الطبقة الأولى
دورة حياة الدفعة:
Submitted → [2 L1 blocks] → Finalized (auto)
التسوية السيادية (Sovereign)
تعمل عمليات الـ rollup السيادية بإجماع مستقل وتُسلسل معاملاتها ذاتيًا. وهي تربط حالتها بـ QoreChain لإمكانية التحقق، لكنها لا تعتمد على السلسلة المضيفة في النهائية.
- نظام الإثبات: لا يوجد
- النهائية: مستقلة — يحددها إجماع الـ rollup الخاص
- ربط الحالة: تُنشر جذور الحالة إلى QoreChain من أجل الشفافية وإمكانية التحقق، لكنها لا تُفرض
- النهائية التلقائية: لا توجد — تدير عمليات الـ rollup السيادية نهائيتها بنفسها
توافق أنظمة الإثبات
| وضع التسوية | إثباتات الاحتيال | SNARK | STARK | لا يوجد |
|---|---|---|---|---|
| Optimistic | مطلوب | -- | -- | -- |
| ZK | -- | مدعوم | مدعوم | -- |
| Based | -- | -- | -- | مطلوب |
| Sovereign | -- | -- | -- | مطلوب |
لا يزال التحقق من STARK ومن إثباتات ZK الكاملة قيد النضج؛ راجع ملاحظة مستوى النضج الخاصة بـ تسوية ZK أعلاه.
ملفات الإعداد الجاهزة (Preset Profiles)
تأتي RDK مع خمسة ملفات إعداد جاهزة توفّر إعدادات rollup جاهزة للاستخدام ومحسّنة لحالات الاستخدام الشائعة. ويجمع كل ملف بين نموذج تسوية، ووضع مُسلسِل، وخلفية لإتاحة البيانات، ونموذج غاز، وآلة افتراضية (VM) مضبوطة لمجالها المستهدف:
| الملف | التسوية (الإثبات) | المُسلسِل | DA | نموذج الغاز | VM | حالة الاستخدام المستهدفة |
|---|---|---|---|---|---|---|
defi | zk (SNARK) | dedicated | native | EIP-1559 | EVM | تطبيقات التداول والإقراض وتطبيقات نمط AMM |
gaming | based | based | native | flat | custom | حالة لعب وأنشطة اقتصادية داخل الألعاب بإنتاجية عالية وزمن وصول منخفض |
nft | optimistic (fraud) | dedicated | native (Celestia DA planned) | standard | CosmWasm | سكّ الـ NFT والأسواق والمقتنيات الرقمية |
enterprise | based | based | native | subsidized | EVM | عمليات نشر بصلاحيات محدّدة وللاتحادات مع رسوم مدعومة |
custom | معاملات قابلة للتخصيص بالكامل | معاملات قابلة للتخصيص بالكامل | معاملات قابلة للتخصيص بالكامل | معاملات قابلة للتخصيص بالكامل | معاملات قابلة للتخصيص بالكامل | كل حقل يحدّده المستخدم |
يترك ملف custom كل حقل لك لتضبطه. يمكن أن تتطور القيم الدقيقة المجمّعة في كل ملف جاهز مع نضج الـ RDK؛ استعلم عن الإعداد الحيّ باستخدام qorechaind query rdk config (أو RdkClient.params() من @qorechain/rdk) للحصول على المعلمات الموثوقة لكل ملف جاهز، ولاحظ أن تسوية based تقترن دائمًا بوضع المُسلسِل based.
أوضاع المُسلسِل
يحدد المُسلسِل من يرتّب المعاملات داخل كتلة الـ rollup.
المُسلسِل المخصّص (Dedicated)
يقوم مشغّل واحد بتسلسل جميع معاملات الـ rollup.
- المشغّل: عنوان واحد مُعيَّن
- زمن الوصول: أدنى ما يمكن — ترتيب من طرف واحد
- الثقة: يتطلب الثقة بمشغّل المُسلسِل لضمان الحيوية والترتيب العادل
المُسلسِل المشترك (Shared)
تقوم مجموعة من المُسلسِلات بترتيب المعاملات جماعيًا.
- الحد الأدنى لحجم المجموعة: قابل للإعداد (الافتراضي: 1)
- زمن الوصول: أعلى قليلًا بسبب التنسيق متعدد الأطراف
- الثقة: موزّعة عبر مجموعة المُسلسِلات
المُسلسِل المعتمد على الطبقة الأولى (Based)
يقوم مقترحو الطبقة الأولى في QoreChain بتسلسل معاملات الـ rollup.
- تأخير الإدراج: عدد كتل قابل للإعداد قبل الإدراج القسري (الافتراضي: 10)
- حصة رسوم الأولوية: نسبة قابلة للإعداد من رسوم الأولوية تُدفع لمقترحي الطبقة الأولى
- الثقة: ترث أمان مجموعة المدققين في QoreChain ومقاومة الرقابة
- المتطلّب: يتطلب وضع التسوية based المُسلسِل من نوع based (مفروض عند التحقق)
خلفيات إتاحة البيانات
Native DA
تخزين الـ blob في متجر KV على السلسلة داخل QoreChain نفسها.
| المعلمة | القيمة |
|---|---|
| الحد الأقصى لحجم الـ blob | 2 MB (2,097,152 بايت) |
| مدة الاحتفاظ | 432,000 كتلة (~30 يومًا عند كتل من 6 ثوانٍ) |
| التقليم التلقائي | تُقلَّم الـ blob المنتهية في الـ EndBlocker — تُزال البيانات لكن يُحتفظ ببيانات الالتزام التعريفية |
| الالتزام | تجزئة SHA-256 لبيانات الـ blob |
Celestia DA
إتاحة بيانات قائمة على IBC باستخدام طبقة DA المخصّصة من Celestia.
- الحالة: وهمية (stub) في الإصدار الحالي — تُرجع خطأً إذا اختيرت كخلفية وحيدة
- دعم مساحات الأسماء: مساحات الأسماء الخاصة بكل rollup مدعومة في مخطط الـ blob
- مخطّط لاحقًا: تكامل IBC كامل مع تقديم الـ blob والتحقق منه في Celestia
كلاهما (احتياطي)
يخزّن الـ blob على خلفيتي Native وCelestia في آنٍ واحد.
- في الإصدار الحالي، يُخزَّن الـ blob الأصلي (native) فعليًا فقط؛ ويُسجَّل تحذير بشأن مكوّن Celestia.
دورة حياة الـ Rollup
Pending → Active → Paused → Active → Stopped
↑ |
└──────────────────┘
(can resume from paused,
stopped is permanent)
| الحالة | الوصف |
|---|---|
| Pending | الـ rollup مُسجَّل لكنه لم يُفعَّل بعد |
| Active | الـ rollup حيّ ويعالج الدفعات |
| Paused | متوقف مؤقتًا من قبل المُنشئ (يمكن استئنافه) |
| Stopped | مُوقَف نهائيًا — يُعاد سند الحصة إلى المُنشئ |
عند الإنشاء، تُضبط حالة الـ rollup إلى Active فور نجاح حجز الحصة في الضمان وتسجيل الطبقة.
دورة حياة الدفعة
تتتبّع دفعات التسوية تقدّم حالة جذور حالة الـ rollup:
Submitted → Finalized (happy path)
Submitted → Challenged → Rejected (fraud detected)
| الحالة | الوصف |
|---|---|
| Submitted | الدفعة مُرسَلة إلى QoreChain، في انتظار النهائية |
| Challenged | تم تقديم طعن بإثبات احتيال (للتفاؤلية فقط) |
| Finalized | قُبلت الدفعة كقيمة معتمدة (canonical) |
| Rejected | بُطلت الدفعة بسبب طعن ناجح |
قواعد النهائية التلقائية
| وضع التسوية | محفّز النهائية |
|---|---|
| Optimistic | انتهاء نافذة الطعن (~7 أيام) دون طعن صحيح |
| ZK | فورية عند تقديم إثبات صحيح |
| Based | كتلتان على الطبقة الأولى بعد التقديم |
| Sovereign | لا يوجد — يُدار عبر إجماع الـ rollup الخاص |
تُنفَّذ النهائية التلقائية في الـ EndBlocker لعمليات الـ rollup التفاؤلية والمعتمدة على الطبقة الأولى. أما دفعات ZK فتُنهى مباشرة أثناء تقديم الدفعة.
معلمات الوحدة
| المعلمة | الافتراضي | الوصف |
|---|---|---|
max_rollups | 100 | الحد الأقصى لعدد عمليات الـ rollup التي يمكن تسجيلها |
min_stake_for_rollup | 10,000,000,000 uqor (10,000 QOR) | الحد الأدنى للحصة المطلوبة لإنشاء rollup |
rollup_creation_burn_rate | 0.01 (1%) | نسبة حصة الإنشاء المحروقة عبر x/burn |
default_challenge_window | 604,800 ثانية (7 أيام) | نافذة الطعن التفاؤلية الافتراضية |
max_da_blob_size | 2,097,152 بايت (2 MB) | الحد الأقصى لحجم blob إتاحة البيانات |
blob_retention_blocks | 432,000 (~30 يومًا) | عدد الكتل قبل تقليم blobs الـ DA |
max_batches_per_block | 10 | الحد الأقصى لدفعات التسوية المعالَجة لكل كتلة |
التكامل متعدد الطبقات
تتكامل وحدة RDK مع x/multilayer لإدارة الحالة عبر الطبقات:
تسجيل الطبقة
عند إنشاء rollup، يُسجَّل تلقائيًا كطبقة سلسلة جانبية عبر RegisterSidechain. ويتضمن التسجيل:
- معرّف الطبقة (يطابق معرّف الـ rollup)
- زمن الكتلة المستهدف والحد الأقصى للمعاملات لكل كتلة
- أنواع الـ VM والمجالات المدعومة
- فترة التسوية
التسجيل غير حاسم (non-fatal): إذا فشل تسجيل x/multilayer، يُنشأ الـ rollup مع ذلك ويُسجَّل تحذير.
ربط الحالة
تُربط كل دفعة تسوية مُرسَلة إلى الـ RDK بـ x/multilayer عبر AnchorState. وهذا يسجّل:
- معرّف الطبقة وارتفاع الطبقة (فهرس الدفعة)
- جذر الحالة
- عدد المعاملات
الربط غير حاسم (non-fatal): تُسجَّل حالات الفشل لكنها لا تمنع معالجة الدفعة.
التكامل مع الحرق
عند إنشاء الـ rollup، يُحرق 1% من مبلغ الحصة عبر وحدة x/burn من خلال قناة الحرق rollup_create. على سبيل المثال، إنشاء rollup بالحصة الدنيا البالغة 10,000 QOR يحرق 100 QOR نهائيًا. وتُحتجز الـ 9,900 QOR المتبقية في الضمان وتُعاد عند إيقاف الـ rollup.