彭鱼宴啊

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

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

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

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

#dusk $DUSK @Dusk ظللتُ دائمًا أتساءل عن صندوق التطوير في نظام Dusk البيئي؛ كيف يعمل ذلك تحديدًا—هل الفريق هو من يقرر كل شيء بنفسه، أم توجد بالفعل عملية يَستطيع من خلالها أشخاص من خارج الفريق التقدم للحصول على هذه الأموال. بعد أن راجعت شرح الحوكمة جولةً كاملة، اكتشفت أن هذه العملية أكثر رسمية مما كنت أتخيل في البداية.
مصدر تمويل هذا الصندوق مباشر: ففي كل مرة تنتج الشبكة الرئيسية كتلةً جديدة، يتم اقتطاع جزء ثابت من المكافآت وتُضاف على المدى الطويل إلى هذا التجمع (Pool) الخاص بالصندوق، بهدف دعم أعمال التطوير والبحث اللاحقة داخل النظام البيئي. وليس الأمر معتمدًا على تبرعات مؤقتة أو مساهمات من جيب الفريق.
أما موضع تفويض الصلاحيات الحقيقي فهو في إجراءات الموافقة. فالتعديلات المتعلقة بالاتفاقية نفسها—مثل اقتراحٍ تقني محدد—تمر عبر خط تقديم وتقييم واتخاذ قرار بشأن ما إذا كان سيتم اعتماد هذا البند. كما تُشترط أن تكون الصياغة منظمة نسبيًا، على نحو يشبه وثيقة رسمية مقترحة للتقنيات، وليس مجرد نشر منشور عشوائي ثم يُعتبر الأمر محسومًا. أما المصروفات التي لا ترتبط مباشرةً بكود الاتفاقية—مثل تطوير أداة محفظة، أو ميزانية بحثية لموضوع/مقرر متخصص—فتسير عبر مسار موافقة آخر، حيث تقوم مجموعة حوكمة مكلّفة تحديدًا بتقييم توزيع هذه الأموال واتخاذ القرار. ومن الناحية النظرية، يمكن لأعضاء من المجتمع الخارجي أيضًا المشاركة عبر إجراءات انتخاب هذه المجموعة، وبالتالي الدخول في عملية الموافقة.
كنت أعتقد في الأصل أن هذا مجرد «صندوق أسود للموافقة الداخلية للفريق»، لكن بعد قراءة الشرح تبيّن أن الخطين منفصلان بشكل واضح على مستوى الوثائق على الأقل، وكلاهما يترك منافذ تسمح لأشخاص من خارج الفريق بتقديم طلبات بل والمشاركة في التقييم، وليس الأمر مغلقًا بالكامل. غير أن الشرح في الوثائق شيء والتنفيذ الفعلي شيء آخر. وبخصوص السنوات القليلة الماضية: ما هي المشاريع التي تمت الموافقة عليها بالضبط، وما معدل الموافقة تقريبًا، وما نسبة الطلبات المقدمة من الخارج—لم أجد بيانات تنفيذ محددة بين يدي حتى الآن. وبناءً على ذلك، يمكنني القول إن تصميم العملية من حيث المبدأ يتيح الانفتاح، لكن من ناحية ما إذا كانت تُدار بصورة شفافة أو غير شفافة، فهذا أمر لا يزال غير محسوم ويحتاج إلى المزيد من السجلات التاريخية للتحقق، ولا أستطيع حاليًا تقديم حكمٍ مؤكد.

#dusk $DUSK @Dusk في البداية كانت لدي تصوّرات بسيطة جدًا عن "تأمين/إيداع DUSK كـ provisioner"—فقط انقل العملات، شغّل عقدة، ثم انتظر للحصول على المكافآت. إلى أن قرأت بجدية أدلة التشغيل/السلامة الرسمية، وطبّقت الخطوات فعليًا، عندها أدركت أن هذا الموضوع أصعب بكثير مما كنت أظن.
الطريقة الموصى بها في الدليل هي أن يتم توليد owner key الخاص بصلاحية الإيداع المرهون مباشرةً على جهاز USB مشفّر باستخدام LUKS، بدلًا من تركه على قرص صلب كمبيوتر عادي متصل بالإنترنت. الخطوات تكون مثلًا: أولًا استخدم cryptsetup لتشفير كامل قرص الـ U باستخدام LUKS، ثم ضع كلمة مرور قوية، وبعد ذلك ولّد مفتاح المحفظة/مالكها مباشرة داخل قسم التشفير هذا. عادةً لا يتم توصيله طوال الوقت؛ بل يتم إدخاله فقط عند الحاجة فعلًا لإلغاء الإيداع أو استخراج المكافآت لاستخدامه مرة واحدة. منطق هذه الطريقة هو أنه حتى لو ضاع هذا الـ USB أو تم سرقته، فلن يمكن قراءة أي شيء منه بدون كلمة المرور. أما التشغيل اليومي للعقدة فيتم باستخدام مجموعة مفاتيح أخرى بصلاحيات أقل، منفصلة عن owner key الذي يمكنه فعليًا استخدام رأس المال المرهون.
بعد أن اتبعت هذه الخطوات، كان أكبر شعوري هو أن الأمر لم يعد مجرد"ضغط زرّات قليلة"؛ بل صار يتطلب منك فهم طبقات تشغيل وصيانة مثل تشفير الأقراص وإدارة المفاتيح دون اتصال (offline). بالنسبة لي، الذي يكتب الكود عادةً لكنه ليس مختصًا في أعمال التشغيل/الـ ops بشكل احترافي، استيعاب ما يجب إدخاله بالضبط ضمن /dev/sdX وأي جهاز تختار—وعدم الوقوع في خطأ قد يؤدي إلى تهيئة قسم خاطئ—استغرق وقتًا طويلًا من التحقق المتكرر.
هذا جعلني أعيد التفكير في جانب مشاركة إيداع Dusk: حد الإيداع الأدنى مجرد 1000 DUSK، ما يبدو وكأنه سهل جدًا من ناحية القبول. لكن إذا طبّقت فعلًا معايير الأمان الموصى بها رسميًا، فإن عتبة التشغيل الواقعية لا تقتصر على"وجود 1000 قطعة نقدية" فحسب؛ بل تحتاج أيضًا إلى قدر من المهارات التقنية وصبر لإكمال مسار الأمان خطوة بخطوة. هذا غالبًا سيستبعد بشكل طبيعي شريحة من المستخدمين العاديين الذين يريدون فقط"إيداعًا دون عناء"، بينما الباقي سيكون أكثر ممن يحرصون على التعامل بجدية مع أمان العقدة—وهذا شيء جيد من ناحية أمن الشبكة. لكن بالنسبة لهدف "الوصول إلى لا مركزية كافية عبر المشاركة في الإيداع"، فقد تكون عتبة التشغيل نفسها أيضًا عامل تصفية سهل أن يتم تجاهله.

