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

ما هي قابلية ترقية العقود الذكية؟

قابلية ترقية العقود الذكية هي القدرة على تغيير منطق نظام عقود ذكية منشور أو استبداله أو توسيعه أو إعادة توجيهه بعد نشره الأول.

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

توضح وثائق Ethereum الرسمية حول ترقية العقود الذكية أن العقود الذكية تُعامل غالبًا على أنها غير قابلة للتغيير، لكن يمكن للمطورين استخدام أنماط الترقية عندما تكون التغييرات المستقبلية مطلوبة.

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

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

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

عند تغير الـ Implementation، يمكن أن يظل عنوان الـ Proxy كما هو بينما يتغير الرمز البرمجي الموجود خلفه.

يفيد ذلك المستخدمين لأن الأرصدة والأذونات وعمليات التكامل قد تستمر في الإشارة إلى العنوان نفسه.

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

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

أهمية قابلية ترقية العقود الذكية

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

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

تمنح قابلية الترقية المطورين وسيلة لتصحيح المشكلات الحرجة وتحسين البروتوكول بعد النشر.

يوضح دليل OpenZeppelin لترقية العقود الذكية أن عمليات النشر القابلة للترقية يمكنها تعديل رمز العقد مع الحفاظ على العنوان والحالة والرصيد.

ويهم هذا الحفاظ لأن المستخدمين والمحافظ وأدوات التحليلات والبروتوكولات الأخرى قد تعتمد بالفعل على عنوان العقد الأصلي.

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

وقد يكون الترحيل بطيئًا ومحفوفًا بالمخاطر ومكلفًا ومربكًا.

ومع ذلك، تغير قابلية الترقية أيضًا نموذج الثقة الخاص بالعقد الذكي.

فالعقد القابل للترقية ليس غير قابل للتغيير بالكامل بالطريقة نفسها التي يكون عليها عقد لا يملك آلية ترقية.

ينبغي للمستخدمين دائمًا السؤال عمن يستطيع ترقية العقد، وكيف تُعتمد الترقيات، ومدى سرعة تنفيذها، وما إذا كان يمكنهم الخروج قبل سريان تغيير كبير.

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

تعمل قابلية ترقية العقود الذكية عادةً عبر فصل التخزين عن المنطق.

يحتفظ عقد Proxy بالعنوان الذي يستدعيه المستخدمون، وعادةً ما يخزن الحالة الرئيسية للنظام.

ويحتوي عقد Implementation على المنطق الذي يحدد ما تفعله الوظائف.

عندما يستدعي مستخدم الـ Proxy، يمرر الـ Proxy الاستدعاء إلى عقد الـ Implementation الحالي.

في الأنظمة على نمط Ethereum، يستخدم هذا التمرير غالبًا delegatecall، الذي يشغّل منطق الـ Implementation ضمن سياق تخزين الـ Proxy.

وهذا يعني أن رمز الـ Implementation يمكنه قراءة تخزين الـ Proxy وكتابته كما لو كان هذا التخزين تابعًا للـ Implementation.

عندما يرقّي البروتوكول النظام، يغيّر حساب مخوّل أو عملية حوكمة عنوان الـ Implementation المخزن بواسطة الـ Proxy.

بعد التغيير، تتجه الاستدعاءات المستقبلية إلى منطق الـ Implementation الجديد.

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

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

عقد Proxy

عقد Proxy هو عنوان العقد المستقر الذي يتفاعل معه المستخدمون والعقود الأخرى في العديد من الأنظمة القابلة للترقية.

يخزن الـ Proxy عادةً الحالة ويمرر استدعاءات الوظائف إلى عقد Implementation.

تصف وثائق نمط ترقية Proxy من OpenZeppelin نمط الـ Proxy ذي التخزين غير المنظم بأنه لبنة أساسية للعقود القابلة للترقية.

يفيد الـ Proxy لأن المستخدمين لا يحتاجون إلى تغيير عناوين العقود في كل مرة يُرقّى فيها المنطق.

يمكن للتطبيقات والمحافظ ولوحات المعلومات وعمليات تكامل DeFi الاستمرار في استخدام عنوان الـ Proxy نفسه.

لكن نمط الـ Proxy يضيف تعقيدًا أيضًا، لأن المستخدمين قد يرون عنوان عقد واحدًا بينما يوجد المنطق الفعلي في عنوان آخر.

تعرض مستكشفات البلوكشين غالبًا معلومات الـ Proxy وعناوين الـ Implementation عندما تتمكن من اكتشاف هذا النمط.

ينبغي للمستخدمين فحص كل من الـ Proxy والـ Implementation عند مراجعة العقود القابلة للترقية.

لا يكون الـ Proxy آمنًا تلقائيًا، لأن الأمان يعتمد على ضوابط الترقية وتوافق التخزين وجودة رمز الـ Implementation.

الـ Proxy هو المدخل، بينما الـ Implementation هو المنطق الموجود خلف هذا المدخل.

عقد Implementation

عقد Implementation هو العقد الذي يحتوي على منطق الأعمال الذي يستخدمه Proxy.

قد يحدد وظائف للتحويلات والإيداعات والسحوبات والإقراض والتصويت وسك التوكنات وحرقها والإيقاف المؤقت والتصفيات أو إجراءات البروتوكول الأخرى.

لا يتفاعل المستخدمون عادةً مع عنوان الـ Implementation مباشرةً في نظام يعتمد على Proxy.

بل يتفاعلون مع الـ Proxy، ويفوض الـ Proxy التنفيذ إلى الـ Implementation.

تعني الترقية عادةً تغيير الـ Proxy بحيث يشير إلى عقد Implementation جديد.

ينبغي أن يكون الـ Implementation الجديد متوافقًا مع تخطيط التخزين القديم وتوقعات المستخدمين.

قد تضيف ترقية Implementation خطيرة منطقًا ضارًا أو تعطل المحاسبة أو تغير الأذونات أو تمنع السحب.

لهذا ينبغي التحقق من رمز الـ Implementation وتدقيقه واختباره ومراجعته قبل تنفيذ الترقية.

ينبغي للمستخدمين ألا يفترضوا أن البروتوكول سيظل كما هو إلى الأبد لمجرد أن عنوان الـ Proxy لم يتغير.

