#dusk $DUSK @Dusk ذهبت اليوم للبحث عن سبب إزعاج الشفق لتشغيل بيئتين تنفيذ منفصلتين بدلًا من اختيار واحدة فقط، وللصراحة؟ 😂 اتضح أن الإجابة ليست مجرد استعراض تقني، بل إنها مفاضلة حقيقية.
لذا، duskvm هي بيئة wasm مبنية حول wasmtime، وتعمل مباشرة على طبقة dusk l1 نفسها، ولا تحتاج إلى قفزة تسوية بالطريقة التي يتطلبها duskevm عبر duskds، والذي كتبـتُ عنه منذ فترة. وهي مخصصة لعقود rust التي تريد تكاملًا أضيق مع نماذج المعاملات الخاصة بـ dusk، والأصول على مستوى البروتوكول، وإمكانيات الخصوصية أو zk على وجه الخصوص. أما duskevm، من جهته، موجود أساسًا لـ solidity وأدوات evm القياسية مثل foundry وhardhat والمحافظ الموجودة—بشكل عام، كامل منظومة الإيثيريوم التي يعرفها الناس بالفعل. والكتابة الخاصة بـ dusk تُظهر أرقامًا حقيقية توضح لماذا هذا الانقسام مهم: يبدو أن تكامل مخصص مهيّأ مع l1 قد يستغرق من ستة إلى اثني عشر شهرًا ويكلف نحو خمسين مرة أكثر من نشر evm المكافئ، كما يشيرون إلى أن التبادلات نفسها تقضي أشهرًا في التكيّف مع تكامل dusk الأصلي مقارنةً بأسابيع لتكاملات evm.
ما أعود للتفكير فيه منذ قراءتي لهذه الأرقام هو ما إذا كانت فجوة التكلفة هذه تدفع تقريبًا الجميع—بالأمر الواقع—نحو duskevm افتراضيًا، حتى المشاريع التي تستفيد تقنيًا أكثر من تكامل الخصوصية الأصلي الأضيق في duskvm. إذا كان مسار أقل مقاومة هو أرخص وأسرع إلى هذا الحد، فهل الخيار الأصعب لكنه مُصمم لغرض محدد ينتهي به الأمر إلى أن يُستخدم أقل بغض النظر عن مدى مناسبته؟ لم أر شيئًا يتناول هذا التوتر مباشرة.
ومع ذلك، فإن منح المطورين مسارين حقيقيين بدلًا من فرض نموذج تنازلات واحد على الجميع هو رد مشروع على احتياجات مختلفة فعليًا، وليس مجرد تعقيد إضافي من أجل التعقيد.
بصراحة لا أعرف إن كانت فجوة التكلفة هذه تدفع معظم المشاريع الجادة نحو duskevm، أم أن duskvm يحتفظ بمكانته لحالات الاستخدام التي تحتاجه فعلًا؟
🤔
#dusk @Dusk $DUSK
لذا، duskvm هي بيئة wasm مبنية حول wasmtime، وتعمل مباشرة على طبقة dusk l1 نفسها، ولا تحتاج إلى قفزة تسوية بالطريقة التي يتطلبها duskevm عبر duskds، والذي كتبـتُ عنه منذ فترة. وهي مخصصة لعقود rust التي تريد تكاملًا أضيق مع نماذج المعاملات الخاصة بـ dusk، والأصول على مستوى البروتوكول، وإمكانيات الخصوصية أو zk على وجه الخصوص. أما duskevm، من جهته، موجود أساسًا لـ solidity وأدوات evm القياسية مثل foundry وhardhat والمحافظ الموجودة—بشكل عام، كامل منظومة الإيثيريوم التي يعرفها الناس بالفعل. والكتابة الخاصة بـ dusk تُظهر أرقامًا حقيقية توضح لماذا هذا الانقسام مهم: يبدو أن تكامل مخصص مهيّأ مع l1 قد يستغرق من ستة إلى اثني عشر شهرًا ويكلف نحو خمسين مرة أكثر من نشر evm المكافئ، كما يشيرون إلى أن التبادلات نفسها تقضي أشهرًا في التكيّف مع تكامل dusk الأصلي مقارنةً بأسابيع لتكاملات evm.
ما أعود للتفكير فيه منذ قراءتي لهذه الأرقام هو ما إذا كانت فجوة التكلفة هذه تدفع تقريبًا الجميع—بالأمر الواقع—نحو duskevm افتراضيًا، حتى المشاريع التي تستفيد تقنيًا أكثر من تكامل الخصوصية الأصلي الأضيق في duskvm. إذا كان مسار أقل مقاومة هو أرخص وأسرع إلى هذا الحد، فهل الخيار الأصعب لكنه مُصمم لغرض محدد ينتهي به الأمر إلى أن يُستخدم أقل بغض النظر عن مدى مناسبته؟ لم أر شيئًا يتناول هذا التوتر مباشرة.
ومع ذلك، فإن منح المطورين مسارين حقيقيين بدلًا من فرض نموذج تنازلات واحد على الجميع هو رد مشروع على احتياجات مختلفة فعليًا، وليس مجرد تعقيد إضافي من أجل التعقيد.
بصراحة لا أعرف إن كانت فجوة التكلفة هذه تدفع معظم المشاريع الجادة نحو duskevm، أم أن duskvm يحتفظ بمكانته لحالات الاستخدام التي تحتاجه فعلًا؟
🤔
#dusk @Dusk $DUSK