#termmax @TermMax كنت قد قصدت في الأصل الاطلاع على الورقة البيضاء لـ TermMax بهدف معرفة تفاصيل أسعار الإقراض، لكن أثناء قراءة الجزء الذي يتحدث عن الرؤية، كدت أمرّ عليه بسرعة—"إنشاء سوق ائتمان كامل لكل زوج من الرموز، كما يحدث في العالم الحقيقي"، هذا النوع من الكلام شائع جدًا في الأوراق البيضاء؛ لذلك لم أعره اهتمامًا في البداية. لكن بعد التمعّن في السطور التالية، اكتشفت أن نفس القائمة تضمنت أيضًا إدراج "القيام بالشراء أو البيع على المكشوف للأصول الفورية". عندها توقفت وأعدت القراءة من جديد.
أول ما خطر لي هو أن هاتين الأمور لا يبدو أنهما تتناسبان معًا—فالإقراض بمعدل ثابت هو أداة مالية، بينما الشراء على المكشوف/البيع على المكشوف للأصل الفوري هو قصة مختلفة. لماذا تُذكران ضمن نفس الرؤية للمنتج؟ وعندما جمعتُ هذا المقطع مع الآلية السابقة لـ GT الممكّن بنقرة واحدة والاقتراض الدوري، فهمت الأمر: المعدل الثابت هنا ليس الغاية بحد ذاته، بل هو مجرد قاعدة. إذا تم استبدال الاقتراض من A ببيع A والانتقال إلى B للقيام بشراء/بيع على المكشوف لـ B، أو بالعكس، طالما يمكن قفل تكلفة التمويل مسبقًا، فلن تلتهم تقلبات معدل الفائدة العائد بشكل خفي. اتضح أن الإقراض بمعدل ثابت هو أساس/متينة أسفل طبقة استراتيجية التداول الموضحة أعلاه.
عند هذه النقطة بدأت أشك في أنني ربما أستنتج أكثر من اللازم. عدتُ للتحقق من عمق أوامر Range Order و Limit Order في الوقت الحالي، ووجدت أن معظمها يتركز فعلًا في بضعة أسواق في المقدمة. وهذا جعلني مترددًا: لكي تكون استراتيجية مثل "اقترض A لشراء/الشراء على B" قابلة للتطبيق، يجب أن يكون هناك تسعير عميق بما يكفي على جانبي الضمان والأصل المَدِين. أما المنحنيات بالنسبة للأصول الطرفية/غير الأساسية فقد لا تثبت أساسًا. بمعنى آخر، عبارة "إنشاء سوق ائتمان كامل كما يحدث في العالم الحقيقي"، أراها الآن أقرب إلى واجهة/مخطط معماري تم توفيره، دون أن تكون مرحلة تحقيق ذلك الفعلي قد وصلت بعد.
في الخطوة التالية، لن أظل أراقب عدد أسواق الإقراض التي يتم دعمها، بل سأريد معرفة ما إذا كان هناك من يستخدم فعليًا تداولًا اتجاهيًا نقيًا من نوع "اقترض A لشراء B"—بدلًا من الرجوع إلى ذلك الدوران القديم لآلية الرافعة بنقرة واحدة. الفجوة بين الرؤية والمنتج هي المفتاح لمعرفة إلى أي مرحلة وصل هذا القصة بالفعل.

#dusk $DUSK @Dusk في وقتٍ مضى، عندما كنت أشرح لأحد الأصدقاء آلية الإجماع في Dusk، نقلت تلقائيًا ما كنت قد رأيته من قبل—فـDusk تستخدم Proof of Blind Bid، وهو ما يعني أن هوية مُصدِر الكتلة تكون مجهولة، ويتم إخفاء مبلغ الرهان عبر إثباتات المعرفة الصفرية للمنافسة على حق إصدار الكتلة. بعد أن انتهيت، راودتني الشكوك: هل ما زالت Dusk تستخدم بالفعل هذه الآلية حتى اليوم، أم أنني أتذكر وثيقة قديمة جدًا؟ عدت وفحصت الأمر، واتضح أنني كنت مخطئًا بالفعل.
في النسخ المبكرة من ورقة Dusk البيضاء، كانت Proof of Blind Bid فعلًا تصميمًا يحمل الكثير من الأفكار: يقدّم مرشح إصدار الكتل (Block Generator) معاملة “Bid Transaction”، ويقوم بتخزين مبلغ الرهان داخل شجرة Poseidon، ثم يولّد إثباتًا ذا معرفة صفرية مطابقًا. وبهذا، لا يستطيع العالم الخارجي معرفة من يشارك أو كم راهن. كان هذا التصميم بدافع واقعي جدًا—فإذا كانت هوية مُصدِر الكتلة ومبلغ الرهان معلنين، فهذا يعني أن المهاجم يحصل على “قائمة أهداف رئيسية” للتركيز على مُصدِري الكتل المعروفين وبمبالغ كبيرة، عبر هجمات على مستوى الشبكة. وقد كانت المنافسة المجهولة التي تعتمدها Dusk في بداياتها بمثابة الحل التشفيري لمواجهة هذا النوع من الهجمات الموجهة.
لكن الآن، في وثائق Dusk الرسمية الخاصة بإجماع الشبكة الرئيسية (mainnet)، يُسمّى Succinct Attestation، وهو تصميم لإثبات الحقوق قائم على لجنة (committee). حيث يتم الاعتماد على provisioner لإنتاج المرشحين المُصدّرين واللجنة التي تقوم بالتصويت عبر انتخابات حتمية، ولا يُذكر خلال العملية مفهوم “المنافسة المجهولة” إطلاقًا. وبعبارة أخرى، في انتقال Dusk من التصميم المبكر إلى تطبيقه على الشبكة الرئيسية، قامت بهدوء باستبدال خاصية “مجهولية هوية مُصدِر الكتل” بخاصية تركز أكثر على الكفاءة وحتمية النتيجة عبر آلية اللجنة.
لم يُعلن عن هذا التغيير بشكل كبير، لكن دلالته ليست صغيرة—فالمشكلة التي كانت Proof of Blind Bid المبكرة تهدف إلى حلها، وهي “منع الهجمات الموجهة”، تمت معالجتها في Succinct Attestation بطريقة مختلفة: اعتماد أكبر على حجم اللجنة وعلى عدم القدرة على التنبؤ بالانتخابات، بدلًا من إخفاء الهوية تمامًا. وبالنسبة لي، يذكّرني هذا بأمر مهم: عند تقييم التصميم التقني لأي مشروع، لا يمكن الاكتفاء بالرجوع إلى مقالات كُتبت منذ سنوات مضت كدليل. فآلية Dusk الأساسية نفسها تخضع لتطويرات مستمرة؛ ومن الممكن ألا تكون خطة المنافسة المجهولة التي تبدو رائعة في تلك المرحلة المبكرة هي التي تعمل بها فعليًا اليوم.

