عندما درست لأول مرة عملية خروج مُقدِّم الخدمة (provisioner) الخاصة بـ Dusk، افترضت افتراضًا بدا الآن أنه مبسّط للغاية: توقعت أن يعني فكّ الرهن (unstaking) الدخول إلى قائمة انتظار غير قابلة للتغيير لإتمام فكّ الرهن، والانتظار مدة محددة بواسطة البروتوكول، ثم استعادة السيولة الخاصة بي.
لكن هذا ليس ما يحدث حاليًا في Dusk.
تذكر الوثائق أنه لا توجد فترة انتظار يفرضها البروتوكول بعد تنفيذ معاملة فك رهن ناجحة. لكن هذا جعلني أتدقق أكثر في معنى كلمة “الخروج” (exit). إن فكّ الرهن لسداد المبلغ الأساسي (principal) وسحب المكافآت المتراكمة هما إجراءان منفصلان. هذا التمييز سهل أن يفلت من الذهن عندما تفكر في عملية الرهان (staking) على أنها سير عمل واحد لإيداع ثم سحب.
تحت الغطاء، يستخدم <t-2/> @Dusk مقدّمي الخدمة لاقتراح الكتل والتحقق منها. مشاركةهم في الإجماع احتمالية، حيث تتأثر المكافآت بالرهن النشط وبالاشتراك الفعلي، وليس بعائد ثابت. كما يميّز الشبكة بين “عقوبات” ناعمة لفشل المشاركة وبين عقوبات أشدّ للسلوك الإجماعي غير الصحيح الذي يمكن إثباته (provably invalid).
البنية هنا مهمة: دورة حياة الرهان موجودة إلى جانب متطلبات التشغيل الخاصة بمقدّم الخدمة—عقدة متصلة بالإنترنت ومُزامنة، ومفاتيح الإجماع، وتفعيلًا قائمًا على الحقبة (epoch)، ومحاسبة منفصلة للمكافآت. لذلك فـ “الخروج” ليس مجرد زرّ “بيع”؛ بل هو انتقال حالة داخل نظام إجماع حي. #dusk
بالنسبة لرأس المال المؤسسي، هذا التمييز جوهري. تخطيط السيولة لا يتعلق فقط بما إذا كان لدى البروتوكول مدة تأخير لفكّ الرهن. بل يتعلق أيضًا بما إذا كانت إدارة الحفظ (custody) وتشغيل العقدة وسحب المكافآت والتسوية ستظل قابلة للتنبؤ عندما يتعين على رأس المال التحرك بسرعة.
لهذا السبب، $DUSK تهمني أقل بوصفها أداة عائد، وأكثر بوصفها بنية تحتية يجب أن تصمد أمام ضغوط السيولة الواقعية.
وقد تحوّل سؤالي من “هل يمكنني فكّ الرهن؟” إلى:
هل يستطيع Dusk جعل سير عمل الخروج الكامل وصولًا إلى التسوية قابلاً للتنبؤ بدرجة كافية لرأس المال المؤسسي عندما يتعرض السوق للضغط؟
لكن هذا ليس ما يحدث حاليًا في Dusk.
تذكر الوثائق أنه لا توجد فترة انتظار يفرضها البروتوكول بعد تنفيذ معاملة فك رهن ناجحة. لكن هذا جعلني أتدقق أكثر في معنى كلمة “الخروج” (exit). إن فكّ الرهن لسداد المبلغ الأساسي (principal) وسحب المكافآت المتراكمة هما إجراءان منفصلان. هذا التمييز سهل أن يفلت من الذهن عندما تفكر في عملية الرهان (staking) على أنها سير عمل واحد لإيداع ثم سحب.
تحت الغطاء، يستخدم <t-2/> @Dusk مقدّمي الخدمة لاقتراح الكتل والتحقق منها. مشاركةهم في الإجماع احتمالية، حيث تتأثر المكافآت بالرهن النشط وبالاشتراك الفعلي، وليس بعائد ثابت. كما يميّز الشبكة بين “عقوبات” ناعمة لفشل المشاركة وبين عقوبات أشدّ للسلوك الإجماعي غير الصحيح الذي يمكن إثباته (provably invalid).
البنية هنا مهمة: دورة حياة الرهان موجودة إلى جانب متطلبات التشغيل الخاصة بمقدّم الخدمة—عقدة متصلة بالإنترنت ومُزامنة، ومفاتيح الإجماع، وتفعيلًا قائمًا على الحقبة (epoch)، ومحاسبة منفصلة للمكافآت. لذلك فـ “الخروج” ليس مجرد زرّ “بيع”؛ بل هو انتقال حالة داخل نظام إجماع حي. #dusk
بالنسبة لرأس المال المؤسسي، هذا التمييز جوهري. تخطيط السيولة لا يتعلق فقط بما إذا كان لدى البروتوكول مدة تأخير لفكّ الرهن. بل يتعلق أيضًا بما إذا كانت إدارة الحفظ (custody) وتشغيل العقدة وسحب المكافآت والتسوية ستظل قابلة للتنبؤ عندما يتعين على رأس المال التحرك بسرعة.
لهذا السبب، $DUSK تهمني أقل بوصفها أداة عائد، وأكثر بوصفها بنية تحتية يجب أن تصمد أمام ضغوط السيولة الواقعية.
وقد تحوّل سؤالي من “هل يمكنني فكّ الرهن؟” إلى:
هل يستطيع Dusk جعل سير عمل الخروج الكامل وصولًا إلى التسوية قابلاً للتنبؤ بدرجة كافية لرأس المال المؤسسي عندما يتعرض السوق للضغط؟
