الانتقال إلى المحتوى
Financial Context Wiki

عقد ذكي قابل للترقية

يحافظ العقد الذكي القابل للترقية على عنوان الوكيل وحالته بينما يغيّر المخولون تنفيذه. وتضيف هذه المرونة مخاطر التخزين والتهيئة والحوكمة والمراقبة.

آخر تحديث

لأغراض تعليمية فقط؛ وليس نصيحة استثمارية أو أمنية. قد تمنح قابلية الترقية جهات مميزة سلطة تغيير سلوك العقد وقد تسبب خسائر.

الجواب المباشر

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

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

ليست كل الوكلاء قابلة للترقية؛ فقد يرحّل المشروع الحالة أو يعطل الترقية نهائياً. العبرة بالبنية والصلاحيات الفعلية على السلسلة.

آلية العمل

ينفذ الوكيل شفرة التنفيذ في سياق تخزينه بواسطة delegatecall. يوحّد ERC-1967 خانات التنفيذ وBeacon والمسؤول. يفصل الوكيل Transparent استدعاءات المسؤول، بينما يضع UUPS منطق الترقية في التنفيذ وفق ERC-1822، وقد يغيّر Beacon واحد عدة وكلاء.

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

لا يهيئ المنشئ تخزين الوكيل، لذا يستدعى initialize مرة واحدة وتُقفل التهيئة المباشرة.

العملية المنضبطة هي:

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

مثال

يستخدم وكيل بروتوكول إقراض التنفيذ A. ينشر الفريق B بعد التأكد من أنه يضيف التخزين فقط، وينشر الشفرة ويضع الترقية خلف قفل زمني مدته 48 ساعة. بعدها يستخدم العنوان نفسه B وتبقى الأرصدة في الوكيل.

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

المخاطر

  • استبدال مميز: قد يثبت المسؤول أو التوقيع المتعدد أو مفتاح مخترق منطقاً ضاراً.
  • فساد التخزين: قد يفسر التخطيط غير المتوافق الأرصدة والمالكين والخرائط خطأ.
  • فشل التهيئة: قد تنقل التهيئة الناقصة أو المتكررة السيطرة.
  • فشل خاص بالنمط: تختلف أعطال Transparent وUUPS وBeacon والأنماط المخصصة.
  • حوكمة شكلية: قد يوجد تجاوز طارئ أو تأخير قصير أو قوة تصويت مركزة.
  • ترحيل أو تراجع غير آمن: قد تتغير الحالة بلا رجعة.
  • فجوة تحقق: توثيق مصدر التنفيذ لا يثبت وجهة الوكيل أو المسؤول أو الحالة.
  • خطر المراقبة: قد تتبع الخدمات تنفيذاً قديماً أو تفوّت تغيير Beacon.

مفاهيم خاطئة

  • «العقد عند هذا العنوان ثابت». قد تكون شفرة الوكيل ثابتة ويتغير السلوك عبر خانة التنفيذ أو Beacon.
  • «التوقيع المتعدد يحقق اللامركزية». يعتمد ذلك على استقلال الموقعين والعتبة والتشغيل والاستبدال.
  • «القفل الزمني يمنع الترقية الضارة». يمنح وقتاً للمراقبة والخروج ولا يجعل الشفرة آمنة.
  • «فحص التخزين يثبت الأمان». لا يغطي المنطق والصلاحيات والأوراكل والترحيل والاقتصاد.
  • «التخلي عن الترقية يزيل السيطرة دائماً». يجب فحص المسؤول وBeacon والحوكمة وUUPS والمسارات البديلة.

موضوعات ذات صلة

المصادر

التنقل

ابحث في الويكي...