كنت أظن سابقًا أن ما يُسمّى في البلوك تشين بـ“عدم قابلية التلاعب” يكفي فيه بقاء الكتل القديمة وأن قيمة الـHash لم تتغير. لكن خلال قراءتي مؤخرًا لوثيقة ترقية Boreas بعدد @Dusk ، اكتشفت أن هذا الفهم ناقص بقدر النصف: ثبات البيانات لا يعني أن عقد الشبكة في الإصدارات الجديدة بعد سنوات سيُفسّرها وفق القواعد نفسها التي كانت تُستخدم يومها. فبالنسبة للحوّالات العادية يشبه ذلك تفاصيل هندسية، لكن في نطاق التدقيق المالي يصبح الأمر شيئًا آخر.
لنفترض أن سند دين أُنجزت له عملية تحويل على السلسلة في عام 2026. وعند إجراء التدقيق في عام 2031 تكون الشبكة قد شهدت عدة ترقيات؛ إذ تغيّر شكل المعاملة وقواعد الـGas وسلوك الآلة الافتراضية (الـVM). ما يحتاج التدقيق فعليًا إلى تأكيده ليس فقط أن تلك المعاملة موجودة، بل أنَّه عند إعادة المزامنة والتنفيذ اليوم للتاريخ، هل يمكن إعادة إنتاج حالة دفتر الأستاذ نفسها التي كانت آنذاك. الأمر يشبه التحقّق من إقرار الضرائب لعام 2026: لا يمكنك إعادة حسابه وفق قواعد عام 2031 ثم القول لك “لم تتغير البيانات”.
في 10 يونيو من هذا العام، دخلت Boreas إلى شبكة Dusk الرئيسية مع Rusk 1.7.0. وقد فصلت خصيصًا بين تنسيق ما يرسله العميل، وبين ما يسمى بالمعاملة canonical داخل العقد، وبين التنسيق النهائي عند الكتابة في ledger، مع الاحتفاظ بموحّدات فك ترميز التاريخ السابقة لـpre-Aegis وpre-Boreas. والسبب الرسمي المقدم كان هندسيًا جدًا: لا ينبغي أن يؤدي كلٌّ من mempool وعمليات إنتاج الكتل والتحقق بالاتفاق وإعادة تشغيل التاريخ (historical replay) لنفس مجموعة بيانات المعاملات إلى تفسيرات مختلفة.
هنا أدركت أن دفتر الحسابات المالي لا يخشى بالضرورة أن يفشل البرنامج مباشرةً، بل أن تعمل عدة أنظمة بصورة طبيعية ومع ذلك تُنتج إجابات مختلفة كلٌّ على حدة. حتى إن Boreas تُميّز تنفيذ الـVM وقواعد الـGas حسب إصدار hard fork، فهذا في جوهره الشيء ذاته: لا يجوز الرجوع لإعادة حساب معاملات “أمس” باستخدام قواعد “اليوم”.
لكنّي لن أصنّف Dusk تلقائيًا ضمن البنية التحتية المالية الناضجة لمجرد أن هذه التصاميم تم تشغيلها. فوجود اعتبار historical replay في البروتوكول شيء، بينما أن تتمكن بعد خمس سنوات ومن خلال عدة انقسامات/تفريعات (forks) من إعادة احتساب الدفاتر القديمة بشكل مستقر أيضًا شيء آخر. إن اختبارات إعادة التشغيل الخاصة بالتوافق، والمزامنة طويلة الأمد عبر archive/indexer، وتناسق العقد عبر الإصدارات المختلفة، إضافة إلى إمكانية إعادة إنتاج التدقيق بعد دخول أصول مالية عالية القيمة فعلًا—هذه هي البيانات التي يجب النظر إليها لاحقًا.
لذلك، كلما رأيت لاحقًا ترقية الشبكة الكامنة وراء $DUSK ، سأركّز بدلًا من ذلك على هذا النوع من المؤشرات المملة قليلًا: بعد إجراء الترقيات عشر مرات، هل يمكن إعادة تشغيل السجل القديم وإعادة بثّه بدقة تامة دون اختلاف في كل معاملة. بالنسبة للبنية التحتية المالية: لا يكفي أن يكون الحساب صحيحًا اليوم؛ بل يجب أن يكون بعد خمس سنوات أيضًا—عند إعادة الحساب مرة أخرى—نفس الإجابة التي حصلنا عليها في البداية.
#dusk $DUSK @Dusk
لنفترض أن سند دين أُنجزت له عملية تحويل على السلسلة في عام 2026. وعند إجراء التدقيق في عام 2031 تكون الشبكة قد شهدت عدة ترقيات؛ إذ تغيّر شكل المعاملة وقواعد الـGas وسلوك الآلة الافتراضية (الـVM). ما يحتاج التدقيق فعليًا إلى تأكيده ليس فقط أن تلك المعاملة موجودة، بل أنَّه عند إعادة المزامنة والتنفيذ اليوم للتاريخ، هل يمكن إعادة إنتاج حالة دفتر الأستاذ نفسها التي كانت آنذاك. الأمر يشبه التحقّق من إقرار الضرائب لعام 2026: لا يمكنك إعادة حسابه وفق قواعد عام 2031 ثم القول لك “لم تتغير البيانات”.
في 10 يونيو من هذا العام، دخلت Boreas إلى شبكة Dusk الرئيسية مع Rusk 1.7.0. وقد فصلت خصيصًا بين تنسيق ما يرسله العميل، وبين ما يسمى بالمعاملة canonical داخل العقد، وبين التنسيق النهائي عند الكتابة في ledger، مع الاحتفاظ بموحّدات فك ترميز التاريخ السابقة لـpre-Aegis وpre-Boreas. والسبب الرسمي المقدم كان هندسيًا جدًا: لا ينبغي أن يؤدي كلٌّ من mempool وعمليات إنتاج الكتل والتحقق بالاتفاق وإعادة تشغيل التاريخ (historical replay) لنفس مجموعة بيانات المعاملات إلى تفسيرات مختلفة.
هنا أدركت أن دفتر الحسابات المالي لا يخشى بالضرورة أن يفشل البرنامج مباشرةً، بل أن تعمل عدة أنظمة بصورة طبيعية ومع ذلك تُنتج إجابات مختلفة كلٌّ على حدة. حتى إن Boreas تُميّز تنفيذ الـVM وقواعد الـGas حسب إصدار hard fork، فهذا في جوهره الشيء ذاته: لا يجوز الرجوع لإعادة حساب معاملات “أمس” باستخدام قواعد “اليوم”.
لكنّي لن أصنّف Dusk تلقائيًا ضمن البنية التحتية المالية الناضجة لمجرد أن هذه التصاميم تم تشغيلها. فوجود اعتبار historical replay في البروتوكول شيء، بينما أن تتمكن بعد خمس سنوات ومن خلال عدة انقسامات/تفريعات (forks) من إعادة احتساب الدفاتر القديمة بشكل مستقر أيضًا شيء آخر. إن اختبارات إعادة التشغيل الخاصة بالتوافق، والمزامنة طويلة الأمد عبر archive/indexer، وتناسق العقد عبر الإصدارات المختلفة، إضافة إلى إمكانية إعادة إنتاج التدقيق بعد دخول أصول مالية عالية القيمة فعلًا—هذه هي البيانات التي يجب النظر إليها لاحقًا.
لذلك، كلما رأيت لاحقًا ترقية الشبكة الكامنة وراء $DUSK ، سأركّز بدلًا من ذلك على هذا النوع من المؤشرات المملة قليلًا: بعد إجراء الترقيات عشر مرات، هل يمكن إعادة تشغيل السجل القديم وإعادة بثّه بدقة تامة دون اختلاف في كل معاملة. بالنسبة للبنية التحتية المالية: لا يكفي أن يكون الحساب صحيحًا اليوم؛ بل يجب أن يكون بعد خمس سنوات أيضًا—عند إعادة الحساب مرة أخرى—نفس الإجابة التي حصلنا عليها في البداية.
#dusk $DUSK @Dusk
