عقد Proxy

ما عقد Proxy؟

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

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

يُسمى العقد الذي يتفاعل معه المستخدمون عادةً Proxy.

أما العقد الذي يحتوي على المنطق الحالي فيُسمى عادةً عقد التنفيذ أو عقد المنطق أو النسخة الرئيسية.

يوضح نمط ترقية Proxy من OpenZeppelin أن قابلية الترقية المعتمدة على Proxy تعمل عبر فصل تخزين العقد عن منطقه.

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

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

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

يواصل المستخدمون والمحافظ والتطبيقات التفاعل مع عنوان Proxy، بينما يمكن تغيير المنطق الكامن وراءه.

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

لماذا تُستخدم عقود Proxy؟

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

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

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

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

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

يتيح عقد Proxy بقاء العنوان الذي يتعامل معه المستخدم ثابتًا.

وهذا مهم لبروتوكولات DeFi ومجموعات NFT وDAOs وعقود التوكنات والجسور وأنظمة Staking وأصول الألعاب ومحافظ تجريد الحسابات.

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

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

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

آلية عمل عقد Proxy

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

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

بل يوجّه الاستدعاء إلى عقد التنفيذ باستخدام آلية منخفضة المستوى في EVM مثل

.

تُنفذ شيفرة عقد التنفيذ، لكن التخزين الذي يتغير هو تخزين Proxy.

وهذه هي النقطة الأساسية التي تتيح أنظمة Proxy القابلة للترقية.

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

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

إذا جرت ترقية النظام، يُنشر عقد تنفيذ جديد بمنطق محدث.

ثم يحدّث Proxy المؤشر الذي يشير إلى عقد التنفيذ الجديد.

يظل العنوان الذي يتعامل معه المستخدمون والبيانات المخزنة في Proxy، بينما تستخدم الاستدعاءات المستقبلية المنطق الجديد.

عقد Proxy وdelegatecall

تُعد

الآلية منخفضة المستوى التي تشغّل كثيرًا من عقود Proxy.

في الاستدعاء الخارجي العادي، يستدعي عقدٌ عقدًا آخر، ويستخدم العقد المُستدعى مساحة تخزينه الخاصة.

أما مع

، فتعمل شيفرة العقد المُستدعى ضمن سياق تخزين العقد الذي يجري الاستدعاء.

وهذا يعني في حالة Proxy أن شيفرة عقد التنفيذ تستطيع تعديل مساحة تخزين Proxy.

هذه الآلية قوية لأنها تتيح لـProxy الاحتفاظ بالحالة مع تغيير شيفرة التنفيذ المستخدمة.

كما أنها خطرة لأن شيفرة عقد التنفيذ يجب أن تراعي ترتيب التخزين الخاص بـProxy.

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

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

يحذر تحذير SWC-112 بشأن delegatecall المطورين من ضرورة استخدام

بحذر وتجنب استدعاء العقود غير الموثوقة.

في أنظمة Proxy، ليست

مجرد تفصيل تقني، بل تقع في صميم نموذج الأمان.

عقد Proxy مقابل عقد التنفيذ

لعقد Proxy وعقد التنفيذ مسؤوليتان مختلفتان.

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

أما عقد التنفيذ فيحتوي على الوظائف والقواعد التي تحدد كيفية تغيير الحالة.

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

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

ثم يُرقّى Proxy للإشارة إلى عقد التنفيذ الجديد.

يبقى عنوان Proxy كما هو، فلا يحتاج المستخدمون وعمليات التكامل إلى الانتقال إلى عنوان جديد.

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

إذا كان مفتاح خاص واحد يتحكم في مسؤول Proxy، فقد يتمتع ذلك المفتاح بصلاحيات واسعة جدًا على العقد.

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

عقد Proxy مقابل العقد الذكي العادي

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

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

أما النظام القائم على Proxy، فيفصل التخزين عن المنطق عبر عقدين على الأقل.

يخزن Proxy الحالة ويوجه الاستدعاءات.

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

