بالأمس كنت أنوي التخلي عن المحاولة، لكنني حاولت تشغيل إعدادات عقدة رقم @Dusk في بيئة محلية، وفي أثناء ترجمة مستودع rusk` الأساسي على شبكة الاختبار، توقفت عند سجل مقارنة لمرحلة من حالات التوافق (consensus) المتزامن
ذهبت لأتفقد منطق رهن/تعهيد العقد (node staking) داخل وحدة consensus/staking، ولاحظت اسم متغير لافتًا جدًا: AttestationCapacity. على الفور أثار فضولي
كنت أظن أنه مجرد حقل عادي لتسجيل كمية الرهن/التخزين المؤمّن للعقدة، لكن عند تتبع سلسلة الاستدعاءات وصولًا إلى rewards_emission.rs، اكتشفت أن Dusk تستخدم بشكل مباشر استراتيجية ربط عُقدة جادة جدًا على مستوى قدرات الحوسبة
في أغلب سلاسل PoS السابقة، كانت عوائد العقدة مجرد “لعبة رأس مال”—ماذا يعني ذلك؟ يعني أنك تشتري عملات أكثر وتُقفلها مدة أطول، فتحصل على مكافآت التضخم أكثر، وحتى لو كانت خوادم العقدة معلقة على Raspberry Pi فلن يهتم أحد. لكن في كود Dusk، ربطت عائدات رهن العقدة بشكل قوي مع استجابة حسابات ZK لآلة Piecrust الافتراضية
إذا كانت العقدة تملك رصيدًا كبيرًا فقط، لكن في الجولة السابقة من توافق SA تأخرت ولو لحظة في معالجة Poseidon hash أو التحقق من إثباتات Plonk، فإن خوارزمية التناقص (attenuation) في النظام ستقوم مباشرة بخصم الوزن الديناميكي لـ AttestationCapacity
بعبارة أبسط: من يتعامل كـ“عقدة تعليق/تغيل في الخلفية” عندما لا تلحق بقدرات الحساب، سيتم تقليل أرباحه قسرًا من قبل النظام
تصميمٌ آخر مثير للاهتمام هو منطق حرق الغاز (Gas burn). ففي وحدة معالجة رسوم المعاملات fee_collector، يتم حرق Base Fee الخاص بكل معاملة امتثلت للمتطلبات وفقًا لآلية حرق على مستوى البروتوكول بشكل ثابت. أما Priority Fee فقط هو ما يتم توزيعه بالوزن على عقد الحوسبة التي تشارك فعلًا في التحقق من ZK
قدرتُ تقريبًا من سجلات القدرة الحاسوبية التي حصلتُ عليها من تشغيل شبكة الاختبار: عندما يصل تسوية أصول RWA في الطبقة العليا إلى وتيرة معاملات معينة، فإن معدل حرق Base Gas سيتصاعد بسرعة حتى يعوض تضخم مكافآت الكتل الأساسية في النظام
لم تقم المنصة بالترويج لأي مفهوم “انكماشي فائق”، بل جعلت في قلب الكود “مساهمة الحوسبة” و“توزيع الرهن” و“حرق الغاز” كنموذج مثلثي مترابط يفرض قيودًا على بعضه البعض. المشاركة في التوافق ليست مجرد جلوس لسحب أرباح، بل يجب ضغط قدرات الحتساب الحقيقية على السلسلة، وكل هذه العوائد، مربوطة بالكامل بـ $DUSK
#dusk
ذهبت لأتفقد منطق رهن/تعهيد العقد (node staking) داخل وحدة consensus/staking، ولاحظت اسم متغير لافتًا جدًا: AttestationCapacity. على الفور أثار فضولي
كنت أظن أنه مجرد حقل عادي لتسجيل كمية الرهن/التخزين المؤمّن للعقدة، لكن عند تتبع سلسلة الاستدعاءات وصولًا إلى rewards_emission.rs، اكتشفت أن Dusk تستخدم بشكل مباشر استراتيجية ربط عُقدة جادة جدًا على مستوى قدرات الحوسبة
في أغلب سلاسل PoS السابقة، كانت عوائد العقدة مجرد “لعبة رأس مال”—ماذا يعني ذلك؟ يعني أنك تشتري عملات أكثر وتُقفلها مدة أطول، فتحصل على مكافآت التضخم أكثر، وحتى لو كانت خوادم العقدة معلقة على Raspberry Pi فلن يهتم أحد. لكن في كود Dusk، ربطت عائدات رهن العقدة بشكل قوي مع استجابة حسابات ZK لآلة Piecrust الافتراضية
إذا كانت العقدة تملك رصيدًا كبيرًا فقط، لكن في الجولة السابقة من توافق SA تأخرت ولو لحظة في معالجة Poseidon hash أو التحقق من إثباتات Plonk، فإن خوارزمية التناقص (attenuation) في النظام ستقوم مباشرة بخصم الوزن الديناميكي لـ AttestationCapacity
بعبارة أبسط: من يتعامل كـ“عقدة تعليق/تغيل في الخلفية” عندما لا تلحق بقدرات الحساب، سيتم تقليل أرباحه قسرًا من قبل النظام
تصميمٌ آخر مثير للاهتمام هو منطق حرق الغاز (Gas burn). ففي وحدة معالجة رسوم المعاملات fee_collector، يتم حرق Base Fee الخاص بكل معاملة امتثلت للمتطلبات وفقًا لآلية حرق على مستوى البروتوكول بشكل ثابت. أما Priority Fee فقط هو ما يتم توزيعه بالوزن على عقد الحوسبة التي تشارك فعلًا في التحقق من ZK
قدرتُ تقريبًا من سجلات القدرة الحاسوبية التي حصلتُ عليها من تشغيل شبكة الاختبار: عندما يصل تسوية أصول RWA في الطبقة العليا إلى وتيرة معاملات معينة، فإن معدل حرق Base Gas سيتصاعد بسرعة حتى يعوض تضخم مكافآت الكتل الأساسية في النظام
لم تقم المنصة بالترويج لأي مفهوم “انكماشي فائق”، بل جعلت في قلب الكود “مساهمة الحوسبة” و“توزيع الرهن” و“حرق الغاز” كنموذج مثلثي مترابط يفرض قيودًا على بعضه البعض. المشاركة في التوافق ليست مجرد جلوس لسحب أرباح، بل يجب ضغط قدرات الحتساب الحقيقية على السلسلة، وكل هذه العوائد، مربوطة بالكامل بـ $DUSK
#dusk
