#dusk $DUSK @Dusk
في السوق توجد مجموعة من المشاريع ترفع شعار “متوافق مع ZK” بمجرد الكلام؛ لكن عندما تُدقّق بجدية في تفاصيل طبقة التنفيذ، يتضح أن أغلبها مجرد زينة سطحية، حيث يتم تحويل ZK إلى “رقعة إضافية” بدل أن يكون قدرة مدمجة على مستوى القاعدة. كثيرون يقارنون فقط زمن توليد إثباتات ZK، لكنهم قلّما ينتبهون إلى كلفة الـgas الإضافية عند استدعاء منطق ZK داخل العقود، وكذلك تأخر الاستدعاء. هذه التكاليف “الخفية” داخل بيئة التنفيذ هي التي تحدد فعليًا ما إذا كانت تطبيقات التمويل الخصوصي يمكنها أن تعمل على نطاق واسع.
تعتمد أغلب السلاسل العامة نهجًا “بالملحقات” للتحقق من ZK: إما الاعتماد على عقود مُسبقة التهيئة (precompiled contracts)، أو تحميل عمليات الإثبات الثقيلة بالكامل إلى خارج السلسلة. هذا المسار سهل العتبة وسريع في النشر، لكنه ذو عيوب واضحة: في كل مرة يتم فيها إجراء تحقق ZK، يجب على العقد بدء استدعاء عبر وحدات متعددة؛ ومع كل طبقة تفاعل إضافية، تزداد تكلفة الـgas. وعبر اختبارات فعلية، غالبًا ما تبدأ الزيادة في الـgas لكل استدعاء من عشرات الآلاف وتمتد إلى مئات الآلاف. وإذا تعرضت خدمات خارج السلسلة للازدحام، فإن تأخر عودة نتيجة الإثبات إلى السلسلة سيؤدي مباشرةً إلى تعثر أعمال السلسلة؛ كما أن نقاط الأعطال تكون متفرقة، وكلما طال الرابط زادت احتمالية حدوث أخطاء. جوهر الأمر أن ZK مجرد ميزة إضافية “للزينة” وليست أولوية أعلى من منطق الأساس داخل السلسلة.
أما بنية آلة Dusk، فتسلك عكس ذلك تمامًا؛ إذ تُنزِل كامل قدرات التحقق التشفيري إلى طبقة وقت التشغيل الأساسية. يتم تغليف منطق التحقق الخاص بأنواع مختلفة من براهين المعرفة الصفرية السائدة، وخوارزميات التجزئة، ومكونات التوقيعات المجمّعة، داخل دوال المضيف للنظام (host) نفسها. يمكن للعقود استدعاؤها مباشرةً، ما يلغي هدر التكلفة الناجم عن القفز بين precompiles أو عن المراسلات ذهابًا وإيابًا مع خارج السلسلة. ومع وجود منطق تحقق ZK نفسه، يمكن ضغط استهلاك الـgas على مستوى العقد إلى ما يقارب 30%. كما يُختزل تأخر الاستدعاء إلى مستوى “بالملي ثانية”.
وليس ذلك فحسب: لم يتم اعتماد نموذج ذاكرة EVM كما هو، بل تمت إعادة تصميم تخطيط الذاكرة اعتمادًا على WASM. نموذج ذاكرة EVM الأصلي مُحسّن للعقود الذكية العادية، لكن عند تنفيذ عمليات ZK، فإن القراءة والكتابة عالية التواتر تولّد نسخًا متكررة غير ضرورية من الذاكرة. وفي بعض سيناريوهات الإثبات المعقدة، يمكن أن تقفز الذاكرة المستخدمة عدة مرات. بالمقابل، فإن حبيبية ذاكرة WASM أكثر مرونة، وقادرة على التكيف مع خصائص ZK ذات دورات تجزئة هائلة وعمليات كثيرة الحدود (polynomial)؛ وقد ينخفض استخدام الذاكرة بما يصل إلى 40%، مع تحسن ملحوظ في كفاءة التنفيذ.
والأهم من ذلك هو “الترابط الشامل”: قدرات ZK ليست مكوّنًا معزولًا. يتم ربط واجهات العقود وبدائيات المعاملات السرية على السلسلة بحيث تُغلق حلقة الإثبات والتحقق ونقل الأصول والمنطق الخاص بالخصوصية ضمن مسار معاملة واحدة؛ لا حاجة إلى تجميع عدة أنظمة مختلفة معًا.
في السوق توجد مجموعة من المشاريع ترفع شعار “متوافق مع ZK” بمجرد الكلام؛ لكن عندما تُدقّق بجدية في تفاصيل طبقة التنفيذ، يتضح أن أغلبها مجرد زينة سطحية، حيث يتم تحويل ZK إلى “رقعة إضافية” بدل أن يكون قدرة مدمجة على مستوى القاعدة. كثيرون يقارنون فقط زمن توليد إثباتات ZK، لكنهم قلّما ينتبهون إلى كلفة الـgas الإضافية عند استدعاء منطق ZK داخل العقود، وكذلك تأخر الاستدعاء. هذه التكاليف “الخفية” داخل بيئة التنفيذ هي التي تحدد فعليًا ما إذا كانت تطبيقات التمويل الخصوصي يمكنها أن تعمل على نطاق واسع.
تعتمد أغلب السلاسل العامة نهجًا “بالملحقات” للتحقق من ZK: إما الاعتماد على عقود مُسبقة التهيئة (precompiled contracts)، أو تحميل عمليات الإثبات الثقيلة بالكامل إلى خارج السلسلة. هذا المسار سهل العتبة وسريع في النشر، لكنه ذو عيوب واضحة: في كل مرة يتم فيها إجراء تحقق ZK، يجب على العقد بدء استدعاء عبر وحدات متعددة؛ ومع كل طبقة تفاعل إضافية، تزداد تكلفة الـgas. وعبر اختبارات فعلية، غالبًا ما تبدأ الزيادة في الـgas لكل استدعاء من عشرات الآلاف وتمتد إلى مئات الآلاف. وإذا تعرضت خدمات خارج السلسلة للازدحام، فإن تأخر عودة نتيجة الإثبات إلى السلسلة سيؤدي مباشرةً إلى تعثر أعمال السلسلة؛ كما أن نقاط الأعطال تكون متفرقة، وكلما طال الرابط زادت احتمالية حدوث أخطاء. جوهر الأمر أن ZK مجرد ميزة إضافية “للزينة” وليست أولوية أعلى من منطق الأساس داخل السلسلة.
أما بنية آلة Dusk، فتسلك عكس ذلك تمامًا؛ إذ تُنزِل كامل قدرات التحقق التشفيري إلى طبقة وقت التشغيل الأساسية. يتم تغليف منطق التحقق الخاص بأنواع مختلفة من براهين المعرفة الصفرية السائدة، وخوارزميات التجزئة، ومكونات التوقيعات المجمّعة، داخل دوال المضيف للنظام (host) نفسها. يمكن للعقود استدعاؤها مباشرةً، ما يلغي هدر التكلفة الناجم عن القفز بين precompiles أو عن المراسلات ذهابًا وإيابًا مع خارج السلسلة. ومع وجود منطق تحقق ZK نفسه، يمكن ضغط استهلاك الـgas على مستوى العقد إلى ما يقارب 30%. كما يُختزل تأخر الاستدعاء إلى مستوى “بالملي ثانية”.
وليس ذلك فحسب: لم يتم اعتماد نموذج ذاكرة EVM كما هو، بل تمت إعادة تصميم تخطيط الذاكرة اعتمادًا على WASM. نموذج ذاكرة EVM الأصلي مُحسّن للعقود الذكية العادية، لكن عند تنفيذ عمليات ZK، فإن القراءة والكتابة عالية التواتر تولّد نسخًا متكررة غير ضرورية من الذاكرة. وفي بعض سيناريوهات الإثبات المعقدة، يمكن أن تقفز الذاكرة المستخدمة عدة مرات. بالمقابل، فإن حبيبية ذاكرة WASM أكثر مرونة، وقادرة على التكيف مع خصائص ZK ذات دورات تجزئة هائلة وعمليات كثيرة الحدود (polynomial)؛ وقد ينخفض استخدام الذاكرة بما يصل إلى 40%، مع تحسن ملحوظ في كفاءة التنفيذ.
والأهم من ذلك هو “الترابط الشامل”: قدرات ZK ليست مكوّنًا معزولًا. يتم ربط واجهات العقود وبدائيات المعاملات السرية على السلسلة بحيث تُغلق حلقة الإثبات والتحقق ونقل الأصول والمنطق الخاص بالخصوصية ضمن مسار معاملة واحدة؛ لا حاجة إلى تجميع عدة أنظمة مختلفة معًا.