غالبًا ما يُحوّل رابط الصفحات (bridge) العملية إلى خط تقدم واحد، لكن عند حدوث مشكلة لا يكون كافيًا. خلف الكواليس توجد مجموعتان من الأدوار على شكل تمرير: تقوم الـ SDK بتحويل إجراءات البروتوكول إلى بيانات صحيحة، بينما تقوم المحفظة بتحديد المرحلة الحالية وإرسال المعاملة. إن فهم من يختص بأي جزء هو ما يحدد من أين نبدأ في تتبع الخطأ.
تم دمج طلب السحب الرسمي الخاص بـ web-wallet PR #947 في 7 أغسطس 2026. تشمل مسؤوليات الـ SDK بداخله: ترميز المستلم، وتحليل MessagePassed والـ hash، وتجزئة withdrawal، وتسلسل L1 prove/finalize، وكذلك ثوابت البروتوكول. أي أنها تعتني بـ "كيف تكون هذه المواد مطابقة للبروتوكول". أما جهة المحفظة فتعنى بـ "هل يمكننا الآن الانتقال إلى الخطوة التالية": فهي المسؤولة عن جلب proof، واختيار dispute-game، وإرسال W3sper، والتحكم في الوصول إلى finality، وتنظيم واجهة المستخدم.
لا يمكن أن يقتصر جسر DuskEVM رقم @Dusk على استكشاف الأعطال من خلال "نجاح أو فشل". إن كانت المشكلة في الترميز فافحص الـ SDK؛ وإن كانت المشكلة في اكتشاف proof أو حالة النضج (matured) فافحص المحفظة؛ وإن كانت المواد جاهزة لكن لم تكتمل عملية الإرسال إلى L1، فراجع إرسال المعاملة وتنظيم الواجهة. قد تختلف طريقة المعالجة تمامًا حتى لو كان خط التقدم نفسه قد توقف.
يقوم الـ PR أيضًا بحفظ معرّف معاملة Dusk الأصلي، وكذلك hash الخاصة بـ Ethereum بعد تحويل adapter. عند استكشاف الأعطال، إذا احتفظت بـ hash واحد فقط، فقد تفقد الفهرسة عند الانتقال إلى الجهة الأخرى. الأكثر عملية للمستخدم هو حفظ هويات نوعي المعاملات منذ البداية.
خلال تجربة محلية أُجراها أحد المساهمين، فإن 0.1 DUSK أدت إلى زيادة صافية نهائية في الحساب قدرها 0.097716912، وكانت تكلفة finalization gas تساوي 0.002283088 DUSK. هذا ليس قياسًا شخصيًا لدي، ولا استنتاجًا حول الرسوم والتأخير والاستقرار من شبكة اختبار عامة أو الشبكة الرئيسية. يمكن لتحديث $DUSK أن يبرهن كيف صُممت طبقات المسؤوليات وكيفية تصميم حقول التتبّع، لكنه لا يمكن أن يُغني عن ضمانات مرتبطة بالبيئة الخارجية. إن مواءمة المكونات والمراحل ونوعَي الـ hash هو ما يمنح فرصة تحويل "التعليق" إلى مشكلة يمكن تحديد موقعها. #dusk
تم دمج طلب السحب الرسمي الخاص بـ web-wallet PR #947 في 7 أغسطس 2026. تشمل مسؤوليات الـ SDK بداخله: ترميز المستلم، وتحليل MessagePassed والـ hash، وتجزئة withdrawal، وتسلسل L1 prove/finalize، وكذلك ثوابت البروتوكول. أي أنها تعتني بـ "كيف تكون هذه المواد مطابقة للبروتوكول". أما جهة المحفظة فتعنى بـ "هل يمكننا الآن الانتقال إلى الخطوة التالية": فهي المسؤولة عن جلب proof، واختيار dispute-game، وإرسال W3sper، والتحكم في الوصول إلى finality، وتنظيم واجهة المستخدم.
لا يمكن أن يقتصر جسر DuskEVM رقم @Dusk على استكشاف الأعطال من خلال "نجاح أو فشل". إن كانت المشكلة في الترميز فافحص الـ SDK؛ وإن كانت المشكلة في اكتشاف proof أو حالة النضج (matured) فافحص المحفظة؛ وإن كانت المواد جاهزة لكن لم تكتمل عملية الإرسال إلى L1، فراجع إرسال المعاملة وتنظيم الواجهة. قد تختلف طريقة المعالجة تمامًا حتى لو كان خط التقدم نفسه قد توقف.
يقوم الـ PR أيضًا بحفظ معرّف معاملة Dusk الأصلي، وكذلك hash الخاصة بـ Ethereum بعد تحويل adapter. عند استكشاف الأعطال، إذا احتفظت بـ hash واحد فقط، فقد تفقد الفهرسة عند الانتقال إلى الجهة الأخرى. الأكثر عملية للمستخدم هو حفظ هويات نوعي المعاملات منذ البداية.
خلال تجربة محلية أُجراها أحد المساهمين، فإن 0.1 DUSK أدت إلى زيادة صافية نهائية في الحساب قدرها 0.097716912، وكانت تكلفة finalization gas تساوي 0.002283088 DUSK. هذا ليس قياسًا شخصيًا لدي، ولا استنتاجًا حول الرسوم والتأخير والاستقرار من شبكة اختبار عامة أو الشبكة الرئيسية. يمكن لتحديث $DUSK أن يبرهن كيف صُممت طبقات المسؤوليات وكيفية تصميم حقول التتبّع، لكنه لا يمكن أن يُغني عن ضمانات مرتبطة بالبيئة الخارجية. إن مواءمة المكونات والمراحل ونوعَي الـ hash هو ما يمنح فرصة تحويل "التعليق" إلى مشكلة يمكن تحديد موقعها. #dusk