التحقق من الكود المصدري: كيف تنشر كود عقدك علناً على Etherscan ليكسب ثقة المستخدمين؟

التحقق من الكود المصدري: كيف تنشر كود عقدك علناً على Etherscan ليكسب ثقة المستخدمين؟

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

عندما يكون العقد Verified يستطيع أي مستخدم أو مدقق أو مستثمر قراءة الشيفرة، استعراض الدوال العامة، تنفيذ أوامر Read Contract وWrite Contract بسهولة، ومقارنة سلوك العقد مع وعود المشروع. هذه الشفافية عنصر أساسي في بناء الثقة والامتثال غير المباشر لمعايير الجودة العالية في المحتوى والمنتج الرقمي.

إذا كنت قد بدأت رحلتك من مدخل إلى Web3: ما هو البلوكتشين ولماذا يغير شكل الإنترنت والأنظمة المالية؟ ثم انتقلت إلى محرر Remix IDE: كتابة ونشر أول عقد ذكي (Smart Contract) على المتصفح مباشرة أو إلى الانتقال إلى بيئة العمل الاحترافية: تثبيت إطار عمل Hardhat باستخدام Node.js، فإن خطوة التحقق هي الجسر الفاصل بين “عقد منشور” و“عقد موثوق وقابل للتدقيق”.

ما معنى التحقق من الكود المصدري تقنياً؟

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

إذا تطابق الناتجان، تعتبر المنصة أن الشيفرة المرفوعة هي المصدر الحقيقي للعقد المنشور. لذلك فإن أي اختلاف في إصدار Solidity Compiler أو إعدادات Optimization أو عدد مرات تشغيل المحسن Runs قد يؤدي إلى فشل التحقق حتى لو كان الكود “شبه مطابق”.

لماذا يؤثر التحقق مباشرة في ثقة المستخدمين؟

1. يزيل الغموض عن منطق العقد

العقد غير الموثق يبدو للمستخدم كصندوق أسود. أما العقد الموثق فيسمح بفهم المتغيرات، الأذونات، الأحداث، ودوال السحب والإدارة. وهذا مهم خصوصاً في عقود ERC-20 وNFT حيث يبحث المستخدم عن صلاحيات مثل mint وpause وowner.

2. يسهل التدقيق المجتمعي

حتى قبل إجراء Security Audit احترافي، يستطيع المطورون المستقلون اكتشاف أنماط خطرة أو صلاحيات مبالغاً فيها. وهذا ينسجم مع مفاهيم الأمان التي تناولناها في أمن العقود الذكية (1): ثغرة إعادة الدخول (Reentrancy Attack) الشهيرة وكيفية استغلالها.

3. يحسن تجربة التكامل مع الواجهات

عند التحقق، تصبح واجهة العقد وقابليته للاستدعاء أوضح للمطورين الذين يستخدمون Ethers.js أو ABI لربط الواجهة بالعقد، كما شرحنا في هندسة الويب اللامركزي (Web3.js & Ethers.js): كيف نربط الواجهات بالعقود الذكية؟.

ما الذي تحتاجه قبل بدء التحقق؟

• عنوان العقد المنشور على الشبكة الصحيحة.
• ملفات المصدر كاملة، بما فيها أي استيراد من OpenZeppelin أو مكتبات أخرى.
• إصدار المترجم نفسه مثل 0.8.20.
• حالة المحسن Optimization Enabled/Disabled وعدد Runs.
• وسائط Constructor Arguments إن وُجدت.
• إن كنت تعمل باحترافية عبر Hardhat، فاحرص على أن تكون عملية النشر موثقة جيداً كما في أتمتة نشر العقود (Deployment): كتابة سكربت لرفع العقد إلى شبكة Ethereum و Polygon.

مثال عقد جاهز للتحقق