أخيرًا وصلنا إلى $ALIGN TGE

اليوم، في تمام الساعة 23:00 بتوقيت بكين، ستبدأ Aligned تشغيل TGE.

كمنصة تركز على التحقق من إثباتات ZK وبنية تحتية للحوسبة القابلة للتحقق على Ethereum، فإن بناء منتجات Aligned على امتداد هذه الرحلة كان متينًا إلى حد كبير.

نتطلع إلى أدائنا اليوم، ونتطلع أيضًا إلى استمرار توسع نظام Aligned البيئي لاحقًا.

وبالإضافة إلى ذلك، وبما أن منصات تداول مثل Coinbase لديها خطط للإدراج، نأمل أن نتمكن من الاستفادة من “اللحوم”
$ALIGN 🚀

#dusk $DUSK @Dusk ظلت فهمي لـ Phoenix طوال الوقت هو: "إنه الإصدار الخاص بـ Dusk من Zcash/Monero" — نموذج معاملات خصوصية يهدف إلى إخفاء الهوية بالكامل، حيث لا يستطيع أي طرف في عملية التحويل رؤية الطرف الآخر. وحتى مؤخراً، وبعد أن راجعت مع النسخة المحدثة لعام 2024 من الورقة البيضاء مع الشرح الرسمي المرفق، اكتشفت أن هذا الفهم قديم بالفعل.
كتبوا في تحديثهم بوضوح شديد: لقد أضافوا إلى Phoenix القدرة على "تمكين المستلم من التعرّف على هوية المرسل"، كما أوضحوا صراحة أن هذه الخطوة تنقل Phoenix من بروتوكول مجهول الهوية (anonymity protocol) إلى بروتوكول يحافظ على الخصوصية (privacy-preserving protocol)، بهدف الامتثال لمتطلبات تنظيمية حالية داخل الاتحاد الأوروبي. وذكرت نفس الوثيقة أيضاً أن الدافع المباشر لإدخال Moonlight (نموذج الحسابات الشفافة) هو أن الفريق أدرك أنه إذا كانوا يريدون التكامل بسلاسة مع البورصات والمؤسسات، فإن الاكتفاء بنموذج حساب مجهول بالكامل غير كافٍ — بل إنهم كتبوا بشكل مباشر أن القيام بذلك هو "للحفاظ على الامتثال، وإزالة خطر الإزالة من القوائم".
أرى أن هذا التحول أكبر مما يعتقده معظم الناس. فمصطلحا "المجهولية" و"الخصوصية" ليسا مترادفين في مجتمع التشفير — فالبروتوكول المجهول الهوية يسعى إلى أن أي طرف ثالث (بما في ذلك المستلم) لا يمكنه تحديد هوية المرسل؛ بينما بروتوكول حماية الخصوصية يضمن فقط ألا يتمكن الأطراف الخارجية غير المعنية من رؤية التفاصيل، ويمكن بل ويُصمَّم أن تبقى قابلية التعرّف بين طرفي المعاملة أو حتى تُدرج عمداً. لقد تخلّى Dusk عن الخيار الأول واختار الثاني — وهذه ليست تنازلاً تقنياً، بل تعديلاً شديد الوضوح في توجيه المنتج: فالطموح في الورقة البيضاء المبكرة لـ Phoenix كان أقرب إلى العملات الخالصة للخصوصية، ثم تم توجيه هذا المسار مباشرة بفعل حقائق الامتثال.
كنت أعتقد سابقاً أن "المجهولية" هي أهم نقطة بيع في Phoenix، لكن بالنظر إلى الوراء أدركت أن هذا الفهم نفسه كان تقييم بروتوكول تطور بالفعل اعتماداً على ورقة بيضاء قديمة. أما بالنسبة لمن لا يزال يستخدم إطاراً يسأل: "هل Dusk عملة مجهولة؟" فقد تكون صياغة السؤال خاطئة أصلاً — فالأهم هو: ضمن شرط "المستلم قادر على التعرف على هوية المرسل"، أين تنحصر حدود الخصوصية المتبقية في Phoenix؟ وهل هذه الحدود كافية لدعم سيناريوهات الامتثال المؤسسي التي يهدف إلى خدمتها.

#termmax @TermMax TermMax يحوّل كل مركز رافعة مالية إلى GT، أي ERC-721. عندما رأيت هذا التصميم لأول مرة لم أفكر كثيرًا، حتى أدركت أن الـNFT يمكن تداولها—وهذا يعني "مركزًا يحمل ديونًا" ويمكن نظريًا بيعه لشخص آخر.

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

