لماذا شارات “التدقيق” في العملات المشفرة تمنح المستثمرين إحساسًا زائفًا خطيرًا بالأمان

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

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

أفادت كريبتوسليت في ذلك الوقت أن المهاجمين استولوا على ما يقرب من 401,347 إيثريوم ETH بالإضافة إلى عدة أصول إيثريوم مُجمّعة (Staked Ethereum).

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

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

الشارة أصبحت ضمانًا

يظهر مصطلح “مدقَّق” (Audited) على مواقع البروتوكولات كشارة، عادةً بجانب شعار شركة الأمان ورابط لملف PDF. يمكن للمستخدمين قراءة هذه الشارة كدليل مختصر على أن الأموال آمنة، والمشغلين أكفاء، والبرمجيات تم فحصها من البداية إلى النهاية. لكن العمل الذي تقوم به شركة التدقيق قد يغطي في الواقع ملفات محدودة من مستودع واحد خلال أسبوع واحد فقط.

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

يميل مدققو العقود الذكية إلى وصف مهامهم بدقة أكبر بكثير من المشاريع التي تسوق لهم. تقرير OpenZeppelin على سبيل المثال يحدد أربعة طلبات سحب (Pull Requests) بواسطة بصمة الالتزام (Commit Hash)، ويسمي العقود المشمولة ويسجل فترة مراجعة مدتها ثلاثة أيام. بصمة الالتزام هي في الأساس بصمة إصبع لقطة واحدة من الكود؛ وبمجرد أن يتغير الكود، لا ينتقل التقرير تلقائيًا معه.

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

يبدأ التشويه عندما يصل تقرير محدود بعناية إلى موقع المشروع ويصبح ادعاءً عامًا حول المؤسسة التي تشغل الكود.

ورقة بحثية أولية (Preprint) صادرة في يونيو عن ستيفان باير من شركة Oak Security تعطي هذا الفجوة أرقامًا ضخمة جدًا. فحص باير 23,818 نتيجة تدقيق عامة من 22 شركة أمان، ثم قارنها بـ 218 حادثة موثقة في موقع rekt.news بين 1 يناير 2022 و27 مارس 2026. أنتجت هذه الحوادث خسائر تقدر بنحو 7.764 مليار دولار.

نتائج التدقيق تبدو تمامًا مثل مخرجات أشخاص وظفوا لفحص الكود. شكلت عيوب المنطق وعيوب منطق الأعمال 14.6% من الإجمالي، ومشاكل جودة الكود 13%. ثغرات التحقق من المدخلات ساهمت بنسبة 10%، وقضايا التحكم في الوصول جاءت خلفها مباشرة بنسبة 9.8%. حوالي واحد من كل ستة نتائج تم تصنيفه كحرج أو عالي، مما يعطي مجموعة البيانات 1,439 مشكلة حرجة و2,659 مشكلة عالية الخطورة.

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

ماذا تجد عمليات التدقيق، وأين تذهب الأموال

الترتيبات تصف مجموعات سكانية مختلفة وليست متكافئة عنصرًا بعنصر. جانب التدقيق يحصي 23,818 نتيجة؛ وجانب الخسائر يغطي 7.764 مليار دولار مسروقة عبر 218 حادثة من يناير 2022 حتى مارس 2026.

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

إضافة هجمات التبعيات (Dependencies) وهجمات الحوكمة (Governance) ترفع فئة “الناقل البشري” في الورقة إلى 49.6% من الخسائر. هذه الإخفاقات تبدأ في الأشخاص والعمليات والأنظمة الطرفية التي لم يتم توظيف مراجعة الكود المعتادة لفحصها.

رقم 49.6% يحتاج إلى تحذير خاص به. قدمت بايبيت 1.43 مليار دولار من إجمالي 1.51 مليار دولار من خسائر التصيد، و18.4% من كل دولار في مجموعة بيانات الحوادث. أثمرت ثماني حوادث عن نصف جميع الخسائر، تاركة الـ 210 حوادث الأخرى لتتقاسم الباقي.

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

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

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

المهاجمون يدققون في المؤسسة

العقد الذكي هو غرفة واحدة في منزل ضخم. يصل إليه المستخدمون عبر موقع إلكتروني ومحفظة، وقد يعتمد العقد على بيانات أسعار خارجية قبل أن يتمكن من العمل. إجراءات المحافظ المتعددة التوقيع (Multisig) تحكم التحويلات الحساسة؛ وصلاحيات المدير تحدد من يمكنه تعديل البرمجيات.

