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

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

عقد الوكيل هو عقد وسيط يمرر الاستدعاءات إلى عقد آخر يُسمى عادة عقد التنفيذ أو عقد المنطق. في تصميم شائع لآلة EVM، يستخدم الوكيل `delegatecall`، فتعمل شيفرة التنفيذ ضمن سياق الوكيل بينما تبقى الحالة والأرصدة في عنوان الوكيل.

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

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

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

## آلية العمل

عندما يصل استدعاء إلى الوكيل، ينسخ مسار الاستقبال الاحتياطي بيانات الاستدعاء إلى تنفيذ أو يمررها إليه. مع `delegatecall` يكون `address(this)` هو الوكيل، وتؤثر قراءات التخزين وكتاباته في الوكيل، وتُحفظ القيم الأصلية لـ `msg.sender` و`msg.value`. ثم يعيد الوكيل بيانات التنفيذ أو يتراجع معه عن المعاملة.

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

تضع التصاميم الشائعة صلاحية الترقية في مواضع مختلفة:

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

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

## مثال

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

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

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

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

## المخاطر

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

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

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

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

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

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

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

- [مخاطر التخزين في Delegatecall](/ar/crypto/delegatecall-storage-risk/)
- [تصادم تخزين الوكيل](/ar/crypto/proxy-storage-collision/)
- [مراقبة ترقية الوكيل](/ar/crypto/proxy-upgrade-monitoring/)
- [العقد الذكي](/ar/crypto/smart-contract/)
- [العقد القابل للترقية](/ar/crypto/upgradeable-contract/)

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

## المصادر

- [مقدمة إلى العقود الذكية](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html) - Solidity Documentation (تاريخ الاطلاع: 2026-08-21)
- [ERC-1967: خانات تخزين الوكيل](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (تاريخ الاطلاع: 2026-08-21)
- [ERC-1822: معيار الوكيل العام القابل للترقية (UUPS)](https://eips.ethereum.org/EIPS/eip-1822) - Ethereum Improvement Proposals (تاريخ الاطلاع: 2026-08-21)
- [الوكيل](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin Documentation (تاريخ الاطلاع: 2026-08-21)

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