لماذا يحتاج غير التقنيين فهم هذا؟
إذا كنت مؤسساً أو مستثمراً أو مدير منتج أو مسؤولاً تنفيذياً يعمل في محيط مشروع بلوكتشين، تحتاج فهماً عملياً لأمان العقود الذكية.
ليس لأنك ستقرأ الكود. بل لأنك ستتخذ قرارات تؤثر على ما إذا كان الكود آمناً.
متى تُطلق؟ هل تُنفق على تدقيق ثالث؟ هل ترفع سقف TVL؟ هل ادعاء الفريق أن نتيجة تدقيق ما "منخفضة الخطورة" دقيق؟ هذه أحكام تستلزم سياقاً. هذا هو السياق.
ما هي العقود الذكية فعلاً؟
العقد الذكي برنامج منشور على بلوكتشين. بمجرد نشره، يعمل بشكل مستقل، ينفذ منطقه كلما تحققت الشروط المحددة، دون الحاجة لموافقة بشرية على كل معاملة. الكود هو القاعدة.
هذا قوي. وهنا تكمن المخاطرة. إذا كان في الكود خلل، فالخلل يُنفَّذ تلقائياً أيضاً. لا بنك تتصل به، لا عملية تسوية نزاعات، وفي معظم الحالات لا طريقة للتراجع عن المعاملة بمجرد معالجتها.
تاريخ استغلال العقود الذكية إلى حد بعيد هو تاريخ مطورين كتبوا كوداً يفعل بالضبط ما يقوله، لكن ليس ما أرادوه.
هجوم إعادة الدخول
هذا الاستغلال الأصلي، الذي اشتهر بسبب اختراق DAO عام 2016 الذي أسفر عن سرقة 60 مليون دولار وأفضى في نهاية المطاف إلى انقسام إيثيريوم.
المفهوم: عقد ذكي يُرسل ETH إلى عنوان خارجي. قبل انتهاء العقد من تحديث سجلاته الداخلية، يستدعي ذلك العنوان الخارجي العقد مجدداً ويُطلق سحباً آخر. العقد لم يسجّل السحب الأول بعد، فيسمح بالثاني. يتكرر هذا حتى يُستنزف العقد.
لماذا لا يزال يحدث: اللغات والأطر الحديثة لها حماية مدمجة، لكن المطورين لا يزالون يُدخلون ثغرات إعادة الدخول من خلال أنماط استدعاء وظائف معقدة. في عام 2022، كانت إعادة الدخول لا تزال مسؤولة عن مئات الملايين من الخسائر.
ما تبحث عنه: هل التدقيق يختبر إعادة الدخول تحديداً؟ هل نمط "الفحوصات-التأثيرات-التفاعلات" مُتّبَع؟ هل توجد حراسات ضد إعادة الدخول في الوظائف الحيوية؟
الفيضان العددي والتدفق السفلي
تخزّن العقود الذكية، كجميع البرامج، الأرقام في حاويات ذات حجم ثابت. إذا تجاوز رقم الحجم الأقصى، يلتف حول الصفر. رقم يتجاوز الأقصى بقليل يصبح صفراً أو رقماً صغيراً جداً.
عملياً: عقد يتتبع أرصدة المستخدمين يمكن التلاعب به بحيث يصبح رصيد ينبغي أن يكون صفراً فلكياً الحجم. أو عقد يحسب الرسوم يمكن التلاعب به بحيث تُنتج عملية طرح نتيجة لا معنى لها مالياً.
إصدارات Solidity الحديثة (0.8.0 وما فوق) تشمل حماية مدمجة من الفيضان، لكن العقود القديمة والعقود التي تستخدم كود التجميع قد تكون لا تزال عرضة للخطر.
ما تبحث عنه: ما إصدار Solidity الذي يستخدمه العقد؟ هل التدقيق يغطي العمليات الحسابية تحديداً؟ هل توجد فحوصات حدودية على المدخلات التي يتحكم بها المستخدم في الوظائف الحسابية؟
إخفاقات التحكم في الوصول
الفئة الأكثر قابلية للتجنب. بعض الوظائف في العقد الذكي ينبغي أن تستدعيها فقط العناوين المفوّضة: وظائف الإدارة، وظائف الإيقاف الطارئ، آليات الترقية. إذا كانت ضوابط الوصول هذه مفقودة أو مُعطَّلة، يستطيع أي شخص استدعاؤها.
استغلال Poly Network عام 2021 بـ611 مليون دولار تضمن إخفاقاً في التحكم بالوصول سمح للمهاجم باستدعاء وظيفة مميزة وتعديل قائمة العناوين المفوّضة. بمجرد سيطرته على التفويض، تمكّن من تحريك الأموال بحرية.
ما تبحث عنه: ما الوظائف المقيدة على المدير/المالك؟ هل ضوابط الوصول القائمة على الأدوار موثّقة ومُدقَّق عليها؟ ماذا يحدث إذا تعرّض مفتاح المالك للاختراق؟
التلاعب بالأوراكل
ليست ثغرة كود تماماً، بل ثغرة تصميم نظام. كثير من العقود تعتمد على تدفقات أسعار خارجية لاتخاذ قرارات: هل تُصفّي موقفاً، كم من الرموز تُصدر، ما نسبة الضمانات. إذا كان بالإمكان التلاعب بهذه التدفقات، فيمكن استغلال منطق العقد حتى لو كان الكود تقنياً صحيحاً.
هجمات القروض السريعة هي آلية التوصيل النموذجية. يقترض مهاجم مبلغاً ضخماً من رأس المال لمعاملة واحدة، يستخدمه لتشويه سعر على DEX يُستخدم كأوراكل سعر، يستغل العقد الذي يعتمد على ذلك السعر المشوّه، ثم يُسدّد القرض السريع، كل ذلك في معاملة واحدة. لا يُشترط رأس مال مبدئي.
ما تبحث عنه: ما الأوراكل التي يستخدمها العقد؟ شبكات الأوراكل اللامركزية أصعب بكثير في التلاعب من حسابات الأسعار على السلسلة. هل يستخدم العقد أسعاراً متوسطة مُرجَّحة بالوقت بدلاً من الأسعار الفورية؟
أخطاء المنطق
الفئة الأصعب في التقييم والتي تستلزم أكثر أنواع التدقيق تطوراً. أخطاء المنطق هي حالات يفعل فيها الكود بالضبط ما يقوله. المنطق فحسب خاطئ للسلوك المقصود.
مشكلة Compound عام 2021، حيث أفضى أوراكل مُعطَّل إلى توزيع رموز مبلغ بـ90 مليون دولار خاطئة، كانت أساساً خطأ منطقياً في كيفية تفاعل وظيفة التوزيع مع بيانات الأسعار. الكود عمل بشكل صحيح. المنطق كان خاطئاً.
ما تبحث عنه: هل المدقّقون يشملون تحليلاً اقتصادياً جانب مراجعة الكود؟ هل حُدّدت الثوابت الأساسية للبروتوكول، الخصائص التي يجب أن تكون صحيحة دائماً، واختُبرت بشكل صريح؟
ماذا يعني هذا لقراراتك؟
إذا كنت صاحب قرار غير تقني يعمل على أو يستثمر في مشروع بلوكتشين، لا تحتاج قراءة الكود. تحتاج السؤال:
- من دقّق هذا، وما كانت النتائج؟
- أي النتائج لم تُعالَج، ولماذا؟
- هل يوجد برنامج مكافآت اكتشاف الأخطاء؟ ما الحد الأقصى للمكافأة؟
- ما آلية الترقية؟ من يتحكم بها؟
- ما البيانات الخارجية التي يعتمد عليها هذا العقد؟
إجابات هذه الأسئلة تُخبرك عن الوضع الأمني لمشروع أكثر مما سيفعله الكود نفسه. اطرحها قبل الإطلاق، قبل الاستثمار، وقبل زيادة التعرض لأي بروتوكول في محفظتك.