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