#dusk $DUSK @Dusk أنا كنت أظنّ أن Data Driver، طالما أنها تحمل توقيع صاحب العقد، فالأمان يكفي. بعد أن قرأت كود Dusk، لم يبقَ من الاطمئنان إلا النصف: التوقيع يثبت من قام برفع الملف، لكنه لا يثبت أنه يتوافق مع أي نسخة من العقد.
في Dusk، تعد Data Driver ملف WASM مستقلًا. يعتمد عليه المحفظة والبورصات والروبوتات لقراءة بايتات الآلة التي يخرجها العقد على شكل مبالغ وصلاحيات وأحداث، وكذلك لتشفير عمليات المستخدم إلى بيانات يمكن للعقد تنفيذها. عند الرفع، يمنح صاحب العقد توقيع تجزئة (هاش) ملف الـDriver، ثم يقوم العقد/العقدة بتخزينه لاحقًا وفقًا لمعرّف العقد (contract ID).
اكتشفت أن المشكلة الأساسية تقع في العميل. تقوم W3sper حاليًا أيضًا بتسجيل الـDriver وتخزينه مؤقتًا وفقًا لمعـرّف العقد نفسه. وتشير Issues في المستودع الرسمي إلى أن هنا ما يزال ينقص الربط القوي بين الـDriver وإصدار العقد أو هاشه.
يؤدي ذلك إلى نوع من عدم التطابق الشائع في Dusk: طرف قديم يستمر في استخدام الـDriver القديم المخزَّن مؤقتًا، بينما طرف جديد يقوم بتنزيل الـDriver الجديد. قد تأتي كلتا النسختين من مسارات سليمة، ولا تظهر أي أخطاء على الجانبين، لكن على نفس الارتفاع (height) قد تُقرأ المبالغ والأحداث وحتى معاملات الصفقة بمعانٍ مختلفة.
أسوأ ما أخافه في التداول هو حدوث هذا النوع من الأعطال. فشل الصفقة سيطلق تنبيهًا؛ أما قراءة البيانات بشكل خاطئ بصمت—فقد يؤدي ذلك إلى أن تحسب المحفظة رصيدها والروبوت مراكزه وسجلات منصة البيانات كلٌ على حدة، حتى لا تتكشف المشكلة إلا عندما لا تتطابق الأموال.
في المراحل القادمة سأضيف مؤشرات لتقييم $DUSK . عدد العقود يمكن أن يتضخم بسهولة، لذا يصبح اتساق تجزئات الـDriver (Driver hash) أكثر قيمة. من المهم أن يكون من الممكن التحقق من أي نسخة من الـDriver استخدمتها المحافظ الرئيسية والبورصات والفهارس، ومن أي ارتفاع أصبحت فعّالة، ومتى انتهت صلاحية النسخة القديمة.
يقسم Dusk بين "تنفيذ العقد" و"تفسير العقد" إلى طبقتين، ما وفر مرونة، لكنه أضاف أيضًا طبقة مسؤولية خاصة إضافية: يجب أن يثبت الملف الأصلي أيضًا أنه لم يَفُت عليه الزمن. عندها فقط يمكن للناس أن يتداولوا براحة أكبر.
$BTC
في Dusk، تعد Data Driver ملف WASM مستقلًا. يعتمد عليه المحفظة والبورصات والروبوتات لقراءة بايتات الآلة التي يخرجها العقد على شكل مبالغ وصلاحيات وأحداث، وكذلك لتشفير عمليات المستخدم إلى بيانات يمكن للعقد تنفيذها. عند الرفع، يمنح صاحب العقد توقيع تجزئة (هاش) ملف الـDriver، ثم يقوم العقد/العقدة بتخزينه لاحقًا وفقًا لمعرّف العقد (contract ID).
اكتشفت أن المشكلة الأساسية تقع في العميل. تقوم W3sper حاليًا أيضًا بتسجيل الـDriver وتخزينه مؤقتًا وفقًا لمعـرّف العقد نفسه. وتشير Issues في المستودع الرسمي إلى أن هنا ما يزال ينقص الربط القوي بين الـDriver وإصدار العقد أو هاشه.
يؤدي ذلك إلى نوع من عدم التطابق الشائع في Dusk: طرف قديم يستمر في استخدام الـDriver القديم المخزَّن مؤقتًا، بينما طرف جديد يقوم بتنزيل الـDriver الجديد. قد تأتي كلتا النسختين من مسارات سليمة، ولا تظهر أي أخطاء على الجانبين، لكن على نفس الارتفاع (height) قد تُقرأ المبالغ والأحداث وحتى معاملات الصفقة بمعانٍ مختلفة.
أسوأ ما أخافه في التداول هو حدوث هذا النوع من الأعطال. فشل الصفقة سيطلق تنبيهًا؛ أما قراءة البيانات بشكل خاطئ بصمت—فقد يؤدي ذلك إلى أن تحسب المحفظة رصيدها والروبوت مراكزه وسجلات منصة البيانات كلٌ على حدة، حتى لا تتكشف المشكلة إلا عندما لا تتطابق الأموال.
في المراحل القادمة سأضيف مؤشرات لتقييم $DUSK . عدد العقود يمكن أن يتضخم بسهولة، لذا يصبح اتساق تجزئات الـDriver (Driver hash) أكثر قيمة. من المهم أن يكون من الممكن التحقق من أي نسخة من الـDriver استخدمتها المحافظ الرئيسية والبورصات والفهارس، ومن أي ارتفاع أصبحت فعّالة، ومتى انتهت صلاحية النسخة القديمة.
يقسم Dusk بين "تنفيذ العقد" و"تفسير العقد" إلى طبقتين، ما وفر مرونة، لكنه أضاف أيضًا طبقة مسؤولية خاصة إضافية: يجب أن يثبت الملف الأصلي أيضًا أنه لم يَفُت عليه الزمن. عندها فقط يمكن للناس أن يتداولوا براحة أكبر.
$BTC