---
title: "هل توقيع تفويض الحوكمة آمن؟"
description: "تعرّف إلى ما يصرّح به توقيع تفويض الحوكمة، وكيف يقلّل فصل النطاق وفق EIP-712 والأرقام التسلسلية وانتهاء الصلاحية مخاطر إعادة الاستخدام، وما ينبغي التحقق منه قبل التوقيع."
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>

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

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

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

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

## آلية العمل

يتكوّن تدفق `delegateBySig` الشائع من أربع خطوات:

1. يُعدّ التطبيق بيانات EIP-712 معرّفة بأنواع تتضمن عنوان المفوَّض إليه، ورقمًا تسلسليًا، ووقت انتهاء الصلاحية.
2. توقّع المحفظة ملخصًا مشفّرًا مرتبطًا بالرسالة المعرّفة وبنطاق EIP-712.
3. يمكن لأي حساب ترحيل التوقيع إلى عقد الرمز أو عقد الحوكمة.
4. يستخرج العقد الموقّع أو يتحقق منه، ويتحقق من الرقم التسلسلي وانتهاء الصلاحية، ثم يسجّل المفوَّض إليه الجديد.

يمكن أن يتضمن نطاق EIP-712 الحقول `name` و`version` و`chainId` و`verifyingContract`. تفصل هذه الحقول الرسائل المتطابقة في ما عدا ذلك بين التطبيقات والإصدارات والشبكات والعقود. ينص معيار EIP-712 نفسه صراحةً على أنه **لا** يوفر حماية من إعادة الاستخدام؛ فعلى العقد استهلاك رقم تسلسلي أو جعل كل تصريح صالحًا لمرة واحدة بطريقة أخرى، ولا يحد انتهاء الصلاحية النافذة الزمنية إلا إذا كان العقد يتحقق منه فعلًا.

قبل التوقيع، تحقق من كل ما يلي بالرجوع إلى واجهة الحوكمة الرسمية أو الوثائق أو بيانات العقد المتحقق منها بصورة مستقلة:

- يجب أن يصف `primaryType` وأسماء الحقول التفويض، لا تصريح إنفاق أو نقل رموز أو أمرًا أو إذنًا لإدارة الحساب.
- يجب أن يكون `verifyingContract` هو عقد الرمز أو الحوكمة المقصود على `chainId` النشطة.
- يجب أن يكون `delegatee` عنوان الممثل الذي اخترته، مع التحقق من العنوان كاملًا بدلًا من اسم العرض.
- يجب أن يطابق `nonce` الرقم التسلسلي الحالي للموقّع في العقد، وأن يكون `expiry` قصيرًا بما يناسب الإجراء المقصود.
- ينبغي أن تعرض المحفظة البيانات المعرّفة بأنواع كاملة. ارفض طلبات التوقيع الأعمى أو الملخصات الخام التي لا تستطيع إعادة إنتاج معناها بصورة مستقلة.

تختلف التطبيقات. فعقد COMP لدى Compound، على سبيل المثال، يجزّئ بيانات المفوَّض إليه والرقم التسلسلي وانتهاء الصلاحية، ويشترط مساواة الرقم التسلسلي للقيمة المخزنة للموقّع، ثم يزيده ويرفض التوقيع المنتهي. وتعرض واجهة `Votes` لدى OpenZeppelin أيضًا `delegateBySig` ومعالجة الأرقام التسلسلية وفحوص انتهاء الصلاحية. لا تفترض أن دالة تحمل اسمًا مشابهًا في عقد آخر توفر وسائل الحماية نفسها.

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

## مثال

تعتزم ميرا تفويض 10,000 صوت إلى العنوان `0xAB...1234`. تعرض محفظتها `primaryType: Delegation` وعقد رمز التصويت المتحقق منه ومعرّف السلسلة النشطة و`delegatee: 0xAB...1234` والرقم التسلسلي الحالي ووقت انتهاء بعد 20 دقيقة. بعد التحقق من العنوان عبر مصدر موثوق ثانٍ، توقّع ميرا؛ فترسل جهة ترحيل الرسالة، ويصدر العقد حدث التفويض. يبقى رصيد رموزها في محفظتها، بينما يحصل الممثل على قوة التصويت المرتبطة وفق قواعد ذلك البروتوكول.

والآن غيّر تفصيلًا واحدًا: تطلب الصفحة `primaryType: Permit` وتذكر جهةً منفقة للرموز، أو يكون `verifyingContract` عقدًا غير ذي صلة. هذه ليست تعليمة التفويض نفسها، وقد تمنح بدلًا من ذلك صلاحية إنفاق الرموز، حتى لو كان زر الصفحة يحمل كلمة "تفويض" ولم يدفع الموقّع رسوم غاز. ينبغي لميرا رفضها.

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

## المخاطر والضوابط

