فكرة سريعة:

ماذا يحدث عندما تحتاج إلى التحقيق في شيء وقع على السلسلة قبل ثلاث سنوات؟

هنا تصبح عقد الأرشيف أكثر إثارة للاهتمام مما يبدو عليه الأمر.

تميّز بنية Dusk بين عقد الأرشيف وبقية منظومة العقد؛ لأن البيانات التاريخية يجب أن تظل متاحة لأشياء مثل المستكشفين (explorers) والفهرسة (indexers) والخدمات الأخرى التي تحتاج إلى الحالة السابقة للسلسلة.

وهذا يهم بشكل خاص البنية التحتية المالية.

لا تحتاج الأسواق فقط إلى معرفة ما حدث قبل خمس ثوانٍ.

قد تحتاج إلى إعادة بناء معاملة أقدم.

قد يحتاج المدقق إلى أدلة تاريخية.

قد تحتاج تطبيقات إلى الحالة السابقة.

قد يحتاج المحقق إلى فهم كيفية انتقال أصل ما عبر النظام.

لذلك فإن «عدم القابلية للتغيير (immutability) في البلوكشين» و«إتاحة تاريخية مفيدة» هما في الواقع شيئان مختلفان.

يقول الأول إن التاريخ موجود.

والآخر يسأل:

هل يمكن لشخص ما استرجاعه وتفسيره بكفاءة لاحقًا؟

هنا تدخل البنية التحتية للأرشفة.

ويضيف Dusk تعقيدًا إضافيًا لأن جزءًا من نشاط معاملاته يتم الحفاظ عليه عبر تقنيات تحافظ على الخصوصية.

يمكن للسلسلة أن تحتفظ بالسجل التشفيري دون جعل كل تفاصيل المعاملة متاحة للعامة. وتُشير وثائق Dusk إلى أن تفاصيل معاملات Phoenix ليست مكشوفة للعامة بالطريقة نفسها التي تُعرض بها أنشطة Moonlight.

لذا فالأرشيف ليس مجرد جدول عمومي ضخم.

إنه سجل تاريخي بخصائص رؤية مختلفة.

وهذا نموذج أكثر إثارة للاهتمام لتاريخ البلوكشين من «كل شيء عام إلى الأبد».

@Dusk $DUSK #dusk