ZeroBlock

كنتُ أراجع تصميم الحفظ (RWA custody) الخاص بـ Dusk، وظلّت نقطة واحدة تُعيدني للخلف: الحفظ ليس هو الشيء نفسه مجرّد وضع أصلٍ على السلسلة (onchain).
يبدو هذا بديهيًا، لكنه يغيّر طريقة قراءتي للتركيبة كاملة.
بالنسبة للأصول الواقعية (real world assets)، ليست الصعوبة فقط في تمثيل الملكية رقميًا. ما يزال النظام مضطرًا للتعامل مع الأصل القانوني نفسه، والأهلية، وقواعد النقل، وإعداد التقارير، والمؤسسات المسؤولة عن هذه الالتزامات.
السرد المعتاد في عالم العملات المشفّرة هو أن “الترميز” يحوّل الـ RWA إلى شيء يمكنه التحرك مثل أي توكن آخر. لكن الوثائق تشير إلى واقع أكثر تقييدًا. يمكن لـ Dusk توفير بنية تحتية لتمثيل الأصول المنظمة وإدارتها مع الخصوصية والإفصاح المُتحكَّم فيه، لكنه لا يجعل طبقة القانون والمؤسسات الأساسية تختفي.
هذا الفرق مهم بالنسبة للحفظ.
يمكن أن تمتلك الورقة المالية المُرمّزة حالة على السلسلة، بينما لا تزال علاقة الحفظ في العالم الحقيقي تعتمد على الجهات المنظمة والعمليات القائمة. تغيّر Dusk طريقة التعامل مع أجزاء من تلك الحالة وسير العمل للمعاملات على السلسلة. لكنها لا تُغْنِي عن محامي/منظّم الحافظ (custodian) ولا تُلغي كل قرار يتم خارج السلسلة.
لهذا أعتقد أن السؤال المثير للاهتمام ليس ما إذا كانت RWAs يمكن ترميزها.
بل ما إذا كانت السلاسل الكتلية يمكن أن تقلّل التعقيد التشغيلي حول الملكية المُنظمة دون التظاهر بأن طبقة التنظيم لم تعد موجودة.
إذا كان الحفظ يظل – جزئيًا وبحسب التصميم – مؤسسيًا، فهل الفرصة الحقيقية في ترميز RWA تكمن في الأصل نفسه أم في البنية التحتية التي تنسّق كل شيء حوله...
#dusk $DUSK @Dusk

ذهبت أبحث في جانب الأوراق المالية المُنظَّمة لدى Dusk، وانتهيت إلى إيلاء اهتمام أقل للأصول نفسها وأكثر لسير العمل المحيط بها.
الجزء المثير للاهتمام هو أن الأصول المُنظَّمة لا تحتاج فقط إلى الخصوصية. إنها تحتاج إلى خصوصية مع طريقة مُتحكَّم بها لكشف المعلومات عندما تتطلب القواعد ذلك.
وهذا جعل معمارية خصوصية Dusk أكثر إثارة للاهتمام عندما ربطتها مع Citadel ونموذج المعاملات المعتمد على الحسابات في الشبكة. يمكن أن يبقى “الحالة السرّية” محمية بينما تتيح “الإفصاحات الانتقائية” للمشاركين المُنظَّمين مسارًا لإثبات معلومات محددة أو مشاركتها. ثم يصبح نموذج الحساب مهمًا لأن سير العمل هذا يمكن تمثيله كتغييرات في الحالة دون إجبار كل مشارك على كشف تفاصيل المعاملة الكامنة.
ثم نظرت إلى جانب الإجماع. يفصل تصميم SA لدى Dusk بين التحقق من الاقتراح والمصادقة. بالنسبة لسير عمل مُنظَّم، هذه الفروق مهمة لأن التسوية ليست مجرد تقديم معاملة. يحتاج عدة مشاركين في الشبكة إلى الاتفاق على أن الحالة الناتجة صحيحة قبل أن تصبح جزءًا من السجل.
هناك طبقة أخرى يمكن إغفالها بسهولة: يحتاج مقدمو الخدمة (provisioners) إلى رهن DUSK والحفاظ على البنية التحتية. لذا فإن النظام يربط إدارة الحالة السرّية والتسوية المُنظَّمة بطبقة أمن اقتصادية وتشغيلية.
ما أراه أكثر إثارة للاهتمام هو مشكلة التنسيق الكامنة تحت كل ذلك. تتطلب منصة الأصول المُنظَّمة خصوصية للمستخدمين، وإفصاحًا للأطراف المرخّصة، وتسويةً حتمية للمؤسسات، ودرجة كافية من الاعتمادية التشغيلية بحيث لا ينكسر سير العمل على مستوى الشبكة.
لا تصبح التقنية مفيدة إلا عندما تعمل هذه الأجزاء معًا. وهناك أعتقد أن التعقيد الحقيقي للأصول المُنظَّمة على السلسلة يكمن.
#dusk $DUSK @Dusk

