دليل خطوة بخطوة لتدقيق العقد الذكي لمشروع العملات المشفرة

تُعدّ مراجعة العقود الذكية محاولةً مُنظّمةً لاكتشاف كيفية فشل العقد، أو إساءة استخدامه، أو التحكم فيه بطريقةٍ غير متوقعةٍ من قِبل المستخدمين. وهي تختلف عن تشغيل ماسح ضوئي واحد، أو قراءة شارة مراجعة، أو التأكد من صحة شفرة المصدر. استخدم سير العمل الموضح أدناه لمراجعة عقد EVM المنشور أو قاعدة الشفرة قبل استثمار أموالٍ كبيرةٍ فيه.

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

قائمة تدقيق سريعة

الخطوة 1: تأكيد النطاق والعنصر المنشور

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

تحقق مما إذا كان المصدر المُوثَّق للمستكشف يُعيد إنتاج رمز البايت المُنشَر. يُعد التحقق مفيدًا لأنه يسمح لك بفحص المصدر وواجهة التطبيق الثنائية (ABI)، ولكنه مجرد فحص للهوية: فهو لا يُثبت سلامة منطق العمل. إذا كان العقد قابلاً للتحديث، فحدد كلاً من الوكيل وتنفيذه الحالي. اقرأ عنوان التنفيذ من آلية الوكيل الموثقة أو معلومات المستكشف، ثم تأكد من أن التنفيذ هو الذي تنوي مراجعته. يُوثِّق دليل التحقق الرسمي من Foundry الخاص بـ Etherscan عملية التحقق للعقود الجديدة والحالية.

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

الخطوة الثانية: بناء نقطة دخول وخريطة أصول

أدرج جميع الدوال العامة والخارجية، بما في ذلك الدوال الموروثة ودوال الاستجابة أو دوال الاستقبال. لكل دالة، سجّل ما إذا كانت تستطيع:

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

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

الخطوة 3: التجميع السليم وتشغيل التحليل الثابت

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

بالنسبة لمشاريع Hardhat أو Foundry أو ما شابهها، شغّل برنامج Slither من جذر المشروع. يصفه دليله الرسمي بأنه محلل ثابت للغة Solidity وVyper، ويقدم الأمر الشائع لاستخدامه:

slither .

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

الخطوة الرابعة: تتبع المكالمات الخارجية وإعادة الدخول يدويًا

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

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

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

الخطوة 5: اختبار الثوابت الحسابية والتجارية

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

تكتشف Solidity 0.8 والإصدارات الأحدث عادةً حالات تجاوز السعة الحسابية ونقصها، لكن الكود داخل uncheckedكتلة برمجية يُغيّر هذا السلوك عمدًا. كما يمكن أن يؤدي التحقق من العمليات الحسابية إلى تعطل البروتوكول أو جعله غير قابل للاستخدام إذا لم تُصمّم الحدود بشكل صحيح. اختبر كلا الاحتمالين: السرقة أو المحاسبة غير الصحيحة، وحرمان المستخدم من الخدمة بسبب قيمة لا يمكن معالجتها أبدًا.

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

الخطوة 6: مراجعة الأذونات وإمكانية الترقية

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

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

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

الخطوة 7: اختبار النظام باستخدام تقنيات الفحص العشوائي، والثوابت، والتفرعات

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

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

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

الخطوة 8: كتابة النتائج التي يمكن إصلاحها وإعادة اختبارها

استخدم سجلاً واحداً لكل مشكلة. يجب أن تتضمن النتائج العملية ما يلي:

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

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

أخطاء شائعة في التدقيق يجب تجنبها

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

إجراء فحص ذاتي نهائي قبل الوثوق بالنتيجة

ينبغي أن تكون قادراً على الإجابة بنعم على هذه الأسئلة:

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

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