المؤلف: فاوست ، المهوس Web3
في العالم الحقيقي ، يحتوي كل مبنى شاهق تقريبا على عنصر لا غنى عنه: مخرج أمان. عندما تسقط حالات الطوارئ مثل الحرائق والزلازل ، فإن مخارج السلامة هي المنقذ لضمان سلامة حياة الناس. في نظام منصة الحفظ Ethereum Layer 2 ، الذي يحمل عشرات المليارات من الدولارات من الأصول ، أصبحت وظيفة “السحب القسري” ، التي تسمح للمستخدمين بسحب الأصول بأمان إلى الطبقة 1 ، مرفقا ضروريا لا غنى عنه.
في مقالته الأخيرة “أنواع مختلفة من الطبقة 2s” ، أكد فيتاليك أيضا أن قدرة المستخدمين على سحب الأصول بسلاسة من الطبقة 2 إلى الطبقة 1 هي مؤشر أمان مهم للغاية.
ومع ذلك ، لا يبدو أن مسألة “الانسحاب السلس” قد حظيت باهتمام كبير من معظم الناس في الماضي ، وحتى العديد من مشاريع الطبقة 2 لم تطلق وظيفة “الانسحاب القسري” أو “جراب الهروب”. في العصر الذي لا يكون فيه النظام البيئي L2 على قدم وساق ، لا يبدو أن تجاهل “عمليات السحب بدون إذن” يمثل مشكلة. ولكن الآن بعد أن أصبح لدى Layer 2 أكثر من 12 مليار دولار من الأصول ، فقد أصبح مبنى “أكبر من أن يفشل”. إذا لم يكن لدى ناطحة السحاب هذه مخرج أمان ، فإن العواقب ببساطة لا يمكن تصورها.
بهدف جعل القراء ينتبهون إلى المخاطر الأمنية للطبقة 2 ، سيأخذ “Geek Web3” بروتوكول Loopring V3 و Arbitrum كأمثلة أدناه لشرح سبب كون “وظائف السحب غير المصرح بها” مثل السحب القسري وفتحة الهروب جزءا لا غنى عنه من الطبقة 2.
(وفقا لمتصفح L2BEAT dYdX ، تم استخدام وظيفة المعاملة / السحب القسري dYdX 152 مرة حتى الآن ، وكانت هناك 7 عمليات سحب كبيرة بأكثر من مليون دولار.)
مقاومة الرقابة هي المشكلة الكبيرة: ماذا تفعل إذا رفض جهاز التسلسل طلبك عمدا ****
في الماضي ، غالبا ما واجهت المقالات العلمية الشائعة حول الطبقة 2 مشكلة ، أي أنها ركزت في معظم الأحيان على “الأمان” و “سهولة الاستخدام” على السطح ، لكنها تجاهلت “مقاومة الرقابة”. حتى عند الحديث عن حلول التسلسل اللامركزية ، ينتبه الكثير من الناس إلى ما إذا كانت MEV لامركزية ، وليس مقاومة الرقابة.
بمعنى آخر ، يميل معظم الناس إلى التركيز على ما إذا كانت انتقالات حالة الطبقة 2 صالحة ، وما إذا كان جهاز التسلسل يمكنه سرقة العملات المعدنية ، وما إذا كان نظام إثبات الصلاحية / الصلاحية قيد الاستخدام ، لكنهم يتجاهلون المخاطر التي لا ينبغي التغاضي عنها: ماذا لو استمر جهاز التسلسل في رفض طلبات المعاملات الخاصة بك ، أو فشل ببساطة لفترة طويلة ، أو حتى انخفض؟ **
كما تعلمون ، أثناء انقطاع Solana ، كان هناك أشخاص غير قادرين على تغطية مراكزهم في الوقت المناسب لأن أصولهم كانت تواجه التصفية ، مما يعرض ملايين الدولارات من الأصول للخطر. ** بمجرد حدوث مثل هذا الرفض لطلب المستخدم ، فإن الخسارة الاقتصادية الناجمة لا يستهان بها.
حتى لو كان عدد قليل من الناس في هذا الموقف ، إذا وقع على بعض الحيتان مع الكثير من المال ، فقد يعاني السوق بأكمله (لنفترض أن شخصا ما لديه مئات الملايين من الدولارات من الأصول على بروتوكول إقراض Defi على Ethereum يمكن تصفيته في غضون أسبوع ، لكنه مدرج في قائمة عقوبات مكتب مراقبة الأصول الأجنبية لاستخدام Tornado). معظم أموال هذا الشخص موجودة في البروتوكول الاختياري ، ويعمل جهاز تسلسل البروتوكول الاختياري مع مكتب مراقبة الأصول الأجنبية لرفض طلبه)
قد نقوم أيضا بإسقاط هذه المشكلة على سلاسل عامة مثل الانهيار الجليدي أو المضلع ، والتي تكون مستقلة عن Ethereum. إذا قررت أكثر من 2/3 من عقد إجماع المدقق على Avalanche فرض رقابة على معاملاتك ، فيمكنهم رفض تضمين Txn الخاص بك في كتلة ، أو عدم التعرف على الكتلة التي تحتوي على Txn الخاص بك. في هذا الوقت ، يتم دفن أموالك بشكل أساسي في هذه السلسلة ولا يمكنها الخروج: **
ما لم تتمكن من استمالة بعض المدققين بحيث يشارك أقل من 2/3 من المدققين في هجوم الرقابة ، أو يمكنك دعوة بعض الأشخاص إلى تقسيم Avalanche من خلال الإجماع الاجتماعي. من الواضح ، في هذه المرحلة ، لا يزال لديك طريقة لسحب الأموال بسرعة من Avalanche ، وعلينا أن نأخذ في الاعتبار أن أكثر من 2/3 من المدققين يوحدون قواهم لبدء مراجعة المعاملات لعنوان معين ، والذي يستغرق في حد ذاته بعض الوقت لتحقيقه ، مما سيترك وقتا كافيا للمستخدمين الخاضعين للرقابة “للهروب”.
لكن في الطبقة 2 ، يمكن أن يكون الوضع مختلفا تماما. يتم تشغيل Layer 2 Sequencer بشكل عام من قبل المسؤول نفسه ، وإذا أراد Sequencer شن هجوم رقابة عليك ، فيمكنه “تجميد أموالك في الطبقة 2” ، أي رفض طلب معاملتك تماما لعبور الأصول من L2 إلى L1. من الواضح ، وفقا لآلية تشغيل L2 ، إذا لم تتمكن من تجاوز جهاز التسلسل لإجراء عملية سحب ، فمن الممكن تماما أن يقوم جهاز التسلسل بتجميد الأصول في L2 ولا يمكن نقلها.
فكيف تحل هذا النوع من المشاكل؟ في الواقع ، بصراحة ، كيفية تنفيذ وظيفة السحب “بدون إذن” ، بحيث يمكن للمستخدمين سحب أصولهم إلى الطبقة 1 دون أي ضرر عند مراجعتها من قبل أطراف مشروع Sequencer أو Layer 2؟ هناك بعض المشاريع التي اقترحت جهاز التسلسل اللامركزي ، ولكن هذا ليس حلا ملطفا ، وإذا انضم عدد محدود جدا من أجهزة التسلسل لمراجعتك ، فلا يزال بإمكانك “تجميد” أصولك ، كما أن مكافحة عقدة نقاط البيع هي أيضا مشكلة صعبة (انظر أحداث متعددة السلاسل).
الطريقة الأكثر فعالية للقيام بذلك هي إعداد “خروج” مباشرة على سلسلة L1 ، مما يسمح للمستخدمين بسحب الأموال من L2 من خلال مخرج مخصص على L1 إذا لم يحصلوا على استجابة من Sequencer لفترة طويلة. **
****بروتوكول التكرار V3 نموذج الانسحاب القسري وتصفية الإفلاس ****
هنا نأخذ الإصدار V3 من بروتوكول Loopring كمثال ، والذي يسرد سيناريوهين مختلفين لعمليات السحب القسري التي بدأها المستخدم ، الحالة الأولى هي:
يمكن للمستخدمين بدء سحب قسري مباشرة على الطبقة 1 من خلال وظيفة forcedWithdrawal في عقد ExchangeV3 ، والإعلان عن حساب L2 الذي لديهم في بروتوكول Loopring ونوع الرمز المميز الذي يريدون سحبه. بعد ذلك ، يلقي عقد ExchangeV3 حدثا على السلسلة للإشارة إلى أن شخصا ما قد بدأ طلب سحب قسري. نظرا لأن جميع عقد بروتوكول Loopring (بما في ذلك Sequencer) تعمل على تشغيل عملاء Geth ، فمن المعروف من كتلة Ethereum أن شخصا ما بدأ انسحابا قسريا وأثار الحدث المقابل على السلسلة.
من المهم ملاحظة أن عمليات السحب القسري لا تتم معالجتها على الفور ، ولكن يتم وضعها في قائمة انتظار ForcedWithdrawals المعلقة وهي معلقة. ** لاحظ Sequencer أنه بعد أن يبدأ شخص ما عملية سحب قسري في الطبقة 1 ، يتم تشغيل وظيفة العملية في عقد ExchangeV3 في غضون 15 يوما لنقل الرمز المميز إلى بادئ السحب على سلسلة Ethereum (من عنوان إيداع طرف مشروع L2 على سلسلة Ethereum لتحويل الأموال إلى المسحوب).
إذا لم يستجب Sequencer لطلب السحب القسري للمستخدم في غضون 15 يوما ، فيمكن للمستخدم استدعاء وظيفة notifyForcedRequestTooOld لجعل عقد ExchangeV3 يلقي حدثا يسمى WithdrawalModeActivated لإخطار العقدة الكاملة لبروتوكول Loopring بتنشيط وضع تصفية الإفلاس. **
** إذا تم تنشيط وضع التصفية ، فسيتوقف Loopring V3 عن تلقي كتل L2 الجديدة المقدمة بواسطة Sequencer ، مما يعني أن بروتوكول Loopring بأكمله سيتوقف عن العمل. تستمر هذه العملية 30 يوما على الأقل.
ومع ذلك ، في وضع تصفية الإفلاس ، لا يزال بإمكان المستخدمين سحب أصولهم على الطبقة 1 ، لكنهم بحاجة إلى تقديم دليل merkle لإثبات حالة / حالة أصولهم ، والتي يمكن التحقق منها على شجرة حالة L2. (** إثبات أن رصيد الأصول الخاص بك في الطبقة 2 يتوافق مع المبلغ الذي أعلنته عند بدء السحب **)
يعرف نموذج تصفية الإفلاس هذا لبروتوكول Loopring أيضا باسم آلية Escape Hatch على L2BEAT. يتم تشغيل هذا الوضع بناء على شرط أساسي لجهاز التسلسل الذي لا يستجيب لطلب السحب القسري للمستخدم خلال الوقت المحدد ، أو إذا كان جهاز التسلسل يعاني من فشل أو توقف طويل الأجل. في هذا الوقت ، يمكن للمستخدم تشغيل عقد الإظهار يدويا في وضع التجميد / إيقاف التشغيل. بعد ذلك ، يمكن للمستخدمين إنشاء إثباتات merkle لإثبات أصولهم على الطبقة 2 ، وسحب أصولهم الخاصة من عنوان إيداع طرف مشروع L2 في L1. **
في وثائق StarkEx ، يتم أيضا رسم رسم تخطيطي مخصص لهذه العملية. إذا لم يتلق مستخدم L2 استجابة جهاز التسلسل في نهاية نافذة 7 أيام عندما يرسل مستخدم L2 طلب سحب إجباري على L1 ، فيمكن لمستخدم L2 استدعاء وظيفة طلب التجميد لإدخال L2 في فترة التجميد. في هذه الحالة ، لن يتمكن جهاز التسلسل L2 من تحديث حالة L2 على L1 ، وسيستغرق الأمر عاما واحدا بعد تجميد حالة L2 ليتم إلغاء تجميدها. بعد ذلك ، يمكن للمستخدمين إرسال دليل Merkle وسحب الأموال.
ومع ذلك ، من أجل إنشاء Merkle Proof ، تحتاج إلى معرفة شجرة حالة L2 الكاملة أولا ، أي أنك تحتاج إلى العثور على عقدة L2 كاملة لطلب البيانات ، وفي الوقت نفسه ، تحتاج إلى جزء من التعليمات البرمجية لإنشاء Merkle Proof ، والذي من الواضح أنه يتطلب عتبة فنية معينة. من أجل راحة غالبية المستخدمين ، ذكرت L2BEAT سابقا أن الطبقة 2 يجب أن تنشئ عددا من العقد الكاملة بأذونات مفتوحة وشفرة مفتوحة المصدر لمساعدة المستخدمين على معرفة حالة جميع الحسابات على L2 (بما في ذلك الرصيد وعدد المعاملات وما إلى ذلك). توضح هذه الخطوة أيضا أهمية عمليات السحب الإلزامية وآليات الهروب.
ميزة “التضمين القسري للمعاملات” في Arbitrum
لكن لا يبدو أن عمليات السحب القسري / الهروب هي الحل الوحيد المقاوم للرقابة. على سبيل المثال ، يستخدم Arbitrum طريقة “فرض تضمين المعاملات” ، ويمكن للمستخدم أولا إرسال Txn / السحب الذي يحتاج إلى معالجة بواسطة Sequencer في عقد Inbox المتأخر على L1 ، وإذا لم يعالجه Sequencer لأكثر من 24 ساعة ، يمكن للمستخدم استدعاء وظيفة تضمين القوة لعقد Sequencer Inbox على L1. دع Txn يتم تضمينه مباشرة في تسلسل معاملات Arbitrum ** (قم بإلقاء حدث على السلسلة لإبلاغ عقد Arbitrum الكاملة بأن Txn مع بعض سجلات البريد الوارد المتأخرة تحتاج إلى تضمينها في دفتر الأستاذ L2).
في المقابل ، فإن نهج Arbitrum أبسط ، لكنه لا يزال غير موجود بعض الشيء: فهو يلقي فقط حدثا على السلسلة يخبر عقدة Arbitrum أن هناك بعض المعاملات التي يتجاهلها جهاز التسلسل والتي يجب تضمينها في أطول سلسلة L2 ، بدلا من السماح للمستخدمين بسحب الأموال مباشرة على L1 كما يفعل بروتوكول Loopring ووضع الإفلاس / جراب الهروب من StarkEx. إذا اتحدت العقد المنافسة في Arbitrum معا لشن هجوم رقابي ، فيبدو أنه لا يزال من الممكن تجميد أموال المستخدمين في L2. **
لذا فإن تضمين قوة Arbitrum ليس بلا إذن كاف ، وعلى الرغم من أنه سيكون من الجيد القول إن جهاز التسلسل تجاهل طلب forceInclusion الخاص بالمستخدم طالما كانت هناك عقدة صادقة على استعداد لنشر دليل على الاحتيال ، إلا أن هذا لا يزال يقدم درجة معينة من افتراض الثقة ، وإن كان بدرجة أقل.
بتعبير أدق ، يجب التعرف على “المعاملات التي يجب تضمينها إلزاميا” من قبل عقدة منافسة ARB واحدة على الأقل ، والتي تحتوي حاليا على 9 عقد لها الحق في تحديد الرسائل عبر السلسلة L2-L1 التي يجب السماح بها ، والآن يمكنهم فقط إصدار أدلة على الاحتيال. ** طالما أن هذه العقد ال 9 تتواطأ معا ، فمن الناحية النظرية لا يزال من الممكن إبطال “المعاملة القسرية” للمستخدم. **
لذلك ، فإن الإدراج الإلزامي الحالي للمعاملات / السحوبات في Arbitrum لا يشبه نموذج تصفية الإفلاس في Loopring و StarkEx الذي لا يتطلب إذن عقدة L2. ومع ذلك ، لا يزال L2BEAT يمنح Arbitrum تصنيفا عاليا لهذا الحل. لأنه في المستقبل ، ستطلق Arbitrum آلية تحرير إثبات الاحتيال بدون إذن تسمى BOLD ، وسيكون من الصعب أو المستحيل على العقد المنافسة التواطؤ في ذلك الوقت (من الصعب في الواقع التواطؤ الآن).
وفقا ل L2BEAT ، فإن TVL الحالي يزيد عن 50 مليون دولار ، ولا توجد استجابة لأي من حالات فشل التسلسل أو فشل المقترح: ** OP Mainnet و Base و zkSync Era و Mantle و Starknet و Linea و Polygon zkEVM و Metis. يمكن أن تتسبب L2s هذه في تجميد أصول المستخدم في L2 في الحالات القصوى. **
من الواضح أن نموذج الانسحاب القسري أو تصفية الإفلاس له ضرورته ، على الرغم من أنه في الوقت الحالي يعتمد فقط على تسلسل المستخدم كلعبة الطرف المقابل للعمل ، ** ليس حقا “جاهزا للانسحاب” ** (Arbitrum لديه تأخير لمدة 24 ساعة ويمكن أن يفشل ، Loopring لديه تأخير أقصى يبلغ 15 يوما ، StarkEx لديه تأخير أقصى يبلغ 7 أيام) ، ولكن من الواضح أن “شيئا أفضل من لا شيء”. علاوة على ذلك ، يعتقد أن مشكلة التأخير في عمليات السحب القسري سيتم حلها بشكل صحيح في المستقبل من خلال تصميم آلية أكثر تطورا ** (في الوقت الحالي ، يرجع ذلك أساسا إلى حقيقة أن بعض علماء MEV قد يستخدمون forceInclusion لبدء المعاملات الأمامية ، لذلك من الضروري إدخال التأخير.) لمزيد من التفاصيل ، يرجى الرجوع إلى الوثائق الرسمية لأطراف مشروع L2 الرئيسية).
مع إدراج Sequencer اللامركزي في المزيد والمزيد من خرائط طريق L2 ، وتواصل مؤسسة Ethereum بقيادة Vitalik تثقيف الناس حول أمان الطبقة 2 ، لا بد من إيلاء المزيد والمزيد من الاهتمام لميزات المعاملات المقاومة للرقابة مثل عمليات السحب القسري ، مما سيجعل نظام Ethereum Layer2 أقرب إلى نظام بنية تحتية مالية مقاوم للرقابة وغير موثوق به. إذا نفذت الطبقة 2 وصولا غير موثوق به إلى الأموال ، فمن المعتقد أن المزيد من صناع السوق ومقدمي السيولة سيدخلون البنية التحتية L2 ، وسيتم دفع التبني الجماعي للويب 3 بأكمله خطوة أخرى إلى الأمام.
