ترقية العقود الذكية (Upgradeable Contracts): كيف تحدث الكود بعد نشره على البلوكتشين؟

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

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

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

لماذا لا يمكن تعديل العقد الذكي مباشرة بعد النشر؟

عندما ترفع عقداً مكتوباً بلغة Solidity إلى شبكة متوافقة مع EVM، يتم تخزين bytecode في عنوان ثابت على السلسلة. هذا الكود لا يمكن استبداله بعملية تعديل بسيطة كما في التطبيقات المركزية.

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

الفكرة الأساسية وراء Proxy Pattern

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

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

المكونات الرئيسية

• Proxy Contract: يستقبل المعاملات من المستخدمين.
• Implementation Contract: يحتوي منطق الأعمال الفعلي.
• Storage: البيانات تبقى في العقد الوسيط لا في عقد المنطق.
• delegatecall: الآلية التي تجعل كود المنطق يُنفَّذ في سياق تخزين Proxy.

إذا لم تكن فكرة التخزين واضحة بعد، فمراجعة إدارة الذاكرة بذكاء: الفرق الحاسم بين Storage, Memory, و Calldata ستساعدك على فهم سبب حساسية الترقية بشكل كبير.

كيف يعمل delegatecall في الترقية؟

عندما يستدعي المستخدم دالة مثل increment() عبر العقد الوسيط، يقوم Proxy بتمرير الاستدعاء إلى عقد المنطق باستخدام delegatecall. هنا يتم تنفيذ الكود الخارجي، لكن الكتابة والقراءة تحدث داخل مساحة تخزين Proxy.

هذا هو السر كله: منطق قابل للاستبدال مع بيانات ثابتة. لذلك، أي تغيير في ترتيب المتغيرات داخل النسخة الجديدة قد يسبب تلفاً كارثياً في التخزين، لأن مواقع storage slots يجب أن تبقى متوافقة.

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

أشهر أنماط الترقية

1) نمط Transparent Proxy

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

2) نمط UUPS

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

3) نمط Beacon Proxy

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

مثال عملي على عقد قابل للترقية

في العقود القابلة للترقية لا نستخدم constructor بالشكل التقليدي، بل نستبدله بدالة تهيئة initialize(). السبب أن عقد المنطق لا يتم تفعيله بالطريقة المعتادة للمستخدم، بل يُستدعى عبر Proxy.

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

import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";

contract CounterV1 is Initializable, OwnableUpgradeable, UUPSUpgradeable {
    uint256 public count;

    function initialize(address initialOwner) public initializer {
        __Ownable_init(initialOwner);
        __UUPSUpgradeable_init();
        count = 0;
    }

    function increment() external {
        count += 1;
    }

    function _authorizeUpgrade(address newImplementation) internal override onlyOwner {}
}

بعد ذلك يمكن إنشاء نسخة جديدة تضيف وظيفة أخرى دون كسر التخزين القائم:

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

import "./CounterV1.sol";

contract CounterV2 is CounterV1 {
    function decrement() external {
        require(count > 0, "Count cannot go below zero");
        count -= 1;
    }
}

لفهم مفاهيم مثل require ووراثة العقود، راجع التعامل مع الأخطاء وإرجاع الأموال: استخدام require, assert, revert والوراثة (Inheritance): بناء عقود ذكية متقدمة بالاعتماد على أكواد عقود سابقة.

خطوات الترقية باستخدام Hardhat

في البيئات الاحترافية يُفضّل استخدام الانتقال إلى بيئة العمل الاحترافية: تثبيت إطار عمل Hardhat باستخدام Node.js مع إضافات الترقية الرسمية.

1. تثبيت مكتبات OpenZeppelin Upgrades.
2. نشر النسخة الأولى عبر deployProxy().
3. كتابة نسخة ثانية من العقد مع الحفاظ على ترتيب التخزين.
4. تنفيذ الترقية عبر upgradeProxy().
5. تشغيل الاختبارات قبل وبعد الترقية للتأكد من سلامة البيانات والسلوك.

// مثال نشر وترقية يتم عادة من سكربت JavaScript داخل Hardhat,
// لكن العقد نفسه يبقى كما هو في Solidity.
// الفكرة أن عنوان الـ Proxy يظل ثابتاً بينما يتغير الـ Implementation.

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

المخاطر الأمنية في العقود القابلة للترقية

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

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

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

هل الترقية تؤثر على استهلاك الغاز؟

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

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

متى تستخدم العقود القابلة للترقية ومتى تتجنبها؟

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

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

الخلاصة

العقود القابلة للترقية ليست سحراً يغير الكود المنشور مباشرة، بل هي هندسة ذكية تفصل بين العنوان العام ومنطق التنفيذ باستخدام Proxy Pattern وdelegatecall. وهي أداة قوية جداً، لكنها تتطلب انضباطاً هندسياً صارماً في التخزين، الصلاحيات، الاختبارات، والمراجعة الأمنية.

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