قضيت هذا الصباح في مراجعة كيفية انتقال معاملة duskevm فعليًا عبر النظام، وبصراحة؟ 😂 كنت أظن أنه بمجرد ظهورها في بلوك أصبحت الأمور انتهت بالنسبة لي، لكن اتضح أن ذلك ليس صحيحًا تمامًا.

لذا، duskevm هي الطبقة المتوافقة مع EVM على Dusk. يعني أنك تكتب Solidity، وتستخدم محافظ EVM العادية وأدوات قياسية مثل Foundry أو Hardhat، وتدفع الغاز باستخدام Dusk طوال الوقت. لكن المعاملة لا تعيش وتموت على duskevm وحدها. بل تمر عبر دورة حياة على نمط الـ rollup. أولًا يتم إرسالها إلى sequencer الخاص بـ duskevm، ثم يتم إدراجها في بلوك L2 بسرعة نسبيًا. بعد ذلك يقوم batcher بنشر بيانات المعاملة على duskds، وهي طبقة التسوية الفعلية وavailability للبيانات في Dusk. ما يربط الحالة الناتجة بالعودة إلى duskds هو الالتزامات بالحالة وإثباتات الأعطال (fault proofs)، بحيث يتم تسويتها بالفعل، وليس مجرد بقاءها في مكان ما داخل بلوك L2 منتظرة.

ما أعود إليه باستمرار هو جملة في التوثيق تشير إلى أن الإدراج (inclusion) والتسوية (settlement) هما مرحلتان مختلفتان فعلاً. وأن التطبيقات التي تنقل قيمة بين duskevm وDusk L1 يجب أن تتحقق من حالة البروتوكول أو حالة المحفظة بدلًا من افتراض أن كل شيء نهائي فقط لأن الوقت قد مر. هذه ليست مجرد تفصيلة تقنية.

لم أجد أي مكان يوضح كم عادةً يستغرق هذا الفارق عمليًا. صحيح أن الإدراج السريع لا يعني تسوية فورية، لكنني لا أعرف النافذة الفعلية التي يجب أن ينتظرها شخص ما.

ومع ذلك، اختيار التصميم منطقي بالنسبة لي. بدلًا من بناء سلسلة EVM منفصلة تمامًا تطفو وحدها، تبقى duskevm متجذرة في duskds للتسوية وتوفّر البيانات. وبذلك تحصل على أدوات Solidity كاملة دون أن تفقد ضمانات الطبقات الأساسية حول الإنهاء النهائي (finality).

بصراحة لا أعرف إن كانت فجوة الإدراج إلى التسوية صغيرة بما يكفي لتجاهلها يوميًا، أم أن على المطورين حسابها بشكل نشط؟
🤔

#dusk @Dusk $DUSK