إذا نجح تصميم TermMax بالفعل في العمل، فسيخلق نوعًا جديدًا من سلوك التداول: شخص ما يتولى عمدًا شراء GT بسعر منخفض عندما تكون LTV مرتفعة بالفعل لكنها لم تصل بعد إلى LLTV، رهانه أن يجد مشتريًا لاحقًا قبل أن يتم الوصول إلى خط التصفية، أو يراهن على قدرته على إدارتها بشكل أفضل من صاحب المركز الأصلي. هذا يبدو كأنما هو يوفّر جهة أكثر احترافًا لاستيعاب المخاطر، لكنه قد يكون أيضًا مجرد نقل مخاطر التصفية من شخص غير محترف إلى شخص آخر غير محترف أيضًا، لكن يملك الجرأة على المقامرة. لا يصبح البروتوكول بحد ذاته أكثر أمانًا لمجرد أن GT تغيّر مالكه.

ما أريد معرفته أكثر هو: هل توجد حاليًا سجلات حقيقية لتبادل GT في السوق الثانوية؟ وهل تكون المعلومات بين طرفي البيع والشراء حول حالة الضمان الحالية متكافئة عند إجراء التداول، أم أن ميزة "القابلية للتداول" لا تزال موجودة فقط على مستوى العقد، بينما لا أحد يستخدمها فعليًا؟ كون يمكن تداول مركز لدى TermMax، وكونه تم تداولها—شيئان مختلفان تمامًا.

#dusk $DUSK @Dusk لطالما شاهدت شرح اقتصاد توكنات Dusk، وكانت هناك جملة تتكرر دائمًا: "سيتم إطلاق 500 مليون قطعة DUSK تدريجيًا للمُرهِنين خلال 36 عامًا". تبدو هذه الجملة وكأنها تصف منحنى إطلاق شديد السلاسة، شبه غير محسوس من حيث ضغط التضخم. كنت أفهمها أيضًا على هذا النحو، إلى أن قمت بحسابها اعتمادًا على المعلمات الواردة في الوثائق الرسمية بنفسي، واتضح أن الأمر ليس بهذه البساطة.
الحدّ الأقصى لإجمالي كمية Dusk هو 1 مليار قطعة. منها 500 مليون دخلت التداول بالفعل قبل إطلاق الشبكة الرئيسية، أما الـ 500 مليون المتبقية فيتم إطلاقها للمُرهِنين على مدى 36 عامًا وفق نموذج تناقص هندسي، بمعدل تضاؤل يتم فيه خفضه للنصف كل 4 سنوات. إن عبارة "كل 4 سنوات يُخفض للنصف" هي المعلومة المفتاحية—فإذا بسطنا كامل سلسلة التناقص كمتتالية هندسية، فإن كمية الدورة الأولى التي تُطلق خلال أول 4 سنوات تكون تقريبًا مساوية لنصف الـ 500 مليون المتبقية، أي حوالي 250 مليون قطعة. وبشكل تقريبي، فإن متوسط كمية الإطلاق في السنوات الأربع الأولى يعادل أكثر من 4 مرات "معدل التضخم المتوسط" الناتج عن تسطيح 500 مليون قطعة عبر 36 عامًا.
بمعنى آخر، عبارة "الإطلاق البطيء خلال 36 عامًا" لا تكذب في حد ذاتها، لكنها قد تدفع الناس تلقائيًا إلى تصور أن "سرعة إصدار التزايدات سنويًا متقاربة تقريبًا وبشكل سلس"؛ في الواقع، تكون ضغوط الإصدار أكثر تركيزًا في السنوات الأولى بوضوح، ثم مع مرور كل دورة مدتها 4 سنوات تنخفض سرعة الإطلاق للنصف، فيكون المنحنى هابطًا بشكل حاد، وليس خطًا مستقيمًا مسطحًا. وبالنسبة للتوقعات الفعلية لعائدات الرهن، لا تُعد هذه الفروق مجرد تفاصيل غير مهمة—فالمشاركون الأوائل يحصلون على حصة من صندوق المكافآت التي تكون ضمن أسرع أجزاء منحنى الإطلاق، وكلما تأخر الانضمام تقلّ تدريجيًا سماكة الجزء المضاف من الإصدار الذي يمكنهم الحصول عليه.
لا أعتقد أن هذا خلل تصميم. فالتناقص الهندسي بحد ذاته أسلوب شائع في كثير من شبكات PoS، يُستخدم لتوفير حوافز كافية في المراحل المبكرة لدعم نمو شبكة المُحققين، ثم يتم لاحقًا تضييق التضخم تدريجيًا. لكن إذا اقتصرت على النظر إلى رقم "36 عامًا" وافترضت تلقائيًا أن ضغط التضخم يتوزع بشكل متساوٍ، فسوف يفوتك الواقع. نقطة الملاحظة التالية التي سأحددها لنفسي هي: اعتبارًا من عام 2026 وما بعده، عند الاقتراب من أول عقدة تناقص مدتها 4 سنوات، سأتحقق من بيانات مكافآت الرهن الفعلية على السلسلة لمعرفة ما إذا كانت تتطابق مع المنحنى النظري لنموذج التناقص الهندسي—إذا تطابقت، فهذا يعني أن الفريق ينفذ نموذج الاقتصاد كما هو بثبات وفقًا للورقة البيضاء؛ أما إذا ظهرت فروقات، فستكون إشارة أخرى تستدعي إعادة تقييم.

