دليل حول شجرة التأكيد “Assertion Tree”

تعريف شجرة التأكيد “Assertion Tree”
“Assertion Tree” في سياق البلوكتشين تشير إلى بنىة بيانات تستعمل لتأكيد صحة ونزاهة المعاملات أو البيانات المخزنة في البلوكتشين. استخدام الأشجار التأكيدية (Assertion Trees) أو ما يعرف أيضًا بأشجار الميركل (Merkle Trees) هو أحد المفاهيم الأساسية التي تعزز من كفاءة وأمان البلوكشين.

النقاط الرئيسية لاستخدام أشجار التأكيد في البلوكشين:

تعريف شجرة الميركل (Merkle Tree):

  • شجرة الميركل هي بنية بيانات شجرية حيث تكون كل ورقة (leaf) هي تجزئة (hash) لكتلة من البيانات، وكل عقدة (node) غير ورقية هي تجزئة تجمع من تجزئات العقد التابعة لها.
  • في قمة الشجرة، توجد “تجزئة الجذر” (root hash) التي تمثل جميع البيانات في الشجرة.

الأمان والتحقق:

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

نظرة عامة على استخدام شجرة التأكيد فى Arbitrum

يتم تأكيد حالة سلسلة Arbitrum مرة أخرى على Ethereum عبر “التأكيدات”، والمعروفة أيضًا باسم “التأكيدات القابلة للطعن” أو “DAs”. هذه هي الادعاءات التي قدمها محققو Arbitrum حول حالة السلسلة. لتقديم تأكيد، يجب على المحقق نشر سند في Ether.

في الحالة السعيدة / الشائعة، ستكون جميع التأكيدات المعلقة صالحة؛ أي أن التأكيد الصحيح سيعتمد على تأكيد صالح آخر، والذي يعتمد على تأكيد صالح آخر، وهكذا. بعد مرور فترة النزاع (حوالي أسبوع واحد) وعدم الطعن في التأكيد، يمكن تأكيده مرة أخرى على L1 “الطبقة 1”.

ومع ذلك، إذا كان هناك تأكيدان متعارضان أو أكثر، فإن شجرة التأكيد تتفرع إلى فروع متعددة

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

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

من أجل التأكد من التأكيد واستعادة حصته، يجب استيفاء شرطين: يجب أن يكون قد مر وقت كافٍ للنزاعات، ولا يمكن أن توجد فروع متعارضة أخرى في شجرة التأكيد (أي، تم الطعن فيها جميعًا / “تقليمها”).

تضمن هذه الخصائص معًا أنه طالما يوجد محقق نشط صادق واحد على الأقل، فسيتم تأكيد حالة السلسلة الصالحة في النهاية.

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

التأخير الوحيد الذي يواجهه المستخدمون أثناء النزاع هو رسائلهم من L2 إلى L1 (أي “عمليات السحب”). لاحظ أن “مهاجم التأخير” الذي يسعى إلى إزعاج النظام عن طريق التسبب عمدًا في مثل هذه التأخيرات سيجد أن هذا الهجوم مكلف للغاية، لأن كل جزء من وقت التأخير المكتسب يتطلب من المهاجم خسارة حصة أخرى.