ZeroBlock

ذهبت للنظر في إعدادات مخاطر الإقراض لدى Termax وانتهيتُ إلى إيلاء اهتمام أكبر للفجوة بين الحد الأقصى للقيمة مقابل القرض (LTV) وقيمة التصفية (LTV للتصفية).
في البداية يبدو الأمر كضابط تحكم بسيط في المخاطر. يقوم المقترضون بتقديم ضمانات، ويختار المقرضون مقدار الدين الذي يشعرون بالراحة تجاهه، وتعمل التصفية على حماية المركز عندما تنخفض قيمة الضمانات كثيرًا.
لكن كلما فكرت أكثر، رأيت الآلية الحقيقية بوضوح.
إن LTV الأقصى ليس مجرد رقم يصف مقدار ما يمكن أن يقترضه شخص ما. بل هو تعبير عن مقدار التذبذب الذي يكون مزوِّد السيولة مستعدًا لامتصاصه قبل أن يصبح المركز غير مريح.
ثم تُنشئ قيمة التصفية (liquidation LTV) حدًا ثانيًا. تلك الفجوة بين المستويين تُعد عمليًا مساحة تنفّس تشغيلية.
إذا كانت الضمانات بالفعل قريبة من التصفية عند إنشاء القرض، فقد تدفع حركة سوقية متواضعة المركز إلى التصفية قبل أن يكون هناك وقت كافٍ لنظام المنصة أو المقترض للتفاعل. أما الفجوة الأوسع فتغيّر توقيت ذلك.
وهذا أيضًا يفسر لماذا تؤثر إعدادات محدِّدات الأوامر (order setters) أكثر مما افترضت في البداية.
فهي تقوم فعليًا بتشكيل سطح المخاطر في سوق الإقراض. يمكن أن تؤدي إعدادات مختلفة إلى إنشاء برك سيولة مختلفة ذات مستويات مختلفة من تحمل التذبذب. وهذا يعني أن السيولة المتاحة ليست سوقًا واحدًا موحّدًا بالفعل؛ بل يتم تقسيمها وفقًا لتفضيل المخاطر.
ما شدّ انتباهي هو أن هذا يجعل التصفية أقل كونها آلية طارئة معزولة وأكثر كونها نتيجة لكيفية تهيئة السيولة قبل أن يوجد القرض أصلًا.
لذلك، ليست البيانات المهمة ببساطة هي مقدار ما تم اقتراضه.
أود أن أراقب أين تتجمع إعدادات LTV، ومدى سرعة تحرك الضمانات عبر تلك النطاقات، وما إذا كانت السيولة تبقى باستمرار حول عتبات محافظة أم عدوانية.
في النهاية، يكشف سوق الإقراض ما الذي يكون المشاركون مستعدين لتحمّله قبل أن يكونوا مستعدين لتقديم رأس المال.
#termmax @TermMax

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