#termmax @TermMax في البداية اعتبرت نظام نقاط TermMaxFi مجرد أسلوب “إسقاط جوي” معتاد: كلما استخدمت أكثر، زادت النقاط. إلى أن رأيت منشورًا رسميًا مخصصًا يوضح أن XP وMP ليستا الشيء نفسه، عندها أدركت أن في هذا التصميم مشكلة أعمق تستحق التأمل: بروتوكول المنصة يريد بالفعل مكافأة من؟
XP يرتبط بمدى عمق استخدامك داخل البروتوكول—كم أودعت، وكم اقترضت، وكم مدة بقائك في المراكز المفتوحة—وهي بيانات استخدام بحتة. أما MP فيقابله مقدار التأثير الذي أنشأته خارج البروتوكول، وهو أقرب إلى المساهمة في الانتشار وجلب مستخدمين جدد. كون منحنيي التسجيل منفصلين يعني أن مستخدمًا يكتفي بالاقتراض ولا يشارك منشورات إطلاقًا، ومستخدمًا ينشر يوميًا لكن بحجم مراكز على السلسلة صغير جدًا، ستختلف تمامًا طريقة احتساب “توزيع نقاط” الإسقاط الجوي بينهما.
هذا التصميم أراه صريحًا نوعًا ما؛ على الأقل لم يحاول تلميع الضجيج التسويقي مباشرة ونعته بـ“نشاط البروتوكول” لخداع الناس. لكنه يجلب أيضًا مشكلة جديدة: إذا كانت أوزان MP مرتفعة جدًا، فمن السهل على المنصة أن ترفع ضجيجًا اجتماعيًا مبكرًا دون وجود حجم اقتراض حقيقي مواكب له—فتبدو أرقام TVL جيدة، بينما لا يتزامن بالضرورة ارتفاعه مع أحجام الاقتراض الفعلية على السلسلة، والتي قد تظل ثابتة عند معدلات الفائدة المتعاقد عليها. لقد وصل TVL الخاص بـ TermMaxFi هذا العام إلى ما يقارب 35 مليون دولار أمريكي؛ هذا الرقم بحد ذاته: هل تم رفعه عبر XP، أم عبر MP وما نتج عنه من اهتمام إضافي؟ يستحق أن ينظر إليه بشكل منفصل.
بعد ذلك سأتتبع أمرين: مدى تداخل المستخدمين الموجودين في صدارة ترتيب كل من XP وMP، وهل بعد انتهاء دورة النقاط والهبوط الفعلي لعمليات الإسقاط الجوي ينخفض حجم الاقتراض على السلسلة بشكل ملحوظ. الإسقاط الجوي قد يحفّز النشاط، لكنه لا يضمن الاستبقاء.

#dusk $DUSK @Dusk عندما رأيت خبر تعاون Dusk و21X في الماضي، كانت أول ردة فعلي هي: "Dusk حصل أيضًا على ترخيص نظام تجارب DLT الخاص بالاتحاد الأوروبي (DLT Pilot Regime)". لكن هذه المرة للتأكد من الأمر، أعادتُ ترتيب الخط الزمني من جديد فوجدت أنني فهمت نصفه فقط بشكل صحيح.

لنبدأ بالخلفية: نظام تجارب DLT هو نافذة تنظيمية مؤقتة يمنحها الاتحاد الأوروبي لبنية تحتية لتسوية معاملات DLT. تتيح لهذه الجهة أن تقوم في آنٍ واحد بعمليتي مطابقة/توجيه التداول والتسوية، دون الحاجة للبحث عن جهة إيداع مركزية للأوراق المالية بشكل منفصل كما في النماذج التقليدية. أما 21X فهي شركة ألمانية، وبنهاية 2024 أصبحت أول جهة تحصل على ترخيص من هذا النوع يُسمى "نظام تسوية تداول DLT" (DLT-TSS)، وتشغله على شبكة Polygon.

أما تعاون Dusk مع 21X، فالصياغة الرسمية تقول: "سيَنضم Dusk باعتباره طرفًا مشاركًا (trade participant)"، وفي الوقت نفسه: "حصلنا على حق الإعفاء التنظيمي لاستخدامه، ويحصلون هم على بنية سلسلة كتل على مستوى مؤسسي من جانبنا". أي أن الترخيص يبقى دائمًا في يد 21X، بينما يدخل Dusk عبر التعاون للاستفادة من هذا الإعفاء التنظيمي—وليس لأنه حصل بنفسه على ترخيص DLT-TSS. وهذا يختلف تمامًا عمّا انطبعت به أولاً.

وبالعودة خطوة إلى الوراء: في مارس 2024 كان Dusk وNPEX بالفعل يجهزان طلبًا مشتركًا للحصول على مؤهلات نظام تجارب DLT، ما يعني أن مسار التنظيم هذا قد فكر فيه Dusk لمدة عامين أو أكثر، وليس مجرد اندفاع لحظة. لكن حتى أحدث المعلومات العامة التي تمكنت من العثور عليها، لا يظهر على اسم Dusk نفسه أي سجل لترخيص DLT-TSS مستقل—بينما تذكر صفحة موقع 21X الرسمي بوضوح أنه، حتى الآن، لا تمتلك هذا الترخيص سوى جهتان: 21X وCSD Prague في براغ.

وقد وضعتُ لنفسي معيارًا للحكم: إذا خلال سنة واحدة ظهر على اسم Dusk (أو على اسم NPEX المرتبط به ارتباطًا عميقًا) ترخيص مستقل لـ DLT-TSS أو ترخيص نظير، فهذا يعني أن مسار التنظيم قد تم بالفعل بالكامل. أما إذا استمرت الأمور في التوقف عند "الانضمام عبر طرف مشارك باستخدام ترخيص جهة أخرى"، فسيؤثر ذلك على قوة القصة وموثوقيتها؛ وستبدو أقرب إلى انتظار ترخيص خاص بها بدل أن تكون قد حصلت عليه بالفعل.

عند قراءة اتفاقيات الاقتراض بسعر فائدة ثابت، كنت أركز فقط على رقم APY، حتى أنني حللت منطق التصفية بالكامل لـ @TermMax ، ثم أدركت أن الشيء الذي يستحق التدقيق ليس الفائدة نفسها، بل كيف يتعامل مع مسألة "عدم القدرة على السداد عند الاستحقاق".

منطق التصفية في اتفاقيات الإقراض التقليدية يكون قاسياً: إذا انخفضت قيمة الضمان عن حدّ معيّن، يتم بيع الضمان مباشرة لتحويله إلى عملة مستقرة، وكلما زادت التقلبات زادت الانزلاقات، وقد يخسر كل من المقترض والمُصفّي. يعتمد TermMax على فكرة التسليم العيني (physical delivery): في حال حدوث ظروف شديدة أو نقص السيولة، يتم تسليم الضمان مباشرة إلى المُقرض، بدل أن يتم أولاً ضغط السوق على الضمان ثم تتم التسوية. الفكرة وراء ذلك هي أنه بدلاً من بيع الأصول بسعر متدنٍّ في ذروة الهلع مما قد يسبب ضرراً إضافياً، الأفضل أن تكون عملية التصفية عبارة عن تسليم أصول محدد مرة واحدة.

