كنت أفكر مؤخرًا في سؤال: لماذا تركز أغلب السلاسل العامة على قابلية التوافق، بينما لا يتحدث الكثيرون عن "ما إذا كانت الأصول المختلفة تحتاج إلى منطق تنفيذ مختلف"؟
عندما نظرت إلى البنية التقنية لـ Dusk، وجدت أنها لم تسلك مسار "آلة افتراضية واحدة لتناسب الجميع". يوفر DuskEVM لمطوري Solidity بيئة مألوفة، بينما يتيح DuskVM لعقود Rust أن تعمل مباشرة على L1، ويقوم Transfer Contract بتوزيع معاملات مختلفة حسب الحمولة (payload) إلى مسارات التحقق المناسبة—وهذا التصميم ليس للمباهاة، بل للاستجابة لواقع: عندما يتم ترميز أصول معقدة مثل الأسهم الخاصة (private equity) والسندات الإذنية للشركات (corporate bonds)، فإن قواعد تنفيذها تختلف تمامًا عن الرموز العادية.
المشكلة في الأصول التقليدية ليست في الإصدار، بل في الاستخدام. هل يمكن لحصة في صندوق استثماري خاص أن تُستخدم كضمان؟ وإذا كان الأمر ممكنًا، فإلى من يمكن تحويل الضمان عند التصفية؟ كيف يتم التحقق من هوية المستثمرين المؤهلين؟ إذا بقيت هذه القواعد محصورة في بروتوكولات خارج السلسلة أو قيود الواجهة الأمامية، فستُلتفَّ عليها؛ أما إذا تم تضمينها (hard-coded) داخل العقد، فسيكون ذلك على حساب المرونة.
نهج Dusk هو نقل منطق التحقق إلى بيئة التنفيذ مقدمًا. يقوم Phoenix بالتعامل مع المعاملات التي تتطلب إخفاء المبالغ، بينما يتولى Moonlight التعامل مع السيناريوهات التي يجب أن تكون علنية وشفافة، وكلاهما يشتركان في طبقة تسوية واحدة. وهذا يعني أن سمات الأصول لا تعتمد على التزام المُصدِر، بل تُفرض عبر البنية التحتية.
لكن هذا التقسيم الطبقي يفرض أيضًا تكلفة معرفية. يجب على المطورين فهم متى يستخدمون أي آلة افتراضية، وعلى المستخدمين أن يتأكدوا من أن معاملتهم تسلك أي مسار. إذا كان معظم الناس يستخدمون طبقة توافق EVM لفترة طويلة فقط، فإن القدرات الأصيلة في DuskVM وPhoenix ستظل مزايا نظرية.
لذلك اهتمامي ليس بعدد أنواع الأصول التي يدعمها Dusk، بل بما إذا كانت هذه الأصول ستستخدم فعلاً القدرات المميزة التي صُممت من أجلها. قيمة البنية التقنية—في النهاية—لا يمكن التحقق منها إلا عبر سيناريوهات الاستخدام الفعلية.
#dusk @Dusk $DUSK
عندما نظرت إلى البنية التقنية لـ Dusk، وجدت أنها لم تسلك مسار "آلة افتراضية واحدة لتناسب الجميع". يوفر DuskEVM لمطوري Solidity بيئة مألوفة، بينما يتيح DuskVM لعقود Rust أن تعمل مباشرة على L1، ويقوم Transfer Contract بتوزيع معاملات مختلفة حسب الحمولة (payload) إلى مسارات التحقق المناسبة—وهذا التصميم ليس للمباهاة، بل للاستجابة لواقع: عندما يتم ترميز أصول معقدة مثل الأسهم الخاصة (private equity) والسندات الإذنية للشركات (corporate bonds)، فإن قواعد تنفيذها تختلف تمامًا عن الرموز العادية.
المشكلة في الأصول التقليدية ليست في الإصدار، بل في الاستخدام. هل يمكن لحصة في صندوق استثماري خاص أن تُستخدم كضمان؟ وإذا كان الأمر ممكنًا، فإلى من يمكن تحويل الضمان عند التصفية؟ كيف يتم التحقق من هوية المستثمرين المؤهلين؟ إذا بقيت هذه القواعد محصورة في بروتوكولات خارج السلسلة أو قيود الواجهة الأمامية، فستُلتفَّ عليها؛ أما إذا تم تضمينها (hard-coded) داخل العقد، فسيكون ذلك على حساب المرونة.
نهج Dusk هو نقل منطق التحقق إلى بيئة التنفيذ مقدمًا. يقوم Phoenix بالتعامل مع المعاملات التي تتطلب إخفاء المبالغ، بينما يتولى Moonlight التعامل مع السيناريوهات التي يجب أن تكون علنية وشفافة، وكلاهما يشتركان في طبقة تسوية واحدة. وهذا يعني أن سمات الأصول لا تعتمد على التزام المُصدِر، بل تُفرض عبر البنية التحتية.
لكن هذا التقسيم الطبقي يفرض أيضًا تكلفة معرفية. يجب على المطورين فهم متى يستخدمون أي آلة افتراضية، وعلى المستخدمين أن يتأكدوا من أن معاملتهم تسلك أي مسار. إذا كان معظم الناس يستخدمون طبقة توافق EVM لفترة طويلة فقط، فإن القدرات الأصيلة في DuskVM وPhoenix ستظل مزايا نظرية.
لذلك اهتمامي ليس بعدد أنواع الأصول التي يدعمها Dusk، بل بما إذا كانت هذه الأصول ستستخدم فعلاً القدرات المميزة التي صُممت من أجلها. قيمة البنية التقنية—في النهاية—لا يمكن التحقق منها إلا عبر سيناريوهات الاستخدام الفعلية.
#dusk @Dusk $DUSK