مناقشة حول أمان بروتوكول عبر السلاسل: أهمية اللامركزية وعدم الحاجة إلى الثقة

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

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

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

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

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

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

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

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

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

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

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