ذهبتُ إلى ما وراء الغسق لأفهم زاوية رأس المال لدى الشركات الصغيرة والمتوسطة (SME)، وانتهيتُ إلى التركيز أكثر على كل ما يجب أن يحدث قبل أن تتمكن الـSME بالفعل من استخدام مسار تمويل جديد.
إن NPEX هي الجزء الذي جعلني أتوقف. لا يبدأ الغسق من فكرة مجردة للأوراق المالية المُرمّزة. تعمل NPEX بالفعل كسوق مُنظَّم مخصص للشركات الصغيرة والمتوسطة، وقد سهّل تمويلًا يتجاوز 200 مليون يورو لأكثر من 100 شركة صغيرة ومتوسطة، مع الربط مع أكثر من 17,500 مستثمر نشط.
عندها بدأت معمارية الغسق تصبح أكثر وضوحًا.
يتحدث جزء “المادة الخاصة بالترميز” عن تقريب الإصدار وعمليات اعرف عميلك KYC ومكافحة غسل الأموال AML وسجلات الملكية والإجراءات/العمليات المؤسسية من الأصل نفسه. ويتجاوز تصميم الإصدار الأصلي ذلك عبر استهداف التسوية الفورية T+0 بدلًا من العملية التقليدية T+2.
هذا يبدو في البداية كتحسين للسرعة.
لكن الجزء الأكثر إثارة للاهتمام برأيي هو ما يحدث لبنية التكلفة المحيطة بالمُصدِرين الأصغر.
لا تعاني الـSME فقط لأن رأس المال غير متاح. قد تواجه صعوبة لأن إصدار الأوراق المالية يُنشئ سلسلة من الأعمال القانونية، وإدارة شؤون المساهمين، والتحقق من الامتثال، وعمليات التسوية، وسجلات متفرقة. وإذا بقيت هذه العمليات باهظة التكلفة، فلن يغيّر وضع الورقة على بلوكتشين سوى القليل.
ما لفت انتباهي هو أن الغسق كان يعمل على البنية التحتية حول هذه المشكلة لسنوات، بينما تمنحه علاقة NPEX سياقًا سوقيًا مُنظَّمًا قائمًا بالفعل. إن انتقال مؤسس الغسق، إمانويلي فرانشوني، في عام 2024 إلى دور قيادي في تقنيات NPEX يجعل هذا الربط أكثر عملية.
لذلك، النقطة التي تُركت دون انتباه بالنسبة لي بسيطة.
فرصة الـSME ليست حقًا عن وضع الأسهم على السلسلة.
بل هي عن جعل الأسواق الرأسمالية الأصغر عملية اقتصاديًا بما يكفي لتتمكن من الوجود أصلًا.
#dusk $DUSK @Dusk

ذهبت أبحث في منتجات TermMax الطويلة والقصيرة، متوقعًا أن تكون الأجزاء المثيرة هي التداول الاتجاهي نفسه. لكني انتهيت إلى التركيز أكثر على ما يجب أن يكون موجودًا تحت ذلك التداول.
أول ما لفت انتباهي هو أن TermMax لا يتعامل مع التعرض الطويل والقصير كميزة تداول معزولة. فتصميمه الأوسع يربط بين الإقراض والاقتراض لآجال ثابتة وبين الرافعة والمنتجات المُهيكلة. وهذا مهم لأن الموقف الاتجاهي يحتاج إلى طرف آخر يقف في الجهة المقابلة من المخاطر.
ثم لاحظت بنية الاستثمار المزدوج (Dual Investment). يقوم مزودو السيولة فعليًا بتوفير رأس المال الذي يحتاجه المشترون لكل من المراكز الطويلة والقصيرة. كما تُظهر صفحة الـ vault أن هذه الأموال تُوزَّع عبر أسواق بسعر ثابت بدلًا من مجرد الجلوس كسيولة تداول غير مستغلة.
غيّر ذلك طريقة نظري إلى المنتج.
التحدي الحقيقي ليس إنشاء زر لـ “طويل” أو “قصير”. بل هو تنسيق السيولة والتسعير والاستحقاق والتسوية بحيث يمكن أن توجد هذه الصفقة دون الاعتماد على آليات الهامش المفتوح (open ended) الشائعة في أماكن أخرى.
كما يبدو أن التنفيذ الحالي مُركَّز عمدًا في أسواق محددة. تُظهر واجهة TermMax أسواق Alpha الطويلة والقصيرة على BNB Chain، بينما يمتد بقية البروتوكول عبر عدة سلاسل للإقراض والاقتراض والرافعة.
هذا الفصل مثير للاهتمام.
يشير ذلك إلى أن المشكلة الصعبة ليست مجرد إضافة المزيد من الأصول. بل بناء سيولة كافية وبنية تحتية للتسعير حول كل أصل بحيث يبقى التعرض الاتجاهي قابلاً للاستخدام.
بعد الاطلاع على المعمارية وواجهة السوق، خرجت بفكرة مفادها أن مركز “طويل” أو “قصير” هو في الواقع الطبقة المرئية.
أما الطبقة الأقل وضوحًا فهي تنسيق السيولة الذي يجعل هذا المركز ممكنًا.
#termmax @TermMax

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

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

كنتُ أراجع تصميم الحفظ (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