تحديات بروتوكول عبر السلاسل وقيود LayerZero

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

بين العديد من حلول عبر السلاسل، اعتمد LayerZero تصميمًا معماريًا مبسطًا. يستخدم Relayer لتنفيذ الاتصالات بين السلاسل، ويشرف عليه Oracle. هذه التصميم يتجنب العملية المعقدة التي تحتاجها الحلول التقليدية عبر السلاسل، والتي تتطلب وجود سلسلة ثالثة لإتمام الإجماع والتحقق من عدة عقد، مما يوفر للمستخدمين تجربة "عبر السلاسل السريعة". نظرًا لكون الهيكل خفيفًا، والكود بسيطًا، وقابلًا للاستفادة من Chainlink الموجود كـ Oracle، يمكن لمشاريع من نوع LayerZero أن تنطلق بسرعة، لكنها في نفس الوقت سهلة التقليد.

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

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

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

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

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

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

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

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