ما لفت انتباهي في وثائق Dusk ليس طبقة الخصوصية — بل مدى صِغَر الوحدة الذرّية للمعاملة على L1 حتى الآن.

يحمل نموذج المعاملات الحالي في Dusk إجراءً واحدًا اختياريًا فقط: تحويل، أو مذكرة، أو استدعاء عقد، أو نشر، أو blob. تقترح مسألة Rusk في يونيو 2026 معاملات مجمّعة، لأن النوايا التي تتضمن عدة خطوات للمستخدم يتعين حاليًا تقسيمها إلى معاملات منفصلة، يتم توقيع كل واحدة منها بشكل مستقل ويُشترط إدراجها.

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

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

وهناك ملاحظة دقيقة مهمة: يدعم DuskVM استدعاءات عبر العقود، لذا فإن التركيب على مستوى التطبيقات ممكن بالفعل. الفجوة التي أراقبها هي التماسك الذري للمعاملة على المستوى الأدنى، وليس ما إذا كان بإمكان Dusk تشغيل عقود معقدة.

بالنسبة لي، هذه مفاضلة مثيرة للاهتمام: Dusk تتجه نحو تمويل منظَّم وقابل للبرمجة، بينما ما يزال أحد بدائله الأساسية للمعاملة بسيطًا عمدًا.

أتساءل ما إذا كانت المجمّعات الأصلية ستصبح جزءًا من البروتوكول — أم أن Dusk ستبقي هذا التعقيد داخل العقود وأوْساط التنفيذ.

@Dusk $DUSK #dusk