في الأنظمة القابلة للترقية، يعد عنوان الـ Implementation جزءًا أساسيًا من منظومة الأمان.

Delegatecall

Delegatecall هي آلية منخفضة المستوى في EVM تتيح لعقد تنفيذ رمز من عقد آخر مع استخدام سياق تخزين العقد المستدعي.

في قابلية ترقية Proxy، يتيح delegatecall للـ Proxy استخدام منطق الـ Implementation مع إبقاء الحالة في عنوان الـ Proxy.

ولهذا يمكن لـ Implementation جديد تغيير السلوك دون نقل أرصدة المستخدمين من الـ Proxy.

تتميز Delegatecall بالقوة لأنها تفصل الرمز عن الحالة.

لكنها تنطوي على مخاطر لأن الـ Implementation يجب أن يفترض أنه يكتب في تخزين الـ Proxy وليس تخزينه الخاص.

إذا استخدم الـ Implementation تخطيط تخزين مختلفًا عن المتوقع، فقد تتصادم المتغيرات أو تتلف الحالة.

قد يؤدي تصميم delegatecall خاطئ إلى الكتابة فوق متغيرات الملكية أو الأرصدة أو التعيينات أو قيم الإعدادات.

ينبغي للمطورين تجنب كتابة منطق delegatecall مخصص لـ Proxy ما لم يفهموا التخزين وتنفيذ EVM فهمًا كاملًا.

لا يحتاج المستخدمون إلى فهم كل opcode، لكن ينبغي أن يعرفوا أن Proxies القابلة للترقية تعتمد على توجيه تقني غير مباشر.

وتعد Delegatecall أحد أسباب حاجة العقود القابلة للترقية إلى عمليات تدقيق متخصصة.

تخطيط التخزين

تخطيط التخزين هو ترتيب المتغيرات ومواقعها في تخزين العقد الذكي.

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

يمثل تخطيط التخزين أحد أهم مخاطر قابلية الترقية.

إذا غيّر Implementation جديد ترتيب المتغيرات الحالية أو نوعها أو بنيتها على نحو غير صحيح، فقد يفسر الـ Proxy بيانات التخزين القديمة بطريقة جديدة ومعطلة.

فعلى سبيل المثال، قد ينزاح تعيين للأرصدة، أو يُكتب فوق عنوان المالك، أو يُقرأ متغير إعدادات على أنه نوع مختلف.

ويُسمى ذلك خطر تصادم التخزين أو تلفه.

يضيف المطورون عادةً المتغيرات الجديدة بعد المتغيرات الموجودة بدلًا من إدراجها في الوسط.

كما يتجنبون تغيير أنواع المتغيرات أو ترتيب الوراثة دون تخطيط دقيق للترحيل.

يمكن لأدوات الترقية الحديثة مقارنة تخطيطات التخزين قبل السماح بالترقية.

ينبغي للمستخدمين اعتبار سلامة تخطيط التخزين جزءًا أساسيًا من أمان العقود القابلة للترقية.

خانات تخزين Proxy وفق ERC-1967

ERC-1967 هو معيار يحدد خانات تخزين معينة لمعلومات Proxy، مثل عنوان الـ Implementation وعنوان المسؤول وعنوان Beacon.

يحدد معيار ERC-1967 الرسمي خانات تخزين قياسية لـ Proxy كي تتمكن الأدوات والمستكشفات من تحديد إعدادات Proxy بموثوقية أكبر.

تقلل هذه الخانات المعيارية احتمال تصادم متغيرات إدارة Proxy مع متغيرات تخزين التطبيق.

كما يساعد ERC-1967 مستكشفات البلوكشين على إظهار الـ Implementation الذي يستخدمه Proxy حاليًا للمستخدمين.

تعتمد العديد من أنظمة Proxy الحديثة على خانات متوافقة مع ERC-1967.

ولا يجعل المعيار الترقيات آمنة بمفرده.

فهو يوفر أساسًا مكانًا متوقعًا لتخزين بيانات Proxy الوصفية.

ولا يزال المطورون بحاجة إلى تفويض صحيح والتحقق من تخطيط التخزين ومراجعة الـ Implementation وتنفيذ الترقية بأمان.

ينبغي للمستخدمين الذين يراجعون العقود القابلة للترقية التحقق مما إذا كان الـ Proxy يتبع معايير معروفة بدلًا من نمط مخصص غير معروف.

يحسن تخزين Proxy المعياري الشفافية، لكنه ليس سوى جزء واحد من أمان قابلية ترقية العقود الذكية.

نمط Transparent Proxy

يفصل نمط Transparent Proxy استدعاءات المسؤول عن استدعاءات المستخدمين لتقليل الالتباس بين محددات وظائف Proxy ووظائف الـ Implementation.

توضح وثائق Proxy من OpenZeppelin أن TransparentUpgradeableProxy يتضمن واجهة مدمجة للمسؤول والترقية.

في هذا النمط، يتفاعل المستخدمون العاديون مع وظائف الـ Implementation عبر Proxy.

ينفذ مسؤول Proxy إجراءات الترقية، ولا ينبغي له أن يستدعي وظائف الـ Implementation عن طريق Proxy بالطريقة نفسها التي يستخدمها المستخدمون عن غير قصد.

يساعد هذا التصميم على تجنب التعارضات التي تشترك فيها وظيفة Proxy ووظيفة Implementation في المحدد نفسه.

تُستخدم Transparent Proxies على نطاق واسع لأنها توفر نموذج مسؤول واضحًا.

لكنها لا تزال تتطلب إدارة آمنة لمفاتيح المسؤول.

إذا كان مسؤول Proxy خاضعًا لمفتاح واحد مكشوف، فقد يتعرض البروتوكول بأكمله للخطر.

يمكن أن تكون Transparent Proxies آمنة عند اقترانها بتحكم متعدد التوقيع، وأقفال زمنية، وعمليات تدقيق، وحوكمة واضحة.

يقلل النمط من خطر تقني واحد، لكنه لا يزيل مخاطر الحوكمة.

نمط UUPS Proxy

UUPS اختصار لـ Universal Upgradeable Proxy Standard.

