متى يمكن للشخص التأكد من أن صفقة L2 (الطبقة 2) ستُدرج في كتلة؟ متى يمكن للشخص أن يكون متأكدًا من أن الأرباح من صفقة L2 لن تُرفض بسبب Re-org؟

ستقدم هذه المقالة للقراء العملية الكاملة لتنفيذ معاملة L2 وتحليل الأداء الأمني في كل مرحلة من مراحل عملية المعاملة.

المعرفة المسبقة:

1. عملية كاملة لمعاملات L1 (الطبقة 1)

2. أسباب وآثار إعادة التنظيم

3. فهم الأدوار وأساليب التشغيل في بنية PBS الحالية ل Ethereum

4. فهم الاختلافات بين Optimistic Rollup و Validity (ZK) Rollup

فهم المعاملات L1

عملية الصفقة

بعد أن يصدر المستخدم معاملة ويوقع عليها ، يتم إرسالها إلى شبكة نظير إلى نظير وينتظر عامل منجم بموجب آلية إجماع إثبات العمل أو مقترح بموجب آلية إجماع PoS لتضمينه في كتلة. عندما يجد المستخدم أن معاملته قد تم تضمينها في أحدث كتلة ، لا يمكن أن يكون متأكدا بنسبة 100٪ من أن المعاملة سيتم تسجيلها بشكل دائم في سجل blockchain هذا. ويرجع ذلك إلى إمكانية حدوث حدث blockchain يعرف باسم "Re-org". يجب على المستخدمين الانتظار حتى يكون احتمال حدوث إعادة التنظيم في كتلة معينة منخفضا بما يكفي ليكونوا واثقين من أن معاملتهم سيتم تسجيلها في تاريخ blockchain.

توضيح عملية المعاملة L1

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

احتمالية وتكلفة Re-org تختلف اعتمادًا على خوارزمية توافق سلسلة وقيمة سوق أصولها. لن يتم مناقشة طريقة حساب تكلفة Re-org بالتفصيل هنا.

فهم معاملات L2

عملية الصفقة

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

عملية توضيح عملية المعاملات L2

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

تأكيد مسبق / تأكيد سريع / تأكيد ناعم

يجب على المستخدمين أن يشهدوا idealmente معاملاتهم L2 (المدرجة في كتل L2) تشمل في كتل L1، وانتظر حتى يكون احتمال إعادة تنسيق منخفض بما فيه الكفاية، قبل الثقة بأن تم تضمين معاملاتهم L2. ولكن ماذا لو كان المستخدمون على استعداد للثقة بمسلسل الأحداث؟ لنفترض أن المسلسل يتم تشغيله من قبل فريق تطوير L2 أو مؤسسة ذات سمعة طيبة. إذا أكد المسلسل للمستخدمين عند استلام معاملاتهم أنها ستتضمن فورًا أو في الكتلة X، فقد تكون هذه الضمانة كافية لأولئك الذين يرغبون في الثقة بالمسلسل. هذا يشبه المستخدم الذي يثق في تطبيق محفظته ولا يتحقق بشكل متكرر من تأكيد المعاملة في Etherscan بعد أن أعلمته المحفظة بتضمينها.

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

المرة القادمة، سنقدم عدة طرق مختلفة لعرض حالة إدراج المعاملة L2.

حالة تضمين المعاملة على أربيتروم/أوبتيميزم

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

لمزيد من المعلومات حول دورة حياة المعاملة التفصيلية على Arbitrum ، يمكنك الرجوع إلى المستند الرسمي على: https://docs.arbitrum.io/tx-lifecycle

لمزيد من التفاصيل حول دورة حياة المعاملات على منصة Gate.io ، راجع المستند الرسمي على: https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

التحقق من حالة إدراج المعاملة في التحكيم

يتضمن المعاملات المعروضة على مستكشف Arbitrum تلك ذات التأكيد المسبق، أي المعاملات التي لم تُحمّل بعد إلى L1. كما هو موضح في الصورة التالية، تم وضع علامة على المعاملة برقم الكتلة 145353000 باسم "تم تأكيدها بواسطة المُسلسل"، مما يشير إلى أنه تم تأكيد المعاملة بواسطة المُسلسل ولكن لم يتم رفعها بعد إلى L1:

[الصورة تظهر عملية تم تأكيدها من قبل Sequencer ولكن لم يتم تحميلها على L1]

