أهمية أمان بروتوكول عبر السلاسل ونقص LayerZero

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

لننظر أولاً إلى تصميم معماري نموذجي لمنتج عبر السلاسل. خلال عملية الاتصال بين Chain A وChain B، يتم تنفيذ العمليات المحددة بواسطة Relayer، بينما يقوم Oracle بالإشراف على Relayer. ميزة هذا الهيكل هي أنه يتجنب العملية المعقدة التي تتطلب وجود سلسلة ثالثة (عادةً لا يتم نشر dApp) لإكمال خوارزمية الإجماع والتحقق من عدة عقد، وبالتالي يمكن أن يوفر تجربة "عبر السلاسل السريعة" للمستخدم النهائي. نظرًا لكون الهيكل خفيفًا، وكمية الشيفرة البرمجية قليلة، ويمكن استخدام Chainlink الجاهز كـ Oracle، فإن هذا النوع من المشاريع سهل الإطلاق بسرعة، ولكنه أيضًا سهل التقليد، حيث أن العتبة التقنية شبه معدومة.

ومع ذلك، توجد مشكلتان على الأقل في هذا الهيكل:

1. تم تبسيط عملية التحقق من عشرات العقد إلى تحقق Oracle واحد، مما قلل بشكل كبير من مستوى الأمان.

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

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

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

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

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

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

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

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

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

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

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