مخاطر الأمان في بروتوكول عبر السلاسل وأهمية اللامركزية

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

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

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

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

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

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

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

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

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

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

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