#dusk $DUSK اليوم كنت أقرأ وثائق شبكة الاختبار DuskEVM لـ @Dusk. في البداية ظننت أنها تعني: "دسـك أخيرًا تدعم Solidity" — طبقة توافق EVM قياسية، يمكن للمطورين نقل عقود الإيثيريوم وتشغيلها ببساطة. لكن عندما رأيت في مخطط البنية علاقة DuskEVM بـ DuskDS، أدركت أن الأمر ليس بهذه البساطة.
يُبنى DuskEVM على OP Stack، ويستخدم واجهة JSON-RPC القياسية الخاصة بالإيثيريوم، ومعرّف السلسلة Chain ID745، ورمز الغاز ما زال هو $DUSK . يمكن للمطورين نشر العقود باستخدام Foundry أو Hardhat، ومتصفح شبكة الاختبار أيضًا هو Blockscout. على السطح، يبدو الأمر مشابهًا لأي سلسلة أخرى مبنية على OP Stack.
لكن النقطة الجوهرية هي أن DuskEVM لا يتولى بنفسه التسوية وDA. فهو ينقل التنفيذ إلى طبقة EVM، بينما تُترك التسوية وإتاحة البيانات إلى DuskDS — أي طبقة الإجماع والنهائية في Dusk L1. وهذا يعني أن عقود EVM تعمل داخل بيئة توافق، لكن الحالة النهائية يتم قفلها وفق إجماع Succinct Attestation الخاص بـ DuskDS؛ أي أنها تتمتع بنهائية حتمية، وليست مجرد تأكيد احتمالي.
وأشبه الأمر بفتح متجر بمواصفات مماثلة في قلب المدينة ليس في نفس مركز التسوق، بل باستخدام نظام الكاشير نفسه الذي يعرفه الجميع (EVM). لكن في النهاية، كل عملية محاسبة تذهب إلى الخزنة الرئيسية (DuskDS) لتُصفّى. يشعر العميل أنه لا يوجد فرق، بينما يهتم التدقيق والامتثال بسجلّ الحسابات في المقر الرئيسي، وليس بذاكرة الكاشير.
هناك قيد سهل أن يُتغافل: يتصل DuskEVM وDusk L1 عبر bridge. و DUSK هو أصل واحد في نظامي الحساب على الجانبين، لكن التحويل عبر الطبقات يتطلب عملية bridge. فإذا كانت سيولة bridge غير كافية أو كانت التأخيرات عالية جدًا، فسوف تتراجع تجربة DeFi على طبقة EVM. حاليًا، في مرحلة شبكة الاختبار، لا تتوفر بيانات كثيرة عن السعة الفعلية والتأخير الخاص بـ bridge. @Dusk
لذلك عند النظر إلى خطوة#dusk من حيث EVM، سأركز على كمية نشر العقود الفعلية على شبكة الاختبار، وتوزيع تأخيرات bridge، وتكلفة الاحتكاك في انتقال الأصول بين DuskEVM و Dusk L1. $DUSK لا يعني مجرد وجود مدخل EVM أن المطورين سيأتون—العبرة فيما إذا كانوا سيتمكنون من البقاء بعد المجيء.