كما أن هيكل العملات الثلاثية لديه بُني حول هذا المنطق: يقوم المقترض بترميز (إصدار) أصول الضمان عبر GT (وهو ERC-721 يجمع الضمان والديْن في مركز واحد)، وفي الوقت نفسه يصدر FT لتمثيل أصل الدين والفوائد المطلوب سدادها عند الاستحقاق. يتم تقسيم FT إلى جزأين: جزء يمثل المبلغ الأصلي وجزء يمثل الفائدة. يتم بيع جزء الفائدة للمُقرض لتحويله إلى XT، بينما يُترك جزء رأس المال للمقترض. وبدلاً من أن يتحرك الاقتراض الدوري عبر عدة بروتوكولات بشكل متكرر، تم تقليص ذلك إلى معاملة واحدة.

كما أن هذا التصميم تم دمجه الآن أيضاً في سيناريوهات ضمان الأسهم المُرمّزة، حيث جرى على سلسلة BNB تجربة استراتيجيات الخيارات والمقابلة (covered call/covered strategies) لبعض الأصول، ما يشير إلى أنه لا يستهدف فقط الأصول المشفّرة الأصلية.

لكن يجب أن أوضح: إن آلية التسليم العيني هذه تعمل حالياً بشكل أساسي ضمن التقلبات الاعتيادية. الاختبار الحقيقي هو في ظل الظروف القصوى: هل يمكن للضمان أن يُسلّم بنجاح وفي الوقت المحدد إلى يد المُقرض؟ وهل تكفي السيولة لدعم هذه الحلقة في ظل النشر عبر السلاسل (cross-chain)؟ لم أرَ بيانات كافية تمتد لفترات طويلة.

في المرحلة المقبلة سأتابع مؤشرين: سجل التسليم الفعلي لمراكز GT تحت ظروف السوق المتطرفة، وما إذا كانت سيولة التصفية على كل سلسلة تتقدم بالتزامن. يمكن كتابة الالتزام بفائدة ثابتة بسهولة، لكن قدرة التسليم هي الاختبار الحقيقي.#TermMax

لدي عادة: لا أنظر أولاً إلى ما تقوله الـ KOL عن المشروع، بل أذهب إلى الموقع الرسمي للبحث عن أرقام يمكن التحقق منها. في الأسبوع الماضي قرأت الموقع الرسمي لـ Dusk بعناية، ولاحظت بعض الأرقام؛ وبعد التحقق منها شعرت بتعقيد الأمور.
يذكر الموقع أن هناك «حجم إصدار مؤكد» يتجاوز 300 مليون يورو، و«وصولاً إلى مستثمرين» يتجاوز 50 ألفاً، و«كمية رهونات DUSK» تتجاوز 210 مليون.
أول ردة فعل لم تكن حماساً بل شك. ما معيار رقم 300 مليون يورو؟ هل المقصود بالإصدار المؤكد هو إصدارات أصول تمت فعلاً على السلسلة وتمت، أم أنه مجرد توقيع خطاب نوايا دون أن يتم رفعه على السلسلة بعد؟ الفرق بين الأمرين كبير جداً: الأول يحدث فعلياً، والثاني هو مجرد رقم داخل «أنبوب» انتظار التنفيذ.
لكنني قارنت الرقم بما تقوله مشاريع كثيرة في السوق وتكتفي عادةً بالشعار القائل «بوابة RWA على مستوى تريليون»؛ فبدلاً من أن أرى في 300 مليون يورو أنه كبير جداً، وجدت أن المثير للاهتمام فيه هو أنه رقم يمكن مساءلته. يمكنك أن تسأل عن المعيار المتبع، وعن أي أصول تشكل الـ 300 مليون هذه، وعن ما إذا كانت هناك نشاطات في السوق الثانوية بعد الإصدار. الأرقام التي يمكن مساءلتها تملك معلومات أكثر من سردٍ ضخم لكنه غامض.
الأمر الذي غيّر حكمي فعلاً هو شيء آخر. لم تكن خريطة طريق Dusk في السنوات الأخيرة تبدّل السرد كل بضعة أشهر، بل كانت تبني الطبقات واحدة تلو الأخرى: طبقة الإجماع، وطبقة التنفيذ، وإصدار الأصول، والتداول، وواجهات التنظيم. الإيقاع بطيء، لكن في كل خطوة يمكنك العثور على سجل مطابق داخل تحديثات الهندسة. @Dusk
إذا كان المشروع ما زال يقضم أشياء غير «مُلفتة» في سنوات لا تحظى بالزخم—مثل التصاريح وقواعد الأصول وتفاصيل التسوية—فغالباً ليست دالة هدفه هي التركيز على الاهتمام قصير الأجل. أرغب في منح مثل هذا المشروع وقتاً إضافياً، ليس لأنه حتماً سينجح، بل لأن ما يقوم به إذا نجح فسيكون شيئاً صعباً جداً تقليده.
#dusk $DUSK

