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

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

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

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

لماذا يعد التحقق من الكود المصدري خطوة أساسية وليست اختيارية؟

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

• يرفع الثقة لأن المستخدم يرى الكود الحقيقي لا وصفاً تسويقياً له.
• يسهّل المراجعة الأمنية من مجتمع المطورين والمدققين.
• يمكّن أدوات الواجهة من قراءة ABI مباشرة عبر المستكشف.
• يساعد المستثمرين على تحليل صلاحيات الإدارة وحدود السك والتجميد والتحويل.
• يدعم معايير الشفافية المطلوبة في مشاريع DeFi وNFT.

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

ما الذي تطابقه Etherscan فعلياً أثناء التحقق؟

عملية التحقق ليست مجرد رفع ملف .sol. المنصة تعيد إنتاج مخرجات الترجمة من جديد. لهذا السبب يجب أن تعرف مسبقاً إعدادات البناء التي استخدمتها في Hardhat أو Remix.

العناصر المؤثرة تشمل:

1. إصدار Solidity بدقة.
2. تفعيل أو تعطيل optimization.
3. عدد مرات runs.
4. تمرير معاملات constructor بشكل صحيح إذا كان العقد يستقبلها عند النشر.
5. ربط المكتبات الخارجية إذا كان هناك library linking.

هذه الفكرة ترتبط مباشرةً بما تعلمته في إعداد مشروع Hardhat وكتابة أول سكربت JavaScript لترجمة (Compile) العقد الذكي، لأن الترجمة المتسقة هي مفتاح التطابق مع البايت كود.

مثال عقد بسيط قابل للتحقق

لنأخذ مثالاً مصغراً لعقد تخزين قيمة مع حدث يسهّل التتبع. الكود التالي واضح، لكنه يوضح أيضاً لماذا يفيد التحقق المستخدمين؛ فهم يستطيعون التأكد من أن الدالة setValue وحدها تعدل الحالة، وأن القراءة تتم عبر view function.

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

contract VerifiedStorage {
    uint256 public value;
    address public owner;

    event ValueUpdated(uint256 oldValue, uint256 newValue, address indexed updatedBy);

    constructor(uint256 initialValue) {
        owner = msg.sender;
        value = initialValue;
    }

    function setValue(uint256 newValue) external {
        uint256 oldValue = value;
        value = newValue;
        emit ValueUpdated(oldValue, newValue, msg.sender);
    }

    function getValue() external view returns (uint256) {
        return value;
    }
}

إذا أردت فهماً أعمق للمكونات السابقة، فراجع أساسيات لغة Solidity: أنواع البيانات والمتغيرات (State Variables) والأحداث (Events): كيف يخبر العقد الذكي واجهة الموقع (React) بأن شيئاً ما قد حدث؟.

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

1) تجهيز معلومات النشر

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

2) فتح صفحة العقد

اذهب إلى عنوان العقد على Etherscan ثم اختر خيار Verify and Publish. بعد ذلك ستحدد إن كنت تستخدم ملفاً مفرداً أو تنسيق Standard JSON Input.

3) لصق الكود واختيار الإعدادات

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

4) إدخال معاملات المُنشئ

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

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

في المشاريع الجدية، التحقق اليدوي ليس الأفضل. الأصح هو أتمتة العملية داخل بيئة النشر نفسها. هذا يضمن أن مصدر الحقيقة هو ملفات المشروع وسكربتات النشر، لا النسخ اليدوي. إذا كنت تعمل بالفعل وفق منهجية أتمتة نشر العقود (Deployment): كتابة سكربت لرفع العقد إلى شبكة Ethereum و Polygon فخطوة التحقق يجب أن تكون جزءاً من نفس المسار.

// hardhat.config.js example snippet represented inside solidity block as requested
require("@nomicfoundation/hardhat-toolbox");
require("@nomicfoundation/hardhat-verify");

module.exports = {
  solidity: {
    version: "0.8.20",
    settings: {
      optimizer: { enabled: true, runs: 200 }
    }
  },
  etherscan: {
    apiKey: process.env.ETHERSCAN_API_KEY
  }
};

بعد النشر، يمكنك تنفيذ أمر التحقق مع عنوان العقد ومعاملات المُنشئ. الفكرة الجوهرية هنا أن إضافة plugin التحقق داخل Hardhat تقلل أخطاء البشر وتبقي سلسلة التوريد البرمجية واضحة وقابلة لإعادة الإنتاج.

أكثر أسباب فشل التحقق شيوعاً

• اختيار إصدار مترجم مختلف ولو بفارق بسيط.
• نسيان تفعيل optimizer أو إدخال عدد runs بشكل خاطئ.
• تمرير معاملات constructor بترتيب أو ترميز غير صحيح.
• وجود مكتبات خارجية لم يتم ربط عناوينها أثناء التحقق.
• محاولة التحقق من كود مختلف قليلاً عن النسخة التي نُشرت فعلاً.

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

كيف يعزز التحقق الثقة فعلياً لدى المستخدمين؟

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

كما أن الواجهات الأمامية، والمحللين، وحتى بعض المحافظ، قد تستفيد من verified ABI لعرض وظائف العقد للمستخدم بشكل أفضل. هذا يرفع قابلية الدمج مع أدوات مثل Ethers.js وواجهات القراءة والتحليل.

علاقة التحقق بتحسين السمعة التقنية للمشروع

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

إذا كنت تهدف أيضاً إلى تحسين استهلاك الغاز، فاجعل نسخة العقد التي تتحقق منها هي النسخة المحسنة فعلاً بعد مراجعة أنماط التخزين والقراءة واستخدام الدوال view وpure عند الإمكان، كما شرحنا في أنواع الدوال : فهم view و pure لتوفير رسوم الـ Gas والتكاليف (Gas Fees): كيف يحسب البلوكتشين تكلفة تنفيذ الأكواد؟.

خلاصة عملية

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

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