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

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

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

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

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

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

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

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

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

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

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

في المستقبل، لن يتمكن سوى أولئك الذين يمكنهم تحقيق بروتوكولات أمان لامركزية حقيقية من البروز في المنافسة الشديدة، وتوفير بنية تحتية عبر السلاسل موثوقة لبيئة Web3.