يصف معيار EIP-1822 الرسمي نمط Proxy قابلًا للترقية عالميًا، يرتبط فيه منطق الترقية بتصميم الـ Implementation.

توضح وثائق OpenZeppelin أن UUPSUpgradeable يتضمن آلية الترقية في عقد الـ Implementation بدلًا من استخدام بنية مسؤول Proxy المدمجة نفسها المستخدمة في Transparent Proxy.

قد تكون UUPS Proxies أخف من Transparent Proxies لأن Proxy نفسه قد يكون أبسط.

لكن يجب أن يتضمن الـ Implementation وظائف الترقية ويحميها بطريقة صحيحة.

قد يؤدي Implementation سيئ لـ UUPS إلى إزالة القدرة على الترقية عن غير قصد، أو كشف صلاحية الترقية، أو السماح بترقيات غير مصرح بها.

يجب على المطورين أيضًا الحماية من الترقية إلى Implementation يعطل مسار الترقية.

يمكن أن تكون UUPS فعالة ومرنة عند استخدامها مع مكتبات ناضجة وأدوات تحقق.

ولا ينبغي نسخها دون فهم ضوابط التفويض وفحوصات أمان الترقية.

ينبغي للمستخدمين التحقق ممن يتحكم بترقيات UUPS وما إذا كانت الترقيات السابقة شفافة ومدققة.

نمط Beacon Proxy

يستخدم نمط Beacon Proxy عقد Beacon يخزن عنوان الـ Implementation لعدة Proxies.

بدلًا من أن يخزن كل Proxy عنوان الـ Implementation الخاص به، يقرأ كل Proxy الـ Implementation من Beacon.

يسمح هذا بترقية عدة مثيلات Proxy معًا عبر تحديث Beacon واحد.

تفيد Beacon Proxies الأنظمة التي تنشر عقودًا متشابهة كثيرة، مثل الخزائن ومجمعات السيولة والحسابات أو مثيلات العقود الخاصة بالمستخدمين.

وقد تقلل التعقيد التشغيلي عندما تحتاج مثيلات عديدة إلى الترقية نفسها.

كما يمكن أن تزيد نطاق التأثير، لأن ترقية Beacon سيئة قد تؤثر في Proxies كثيرة دفعة واحدة.

تتضمن وثائق Proxy من OpenZeppelin مكوّني BeaconProxy وUpgradeableBeacon المرتبطين بـ Proxy.

يجب حماية صلاحية Beacon بعناية لأنها قد تتحكم في منطق عقود عديدة.

ينبغي للمستخدمين التحقق مما إذا كان العقد الذي يستخدمونه يعتمد على Beacon ومن يستطيع تحديثه.

يُعد Beacon مناسبًا للمطورين، لكنه يركز سلطة الترقية في نقطة تحكم مشتركة.

نمط Diamond Proxy

يتيح نمط Diamond Proxy لعقد يشبه Proxy توجيه استدعاءات الوظائف إلى عدة عقود Implementation تُسمى Facets.

يحدد معيار EIP-2535 Diamond الرسمي نظام عقود ذكية معياريًا يمكن فيه إضافة الوظائف أو استبدالها أو إزالتها عبر Facets.

تفيد Diamonds الأنظمة الكبيرة التي قد تتجاوز حدود حجم العقد أو تحتاج إلى ترقيات معيارية.

يمكن لـ Diamond تنظيم المنطق المعقد في Facets منفصلة كثيرة مع الحفاظ على عنوان رئيسي واحد.

وقد تكون هذه المرونة قوية لأنظمة DeFi الكبيرة والألعاب وأنظمة الحسابات أو أطر البروتوكولات.

لكنها تزيد التعقيد لأن المستخدمين والمدققين يحتاجون إلى فهم توجيه Facets وجداول المحددات وأنماط التخزين وصلاحية الترقية.

يمكن لترقية Diamond استبدال جزء فقط من النظام، ما يجعل تتبع التغييرات أمرًا مهمًا.

ويكتسب تصميم التخزين أهمية خاصة لأن Facets متعددة قد تشترك في التخزين نفسه.

ينبغي للمطورين استخدام أنماط تخزين Diamond الواضحة أو التخزين ذي المساحات الاسمية عند الاقتضاء.

ينبغي للمستخدمين التعامل مع عقود Diamond باعتبارها أنظمة متقدمة قابلة للترقية تتطلب مراجعة دقيقة.

التخزين ذو المساحات الاسمية

التخزين ذو المساحات الاسمية هو أسلوب لتنظيم تخزين العقد بحيث تستخدم الوحدات المختلفة مواقع تخزين محددة وتقلل خطر التصادم.

يحدد معيار ERC-7201 لتخطيط التخزين ذي المساحات الاسمية اصطلاحًا لتوثيق مواقع التخزين لهذا النوع من التخزين في رمز Solidity المصدر.

يفيد التخزين ذو المساحات الاسمية في العقود القابلة للترقية والمعيارية لأنه يقلل الاعتماد على ترتيب متغيرات بسيط واحد عبر سلسلة وراثة طويلة.

وقد يجعل الترقيات أكثر أمانًا عندما تُبنى العقود من وحدات متعددة.

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

تشير إرشادات OpenZeppelin لكتابة العقود القابلة للترقية إلى أن Solidity 0.8.20 أو إصدارًا أعلى مطلوب لكي تتمكن إضافات الترقية من التحقق من تخطيطات التخزين ذات المساحات الاسمية باستخدام معلومات المترجم اللازمة.

لا يلغي التخزين ذو المساحات الاسمية الحاجة إلى التدقيق.

لكنه يساعد على تنظيم الحالة كي تصبح التغييرات المستقبلية أسهل إدارة.

ينبغي للمطورين استخدام التخزين ذي المساحات الاسمية باستمرار إذا اختاروا هذه البنية.

ويستفيد المستخدمون بصورة غير مباشرة لأن تصميم التخزين الأكثر أمانًا يقلل احتمال تلف الحالة المرتبط بالترقية.

دوال التهيئة

دوال التهيئة هي وظائف إعداد خاصة تستخدمها العقود القابلة للترقية بدلًا من Constructors.

في العقد العادي، يعمل Constructor عند نشر العقد.

