في العالم الحقيقي ، تحتوي كل ناطحة سحاب تقريبا على عنصر لا غنى عنه: مخرج للطوارئ. عندما تحدث أحداث غير متوقعة مثل الحرائق أو الزلازل ، فإن هذه المخارج هي المنقذة للحياة من أجل سلامة الناس. وبالمثل ، في النظام البيئي Ethereum Layer 2 ، الذي يحتفظ بمليارات الدولارات من الأصول ، أصبحت ميزة "السحب القسري" التي تسمح للمستخدمين بسحب الأصول بأمان إلى الطبقة 1 مرفقا أساسيا.

أكد فيتاليك أيضًا في مقاله الأخير “أنواع مختلفة من الطبقات 2” أن القدرة على سحب الأصول بسلاسة من الطبقة 2 إلى الطبقة 1 مؤشر أمان مهم جدًا للمستخدمين.

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

بهدف رفع الوعي لدى القراء حول مخاطر الأمان في الطبقة 2، سيستخدم "Geek Web3" بروتوكول Loopring V3 وArbitrum كأمثلة في النص التالي لشرح لماذا "وظائف السحب بدون إذن" مثل السحب القسري وبوابة الهروب ضرورية كمكونات لا غنى عنها في الطبقة 2.

(وفقًا لمتصفح L2BEAT dYdX ، حتى الآن ، تم استخدام وظيفة التداول / السحب القسري لـ dYdX مجموع 152 مرة ، مع سحوبات كبيرة تزيد عن مليون دولار تبلغ 7 حالات) مقاومة الرقابة هي قضية كبيرة: ماذا لو رفض المسلسل طلبك بشكل متعمد؟

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

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

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

حتى إذا كانت الحالات القليلة التي قد تواجه مثل هذه الوضعيات، إذا حدث ذلك لبعض 'الحيتان' الذين يحملون كميات كبيرة من الأموال، فإن السوق بأكمله قد يعاني. على سبيل المثال، لنفترض أن شخصًا لديه مئات الملايين من الدولارات في أصول في بروتوكول الإقراض DeFi على إيثيريوم يواجه التصفية خلال أسبوع ولكنه تم معاقبته من قبل OFAC بسبب استخدام Tornado. معظم أمواله على منصة Optimism (OP)، والمتسلسل OP، وفقًا لتوجيهات OFAC، يرفض طلباته.

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

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

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

إذا، كيف يمكن حل هذه المشكلة؟ ببساطة، كيف يمكننا تنفيذ وظيفة السحب 'بدون إذن' التي تسمح للمستخدمين بسحب أصولهم بأمان إلى الطبقة 1 حتى عندما يكونون تحت المراقبة من قبل سلسلة أحداث أو فريق عمل مشروع الطبقة 2؟ قد اقترح بعض فرق المشاريع فكرة وجود مُسلسلين لامركزيين، ولكن هذا هو حلاً سطحيًا. إذا تآمروا هؤلاء المُسلسلين المحدودون لفحصك، فيمكنهم لا زالة 'تجميد' أصولك. علاوة على ذلك، مشكلة هجمات السايبل المضادة في عقد الحصة الأثبتية (PoS) أيضًا مشكلة (كما رأينا في حادثة متعددة السلاسل).

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

في سياق إصدار البروتوكول Loopring الإصدار 3، يحدد سيناريوهين مختلفين للسحب القسري الذي يبدأه المستخدم. السيناريو الأول هو كما يلي:

يمكن للمستخدمين بشكل مباشر بدء سحب إجباري على الطبقة 1 باستخدام وظيفة forcedWithdraw في عقد ExchangeV3. يجب عليهم الإعلان عن حسابهم في الطبقة 2 في بروتوكول Loopring والرمز الذي يرغبون في سحبه. بعد ذلك، يقوم عقد ExchangeV3 بإصدار حدث في سلسلة الكتل، يشير إلى أن شخصًا ما بدأ طلب سحب إجباري. نظرًا لأن جميع العُقد في بروتوكول Loopring، بما في ذلك Sequencer، يعملون بعميل Geth، سيتم إعلامهم بالسحب الإجباري وحدث سلسلة الكتل المقابل من بيانات كتل Ethereum.

من المهم ملاحظة أن عملية السحب القسري لا تتم على الفور، بل يتم وضعها في قائمة السحوبات القسرية المعلقة، في انتظار المعالجة. عند ملاحظة عملية السحب القسري التي بدأت على الطبقة 1، يقوم المُسلسل عادةً بتشغيل وظيفة المعالجة في عقد ExchangeV3 خلال 15 يومًا. تقوم هذه الوظيفة بتنفيذ تحويل الرموز على سلسلة Ethereum إلى مبادل السحب (من عنوان إيداع مشروع الطبقة 2 على سلسلة Ethereum إلى المسحوب).

