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

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

المعرفة الأولية:

• العملية برمتها للمعاملات L1 (الطبقة 1)
• أسباب وتأثيرات حدوث إعادة التنظيم
• فهم الأدوار وطرق العمل في الهندسية المعمارية الحالية لـ Ethereum PBS
• الاختلافات بين التراكم التفاؤلي والتراكم بالصحة (ZK)

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

عملية الصفقة

بعد أن يصدر المستخدم ويوقع على عملية النقل، يتم إرسالها إلى شبكة الند للند، في انتظار إدراجها في كتلة من قبل منقب بميكانيزم الإثبات العمل (PoW) أو مقترح بميكانيزم الإثبات بالحصة (PoS). عندما يلاحظ المستخدم أن تم إدراج عمليته في أحدث كتلة، فإنه ليس مؤكدا بعد أن سيتم تسجيل العملية بشكل دائم في تاريخ البلوكشين. يعود هذا العدم اليقين إلى احتمالية حدوث "Re-org" (إعادة التنظيم) على البلوكشين. يجب أن ينتظر المستخدمون حتى تكون احتمالية حدوث إعادة التنظيم منخفضة بما فيه الكفاية للثقة بأن عمليتهم ستُسجل بشكل دائم في تاريخ البلوكشين.

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

حتى بعد أن يتم تضمين عملية في كتلة، يمكن لإعادة التنظيم أن تحدث لا تزال، مما يعني أن الإكدار يمكن أن يتم تأكيده فقط عندما يصبح احتمال إعادة التنظيم غير مرجح.

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

فهم المعاملات L2

عملية الصفقة

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

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

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

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

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

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

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

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

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

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

حالة تضمين الصفقات في أربيتروم/أوبتيميزم

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

تعلم المزيد

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

للحصول على معلومات مفصلة أكثر حول دورة حياة تحويل Optimism، راجع الوثائق الرسمية: https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

حالة دخل التداول لأربيتروم/التفاؤل

حاليًا، بعد أن يقوم المستخدمون بإرسال عملية على Arbitrum أو Optimism، يمكنهم الحصول على إيصال العملية (Transaction Receipt) تقريبًا على الفور، الذي سيحتوي على نتائج تنفيذ العملية. هذا يعني أن المُرتَّب الزمني Sequencer قد رتَّب العملية محليًا وقام بمحاكاتها مرة واحدة. هذا إيصال العملية هو التأكيد المسبق الذي يُعطى للمستخدم.

تعلم المزيد

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

https://docs.arbitrum.io/tx-lifecycle

لمزيد من التفاصيل حول دورة حياة المعاملات في التفاؤل، يمكنك نسخ الرابط أدناه إلى المتصفح والرجوع إلى الوثيقة الرسمية:

https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

تحقق من حالة دخل العملية على أربترم

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

الصورة أعلاه تُظهر المعاملات التي تم تأكيدها فقط بواسطة المسلسل ولم يتم رفعها بعد إلى L1.

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

الكتلة L1 التي تحتوي على بيانات هذه الصفقة لديها بالفعل 69 كتلة تتبعها. كلما زاد عدد الكتل التي تتبعها، زادت الأمان.

أو لهذه المعاملة كما هو موضح في لقطة الشاشة أدناه، يحتوي الكتلة L1 التي تحتوي على بيانات هذه المعاملة بالفعل على 6174 كتلة تتبعها، وهو أمر آمن جدًا بالفعل.

ولكن في الواقع، ما يمكن القيام به هنا بشكل أفضل هو تقديمه بالاقتران مع معلومات النهوية من L1.

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

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

المعاملات المعروضة على مستكشف Optimism قد تتضمن تلك المعلمة بأنها قبل التأكيد، مما يشير إلى أنها لم يتم نشرها بعد على الطبقة 1 (L1). كما هو موضح أدناه، تم وسم المعاملة برقم الكتلة 111526300 بأنها "تم تأكيدها بواسطة Sequencer":

المعاملات تم تأكيدها فقط من قبل المُسلسل ولكن لم يتم نشرها بعد إلى L1

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

ومع ذلك، يتم عرض المعاملات الجديدة الظاهرة أيضًا باسم 'تأكيد بواسطة السجل'، وحتى المعاملات التي تمت قبل العديد من الأيام والتي تجاوزت فترة التحدي، تظل في حالة 'تأكيد بواسطة السجل':

المعاملات منذ أيام لا تزال في حالة "تم تأكيدها بواسطة المسلسل"

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

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

بنقر على "دفعة الحالة 3480"، يُظهر حالتها كما تم الإنتهاء منها، متوافقًا مع الحالة المنتهية على L1 (أي الشبكة الرئيسية لإيثريوم)، وهي حالة آمنة للغاية تم تحقيقها بعد تراكم التصويتات من المحققين على مدى حقبتين.

△ تم تضمين الدفعة 3480 في الحالة L1 Block 18457449، وتم استكمال Block 18457449.

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

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

الدفعة 3494، على الرغم من أنها تم نشرها إلى L1، مضمنة في كتلة L1 التي لم يتم تحديدها بعد

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

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

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

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

الوثائق الرسمية:دورة حياة معاملات ستاركنت

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

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

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

تم استلام العملية وتأكيدها.

يتم معالجة المعاملة من قبل المسلسل.

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

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

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

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

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

حالة عائدات المعاملات في zkSync

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

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

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

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

سيظهر التحققات المرئية على مستكشف zkSync أيضًا المعاملات قبل التأكيد، مثل المعاملة في اللقطة الشاشة أدناه. يمكنك أن ترى أن الحالة حاليًا هي zkSync Era Processed، مما يشير إلى أنه تم إضافتها إلى الكتلة L2 من قبل المسلسل:

تمت إدراج هذه المعاملة في كتلة L2 بواسطة السيكونسر وهي في انتظار التحميل إلى L1 (إيثريوم إرسال)

بعد اكتمال المُسَلِّسِل، سيمر الكتلة والمعاملات الموجودة فيها بثلاث مراحل: تأكيد، إثبات وتنفيذ، مما يعني على التوالي "تم تحميل الكتلة إلى L1" و"تمت إثبات صحة الكتلة" و"يتم تحديث حالة L2 إلى L1 بعد تنفيذ المعاملة في الكتلة." يظهر ما يلي ثلاث كتل ومعاملات في مراحل مختلفة:

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

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

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

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

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

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

المعاملات الداخلية ستدخل أيضًا مرحلة التنفيذ من "التحقق"، التي تنتظر التنفيذ.

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

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

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

الطبقة 1 يمكنها أيضًا دعم التأكيد المسبق

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

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

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

ملخص:

بعد تضمين معاملات L1 في كتل L1 ، تقل احتمالية إعادة التنظيم ، وتزداد ثقة المستخدمين في تضمين المعاملات تدريجيا. تحتوي معاملات L2 على سير عمل إضافي مقارنة بمعاملات L1: "يتم تضمين معاملات L2 في كتل L2 وتنتظر التحميل إلى L1." ومع ذلك ، نظرا لعدم تحميل البيانات إلى L1 في هذه المرحلة ، لا يزال هناك احتمال للتباين ، لذا فإن التأكيد الذي يمكن للمستخدمين الحصول عليه حول تضمين المعاملة في هذه المرحلة هو الالتزام الشفهي من جهاز التسلسل ، والمعروف باسم التأكيد المسبق أو التأكيد السريع / التأكيد الناعم. إذا كان جهاز التسلسل ضارا أو واجه خطأ ببساطة ، فيمكن كسر وعده ، مما يؤدي إلى عدم تأكيد معاملة المستخدم L2. حاليا ، تعرض معظم L2s حالات المعاملات في المستكشفين الخاصة بهم والتي تتضمن حالة التأكيد المسبق ، مثل Arbitrum / Optimism's Confirmed by Sequencer أو StarkNet's Accepted on L2. عند رؤية مثل هذه المعلومات ، من المهم الانتباه إلى الفعالية الزمنية لضمان تضمين المعاملة المقدم. إذا كان المستخدمون لا يرغبون في الاعتماد على التأكيد المسبق لجهاز التسلسل ، فسيحتاجون إلى الانتظار لفترة أطول والتحقق من خلال معلومات L2 Explorer حول بيانات L2 التي يتم تحميلها إلى L1. يمكن أن يتضمن التأكيد المسبق آلية حوافز اقتصادية ، مثل معاقبة Sequencers من خلال العقود الذكية عندما يخالفون وعودهم ، مما يوفر للمستخدمين حماية أوضح. يوضح الجدول أدناه ضمانات إدراج المعاملات وسيناريوهات المخاطر المقابلة التي توفرها معاملات L1 و L2 في مراحل مختلفة من عملية المعاملة.

تنويه:

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