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

المؤلف: Nic@ مختبرات imToken

متى يمكنني التأكد من تضمين معاملة L2 في كتلة؟ متى يمكنني التأكد من أن الإيرادات من معاملة L2 لن يتم تجاهلها بسبب إعادة التنظيم؟

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

المتطلبات المسبقه:

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

تعرف على معاملات L1

عملية المعاملة

رسم تخطيطي لتدفق المعاملات L1

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

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

تعرف على معاملات L2

عملية المعاملة

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

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

رسم تخطيطي لتدفق المعاملات L2

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

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

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

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

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

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

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

بعد ذلك ، سنلقي نظرة على بعض الطرق المختلفة التي يتم بها تقديم حالة إيرادات معاملات L2.

حالة إيرادات المعاملات من التحكيم / التفاؤل

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

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

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

** تحقق من حالة إيرادات المعاملات على التحكيم **

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

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

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

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

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

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

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

** تحقق من حالة أرباح المعاملات على التفاؤل **

ستتضمن المعاملات التي نراها في Optimism Explorer أيضا معاملات التأكيد المسبق ، أي المعاملات التي لم يتم تحميلها بعد إلى L1 ، كما هو موضح في الشكل التالي ، يمكننا أن نرى أن هناك رمز مؤكد بواسطة Sequencer بجوار رقم الكتلة 111526300:

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

ومع ذلك ، لا يبدو أن Explorer لديه مواصفات واضحة لما يعنيه Confirmed by Sequencer ، قائلا “تأكيدات Sequencer تعادل عددا قليلا من تأكيدات الكتلة على L1.” ، مما يشير إلى أن Confirmed by Sequencer يمثل عددا من Block التي تم تحميلها إلى L1 وتبعها عدة :

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

منذ عشرات الأيام ، كانت حالة المعاملة لا تزال عالقة في “تم التأكيد بواسطة Sequencer”

نصيحة للقراءة: قد يكون الموقف أعلاه أيضا هو أن المستكشف يضع علامة على حالات مختلفة في أماكن مختلفة: يخبر Confirmed By Sequencer بعد رقم الكتلة المستخدم أنه تم تأكيد الكتلة بواسطة Sequencer ، ويجب على المستخدم تأكيد الحالة بعد التحميل إلى L1 من خلال معلومات أخرى ، مثل معلومات “L1 State Batch” المذكورة أدناه.

بالإضافة إلى ذلك ، تحتوي المعاملة التي تم تحميلها إلى L1 كما هو موضح في لقطة الشاشة أدناه على معلوماتين إضافيتين: “L1 State Batch Index” و “L1 State Root Submit Tx Hash”. تمثل هاتان المعلومتان دفعة الحالة التي تم تضمين معاملة L2 فيها ومعاملة L1 التي تم من خلالها تحميل دفعة الحالة إلى L1:

انقر فوق دفعة الحالة “3480” ، يمكنك أن ترى أن حالتها قد تم الانتهاء منها ، والتي تتوافق مع الحالة النهائية ل L1 (أي ، Ethereum Mainnet) ، وهي حالة آمنة للغاية نجحت في تجميع أصوات اثنين من مدققي العصر.

△ تم الحصول على دفعة الدولة 3480 في L1 Block 18457449 ، وتم الانتهاء من Block 18457449.

مصدر:

إذا تم تحميل الدفعة ولكن لم يتم الانتهاء منها في L1 ، فسيتم عرضها ك ** غير نهائي: **

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

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

** حالة أرباح تداول StarkNet **

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

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

الوثائق الرسمية: _and_concepts/Network_Architecture/transaction-life-cycle/

ستتضمن المعاملات التي شوهدت على Starkscan ، StarkNet Explorer ، أيضا معاملات التأكيد المسبق ، كما هو موضح في الشكل التالي ، يمكنك أن ترى أن الحالة مقبولة حاليا على L2 ، مما يعني أنه تم تصنيفها في كتلة L2 بواسطة Sequencer:

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