في نظام Proxy، يتفاعل المستخدمون مع Proxy، ولا تهيئ Constructors الخاصة بالـ Implementation تخزين Proxy بالطريقة المعتادة.

لهذا تستخدم Implementations القابلة للترقية عادةً دوال تهيئة لضبط المالكين وأسماء التوكنات والأذونات وقيم الإعدادات والحالة الأولية الأخرى.

ينبغي أن تعمل دالة التهيئة مرة واحدة فقط، ما لم يُستخدم Reinitializer مصمم بعناية لترقية لاحقة.

إذا تُركت دالة تهيئة مفتوحة، فقد يهيئ مهاجم العقد ويستولي على الأدوار المهمة.

إذا احتاج Implementation جديد إلى متغيرات حالة جديدة، فقد يلزم Reinitializer لتهيئتها بأمان.

يجب على المطورين حماية دوال التهيئة وتعطيل التهيئة في عقود Implementation المستقلة عند الاقتضاء.

ينبغي للمستخدمين توخي الحذر عندما يكون سجل تهيئة عقد قابل للترقية غير واضح.

أخطاء التهيئة مصدر رئيسي لثغرات العقود القابلة للترقية.

صلاحية الترقية

صلاحية الترقية هي الحساب أو العقد أو المحفظة متعددة التوقيع أو القفل الزمني أو DAO أو نظام الحوكمة الذي يمكنه اعتماد الترقيات.

تعد صلاحية الترقية إحدى أهم افتراضات الثقة في عقد قابل للترقية.

إذا تحكم مفتاح خاص واحد في الترقيات، فقد يتمكن هذا المفتاح من استبدال منطق البروتوكول.

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

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

إذا تحكم قفل زمني في الترقيات، فقد يتاح للمستخدمين وقت للمراجعة والخروج قبل سريان التغييرات.

غالبًا ما تجمع عملية الترقية الآمنة بين التنفيذ متعدد التوقيع وتأخير القفل الزمني والإفصاح العلني عن المقترحات ومراجعة التدقيق والمراقبة.

ينبغي أن تكون صلاحية الترقية ظاهرة وموثقة.

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

في الأنظمة القابلة للترقية، تصميم الحوكمة هو تصميم أمني.

الأقفال الزمنية

يؤخر القفل الزمني التنفيذ بعد اقتراح ترقية أو اعتمادها.

يمنح هذا التأخير المستخدمين والمدققين والباحثين وأنظمة المراقبة وقتًا لمراجعة التغيير القادم.

يمكن للقفل الزمني تقليل خطر الترقيات المفاجئة التي تغير سلوك العقد فورًا.

وقد يمنح المستخدمين أيضًا وقتًا لسحب الأموال إذا لم يوافقوا على ترقية.

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

تستخدم بعض الأنظمة مسارات طوارئ أقصر ومسارات حوكمة عادية أطول.

يمكن لمسارات الطوارئ حماية المستخدمين من الاستغلالات، لكنها قد تخلق أيضًا خطر المركزية.

يشرح البروتوكول الجيد قواعد القفل الزمني بوضوح.

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

القفل الزمني ذو قيمة لأنه يحول صلاحية الترقية من سلطة فورية إلى سلطة مرئية ومؤجلة.

الترقيات التي تتحكم بها الحوكمة

تستخدم الترقيات التي تتحكم بها الحوكمة تصويت التوكنات أو التصويت بالتفويض أو موافقة المجلس أو مقترحات DAO أو أنظمة مماثلة لاعتماد تغييرات الـ Implementation.

قد يجعل ذلك الترقيات أكثر لامركزية من مفتاح مسؤول واحد.

لكنه قد يجعلها أيضًا أبطأ وأكثر تعقيدًا.

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

ولا يعني تصويت الحوكمة تلقائيًا أن التغيير آمن تقنيًا.

فقد يعتمد الناخبون رمزًا لا يفهمونه بالكامل.

وقد يخفي اقتراح ضار منطقًا خطيرًا داخل حزمة ترقية كبيرة.

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

ينبغي للمستخدمين مراجعة عمليات ترقية الحوكمة قبل إيداع الأصول في بروتوكول.

يمكن للحوكمة توزيع السلطة، لكنها لا تلغي الحاجة إلى مراجعة الأمان التقني.

العقود غير القابلة للتغيير مقابل العقود القابلة للترقية

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

يمكن للعقد الذكي القابل للترقية تغيير منطقه عبر آلية ترقية محددة.

قد يكون من الأسهل فهم العقود غير القابلة للتغيير لأن الرمز المنشور يبقى ثابتًا.

لكنها قد تكون خطيرة أيضًا إذا اكتُشف خطأ جسيم ولم يتوفر إصلاح آمن.

يمكن للعقود القابلة للترقية إصلاح الأخطاء وإضافة الميزات.

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

ولا يكون أي من النموذجين أفضل دائمًا.

قد يفضل عقد توكن بسيط عدم القابلية للتغيير إذا كان ينبغي ألا تتغير قواعده أبدًا.

وقد يحتاج بروتوكول DeFi معقد إلى قابلية الترقية من أجل تصحيحات الأمان وظروف السوق المتغيرة.

يعتمد التصميم المناسب على المخاطر والتعقيد ونضج الحوكمة وتوقعات المستخدمين.

الترحيل مقابل قابلية الترقية

يعني الترحيل نشر عقد جديد ونقل المستخدمين أو الأصول أو عمليات التكامل من العقد القديم إلى العقد الجديد.

وتعني قابلية الترقية تغيير المنطق خلف عنوان أو نظام قائم مع الحفاظ على الحالة أو الاستمرارية التي يواجهها المستخدم.

قد يكون الترحيل أسهل فهمًا لأن العقد القديم يظل دون تغيير والعقد الجديد منفصل.

لكن الترحيل قد يكون مرهقًا لأن المستخدمين قد يحتاجون إلى اعتماد التحويلات أو نقل المراكز أو المطالبة بتوكنات جديدة أو تحديث عمليات التكامل.

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

لكنها قد تخفي أيضًا تغييرات كبيرة خلف العنوان نفسه.

تستخدم بعض البروتوكولات النهجين معًا بحسب خطورة التغيير.

قد يستخدم إصلاح خطأ بسيط ترقية، بينما قد تستخدم إعادة تصميم كبيرة ترحيلًا.

