تخطي إلى المحتوى الرئيسي
Change page

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

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

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

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

المتطلبات الأساسية

يجب أن يكون لديك فهم جيد لـ العقود الذكية، وتشريح العقد الذكي، وآلة إيثيريوم الافتراضية (EVM). يفترض هذا الدليل أيضًا أن القراء لديهم فهم لبرمجة العقود الذكية.

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

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

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

يمكن القيام بذلك عبر الطرق التالية:

  1. إنشاء إصدارات متعددة من عقد ذكي وترحيل الحالة (أي البيانات) من العقد القديم إلى مثيل جديد من العقد.

  2. إنشاء عقود منفصلة لتخزين منطق الأعمال والحالة.

  3. استخدام أنماط الوكيل لتفويض استدعاءات الدوال من عقد وكيل غير قابل للتغيير إلى عقد منطقي قابل للتعديل.

  4. إنشاء عقد رئيسي غير قابل للتغيير يتفاعل مع عقود تابعة مرنة ويعتمد عليها لتنفيذ دوال محددة.

  5. استخدام نمط الماسة لتفويض استدعاءات الدوال من عقد وكيل إلى عقود منطقية.

آلية الترقية رقم 1: ترحيل العقد

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

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

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

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

المزيد حول ترحيل العقد. (opens in a new tab)

آلية الترقية رقم 2: فصل البيانات

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

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

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

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

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

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

آلية الترقية رقم 3: أنماط الوكيل

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

هذا ما يحدث في نمط الوكيل:

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

  2. يخزن عقد وكيل عنوان العقد المنطقي ويفوض جميع استدعاءات الدوال إلى العقد المنطقي (الذي يحتفظ بمنطق الأعمال) باستخدام دالة delegatecall.

  3. بعد إعادة توجيه الاستدعاء إلى العقد المنطقي، يتم استرداد البيانات المرجعة من العقد المنطقي وإعادتها إلى المستخدم.

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

من وثائق Solidity (opens in a new tab):

يوجد متغير خاص من استدعاء رسالة، يسمى delegatecall وهو مطابق لاستدعاء رسالة باستثناء حقيقة أن التعليمات البرمجية في العنوان المستهدف يتم تنفيذها في سياق (أي في عنوان) العقد المستدعي ولا يغير msg.sender و msg.value قيمهما. هذا يعني أن العقد يمكنه تحميل التعليمات البرمجية ديناميكيًا من عنوان مختلف في وقت التشغيل. لا يزال التخزين والعنوان الحالي والرصيد يشيرون إلى العقد المستدعي، ويتم أخذ التعليمات البرمجية فقط من العنوان المستدعى.

يعرف عقد وكيل استدعاء delegatecall كلما استدعى المستخدم دالة لأنه يحتوي على دالة fallback مدمجة فيه. في برمجة Solidity، يتم تنفيذ دالة احتياطية (opens in a new tab) عندما لا يتطابق استدعاء دالة مع الدوال المحددة في العقد.

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

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

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

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

المزيد حول أنماط الوكيل (opens in a new tab).

آلية الترقية رقم 4: نمط الاستراتيجية

تتأثر هذه التقنية بـ نمط الاستراتيجية (opens in a new tab)، والذي يشجع على إنشاء برامج برمجية تتفاعل مع برامج أخرى لتنفيذ ميزات محددة. تطبيق نمط الاستراتيجية على تطوير إيثيريوم يعني بناء عقد ذكي يستدعي دوال من عقود أخرى.

يحتوي العقد الرئيسي في هذه الحالة على منطق الأعمال الأساسي، ولكنه يتفاعل مع عقود ذكية أخرى ("عقود تابعة") لتنفيذ دوال معينة. يخزن هذا العقد الرئيسي أيضًا عنوان كل عقد تابع ويمكنه التبديل بين التطبيقات المختلفة للعقد التابع.

يمكنك بناء عقد تابع جديد وتكوين العقد الرئيسي بالعنوان الجديد. يتيح لك ذلك تغيير الاستراتيجيات (أي تنفيذ منطق جديد) لعقد ذكي.

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

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

آلية الترقية رقم 5: نمط الماسة

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

تُعرف العقود المنطقية في نمط الماسة باسم الأوجه (facets). لجعل نمط الماسة يعمل، تحتاج إلى إنشاء تعيين في عقد وكيل يربط محددات الدوال (opens in a new tab) بعناوين أوجه مختلفة.

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

يتمتع نمط ترقية الماسة ببعض المزايا مقارنة بأنماط ترقية الوكيل التقليدية:

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

  2. جميع العقود الذكية (بما في ذلك العقود المنطقية المستخدمة في أنماط الوكيل) لها حد أقصى للحجم يبلغ 24KB، والذي يمكن أن يكون قيدًا — خاصة بالنسبة للعقود المعقدة التي تتطلب المزيد من الدوال. يجعل نمط الماسة من السهل حل هذه المشكلة عن طريق تقسيم الدوال عبر عقود منطقية متعددة.

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

المزيد حول نمط الماسة (opens in a new tab).

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

الإيجابياتالسلبيات
يمكن أن تجعل ترقية العقد الذكي من الأسهل إصلاح الثغرات المكتشفة في مرحلة ما بعد النشر.تتعارض ترقية العقود الذكية مع فكرة عدم القابلية للتغيير للتعليمات البرمجية، مما له آثار على اللامركزية والأمان.
يمكن للمطورين استخدام ترقيات المنطق لإضافة ميزات جديدة إلى التطبيقات اللامركزية.يجب على المستخدمين الوثوق بالمطورين لعدم تعديل العقود الذكية بشكل تعسفي.
يمكن أن تؤدي ترقيات العقود الذكية إلى تحسين الأمان للمستخدمين النهائيين حيث يمكن إصلاح الأخطاء بسرعة.تضيف برمجة وظائف الترقية في العقود الذكية طبقة أخرى من التعقيد وتزيد من احتمالية وجود عيوب حرجة.
تمنح ترقيات العقد المطورين مساحة أكبر لتجربة ميزات مختلفة وتحسين التطبيقات اللامركزية (dapps) بمرور الوقت.قد تشجع فرصة ترقية العقود الذكية المطورين على إطلاق المشاريع بشكل أسرع دون بذل العناية الواجبة خلال مرحلة التطوير.
يمكن أن يسهل التحكم غير الآمن في الوصول أو المركزية في العقود الذكية على الجهات الخبيثة إجراء ترقيات غير مصرح بها.

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

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

  2. تعد ترقية العقود الذكية نشاطًا معقدًا وتتطلب مستوى عاليًا من العناية لمنع إدخال الثغرات.

  3. قلل افتراضات الثقة عن طريق جعل عملية تنفيذ الترقيات لامركزية. تشمل الاستراتيجيات الممكنة استخدام عقد محفظة متعددة التوقيعات للتحكم في الترقيات، أو اشتراط تصويت أعضاء منظمة مستقلة لامركزية (DAO) على الموافقة على الترقية.

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

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

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

الموارد

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

دروس تعليمية

قراءة إضافية