نقاط تحقق الجداول المؤقتة المحفوظة من أجل استعادة النظام بعد الانهيار

يدعم عقد ADAMANT الآن نقاط تحقق دوّارة ومحفوظة للحالة المشتقة من نوع mem_*. بعد انقطاع قسري يؤدي إلى تناقض في صور الذاكرة، يمكن لعملية التشغيل استعادة آخر نقطة تحقق تم التحقق منها، وإعادة تشغيل الكتل فقط من ارتفاع نقطة التحقق فصاعدًا، بدلاً من إعادة بناء جميع الجداول من الارتفاع 1. تم تنفيذ هذا التصميم استنادًا إلى الملف #227، والذي تم دمجه عبر طلب السحب #261. تُعد نقاط التحقق مجرد ذاكرة مؤقتة محلية للتعافي؛ وتظل الكتل وإعادة التشغيل الحتمية هي المصدر الموثوق للحالة. إذا فشل التحقق أو إعادة التشغيل، يعود العقد إلى المسار المعهود لإعادة البناء الكامل.

يمكن أن تصبح الجداول المشتقة مثل mem_accounts وmem_round وجداول الربط الخاصة بالمفوضين (delegates) والتوقيعات المتعددة (multisig)، بالإضافة إلى صورها غير المؤكدة، غير متسقة إذا تم إنهاء العملية أثناء تنفيذ عمليات الكتابة. لا يزال الإغلاق المنظم عبر SIGTERM هو المسار التشغيلي المطلوب، لكن نقاط التحقق تقلل من وقت الاستعادة عند حدوث إنهاء قسري.

يُدخل التنفيذ جدول ميتا بيانات (mem_state_checkpoint_meta) ومجموعتين من ثلاث مجموعات دوّارة من الجداول (mem_ckpt_0..2_*) للحالة المؤكدة. لا يتم إنشاء نقاط تحقق للجداول الانتقالية غير المؤكدة؛ بل يتم إعادة بنائها من الحالة المؤكدة عند الاستعادة. يتم تقسيم المنطق الأساسي عبر عدة ملفات: logic/memCheckpoint.js للبصمة والتناوب بين الفتحات، وmodules/memCheckpoints.js كطبقة وحدة، وsql/memCheckpoints.js لأدوات SQL، مع تعديلات على modules/loader.js وmodules/blocks/chain.js لتفعيل الاستعادة وإنشاء نقاط التحقق.

تُنشأ نقاط التحقق فقط عند اكتمال حدود الدورة، بعد أن يكون خط أنابيب applyBlock قد أكمل حفظ الكتلة. عند رأس السلسلة (chain tip)، يحدث هذا في كل دورة مكتملة. أثناء المزامنة السريعة (catch-up sync)، يحدث كل 100 دورة لتجنب تقليل أداء المزامنة. يستخدم إنشاء نقطة التحقق معاملة REPEATABLE READ في PostgreSQL لتجميد لقطة MVCC. يتم تحرير القسم الحرج لمعالجة الكتل بمجرد حفظ صف الميتا بيانات، بينما تستمر عملية نسخ الجدول وحساب البصمة في الخلفية باستخدام اللقطة المجمدة. وهذا يمنع احتكار القسم الحرج طوال مدة عملية النسخ.

قبل قبول نقطة تحقق للاستعادة، يتم التحقق من عدة شروط ثابتة: يجب أن تكون الحالة مكتملة، ويجب أن تتطابق المخططات وnethash، ويجب أن تكون الكتلة المشار إليها موجودة، ويجب أن يتطابق بُصمة SHA-256. تحاول عملية الاستعادة جميع الفتحات المكتملة من الأحدث إلى الأقدم، لذا فإن تلف الفتحة الأحدث لا يستدعي إعادة بناء كاملة إذا كانت هناك فتحة أقدم صالحة. عند التشغيل، إذا كشف checkMemTables() عن تناقض، فإن memCheckpoints.tryRecover() يستعيد الفتحة، ويُعيد تهيئة الحالة غير المؤكدة، ويُهيئ الكتلة الأخيرة، ثم يعيد تشغيل الكتل من ارتفاع نقطة التحقق حتى الرأس. إذا فشل إعادة التشغيل، يتجاهل العقد حالة نقطة التحقق وينفذ إعادة بناء كاملة من الجينيسيس.

يتم تمكين هذه الميزة افتراضيًا في config.default.json:

"loading": {
  "memCheckpoints": {
    "enabled": true
  }
}

يجب على المشغلين ملاحظة أن هذه الميزة لا تُدخل أي تغييرات على البروتوكول؛ فنقاط التحقق لا تُستخدم أبدًا كمدخلات للتوافق، ولا يمكن للبيانات المحلية المُزيفة تجاوز التحقق من الكتل. بالنسبة إلى أحجام mem_* في الشبكة الرئيسية، تتطلب ثلاث فتحات حوالي 96–144 ميغابايت بالإضافة إلى الميتا بيانات، لذا يُوصى بترك هامش حوالي 1 جيجابايت. يجب على المشغلين ما زال تفضيل الإغلاق المنظم، لأن نقاط التحقق تقلل وقت الاستعادة لكنها لا تُعوّض إجراءات الإغلاق الصحيحة.