#dusk $DUSK @Dusk قبل يومين جرّبت تشغيل عقدة من عقد Dusk. بعد تثبيت node-installer، عندما أرسلت أمر التشغيل توقفت يدي فوق زر الإدخال لحظةً من التردد. لم يكن خوفًا من أن أخطئ في العملية، بل خوفًا من تكرار ما حدث في المرات السابقة—أن يتوقف النظام بعد أسطر قليلة من السجل، ثم أكتشف أن التوثيق لا يطابق الكود.

بعد بدء التشغيل، بدأ rusk في تمرير السجلّات. مرحلة Validation ومرحلة Ratification تتناوبان بالتنفيذ. تأتي أولًا مرحلة Validation، حيث يقوم فريق من أعضاء اللجنة بفحص صحة الكتل المرشحة؛ ثم تأتي Ratification، حيث تؤكد مجموعة أخرى من أعضاء اللجنة نتائج التحقق وتُقر أخيرًا الكتلة. في السجل، في كل دورة تظهر أرقام Round وIteration، وفواصل إصدار الكتل ثابتة. بقيت أحدّق في الشاشة أكثر من عشر دقائق؛ ارتفاع ارتفاع الكتل كان مستمرًا دون انقطاع. ظلال الاختبار السابقة—مثل “التوقف عند منتصف التشغيل” التي كانت تحدث في شبكات اختبار أخرى—انتهت هنا أخيرًا.

ثم ذهبت لتفقد مستودع rusk. 8025 commit، خط أنابيب CI يشغّل clippy مع nightly test، وحتى الفريق كتب بنفسه cargo-dusk-analyzer لإجراء تحليل ساكن. في أداة النشر dsk-deploy-cli لاحظت تفصيلًا: Phoenix وMoonlight عبارة عن معاملات/وسائط سطر أوامر منفصلة. على نفس السلسلة، مساران مختلفان للمعاملات يتم استدعاؤهما بشكل مستقل. عندما وجدت issue وضع فيها صاحبها بيانات الغاز، كان تحويل Moonlight يستهلك حوالي 80 ألف gas؛ أما من Moonlight إلى Phoenix فيستهلك 2556万 gas—فرق ثلاثمئة ضعف. وهذه هي التكلفة الحقيقية لحسابات إثباتات ZK.

بعدها فتحت البحث في طبقة الشبكة. Kadcast هو تنفيذ رسمي بلغة Rust، وجميع المستودعات البالغ عددها 107 مكتوبة بالكامل بلغة Rust. مستودع plonk أيضًا يضم 872 commit، والفريق كتب كل شيء بنفسه، وليس مجرد تعديل بسيط على مكتبة جاهزة ثم تشغيلها.

ثم بحثت في خلفية NPEX. بورصة هولندية خاضعة لرقابة AFM، تحمل تراخيص MTF وBroker وECSP، وتدير أصولًا بقيمة 300 مليون يورو. قائمة المرشحين الخاصة بـ Dusk Trade قد فُتحت بالفعل، وهم فعلًا يقومون ببناء منصة تداول RWA.

من 2018 إلى الآن، سبع سنوات، 8025 commit، 107 مستودع—كلها Rust. التزام هندسي من هذا النوع أنا فعلًا أحترمه.