#dusk $DUSK @Dusk
ذكرت إعلانية شبكة Dusk في يونيو 2025 أن DuskEVM (المبني على OP Stack) يتجاوز نافذة الأعطال المعتادة التي تستمر 7 أيام، لأن DuskDS يشغّل مُسبق تحقق مدعومًا بمعالج MIPS يقوم بفحص انتقالات الحالة قبل أن تصل إلى السلسلة. هذه من منشورهم الخاص بالمدونة، المرتبط بـ $DUSK ، و #dusk، و @Dusk.
الصفحة الحالية الخاصة بالوثائق على DuskEVM، على docs.dusk.network، لا تكرر ذلك. فهي تصف دورة حياة rollup قياسية بدلًا من ذلك — المُرتِّب (sequencer)، ثم المُجمِّع (batcher)، ثم "التزامات الحالة وإثباتات الأعطال" التي تربط التنفيذ مرة أخرى بـ Dusk DS — وتُحذّر صراحةً: لا تستنتج الحتمية (finality) من مرور الوقت، بل استخدم حالة البروتوكول أو حالة المحفظة. هذا التحذير هو ما تتوقعه من سلسلة لا تزال لديها نافذة تحدّي، وليس من سلسلة أزالتها.
حاولت التحقق مما إذا كانت صفحة الوثائق تسبق الإعلان، ما من شأنه تفسير ذلك على أنه وثائق قديمة وليست تناقضًا مباشرًا. لم أتمكن من الحصول على طابع زمني لتلك الصفحة تحديدًا — إذ إن موقع الوثائق يتم توليده من مستودع GitHub تتم صيانته بنشاط، لكنني لم أستطع سحب سجل الالتزامات (commit history) الخاص به. لذا فالأمر الذي لدي فعليًا أضيق من "Dusk تتناقض مع نفسها": بل إن مصدرين رسميين يصفان نماذج حتمية مختلفة، ولا أستطيع حاليًا تحديد أيهما يحكم DuskEVM اليوم.
الخطوة التالية التي سأتحقق منها: سجل التزامات مستودع الوثائق لصفحة DuskEVM، أو عقد الجسر نفسه، لمعرفة ما إذا كانت فترة التحدّي تُفرض على السلسلة (on-chain).