ترقية Aegis في ذلك اليوم $DUSK —كنت أراقب لوحة العقدة ليلًا حتى الفجر. رسميًا الأمر صريح جدًا: إنها "ترقية إلزامية تستهدف جميع مشغلي العقد". إذا لم تُجرِ الترقية، فبعد تفعيل الانقسام الصلب (hard fork) ستخرج العقد مباشرةً من الشبكة، دون فترة انتقالية يمكن اختيارها.
قلبتُ سجل تحديثات Rusk v1.7.0، فوجدت إصلاحًا غير بارز لكنه مهم جدًا مخبأ داخل هذه الترقية: في dusk-wallet-core "منع حدوث التفاف (rollover) عند تجاوز u64 عند تجميع أرصدة Phoenix". وبعبارة بسيطة: كود المحفظة السابق كان عند تجميع أرصدة Phoenix (نموذج الحسابات المشفّر لحسابات UTXO الخاص بـ Dusk) يواجه—نظريًا—خطر حدوث overflow ثم "الالتفاف إلى رقم صغير جدًا أو حتى رقم خاطئ"، وهذه الترقية تسد هذا الخلل. وفي نفس الدفعة من التغييرات أيضًا تم نقل التحقق من إثباتات PLONK إلى إصدار V3، وإضافة حد لحجم جسم طلبات HTTP للوقاية من هجمات استنزاف الذاكرة (memory DoS)، وسد في مسار الاستعادة ثغرة اجتياز مسارات ZIP غير آمنة عند الكتابة—وهذه كلها إجراءات نموذجية لـ "تعزيزات أمنية" لأنظمة جاهزة للإنتاج؛ ليست تحديثات وظيفية بقدر ما هي إزالة للمخاطر.
كعامل تشغيل للعقد، ما يهمني أكثر هو مخاطرة نافذة الترقية نفسها: كتلة التفعيل على الشبكة الرئيسية لـ Aegis هي 3,590,904، وعلى شبكة الاختبار 2,773,727؛ فهي نقطة انقسام صلب محددة مسبقًا بحسب ارتفاع الكتل، وليست "نافذة زمنية مرنة" من نوع متى ما اكتملت الترقية تنفذ. إذا لم تُنهِ مجموعة من العقد الترقية قبل بلوغ هذا الارتفاع، فهل ستظهر الشبكة بشكلٍ مؤقت تباينًا في توافق الانقسام؟ الرواية الرسمية تقول: "هذا تحديث بنية تحتية لتحسين مسار DuskEVM ولا يتضمن اقتصاديات الرموز". يبدو أن التأثير قابل للسيطرة، لكن الإلزام بالانقسام الصلب نفسه—بالنسبة لشبكة ليست لامركزية عالية بعد، وعدد العقد فيها ليس كبيرًا—يبقى دومًا اختبارًا حقيقيًا لمخاطر التنسيق.
#dusk
هذه الترقية تمت بسلاسة، وفي نوع من المعنى تم—وقبل التشغيل الرسمي لـ DuskEVM—إجراء اختبار ضغط على إجماع الطبقة الأساسية والتخزين من خلال @Dusk . لم تخرج الترقية عن المسار أو تسبب مشاكل، لكن عبارة "الانقسام الصلب الإلزامي" هذه الأربعة أحرف تستحق أن يراجعها بعناية كل من يستعد لتشغيل عقدة أو يعتمد على تسوية Dusk التي تعتمد الحتمية.

#dusk كثير من الناس عند أول مرة يَتعرّفون على مصطلح RWA يفترضون أن له طريقة واحدة فقط: تحويل أصل واقعي إلى «حزمة» على شكل توكن، ثم إدراجه للتداول على السلسلة. كنت أفهمه هكذا أيضًا، إلى أن رأيت @Dusk يَفصل بين «التوكننة» و«الإصدار الأصلي» كأمرين مختلفين، عندها أدركت أن هناك تفصيلة سهلة الإغفال تكمن في الأمر.
التوكننة، ببساطة، هي وضع طبقة مرآة رقمية لأصل موجود بالفعل: عمارة، أو سند دين، أو صندوق استثماري… يكون موجودًا أولًا ضمن النظام التقليدي، ثم يقوم وسيط ما بتغليفه وتحويله إلى سندات/إيصالات على السلسلة. وبين هذا وذاك توجد قفزة طبيعية في الثقة: ما تثق به ليس كود السلسلة، بل هل الجهة التي تقوم «بالتغليف» ستلتزم بصدق—وهل تمتلك فعلًا الأصول الأساسية المطابقة. مهما كانت السلسلة «نظيفة» فلن يختفي هذا الاعتماد بطبيعته.
أما الإصدار الأصلي فهو طريق آخر—جعل دورة حياة الأصل تبدأ منذ البداية على السلسلة نفسها: الإصدار، والتداول، والتسوية، وتوزيع الحقوق، مع تقليل الرجوع إلى النظام التقليدي وما يتضمنه من مراحل وسيطة غير شفافة قدر الإمكان. هذا لا يعني أن المؤسسات التقليدية ستختفي، بل يعني أنه عندما تكون المؤسسة نفسها تملك المؤهلات والتصميم المناسب للمنتجات، تستطيع البنية التحتية على السلسلة أن تتولى المزيد من العمليات التي كان يُفترض أن تخص الأصل نفسه، بدل أن تكون مجرد طبقة مرآة بعد وقوع الشيء.
البنية التحتية التي يقدمها Dusk تتمثل وظيفتها في دعم المسارين معًا—إتاحة التوكننة كشكل انتقالي، وكذلك استيعاب سير عمل الإصدار الأصلي عند نضوج الظروف. وأرى أن هذا الموقف «لا يَفترض إجابة وحيدة» صريح إلى حدٍّ ما؛ فإيقاع الامتثال لدى المؤسسات، وتصميم المنتجات، والتراخيص التنظيمية كلها تختلف، ولا يمكن حشر كل السيناريوهات في قالب واحد.
يبدو الإصدار الأصلي هدفًا بعيدًا، لكنه في الحقيقة يشير إلى سؤال بسيط جدًا: لمن ينبغي أن يثبت «حقيقة» أصلٍ ما؟ والإجابة التي يراهن عليها $DUSK هي—قدر الإمكان جعل عملية الإثبات نفسها تتم على السلسلة، بدل الاعتماد على مجرد وعد من وسيط ما.

