#dusk $DUSK @Dusk تابعت باستمرار شيئًا واحدًا في التطوير الأخير لشركة Dusk، وليس هو التشفير بحد ذاته.
بل هو الجهد المبذول لجعل نفس التشفير يعمل بكفاءة أكبر.
لم تُلغِ أعمال تحسين أداء PLONK الأساسيات الحسابية أو تنسيق النسخ (transcript) أو تنسيق الإثبات (proof). بدلًا من ذلك، سعى Dusk إلى معالجة العمل الهدر حولها: تخزين البيانات الحتمية مؤقتًا (caching)، وتجميع عمليات العكس (inversions) وعمليات MSM، وتوازي مهام FFT المستقلة، وتجنب الحسابات المتكررة.
كانت النتيجة لافتة لاهتمامي: انخفض وقت الإثبات بنسبة 58%، وبمعدل وصول تقريبًا إلى 2.4x في إنتاجية الإثبات، وأصبحت عملية التحقق أسرع بنسبة 44%، وتم تجميع (compilation) المشروع بشكل أسرع بنسبة 25%.
لكن بصراحة، الأرقام في الغالب ثانوية.
ما يهمني هو ما تكشفه هذه الأرقام عن المشكلة التالية.
يمكن أن يكون الخصوصية قوية رياضيًا ومع ذلك تصبح غير عملية إذا لم يكن بالإمكان مواكبة عمليات الإثبات أو التحقق أو التنفيذ.
أرى سؤالًا مشابهًا في اختبارات DuskEVM × DuskDS. يتم دفع نماذج تنفيذ وحالات مختلفة عبر أحمال مختلطة بدل الحكم عليها بشكل منفصل.
هذا يبدو أقرب إلى التحدي الحقيقي: ليس ما إذا كان كل جزء يعمل، بل ما إذا كانوا يواصلون العمل معًا عندما يصبح النظام مزدحمًا.
لذا بدأت أتساءل عما إذا كانت أصعب مشكلة هندسية لدى Dusk لم تعد هي جعل الخصوصية تعمل.
بل في جعل الخصوصية والتنفيذ والتنسيق تبدو شبه غير مرئية للمستخدم.
على الأرجح هذا هو الاختبار الأكثر إثارة للاهتمام.

#dusk