وهذا يجعل نظام Proxy أكثر مرونة من العقد العادي.

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

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

أما عقد Proxy فيتطلب من المستخدمين والمدققين فحص ما وراء Proxy لمعرفة عقد التنفيذ النشط.

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

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

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

تتيح العقود القابلة للترقية للمطورين تغيير المنطق بعد النشر دون تغيير عنوان Proxy.

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

لكن قابلية الترقية تغيّر نموذج الثقة.

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

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

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

تجعل التصاميم الأكثر أمانًا سلطة الترقية شفافة وأصعب استغلالًا.

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

ومن دون ضوابط قوية، قد يتحول عقد Proxy إلى باب خلفي خفي للوصول إلى أموال المستخدمين.

معيار ERC-1967 لعقود Proxy

يُعد ERC-1967 معيارًا واسع الاستخدام لخانات تخزين Proxy.

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

يهدف ذلك إلى منع تعارض التخزين بين Proxy وعقد التنفيذ.

يحدث تعارض التخزين عندما يستخدم متغيران خانة التخزين نفسها عن غير قصد.

وقد يكون ذلك خطرًا للغاية في أنظمة Proxy، لأن تخزين Proxy ومنطق عقد التنفيذ يتفاعلان عبر

.

يساعد ERC-1967 أيضًا مستكشفي البلوكشين وأدوات المطورين على تحديد عقد التنفيذ النشط وراء Proxy.

وهذا يجعل فحص أنظمة Proxy وتدقيقها أسهل.

تستخدم أنماط Proxy الشائعة القابلة للترقية خانات ERC-1967.

لكن استخدام معيار معروف لا يجعل Proxy آمنًا تلقائيًا.

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

Proxy شفاف

الـProxy الشفاف نمط Proxy يفصل استدعاءات المسؤول عن استدعاءات المستخدمين.

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

يستطيع المسؤول تنفيذ إجراءات الترقية، لكن يُمنع عادةً من استدعاء وظائف عقد التنفيذ عبر Proxy عن طريق الخطأ.

يساعد هذا التصميم على تجنب تعارض محددات الوظائف بين وظائف مسؤول Proxy ووظائف عقد التنفيذ.

تدرج وثائق Proxy من OpenZeppelin العقد

بوصفه Proxy يتضمن واجهة مدمجة للمسؤول والترقية.

تشيع Proxies الشفافة لأن منطق الترقية يقع بوضوح في جانب Proxy من النظام.

لكن قد يكون العبء الإضافي فيها أعلى قليلًا من نماذج Proxy الأخف.

كما تتطلب إدارة دقيقة لمسؤول Proxy.

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

لا يكون Proxy الشفاف آمنًا إلا بقدر أمان شيفرة التنفيذ وأمن المسؤول.

Proxy من نوع UUPS

يرمز UUPS إلى المعيار العام القابل للترقية (Universal Upgradeable Proxy Standard).

يصف معيار ERC-1822 الخاص بـUUPS تصميم Proxy تُدار فيه توافقية الترقية من خلال منطق عقد التنفيذ.

في تصميم UUPS، يمكن أن يكون Proxy أخف لأن وظيفة الترقية موجودة في عقد التنفيذ بدلًا من واجهة مسؤول ثقيلة ضمن Proxy.

قد يقلل ذلك تكلفة النشر وتعقيد Proxy.

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

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

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

تتضمن أدوات OpenZeppelin الخاصة بـUUPS وسائل حماية تحد من فقدان قابلية الترقية عن طريق الخطأ، لكن المطورين يظلون بحاجة إلى مراجعة دقيقة.

تتميز Proxies من نوع UUPS بالمرونة والكفاءة.

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

Beacon Proxy

Beacon Proxy هو Proxy يحصل على عنوان عقد التنفيذ من عقد Beacon منفصل.

بدلًا من تخزين كل Proxy عنوان عقد التنفيذ الخاص به، يمكن لعدد كبير من Proxies الإشارة إلى Beacon واحد.