إذا فشل جهاز التسلسل في الرد على طلب سحب المستخدم الإجباري في غضون 15 يومًا، يمكن للمستخدم استدعاء وظيفة notifyForcedRequestTooOld. يؤدي هذا الإجراء إلى تنبيه عقد ExchangeV3 بإصدار حدث يسمى WithdrawalModeActivated، مع إخطار جميع العقد في بروتوكول Loopring بتنشيط وضع تصفية الإفلاس.

إذا تم تنشيط وضع تصفية الإفلاس، فإن بروتوكول لوبرينج V3 سيتوقف عن تلقي كتل L2 الجديدة التي تقدمها السيكونسر، وهذا يعني أن بروتوكول لوبرينج بأكمله سيتوقف عن العمل في هذا الوقت. ستستمر هذه العملية لمدة لا تقل عن 30 يومًا.

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

يصف المقال نموذج تصفية إفلاس بروتوكول Loopring، المعروف أيضًا باسم آلية "Escape Hatch" على L2BEAT. يتم تشغيل هذا النموذج في ظروف معينة، مثل عندما يفشل المُعدل في الرد على طلب سحب مستخدم مجبر في الوقت المحدد، أو إذا تعرض المُعدل لعطل طويل الأجل أو إغلاق. في مثل هذه الحالات، يمكن للمستخدمين تشغيل عملية يضعون فيها عقد Rollup في حالة مجمدة أو متوقفة. يمكن للمستخدمين بعد ذلك إنشاء دليل Merkle ليظهروا وضع أصولهم في الطبقة 2 وسحب جزء أصولهم من عنوان إيداع مشروع الطبقة 2 على الطبقة 1.

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

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

ميزة 'ضمان إدراج المعاملات بالقوة' في Arbitrum

ومع ذلك ، لا يبدو أن الانسحابات القسرية / كبسولات الهروب هي الحل الوحيد لمكافحة الرقابة. على سبيل المثال ، يستخدم Arbitrum طريقة "تضمين المعاملات القسري" ، حيث يمكن للمستخدمين أولا إرسال المعاملات / السحوبات التي تحتاج إلى معالجتها بواسطة Sequencer إلى عقد Inbox المتأخر في الطبقة 1 (L1). إذا فشل جهاز التسلسل في معالجتها في غضون 24 ساعة ، فيمكن للمستخدمين استدعاء وظيفة تضمين القوة في عقد صندوق الوارد L1 Sequencer ، مما يسمح بتضمين المعاملة مباشرة في تسلسل معاملات Arbitrum (عن طريق إلقاء حدث على السلسلة لإبلاغ عقد Arbitrum بأن العديد من المعاملات المسجلة في صندوق الوارد المتأخر يجب تضمينها في دفتر الأستاذ L2).

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

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

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

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

لذلك، فإن صفقات الإدماج أو سحب القوة الحالية في Arbitrum ليست بمقدورها أن تكون مفتوحة كما هو الحال في طريقة تصفية الإفلاس الخاصة بـ Loopring و StarkEx. ومع ذلك، لا تزال L2BEAT تقيم هذا النهج من Arbitrum بشكل عالي. في المستقبل، ستقوم Arbitrum بإطلاق آلية نشر تصدق مفتوحة تدعى BOLD، مما يجعل من الصعب، إن لم يكن مستحيلاً، على العقداء (الذين يصعب عليهم الآن) الاندماج.

وفقًا لبيانات من L2BEAT، حاليًا، تشمل منصات طبقة 2 (L2) التي يفوق إجمالي القيمة المقفلة (TVL) فيها 50 مليون دولار، والتي لا تقدم تدابير لمعالجة فشل المتسلسل أو فشل المقترح، OP Mainnet، Base، zkSync Era، Mantle، Starknet، Linea، Polygon zkEVM، وMetis. يمكن أن تؤدي هذه المنصات L2، في حالات شديدة، إلى تجميد أصول المستخدمين وعدم القدرة على سحبها من L2.

لذلك ، من الواضح أن الحاجة إلى آليات مثل السحب القسري أو أوضاع تصفية الإعسار موجودة. على الرغم من أنهم يعتمدون حاليا بشكل أساسي على نظرية اللعبة بين المستخدمين والفرز (منتجي الطلبات) ، ولا يمكن اعتبارهم حقا "قابلين للسحب في أي وقت" (Arbitrum لديه تأخير لمدة 24 ساعة يمكن أن يفشل ، Loopring لديه تأخير يصل إلى 15 يوما ، StarkEx لديه تأخير لمدة 7 أيام كحد أقصى) ، من الواضح أن وجود هذه الآليات أفضل من عدم وجودها على الإطلاق. ومن المحتمل أن تحل مسألة التأخير في عمليات الانسحاب القسري في المستقبل بتصاميم آلية أكثر تطورا. تأخذ التصاميم الحالية في الاعتبار الاستغلال المحتمل ل MEV (القيمة القصوى القابلة للاستخراج) من خلال التضمين القسري ، مما يستلزم إدخال التأخير. لمزيد من التفاصيل ، ينبغي الرجوع إلى الوثائق الرسمية من مختلف مشاريع L2.

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

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

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