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

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

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

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

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

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

## آلية العمل

1. **جرد الصلاحيات الحالية.** انطلاقاً من سلسلة وعنوان حساب جرى التحقق منهما بشكل مستقل، اقرأ التطبيق المنشور وقائمة المالكين والحد وnonce والوحدات المفعلة وguards وfallback handler ومسار الاسترداد وأي timelock. قد تنفذ وحدة أو آلية استرداد خارج حد المالكين المعتاد، بينما قد يمنع guard مقيّد تدويراً صالحاً بخلاف ذلك.
2. **تحديد الحالة المستهدفة قبل التوقيع.** سجّل مجموعة المالكين والحد بدقة بعد التغيير. تأكد من أن الحد لا يتجاوز عدد المالكين وأن عدداً مساوياً له على الأقل من الموقّعين المستقلين سيظل عاملاً. لا يعني الفصل الجغرافي الاستقلال إذا كان شخص واحد أو خزنة كلمات مرور أو حساب سحابي أو مسؤول واحد يسيطر على كل الأجهزة.
3. **تسجيل الموقّع الجديد ومصادقته.** أنشئ المفتاح الجديد أو استعده في بيئة الحفظ المقررة، وتحقق من العنوان على جهاز موثوق، وأثبت السيطرة عبر تحدّ متفق عليه أو توقيع اختباري. أكّد العنوان عبر قناة ثانية موثّقة؛ ولا تعتمد على نص منسوخ من محادثة أو على واجهة المحفظة وحدها.
4. **اختيار ترتيب ذي حالات وسيطة آمنة.** تستطيع بعض العقود استبدال مالك بصورة ذرية. على سبيل المثال، يوفّر Safe الدالة `swapOwner`؛ كما يوفّر `addOwnerWithThreshold` و`removeOwner` و`changeThreshold`. إذا احتاج تطبيق إلى معاملات متعددة، فحلّل مجموعة المالكين والحد بعد كل خطوة. أضف القدرة وتحقق منها قبل إزالتها، إلا إذا جعل اختراق نشط هذا الترتيب غير آمن.
5. **فك ترميز المعاملة الدقيقة ومحاكاتها.** افحص بشكل مستقل chain ID وعنوان الحساب والهدف ومحدّد الدالة وعنواني المالك القديم والجديد والحد الناتج وnonce وvalue ونوع العملية. تعامل مع `delegatecall` والتجميع وتغييرات الوحدات وتغييرات guard كتأثيرات منفصلة عالية المخاطر. يجب أن يوافق كل موقّع على payload المفكوك نفسه وعلى تجزئة المعاملة نفسها.
6. **التنفيذ بالصلاحيات القائمة.** يصرّح النصاب الحالي الصالح بالتدوير ما لم ينص مسار استرداد موثّق على غير ذلك. في الطوارئ، نسّق فقط عبر جهات اتصال موثّقة واستخدم موقّعين غير مخترقين. إذا لم يعد النصاب المعتاد ولا صلاحية استرداد مهيأة مسبقاً متاحاً، فلا تستطيع استدعاءات إدارة المالك القياسية استعادة الوصول.
7. **التحقق من التغيير وإغلاقه.** بعد التأكيد، استعلم مباشرة عن مجموعة المالكين والحد، وافحص الأحداث الصادرة أو traces حسب التطبيق، وتأكد من أن العنوان القديم لم يعد مخولاً. اجعل الموقّع الجديد يشارك في معاملة معتمدة منخفضة المخاطر أو بلا قيمة تتطلب الحد المقصود. راجع المعاملات المعلقة، وألغ وصول الموقّع السابق خارج السلسلة ونسخه الاحتياطية، وأرشف المقترح والتوقيعات وتجزئة المعاملة والكتلة والحالة النهائية.

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

## مثال تطبيقي

افترض أن حساباً من نوع `3-of-5` يملكُه `A` و`B` و`C` و`D` و`E`، وأنه يجب استبدال `B` بـ`F`. يتحقق الفريق أولاً من أن `F` يسيطر على العنوان المقترح الدقيق وأنه مستقل عن بقية المالكين. في نشر Safe متوافق، يجهز الفريق `swapOwner(prevOwner, B, F)`. هذا الاستدعاء معاملة Safe بحد ذاته، ولذلك يحتاج إلى `3` تأكيدات صالحة من مجموعة المالكين الحالية. يجب أن تحافظ النتيجة بعد فك الترميز على عدد مالكين يساوي `5` وحد يساوي `3`.

بعد تأكيد المعاملة، يقرأ الفريق `getOwners` و`getThreshold`، ويتحقق من غياب `B` ووجود `F`، ثم يجعل `F` مع مالكين آخرين ينفذون اختباراً معتمداً بقيمة `0`. ويراجع أيضاً المعاملات المعلقة: قد لا يعود توقيع أو موافقة مسبقة من `B` مستوفياً لفحوص المالك بعد إزالته، لذلك يجب إلغاء المقترحات المتأثرة أو إعادة بنائها بدلاً من افتراض قابليتها للتنفيذ.

