#dusk $DUSK عند ترجمة وثائق DuskEVM $DUSK ، أدركت نقطةً يتجاهلها معظم الناس: DuskEVM ليس "طبقة توافق مع الإيثيريوم"، بل هو إعادة تنفيذ لمجموعة تعليمات EVM كاملة فوق آلة افتراضية تعمل بتقنية WASM. اختيار @Dusk لهذه الطريقة يعني أنها تتحمل كلفة الطرفين معًا.
ميزة التوافق مع EVM واضحة ومباشرة: يستطيع مطورو Solidity الترحيل بسلاسة، ويمكن لـ Metamask الاتصال مباشرة، ويمكن تعديل بروتوكولات DeFi القائمة عبر بضعة أسطر فقط لنشرها على #dusk . لكن EVM على WASM هو في جوهره "مترجم"؛ إذ يجب تفسير كل تعليمة (opcode) من تعليمات EVM من جديد داخل وقت تشغيل WASM ثم تنفيذها. هذه الكلفة الإضافية للترجمة تكون غير محسوسة في سيناريوهات انخفاض التزامن، لكنها تتضخم خلال ذروة التسويات الدفعية في NPEX لتتحول إلى علاوة خفية على الغاز.
والأكثر دقة هو تكلفة التفاعل بين نموذج الخصوصية في DuskEVM ونموذج Phoenix. EVM مبني على نموذج الحسابات، بينما Phoenix يعتمد نموذج UTXO الهجين. والجسر بينهما يتطلب تحويلات إضافية ضمن إثباتات ZK. عندما تتنقل بروتوكولات DeFi بشكل متكرر بين حالة EVM العامة وUTXO الخاصة، فإن كل عملية تبديل تصبح توليدًا للإثبات، وتتراكم التأخيرات خطوةً بعد خطوة. يحسب صانعو السوق في المراجحة أرباحهم على مستوى المللي ثانية؛ فإذا أضيفت طبقات تحويل أكثر، فقد تُستهلك الأرباح بسبب كلفة الاحتكاك.
أنا أؤيد استراتيجية DuskEVM: خفض عتبة دخول المطورين عبر التوافق مع EVM، مع الاحتفاظ بإمكانية التوسع المستقبلية عبر WASM. لكن قابلية هذه الطريق عمليًا لا تعتمد على عدد عقود Solidity التي يدعمها، بل على ما إذا كان تأخير إثباتات جسر EVM-Phoenix يمكن ضغطه إلى مستوى "غير محسوس" في سيناريوهات DeFi الحقيقية.
تحتاج حلقة RWA المغلقة لدى DUSK إلى DeFi كي تكون مزلّق السيولة، ويحتاج DeFi إلى توافق EVM لجذب المطورين. لكن هل سيجعل التراكم الثلاثي—ترجمة WASM، وتنفيذ EVM، وإثباتات Phoenix—هذه السلسلة في ظل الضغط العالي تتحول إلى حالة "يمكن فعلها لكن لا يمكن تنفيذها عمليًا"؟
#dusk @Dusk