يَدُلّ الغسق عن توسيع طبقة متوافقة مع EVM
إلى جانب سلاسلها الأصلية، والمنطق المذكور هو
بسيط للغاية:
خفض عائق دخول المطورين، وترك أدوات Solidity القائمة
تعمل بدلًا من طلب أن يتعلّم كل منشئ مكدسًا جديدًا من الصفر.
ومن حيث الظاهر، هذه هي الخطوة البديهية — فمعرفة EVM هي
أكبر تجمع للمطورين في عالم التشفير،
ورفض مقابلتها ولو جزئيًا هو ما يجعل L1 الواعدة تبقى
متخصصة بشكل دائم.
ما أظل أتوقف عنده هو سؤال أضيق:
هل ترث طبقة متوافقة مع EVM ضمانات الخصوصية الفعلية لدى Dusk،
أم أنها ترث شفافية EVM الافتراضية وتجاور طبقة خصوصية Dusk
دون أن تلامسها؟
هذان ليسا الشيء نفسه، والفرق
يهم أكثر هنا مما قد يهم في معظم L1s
عند إضافة التوافق مع EVM، لأن الخصوصية والإفصاح الواعي بالامتثال
هما السبب الكامل لوجود Dusk.
إذا كان العقد الذي يُنشر على طبقة EVM يتصرف
مثل أي عقد EVM آخر — حالة عامة، و
calldata عام، ونموذج الشفافية القياسي — فحينها «يدعم Dusk EVM» و«يمتد نموذج خصوصية Dusk إلى EVM» ادعاءان مختلفان،
ووفقًا لذلك لا يميل التسويق إلا إلى جعلهما يُقالان معًا في آن واحد.
النسخة الصادقة من هذه المفاضلة هي أن توافق EVM
والحوسبة السرّية الأصلية متقابلان من الناحية البنيوية إلى حد ما.
لم يُبنَ نموذج تنفيذ EVM مع وضع الإفصاح الانتقائي في الاعتبار؛
بينما بُني العرض الأساسي لقيمة Dusk خصيصًا
حول ذلك.
إن كان جسر الاثنين جيدًا — السماح
بأدوات مألوفة مع الاستمرار في الحصول على معاملات سرّية
وعقود ذكية واعية بالامتثال — فهذه مشكلة تكامل شديدة الصعوبة فعلًا، وليست مجرد «خانة اختيار».
من الممكن أن يكون Dusk قد حلها بذكاء.
ومن الممكن أيضًا أن يعني «متوافق مع EVM» بهدوء:
«متوافق مع EVM بالنسبة للنصف الشفاف من السلسلة»،
بينما ما تزال العقود الفعلية التي تحافظ على الخصوصية تتطلب البنية الأصلية، XSC، ومن ثم منحنى تعلّم التوافق مع EVM الذي كان يُفترض أن يزيله.
@Dusk #dusk $DUSK
إلى جانب سلاسلها الأصلية، والمنطق المذكور هو
بسيط للغاية:
خفض عائق دخول المطورين، وترك أدوات Solidity القائمة
تعمل بدلًا من طلب أن يتعلّم كل منشئ مكدسًا جديدًا من الصفر.
ومن حيث الظاهر، هذه هي الخطوة البديهية — فمعرفة EVM هي
أكبر تجمع للمطورين في عالم التشفير،
ورفض مقابلتها ولو جزئيًا هو ما يجعل L1 الواعدة تبقى
متخصصة بشكل دائم.
ما أظل أتوقف عنده هو سؤال أضيق:
هل ترث طبقة متوافقة مع EVM ضمانات الخصوصية الفعلية لدى Dusk،
أم أنها ترث شفافية EVM الافتراضية وتجاور طبقة خصوصية Dusk
دون أن تلامسها؟
هذان ليسا الشيء نفسه، والفرق
يهم أكثر هنا مما قد يهم في معظم L1s
عند إضافة التوافق مع EVM، لأن الخصوصية والإفصاح الواعي بالامتثال
هما السبب الكامل لوجود Dusk.
إذا كان العقد الذي يُنشر على طبقة EVM يتصرف
مثل أي عقد EVM آخر — حالة عامة، و
calldata عام، ونموذج الشفافية القياسي — فحينها «يدعم Dusk EVM» و«يمتد نموذج خصوصية Dusk إلى EVM» ادعاءان مختلفان،
ووفقًا لذلك لا يميل التسويق إلا إلى جعلهما يُقالان معًا في آن واحد.
النسخة الصادقة من هذه المفاضلة هي أن توافق EVM
والحوسبة السرّية الأصلية متقابلان من الناحية البنيوية إلى حد ما.
لم يُبنَ نموذج تنفيذ EVM مع وضع الإفصاح الانتقائي في الاعتبار؛
بينما بُني العرض الأساسي لقيمة Dusk خصيصًا
حول ذلك.
إن كان جسر الاثنين جيدًا — السماح
بأدوات مألوفة مع الاستمرار في الحصول على معاملات سرّية
وعقود ذكية واعية بالامتثال — فهذه مشكلة تكامل شديدة الصعوبة فعلًا، وليست مجرد «خانة اختيار».
من الممكن أن يكون Dusk قد حلها بذكاء.
ومن الممكن أيضًا أن يعني «متوافق مع EVM» بهدوء:
«متوافق مع EVM بالنسبة للنصف الشفاف من السلسلة»،
بينما ما تزال العقود الفعلية التي تحافظ على الخصوصية تتطلب البنية الأصلية، XSC، ومن ثم منحنى تعلّم التوافق مع EVM الذي كان يُفترض أن يزيله.
@Dusk #dusk $DUSK