على العكس، تُظهر الصورة التالية صفقة تم تحميلها بالفعل على L1، بحالة "69 تأكيداً للكتلة L1". وهذا يعني أن الكتلة L1 التي تحتوي على بيانات هذه الصفقة لها 69 كتلة تتبعها، مما يشير إلى مستوى أعلى من الأمان:

[الصورة تظهر عملية تحويل على L1 بتأكيد 69 كتلة]

مثال آخر هو عملية بتأكيدات كتلة 6174 L1، كما هو موضح أدناه، والتي تعتبر آمنة للغاية.

ومع ذلك، سيكون من الأفضل إذا تم دمج معلومات Finality L1 في هذا العرض. إذا كان مجرد إخبار المستخدمين بعدد تأكيدات الكتل L1 مساعدة محدودة، حيث يتعين عليهم فهم وحساب ما يمثله هذا الرقم من مستوى الأمان. نظرًا لأن الطبقة 1 (Ethereum) لديها آلية Finality مثل Casper FFG، يمكن أن يعرض المستكشف مباشرة ما إذا تم تثبيت الكتلة Layer 1. حاليًا، فقد قام Explorer لـ Optimism بتنفيذ هذه الميزة.

التحقق من حالة تضمين المعاملة على Optimism

يتضمن الصفقات المعروضة على مستكشف Optimism أيضًا تلك التي تحتوي على ما قبل التأكيد، أي الصفقات التي لم تُرفع بعد إلى L1. كما هو موضح في الصورة التالية، تم وضع علامة على صفقة برقم الكتلة 111526300 كـ "تم تأكيدها بواسطة المتسلسل":

[تظهر الصورة معاملة تم تأكيدها فقط بواسطة Sequencer ولكن لم يتم تحميلها إلى L1]

ومع ذلك، لا يحدد المستكشف بوضوح معنى "تأكيد بواسطة المتسلسل". يقول: "تأكيدات المتسلسل مكافئة لعدد قليل من تأكيدات الكتل على L1"، مما يقترح أنه تم تحميل عملية مميزة بأنها "تأكيد بواسطة المتسلسل" إلى L1 ولديها العديد من الكتل التالية لها:

[الصورة تظهر المعاملات الأخيرة المسماة "تم تأكيدها من قبل المسلسل"]

المعاملات منذ عدة أيام، حتى تلك التي تجاوزت فترة التحدي، لا تزال تعرض حالة "تم تأكيدها بواسطة المُرتَتب":

[يظهر الصور المعاملات منذ أيام ماضية ما زالت معلمة بـ "تأكيد بواسطة السلسلة"]

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

كما هو موضح في اللقطة الشاشة التالية، تتضمن المعاملة التي تم تحميلها بالفعل على المستوى L1 معلومات إضافية: "L1 State Batch Index" و "L1 State Root Submission Tx Hash." تشير هذه التفاصيل إلى الدفعة الحالية التي تم تضمين المعاملة L2 فيها والمعاملة L1 التي قامت بتحميل هذه الدفعة الحالية إلى L1:

[يظهر صورة لعملية تحتوي على معلومات دفعة حالة L1]

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

[Image shows State Batch 3480 finalized in L1 Block 18457449]

المصدر: https://etherscan.io/block/18457449

إذا تم تحميل دفعة ولكن لم يتم الانتهاء منها بعد على L1 ، عرضها على أنها غير منتهية:

[تظهر صورة دفعة حالة تم تحميلها على L1 ولكن لم يتم الانتهاء منها بعد]

بالمقارنة مع مستكشف Arbitrum، يوفر مستكشف Optimism مزيدًا من المعلومات (State Batch) ويدمج معلومات L1 Finality مباشرة في مستكشف L2، مما يتيح للمستخدمين معرفة ما إذا تمت تثبيت كتلة L1 دون الحاجة إلى تفسير عدد تأكيدات الكتلة من أجل الأمان.

حالة عائدات المعاملات في شبكة ستارك

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

ملاحظة: إذا قام المسلسل بمعالجة المعاملات بسرعة كافية، فقد يتخطى حالة الاستلام وينتقل مباشرة إلى حالة معالجة. لمزيد من التفاصيل حول عملية المعاملات في StarkNet ، راجع المستند الرسمي علىhttps://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/

