Rust العقود الذكية养成日记（9）合约升级

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

1. طرق الترقية الشائعة لعقود Solidity

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

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

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

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

!

2. طرق شائعة لترقية عقود NEAR

باستخدام مشروع StatusMessage كمثال، نقدم طرق الترقية الشائعة لعقود NEAR.

2.1 هيكل بيانات العقد لم يتم تغييره

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

تم تعديل بنية بيانات العقد 2.2

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

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

NEAR يوفر طريقة Migrate للمساعدة في ترقية العقود. أضف طريقة migrate في العقد الجديد:

صدأ #[private] #[init(ignore_state)] pub fn migrate() -> Self { let old_state: OldStatusMessage = env::state_read().expect('failed'); ذاتية { الشعارات: old_state.records, السير الذاتية: LookupMap::new(b'b'.to_vec()), } }

استدعاء طريقة migrate عند إعادة نشر العقد:

نشر قريبًا
--wasmFile target/wasm32-unknown-unknown/release/status_message.wasm
--initFunction 'ترحيل'
--initArgs '{}'
--accountId statusmessage.blocksec_upgrade.testnet

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

!

3. اعتبارات الأمان لترقية العقود

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

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

بالإضافة إلى ذلك، يمكن للمطورين عند إجراء ترحيل العقود النظر في النصائح التالية:

• أضف #[init(ignore_state)] قبل دالة الهجرة، تأكد من عدم تحميل الحالة قبل تنفيذ دالة الهجرة.
• بعد الانتهاء من الترحيل، احذف دالة الترحيل، وتأكد من أن دالة الترحيل قد تم استدعاؤها مرة واحدة فقط.
• تم الانتهاء من تهيئة الهيكلية البيانات الجديدة أثناء الترحيل.

!