شكر خاص لجون شاربونو وكونور ماكمينامين لمراجعة هذه المقالة.

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

في L2BEAT نريد معالجة هذه المشكلة وجعلها في متناول الجميع. على وجه الخصوص، نريد التركيز على النهاية، وهي أقوى قاعدة تأكيد ضد هجمات الإنفاق المزدوج.

قواعد التأكيد: الاتساق مقابل التوفر

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

تمنح قواعد التأكيد المختلفة المستخدمين ضمانات أمان مختلفة. يشمل أمان قاعدة التأكيد الاتساق والتوافر، ويعتمد بشكل كبير على خوارزميات الإجماع الأساسية:

• التناسق (الأمان): تكون طريقة عرض أي عقدتين متسقة ضمن أقسام الشبكة.
• التوفر (الحيوية): يستمر إدراج المعاملات في دفتر الأستاذ في غضون فترة زمنية معينة حتى بعد توقف جزء كبير من العقد عن المشاركة في البروتوكول.

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

لا تستطيع Eve معرفة ما إذا كان Bob ببساطة غير متصل بالإنترنت أو على قسم شبكة مختلف.

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

قواعد التأكيد على إيثريوم

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

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

دائمًا ما يكون دفتر الأستاذ النهائي (الأخضر) بادئة لدفتر الأستاذ المباشر (الأزرق).

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

يمكن للمستخدمين اختيار ما إذا كانوا يريدون استخدام Casper FFG كقاعدة التأكيد الأكثر أمانًا أو أن يكونوا أكثر نشاطًا من خلال الاعتماد على LMD GHOST. يمكن أن تكون قواعد التأكيد لـ LMD GHOST، على غرار قاعدة تأكيد k في بيتكوين، أكثر تعقيدًا من مجرد النظر فيما إذا كانت المعاملة مدرجة في دفتر الأستاذ، كما هو محدد في قاعدة تأكيد Safe Block.

قواعد التأكيد على المجموعات

يمكن لـ Rollups، من حيث المبدأ، استخدام نفس قواعد التأكيد المتاحة على Ethereum. إذا قمت بإرسال معاملة في مجموعة، وشاهدت لاحقًا نفس المعاملة المنشورة على L1 في كتلة نهائية، فقد ترغب أيضًا في اعتبار معاملة L2 نهائية. تبين أن القصة أكثر تعقيدًا بكثير من هذه.

مجموعات بيانات المعاملات

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

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

مجموعة اختلافات الدولة

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

تقدم تقنيات تجميع الأدلة حلاً لهذه المقايضة بين أوقات التأكيد واستهلاك التكلفة: حتى إذا كانت المجموعة تواجه الحد الأدنى من النشاط، فلا يزال بإمكانها الاستفادة من الاستهلاك من خلال تضمين المعاملات من مجموعات أكثر نشاطًا في نفس الإثبات. أحد الأمثلة على هذا النهج هو SHARP من Starkware، الذي يقوم حاليًا بتجميع البراهين من مجموعات Starknet و Paradex و StarkEx مثل dyDx وحتى Validiums.

حيث تتعقد الأمور

مواصفات الاشتقاق التراكمي

وفي حالة عدم استناد المجموعة، يمكن تحديد ترتيب الاشتقاق للدفعات بواسطة مُسلسِل التجميع، والذي قد ينشرها بترتيب مختلف على L1.

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

في سلاسل OP Stack، يكون وقت الكتلة هو ثانيتين، مما ينتج عنه 6 كتل داخل كل كتلة من كتل Ethereum. يُطلق على هذه المجموعة المكونة من 6 كتل بين كتل إيثريوم اسم «العصر». يتم تضمين رسائل L1-to-l2 المرسلة عبر L1 في الجزء الأول من الكتلة الأولى من الحقبة المقابلة لكتلة L1 المحددة. بينما يمكن اعتبار هذه المعاملات مؤكدة دون انتظار مرور نافذة التسلسل، حيث أن ترتيبها داخل دفتر الأستاذ L2 عند الاشتقاق معروف، فمن المهم ملاحظة أن العقد لن تبدأ في حساب الكتل التي تحتوي على هذه الرسائل إذا كانت الدفعة السابقة مفقودة. هذا لأنه لا يمكن حساب الحالة بدون التسلسل الكامل، وبالتالي، لن يتم نشر جذور الحالة أيضًا على L1.

والنتيجة هي أن مجرد فحص البيانات على السلسلة غير كافٍ لتتبع أوقات تأكيد L1. من الضروري أيضًا فهم كيفية اشتقاق كتل L2 من بيانات L1 من خلال فحص برنامج عقدة التجميع نفسه.

الوظائف المسموح بها

Scroll عبارة عن مجموعة ZK تنشر بيانات المعاملات، مما يعني أنه، من حيث المبدأ، لا يحتاج المرء إلى انتظار إثبات ZK لاعتبار معاملته نهائية. كان من الممكن أن يكون هذا صحيحًا إذا لم يقوموا بتنفيذ وظيفة لحذف الدفعات التي لم يتم إثباتها بعد.

https://etherscan.io/address/0x2e07f0fba71709bb5e1f045b02152e45b451d75f#code#F1#L260

يمكن أن ينطبق الشيء نفسه على المجموعات التي تنشر اختلافات الحالة: لدى ZKSync Era و ZKSync Lite عملية من ثلاث خطوات لنشر اختلافات الحالة: أولاً، يقومون بإيداع البيانات دون أي دليل، ثم يقدمون دليلًا عليها، وبعد ذلك، بعد تأخير لمدة 24 ساعة، يصبح الجذر متاحًا للتنفيذ لمعالجة عمليات السحب. من الناحية النظرية، عندما يتم تقديم دليل، يتم إصلاح ترتيب المعاملات، لذلك لا يحتاج المرء إلى الانتظار حتى يمر تأخير التنفيذ. باستثناء ذلك، يمكن لـ ZKSync إرجاع هذه الكتل:

https://etherscan.io/address/0x7Ed066718Dfb1b2B04D94780Eca92b67ECF3330b#code#F10#L425

بينما لم يتم إرجاع أي كتل على الإطلاق في ZKSync Era، فقد حدث ذلك 8 مرات على ZKSync Lite.

قابلية الملاحظة النهائية

نظرًا لأن الاختلافات في حالة النشر التراكمي لا تنشر بيانات المعاملات، فكيف يمكننا تتبع أن المعاملة قد تم تضمينها بالفعل؟ نعم، يمكننا تتبع التأثيرات، مثل ظهور الحساب، لكن الحالة العامة تصبح صعبة. قبل شهر طرحت السؤال التالي:

دعونا نلقي نظرة على بعض الردود:

هذا هو الحل الذي يعمل إذا كان المنظم على استعداد للرد عليك وإذا كنت تثق به. ماذا لو لم يحدث ذلك؟ أو ماذا لو حدث ولكنك لا تثق به؟ كيف تتحقق من صحة المطالبة؟

ردي المفضل.

تم اقتراح حل يعمل بالفعل هنا:

في حين أن هذا يعمل، فهذا يعني أن القرار الفني لاستخدام اختلافات الحالة يتسرب إلى منطق التطبيق، مما يعني أنه حتى لو كانت المجموعة التراكمية مكافئة لـ EVM، يجب على المشاريع تكييف عقدها مع هذا الاعتبار.

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

مقاييس مدى الحياة

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

فيما يلي بعض الأمثلة على البيانات التي نتتبعها لـ ZKSync Era (تحديثات الحالة) و OP Mainnet (دفعات tx):

مقاييس البث المباشر لـ ZKSync Era لشهر سبتمبر.

أعلى مقاييس الحياة في Mainnet لشهر سبتمبر.

كما هو متوقع، نظرًا لأن أدلة ZK تستغرق وقتًا ليتم إنشاؤها وهناك حافز لتضمين المزيد من المعاملات في دليل واحد، فإن ZKSync Era لديها مقاييس حياة أسوأ من OP Mainnet. من المهم أن تضع في اعتبارك أنه، كما ناقشنا في الأقسام السابقة، لا تُترجم مقاييس الحيوية مباشرة إلى اعتبارات نهائية: في أسوأ الحالات، تتمتع OP Mainnet بالفعل بوقت أعلى للنهاية بسبب نافذة التسلسل الخاصة بها.

يمكنك الآن استكشاف مقاييس الحياة لمعظم المجموعات على L2BEAT:

قيود تتبع الحياة

في حين يمكن اعتبار الحيوية مؤشرًا أدنى للنهاية، إلا أنها قد تكون في بعض الأحيان مؤشرًا سيئًا للغاية. تخيل مجموعة تراكمية بوقت كتلة يبلغ 4 ثوانٍ، مما يعني أنه لكل كتلة من كتل إيثريوم هناك ٣ كتل تراكمية. إذا كان مشغل المجموعة ينشر كتلتين فقط من L2 لكل كتلة L1، حتى لو كانت المجموعة حية جدًا من منظور إيثريوم، فسوف تتخلف بشكل متزايد عن تأكيدات L2 الناعمة وسيزداد الوقت حتى النهاية سوءًا بشكل متزايد. في حين أن هذا سيناريو متطرف، إلا أنه أمر تحتاج المجموعات التراكمية إلى حسابه.

مثال عملي هو Starknet: على الرغم من أننا نلاحظ متوسط 32 ثانية بين تحديثات الحالة، فإن وقت الانتهاء يقترب فعليًا من 6 ساعات:

المصدر: starkscan.co

هذا لأن Starknet تنشر تحديثًا جذريًا للحالة لكل كتلة L2 على L1. ومع ذلك، للقيام بذلك، يجب عليهم الرجوع إلى دليل SHARP، والذي يتم نشره عادةً مرة واحدة تقريبًا كل 30 دقيقة. بالإضافة إلى ذلك، فإن هذه البراهين متأخرة بحوالي 6 ساعات عن طرف سلسلة L2 المؤكدة بشكل ناعم.

التأكيدات الناعمة

التأكيدات الناعمة هي قواعد تأكيد تستخدم لتحقيق أوقات تأكيد أقصر على L2 على حساب ضمانات السلامة. حاليًا، في جميع الحالات، تعني التأكيدات الناعمة الثقة في المشغل المركزي بعدم نشر txs مختلفة على L1. التأكيدات الناعمة غير الصحيحة هي أخطاء تعزى، وبالتالي يمكن تنفيذ آليات لتتبع سمعة أجهزة التسلسل خارج السلسلة أو القطع على السلسلة. بالتعاون مع Nethermind، نخطط لتقدير خصائص الأمان هذه وتتبع مقدار القيمة المعرضة للخطر في أي لحظة من الزمن.

على اليسار: ضمانات اقتصادية على Starknet إذا كانت لديها تأكيدات ناعمة مضمونة بآلية خفض. على اليمين: القيمة الإجمالية المعرضة لخطر إعادة ترتيبها بمرور الوقت.

المضي قدمًا

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

إخلاء المسؤولية：

1. تمت إعادة طباعة هذه المقالة من [medium]. جميع حقوق التأليف والنشر تنتمي إلى المؤلف الأصلي [Luca Donno]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسيتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها.