شيء واحد لفت انتباهي أثناء التعمق في Dusk: يمكن أن يظل المحفظة مرتبطة بشكل صحيح بهوية، ومع ذلك تفشل عملية التحويل لأن قرار الأهلية الذي يعتمد عليه هذا التحويل لم يعد حديثًا.

افترضت في البداية أن هذه في الأساس خطوة تحقق واحدة.

ليست كذلك.

كلما نظرت إلى البنية بشكل أعمق، بدا الأمر أكثر كمشكلة إدارة حالة (state-management) وليس كمشكلة في المحفظة.

يرسّخ ربط المحفظة علاقة تشفيرية بين هوية ومحفظة.

يمكن أن تبقى تلك العلاقة صالحة تمامًا، بينما تتغير الظروف الخارجية التي تؤثر على أهلية التحويل.

تخيّل محفظة مرتبطة يوم الاثنين. في يوم الثلاثاء، تتغير معلمة امتثال خارجية على السلسلة (off-chain).

لم يتم إلغاء ارتباط الهوية، ولم تتغير المحفظة، ولا يزال بإمكان المستخدم إثبات السيطرة عليها.

لكن إذا لم تتم إعادة حساب حالة السياسة المستخدمة أثناء تقييم المعاملة، فقد يؤدي ذلك إلى نتيجة مختلفة تمامًا للتحويل. #dusk .

هذا التمييز سهل أن يُفوَّت لأن واجهة المستخدم تُبسّط عدة فحوصات في تجربة واحدة: “مُتحقَّق” لا يعني بالضرورة “مؤهل الآن”.

تحت السطح، قد توجد عدة انتقالات مستقلة للحالة: التحقق من التوقيع، وربط الهوية، وحالة بيانات الاعتماد أو السياسة، والتفويض النهائي للتحويل. @Dusk .

السؤال الهندسي المهم هو كيف تنتقل التغييرات في السياسة الخارجية إلى الحالة التي تقوم المعاملة فعليًا بتقييمها.

بالنسبة لـ $DUSK ، يؤدي ذلك إلى مفاضلة مثيرة للاهتمام. قد يؤدي الحفاظ على حالة السياسة بشكل حذر إلى تقليل تعرض الامتثال، لكن الحالة القديمة تعني رفض تحويلات وحدوث احتكاك تشغيلي.

إن تحديثها بشكل أكثر عدوانية يحسّن حداثتها، لكنه يضيف حسابات إضافية وتنسيقًا وتبعيات على البنية التحتية.

ما أحاول فهمه حتى الآن هو طبقة الحوافز: عندما تصبح محفظة صالحة لكن إذنها قديم، من المسؤول اقتصاديًا وتشغيليًا عن تحديث تلك الحالة؟