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

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

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

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

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

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

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

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

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

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

عند تقييم بروتوكولات عبر السلاسل، يجب علينا العودة إلى الأساسيات، والرجوع إلى المبادئ الأساسية التي تم تقديمها في الورقة البيضاء لبيتكوين. السمة الأساسية لتوافق ساتوشي هي القضاء على الأطراف الثالثة الموثوقة، وتحقيق اللامركزية (Trustless) واللامركزية (Decentralized). بروتوكول الاتصال عبر السلاسل يجب أن يكون في جوهره مثل بيتكوين، وهو نظام من نقطة إلى نقطة، يسمح لأحد الأطراف بإرسال مباشرة من Chain A إلى الطرف الآخر في Chain B، دون الحاجة إلى المرور عبر أي وسطاء موثوقين.

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

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

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