ينبغي للمستخدمين فهم ما إذا كان البروتوكول يستطيع التغيير في مكانه أو يتطلب ترحيلًا يدويًا.

تختلف مخاطر الترحيل عن مخاطر الترقية، لكن كليهما يتطلب تواصلًا دقيقًا.

التحقق من الرمز المصدر

يساعد التحقق من الرمز المصدر المستخدمين على مقارنة الرمز المصدر المنشور بالـ bytecode المنشور.

توضح وثائق Ethereum للتحقق من العقود الذكية أن التحقق يقارن الرمز المصدر للعقد الذكي والـ bytecode المترجم.

بالنسبة للعقود القابلة للترقية، ينبغي للمستخدمين التحقق من كل من Proxy والـ Implementation الحالي متى أمكن.

قد لا يعرض Proxy تم التحقق منه وحده منطق الأعمال الكامل.

يساعد Implementation تم التحقق منه المستخدمين على قراءة المنطق الحالي، لكن ينبغي لهم الاستمرار في التحقق من صلاحية الترقية.

عندما يرقّي البروتوكول النظام، ينبغي أيضًا التحقق من الـ Implementation الجديد.

لا ينبغي للمستخدمين افتراض أن العقد يظل آمنًا لأن Implementation سابقًا تم تدقيقه.

قد تضيف الترقية وظائف جديدة أو تغير الأذونات أو تعدل المحاسبة أو تقدم أخطاء جديدة.

التحقق خطوة للشفافية، وليس ضمانًا كاملًا للأمان.

تحتاج الأنظمة القابلة للترقية إلى تحقق مستمر بعد كل ترقية.

فجوات التخزين

فجوات التخزين هي خانات تخزين غير مستخدمة ومحجوزة تُضاف إلى العقود القابلة للترقية بحيث تتمكن الإصدارات المستقبلية من إضافة متغيرات دون إزاحة تخزين العقود الفرعية بصورة غير متوقعة.

هذا النمط شائع في العقود القابلة للترقية التي تعتمد كثيرًا على الوراثة.

قد تظهر فجوة تخزين في صورة مصفوفة غير مستخدمة ذات حجم ثابت ومحجوزة لمتغيرات مستقبلية.

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

تفيد فجوات التخزين، لكنها تتطلب انضباطًا.

ولا يزال الاستخدام غير الصحيح للفجوة قد يسبب مشكلات في تخطيط التخزين.

يُعد التخزين ذو المساحات الاسمية نهجًا أحدث يمكن أن يقلل الاعتماد على فجوات تخزين كبيرة في بعض البنى.

ينبغي للمطورين اتباع إرشادات إطار الترقية وأدوات المترجم الخاصة بهم.

ينبغي للمدققين مراجعة فجوات التخزين وتغييرات التخطيط أثناء كل ترقية.

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

اختبار الترقية

يتحقق اختبار الترقية مما إذا كان Implementation جديد يعمل بصورة صحيحة مع حالة Proxy القائمة.

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

ينبغي لاختبارات الترقية محاكاة الإصدار القديم، وملء حالة واقعية، وتنفيذ الترقية، ثم اختبار الإصدار الجديد مقابل الحالة القائمة.

ينبغي أن تتحقق الاختبارات من الأرصدة والأذونات والمحاسبة وموافقات التوكنات وتعيينات الأدوار وإعدادات Oracle ومنطق الإيقاف المؤقت ومراكز المستخدمين.

وينبغي أن تتحقق أيضًا من أن المستخدمين غير المصرح لهم لا يمكنهم ترقية العقد.

قد يساعد اختبار Fork في محاكاة الترقيات مقابل حالة سلسلة حقيقية عند الاقتضاء.

يمكن لأدوات التحقق من تخطيط التخزين اكتشاف كثير من التغييرات غير الآمنة قبل النشر.

ينبغي أن تغطي الاختبارات المسارات الناجحة ومسارات الفشل.

ينبغي التعامل مع كل ترقية على أنها نشر جديد مع مخاطر ترحيل إضافية.

يعرض البروتوكول الذي يرقّي دون اختبار جاد مستخدميه لخطر يمكن تجنبه.

تدقيقات الترقية

يراجع تدقيق الترقية الـ Implementation الجديد وتغييرات التخزين ومنطق Initializer أو Reinitializer وضوابط الوصول ومسار تنفيذ الحوكمة.

ينبغي لتدقيق الترقية مقارنة الإصدار القديم بالإصدار الجديد.

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

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

وينبغي لهم أيضًا مراجعة ما إذا كانت الترقية تنشئ تغييرات كاسرة في ABI للتطبيقات التي تستدعي العقد.

لا يضمن التدقيق الأمان، لكنه يقلل المخاطر.

ينبغي للبروتوكولات الكبيرة نشر تقارير التدقيق أو ملخصاتها عندما تؤثر الترقيات في أموال المستخدمين.

قد تكون الترقيات الصغيرة خطيرة أيضًا إذا مست المحاسبة أو الأذونات أو السحوبات أو منطق Oracle.

ينبغي للمستخدمين التحقق مما إذا كانت ترقية Implementation كبيرة قد دُققت قبل الوثوق بها.

تدقيقات الترقية دفاع أساسي ضد التراجعات الخفية.

توافق ABI

يعني توافق ABI أن التطبيقات الخارجية يمكنها الاستمرار في استدعاء العقد كما هو متوقع بعد الترقية.

يحدد ABI أسماء الوظائف والمدخلات والمخرجات والأحداث والأخطاء التي تستخدمها المحافظ والتطبيقات.

قد تكسر الترقية التوافق إذا أزالت وظائف أو غيرت أنواع الإرجاع أو غيرت سلوك الأحداث أو غيرت الافتراضات التي تعتمد عليها الجهات المتكاملة.

قد تؤدي تغييرات ABI الكاسرة إلى تعطل تطبيقات الواجهة الأمامية أو بوتات التداول أو أنظمة المحاسبة أو عمليات تكامل DeFi.

حتى إذا كان التخزين آمنًا، قد تتعطل تجربة المستخدم إذا تغيرت الواجهة دون تنسيق.

ينبغي للمطورين توثيق تغييرات ABI بوضوح قبل الترقيات.