- **المفوَّض إليه الخاطئ:** قد يستبدل تسميم العناوين والرسائل الخاصة وأسماء العرض المنسوخة `delegatee` بعنوان يتحكم فيه مهاجم. تحقق من العنوان كاملًا عبر مقترح رسمي أو ملف الممثل.
- **الإجراء الخاطئ:** قد تطلب واجهة خبيثة نوع EIP-712 آخر مثل تصريح إنفاق. اقرأ `primaryType` وكل حقل والعقد المتحقق؛ فلا قيمة أمنية لنص الزر.
- **إعادة الاستخدام:** قد تسمح فحوص الرقم التسلسلي الضعيفة أو المفقودة بإعادة استخدام التوقيع. وقد يسمح نطاق غير مرتبط بالسلسلة أو العقد المقصودين باستخدامه في سياق غير مقصود. تحقق من شيفرة التحقق الفعلية، لأن EIP-712 وحده لا يمنع إعادة الاستخدام.
- **توقيع طويل الأجل:** قد تظل رسالة موقّعة غير مستخدمة قابلة للتنفيذ إلى أن تنتهي صلاحيتها أو يصبح رقمها التسلسلي غير صالح. فضّل صلاحية قصيرة، ولا تنشر التوقيع، واستخدم فقط طريقة الإبطال الموثقة لدى البروتوكول عند الحاجة إلى الإلغاء.
- **عرض محفظة مضلل:** تمنع الحقول المقتطعة أو النطاق المجهول أو التوقيع الأعمى الموافقة المستنيرة. ألغِ الطلب وافحص طلب البيانات المعرّفة بأنواع بمحفظة أو أداة فك ترميز تعرض الرسالة كاملة.
- **اختلاف حسابات العقود:** قد تتحقق محافظ العقود الذكية من التوقيعات عبر ERC-1271، حيث يمكن أن تعتمد الصلاحية على حالة المحفظة وسياسة التفويض. تأكد من دعم المحفظة وعقد الحوكمة معًا بدل افتراض الاسترداد بالطريقة الخاصة بالحسابات الخارجية.
- **عواقب الحوكمة:** قد يركّز التفويض قوة التصويت أو يمكّن ممثلًا غير موثوق من التصويت خلافًا لمصالحك. راجع هوية الممثل وسجل تصويته وتعارضاته وآلية إعادة التفويض في البروتوكول.

بعد الإرسال، تحقق من المعاملة على السلسلة الصحيحة: افحص العقد الوجهة، والدالة المفكوكة، والموقّع المستخرج أو المبلّغ عنه في الحدث، والمفوَّض إليه الجديد، والرقم التسلسلي. لا تثبت معاملة ترحيل ناجحة سوى أن العقد قبل الاستدعاء؛ ولا تثبت أن القصد الموقّع كان آمنًا.

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

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

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

- **"عدم دفع الغاز يعني عدم منح صلاحية."** يمكن لجهة الترحيل دفع الغاز بينما يوفر التوقيع تصريح الموقّع.
- **"يجعل EIP-712 كل توقيع آمنًا."** يوحّد المعيار تجزئة البيانات المعرّفة بأنواع وفصل النطاق، لكنه لا يتضمن حماية من إعادة الاستخدام ولا يستطيع التحقق من أن المستخدم قصد الإجراء المعروض.
- **"ينقل التفويض رموزي."** ينقل تفويض التصويت التقليدي قوة التصويت أو يخصصها، لا ملكية الرموز، لكن العقد المنشور والرسالة المفكوكة وحدهما يحددان الأثر الفعلي.
- **"يمكنني دائمًا إلغاء توقيع أُنشئ خارج السلسلة."** لا توجد معاملة عامة لإلغاء التوقيعات. انتهاء الصلاحية واستهلاك الرقم التسلسلي أو إبطاله وإعادة التفويض آليات خاصة بكل عقد.
- **"تغيير الممثل يمحو الأصوات السابقة."** تغيّر إعادة التفويض قوة التصويت المستقبلية أو الحالية وفق قواعد البروتوكول؛ وقد لا تلغي الأصوات التي أُدلي بها أو تغيّر اللقطات التاريخية.

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

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

- [توقيع EIP-712 المهيكل](/ar/crypto/eip712-typed-signature/)
- [المنظمة اللامركزية المستقلة (DAO)](/ar/crypto/dao/)
- [هجوم الحوكمة](/ar/crypto/governance-attack/)
- [تفويض المحفظة](/ar/crypto/wallet-approval/)
- [توقيع المحفظة](/ar/crypto/wallet-signature/)

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

## المصادر

- [EIP-712: تجزئة البيانات المهيكلة المعرّفة بأنواع وتوقيعها](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (تاريخ الاطلاع: 2026-08-20)
- [Comp.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/Comp.sol) - Compound Finance (تاريخ الاطلاع: 2026-08-20)
- [واجهة برمجة تطبيقات الحوكمة](https://docs.openzeppelin.com/contracts/5.x/api/governance) - OpenZeppelin (تاريخ الاطلاع: 2026-08-20)
- [ERC-1271: الطريقة القياسية للتحقق من توقيعات العقود](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (تاريخ الاطلاع: 2026-08-20)

Source: https://wiki.fcontext.com/ar/crypto/governance-delegation-signature-risk/index.mdx