على Starkscan، المستكشف StarkNet، تُعرض المعاملات بما في ذلك التأكيد المسبق. على سبيل المثال، تُشير المعاملة التي تظهر باسم "مقبولة على L2" إلى أنه تم ترتيبها في كتلة L2:

"تم قبوله على L2" يعني أن تم تسلسل المعاملة في كتلة L2 ولم يتم تحميلها بعد على L1.

الحالتان السابقتان، Received و Pending، تمثلان "تلقي الصفقة والتحقق منها" و"تجهيز الصفقة بواسطة المسلسل". بعد الانتهاء من المعالجة، تتغير الحالة إلى Accepted على L2.

المعاملة تم استلامها والتحقق منها

يتم معالجة الصفقة بواسطة المسلسل

بعد تحميل بيانات المعاملة على L1، سيتغير الحالة إلى مقبولة على L1، كما هو موضح في الشكل أدناه لهذه المعاملة:

تم تحميل بيانات المعاملات إلى L1

على الرغم من أن معاملات StarkNet لديها مجموعة أوسع من الحالات، مما يتيح للمستخدمين معرفة تقدم معاملاتهم، فإن تحميلها إلى L1 يمكن أن يستغرق عدة ساعات، وذلك يرجع أساسا إلى الوقت اللازم لإنشاء الأدلة ذات الصفر المعرفة. لذلك، يعتمد المستخدمون على تأكيد Sequencer قبل التأكيد خلال هذه الفترة.

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

نظرا لقيود أداء StarkNet ، والاعتماد الطويل على التأكيد المسبق ، ونقص الدعم لمعلومات L1 Finality في Explorer ، فإن تجربة المستخدم لتأكيد تضمين المعاملات على StarkNet تحتاج إلى تحسين.

حالة تضمين معاملة zkSync

على غرار StarkNet، يحتوي zkSync أيضًا على حالة PENDING، والتي تشير إلى أن العقد قد تلقى وتحقق في المعاملة بدون أي مشاكل. ستنتظر المعاملة بعد ذلك لتُدرج وتُنفذ في كتلة L2 بواسطة المُسلسل. لا تحتوي المعاملات في حالة PENDING بعد على أية نتائج تنفيذ.

يمكن للمستخدمين تتبع تقدم معاملاتهم من خلال الحالة المعروضة على مستكشف zkSync.

نصيحة القراءة: إذا قام المُسلسل بمعالجة المعاملات بسرعة كافية، فقد يتجاوز حالة الانتظار وينتقل مباشرة إلى حالة تمت معالجة المعاملة بالفعل.

لمزيد من التفاصيل حول عملية المعاملات في zkSync، اتبع هذا الرابط: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

تشمل المعاملات التي يتم عرضها على مستكشف zkSync أيضًا معاملات ما قبل التأكيد، مثل تلك الموجودة في لقطة الشاشة أدناه. الحالة حاليًا هي "تمت معالجة عصر zkSync"، مما يشير إلى أنه تم ترتيبه في كتلة L2 بواسطة المُسلسل:

تم ترتيب الصفقة في كتلة L2 من قبل السلسلة الزمنية وهي في انتظار رفعها حاليا إلى L1 (إرسال إيثيريوم).

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

تم تحميل الدفعة 292700 إلى L1 ودخلت مرحلة الالتزام. المصدر: https://explorer.zksync.io/batch/292700

تغيرت حالة المعاملات في الدفعة 292700 من إرسال Ethereum إلى التحقق من Ethereum، مما يشير إلى أنها في انتظار التحقق من صحة البرهان الخالي من المعرفة.

سيؤدي تحريك السهم فوق أيقونة التحقق من صحة Ethereum أيضا إلى إظهار المراحل المختلفة ، كما سيتم إرفاق رابط المعاملة للمرحلة السابقة (الإرسال):

دخلت هذه المعاملة مرحلة "التحقق". يمكن رؤية رابط المعاملة لتحميل الدُفعة إلى L1 في المرحلة السابقة (الإرسال) أيضًا مباشرة هنا.

الدفعة 292000 قد أثبتت صحة صلاحيتها، لذلك تدخل مرحلة الإثبات:

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

المعاملات تنتقل بعد ذلك من "التحقق" إلى "التنفيذ"، مما يعني أنها في انتظار التنفيذ.