عند ترقية Beacon، يمكن لجميع Proxies التي تستخدمه بدء استخدام عقد التنفيذ الجديد.

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

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

يمكن لـBeacon Proxy تبسيط الترقيات الجماعية.

لكنه قد يزيد المخاطر أيضًا، لأن ترقية Beacon واحدة قد تؤثر في كثير من مثيلات Proxy دفعة واحدة.

يجب حماية مسؤول Beacon بعناية.

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

تتسم Beacon Proxies بالكفاءة عند إدارة مجموعات كبيرة من العقود، لكنها تركز سلطة الترقية في Beacon.

Proxy بسيط وERC-1167

الـProxy البسيط عقد Proxy صغير جدًا، صُمم لاستنساخ سلوك عقد تنفيذ آخر بتكلفة نشر منخفضة.

يحدد معيار ERC-1167 للـProxy البسيط نمطًا مختصرًا من الشيفرة الثنائية لإنشاء نسخ منخفضة التكلفة توجه الاستدعاءات إلى عقد تنفيذ ثابت.

غالبًا ما تُسمى Proxies البسيطة نسخًا مستنسخة.

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

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

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

ليس كل Proxy بسيط قابلًا للترقية.

تشير نسخ كثيرة من ERC-1167 إلى عقد تنفيذ ثابت، ولا يمكن تغيير وجهتها إلا إذا أُضيف منطق ترقية آخر في مكان مختلف.

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

تجمع بعض الأنظمة بين الفكرتين، لكن ينبغي عدم الخلط بينهما.

تخطيط التخزين في عقود Proxy

يُعد تخطيط التخزين من أهم موضوعات تصميم عقود Proxy.

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

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

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

وقد يؤدي ذلك إلى تعطيل العقد أو إنشاء ثغرات أمنية.

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

تُستخدم فجوات التخزين أحيانًا لحجز مساحة للمتغيرات المستقبلية.

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

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

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

التهيئة في عقود Proxy

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

لا يعمل المُنشئ إلا عند نشر عقد التنفيذ.

لكن المستخدمين في نظام Proxy يتفاعلون مع Proxy، ويجب تهيئة مساحة تخزين Proxy.

لذلك تُنفذ عادةً إجراءات الإعداد عبر وظيفة تهيئة تُستدعى من خلال Proxy.

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

إذا أُهملت التهيئة، فقد يبقى Proxy غير محمي.

إذا استدعى مهاجم وظيفة التهيئة أولًا، فقد يصبح المالك أو المسؤول.

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

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

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

مسؤول Proxy وسلطة الترقية

مسؤول Proxy هو الحساب أو العقد الذي يستطيع ترقية عقد التنفيذ الخاص بـProxy.

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

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

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

إذا سُرق مفتاح المسؤول، فقد يتمكن المهاجم من استبدال عقد التنفيذ.

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

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

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

وقد تقلل المحفظة متعددة التوقيعات خطر المفتاح الواحد، إذ تتطلب توقيع عدة أطراف.

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

عقد Proxy ومستكشفات البلوكشين

غالبًا ما تساعد مستكشفات البلوكشين المستخدمين على فحص عقود Proxy.

قد يوضح المستكشف الجيد أن العنوان Proxy، ويحدد عنوان عقد التنفيذ الحالي.

وقد يعرض أيضًا معلومات مسؤول Proxy إذا كان يتبع معيارًا معروفًا مثل ERC-1967.

يساعد ذلك المستخدمين والمدققين على مراجعة الشيفرة التي تُنفذ فعليًا.

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

وقد يؤدي ذلك إلى ثقة زائفة، لأن Proxy قد يحتوي على قدر ضئيل جدًا من شيفرة التطبيق الظاهرة.

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

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

قد لا ينطبق تدقيق قديم إذا رُقّي Proxy إلى منطق جديد.

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

عقد Proxy وعقود التوكنات

