بعد أن أعدت النظر في Dusk، بدأتُ بدلًا من ذلك أركّز على سؤال نادرًا ما يُناقش: أين ينبغي أن تكون "سلطة التنفيذ" على السلسلة؟
مؤخرًا وأنا أبحث في @Dusk ، وجدتُ أنني أقلّ اهتمامًا بمتابعة ميزة منفردة، وأكثر اهتمامًا بكيفية توزيع سلسلة مالية عامة لقدرات التنفيذ.
Dusk لا تضع الآن كل شيء داخل بيئة تنفيذ واحدة. فـ DuskEVM تتولى Solidity وVyper وأدوات EVM المألوفة؛ أما DuskVM فتعمل مباشرة على Dusk L1، وموجّهة إلى عقود Rust/WASM، ويمكنها الوصول إلى الأصول على مستوى البروتوكول، ونموذج المعاملات الأصلي، والخصوصية، وقدرات ZK؛ بينما تتكفل DuskDS في الطبقة الأساسية بالإجماع والتسوية وتوافر البيانات. وتشرح الوثائق الرسمية هذا التقسيم بوضوح في الواقع.
أعتقد أن هناك فرقًا يسهل تجاهله هنا: توافقية EVM تحل سؤال "كيف نجعل المطورين يدخلون"، بينما بيئة التنفيذ الأصلية تحل سؤال "ما الأشياء التي يجب أن تبقى ملاصقةً لـ L1 لكي تُنجَز على نحو صحيح".
بالنسبة لتطبيقات DeFi العادية، تكفي أدوات EVM لتكون مريحة؛ لكن إذا كان التطبيق نفسه يتضمن معاملات خصوصية، أو أصولًا خاضعة للتنظيم، أو يحتاج إلى استدعاء قدرات Dusk الأصلية مباشرةً، فإن التعامل مع كل شيء وفق نموذج EVM التقليدي قد يقيّد تصميم البروتوكول بدلًا من أن يخدمه.
وهذا أيضًا أحد المنافذ التي أعود من خلالها لفهم Dusk من جديد. فالأمر ليس مجرد السعي إلى "دعم المزيد من التوافقية"، بل محاولة منح أنواع مختلفة من التطبيقات مواضع تنفيذ مختلفة، مع إعادة النتيجة النهائية إلى طبقة تسوية واحدة.
وعندما أنظر إلى $DUSK ، أجد أنه يؤدي أيضًا دور الغاز والـ staking في الوقت نفسه، وبالتالي فإن تنفيذ المعاملات وأمن الشبكة يشتركان في الأصل الاقتصادي نفسه.
وبالطبع، ما إذا كانت هذه البنية ستُظهر قيمتها فعلًا أم لا، فذلك يتوقف على ما إذا كان المطورون سيقبلون مغادرة مسار EVM الصرف من أجل القدرات الأصلية، وكذلك على أي نمط من أنماط التنفيذ ستختاره التطبيقات المالية الحقيقية في النهاية.
لذا، ما أريد مراقبته الآن ليس ما إذا كانت Dusk "تملك EVM" أم لا، بل ما إذا كانت تستطيع إثبات أمر واحد: في السيناريوهات المالية المعقدة، يمكن لبيئة التنفيذ نفسها أن تصبح جزءًا من تصميم البروتوكول. #dusk $DUSK @Dusk
مؤخرًا وأنا أبحث في @Dusk ، وجدتُ أنني أقلّ اهتمامًا بمتابعة ميزة منفردة، وأكثر اهتمامًا بكيفية توزيع سلسلة مالية عامة لقدرات التنفيذ.
Dusk لا تضع الآن كل شيء داخل بيئة تنفيذ واحدة. فـ DuskEVM تتولى Solidity وVyper وأدوات EVM المألوفة؛ أما DuskVM فتعمل مباشرة على Dusk L1، وموجّهة إلى عقود Rust/WASM، ويمكنها الوصول إلى الأصول على مستوى البروتوكول، ونموذج المعاملات الأصلي، والخصوصية، وقدرات ZK؛ بينما تتكفل DuskDS في الطبقة الأساسية بالإجماع والتسوية وتوافر البيانات. وتشرح الوثائق الرسمية هذا التقسيم بوضوح في الواقع.
أعتقد أن هناك فرقًا يسهل تجاهله هنا: توافقية EVM تحل سؤال "كيف نجعل المطورين يدخلون"، بينما بيئة التنفيذ الأصلية تحل سؤال "ما الأشياء التي يجب أن تبقى ملاصقةً لـ L1 لكي تُنجَز على نحو صحيح".
بالنسبة لتطبيقات DeFi العادية، تكفي أدوات EVM لتكون مريحة؛ لكن إذا كان التطبيق نفسه يتضمن معاملات خصوصية، أو أصولًا خاضعة للتنظيم، أو يحتاج إلى استدعاء قدرات Dusk الأصلية مباشرةً، فإن التعامل مع كل شيء وفق نموذج EVM التقليدي قد يقيّد تصميم البروتوكول بدلًا من أن يخدمه.
وهذا أيضًا أحد المنافذ التي أعود من خلالها لفهم Dusk من جديد. فالأمر ليس مجرد السعي إلى "دعم المزيد من التوافقية"، بل محاولة منح أنواع مختلفة من التطبيقات مواضع تنفيذ مختلفة، مع إعادة النتيجة النهائية إلى طبقة تسوية واحدة.
وعندما أنظر إلى $DUSK ، أجد أنه يؤدي أيضًا دور الغاز والـ staking في الوقت نفسه، وبالتالي فإن تنفيذ المعاملات وأمن الشبكة يشتركان في الأصل الاقتصادي نفسه.
وبالطبع، ما إذا كانت هذه البنية ستُظهر قيمتها فعلًا أم لا، فذلك يتوقف على ما إذا كان المطورون سيقبلون مغادرة مسار EVM الصرف من أجل القدرات الأصلية، وكذلك على أي نمط من أنماط التنفيذ ستختاره التطبيقات المالية الحقيقية في النهاية.
لذا، ما أريد مراقبته الآن ليس ما إذا كانت Dusk "تملك EVM" أم لا، بل ما إذا كانت تستطيع إثبات أمر واحد: في السيناريوهات المالية المعقدة، يمكن لبيئة التنفيذ نفسها أن تصبح جزءًا من تصميم البروتوكول. #dusk $DUSK @Dusk