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

أولًا، تحقق بدقة من صلاحيات العقود الذكية، واستعد/اسحب صلاحيات المسؤول (Administrator) و«الصلاحيات الفائقة» (Super Permissions) وصلاحيات ترقية العقد. كثير من فرق التطوير عند كتابة العقود الذكية تفترض تلقائيًا الاحتفاظ بصلاحيات المسؤول. إليك مثالًا حقيقيًا: بعد إطلاق مشروع RWA، كان لدى جهة التطوير صلاحيات مدير العقد، فتمكنوا مباشرة من استدعاء دوال الخلفية لنقل أصول المستخدمين المرهونة داخل العقد، دون أن يكون لدى أصحاب المشروع أي قدرة للتدخل. بعد اكتمال نشر العقد، يجب على أصحاب المشروع أولًا التأكد من تسليم أو إتلاف كل من: صلاحيات المسؤول، وصلاحيات العمليات الفائقة، وصلاحيات وكيل ترقية العقد. لا تترك أعلى صلاحيات العقد في يد فريق التطوير؛ وبذلك تقضي من الجذر على احتمال قيامه بتعديل القواعد في الخلفية أو نقل الأصول.

ثانيًا، إحكام السيطرة على جميع محافظ المشروع، ويجب أن تكون مفاتيح الخصوصية وصلاحيات التوقيع بيدك أنت بالكامل. غالبًا ما يتضمن المشروع ثلاثة أنواع رئيسية من المحافظ: محفظة النشر، ومحفظة مجمع الأموال (الـ Pool)، ومحفظة إدارة متعدد التوقيعات (Multisig). يوجد كثير من المشاريع تتكاسل وتطلب من فريق التطوير الاحتفاظ بالمفاتيح الخاصة للمحافظ. حدث سابقًا في مشروع ألعاب على السلسلة (Chain Game): كانت محفظة الأموال يحتفظ بها فريق التطوير نيابةً عن المشروع، وبعد فترة تشغيل للمشروع، قام المطورون مباشرةً بالاحتيال وسحب عشرات آلاف الـ USDT من داخل المجمع. لم يكن بوسع الشركة رفع دعوى فعّالة أو استرداد الحقوق. مهما كان الطرف الآخر موثوقًا، لا يجوز أبدًا تسليم مفاتيح الخصوصية وصلاحيات التوقيع لمحفظة النشر ومحفظة مجمع الأموال ومحفظة متعدد التوقيعات إلى فريق التطوير. يجب تنفيذ جميع عمليات التوقيع من قبل جهة المشروع نفسها، ولا تُفوّض تطوير الفريق في إدارة مداخل الأصول.

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

ثانيًا، التحقق من كود السلسلة/الكود على الشبكة بشكل مباشر، ومقارنته بمصدر التسليم، وإشراك جهة تدقيق طرف ثالث للكشف عن المخاطر. هنا من السهل جدًا الوقوع في فخ: قد لا يكون كود المصدر الذي يسلّم لك إياه المطور هو نفس الكود الفعلي الذي يعمل على السلسلة. تسلّم بعض الفرق ملفات مصدر نظيفة، لكن النسخة المُنشرَة على السلسلة تُخفي عمدًا عناوين “خاصة سوداء” ووظائف مخفية لتحويل الأصول. لا فائدة من الاكتفاء بمراجعة كود التسليم؛ يجب مطابقة البايت كود للعقود المُنشرَة على السلسلة مع ناتج ترجمة كود المصدر. من الصعب على الجهات العادية إكمال هذه المهمة؛ يُنصح بتكليف جهة تدقيق طرف ثالث لعمل مقارنة للكود، والبحث عن الأبواب الخلفية المخفية وعناوين عالية الخطورة خاصة.

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

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

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