ينبغي للجهات المتكاملة مراقبة ترقيات Implementation في البروتوكولات التي تعتمد عليها.

قد يرى المستخدمون معاملات فاشلة إذا لم يُحدّث التطبيق ليتوافق مع Implementation جديد.

يعد توافق ABI جزءًا من أمان الترقية لأن العقود الذكية توجد ضمن منظومة أوسع.

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

مخاطر مفتاح المسؤول

مخاطر مفتاح المسؤول هي خطر سرقة المفتاح أو الحساب الذي يتحكم في الترقيات أو إساءة استخدامه أو فقدانه أو خضوعه لطرف غير موثوق.

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

إذا فُقد مفتاح المسؤول، فقد يعجز الفريق عن إصلاح أخطاء مستقبلية.

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

يمكن للمحافظ متعددة التوقيع تقليل مخاطر المفتاح الواحد عبر اشتراط عدة موافقات.

يمكن للأقفال الزمنية تقليل خطر الترقيات المفاجئة بإضافة تأخير.

يمكن لحوكمة DAO توزيع سلطة الترقية، لكنها تقدم مخاطر هجمات الحوكمة.

ينبغي للبروتوكولات الإفصاح عمن يتحكم في الترقيات وكيفية تأمين المفاتيح.

ينبغي للمستخدمين اعتبار التحكم الإداري المخفي أو غير الواضح علامة تحذير رئيسية.

في العقود القابلة للترقية، يكون أمان المسؤول غالبًا مهمًا بقدر أمان الرمز.

الترقيات الطارئة

الترقيات الطارئة هي ترقيات سريعة تُستخدم لإصلاح الثغرات الحرجة أو إيقاف الهجمات النشطة.

قد تحمي أموال المستخدمين عندما يكون انتظار دورة حوكمة كاملة بطيئًا جدًا.

لكن الترقيات الطارئة قد تخلق أيضًا خطر المركزية لأنها قد تتجاوز المراجعة أو التصويت أو تأخيرات القفل الزمني المعتادة.

ينبغي أن يحدد البروتوكول صلاحيات الطوارئ قبل وقوع حالة طارئة.

ينبغي أن تكون ضوابط الطوارئ محدودة وموثقة ومراقبة وخاضعة لعمليات موثوقة.

بعد ترقية طارئة، ينبغي للفريق نشر معلومات واضحة عما تغير وسبب التغيير.

ينبغي للمستخدمين فهم ما إذا كان البروتوكول يمتلك حقوق ترقية طارئة.

قد يكون البروتوكول الذي لا يملك مسار طوارئ أبطأ في الاستجابة للاستغلالات.

وقد يتطلب البروتوكول الذي يملك سلطة طوارئ غير محدودة قدرًا مفرطًا من الثقة.

يوازن أفضل تصميم بين الحماية السريعة والشفافية والمساءلة.

التوكنات القابلة للترقية

التوكنات القابلة للترقية هي عقود توكنات يمكن أن يتغير منطقها بعد النشر.

قد يسمح ذلك بإصلاح الأخطاء وتغييرات الامتثال ونماذج الرسوم الجديدة وتغييرات الجسور أو تحديثات الميزات.

وقد يسمح أيضًا بتغييرات خطيرة، مثل حقوق سك جديدة أو قيود على التحويلات أو قوائم حظر أو رسوم غير متوقعة.

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

قد يغير توكن يملك صلاحية ترقية سلوكه حتى إذا ظل اسمه ورمزه وعنوانه كما هي.

ينبغي لحاملي التوكن مراجعة الأدوار الإدارية وصلاحية السك وضوابط الإيقاف المؤقت ووظائف القائمة السوداء وحوكمة الترقية.

ينبغي التحقق من الرمز المصدر بعد الترقيات الكبيرة.

ينبغي لمزودي السيولة توخي الحذر بشكل خاص لأن تغييرات قواعد التوكن قد تؤثر في مجمعات التداول.

قد يكون التوكن القابل للترقية مشروعًا، لكنه يملك نموذج ثقة مختلفًا عن التوكن غير القابل للتغيير.

ينبغي الإفصاح بوضوح للمستخدمين عن قابلية ترقية التوكن.

بروتوكولات DeFi القابلة للترقية

يمكن لبروتوكولات التمويل اللامركزي (DeFi) القابلة للترقية تغيير منطق الإقراض والمبادلة والتخزين والتصفيات واستراتيجيات الخزائن ومعدلات الفائدة أو قواعد الضمانات.

قد تكون هذه المرونة مفيدة لأن أسواق DeFi تتغير بسرعة وقد تكون الأخطاء جسيمة.

لكنها قد تخلق مخاطر أيضًا لأن قواعد البروتوكول قد تتغير بعد إيداع المستخدمين أموالهم.

قد تغير الترقية منطق السحب أو حسابات الرسوم أو معلمات المخاطر أو مصادر Oracle أو سلوك التصفية.

ينبغي للمستخدمين التحقق مما إذا كانت ترقيات بروتوكول DeFi خاضعة لفريق أو محفظة متعددة التوقيع أو قفل زمني أو عملية حوكمة.

وينبغي لهم أيضًا التحقق مما إذا كانت العقود الحرجة غير قابلة للتغيير أو قابلة للترقية.

قد يضم البروتوكول بعض العقود غير القابلة للتغيير وبعض العقود القابلة للترقية.

تكتسب مخاطر ترقية DeFi أهمية خاصة لأن العقود غالبًا ما تحتفظ بسيولة مجمعة.

وقد تؤثر ترقية سيئة واحدة في كثير من المستخدمين دفعة واحدة.

يتطلب DeFi القابل للترقية مراقبة مستمرة، وليس ثقة لمرة واحدة.

قابلية الترقية وOracles

توفر Oracles بيانات خارجية، مثل أسعار الأصول، للعقود الذكية.

قد يتمكن بروتوكول قابل للترقية من تغيير منطق Oracle أو عناوين Oracle.

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

قد تفيد قابلية ترقية Oracle عندما يصبح مصدر بيانات قديم غير موثوق أو يتوفر مصدر أفضل.

لكنها قد تكون خطيرة إذا استطاع مسؤول التبديل إلى Oracle متلاعب به أو ضار.