#dusk $DUSK بصراحة، في البداية كنت متعبًا قليلًا من كلمات "إطلاق الأصول على السلسلة (RWA)"—فقد سمعنا خلال هذه السنوات الكثير من المشاريع ترفع هذا الشعار، وغالبًا ما ينتهي الأمر في الواقع بصورة شاشة وخطاب بضع جُمل من الرؤية، لا يحتمل التدقيق عن قرب، ناهيك عن اجتياز تفحّص الجهات التنظيمية. لكن هذه المرة، عندما قرأت تفاصيل التعاون بين @dusk والبورصة الهولندية NPEX، تغيّر موقفي.
NPEX ليس مصطلحًا جديدًا مخترعًا. بل هي بورصة مرخّصة تخضع لإشراف هيئة أسواق المال في هولندا (AFM)، وتمتلك أيضًا تراخيص MTF وتراخيص وسيط وECSP—وخلف هذه الاختصارات توجد منظومة تنظيم مالي أوروبية حقيقية موجودة منذ سنوات وتم اختبارها مرارًا وتكرارًا، وليست مفهوماً يتم تجميعه عشوائيًا، ولا صفة يمكن الادّعاء بها عبر ورقة “whitepaper”. في هذه الخطة التعاونية، سيتم نقل أصول تتجاوز 300 مليون يورو تدريجيًا إلى سلسلة Dusk، أما الطبقة التطبيقية التي ستستوعب هذه الأصول فهي Dusk Trade.
تم تقديم Dusk Trade على أنه «وسيط مالي من نوع جديد»، يعمل فوق DuskEVM. هدفه تحويل المنتجات المالية التقليدية مثل صناديق سوق المال وETFs والسندات إلى أصول على السلسلة يمكن امتلاكها فعليًا وتسويتها فورًا، ويمكن أيضًا أن تتكامل مع أنماط اللعب مع DeFi. كما أنه يبني بنيته الامتثالية وفقًا للأنظمة ذات الصلة في الاتحاد الأوروبي، باتجاه MTF والمنصات الاستثمارية الخاضعة للرقابة، بدلًا من إطلاق الخدمة أولًا ثم استكمال المستندات لاحقًا. إن اختيار الترتيب هذا بحد ذاته يكشف عن توجهات معينة.
أدركت أن هذا السرد ليس له أي صلة تقريبًا بـ «إصدار عملة من فريق مجهول»—بل يشبه إلى حد كبير المؤسسات المالية التقليدية وهي تختبر بحذر بابًا جديدًا. وعلى الجانب الآخر من هذا الباب، يجب أن توجد رخصة وتدقيق ومسار امتثال قابل للتتبع يدعم ذلك. @Dusk يريد أن يصبح هذه السلسلة نفسها—وليس أن يلتف عليها كطريقة مختصرة. ولهذا السبب أنا أيضًا مستعد لأن أخصص وقتًا لفهمه.
هذه ليست قصة ستتحقق بين ليلة وضحاها. فالتنظيم المالي في أوروبا لم يكن يومًا لعبة سريعة. الرخص والتدقيق والتنسيق عبر الحدود يحتاجان وقتًا، وأي وعود تتخطى هذه الخطوات تستحق قدرًا أكبر من الشك. ومع ذلك، عندما رأيت عبارة «بورصة مرخّصة» و«تسوية على السلسلة» للمرة الأولى تُكتب في بيان تعاون واحد، فمن الجدير بالمتابعة لمعرفة كيف ستترجم إلى واقع لاحقًا—خصوصًا في يوم انتقال تلك الأصول بقيمة 300 مليون يورو فعليًا.

$BABY فترة فك الارتباط: بعد أن درست تصميمها، وجدت أنها تُجري مقايضة مُتعمدة بين حماية أمان الشبكة وسيولة المستخدمين
في بروتوكولات الرهن، غالبًا ما يُناقش تصميم فترة فك الارتباط على أنه مسألة تتعلق بتجربة المستخدم؛ الانتظار لفترة طويلة مزعج، ونرغب في أن يكون أسرع. لكنني عندما نظرت إلى منطق فترة فك الارتباط في @BabylonLabs_io بجدية من زاوية التصميم الأمني، اكتشفت أن مبرر وجودها أعمق بكثير من مجرد القيود على السيولة، بل إن هذا التصميم يتضمن مقايضة أعتقد أنه من المهم توضيحها بشكل جدي.
أهم وظيفة لفترة فك الارتباط هي منح آلية الحجز/الخصم (slashing) وقتًا للتنفيذ. إذا قام مزوّد نهائي (finality provider) بتوقيع مزدوج (double-sign)، يجب رصد الأدلة، ثم رفعها على السلسلة، ثم استدعاء معاملة الحجز. إن تنفيذ هذه السلسلة من العمليات على السلسلة يستغرق وقتًا. وبدون فترة فك الارتباط، يمكن لمدقّق خبيث أن يسحب كل BTC المرهون قبل أن تُكتشف الأدلة وتُقدّم، عندها تصبح آلية الحجز بلا معنى عمليًا. من حيث الجوهر، تقول فترة فك الارتباط: يمكن أن يخرج BTC الخاص بك، لكن عليك الانتظار هذه المدة؛ وخلال هذه الفترة، إذا تبيّن أن المدقّق الذي فوّضته ارتكب سلوكًا خبيثًا، فلا يزال هناك وقت لتنفيذ العقوبة. #baby
انطلاقًا من هذا المنظور، فإن فترة فك الارتباط ليست تنازلًا لتحسين تجربة المستخدم، بل هي شرط تمهيدي لكي تعمل منظومة الأمان بأكملها. بدون فترة فك الارتباط، لن يكون للحجز أسنانًا (أي لا يردع بجدية)، وعندما لا تكون تهديدات الحجز حقيقية، تنخفض القيود على سلوك المدقّقين بشكل كبير.
لكن توجد مقايضة أعتقد أنه ينبغي أن تُقال بوضوح. كلما كانت فترة فك الارتباط أطول، اتسع «نافذة الأمان» وأصبحت آلية الحجز أكثر موثوقية. وكلما كانت أقصر، تحسّنت سيولة المستخدمين وقلت الاحتكاكات المرتبطة بالمشاركة. حدّدت Babylon أقصر فترة فك ارتباط بحوالي 7 أيام؛ هذا الرقم هو نقطة توازن بين هدفين، وليس مجرد قيد تقني بحت.
بالنسبة لحاملي BTC على المدى الطويل، فإن 7 أيام تكاد لا تُحدث فرقًا. أما بالنسبة للمتداولين على المدى القصير، فهي تكلفة سيولة حقيقية. وهذا يعني أن رهن Babylon سيُفرز تلقائيًا في بُنية مستخدميه من يملكون أفقًا زمنيًا طويلًا، بدلًا من الأموال قصيرة الأجل. ومن منظور استقرار البروتوكول، فإن هذا الترشيح للمستخدمين مفيد: لأن الحاملين على المدى الطويل لن يفكوا الرهن بكميات كبيرة عند تقلبات السوق، وبالتالي تكون استقرار TVL أعلى.