أولًا، التمييز بين بيانات التنفيذ وبيانات Blob

تستخدم بعض طبقات الشبكة من الطبقة الثانية وحدات Blob لنقل البيانات المنشورة على إيثيريوم. يهدف تصميم وحدات Blob إلى ضمان توافر البيانات، وليس إلى ضمان احتفاظ كل عقدة عادية بجميع المحتويات التاريخية بشكل دائم. لا يعني عرض سجل الالتزام في متصفح المعاملات أن العقدة الحالية لا تزال تحتفظ بالبيانات كاملةً. عند البحث في سلسلة كتل من الطبقة الثانية، من الضروري توضيح طريقة الإرسال، وعملية التحقق، والجهة المسؤولة عن أرشفة البيانات التاريخية.

التوافر قصير الأجل يختلف عن النسخ الاحتياطي الدائم.

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

لماذا يجب على المستخدمين العاديين الاهتمام بهذا الأمر؟

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

مثال على استعلام تاريخي

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

طرق تقييم موفري الأرشفة

مراجعة نطاق احتفاظ الموفر بالبيانات، وفحوصات سلامة البيانات، وتنسيق التنزيل، وحدود المعدل، وشروط الدفع، وسجل الانقطاعات. من الأفضل التحقق من العلاقة بين المحتوى الذي تم تنزيله والتزامات البروتوكول، وتجنب الاعتماد كليًا على واجهة برمجة تطبيقات تجارية واحدة. يجب أن يكون للتخزين الدائم جهة مسؤولة واضحة وآلية قابلة للتحقق؛ فالشعارات الترويجية لا تُعادل التزامات خدمة طويلة الأجل وقابلة للتنفيذ.

توفير مصدر للمقالات وأبحاث البيانات

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