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

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

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

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

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

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

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

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

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

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

وبالنسبة للمطورين، تتمثل الفائدة الرئيسية في المرونة، إذ يمكنهم تحسين بروتوكول دون فرض ترحيل كامل لأموال المستخدمين وبياناتهم.

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

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

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

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

يحتوي عقد التنفيذ على المنطق الفعلي، مثل قواعد التحويل وحسابات التخزين ووظائف الاقتراض وتوزيع المكافآت أو فحوصات التحكم في الوصول.

عندما يرسل المستخدم معاملة إلى الوكيل، يستخدم الوكيل آلية منخفضة المستوى تسمى

لتشغيل كود من عقد التنفيذ.

مع

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

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

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

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

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

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

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

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

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

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

يمكن للتصميم القابل للترقية تقليل هذه المشكلة من خلال السماح بتحديثات مضبوطة لمنطق البروتوكول.

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

لكن قابلية الترقية تغير أيضًا نموذج الثقة في تطبيق الكريبتو.

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

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

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

نمط الوكيل

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

في هذا النمط، يخزن عقد الوكيل الحالة ويحول استدعاءات الوظائف إلى عقد التنفيذ.

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

عندما يُرقّى البروتوكول، يُنشر عقد تنفيذ جديد ويُحدّث الوكيل ليشير إلى ذلك التنفيذ الجديد.

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

يشرح توثيق Ethereum لترقية العقود الذكية هذا التصميم بالتفصيل.

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

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

لا يكون الوكيل آمنًا تلقائيًا لمجرد أنه قابل للترقية.

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

عقد التنفيذ

يُسمى عقد التنفيذ أحيانًا عقد المنطق، لأنه يحتوي على الكود الذي يحدد كيفية عمل التطبيق.

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

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

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

عندما يفوض الوكيل استدعاءً إلى التنفيذ، يستخدم كود التنفيذ تخزين الوكيل.

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

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

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

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

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

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

في Solidity، توضع متغيرات الحالة في خانات التخزين وفق قواعد محددة، بما في ذلك ترتيب المتغيرات وترتيب الوراثة.

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

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

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

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

يشرح توثيق تخطيط التخزين في Solidity كيفية تنظيم Solidity لمتغيرات الحالة في التخزين الدائم.

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

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

خانات تخزين الوكيل ERC-1967

ERC-1967 هو معيار شائع في Ethereum يحدد خانات تخزين معينة لمعلومات الوكيل، بما يشمل عنوان التنفيذ وعنوان المسؤول وعنوان المنارة.

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

كما يساعد مستكشفات البلوكشين وأدوات المطورين على تحديد التنفيذ الكامن خلف الوكيل.

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

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

تحدد مواصفة ERC-1967 الرسمية هذه الاتفاقيات الخاصة بخانات تخزين الوكيل.

بالنسبة لمستخدمي الكريبتو، يمكن لـERC-1967 أن يجعل العقود القابلة للترقية أسهل للفحص، لأن كثيرًا من الأدوات تستطيع عرض عنوان التنفيذ الحالي.

وبالنسبة للمطورين، يوفر ERC-1967 طريقة أكثر أمانًا ومعيارية لتخزين البيانات الوصفية للوكيل.

التخزين ضمن مساحات أسماء ERC-7201

ERC-7201 هو معيار أحدث لتخطيط التخزين ضمن مساحات أسماء في العقود الذكية.

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

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

تستخدم OpenZeppelin Contracts 5.x أنماط عقود قابلة للترقية تتضمن مساحات تخزين بأسماء على نمط ERC-7201 في الإصدارات القابلة للترقية.

تصف مواصفة ERC-7201 الرسمية اتفاقية لتوثيق مواقع التخزين ضمن مساحات الأسماء في كود مصدر Solidity.

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

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

ولا يلغي الحاجة إلى التدقيق والاختبارات والمراجعة الدقيقة للترقيات.

دوال التهيئة بدلًا من المنشئات

تستخدم العقود القابلة للترقية عادةً دوال التهيئة بدلًا من المنشئات.

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

ولهذا تنقل العقود القابلة للترقية عادةً منطق الإعداد إلى دالة مثل

.

تضبط دالة التهيئة قيمًا مثل اسم التوكن ورمزه وعنوان المالك وأدوار المسؤول ومعايير الرسوم أو الإعداد الأولي.

يجب حماية دالة التهيئة بحيث لا تعمل إلا مرة واحدة لكل وكيل.

إذا أمكن استدعاء دالة التهيئة أكثر من مرة، فقد يعيد مهاجم تعيين الملكية أو يغير الأذونات أو يستولي على العقد.

يشرح دليل OpenZeppelin لكتابة العقود القابلة للترقية سبب استبدال المنشئات بدوال التهيئة في العقود القابلة للترقية القائمة على الوكيل.

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

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

الوكيل الشفاف

الوكيل الشفاف هو تصميم وكيل يفصل استدعاءات المسؤول عن استدعاءات المستخدمين.

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

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

كما يقلل خطر تعارض محددات الوظائف بين وظائف مسؤول الوكيل ووظائف التنفيذ.

هذا النمط شائع في أنظمة الإنتاج لأنه يوفر هيكلًا واضحًا للمسؤول عن الترقيات.

والمقابل هو أنه قد يتضمن مكونات إضافية للنشر والإدارة، مثل عقد مسؤول وكيل.

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

وكيل UUPS

يشير UUPS إلى Universal Upgradeable Proxy Standard.

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

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

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

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

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

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