في أنظمة الإقراض والمشتقات، قد تؤدي ترقية Oracle سيئة إلى تصفيات غير عادلة أو تسوية غير صحيحة.

ينبغي للمستخدمين التحقق ممن يستطيع تغيير مصادر Oracle وما إذا كانت تلك التغييرات خاضعة لقفل زمني.

ينبغي للمطورين استخدام حوكمة ومراقبة قوية لـ Oracle.

ينبغي التعامل مع تغييرات Oracle باعتبارها ترقيات عالية المخاطر.

تُعد مصادر البيانات جزءًا من منطق العقود الذكية حتى عندما توجد خارج الرمز الرئيسي للعقد.

قابلية الترقية والجسور

تستخدم الجسور غالبًا عقودًا قابلة للترقية لأن منطق الجسر يجب أن يستجيب لسلاسل جديدة وتنسيقات رسائل ومجموعات مدققين وضوابط مخاطر وتصحيحات أمنية.

قد تحسن قابلية ترقية الجسر القدرة على التكيف.

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

قد تغير ترقية جسر ضارة قواعد السحب أو تسك الأصول المغلفة بصورة غير صحيحة أو تعيد توجيه الأموال.

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

الجسور معقدة أصلًا لأنها تعتمد على شبكات متعددة وافتراضات للتحقق.

وتضيف قابلية الترقية طبقة أخرى من المخاطر.

قد يكون عقد جسر ذي حوكمة ترقية قوية أكثر أمانًا من عقد يتحكم به مفتاح واحد.

لكن لا تزيل أي عملية ترقية جميع مخاطر الجسر.

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

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

تخلق قابلية الترقية مفاضلة في الثقة.

يحصل المستخدمون على ميزة إصلاح الأخطاء وتحسين الميزات.

ويقبل المستخدمون خطر أن يتغير المنطق المستقبلي بطرق لا تعجبهم.

يمكن لعملية ترقية شفافة تحسين الثقة عبر إظهار ما سيتغير قبل تغييره.

وقد تقلل عملية ترقية مخفية أو فورية الثقة لأن المستخدمين لا يمكنهم تقييم التغييرات في الوقت المناسب.

ينبغي للبروتوكولات شرح حقوق الترقية بلغة واضحة.

وينبغي أن تنشر عناوين الـ Implementation وعناوين المسؤول وتفاصيل القفل الزمني وتقارير التدقيق ومقترحات الحوكمة.

لا ينبغي للمستخدمين أن يسألوا فقط عما إذا كان العقد مدققًا.

بل ينبغي أن يسألوا عما إذا كان يمكن استبدال الرمز المدقق غدًا.

في العقود الذكية القابلة للترقية، تعتمد الثقة على الرمز الحالي وعلى التحكم في التغييرات المستقبلية.

كيفية التحقق مما إذا كان العقد قابلًا للترقية

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

ثم تحقق من عنوان الـ Implementation إذا عرضه المستكشف.

راجع ما إذا كان Proxy يتبع نمطًا معروفًا مثل ERC-1967 أو Transparent Proxy أو UUPS أو Beacon Proxy أو Diamond.

تحقق مما إذا كان الرمز المصدر للـ Implementation قد تم التحقق منه.

تحقق ممن يتحكم في الترقيات من خلال عناوين المسؤول أو أدوار المالك أو المحافظ متعددة التوقيع أو الأقفال الزمنية أو عقود الحوكمة.

راجع الأحداث الأخيرة لمعرفة تغييرات الـ Implementation أو معاملات الترقية.

اقرأ وثائق البروتوكول لفهم سياسة الترقية.

تحقق من تقارير التدقيق لمعرفة ما إذا كانت قابلية الترقية ضمن نطاق التدقيق.

راقب مقترحات الحوكمة إذا كان البروتوكول يستخدم ترقيات تتحكم بها DAO.

لا يكفي عنوان العقد وحده لأن الأنظمة القابلة للترقية تتطلب مراجعة Proxy وImplementation وهيكل الصلاحيات معًا.

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

أحد الأخطاء الشائعة هو تغيير ترتيب متغيرات التخزين أثناء الترقية.

خطأ آخر هو نسيان حماية دوال التهيئة.

والخطأ الثالث هو استخدام مفتاح خاص واحد بصفته مسؤول الترقية الوحيد.

والخطأ الرابع هو الترقية دون قفل زمني أو إشعار علني.

والخطأ الخامس هو نشر Implementation جديد دون التحقق من الرمز المصدر.

والخطأ السادس هو افتراض أن تدقيقًا قديمًا ما زال يغطي Implementation جديدًا.

والخطأ السابع هو تغيير ABI بطريقة تكسر عمليات التكامل.

والخطأ الثامن هو عدم اختبار الترقيات مقابل حالة قائمة شبيهة ببيئة الإنتاج.

والخطأ التاسع هو استخدام منطق Proxy مخصص دون مراجعة معمقة.

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

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

الفائدة الأولى هي القدرة على إصلاح الأخطاء بعد النشر.

الفائدة الثانية هي القدرة على إضافة ميزات دون إجبار المستخدمين على الترحيل يدويًا.

الفائدة الثالثة هي استمرارية العنوان للمستخدمين والمحافظ وعمليات التكامل.

الفائدة الرابعة هي تحسين القدرة على الاستجابة خلال حالات الطوارئ.

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

الفائدة السادسة هي تكرار تطوير المنتجات بسلاسة أكبر في أسواق الكريبتو سريعة الحركة.

الفائدة السابعة هي القدرة على تحديث عمليات تكامل Oracle أو معلمات المخاطر أو التبعيات الخارجية.

الفائدة الثامنة هي تقليل صعوبات الترحيل عندما يتطور تصميم البروتوكول.

تفسر هذه الفوائد سبب اختيار العديد من تطبيقات الكريبتو المتقدمة لبنى قابلة للترقية.

وتكون الفوائد أقوى عندما تكون صلاحية الترقية شفافة وآمنة ومؤجلة ومدققة ومحكومة بمسؤولية.

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

الخطر الأول هو صلاحية ترقية ضارة أو مخترقة.

الخطر الثاني هو تلف التخزين أثناء تغيير غير آمن في الـ Implementation.

