---
title: "كيفية مراقبة ترقيات عقود البروكسي"
description: "راقب تغييرات التنفيذ والمنارة والتحكم في عقود البروكسي القابلة للترقية، ثم تحقق بعد التنفيذ من الشفرة وتوافق التخزين والتهيئة والصلاحيات والسلوك الحرج."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

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

> لأغراض تعليمية فقط؛ لا يُعد نصيحة استثمارية. قد يؤدي الاستثمار إلى خسارة.

<a id="answer"></a>

## الإجابة المباشرة

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

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

<a id="mechanism"></a>

## آلية العمل

حدد نمط البروكسي أولا. يعرّف ERC-1967 خانات تخزين منفصلة لكل من `eip1967.proxy.implementation` و`eip1967.proxy.beacon` والخانة الاختيارية `eip1967.proxy.admin`. ينبغي أن تطلق تغييرات التنفيذ المباشرة الحدث `Upgraded`، وتغييرات عنوان المنارة `BeaconUpgraded`، وتغييرات خانة المسؤول `AdminChanged`. وفي بروكسي المنارة، استدع أيضا `implementation()` على المنارة، إذ يمكنها تغيير تنفيذها مع بقاء خانة المنارة في البروكسي دون تغيير.

لا تستنتج نموذج الصلاحيات الكامل من خانة المسؤول. قد يجري التحكم في بروكسي Transparent عبر `ProxyAdmin`، بينما تنفذ صلاحية ترقية UUPS داخل عقد المنطق الحالي بواسطة `_authorizeUpgrade`. تتبع المالكين والأدوار وحدود التوقيع المتعدد وأقفال الوقت والحوكمة ومسارات الطوارئ والقدرة على تغيير عناصر التحكم هذه.

استخدم الاشتراك في الأحداث والقراءات الدورية للحالة معا. يوصي ERC-1967 بالأحداث لكنه لا يلزم كل تنفيذ بإطلاقها. سجل السلسلة والكتلة والمعاملة والبروكسي والتنفيذ أو المنارة وبصمة شفرة التشغيل والمنفذ وحالة التحكم ذات الصلة من نقاط RPC مستقلة. نبّه عند جدولة العمليات أو إلغائها أو تنفيذها، وانتظر سياسة التأكيد أو النهائية المعتمدة للسلسلة قبل اعتبار الحالة مستقرة.

<a id="example"></a>

## مثال

يجري التحكم في بروكسي إقراض بتوقيع متعدد 3 من 5 عبر قفل زمني مدته 24 ساعة. عند جدولة ترقية، يسجل نظام المراقبة معرّف المقترح والهدف وcalldata وأقرب وقت للتنفيذ والتنفيذ الحالي والمقترح وحالة التحقق من الشفرة المصدرية. يقارن المراجعون الشفرة وتخطيطات التخزين، ويفحصون استدعاء التهيئة، ويراجعون تغييرات الأدوار والاستدعاءات الخارجية والرسوم وقواعد الإيقاف ومسارات السحب.

بعد التنفيذ، يعيد نظام المراقبة قراءة خانة ERC-1967 ذات الصلة، ويتحقق من شفرة التشغيل المنشورة، ويفحص الشروط اللاحقة المتوقعة مثل إصدار التنفيذ والمسؤولين أو حاملي الأدوار وحالة الإيقاف ومحاسبة الأصول ومعاينة السحب للقراءة فقط. ينطلق تنبيه آخر إذا اختلف العنوان أو بصمة الشفرة المرصودة عن المقترح المراجع، أو إذا كشف الاستطلاع الدوري تغييرا لم يبلغ عنه حدث.

<a id="risks"></a>

## المخاطر

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

إجراء التشغيل الأدنى:

1. احصر كل بروكسي ومنارة وتنفيذ ومسؤول ودور ونقطة دخول للترقية على كل سلسلة.
2. احفظ خط أساس سليم معروف للخانات وبصمات الشفرة وحالة التحكم والنتائج الحرجة للقراءة فقط.
3. أصدر تنبيها قبل التنفيذ عندما تسمح جدولة الحوكمة أو القفل الزمني، ثم أصدر تنبيها آخر عند التنفيذ أو الإلغاء.
4. قارن الهدف وcalldata والتنفيذ والبايت كود وتخطيط التخزين والحالة اللاحقة المنفذة بالمقترح المراجع.
5. صعّد التغييرات غير المتوقعة أو فشل الشروط اللاحقة أو غياب التحقق من المصدر أو تقصير التأخير أو تجاوزه؛ ولا تعتمد على ثبات عنوان البروكسي دليلا على الأمان.

<a id="misconceptions"></a>

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

- **الخرافة 1: «تكفي مراقبة `Upgraded`».** قد تتطلب تغييرات تنفيذ المنارة والبروكسيات غير القياسية مراقبة عقد آخر أو استطلاع الحالة؛ طابق الأحداث مع القراءات المباشرة.
- **الخرافة 2: «تكشف خانة المسؤول من يتحكم في كل ترقية».** الخانة اختيارية، وتضع تصميمات Transparent وUUPS والمنارة والحوكمة والتصميمات المخصصة الصلاحية في عقود ودوال مختلفة.
- **الخرافة 3: «تثبت الشفرة المصدرية المتحقق منها أو المراجعة السابقة أمان الترقية».** تحقق للإصدار نفسه من البايت كود المنشور وافتراضات المترجم والمنشئ وتوافق التخزين والتهيئة والإعداد والسلوك.

<a id="related"></a>

## موضوعات ذات صلة

- [مخاطر وحدة التوقيع المتعدد](/ar/crypto/multisig-module-risk/)
- [عقد البروكسي](/ar/crypto/proxy-contract/)
- [تعارض تخزين البروكسي](/ar/crypto/proxy-storage-collision/)
- [الإيقاف الطارئ للبروتوكول](/ar/crypto/protocol-emergency-pause/)
- [العقد القابل للترقية](/ar/crypto/upgradeable-contract/)

<a id="sources"></a>

## المصادر

- [ERC-1967: خانات تخزين البروكسي](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (تاريخ الاطلاع: 2026-08-21)
- [البروكسي](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin (تاريخ الاطلاع: 2026-08-21)
- [كتابة العقود القابلة للترقية](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin (تاريخ الاطلاع: 2026-08-21)
- [التحكم في الوصول](https://docs.openzeppelin.com/contracts/5.x/access-control) - OpenZeppelin (تاريخ الاطلاع: 2026-08-21)

Source: https://wiki.fcontext.com/ar/crypto/proxy-upgrade-monitoring/index.mdx