في المثال التالي سنستخدم عقداً بسيطاً يحتوي على متغير حالة، دالة قراءة، ودالة تحديث محمية بالمالك. ستلاحظ أن البنية واضحة ومناسبة للمراجعة البشرية، وهي ممارسة ممتازة قبل النشر العام. إذا أردت مراجعة الأنماط الأساسية أولاً، يمكنك الرجوع إلى أساسيات لغة Solidity: أنواع البيانات والمتغيرات (State Variables) والدوال (Functions) في Solidity: من يمكنه قراءة وتعديل بيانات العقد؟.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract VerifiedStorage {
    address public owner;
    string private message;

    event MessageUpdated(string newMessage, address indexed updatedBy);

    constructor(string memory initialMessage) {
        owner = msg.sender;
        message = initialMessage;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Not owner");
        _;
    }

    function setMessage(string calldata newMessage) external onlyOwner {
        message = newMessage;
        emit MessageUpdated(newMessage, msg.sender);
    }

    function getMessage() external view returns (string memory) {
        return message;
    }
}

التحقق يدوياً عبر Etherscan

1. افتح صفحة العقد على Etherscan.
2. ادخل إلى خيار Verify and Publish.
3. اختر نوع الملف أو نمط الإدخال، وغالباً Solidity (Single file) أو Standard JSON Input.
4. حدد إصدار المترجم المطابق تماماً لمرحلة النشر.
5. أدخل حالة Optimization وعدد Runs.
6. الصق الكود كاملاً أو ارفع الإدخال القياسي.
7. أضف بيانات Constructor المشفرة إذا كانت مطلوبة.
8. أرسل الطلب وانتظر نتيجة المطابقة.

التحقق الاحترافي باستخدام Hardhat

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

// hardhat.config.js and command example are referenced from deployment workflow
// Verification usually runs with:
// npx hardhat verify --network sepolia CONTRACT_ADDRESS "Hello Web3"

بعد تثبيت إضافة التحقق المناسبة وتهيئة API Key الخاص بـ Etherscan، يمكنك تشغيل أمر التحقق مع عنوان العقد وقيم constructor. ميزة هذا الأسلوب أنه يعيد استخدام إعدادات المشروع نفسها بدلاً من إدخالها يدوياً في كل مرة.

تحقق دائماً من أن إعدادات optimizer وإصدار compiler لم تتغير بين بيئة الاختبار وبيئة النشر. أي تغيير بسيط قد ينتج bytecode مختلفاً ويؤدي إلى فشل التحقق، كما قد يغيّر كفاءة التنفيذ واستهلاك Gas.

أشهر أسباب فشل التحقق

• اختيار إصدار مترجم غير مطابق.
• نسيان تفعيل أو تعطيل optimizer بالشكل الصحيح.
• تمرير constructor arguments بشكل خاطئ.
• وجود مكتبات مرتبطة Linked Libraries بعناوين غير مضبوطة.
• التحقق من عقد وكيل Proxy باعتباره عقد التنفيذ Implementation أو العكس، وهي نقطة مهمة إذا كنت تعمل بعقود قابلة للترقية كما في ترقية العقود الذكية (Upgradeable Contracts): كيف تحدث الكود بعد نشره على البلوكتشين؟.

التحقق ليس بديلاً عن الأمان

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

العقد الموثق يجب أن يمر أيضاً بمراجعات أمان، واختبارات وحدة، واختبارات سيناريوهات فشل. راجع منهجية اختبار العقود الذكية محلياً: كتابة اختبارات الوحدة (Unit Tests) باستخدام Chai & Mocha، ولا تهمل ضوابط الوصول مثل المعدلات (Modifiers): حماية الدوال برمجياً.

أفضل الممارسات بعد اكتمال التحقق

• أضف وصفاً واضحاً للعقد والمشروع داخل مستودع GitHub.
• انشر عنوان العقد الموثق الرسمي في موقع المشروع وقنواته.
• شارك ABI النهائي للمطورين الذين سيبنون الواجهة أو التكاملات.
• اربط صفحة Etherscan بالوثائق التقنية حتى يتمكن المستخدم من المراجعة الذاتية.

خاتمة

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

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