النتيجة الأكثر خطورة لا تكون بالضرورة أن تتعارك العقد فيما بينها، بل أن تستدعي كل العقد المجموعة نفسها من كود التحقق، ثم تتحقق جميعها بشكل متناسق من شيء خاطئ تمامًا.
لقد قارنتُ بين الورقة البيضاء التاريخية لـ @Dusk والوثائق الحالية. تشير المواد القديمة إلى أن بيئة التشغيل هذه للـ Rust/WASM تُسمى Piecrust، بينما تستخدم الوثائق الحالية DuskVM. تغيّر الاسم عبر الزمن، لكن التصميم الجوهري لم يتبدّل: يمكن للعقود أن تسند عمليات التحقق التشفيري مثل PLONK وGroth16 وBLS وغيرها إلى مدخلات عامة في طبقة المضيف، دون الحاجة لتنفيذ كل منها على حدة.
الفوائد واقعية جدًا. يكتب المطورون كودًا تشفيريًا أقل عرضة للخطأ، ولا يتعين على العقد تكرار العمليات الأساسية داخل حيز WASM، كما تصبح التطبيقات أخف، وتصبح قواعد التحقق أسهل في التوحيد.
لكن الكلفة تتجمع أيضًا. غالبًا ما تؤذي أخطاء العقد الذكية كاتبها أولًا؛ أما إذا أخطأ المُحقق المشترك في تحليل المدخلات أو اختيار الإصدار أو شروط الحدود، فقد تتأثر جميع العقود التي تعتمد عليه. وبما أن الشبكة كاملة تتوافق، فلن يكون بالإمكان سوى إثبات أن الجميع نفّذوا القاعدة نفسها.
خلال ترقية Aegis في مارس 2026، فعّلت Dusk سلوك PLONK V3 والإصدار الجديد من BLS، كما أن استعلامات BLS الخاصة بالمضيف التي يستخدمها العقد تتبدّل وفق ارتفاع الكتلة. تستدعي الكتل التاريخية المُحقق القديم، بينما تستخدم البيانات الجديدة النسخة الأحدث؛ وإذا تم اختيار الارتفاع خطأ، فقد يؤدي ذلك إلى استنتاجات مختلفة بشأن صلاحية المعاملة.
لذلك لن أكتفي بعدّ تقارير المراجعة، بل سأتابع كذلك إصدار المُحقق، وارتفاعات الترقية، وناقلات الاختبار (test vectors)، وتعطيل/عدم صلاحية الكاش، وتجارب التراجع (rollback). يتحمل $DUSK مسؤولية Gas وأمن الإجماع، لكن لا يزال هناك مدخلات عامة للتحقق تدعم تطبيقات مالية كذلك. السرعة تحدد مدى سرعة تشغيل النظام، والمُحقق يحدد إن كان سيُسرّع أيضًا تشغيل الأخطاء.
#dusk
لقد قارنتُ بين الورقة البيضاء التاريخية لـ @Dusk والوثائق الحالية. تشير المواد القديمة إلى أن بيئة التشغيل هذه للـ Rust/WASM تُسمى Piecrust، بينما تستخدم الوثائق الحالية DuskVM. تغيّر الاسم عبر الزمن، لكن التصميم الجوهري لم يتبدّل: يمكن للعقود أن تسند عمليات التحقق التشفيري مثل PLONK وGroth16 وBLS وغيرها إلى مدخلات عامة في طبقة المضيف، دون الحاجة لتنفيذ كل منها على حدة.
الفوائد واقعية جدًا. يكتب المطورون كودًا تشفيريًا أقل عرضة للخطأ، ولا يتعين على العقد تكرار العمليات الأساسية داخل حيز WASM، كما تصبح التطبيقات أخف، وتصبح قواعد التحقق أسهل في التوحيد.
لكن الكلفة تتجمع أيضًا. غالبًا ما تؤذي أخطاء العقد الذكية كاتبها أولًا؛ أما إذا أخطأ المُحقق المشترك في تحليل المدخلات أو اختيار الإصدار أو شروط الحدود، فقد تتأثر جميع العقود التي تعتمد عليه. وبما أن الشبكة كاملة تتوافق، فلن يكون بالإمكان سوى إثبات أن الجميع نفّذوا القاعدة نفسها.
خلال ترقية Aegis في مارس 2026، فعّلت Dusk سلوك PLONK V3 والإصدار الجديد من BLS، كما أن استعلامات BLS الخاصة بالمضيف التي يستخدمها العقد تتبدّل وفق ارتفاع الكتلة. تستدعي الكتل التاريخية المُحقق القديم، بينما تستخدم البيانات الجديدة النسخة الأحدث؛ وإذا تم اختيار الارتفاع خطأ، فقد يؤدي ذلك إلى استنتاجات مختلفة بشأن صلاحية المعاملة.
لذلك لن أكتفي بعدّ تقارير المراجعة، بل سأتابع كذلك إصدار المُحقق، وارتفاعات الترقية، وناقلات الاختبار (test vectors)، وتعطيل/عدم صلاحية الكاش، وتجارب التراجع (rollback). يتحمل $DUSK مسؤولية Gas وأمن الإجماع، لكن لا يزال هناك مدخلات عامة للتحقق تدعم تطبيقات مالية كذلك. السرعة تحدد مدى سرعة تشغيل النظام، والمُحقق يحدد إن كان سيُسرّع أيضًا تشغيل الأخطاء.
#dusk