وكيل المنارة

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

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

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

الميزة الرئيسية هي الكفاءة التشغيلية، لأن ترقية منارة واحدة يمكنها تحديث العديد من الوكلاء.

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

ينبغي حماية ملكية المنارة وأذونات الترقية بحوكمة ومراقبة قويتين.

نمط Diamond

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

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

يمكن لتصميم Diamond ترقية جزء واحد من النظام دون استبدال كل الوظائف دفعة واحدة.

قد يكون ذلك مفيدًا لبروتوكولات الكريبتو المعقدة التي تحتاج إلى ميزات كثيرة تحت عنوان واحد.

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

قد تكون الأنظمة على نمط Diamond قوية، لكنها قد تكون أصعب على المستخدمين العاديين للفحص من هياكل الوكيل الأبسط.

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

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

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

الفائدة الثانية هي توسيع الميزات.

يمكن للبروتوكول إضافة أنواع ضمانات جديدة أو قواعد مكافآت جديدة أو وحدات جديدة أو ضوابط أمنية جديدة مع الحفاظ على عنوان العقد نفسه.

الفائدة الثالثة هي استقرار عمليات التكامل.

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

الفائدة الرابعة هي تجربة المستخدم.

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

الفائدة الخامسة هي الاستجابة للطوارئ.

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

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

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

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

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

ومن المخاطر الرئيسية الأخرى تلف التخزين.

قد تؤدي ترقية تنفيذ مصممة بشكل سيئ إلى كسر العلاقة بين البيانات القديمة والمنطق الجديد.

الخطر الثالث هو التعقيد الخفي.

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

الخطر الرابع هو ضعف المراقبة.

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

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

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

كيف يمكن للمستخدمين تقييم عقد قابل للترقية

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

تعرض كثير من مستكشفات البلوكشين معلومات الوكيل عندما يتبع العقد معايير الوكيل الشائعة مثل ERC-1967.

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

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

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

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

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

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

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

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

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

ينبغي لهم كتابة اختبارات آلية للنشر الأصلي ولكل مسار ترقية.

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

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

ينبغي لهم تجنب الأنماط الخطرة منخفضة المستوى ما لم تكن ضرورية وخاضعة للمراجعة الكاملة.

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

ينبغي لهم إصدار أحداث واضحة عند حدوث الترقيات كي تتمكن أنظمة المراقبة من اكتشاف التغييرات.

ينبغي لهم توثيق ما تغير، وسبب تغيره، والمخاطر التي أُخذت في الاعتبار.

ينبغي لهم التخطيط للاستجابة للطوارئ من دون منح سلطة غير محدودة لجهة واحدة.

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

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

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

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

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

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

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

لا يكون أي من التصميمين أفضل دائمًا.

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

لماذا تؤثر قابلية الترقية في مخاطر التوكن والبروتوكول

يمكن للعقود القابلة للترقية أن تؤثر مباشرةً في حاملي التوكنات، لأن منطق العقد قد يحدد السك والحرق وقيود التحويل والرسوم أو حقوق الحوكمة.

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

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

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

يمكن للجسور القابلة للترقية أن تؤثر في حفظ الأصول والتحقق من الرسائل ومنطق السحب.

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

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

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

مفاهيم خاطئة شائعة

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

في معظم تصميمات الوكيل، لا يُعدل كود الوكيل الأصلي، بل يُوجّه الوكيل إلى عقد تنفيذ مختلف.

ومفهوم خاطئ آخر هو أن قابلية الترقية سيئة دائمًا.

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

المفهوم الخاطئ الثالث هو أن التدقيق يلغي مخاطر الترقية.

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

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

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

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

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

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

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

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

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

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

هل العقود القابلة للترقية آمنة؟

يمكن أن تكون العقود القابلة للترقية آمنة عندما تستخدم تحكمًا قويًا في الوصول وإدارة دقيقة للتخزين وعمليات تدقيق ومراقبة وحوكمة شفافة.

ما الخطر الرئيسي للعقد القابل للترقية؟

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

ما هو عقد الوكيل؟

عقد الوكيل هو العقد الظاهر للمستخدمين الذي يخزن البيانات ويحول الاستدعاءات إلى عقد تنفيذ يحتوي على المنطق الحالي.

ما هو عقد التنفيذ؟

عقد التنفيذ هو عقد المنطق الذي يحدد كيفية عمل الوظائف عندما يفوض الوكيل الاستدعاءات إليه.

لماذا تستخدم العقود القابلة للترقية دوال التهيئة؟

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

ما هو تعارض التخزين؟

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

ما هو ERC-1967؟

ERC-1967 هو معيار يحدد خانات تخزين لمعلومات الوكيل، مثل عنوان التنفيذ وعنوان المسؤول وعنوان المنارة.

ما هو ERC-7201؟

ERC-7201 هو معيار لتخطيط التخزين ضمن مساحات الأسماء، يساعد في تنظيم متغيرات الحالة وتقليل تعارضات التخزين في العقود المعقدة القابلة للترقية.

هل يمكن للعقد القابل للترقية أن يصبح غير قابل للتغيير لاحقًا؟

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

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

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

الخلاصة

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

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

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

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

يمكن للمعايير والممارسات المهمة، مثل خانات تخزين الوكيل ERC-1967 والتخزين ضمن مساحات الأسماء ERC-7201 ودوال التهيئة وعمليات التدقيق والأقفال الزمنية وضوابط المسؤول الشفافة، تقليل هذه المخاطر.

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

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