المؤلف الأصلي: باتريك ماكوري
التجميع الأصلي: لوفي ، أخبار البصيرة
ستختار أي قاعدة بيانات تتفاعل مع أصول التشفير يوما ما مجموعة التحديثات كحزمة تقنية. هناك عدد من الأسباب الوجيهة للمطورين لاتخاذ مثل هذا القرار:
- التدقيق في الوقت الحقيقي
- شهادة الملاءة الافتراضية
- ضمان أموال المستخدم اختياري
- مشارك صادق في الحزب يحمي النظام بأكمله
الأهم من ذلك ، تركز جميع جهود تصميم وتنفيذ Rollup على حماية المستخدمين وأموالهم وجميع تفاعلاتهم من مشغلي النظام الأقوياء الذين يحتمل أن يكونوا غير معروفين.
حتى إذا كان النظام بأكمله غير متصل بالإنترنت ، يمكن للمستخدمين استرداد أموالهم بأنفسهم.
إذا كان من الممكن نشر Rollups على نطاق واسع كمجموعة تقنية ، فقد تكون لدينا القدرة على كسر حواجز الثقة وتمكين التفاعلات المالية لأي شخص في المجتمع العالمي ، مما يؤدي إلى حقبة جديدة من التجارة الإلكترونية العالمية ، والتوظيف عن بعد ، وتقديم الخدمات بدون احتكاك.
يتطلب الأمر الكثير من الجهد للحصول على مجموعة التحديثات لأداء بشكل صحيح.
ماذا عن المتعددات؟
هذا يبدو جيدا ، ولكن يتم التحكم في النظام بأكمله في النهاية بواسطة multisig. إذا كان الموقع مخترقا أو ضارا ، فيمكنه بسهولة سرقة جميع الأموال.
إذن ، من يهتم بالتراكمات؟ في مكان ما على CT.
صحيح أن جميع المجموعات الحالية لديها multisig ولها الحق في ترقية العقد الذكي الأساسي ، ولكن كما سنرى ، إنها آلية محافظة تحمي أموال المستخدمين وهي جزء من بنية نظام أوسع.
مسؤوليات لجنة السلامة
Multisig هو مصطلح تقني يشير إلى نظام يتطلب عدة موقعين لتفويض إجراء ما. على سبيل المثال ، يكمل K من الموقعين N التوقيع الرقمي للسماح بالمعاملة.
في سياق عمليات التجميع ، غالبا ما يشار إلى multisig باسم لجنة أمنية ، حيث يتم منح الموقعين سلطة ترقية جميع العقود الذكية ذات الصلة.
دعونا نلقي نظرة على مجلس الأمن في التحكيم (كما أنا على دراية كبيرة به) للحصول على فكرة عن أنواع المسؤوليات التي قد تتحملها هذه المنظمة:
*حق النقض. إذا اعتقدت لجنة الأمن أن الاقتراح الذي تم تمريره من قبل Arbitrum DAO ينتهك ميثاق التحكيم وقد يضر بالنظام البيئي للتحكيم ، فيجوز لها إلغاء الاقتراح. على سبيل المثال ، قم بإلغاء اقتراح تم تمريره بسبب هجوم الحوكمة.
*صيانه. قم بترقية مجموعة العقود الذكية Arbitrum لإجراء تغييرات طفيفة أقل تأثيرا ولا تتطلب مشاركة Arbitrum DAO.
*حالات الطوارئ. استجب بسرعة في حالة الطوارئ ، وإذا اعتقدوا أن أموال المستخدمين معرضة لخطر وشيك ، فيمكنهم ترقية العقد الذكي بشكل عاجل.
بالطبع ، الشيء الأكثر أهمية هو أن الواجب الأول للجنة الأمنية هو الاستجابة لحالات الطوارئ والتصرف بسرعة لحماية أموال المستخدمين.
يجب أن يكون أعضاء لجنة السلامة أشخاصا جديرين بالثقة.
هناك ثقة في الموقعين ليكونوا قادرين على الاستجابة بسرعة ، ليكونوا قادرين على ترقية العقد الذكي في حالة الطوارئ ، وبذل قصارى جهدهم للحفاظ على الأموال في العقد الذكي آمنة.
حدد عتبة multisig الصحيحة
هناك عاملان مهمان يجب مراعاتهما عند اتخاذ قرار بإنشاء لجنة سلامة:
- كم عدد الموقعين هناك؟
- ما هو الحد الأدنى لعدد الموقعين المطلوب للموافقة على إجراء ما؟
- قد يبدو هذا سؤالا تافها ، بعد كل شيء ، إنه مجرد رقمين ، ولكن هناك عمل موازنة يجب مراعاته:
- خرق أمني: قد يتواطأ أعضاء K لتغيير العقود الذكية وسرقة أموال المستخدمين.
- انتهاك نشط: يتواطأ أعضاء N-K + 1 لمنع أي تغييرات على العقد الذكي ، خاصة إذا تم العثور على ثغرة أمنية حرجة.
ويتمثل التحدي في وضع عتبة تحافظ على سلامة الأموال في وقت السلم وتتصرف بسرعة في حالة الطوارئ عندما تكون أموال المستخدمين مهددة.
دعونا نفكر في مثال محدد. لنفترض أن الحد قد تم تعيينه على 9/10 حيث يجب على 9 موقعين المشاركة في توقيع رسالة. هذه عتبة أمنية صارمة حيث يجب على 9 موقعين التواطؤ لسرقة الأموال. ومع ذلك ، فإن الجانب السلبي هو أن أي موقعين اثنين يمكنهما منع أي إجراء في حالة الطوارئ. على سبيل المثال ، إذا سافر اثنان من الموقعين بعيدا على متن رحلة عبر المحيط الأطلسي ، فلن تتمكن لجنة السلامة من أداء واجباتها.
بالطبع ، إذا كان حد الأمان منخفضا ، دعنا نقول 2/10 ، فلن يتطلب الأمر سوى تواطؤ أي موقعين (أو اختراق المفتاح الخاص) لسرقة أموال المستخدمين.
من المرجح أن يتغير تصور نزاهة الشخص بمرور الوقت
اختيار العتبة المناسبة هو قضية اجتماعية أكثر من كونها قضية تقنية ، وأعتقد أنها فن أكثر من كونها علما. يعتمد الأمن بشكل كبير على سلامة الموقع الفردي. كما سنرى قريبا ، هناك طرق لتقليل الثقة في multisig ، ولكن هذا يأتي مع سلسلة من المقايضات.
عضو لجنة السلامة
يقوم الإظهار الرئيسي على الفور بترقية عتبة multisig المطلوبة لجميع العقود الذكية
تحتوي معظم Rollups على مجموعة من الموقعين المجهولين في لجانهم الأمنية. نشك في أن هذا قد يكون بسبب:
- مرحلة تطوير التراكمي ،
- لحماية السلامة الشخصية للأعضاء،
- نعتقد أن عدم الكشف عن هويته هو الخيار الأفضل لحماية أموال المستخدمين.
- من ناحية أخرى ، هناك ثلاثة مشاريع Rollup أعلنت عن عضويتها في اللجان الأمنية:
- Arbitrum: يتم انتخاب الموقعين علنا ، ويمكن الاطلاع على القائمة الحالية على Tally. يرتبط ثلاثة موقعين فقط بمشروع Arbitrum (اثنان من Offchain Labs وواحد من مؤسسة Arbitrum).
- القاعدة: 2/2 multisig ، واحد تسيطر عليه قاعدة والآخر تسيطر عليها التفاؤل.
- Polygon zkEVM: لم يتم تنفيذه بعد ، لكنهم أعلنوا أنهم سيقومون بترقية multisig إلى 10/13 ، والذي يتضمن عضوين من Polygon Labs ومستشار واحد من Polygon Labs.
- zkSync Lite: يجب تمييز zkSync Lite عن ZkSync Era ، التي يتم الإعلان عن لجنة السلامة الخاصة بها علنا ولا تشمل الشركات التابعة المباشرة من مشروع Rollup (باستثناء المستثمرين في zkSync).
في Arbitrum ، وفي Polygon القادم ، يرتبط عدد قليل فقط من الموقعين مباشرة بمشروع Rollup ، والعدد صغير بما يكفي لضمان عدم تواطؤ الشركات التابعة لمنع الإجراءات التي تتخذها اللجنة الأمنية. في zkSync Lite ، بالإضافة إلى مستثمري zkSync ، يعينون الموقعين المستقلين عن المشروع.
في جميع الحالات ، يضع Rollup قيمة عالية على الموقعين الذين لا يرتبطون مباشرة بالمشروع.
ومع ذلك ، يبدو أن هناك عدم توافق في الآراء حول ما يشكل multisig جيدة ، مما يقودنا إلى العديد من قضايا التصميم:
- هل يجب السماح للأعضاء المجهولين؟
- هل يجب أن يكون الأعضاء من مناطق جغرافية مختلفة؟
- هل يجب أن يكون الأعضاء أفرادا أم شركات؟
- هل ينبغي تعيين الأعضاء أو انتخابهم؟
- كم عدد الأعضاء من نفس الشركة (أو البلد) الذي يجب السماح به؟
- هل هناك حد أدنى للحجم والعتبة التي تعتبر مناسبة؟
يجب أن تكون القاعدة العامة هي اختيار أعضاء يتمتعون بدرجة عالية من النزاهة حتى يثق الجمهور في أمن النظام. على الأقل ، أعتقد أن معظم المشاريع ربما تفعل ذلك ، حتى لو لم يكن هذا دائما قابلا للتحقق منه علنا.
ملاحظة تم حاليا تعيين ستة أعضاء في لجنة أمن التحكيم مسبقا ، لكن سيتم استبدالهم في انتخابات مارس.
إضعاف صلاحيات الهيئة
حتى الآن ، نظرنا في لجنة واحدة فقط لديها القدرة على ترقية العقد الذكي على الفور ، ولكن هناك طرق للحد من صلاحيات اللجنة:
تأخير الوقت. لن يتم تنفيذ جميع الإجراءات التي أذنت بها اللجنة وتصبح سارية المفعول حتى انقضاء الوقت.
إيقاف مؤقت فقط. يمكن تجميد جميع الأصول التي يحتفظ بها الجسر الأصلي عبر السلسلة من قبل اللجنة. قد يؤدي هذا إلى تعليق الميزات التالية:
- تسليم الرسالة من L2 إلى L1 (أي سحب الأموال) ،
- استكمال فرز المعاملات المعلقة ،
- استكمال نقاط التفتيش / الشهادات الجديدة ،
- قبول بيانات التجميع الجديدة (أي المعاملات المعلقة).
عمولة الالتفافية (تمت إزالتها). التخلي عن اللجنة والاعتماد على آلية حوكمة أخرى ، مثل DAO ، للموافقة على الترقية.
وهذا، بطبيعة الحال، يحد من قدرة اللجنة على التصرف بسرعة وقدرتها على الاستجابة بفعالية لحالات الطوارئ التي تهدد أموال المستخدمين.
إذا تم الكشف عن الثغرة الأمنية للجنة بشكل خاص ، ولكن لم يتم استغلالها بعد من قبل المتسللين ، فإن لجنة الأمن لديها خيار ترقية العقد الذكي وإصلاح الخطأ. تؤدي إضافة تأخير زمني إلى ترقية إلى زيادة خطر قيام المهاجم بالبحث عن ترقية تم الكشف عنها بشكل عام، والعثور على ثغرة أمنية، ثم استغلالها.
على سبيل المثال ، تم الإعلان عن CVE-2018-17144 في BTC في البداية على أنها ثغرة DDoS في محاولة لإخفاء ثغرة تضخم رمزية أكثر خطورة. سرعة الترقية أمر بالغ الأهمية لمنع استغلالها.
تقييم دفاعات آلية الإيقاف المؤقت فقط
دعنا نفكر في سيناريو محتمل للمهاجم لاستغلال ثغرة أمنية بشكل نشط:
- رسائل L2 → L1 الخبيثة. يمكن للمهاجم صياغة رسائل عشوائية تنشأ من عقد ذكي على مجموعة التحديثات وإعادة توجيه الرسالة إلى العقد الذكي على ETH عبر جسر أصلي عبر السلسلة.
- انتقالات الحالة غير صالحة. يمكن للمهاجم تنفيذ معاملة على مجموعة التحديثات التي تنتهك قواعد وظيفة انتقال الحالة ويجب اعتبارها غير صالحة بشكل عام.
- ثغرات الانسحاب. يمكن للمهاجم سحب الأموال من الجسر الأصلي عبر السلسلة ببساطة عن طريق إصدار معاملة على ETH Fang (الطبقة 1).
في جميع الحالات الثلاث ، يمنح التأخير الزمني المهاجم مزيدا من الوقت لمواصلة سرقة الأموال ويقلل من نافذة الفرصة للجنة للدفاع عن النظام. لا تحمي ميزة الفاصل الزمني من الهجمات النشطة ويمكن استخدامها فقط للصيانة الروتينية والمهام غير العاجلة.
سنقوم فقط بتقييم القدرة على إيقاف النظام مؤقتا ومدى إمكانية تعليق النظام.
في حالة رسائل L2 → L1 الضارة ، يمكن لميزة الإيقاف المؤقت التخفيف من الهجوم دون التدخل في أنشطة التداول. على اللجنة تعليق الرسائل و/أو وضع اللمسات الأخيرة على وظائف نقاط التفتيش الجديدة. هناك حجة مفادها أنه يجب أن يكون هناك تأخير زمني قبل تنفيذ رسالة L2 → L1 بحيث يكون لدى اللجنة الوقت لاكتشاف الأخطاء والاستجابة لحالات الطوارئ.
يعد الدفاع ضد انتقالات الحالة غير الصالحة أكثر تعقيدا لأن نهائية المعاملة لها طبقات مختلفة في عمليات التراكم. إذا أخذنا في الاعتبار فقط المعاملات المتراكمة دون النظر في أي آثار جانبية ، فإن أفضل دفاع للجنة الأمنية هو إيقاف القدرة على إنهاء نقاط التفتيش ، مع الاستمرار في السماح بفرز المعاملات. يتيح ذلك الوقت لإصلاح الأخطاء وإعادة تنشيط إكمال نقطة التفتيش وتجاهل المعاملات غير الصالحة ببساطة.
ومع ذلك ، إذا لم يتم إيقاف تشغيل نشاط التداول على مجموعة التحديثات ، فستكون تجربة المستخدم فوضوية وقد يبدو أن مجموعة التحديثات معطلة بشدة حتى تتم ترقية برنامج العميل.
هذا يقودنا إلى السيناريو التالي. كيف يجب أن تتصرف اللجنة إذا أخذنا في الاعتبار كيف يمكن أن تؤثر المعاملات غير الصالحة على المجموعات على الأنظمة الأخرى. أفضل خط دفاع هو تجميد قدرة الجسر الأصلي عبر السلسلة على إنهاء ترتيب المعاملات ، أو إيقاف تشغيل جهاز التسلسل تماما.
وذلك لأن بعض الأنظمة ، مثل الجسور السريعة عبر السلاسل التي تحول الأموال من مجموعة إلى أخرى ، قد تسمح بتحويل الأموال بمجرد اعتقادها أن معاملات مجموعة التحديثات (بما في ذلك المعاملات غير الصالحة) قد تم فرزها. في هذا المثال ، قد يسمح للمهاجم باستغلال بروتوكول DeFi على مجموعة التحديثات ثم تحويل الأموال بسرعة عن طريق تحويلها إلى مجموعة أخرى عبر جسر سريع عبر السلسلة.
بحلول الوقت الذي تقوم فيه اللجنة بإصلاح الخرق وإعادة المعاملة غير الصالحة ، قد يكون الضرر قد حدث بالفعل. يمكن أن تتحمل LPs في كل من بروتوكولات DeFi والجسور عبر السلاسل تكلفة الهجوم.
أخيرا ، إذا سمحت الثغرة الأمنية للمهاجم بسحب الأموال مباشرة من الجسر الأصلي عبر السلسلة ، على غرار Nomad Hack ، فقد تكون لجنة الأمان عاجزة عن إيقافه.
هناك مشكلة شاملة في نهاية المطاف مع آلية التعليق. علينا أن نفترض أن هناك نظام حوكمة أوسع يمكنه الموافقة على الترقيات وإعادة تنشيط التراكمات. إذا افترضنا أن نظام الحوكمة هو DAO مع نظام تصويت على السلسلة يعمل على مجموعة التحديثات ، فستظهر مشكلات تنفيذ صعبة.
على سبيل المثال، إذا تم إيقاف جسر الرسالة عبر السلسلة L2→L1 مؤقتا، فلا يمكن تمرير نتائج تصويت DAO من مجموعة التحديثات إلى الجسر الأصلي عبر السلسلة على ETH، ويجب أن تكون هناك طريقة بديلة ل DAO لإرسال الموافقة وإجراء الترقية.
الإلغاء التدريجي لمجلس الأمن
هناك من يعتقد في المجتمع أنه يجب التخلص التدريجي من لجنة السلامة ، لكن في رأيي ، هذا يطرح مشكلتين:
شعور زائف بالأمان. ينتظر المهاجمون الذين يدركون الثغرة حتى يتم التخلص التدريجي من لجنة الأمان قبل تنفيذ الهجوم. بمرور الوقت ، يمكن أن يؤدي ذلك إلى تآكل ثقتنا في أمان أنظمتنا.
خيارات الاسترداد محدودة. بدون لجنة سلامة ، لا يمكن للمجتمع أن يقاوم المهاجمين. الخيار الوحيد المتاح هو تشغيل اختراق مواز للقبعة البيضاء ونأمل في استعادة بعض الأموال.
في رأيي ، ستكون لجان السلامة ضرورية دائما ، ولكن يجب تقليل الصلاحيات الممنوحة لها تدريجيا.
مع وضع ذلك في الاعتبار ، يجب أن يكون سؤال التصميم:
كيف يمكننا جعل لجنة السلامة تعلق النظام بأقل تأثير على المستخدمين ، مع السماح للمجتمع الأوسع بالمشاركة في تحديد كيفية إصلاح الأخطاء وإعادة تنشيط النظام؟
وبعبارة أخرى، نحن بحاجة إلى برنامج يسمح حقا للمجتمع بالتدخل واستعادة النظام، ومن ثم الحد من سلطة التعليق لمجلس الأمن.
في مساحة Layer 1 blockchain ، يمكن بالفعل الوصول إلى المجتمع مباشرة باستخدام الشوكات التي ينشطها المستخدم ، ولكن هذه الطريقة لا تعمل مع العقود الذكية على مربعات ETH (مثل Rollups) لأنه لا توجد حاجة لتقسيم ETH بالكامل. في بعض الحالات ، قد يقرر مجتمع ETH بشكل جماعي حفظ مجموعة التحديثات ، مثل TheDAO في عام 2016 ، ولكن يجب ألا تعتمد مجموعة التحديثات أبدا على مثل هذه النتيجة أو تتوقعها.
فكرة أخرى مثيرة للاهتمام على هذا المنوال هي تنفيذ ETH للمحكمة العليا لاتخاذ قرار بشأن ترقيات العقود الذكية وتمكين الشوكات المشابهة لتنشيط المستخدم.
كما ذكرنا سابقا ، إذا قام Rollup بتفويض أمانه إلى DAO ، فيجب أن يكون هناك تطبيق يسمح ل DAO بالتصويت مباشرة على ETH. هذا أمر صعب للغاية ، خاصة إذا كان بروتوكول التصويت موجودا في مجموعة التحديثات.
وأخيرا، أعتقد أن هناك حاجة إلى إجراء استعراض شامل لأنواع الحالات التي قد تتطلب استجابة من المجلس بغية تيسير المناقشة حول ضرورتها.
لماذا تقلق بشأن التراكمات إذا كان لديك multisigs؟
لقد أمضينا وقتا طويلا في فهم مسؤوليات وتصميم واحتياجات لجنة السلامة ، ولكن من المهم العودة إلى السؤال الأصلي في هذه المقالة:
هل الإظهار مجرد متعدد الخيارات؟
الإجابة لا.
للمساعدة في فهم السبب ، من الأفضل التراجع خطوة إلى الوراء وفهم ما يريد نظام blockchain فعله حقا.
بروتوكول blockchain هو أداة تسمح للمستخدمين بحساب نسخة من قاعدة البيانات وأن يكونوا واثقين من أن لديهم نفس قاعدة البيانات مثل أي شخص آخر.
مع وضع ذلك في الاعتبار ، هناك مكونان لأي نظام blockchain:
- بروتوكول بلوكتشين. يمنح الجمع بين البرامج والتشفير والأنظمة الموزعة أي شخص الثقة في سلامة قاعدة البيانات.
- نظام الحوكمة. آلية تنسيق تسمح لجميع أصحاب المصلحة بالعمل معا والاتفاق على التغييرات في بروتوكول blockchain.
الهدف من أي نظام blockchain ، بما في ذلك Rollup ، هو التأكد من أن بروتوكول blockchain يعمل دائما مع وقت تشغيل موثوق للغاية يبلغ 99.9999٪. يجب أن يكون لمشغل النظام الموثوق به تداخل ضئيل أو معدوم مع التشغيل اليومي للنظام. في النهاية ، فإن البرامج والتشفير والأنظمة الموزعة هي المسؤولة في النهاية عن حماية أرصدة المستخدمين ورمز العقد الذكي والحالة.
في بعض الأحيان يكون من الضروري تغيير بروتوكول blockchain لتحسين مصالح المستخدمين. قد يرغب المجتمع في إصلاح مشكلات التكوين أو إضافة ميزات جديدة أو التفاعل مع الثغرات الأمنية الحرجة التي تهدد سلامة النظام. هذا يتطلب تدخلا بشريا ولا يمكن تسميته إلا بنسبة 0.0001٪ من الوقت.
أنظمة الحوكمة مسؤولة عن تنفيذ التدخل البشري ، وقد ظهرت عدة مناهج على مر السنين:
- الأحزاب السياسية الشمولية: يمكن للأحزاب الأحادية أن تقرر بشكل فردي كيفية ترقية النظام (العديد من المشاريع ، بما في ذلك BTC ، بدأت بهذه الطريقة).
- إجماع تقريبي: قال غالبية المشاركين إنهم مستعدون لنشر الترقية ، وتحديد يوم العلامة ، ثم إجراء الترقية في يوم العلامة (BTC/ETH).
- اتفاق التصويت: تشارك جميع الأحزاب في الانتخابات وتصوت صراحة على ما إذا كانت ستوافق على التصعيد.
- لا تدخل: يمكن أن تكون العقود الذكية غير قابلة للتغيير ، ولا يمكن تغيير النظام أبدا.
بالإضافة إلى ما سبق ، يمكن للمجتمع أيضا أن يقرر تعيين لجنة سلامة كخيار تكميلي للحوكمة للعمل بسرعة في حالات الطوارئ.
ومجلس الأمن لا يوقف الهجوم. هذه آلية سلبية تعمل جنبا إلى جنب مع الحوكمة عندما تتعرض أموال مستخدم بروتوكول blockchain أو موثوقية / أداء النظام للهجوم.
أخيرا
جميع المناقشات حول بروتوكولات blockchain والحوكمة واللجان الأمنية حاسمة. وجود هذه المناقشة هو ما يجعل العملات المشفرة مميزة للغاية.
هذا مثال جيد على هندسة الثقة: تخصص هندسي يركز على تحديد وقياس وتقليل / إزالة عناصر الثقة في النظام.
في العملة المشفرة ، نركز على بناء أنظمة لا تحمي المستخدمين من مشغلي الأنظمة الأقوياء فحسب ، بل تمكنهم أيضا من العمل بشكل موثوق (آمن) في ظل أكثر الظروف سوءا.
لهذا السبب من الصحي أن يكون أعضاء المجتمع متشككين في دور لجنة السلامة ، لكن عليهم مسؤولية التوصل إلى حلول أفضل أثناء حالات الطوارئ لحماية أموال المستخدمين بطريقة تفاعلية.
آمل أن توضح هذه المقالة سبب فائدة اللجان الأمنية ، فهي ضرورية اليوم ، لكنها ليست سوى جزء صغير من البنية الأوسع لأنظمة العقود الذكية.