تستخدم عقود توكنات كثيرة Proxies لدعم الترقيات المستقبلية.

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

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

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

فمثلًا، قد تضيف الترقية قيودًا على التحويل أو تغير الرسوم أو تضيف صلاحيات الإيقاف المؤقت أو تعدل ضوابط الوصول.

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

كما ينبغي لهم معرفة الجهة التي تتحكم في الترقيات وما إذا كانت الحوكمة تؤخر التغييرات.

وجود Proxy في عقد التوكن لا يعني أنه غير آمن تلقائيًا.

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

السؤال المهم هو ما إذا كانت سلطة الترقية شفافة ومحمية جيدًا.

عقد Proxy وبروتوكولات DeFi

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

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

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

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

لكن قابلية الترقية تخلق مخاطر نظامية أيضًا.

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

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

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

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

تحسن عقود Proxy قابلية صيانة DeFi، لكنها تزيد أهمية الحوكمة.

عقد Proxy وNFTs

قد تستخدم مشاريع NFT عقود Proxy لجعل منطق البيانات الوصفية أو السك أو تكامل السوق أو الإتاوات أو أنظمة Staking أو آليات الألعاب قابلًا للترقية.

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

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

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

لكن الأمر قد يثير الجدل عندما يتوقع جامعو المقتنيات قواعد ثابتة أو بيانات وصفية دائمة.

ينبغي لمشتري NFT التحقق مما إذا كان العقد قابلًا للترقية وما إذا كان يمكن تغيير البيانات الوصفية.

كما ينبغي لهم التحقق من الجهة التي تتحكم في مسؤول الترقية.

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

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

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

عقد Proxy وDAOs

قد تستخدم DAOs عقود Proxy لترقية وحدات الحوكمة أو أدوات الخزينة أو أنظمة التصويت أو عقود Staking أو معلمات البروتوكول.

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

لكن حوكمة DAO لا تجعل الترقيات آمنة تلقائيًا.

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

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

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

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

قد تساعد عقود Proxy DAOs على التكيف بمرور الوقت.

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

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

فوائد عقود Proxy

الفائدة الأولى لعقد Proxy هي قابلية الترقية.

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

الفائدة الثانية هي استمرارية الحالة.

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

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

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

الفائدة الرابعة هي تقليل صعوبات الانتقال.

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

الفائدة الخامسة هي كفاءة الغاز في أنماط النسخ.

يمكن لـProxies البسيطة نشر عقود كثيرة متشابهة بتكلفة أقل من نشر الشيفرة الكاملة في كل مرة.

الفائدة السادسة هي البنية المعيارية.

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

لا تكون هذه الفوائد ذات قيمة إلا إذا صُممت عقود Proxy ودُققت وحُوكمت ورُصدت بعناية.

مخاطر عقود Proxy

الخطر الأول هو الترقيات الخبيثة.

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

الخطر الثاني هو تعارض التخزين.

إذا كان تخطيط التخزين غير صحيح، فقد تؤدي الترقية إلى إتلاف حالة مهمة في العقد.

الخطر الثالث هو فشل التهيئة.

قد يتيح Proxy أو عقد تنفيذ غير مهيأ للمهاجم السيطرة عليه.

الخطر الرابع هو تعارض محددات الوظائف.

قد تتعارض وظائف مسؤول Proxy مع وظائف عقد التنفيذ إذا كان النمط سيئ التصميم.

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

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

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

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

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

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

الخطر الثامن هو سوء فهم الأدوات.

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

كيفية التحقق من عقد Proxy قبل التفاعل معه

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

وينبغي لهم البحث عن عنوان عقد التنفيذ الحالي.

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

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

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

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

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

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

ينبغي لهم تجنب افتراض أن العقد غير قابل للتغيير لمجرد أن عنوان Proxy لم يتغير.

عند إيداع مبالغ كبيرة، ينبغي للمستخدمين اعتبار مراجعة Proxy جزءًا من إجراءات العناية الواجبة المعتادة.

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

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

