وصف تشغيل نموذجين معاملات مختلفين بنيويًا على طبقة تسوية واحدة هو أمر يمكن تقديمه بشكل تجريدي. لكن تطبيق ذلك بحيث لا يمكن أن يتناقضا معًا يمثل مشكلة أخرى تمامًا، وقد حلّت DuskDS هذه المسألة عبر جزء واحد محدد من البنية المعمارية، وهو عقد التحويل (Transfer Contract).

فليس نظام Phoenix ونظام Moonlight نظامين مستقلين يعملان بالتوازي على أمل البقاء متّسقين بالصدفة. فكل حركة قيمة، سواء كانت ملاحظة UTXO مُشفّرة ضمن Phoenix أو رصيد حساب عام ضمن Moonlight، تمر في النهاية عبر عقد التحويل، وهو السلطة الفعلية على الحالة العالمية في DuskDS. وهو المكان الوحيد المسؤول عن ضمان ألا يؤدي إنفاق ملاحظة مُشفّرة وتحديث رصيد عام إلى إنتاج إجمالي غير متّسق، ولا يمكنه خلق قيمة من لا شيء، ولا يسمح لنموذجيّ المعاملات بأن ينفصلا عن بعضهما بمرور الوقت.

ما يعنيه ذلك عمليًا هو أن Phoenix وMoonlight ليسا دفترين مستقلين يشتركان في سلسلة (chain) فحسب؛ بل هما تمثيلان مختلفان تفرضهما جهة واحدة مشتركة للحقيقة. يتغير نموذج الخصوصية تبعًا لنوع المعاملة التي تستخدمها، لكن المحاسبة الأساسية لا يحق لها أن تتعارض مع نفسها اعتمادًا على أي جهة من النظام تنظر منها.

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

لذا، هل تُعد مركزية عملية المصالحة/التوفيق ضمن عقد واحد التصميم الأكثر أمانًا لأن هناك مكانًا واحدًا فقط يمكن تدقيقه والتحقق من صحته، أم أن تحميل تلك المسؤولية على عقد واحد يركّز المخاطر بدلًا من تقليلها.

#dusk @Dusk $DUSK