---
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>

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

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

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

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

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

## آلية العمل

تضع Solidity متغيرات الحالة عادةً ابتداءً من الخانة `0` وبترتيب التصريح بعد خطية C3 للوراثة. قد تتشارك القيم الأصغر من 32 بايت خانة واحدة؛ وللبنى والمصفوفات قواعد إضافية، بينما تستمد الخرائط والمصفوفات الديناميكية مواقع بياناتها من خانة أساسية. وعند تحريك الخانة الأساسية تتغير مواقع البيانات المشتقة منها أيضًا.

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

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

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

## مثال

لنفترض أن الإصدار 1 يملك التخطيط التالي:

```solidity
uint256 totalAssets; // slot 0
address owner;       // slot 1
```

يدرج الإصدار 2 متغيرًا في البداية على نحو خاطئ:

```solidity
bool paused;         // slot 0, offset 0
uint256 totalAssets; // slot 1
address owner;       // slot 2
```

بعد الترقية يقرأ `paused` البايت الأدنى من `totalAssets` القديم، ويقرأ `totalAssets` الجديد كلمة `owner` القديمة كعدد صحيح، بينما يقرأ `owner` ما كان موجودًا في الخانة `2`، وغالبًا يكون صفرًا. تبقى الكلمات الأصلية في التخزين، لكن الشفرة الجديدة تمنحها معاني مختلفة. وقد تنجح المعاملة مع تطبيق التفويض أو المحاسبة على تفسيرات فاسدة للحالة.

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

## المخاطر وفحوص الترقية

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

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

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

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

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

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

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

- [مخاطر التخزين في delegatecall](/ar/crypto/delegatecall-storage-risk/)
- [الاستيلاء على دالة التهيئة](/ar/crypto/initializer-takeover/)
- [عقد الوكيل](/ar/crypto/proxy-contract/)
- [مراقبة ترقيات الوكيل](/ar/crypto/proxy-upgrade-monitoring/)
- [العقد القابل للترقية](/ar/crypto/upgradeable-contract/)

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

## المصادر

- [مقدمة إلى العقود الذكية](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html) - Solidity Documentation (تاريخ الاطلاع: 2026-08-21)
- [تخطيط متغيرات الحالة في التخزين](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html) - Solidity Documentation (تاريخ الاطلاع: 2026-08-21)
- [ERC-1967: خانات تخزين الوكيل](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (تاريخ الاطلاع: 2026-08-21)
- [كتابة العقود القابلة للترقية](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin Documentation (تاريخ الاطلاع: 2026-08-21)

Source: https://wiki.fcontext.com/ar/crypto/proxy-storage-collision/index.mdx