ينبغي لهم اتباع معايير مثل ERC-1967 عند الاقتضاء كي تتمكن الأدوات من فحص حالة Proxy.

ينبغي لهم حماية وظائف الترقية بضوابط وصول قوية.

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

ينبغي لهم كتابة وظائف التهيئة بعناية ومنع تكرار التهيئة.

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

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

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

ينبغي لهم نشر إعلانات الترقيات وعمليات التدقيق والشروحات التقنية قبل إجراء تغييرات كبرى.

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

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

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

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

كما ينبغي لهم التحقق مما إذا كانت الترقيات مؤجلة عبر قفل زمني.

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

ينبغي لهم توخي الحذر إذا كان مسؤول Proxy خاضعًا لسيطرة محفظة واحدة مجهولة.

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

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

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

ينبغي لهم تذكر أن الترقية قد تغير السلوك المستقبلي حتى لو بدا السلوك السابق آمنًا.

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

مفاهيم خاطئة شائعة عن عقود Proxy

من المفاهيم الخاطئة أن عقد Proxy غير آمن تلقائيًا.

قد يكون عقد Proxy آمنًا عند استخدام نمط مجرّب وضوابط وصول جيدة وحوكمة قوية وعمليات تدقيق وترقيات شفافة.

ومن المفاهيم الخاطئة الأخرى أن عقد Proxy آمن تلقائيًا لأنه يستخدم إطارًا شائعًا.

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

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

في الواقع، يوجد منطق التطبيق المهم غالبًا في عقد التنفيذ.

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

إذا رُقّي Proxy، فقد لا يشمل التدقيق القديم عقد التنفيذ الجديد.

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

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

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

ما معنى عقد Proxy؟

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

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

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

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

كثير من عقود Proxy قابلة للترقية، لكن ليس كلها، إذ تشير بعض Proxies البسيطة إلى منطق ثابت.

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

عقد التنفيذ هو العقد الذي يحتوي على المنطق الذي ينفذه Proxy عبر التوجيه أو

.

ما delegatecall في عقد Proxy؟

عملية في EVM تتيح لـProxy تنفيذ شيفرة عقد التنفيذ مع استخدام سياق التخزين الخاص بـProxy.

ما ERC-1967؟

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

ما Proxy الشفاف؟

Proxy الشفاف نمط قابل للترقية يفصل استدعاءات ترقية المسؤول عن استدعاءات المستخدمين العادية للحد من مخاطر تعارض الوظائف.

ما Proxy من نوع UUPS؟

Proxy من نوع UUPS نمط قابل للترقية تُدار فيه آلية الترقية في عقد التنفيذ بدلًا من وجودها أساسًا في Proxy.

ما Beacon Proxy؟

يحصل Beacon Proxy على عنوان عقد التنفيذ من عقد Beacon، ما يتيح ترقية Proxies كثيرة معًا عن طريق تغيير Beacon.

ما Proxy البسيط؟

Proxy البسيط عقد نسخة صغير، يعتمد غالبًا على ERC-1167، ويوجه الاستدعاءات إلى منطق تنفيذ مشترك لتقليل تكلفة النشر.

هل تنطوي عقود Proxy على مخاطر؟

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

كيف يمكنني التحقق مما إذا كان العقد Proxy؟

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

الخلاصة

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

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

يستقبل Proxy الاستدعاءات ويحفظ التخزين ويوجه التنفيذ إلى عقد التنفيذ، غالبًا عبر

.

تساعد معايير مثل ERC-1967 وERC-1822 وERC-1167 على تنظيم تصاميم Proxy الشائعة، ومنها Proxies الشفافة وUUPS وBeacon وProxies البسيطة.

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

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

ينبغي للمطورين التعامل مع عقد Proxy بوصفه مكوّنًا معماريًا عالي المخاطر يتطلب تصميمًا واختبارًا وضوابط وصول وتوثيقًا علنيًا بعناية.

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

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

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