إذا كان `B` قد يكون مخترقاً، فلا يطلب الفريق منه الموافقة على الإزالة. ينفذ ثلاثة مالكين آخرين غير مخترقين الاستبدال، ثم يفحصون الوحدات وصلاحيات الاسترداد وallowances وsession keys والمعاملات المنفذة سابقاً، لأن إزالة `B` لا تعكس الإجراءات السابقة ولا تلغي الصلاحيات الممنوحة عبر مسار آخر. إذا توفر أقل من `3` مالكين غير مخترقين، فقد يساعد فقط مسار استرداد أو إدارة جرى إعداده مسبقاً؛ ولا تشكّل مشاركة عبارات الاسترداد أو الثقة بخدمة «استرداد» غير مطلوبة بديلاً عن النصاب.

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

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

- **حساب أو عنوان خاطئ.** تحقق من chain ID وعنوان متعدد التوقيع والتطبيق وعنوان المالك الجديد على أجهزة ومن مصادر مستقلة. قد يمنح تسميم العناوين وأخطاء النسخ السيطرة لمهاجم.
- **فقدان النصاب.** ضع نموذجاً لكل حالة وسيطة. قد يؤدي حذف مالك مبكراً جداً، أو رفع الحد فوق عدد الموقّعين المتاحين، أو تدوير أجهزة مترابطة عدة معاً إلى جعل الحساب غير قابل للاستخدام.
- **تركيز مؤقت.** قد يخلق حد أدنى أو موقّع مضاف حديثاً فترة تسيطر فيها أطراف أقل على الحساب. فضّل الاستبدال الذري عند دعمه، ولا تخفض الحد لمجرد تبسيط الإجراء.
- **حفظ مترابط.** لا تكون العناوين المختلفة مستقلة إذا كانت عبارات الاسترداد أو الأجهزة أو النسخ الاحتياطية أو الاتصالات أو المسؤولون تشترك في نطاق فشل واحد. اختبر الاسترداد من دون تركيز الأسرار.
- **صلاحية خفية.** يمكن للوحدات وguards وfallback handlers وsession keys وtimelocks وعقود الاسترداد تجاوز مسار المالك أو منعه. اجردها وتحقق منها قبل التدوير وبعده.
- **سباق مع موقّع مخترق.** قبل تأكيد الإزالة، قد يستبق الموقّع المشتبه به المعاملة أو يسحب الأصول أو يغيّر الإعدادات أو يوافق على معاملة أخرى. استخدم إجراءات الحوادث، وإرسال المعاملات الخاص عند ملاءمته، والمراقبة المستمرة للحالة؛ ولا تفترض أن المعاملة المرسلة فازت بالسباق.
- **موافقات معلقة قديمة.** قد تبطل تغييرات المالكين والحد توقيعات جُمعت أو تغيّر الموافقات الكافية. أعد تقييم كل معاملة في قائمة الانتظار مقابل الحالة النهائية وألغ المقترحات المتقادمة.
- **اكتمال زائف.** لا يثبت إشعار النجاح في الواجهة تحقق الحالة المقصودة. انتظر سياسة التأكيد المطلوبة، ثم اقرأ حالة العقد وتحقق من payload المعاملة والأحداث ونتيجة التنفيذ.
- **إنهاء وصول غير مكتمل.** لا تؤدي إزالة مالك على السلسلة إلى حذف المفاتيح المنسوخة أو وصول المؤسسة أو بيانات اعتماد relayer أو إدخالات خزنة كلمات المرور أو الصلاحيات في عقود وسلاسل أخرى. ألغ كل عنصر بصورة منفصلة واحتفظ بمسار تدقيق.

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

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

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

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

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

- [محفظة أجهزة](/ar/crypto/hardware-wallet/)
- [محفظة متعددة التوقيع](/ar/crypto/multisig-wallet/)
- [إدارة المفاتيح الخاصة](/ar/crypto/private-key-management/)
- [مخاطر استرداد مالك الحساب الذكي](/ar/crypto/smart-account-owner-recovery-risk/)
- [محاكاة المعاملات](/ar/crypto/transaction-simulation/)

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

## المصادر

- [كيف تعمل حسابات Safe الذكية؟](https://docs.safe.global/advanced/smart-account-overview) - Safe Documentation (تاريخ الاطلاع: 2026-08-21)
- [addOwnerWithThreshold](https://docs.safe.global/reference-smart-account/owners/addOwnerWithThreshold) - Safe Documentation (تاريخ الاطلاع: 2026-08-21)
- [removeOwner](https://docs.safe.global/reference-smart-account/owners/removeOwner) - Safe Documentation (تاريخ الاطلاع: 2026-08-21)
- [swapOwner](https://docs.safe.global/reference-smart-account/owners/swapOwner) - Safe Documentation (تاريخ الاطلاع: 2026-08-21)
- [changeThreshold](https://docs.safe.global/reference-smart-account/owners/changeThreshold) - Safe Documentation (تاريخ الاطلاع: 2026-08-21)
- [OwnerManager.sol](https://github.com/safe-fndn/safe-smart-account/blob/main/contracts/base/OwnerManager.sol) - Safe Ecosystem Foundation (تاريخ الاطلاع: 2026-08-21)
- [توصية إدارة المفاتيح: الجزء 1 - عام](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) - NIST (تاريخ الاطلاع: 2026-08-21)

Source: https://wiki.fcontext.com/ar/crypto/multisig-signer-rotation/index.mdx