يجرب المستخدمون هذا الهيكل بأكمله كمنتج واحد. لكن المهاجمين يرون مجموعة من الأبواب، كل باب يحرسه أشخاص مختلفون وبرمجيات مختلفة.

المكونات على السلسلة (Onchain) الخاصة ببايبيت نفذت معاملة موقعة بشكل صحيح. بدأ الفشل على جهاز مطور شكل الاقتراح، ثم مر عبر واجهة أخبرت الموقعين أنهم يوافقون على شيء روتيني. أعادت Safe بناء بنيتها التحتية، ودوّرت بيانات الاعتماد، والتزمت بجعل المعاملات أسهل في التحقق. كانت تلك إصلاحات تشغيلية وإصلاحات للواجهة لحدث نفذه كود سلسلة صالح بأمانة.

وجدت الورقة الأولية أن 105 من أصل 218 حادثة تنطوي على بروتوكول لديه على الأقل تدقيق عام واحد قبل الحدث. مثلت هذه الحوادث حوالي 4.3 مليار دولار، أو 55% من الخسائر المرصودة، وهو إحصاء مصمم عمليًا لإساءة استخدامه.

هذا لا يثبت أن المدققين فاتتهم 4.3 مليار دولار من الكود القابل للاستغلال. “تم تدقيقه سابقًا” يمكن أن يصف نسخة أخرى، أو مجموعة عقود أخرى، أو مراجعة غير مرتبطة بالطريق النهائي إلى النظام.

تسع من أصل 12 من أكبر الحالات في تلك المجموعة جاءت عبر التصيد أو المفاتيح المسروقة أو التبعيات أو البنية التحتية أو الحوكمة. الحالات المدفوعة بالكود تقاوم أيضًا الحكم السهل. بالنسبة لـ Nomad و Euler وغيرها، وجدت الورقة كودًا لاحقًا أو مسارات مستبعدة أو اختلافات أخرى بين المواد المراجعة والبرمجيات التي احتفظت بالأموال في النهاية. اعتبار كل هذا فشل تدقيق سيكون نفس خطأ النطاق الذي تحاول الورقة كشفه.

البحث يحتاج أيضًا إلى تفسير متشكك لأنه ورقة أولية كتبها شخص من داخل صناعة التدقيق. الشركات الـ 22 غير مسماة، مما يمنع عمليات التحقق على مستوى الشركات، ومجموعة الحوادث تأتي من أرشيف ناشر واحد. استخراج PDF يجعل الأمور أكثر غموضًا، وجزء من التصنيف تم باستخدام نموذج لغوي كبير (LLM) تحت إشراف بشري.

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

أقوى ادعاء في الورقة يتعلق باللغة. أصبح عالم الكريبتو جيدًا في طلب نوع واحد من الفحص وسيئًا في إخبار المستخدمين أين ينتهي هذا الفحص. يمكن لشركة تدقيق مراجعة العقود بكفاءة، ويمكن لمزود الحفظ تأمين المفاتيح تمامًا كما وعد. يمكن لمزودي الخدمات السحابية وشركات المراقبة ومنصات المكافآت الأمنية (Bug Bounty) جميعًا تسليم أجزائهم المخصصة بينما يظل المسار الكامل من جهاز المطور إلى شاشة الموقع وأخيرًا إلى الكود المنشور غير مختبَر.

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

الشروط الدقيقة تدرك أن التطبيق يمتلك النظام المدمج، حتى عندما تتعامل لغة التدقيق العامة مع الأمان كشهادة ملحقة بمستودع.

استبدل شارة “مدقَّق” بملصق معلومات

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

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

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

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

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

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

الأسئلة الشائعة

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

س: كيف حدثت سرقة بايبيت البالغة 1.46 مليار دولار؟
ج: المهاجمون اخترقوا جهاز مطور وتم التلاعب بواجهة التوقيع بحيث رأى الموقعون عنوانًا صحيحًا بينما كانت المعاملة الفعلية تعطي المهاجم السيطرة على المحفظة. التوقيعات كانت صالحة تمامًا، لكن الموقعين خدعوا بشأن ما وافقوا عليه فعليًا.

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