#dusk $DUSK
استمرّت عبارة "الدوال المضيفة" بالظهور في ورقة Dusk البيضاء، وكنت أتعامل معها كتفصيلٍ تنفيذي. لكن عندما قرأت قسم الأداء فعليًا، اتضح أنها قرارٌ معماري أكثر تعمّدًا من ذلك.
تشغيل ZK داخل جهاز افتراضي WASM: تشير الورقة البيضاء إلى أبحاث تُظهر أن تنفيذ WASM يمكن أن يكون أبطأ بنسبة 45-255% مقارنةً بالشفرة الأصلية للتطبيقات المعقّدة. يعود هذا إلى تكلفة إدارة الذاكرة المُؤتمَة وإلى معالجة التعليمات الإضافية داخل بيئة معزولة (سانبوكس). بالنسبة للهاش والتحقق من التوقيعات فهذا مزعج. أمّا بالنسبة للتحقق من إثباتات ZK الذي يعمل في كل معاملة، فإن بطئًا بنسبة 45-255% يُعد مشكلةً كبيرة في قابلية المعالجة.
الدوال المضيفة: تتيح Dusk مجموعة من الدوال التي تعمل أصليًا على الجهاز المُضيف، خارج نطاق عزل WASM. verify_plonk و verify_groth16_bn254 و verify_schnorr و verify_bls و hash. يستدعي العقد الذكي هذه مباشرةً؛ حيث تعمل الأعمال التشفيرية الثقيلة بسرعة أصلية. وتكون النتيجة مكرّرة عبر العقد بالطريقة نفسها التي تُجرى بها أي عملية حسابية أخرى.
فلماذا لا تفعل كل سلسلة تشغّل ZK ذلك.
إن نقل الحساب خارج الـ VM يقلّل ضمانات العزل. في نموذج تنفيذ WASM النقي، يكون العقد المعيب أو الخبيث معزولًا داخل حدود الـ VM. عندما تضيف دوالًا مضيفة، فإنك تُتيح وصولًا على مستوى النظام إلى عمليات محددة — وقد يؤدي وجود خطأ أو سوء إعداد في طبقة الدوال المضيفة إلى عواقب لا يمكن للعقد المعزول أن ينتجها وحده. أنت تتبادل العزل مقابل قابلية المعالجة.
في الحقيقة، أجد حجة كفاءة الطاقة أكثر إثارة من حجة السرعة — إذ تُقدّم الورقة البيضاء الدوال المضيفة جزئيًا كوسيلة لتقليل تكاليف الطاقة لكل عقدة، وليس فقط تقليل زمن التأخير. وهذا تأطير غير معتاد لوثيقة تصميم خاصة بسلسلة بلوك تشين.
ما لم أرَه مَشروحًا هو كيفية تعامل Dusk مع ترقيم/نسخ إصدارات الدوال المضيفة — ما إذا كان أي تغيير في سلوك الدالة المضيفة يُعد تغييرًا بروتوكوليًا يتطلب إجماعًا، أم ما إذا كان بإمكان المشغّلين تحديث التطبيقات/التنفيذات بشكل مستقل. @Dusk
$DUSK #dusk
استمرّت عبارة "الدوال المضيفة" بالظهور في ورقة Dusk البيضاء، وكنت أتعامل معها كتفصيلٍ تنفيذي. لكن عندما قرأت قسم الأداء فعليًا، اتضح أنها قرارٌ معماري أكثر تعمّدًا من ذلك.
تشغيل ZK داخل جهاز افتراضي WASM: تشير الورقة البيضاء إلى أبحاث تُظهر أن تنفيذ WASM يمكن أن يكون أبطأ بنسبة 45-255% مقارنةً بالشفرة الأصلية للتطبيقات المعقّدة. يعود هذا إلى تكلفة إدارة الذاكرة المُؤتمَة وإلى معالجة التعليمات الإضافية داخل بيئة معزولة (سانبوكس). بالنسبة للهاش والتحقق من التوقيعات فهذا مزعج. أمّا بالنسبة للتحقق من إثباتات ZK الذي يعمل في كل معاملة، فإن بطئًا بنسبة 45-255% يُعد مشكلةً كبيرة في قابلية المعالجة.
الدوال المضيفة: تتيح Dusk مجموعة من الدوال التي تعمل أصليًا على الجهاز المُضيف، خارج نطاق عزل WASM. verify_plonk و verify_groth16_bn254 و verify_schnorr و verify_bls و hash. يستدعي العقد الذكي هذه مباشرةً؛ حيث تعمل الأعمال التشفيرية الثقيلة بسرعة أصلية. وتكون النتيجة مكرّرة عبر العقد بالطريقة نفسها التي تُجرى بها أي عملية حسابية أخرى.
فلماذا لا تفعل كل سلسلة تشغّل ZK ذلك.
إن نقل الحساب خارج الـ VM يقلّل ضمانات العزل. في نموذج تنفيذ WASM النقي، يكون العقد المعيب أو الخبيث معزولًا داخل حدود الـ VM. عندما تضيف دوالًا مضيفة، فإنك تُتيح وصولًا على مستوى النظام إلى عمليات محددة — وقد يؤدي وجود خطأ أو سوء إعداد في طبقة الدوال المضيفة إلى عواقب لا يمكن للعقد المعزول أن ينتجها وحده. أنت تتبادل العزل مقابل قابلية المعالجة.
في الحقيقة، أجد حجة كفاءة الطاقة أكثر إثارة من حجة السرعة — إذ تُقدّم الورقة البيضاء الدوال المضيفة جزئيًا كوسيلة لتقليل تكاليف الطاقة لكل عقدة، وليس فقط تقليل زمن التأخير. وهذا تأطير غير معتاد لوثيقة تصميم خاصة بسلسلة بلوك تشين.
ما لم أرَه مَشروحًا هو كيفية تعامل Dusk مع ترقيم/نسخ إصدارات الدوال المضيفة — ما إذا كان أي تغيير في سلوك الدالة المضيفة يُعد تغييرًا بروتوكوليًا يتطلب إجماعًا، أم ما إذا كان بإمكان المشغّلين تحديث التطبيقات/التنفيذات بشكل مستقل. @Dusk
$DUSK #dusk
