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

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

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

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

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

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

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

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

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

إذا كان مشروع يدعي أنه "البنية التحتية" لا يستطيع مشاركة الأمان مثل Layer 1 أو Layer 2، فلا يمكن اعتباره بنية تحتية حقيقية. تُسمى البنية التحتية "أساسية" لأنها توفر أمانًا متسقًا للنظام البيئي بأكمله. لذلك، قد يتم وصف بعض بروتوكولات عبر السلاسل بشكل أكثر دقة على أنها برامج وسيطة (Middleware) بدلاً من البنية التحتية (Infrastructure).

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

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

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

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

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