تم تفعيل PLONK V3 على الشبكة الرئيسية (mainnet) في الكتلة رقم 3,590,904، لكن الكتل الأقدم ما زالت تعتمد على قواعد PLONK V1 أو V2 التي كانت سارية عندما تم إنتاجها.
في البداية، قد يبدو الأمر كترقية بسيطة للمتحقق. لكن قاعدة جديدة للنشاط الحالي لا تصبح تلقائيًا قاعدةً لتاريخ Dusk بالكامل.
إن تفعيل PLONK V3 يخبرني بقواعد الإثبات التي يستخدمها Dusk بدءًا من حدّ الانقسام (fork) هذا. لكنه لا يخبرني بأن الكتل الأقدم تتم إعادة تقييمها وفقًا للمتحقق الأحدث.
ما لا أعرفه بعد هو مدى موثوقية شبكة Dusk في الحفاظ على فصل عصور التحقق تلك أثناء قيام العقد بالمزامنة وإعادة تشغيل التاريخ (replay) والتحقق من نشاطٍ جديد تحت مجموعات قواعد مختلفة.
هذا يهم أكثر مع قيام Dusk ببناء البنية التحتية لسير عمل الإصدار الأصلي (native issuance)، حيث يمكن أن يعتمد جزء أكبر من دورة حياة أداة أمنية خاضعة للتنظيم على قيام دفتر الأستاذ (ledger) بالحفاظ على سجلٍّ تاريخيٍّ متسق عبر ترقيات البروتوكول.
تمنح Rusk آليةً مفيدة لمراقبة ذلك. فهي تختار المتحقق المناسب بناءً على ارتفاع الكتلة (block height)، بحيث يتم التحقق من الكتل التاريخية وفق قواعدها الأصلية بينما يستخدم النشاط الأحدث PLONK V3.
يثبت نجاح التفعيل أن Dusk يمكنها تقديم متحقق جديد. ويعدّ الاتساق في إعادة التشغيل عبر V1 وV2 وV3 دليلًا أقوى لأن العقد يجب أن تتفق ليس فقط على القواعد الحالية، بل أيضًا على تحديد القواعد نفسها التي تنطبق على كل جزء سابق من السلسلة.
هذا يغيّر الطريقة التي سأحكم بها على ترقيات التشفير في Dusk.
السؤال هو ما إذا كان بإمكان Dusk مواصلة التطور في مكدسها التشفيري مع الحفاظ تمامًا على القواعد التي جعلت كل كتلة سابقة صالحة.
أنا أراقب إعادة تشغيل التاريخ (historical replay)، ومزامنة العقد عبر حدود المتحقق (verifier boundaries)، وما إذا كانت مكوّنات Dusk تواصل اختيار مجموعة القواعد نفسها عند نفس ارتفاع الكتلة.
#dusk $DUSK @Dusk
في البداية، قد يبدو الأمر كترقية بسيطة للمتحقق. لكن قاعدة جديدة للنشاط الحالي لا تصبح تلقائيًا قاعدةً لتاريخ Dusk بالكامل.
إن تفعيل PLONK V3 يخبرني بقواعد الإثبات التي يستخدمها Dusk بدءًا من حدّ الانقسام (fork) هذا. لكنه لا يخبرني بأن الكتل الأقدم تتم إعادة تقييمها وفقًا للمتحقق الأحدث.
ما لا أعرفه بعد هو مدى موثوقية شبكة Dusk في الحفاظ على فصل عصور التحقق تلك أثناء قيام العقد بالمزامنة وإعادة تشغيل التاريخ (replay) والتحقق من نشاطٍ جديد تحت مجموعات قواعد مختلفة.
هذا يهم أكثر مع قيام Dusk ببناء البنية التحتية لسير عمل الإصدار الأصلي (native issuance)، حيث يمكن أن يعتمد جزء أكبر من دورة حياة أداة أمنية خاضعة للتنظيم على قيام دفتر الأستاذ (ledger) بالحفاظ على سجلٍّ تاريخيٍّ متسق عبر ترقيات البروتوكول.
تمنح Rusk آليةً مفيدة لمراقبة ذلك. فهي تختار المتحقق المناسب بناءً على ارتفاع الكتلة (block height)، بحيث يتم التحقق من الكتل التاريخية وفق قواعدها الأصلية بينما يستخدم النشاط الأحدث PLONK V3.
يثبت نجاح التفعيل أن Dusk يمكنها تقديم متحقق جديد. ويعدّ الاتساق في إعادة التشغيل عبر V1 وV2 وV3 دليلًا أقوى لأن العقد يجب أن تتفق ليس فقط على القواعد الحالية، بل أيضًا على تحديد القواعد نفسها التي تنطبق على كل جزء سابق من السلسلة.
هذا يغيّر الطريقة التي سأحكم بها على ترقيات التشفير في Dusk.
السؤال هو ما إذا كان بإمكان Dusk مواصلة التطور في مكدسها التشفيري مع الحفاظ تمامًا على القواعد التي جعلت كل كتلة سابقة صالحة.
أنا أراقب إعادة تشغيل التاريخ (historical replay)، ومزامنة العقد عبر حدود المتحقق (verifier boundaries)، وما إذا كانت مكوّنات Dusk تواصل اختيار مجموعة القواعد نفسها عند نفس ارتفاع الكتلة.
#dusk $DUSK @Dusk
