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