في عالم التمويل اللامركزي، كثيرًا ما يُقدَّم مصطلح “مُدقَّق” وكأنه حكم نهائي على المشروع بأكمله. لكن في الحقيقة، التدقيق عادةً يغطي كودًا ومكونات وإصدارات محددة في وقت معين فقط. أي شيء يُضاف أو يُستثنى أو يُدار خارج هذا النطاق قد يحمل مستوى مختلفًا من الضمان.
دراسة جديدة وضعت رقمًا لهذه الفجوة. باحثون من شركة الأمن ack3 وجامعة التشيك التقنية في براغ فحصوا 135 حادثة تم الإبلاغ عنها في النصف الأول من 2026، بخسائر بلغت 939.86 مليون دولار. وجدوا تدقيقات عامة معروفة قبل الحوادث في 68 حادثة فقط.
من بين هذه الـ 68 حادثة، صنّف الباحثون 46 مسار هجوم على أنها خارج كل نطاق تدقيق استطاعوا تحديده، و20 داخل نطاق واحد على الأقل، واثنتين لم تُحلا. مجموعة “خارج النطاق” مثّلت 67.6% من الحوادث لكن 94.4% من الخسائر المُبلَّغ عنها.
هذه النسبة المذهلة ليست تقديرًا لفعالية التدقيق ولا دليلًا على أن حدود التدقيق تسببت في الخسارة. إنها تصف توزيع الخسائر في مجموعة مختارة من الحوادث المُبلَّغ عنها. حالتان كبيرتان تهيمنان أيضًا على النتيجة: بعد استبعاد 292 مليون دولار في Kelp DAO و285 مليون دولار في Drift Protocol، تنخفض حصة “خارج النطاق” إلى 72.1% من الخسائر في نفس المجموعة.
حتى مع هذه القيود، تكشف الدراسة مشكلة ضمان أساسية. قد يقول مشروع بصدق أنه خضع للتدقيق، بينما يبقى المستخدمون غير قادرين على معرفة ما إذا كان النظام الفعلي والمسار الذي يحتفظ بأموالهم والضوابط المحيطة به قد تمت مراجعتها.
ماذا تُظهر البيانات فعليًا
تغطي بيانات ack3 حوادث من 1 يناير حتى 29 يونيو. صنّف المؤلفون 122 حادثة كمؤكدة و13 كمحتملة. من المجموعة الكاملة، 35 لم يكن لها تدقيق محدد و32 كان تاريخ تدقيقها غير معروف، لذا لا تظهر أي من المجموعتين في حساب نطاق الـ 68 حادثة.
لمجموعة الـ 68 حادثة، مثّلت الحوادث خارج النطاق 680.97 مليون دولار من 721.24 مليون دولار من الخسائر المُبلَّغ عنها، مما أنتج رقم 94.4%. إزالة Kelp DAO وDrift Protocol تركت 103.97 مليون دولار من 144.24 مليون دولار خارج النطاق، أو 72.1%. السجل القابل للقراءة آليًا يعيد إنتاج أعداد الفئات ومجاميع الخسائر.
تصنيفات “داخل أو خارج” تبقى أحكام الباحثين على الأدلة العامة. بحثوا في أرشيفات المشاريع والمدققين، وحددوا تقارير ما قبل الحادثة، وقارنوا مسارات الهجوم النهائية بالكود والإصدارات والاستثناءات المراجعة. العمل عبارة عن دراسة أولية من ست صفحات أُنتجت مع ناشر البيانات، ومؤلفان مرتبطان بـ ack3 التي تبيع مراجعات أمنية.
تفتقر الدراسة أيضًا إلى مجموعة مقارنة غير مستغلة وقياس لمدة تعرض كل نظام. لا يمكنها إثبات ما إذا كانت البروتوكولات المدققة أكثر أمانًا بشكل عام، أو تقدير احتمالية الحوادث، أو إظهار أن الوقوع خارج النطاق تسبب في كل خسارة. التدقيقات غير المُعلنة والحوادث الخاصة قد تكون مفقودة، بينما أرقام الخسائر المُبلَّغ عنها ليست قابلة للمقارنة تمامًا.
لذلك تدعم الدراسة استنتاجًا محدودًا: تاريخ التدقيق ونطاق التدقيق متغيران مختلفان. العقد الذكي المراجع لا يمنح تلقائيًا نفس الضمان لترقية أو مفتاح مميز أو واجهة أمامية أو مُرحّل أو أوراكل أو خدمة سحابية أو عملية الاستجابة للحوادث.
حادثتان من أغسطس توضحان هذا التمييز بطرق مختلفة. شبكة ICON تقدم مثالًا مباشرًا على فشل كود مراجع عند الحدود بين فحصين. حادثة aelf في أغسطس تقدم حالة متباينة لأن الأدلة التدقيقية المتاحة لا يمكن ربطها بعد بمسار التشغيل المُبلَّغ عنه.
في هجوم إعادة التشغيل على شبكة ICON في 27 أغسطس، فسّر جزءان من مسار السحب نفس الرسالة بشكل مختلف.
وفقًا لتقرير مؤسسة ICON في 30 أغسطس، استخدم عقد الترحيل البتات العليا من الرقم التسلسلي لرسالة السحب لتحديد ما إذا كانت فريدة. التوقيع التشفيري غطى فقط الـ 256 بتة المنخفضة. بتغيير البتات العليا غير الموقعة، أعاد المهاجم إرسال رسالتي سحب موقعة بشكل شرعي 1,492 مرة خلال حوالي 20 دقيقة. قالت ICON إن 1,490 استدعاء نجح.
الحدود التدقيقية التي فاتت ICON
أطلقت عمليات إعادة التشغيل 119.866 مليون ICX و531,600 bnUSD. في وقت التقرير، قدرت ICON صافي الخسارة المؤكدة بحوالي 150.2 ETH بالإضافة إلى 31,204 USDC. وقالت إن 531,600 bnUSD و1.366 مليون SODA تم استردادها وأن ودائع المستخدمين وأرصدتهم ومراكزهم لم تتأثر.
قالت ICON إن عقد الترحيل خضع لتدقيق خارجي وأن التوصيات نُفذت، بما في ذلك تغييرات في نفس المنطقة. كما قالت إن منطق الترحيل ذي الصلة تلقى مراجعة مخصصة. يسرد أرشيف تدقيق SODAX ثمانية تقارير عبر مكونات مختلفة، بما في ذلك تدقيق ترحيل في نوفمبر 2025.
ومع ذلك، قال التقرير إن عدم التطابق الدقيق بين فحص التفرد والقيمة الموقعة وقع خارج تلك النتائج. شارة على مستوى المشروع لم تستطع إخبار المستخدم ما إذا كان طرفا مسار السحب متفقين على ما يجعل الرسالة فريدة.
الجدول الزمني للاستجابة يضيف نوعًا ثانيًا من الحدود. أول تنبيه تلقائي لـ ICON انطلق في 02:08 UTC، حوالي سبع دقائق بعد بدء الاستغلال. فتح الموظفون تحقيقًا حوالي 03:40، وأوقفوا العقد المتأثر في 03:53 وأوقفوا الشبكة في 06:18:54.
عزت ICON الفجوة التي تبلغ حوالي 90 دقيقة بين أول تنبيه واستجابة حادثة كاملة إلى ضبط التنبيهات. فئة التنبيه أنتجت إنذارات كاذبة خلال حوادث اتصال غير ذات صلة ولم تستدعِ الفريق المناوب بالخطورة المطلوبة. قالت المؤسسة إنها تخطط لمشغل إيقاف تلقائي وعتبات قاطع دائرة أقل ومراجعة متابعة تركز على تفرد الرسائل وحواجز إعادة التشغيل.
هذه الضوابط لا تحل محل التدقيق. إنها تقدم أدلة لسؤال مختلف: عندما يفشل المنع، ما مدى سرعة تحول الاكتشاف إلى احتواء؟
aelf تُظهر لماذا يجب أن يبقى الضمان محدثًا
حادثة aelf في أغسطس تختبر الحجة من اتجاه آخر. سجلها العام يصف اختراقًا في وقت التشغيل واستردادًا مُتحكمًا به، لكنه لا يقدم أدلة كافية لوضع المسار داخل أو خارج تدقيق محدد قبل الحادثة.
أعلنت الشركة إيقاف الشبكة في 18 أغسطس. في تحديث التقدم في 26 أغسطس، قالت aelf إن عقدًا ذكيًا غير مصرح له يمكنه استخدام معاملات المعاملات لتوصيل تجميعات .NET المشفرة والتعليمات إلى مسار تنفيذ العقدة.
ربط الحساب المؤقت الحادثة بثغرات في فحوصات الانعكاس في وقت التشغيل والتحميل الديناميكي، مع عزل ضعيف بين تنفيذ العقود وموارد العقدة أو البنية التحتية الحساسة. حددت aelf 155 معاملة مرتبطة وخمس تجميعات حمولة فريدة بقدرات تشمل تنفيذ أوامر المضيف ومحاولة اتصال خارجي والوصول لمفتاح العقدة واستطلاع البنية التحتية.
القدرة ليست نفس التنفيذ المؤكد. قالت aelf إن الحمولات لم تثبت أن كل تجميع تم تشغيله، أو أن كل بيانات اعتماد مستهدفة تم الحصول عليها، أو أن بيانات حساسة غادرت أنظمتها. قالت الشركة إنها تدور مفاتيح التوقيع وبيانات اعتماد البنية التحتية وفق معيار التعرض المحتمل.
بقيت الحالة العامة مؤقتة في 11 سبتمبر: فهرس مدونة aelf لم يحتوي على أي عنصر خاص بالحادثة نُشر بعد 26 أغسطس. التزم بيان 26 أغسطس بتحديث آخر ومراجعة نهائية في النهاية.
تقول وثائق الأمن الحالية لـ aelf إن سلسلة الكتل وعقود رمز ELF خضعت لتدقيقات متعددة دون تحديد مشكلات أمنية. لكن الصفحات المتاحة لا تربط تقريرًا محددًا قبل الحادثة بمسار وقت التشغيل الموصوف في أغسطس. لذا فإن وصف الحادثة إما كفشل تدقيق أو كفشل خارج النطاق سيتجاوز الأدلة.
هذا الغموض مفيد بحد ذاته. تاريخ التدقيق المؤرخ يمكن أن ينفصل عن الكود والتبعيات وحالة التشغيل الحالية للنظام. يحتاج المستخدمون إلى سجل ضمان مُرقّم ومحدد بما يكفي لكشف هذا الانحراف.
يجب أن يسمي هذا السجل المستودع والالتزام المراجعين، وعناوين النشر، والمكونات المستثناة، والأدوار المميزة، والتبعيات. يجب أن يسجل أيضًا الترقيات منذ المراجعة، وحيازة المفاتيح وتدويرها، وعزل وقت التشغيل، وسلوك التنبيه وقاطع الدائرة، وحالة استرداد مؤرخة تفصل الخسارة المؤكدة عن التعرض المجمد أو غير المحلول.
هذا لا يقلل من قيمة التدقيق. إنه يجعل الادعاء متناسبًا مع العمل المنجز ويربط ذلك العمل بالنظام العامل الآن.
شارة التدقيق لا تستطيع الإجابة عما إذا كان العنصر المراجع والنظام المنشور والآليات التي تستجيب للفشل لا تزال تشترك في نفس الحدود الأمنية.
الأسئلة الشائعة
هل التدقيق يضمن أن المشروع آمن بالكامل؟
لا، التدقيق يغطي فقط كودًا ومكونات محددة في وقت معين. أي شيء يُضاف أو يُدار خارج هذا النطاق قد لا يكون مشمولًا بالمراجعة.
ما الذي كشفته الدراسة الجديدة عن التدقيق والخسائر؟
وجدت الدراسة أن 94.4% من الخسائر في الحوادث المدققة جاءت من مسارات هجوم خارج نطاق التدقيق، مما يظهر فجوة كبيرة بين التدقيق والضمان الفعلي.
ما الذي يحتاجه المستخدمون للتأكد من أمان المشروع؟
يحتاج المستخدمون إلى سجل ضمان محدث ومحدد يشمل الكود المنشور والترقيات والمفاتيح والضوابط التشغيلية، وليس فقط شارة تدقيق قديمة.