بعد أن يتم إثبات دُفعة، هناك فترة انتظار (حوالي 21 ساعة وفقًا للوثائق الرسمية) قبل تنفيذ المعاملات ضمنها وتحديث الحالة L2 المُسجلة على L1. هذا إجراء وقائي في المرحلة ألفا لضمان وجود وقت رد كافٍ في حالة وجود علل. بمجرد تنفيذ الدُفعة، تدخل مرحلة التنفيذ النهائية:

بعد التنفيذ، يدخل الدفعة في حالة التنفيذ النهائية، مع رابط للمعاملة التي تنفذ إجراء التنفيذ.

يتم تحديث حالة المعاملات داخل الدُفعة أيضًا إلى "تم التنفيذ".

بالمقارنة مع StarkNet، حيث تنتقل المعاملات من L2 إلى L1 في خطوة واحدة، يقوم zkSync بتقسيم العملية من L2 إلى L1 إلى ثلاث مراحل أكثر تفصيلاً: تم الارتكاب → تم إثباته → تم تنفيذه. على الرغم من أن العملية بأكملها تستغرق حوالي يوم كإجراء وقائي، يتيح حالة التم الارتكاب للمستخدمين معرفة سريعة ما إذا تم تضمين معاملتهم (بعد التم الارتكاب، ليس فقط قبل التأكيد) دون الاعتماد فقط على الثقة في المُرتب. بالإضافة إلى ذلك، يوفر zkSync Explorer بيانات شاملة لكل مرحلة، مما يمكن أي شخص من تتبع أحدث حالة للمعاملات وحتى التحقق من التحولات بين المراحل (على سبيل المثال، من تم الارتكاب إلى تم إثباته، من تم إثباته إلى تم تنفيذه).

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

يمكن لـ L1 دعم التأكيد المسبق أيضًا

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

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

نصيحة القراءة: لمزيد من المعلومات حول Gate.io، يرجى نسخ الرابط أدناه إلى متصفحك للقراءة: https://mirror.xyz/0x347c9872A2a1dE370D798f9FE96341A9A0E05af8/oG_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

تحسين التأكيد المسبق

التأكيد المسبق هو مجرد وعد شفهي من Builder أو L2 Sequencer ، دون أي التزام بالوفاء به ولا آلية عقاب لعدم الامتثال. هل يمكن جعل هذا الوعد أكثر موثوقية؟ نعم ، لأن محتوى الالتزام (على سبيل المثال ، "تضمين هذه المعاملة في المربع 1350000") الذي قدمه الشخص المسؤول عن إنتاج الكتل يمكن كتابته كشيك مشروط. وبالتالي ، يمكننا استخدام العقود الذكية لتنظيم Builders أو Sequencers ، ومطالبتهم بإيداع ضمانات في العقد الذكي عند تقديم خدمات التأكيد المسبق والتوقيع على محتوى الالتزام. إذا وجد المستخدمون أن Builders أو Sequencers لم يفوا بوعودهم ، فيمكنهم إرسال الالتزام والتوقيع على العقد الذكي للتحقق منه.

على الرغم من أن تطبيق مثل هذه العقود لا يزال في مرحلة دليل السياق ، إلا أن الرابط التالي إلى فيديو العرض التقديمي يعرض مثالًا واحدًا على تطبيق العقد:

https://www.youtube.com/watch?v=Uw5HxSYXwYo

ملخص

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

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

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

حاليا ، تعرض معظم L2s حالة المعاملة في المستكشفين ، بما في ذلك حالة التأكيد المسبق ، مثل "Confirmed by Sequencer" من Arbitrum / Optimism أو "مقبول على L2" من StarkNet. يجب أن يكون المستخدمون على دراية بالصلاحية الزمنية لضمان تضمين المعاملة الذي توفره هذه الحالات.

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

يمكن أن يتضمن مرحلة قبل التأكيد آلية حافز اقتصادي، مثل العقوبات من خلال العقود الذكية للمسلسلين الذين يخرقون وعودهم، مما يوفر حماية أوضح للمستخدمين.

يظهر الجدول أدناه ضمانات إدراج المعاملة وسيناريوهات المخاطر المقابلة لمراحل مختلفة من المعاملات L1 و L2: [يرجى ملاحظة أن الجدول غير متوفر في الترجمة.]

تنصل:

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