أول حالتين من مقبول على L2 هي المستلمة والمعلقة ، مما يعني أنه “تم استلام المعاملة والتحقق منها” و “تتم معالجة المعاملة بواسطة Sequencer” ، وستدخل المعاملة في حالة مقبولة على L2 بعد تنفيذ المعاملة:

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

تتم معالجة المعاملة بواسطة Sequencer

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

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

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

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

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

حالة إيرادات معاملات zkSync

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

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

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

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

ستتضمن المعاملات التي تراها على zkSync Explorer أيضا معاملات التأكيد المسبق ، مثل تلك الموجودة في لقطة الشاشة أدناه ، يمكنك أن ترى أن الحالة هي حاليا zkSync Era تمت معالجتها ، مما يعني أنه تم تصنيفها في L2 Block بواسطة Sequencer:

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

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

تم تحميل الدفعة 292700 إلى L1 وهي في مرحلة الالتزام. مصدر:

تغيرت الحالة الحالية للمعاملة في الدفعة 292700 من إرسال Ethereum إلى التحقق من صحة Ethereum ، مما يشير إلى أنها تنتظر التحقق منها بواسطة Zero-Knowledge Proof.

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

تدخل هذه المعاملة مرحلة “التحقق من الصحة” ، ويمكن أيضا رؤية رابط المعاملة التي حملت الدفعة إلى L1 في المرحلة السابقة (الإرسال) هنا.

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

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

ستنتقل المعاملة أيضا من “التحقق من الصحة” إلى “uting” ، أي في انتظار تنفيذها.

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

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

تم أيضا تحديث حالة المعاملة في Batch إلى “uted”

على عكس StarkNet ، حيث يتم إكمال معاملات L2 إلى L1 في خطوة واحدة ، يتم تقسيم عملية zkSync لنقل L2 إلى L1 إلى ثلاث مراحل أكثر تفصيلا: ملتزم → مثبت →.

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

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

ومع ذلك ، تجدر الإشارة إلى أنه كإجراء حماية لمرحلة ألفا ، يمكن تعديل السجل بواسطة zkSync Sequencer في هذا الوقت.

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

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

إذا كنت تستطيع أن تعرف مسبقا من المسؤول عن إنتاج الكتل ، فيمكن ل L1 أيضا دعم التأكيد المسبق.

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

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

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

نصيحة للقراءة: لمزيد من المعلومات حول PBS ، يرجى نسخ الرابط أدناه للقراءة في متصفحك: _4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

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

التأكيد المسبق هو مجرد وعد شفهي من قبل المنشئ أو جهاز التسلسل L2 ، والطرف الآخر ليس ملزما بالوفاء بالوعد ، ولا توجد آلية عقوبة لعدم الوفاء.

هل من الممكن جعل هذا الوعد أكثر ضمانا؟ في الواقع ، نعم ، لأن الشخص المسؤول عن إنتاج الكتلة ومحتوى وعده (على سبيل المثال “في 1,350,000 حظر معاملة الإيرادات”) يمكن كتابته كفحص شرط. لذلك ، يمكننا استخدام العقد الذكي لتنظيم المنشئ أو جهاز التسلسل ، ومطالبتهم بتقديم خدمات التأكيد المسبق عند ضمان الإيداع في العقد الذكي ، وتوقيع المحتوى عند إعطاء وعد بدخل المعاملة ، عندما يجد المستخدم أن المنشئ أو جهاز التسلسل لم يف بالالتزام ، يمكن إرسال المحتوى الموعود وتوقيع الطرف الآخر إلى العقد الذكي ، ويمكن للعقد الذكي التحقق مما إذا كان الالتزام قد تم الوفاء به (مثل “في الأول 1,350,000 كتلة إيرادات لهذه الصفقة”).

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

ملخص

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

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