كلما تعمّقت في “Dusk”، قلّ اهتمامي بفكرته، إذ تبدو ببساطة كـ “طبقات تنفيذ متعددة”.

الجزء الذي يظل بارزًا بالنسبة إليّ هو ما تختار Dusk الإبقاء عليه تحت تلك الطبقات.

يمكن لـ DuskEVM تزويد المطورين بالبيئة التي يفهمونها بالفعل. ويمكن لـ DuskVM التعامل مع التطبيقات التي تحتاج إلى وصول أكثر مباشرةً إلى L1 وإمكانياته الأصلية. لكن لا يصبح أيٌّ منهما هو السلطة النهائية. يبقى هذا الدور مع DuskDS، التي تتولى الإجماع وتوافر البيانات والتسوية.

أعتقد أن خيار التصميم هذا مهم أكثر مما يبدو للوهلة الأولى.

يعني ذلك أن Dusk يمكنها تغيير طريقة تنفيذ التطبيقات دون الحاجة إلى تغيير الطبقة المسؤولة عن تحديد ما يُعدّ في النهاية “مُستقرًّا”.

يمكنك في الواقع رؤية هذه العلاقة من خلال الجسر. إن نقل DUSK إلى DuskEVM ثم إعادته ليس مجرد نقل توكن بين واجهتين. تمر عمليات الإيداع والسحب عبر خطوات تأكيد وإثبات وإقرار نهائي منفصلة قبل اعتبار الأصل مُستقرًّا في الجهة الأخرى.

وهناك درس هنا أجد أنه من السهل تفويته.

أظهر حادث الجسر في وقتٍ سابق من هذا العام أن وجود بروتوكول أساسي يعمل لا يجعل تلقائيًا كل طبقة حوله بنفس المستوى من الأمان. يمكن للجسر أن يصبح جزءًا من الحدّ الحقيقي لأمان الأصل.

لذا فإن رؤيتي الحالية لـ Dusk أقلّ ارتباطًا بعبارة “بلوكشين الخصوصية” وأكثر ارتباطًا بهذا السؤال:

هل يمكنك الحفاظ على التسوية مستقرة بينما تتطور بيئة التنفيذ من حولها؟

#dusk $DUSK @Dusk