#dusk $DUSK @Dusk 昨晚 ذهبتُ أتحقق من الآلية التي تجعل ورقة مالية أصدرتها Dusk تلتزم بالقواعد بشكلٍ إلزامي، وما الذي تعتمد عليه بالضبط. كنتُ أظنّ في الأصل أن هذا الجزء يجب أن يكون خارج السلسلة — على الأرجح نظام تسجيل ما يجري تدقيق الأهلية فيه قبل التحويل، فمعظم منصات الأصول المرمّزة تعمل بهذه الطريقة. لكن اتضح أن القواعد ليست خارج السلسلة أصلًا.
XSC، أي معيار العقود السرية للأوراق المالية لدى Dusk، يتيح للجهة المُصدِرة أن تدمج شروط الامتثال مباشرة داخل الرمز نفسه — بحيث يمكن برمجة ورقة مالية لتنتقل فقط بين الحائزين المؤهلين والموجودين في القائمة البيضاء، ويُجرى هذا التحقق على مستوى البروتوكول نفسه، لا عبر إضافة طبقة موافقة لاحقة. القيود ترافق الأصل أينما ذهب، بدلًا من أن يعتمد الأمر على قاعدة بيانات خارجية تراقب من يملك الحق في الاحتفاظ به.
هذا ليس نمط الفشل الذي كنت أتوقعه. معظم حلول "الامتثال" في الترمزة التي قرأت عنها كانت تعاني من ثغرة: الرمز ينتقل على السلسلة، لكن التحقق الحقيقي من الأهلية يحدث في نظام خارج السلسلة لا تستطيع السلسلة نفسها التحقق منه. إذا تعطل ذلك النظام، أو أصبحت البيانات قديمة، أو لم يُستدعَ أصلًا، فلن يوجد شيء على السلسلة يمنع التحويل.
هناك تفصيلة في التصميم شدّت انتباهي كثيرًا — فالمعيار يجب أن يعالج أيضًا حالة فقدان المفتاح الخاص، من دون انتهاك الالتزامات القانونية على الجهة المُصدِرة. إذا فقد المساهم حق الوصول، فإن قانون الأوراق المالية لا يزال ينص على أنه لا يفقد الملكية بسبب ذلك. يجب أن يمنح XSC الجهة المُصدِرة ما يكفي من السلطة لتنفيذ هذا الأمر، لكن هذه السلطة نفسها لا يمكن أن تتحول إلى باب خلفي يضعف الفرضية الأساسية نفسها: "فرض القواعد على السلسلة".
هذا ذكّرني بمبنى يصادق فيه المصعد على البطاقة قبل فتح الباب، بدلًا من الاعتماد على حارس في الأسفل قد يكون في تلك اللحظة غير موجود.
وللتوضيح، ما قرأته هو هدف التصميم الذي يعلنه هذا المعيار، وليس مشاهدة سجلّ مساهم حقيقي يصطدم بحالات الحافة — لم أرَ حالات عملية لفقدان المفتاح أو تغيّر الولاية القضائية في أصول خاضعة للتنظيم بشكل فعلي.
وأظل أفكر: هل فرض التحقق من الأهلية على مستوى الرمز يملأ فعلًا فجوة الامتثال، أم أنه ببساطة ينقل المشكلة إلى سؤال آخر: "من يملك حق تحديث القاعدة المضمّنة داخل الرمز، وبأي سرعة يمكنه تحديثها؟"
@Dusk $DUSK #dusk #BinanceSquareFamily
XSC، أي معيار العقود السرية للأوراق المالية لدى Dusk، يتيح للجهة المُصدِرة أن تدمج شروط الامتثال مباشرة داخل الرمز نفسه — بحيث يمكن برمجة ورقة مالية لتنتقل فقط بين الحائزين المؤهلين والموجودين في القائمة البيضاء، ويُجرى هذا التحقق على مستوى البروتوكول نفسه، لا عبر إضافة طبقة موافقة لاحقة. القيود ترافق الأصل أينما ذهب، بدلًا من أن يعتمد الأمر على قاعدة بيانات خارجية تراقب من يملك الحق في الاحتفاظ به.
هذا ليس نمط الفشل الذي كنت أتوقعه. معظم حلول "الامتثال" في الترمزة التي قرأت عنها كانت تعاني من ثغرة: الرمز ينتقل على السلسلة، لكن التحقق الحقيقي من الأهلية يحدث في نظام خارج السلسلة لا تستطيع السلسلة نفسها التحقق منه. إذا تعطل ذلك النظام، أو أصبحت البيانات قديمة، أو لم يُستدعَ أصلًا، فلن يوجد شيء على السلسلة يمنع التحويل.
هناك تفصيلة في التصميم شدّت انتباهي كثيرًا — فالمعيار يجب أن يعالج أيضًا حالة فقدان المفتاح الخاص، من دون انتهاك الالتزامات القانونية على الجهة المُصدِرة. إذا فقد المساهم حق الوصول، فإن قانون الأوراق المالية لا يزال ينص على أنه لا يفقد الملكية بسبب ذلك. يجب أن يمنح XSC الجهة المُصدِرة ما يكفي من السلطة لتنفيذ هذا الأمر، لكن هذه السلطة نفسها لا يمكن أن تتحول إلى باب خلفي يضعف الفرضية الأساسية نفسها: "فرض القواعد على السلسلة".
هذا ذكّرني بمبنى يصادق فيه المصعد على البطاقة قبل فتح الباب، بدلًا من الاعتماد على حارس في الأسفل قد يكون في تلك اللحظة غير موجود.
وللتوضيح، ما قرأته هو هدف التصميم الذي يعلنه هذا المعيار، وليس مشاهدة سجلّ مساهم حقيقي يصطدم بحالات الحافة — لم أرَ حالات عملية لفقدان المفتاح أو تغيّر الولاية القضائية في أصول خاضعة للتنظيم بشكل فعلي.
وأظل أفكر: هل فرض التحقق من الأهلية على مستوى الرمز يملأ فعلًا فجوة الامتثال، أم أنه ببساطة ينقل المشكلة إلى سؤال آخر: "من يملك حق تحديث القاعدة المضمّنة داخل الرمز، وبأي سرعة يمكنه تحديثها؟"
@Dusk $DUSK #dusk #BinanceSquareFamily
