أحيانًا أجد نفسي أفترض أنَّه إذا صممتَ وقت تشغيل (runtime) أفضل من الصفر، فسينتقل المطورون إليه تلقائيًا. هكذا نظرتُ أول مرة إلى التحوّل من Zedger إلى Hedger على Dusk. كانت الفكرة الأصلية تبدو وكأنها تُفضِّل بيئة تنفيذ أصلية ونظيفة مبنية خصيصًا للتوافق مع الخصوصية التي لا تكشف المعرفة (zero-knowledge)، وخالية من اختيارات التصميم القديمة.

ثم نظرتُ إلى التحوّل نحو نهج EVM أولًا، وأدركتُ أنه يعكس حلًّا وسطًا عمليًا للغاية. الجزء اللافت ليس أيُّ آلة افتراضية تنفّذ التعليمات أسرع. يكمن الفرق في توزيع المطورين. إن بناء بدائل برمجية (primitives) تشفيرية مخصّصة داخل بيئة تشغيل معزولة يُجبر كل منشئ على تعلّم نموذج جديد، بينما تضمين الخصوصية ضمن أدوات متوافقة مع EVM يضع الأمر حيث توجد السيولة بالفعل. يعتمد نمو النظام البيئي العام على قابلية التراكيب القياسية (standardized composability)، في حين تُقدّم البيئات التشغيلية المخصّصة نقاءً معماريًا. ومع ذلك تظلّ المنطقية نفسها: بيئات التنفيذ ليست سوى طبقات تنسيق لحالةٍ مشتركة.

في النهاية، يُعدّ الانتقال إلى التوافق مع EVM اعترافًا بأن التوزيع (distribution) أهم من الكفاءة النظرية. لكن هذا الاختيار يعيد حدود الثقة إلى أرضٍ مألوفة. التحدي الحقيقي هو ما إذا كان بإمكانك الحفاظ على الامتثال للـ zero-knowledge على نطاق واسع دون وراثة كل اختناقات التنفيذ القياسية في EVM. ما زلتُ غير متأكد إن كان جلب الخصوصية إلى أدوات Ethereum أصعب من إقناع منشئي Ethereum بالثقة في بيئة تشغيل جديدة.

#dusk $DUSK @Dusk