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

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

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

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

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

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

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

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

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

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

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

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

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

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

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