#dusk $DUSK في الليلة الماضية عندما كنت أتصفح مستندات Dusk، شعرت أن رقبتي بردت قليلاً.
يبدو أن التوافق مع EVM أمرٌ جميل. لكن عندما نظرت بعناية إلى آلية الخروج، شدّ ذلك قلبي—ليس بسبب “الابتزاز عبر الرسوم”، بل لأن تصميمه عميق للغاية.
تشغيل التطبيقات على جانب EVM، مع قيام L1 بالتحقق من التسوية. الخروج يتطلب ثلاث خطوات: انتظار إرسال المقترح (Output Proposal)، انتظار تقديم الدليل (Proof)، ثم انتظار انتهاء نافذة النزاع. تحقق حالة عبر الطبقات: كل طبقة يجب أن تدفع Gas. هذا ليس مجرد “رسوم مكررة”، بل يعني أن كل بوابة تحتاج إلى شراء تذكرة مستقلة. وإذا كان الرصيد غير كافٍ في أي خطوة، ستتوقف الأصول في منتصف الطريق—لا دخول ولا خروج.
أكثر ما يقلقني هو: حاليًا كل البيانات على شبكة الاختبار.
المرور عبر العملية لا يثبت سوى أن الكود يمكنه العمل. لكن بعد الإطلاق على الشبكة الرئيسية لـ @Dusk ، فإن مجموعة المدققين، وتكرار النزاعات، وتقلبات أسعار الغاز—أي متغير منها قد يحوّل “إمكانية الخروج” إلى “عدم القدرة على الخروج”. يقول فريق المشروع إنه يدعم الخروج، لكنه لم ينشر أبدًا متوسط زمن الخروج على الشبكة الرئيسية، ولم يُفصح أيضًا عن تفاصيل آلية استعادة الفشل. وإذا حدثت مشكلة فعلًا، من الذي سيساعدك في استرجاع أصولك؟ لا يوجد ذلك مكتوبًا في المستندات.
الجسور عبر الطبقات الناضجة ليست قلة أزرار، بل هي أن تجعل المستخدم يفهم كل خطوة: ماذا يحدث في كل مرحلة، وأين ذهبت الأصول، ولماذا يتعين الانتظار. في DuskEVM الحالي، المنطق على مستوى التقنية واضح، لكن المستخدم أمام “صندوق أسود”: تضغط خروجًا مرة واحدة، ثم يبدأ انتظار طويل؛ وعلى الشاشة تظهر حالات pending لا يفهمها أحد.
لا يفتقر هذا المجال إلى الرؤى التقنية، بل يفتقر إلى شيء واحد: ماذا ستفعل إذا حدث انحراف؟ عندما لا تكون آلية استعادة الفشل واضحة ومكتوبة بشأن البروتوكول، هل تراهن على التقنية أم على الحظ؟
يبدو أن التوافق مع EVM أمرٌ جميل. لكن عندما نظرت بعناية إلى آلية الخروج، شدّ ذلك قلبي—ليس بسبب “الابتزاز عبر الرسوم”، بل لأن تصميمه عميق للغاية.
تشغيل التطبيقات على جانب EVM، مع قيام L1 بالتحقق من التسوية. الخروج يتطلب ثلاث خطوات: انتظار إرسال المقترح (Output Proposal)، انتظار تقديم الدليل (Proof)، ثم انتظار انتهاء نافذة النزاع. تحقق حالة عبر الطبقات: كل طبقة يجب أن تدفع Gas. هذا ليس مجرد “رسوم مكررة”، بل يعني أن كل بوابة تحتاج إلى شراء تذكرة مستقلة. وإذا كان الرصيد غير كافٍ في أي خطوة، ستتوقف الأصول في منتصف الطريق—لا دخول ولا خروج.
أكثر ما يقلقني هو: حاليًا كل البيانات على شبكة الاختبار.
المرور عبر العملية لا يثبت سوى أن الكود يمكنه العمل. لكن بعد الإطلاق على الشبكة الرئيسية لـ @Dusk ، فإن مجموعة المدققين، وتكرار النزاعات، وتقلبات أسعار الغاز—أي متغير منها قد يحوّل “إمكانية الخروج” إلى “عدم القدرة على الخروج”. يقول فريق المشروع إنه يدعم الخروج، لكنه لم ينشر أبدًا متوسط زمن الخروج على الشبكة الرئيسية، ولم يُفصح أيضًا عن تفاصيل آلية استعادة الفشل. وإذا حدثت مشكلة فعلًا، من الذي سيساعدك في استرجاع أصولك؟ لا يوجد ذلك مكتوبًا في المستندات.
الجسور عبر الطبقات الناضجة ليست قلة أزرار، بل هي أن تجعل المستخدم يفهم كل خطوة: ماذا يحدث في كل مرحلة، وأين ذهبت الأصول، ولماذا يتعين الانتظار. في DuskEVM الحالي، المنطق على مستوى التقنية واضح، لكن المستخدم أمام “صندوق أسود”: تضغط خروجًا مرة واحدة، ثم يبدأ انتظار طويل؛ وعلى الشاشة تظهر حالات pending لا يفهمها أحد.
لا يفتقر هذا المجال إلى الرؤى التقنية، بل يفتقر إلى شيء واحد: ماذا ستفعل إذا حدث انحراف؟ عندما لا تكون آلية استعادة الفشل واضحة ومكتوبة بشأن البروتوكول، هل تراهن على التقنية أم على الحظ؟
