افترضتُ أن معنى المعاملة ثابت بمجرد أن توجد بايتها: فكّها مرةً واحدة، وتحصل على الإجابة نفسها في كل مكان. وملف تغييرات Dusk الخاص بـ Rusk لترقية Boreas يتعامل مع ذلك بوصفه شيئًا يجب تصميمه/هندسـته، وليس أمرًا مسلمًا به.
أضاف Boreas فك ترميز للمعاملات يراعي الإصدارات مرتبطًا بسليفورك محدد، بالإضافة إلى اختيار صيغة يخضع للحُكْم بحسب السليفورك لإعادة تشغيل الكتل القديمة. أصبح لدى قاعدة الكود نوعان منفصلان صراحةً: CanonicalTransaction وLedgerTransaction، مما يفصل تمثيل المعاملة في الذاكرة عن الصيغة التي يتم فعليًا حفظها على السجل (ledger). وهناك حتى اختبار انحدار مخصص فقط للتأكد من فك ترميز المعاملات السابقة لعصر Aegis بشكل صحيح أثناء تسلسل/تسجـيل الكتل (block serialization).
ولا يصبح ذلك ضروريًا إلا عندما يتعين على فك ترميز المعاملات مراعاة عصور البروتوكول ومراحل المعالجة المختلفة: معاملة جديدة واردة عبر السلك من عميل، موجودة في الذاكرة ككائن معياري (canonical)، ثم يُعاد تشغيلها/تُعاد معالجتها من كتلة تسبق القواعد الحالية.
وهذا يعني أن ترقية البروتوكول ليست آمنة لمجرد أن المعاملات الجديدة تعمل وفق القواعد الجديدة. تكون آمنة فقط إذا لم تُخِل تلك القواعد الجديدة بشكل صامت بقدرة النظام على إعادة تشغيل حالة السجل القديمة (old ledger state) بشكل صحيح وفق القواعد التي أنتجتها. هذه هي فئة حالات فشل عدم تطابق الإصدارات التي صُمِّمت التوافقية مع الإعادة التاريخية (historical-replay compatibility) وفك التشفير المُقيَّد بالسليفورك (hardfork-gated decoding) لمنعها.
"المعاملة لا تكون موثوقة إلا إذا اتفقت كل مرحلة تمسّها على معناها."
ما كنتُ أتمنى رؤيته فعلًا: إعادة تشغيل كتلة حقيقية من ما قبل Aegis على عقدة حالية دون تغيير طريقة فك ترميز معاملاتـها التاريخية وفق القواعد المعمول بها، لا مجرد اختبار انحدار عابر بمعزلٍ عن السياق.
#dusk $DUSK @Dusk
أضاف Boreas فك ترميز للمعاملات يراعي الإصدارات مرتبطًا بسليفورك محدد، بالإضافة إلى اختيار صيغة يخضع للحُكْم بحسب السليفورك لإعادة تشغيل الكتل القديمة. أصبح لدى قاعدة الكود نوعان منفصلان صراحةً: CanonicalTransaction وLedgerTransaction، مما يفصل تمثيل المعاملة في الذاكرة عن الصيغة التي يتم فعليًا حفظها على السجل (ledger). وهناك حتى اختبار انحدار مخصص فقط للتأكد من فك ترميز المعاملات السابقة لعصر Aegis بشكل صحيح أثناء تسلسل/تسجـيل الكتل (block serialization).
ولا يصبح ذلك ضروريًا إلا عندما يتعين على فك ترميز المعاملات مراعاة عصور البروتوكول ومراحل المعالجة المختلفة: معاملة جديدة واردة عبر السلك من عميل، موجودة في الذاكرة ككائن معياري (canonical)، ثم يُعاد تشغيلها/تُعاد معالجتها من كتلة تسبق القواعد الحالية.
وهذا يعني أن ترقية البروتوكول ليست آمنة لمجرد أن المعاملات الجديدة تعمل وفق القواعد الجديدة. تكون آمنة فقط إذا لم تُخِل تلك القواعد الجديدة بشكل صامت بقدرة النظام على إعادة تشغيل حالة السجل القديمة (old ledger state) بشكل صحيح وفق القواعد التي أنتجتها. هذه هي فئة حالات فشل عدم تطابق الإصدارات التي صُمِّمت التوافقية مع الإعادة التاريخية (historical-replay compatibility) وفك التشفير المُقيَّد بالسليفورك (hardfork-gated decoding) لمنعها.
"المعاملة لا تكون موثوقة إلا إذا اتفقت كل مرحلة تمسّها على معناها."
ما كنتُ أتمنى رؤيته فعلًا: إعادة تشغيل كتلة حقيقية من ما قبل Aegis على عقدة حالية دون تغيير طريقة فك ترميز معاملاتـها التاريخية وفق القواعد المعمول بها، لا مجرد اختبار انحدار عابر بمعزلٍ عن السياق.
#dusk $DUSK @Dusk