الخطر الثالث هو إساءة استخدام Initializer أو Reinitializer.

الخطر الرابع هو المركزية الخفية عبر مفاتيح المسؤول.

الخطر الخامس هو تعطل عمليات التكامل بسبب تغييرات ABI أو السلوك.

الخطر السادس هو ارتباك المستخدمين لأن العنوان الظاهر قد يبقى نفسه بينما يتغير المنطق.

الخطر السابع هو إساءة استخدام الترقيات الطارئة.

الخطر الثامن هو الثقة الزائفة الناتجة عن تدقيق غطى Implementation قديمًا فقط.

الخطر التاسع هو الاستيلاء على الحوكمة أو التصويت المتسرع.

الخطر العاشر هو التعقيد الذي يجعل فهم النظام أصعب على المستخدمين والمدققين.

أفضل الممارسات للمطورين

استخدم مكتبات ترقية ناضجة وخضعت لمراجعة جيدة بدلًا من رمز Proxy مخصص متى أمكن.

اختر نمط ترقية واضحًا مثل Transparent Proxy أو UUPS أو Beacon Proxy أو Diamond فقط بعد فهم مفاضلاته.

تحقق من تخطيط التخزين قبل كل ترقية.

احمِ دوال التهيئة وإعادة التهيئة بعناية.

استخدم التحكم متعدد التوقيع والأقفال الزمنية وعمليات الحوكمة لصلاحيات الترقية المهمة.

انشر عناوين الـ Implementation ومعاملات الترقية وشروحات الترقية بلغة واضحة.

تحقق من الرمز المصدر لكل Implementation جديد.

أجرِ اختبارات الترقية مقابل حالة شبيهة بالإنتاج وبيئات Fork عند الاقتضاء.

دقق الترقيات الكبيرة قبل التنفيذ.

راقب أحداث الترقية وأعد خطط التراجع أو الاستجابة للحوادث عندما تسمح البنية بذلك.

أفضل الممارسات للمستخدمين

تحقق مما إذا كان العقد قابلًا للترقية قبل إيداع الأموال.

راجع من يتحكم في صلاحية الترقية.

فضّل البروتوكولات التي تستخدم أقفالًا زمنية وتحكمًا متعدد التوقيع وعمليات تدقيق وحوكمة علنية للترقيات.

تحقق مما إذا كان الرمز المصدر للـ Implementation الحالي قد تم التحقق منه.

لا تفترض أن تدقيقًا قديمًا يغطي Implementation جديدًا.

راقب إعلانات ترقيات البروتوكول الرئيسية إذا كنت تستخدم البروتوكول بكثافة.

افهم ما إذا كانت الترقيات الطارئة يمكن أن تتجاوز التأخيرات المعتادة.

راجع أدوار المسؤول وضوابط الإيقاف المؤقت وضوابط Oracle وصلاحيات سك التوكنات.

فكر في سحب الأموال قبل الترقيات المثيرة للجدل أو غير الواضحة متى أمكن.

تعامل مع قابلية الترقية باعتبارها افتراضًا للثقة، وليس تفصيلًا تقنيًا ثانويًا.

الأسئلة الشائعة

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

تعني قابلية ترقية العقود الذكية أن نظام عقود ذكية منشورًا يمكنه تغيير منطقه بعد النشر عبر آلية ترقية مصممة.

لماذا تتم ترقية العقود الذكية؟

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

هل العقود الذكية القابلة للترقية أقل أمانًا؟

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

ما هو عقد Proxy؟

عقد Proxy هو عنوان مستقر يمرر الاستدعاءات إلى عقد Implementation مع الحفاظ عادةً على حالة النظام.

ما هو عقد Implementation؟

يحتوي عقد Implementation على المنطق الذي ينفذه Proxy عبر التفويض.

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

أكبر المخاطر هي أن صلاحية ترقية مخولة أو مخترقة يمكنها استبدال منطق آمن بمنطق معطل أو ضار.

ما هي مخاطر تخطيط التخزين؟

مخاطر تخطيط التخزين هي احتمال أن يقرأ Implementation جديد تخزين Proxy القائم أو يكتبه بصورة غير صحيحة، مما يتلف الحالة المهمة.

ما هو القفل الزمني في قابلية الترقية؟

يؤخر القفل الزمني تنفيذ الترقية بحيث يتوفر للمستخدمين والمراجعين وقت لفحص التغييرات المقترحة قبل سريانها.

هل يعني الرمز المصدر الذي تم التحقق منه أن العقد القابل للترقية آمن؟

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

كيف يمكنني معرفة ما إذا كان العقد قابلًا للترقية؟

يمكنك التحقق من تصنيفات Proxy في مستكشف البلوكشين وعناوين الـ Implementation وخانات ERC-1967 وأحداث الترقية وأدوار المسؤول ووثائق الحوكمة وتقارير التدقيق.

الخلاصة

قابلية ترقية العقود الذكية هي نهج تصميم يتيح لتطبيقات البلوكشين تغيير منطق العقد بعد النشر مع الحفاظ على العناوين والحالة المهمة.

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

تستخدم تصاميم قابلية الترقية الأكثر شيوعًا Proxies وعقود Implementation وdelegatecall وخانات تخزين معيارية وصلاحية ترقية خاضعة للتحكم.

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

يعتمد أمان النظام القابل للترقية على الانضباط في تخطيط التخزين وحماية دوال التهيئة والتحقق من الرمز المصدر والاختبار والتدقيق وأمان مفاتيح المسؤول والأقفال الزمنية والحوكمة الشفافة.

لا ينبغي للمستخدمين أبدًا التعامل مع العقد القابل للترقية على أنه غير قابل للتغيير بالكامل ما لم تُزل صلاحية الترقية أو تصبح مستحيلة بحكم التصميم.

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

للمبتدئين، من الأفضل فهم قابلية ترقية العقود الذكية باعتبارها طريقة لتحديث برمجيات البلوكشين بعد النشر.

وللمستخدمين المتقدمين، هي نموذج أمان متكامل يشمل بنية Proxy وتوافق التخزين والتحكم في الوصول وتنفيذ الحوكمة والمراقبة وحقوق خروج المستخدمين.

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

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