ذهبتُ أبحث في إجماع Dusk عند غروب الشمس متوقعًا أن تكون الجزء المثير هو اختيار اللجنة. لكني انتهيتُ إلى الانتباه أكثر لما يحدث بعد اختيار اللجنة.
يقسم SA الإجماع إلى التحقق من الاقتراح والمصادقة (ratification). يبدو ذلك كخيار تصميم تقني حتى قارنته ببنية المكافآت ومتطلبات الـ staking. لا يقوم النظام ببساطة بدفع مُدقّق واحد مقابل إنتاج كتلة. بل تُشارك المكافآت عبر لجنة التحقق الخاصة بمولّد الكتل ولجنة المصادقة. يمكن للمولّد أن يحصل على 70% بالإضافة إلى 10% أخرى اعتمادًا على عدد الـ credits المدرجة، بينما تحصل كل من لجنة التحقق ولجنة المصادقة على 5%.
وهذا يغيّر طريقة تفكيري في نموذج الحوافز.
النظام عمليًا يدفع لعدة مجموعات كي تحافظ على استمرار الكتلة وهي تمر عبر مراحل مختلفة من الاتفاق. وهذا مهم لأن التسوية الحتمية السريعة لا تكون مفيدة إلا إذا بقيت المشاركة موثوقة. قد يواجه عضو اللجنة الذي يفشل بشكل متكرر في المشاركة عقوباتًا خفيفة، بينما يمكن أن يؤدي السلوك المثبت أنه غير صالح إلى حرق الرصيد المُرهَن.
ثم توجد الجهة التشغيلية التي يسهل التغاضي عنها. يحتاج المُزوّد (provisioner) إلى ما لا يقل عن 1,000 DUSK ويجب أن يحافظ على البنية التحتية متصلة بالإنترنت ومُزامنة. الحد الأدنى من المتطلبات المنشورة هو 2 CPU cores و4 GB RAM و50 GB تخزين و10 Mbps شبكات.
لذلك قد لا تكون القيود الحقيقية مجرد تكلفة العتاد الخام. بل هي الانضباط التشغيلي.
ما وجدته مثيرًا هو أن SA يبدو أنه صُمم لتقليل تكلفة الاتفاق بدلًا من زيادة عدد المشاركين فحسب. اللجان العشوائية توزّع المسؤولية، بينما يحاول نظام المكافآت والعقوبات جعل المشاركة قابلة للاعتماد.
وهذا يجعل الإجماع أقل تعلقًا بمن ينتج الكتل وأكثر تعلقًا بما إذا كان هناك ما يكفي من المشغلين المستقلين الذين يحضرون باستمرار عند حلول دورهم.
#dusk $DUSK @Dusk

ذهبتُ للبحث في تدفّق ترحيل (migration) جسر الغسق (Dusk) متوقعًا أن تكون الجزء المثير هو عقد EVM. اتضح أن الأمر كان يتعلق بالجهة المُوقِّعة (signer) الكامنة خلفه.
كان عقد الترحيل نفسه مباشرًا نسبيًا. قام المستخدمون بإقفال (lock) ERC20 أو BEP20 DUSK، وتم إصدار حدث ترحيل. لكن ذلك الحدث لم يُنشئ فجأة DUSK محليًا (native). كان لا بد من خدمة خارجية تراقبه ثم تعيد إصدار الأموال على Dusk.
هذه التفرقة أهم مما قد يبدو أول الأمر.
كانت البنية الأوسع لـDusk تتحرّك نحو نموذج جسر أصلي (native bridge)، بحيث يمكن أن تنتقل القيمة بين DuskDS وDuskEVM دون أصول مغلّفة (wrapped assets) أو أمناء حفظ خارجيين. ومع ذلك، ما زار مسار الترحيل الأقدم يعتمد على محفظة توقيع تشغيلية لتحويل حدث EVM المُلاحظ إلى معاملة فعلية على Dusk.
تُظهر بيانات الحادث هذا الاعتماد بوضوح. في 16 يناير، اخترق أحد المهاجمين تلك المحفظة ثم نقل DUSK مُسروقًا عبر مسار الجسر. تضمّن التسلسل 7,880 DUSK تم ترحيلها، وبعد ذلك 1.91 مليون DUSK أخرى قبل أن توقف المعالجة اللاحقة محاولة ترحيل إضافية قدرها 8.91 مليون DUSK.
ما أعتبره مهمًا ليس فقط أن المحفظة تم اختراقها.
بل أن إدخال الحدث (event ingestion) وإطلاق القيمة (value release) كانا مرتبطين فعليًا عبر مسار تشغيل واحد. يمكن لعقد ذكي أن يكون حتميًا (deterministic)، بينما يظل النظام المحيط به يعتمد على حيازة المفاتيح (key custody)، وعزل الخوادم (server isolation)، والمراقبة (monitoring)، ومعالجة المعاملات (transaction handling).
لذلك فإن إعادة التصميم التي تفصل إدخال الأحداث عن التوقيع وتحويل أحداث الترحيل إلى وظائف (jobs) مُؤتمَّنة (persisted) ليست مجرد رقعة أمنية. إنها تغيّر مكان تمركز الثقة.
قراءة هذا جعلتني أفكر بشكل مختلف بشأن الجسور. غالبًا ما يكون العقد هو الجزء الذي نفحصه أولًا، لكن حدّ الثقة الحقيقي قد يكون على بُعد عدة طبقات خلف العقد، داخل البرنامج الذي يقرر متى يصبح الحدث نقودًا.
#dusk $DUSK @Dusk

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