---
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. **حدّد الحساب والشفرة.** تحقق من معرّف السلسلة وعنوان الحساب، ثم حدّد التنفيذ وproxy أو beacon والمصنع والإصدار. في proxy من نوع ERC-1967، اقرأ خانات التنفيذ وbeacon والمسؤول بدل الثقة بشارة في الواجهة.
2. **احصر مسارات التفويض.** اقرأ المالكين والحدود، ومدققي ERC-4337، ومدققي ERC-7579 ومنفذيه وhooks وfallback handlers، ووحدات Safe وguards، ومفاتيح الجلسة، وعقود الاسترداد، وكل مسؤول طوارئ أو ترقية. قد ينفذ منفذ أو وحدة Safe من دون حد المالكين المعتاد.
3. **فك آلة حالات الاسترداد.** حدّد من يرشح مالكًا بديلًا، وكيف تُحسب موافقات الأوصياء وتنتهي، ومتى يبدأ التأخير، ومن يلغي وينهي، وما الذي يحدث عند استبدال الاسترداد أو تكراره. لا تفترض أن جميع عقود «الاسترداد الاجتماعي» تستخدم التسلسل نفسه.
4. **اختبر الاستقلال والتوافر.** لا تكون العناوين مستقلة إذا تحكم فيها جهاز أو شخص أو حساب سحابي أو خزنة كلمات مرور أو أمين حفظ أو مسؤول واحد. تأكد من بقاء الحد ممكنًا بعد عطل متوقع واحد من دون منح نطاق تحكم واحد قوة كافية للاستحواذ.
5. **راجع سلطة الإعداد.** حدّد من يضيف أو يزيل وصيًا أو مدققًا أو منفذًا أو hook أو وحدة أو fallback handler، ويغير الحد أو التأخير، ويوقف الإلغاء، أو يرقّي شفرة الحساب والاسترداد. لا يفيد timelock إذا استطاع دور آخر تجاوز التأخير ومسار الإلغاء.
6. **راقب وتحقق.** اشترك في تغييرات الاسترداد والمالك والوحدة والحد والتنفيذ والمسؤول أو استعلم عنها باستقلال. بعد أي عملية، فك المعاملة وتحقق من الإيصالات والأحداث والتخزين ومجموعة المالكين النهائية على السلسلة الصحيحة؛ إشعار نجاح الواجهة غير كافٍ.

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

## مثال عملي

افترض حسابًا مالكه `O` وله ثلاثة أوصياء `G1` و`G2` و`G3`. يستطيع أي `2-of-3` منهم اقتراح المالك الجديد `N`؛ ثم يبدأ تأخير `24-hour`؛ ويمكن لـ`O` الإلغاء خلاله؛ وبعد انتهائه يستطيع أي شخص الإنهاء. يمكن لوحدة الاسترداد استدعاء دالة تغيير المالك دون موافقة `O` على المعاملة النهائية.

توحي التسميات باسترداد موزع، لكن `G1` و`G2` تطبيقان محفوظان في الحساب السحابي نفسه. يمنح اختراق بياناته مهاجمًا واحدًا حد `2-of-3` الفعلي. يقترح `N`؛ وإذا فشلت المراقبة أو الإلغاء خلال `24 hours`، ينقل الإنهاء التحكم رغم أن مفتاح `O` الخاص لم يُسرق.

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

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

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

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

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

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

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

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

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

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

- [تجريد الحساب](/ar/crypto/account-abstraction/)
- [مخاطر وحدات التوقيع المتعدد](/ar/crypto/multisig-module-risk/)
- [تدوير موقعي التوقيع المتعدد](/ar/crypto/multisig-signer-rotation/)
- [إدارة المفاتيح الخاصة](/ar/crypto/private-key-management/)
- [محاكاة المعاملات](/ar/crypto/transaction-simulation/)

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

## المصادر

- [ERC-4337: Account Abstraction Using Alt Mempool](https://eips.ethereum.org/EIPS/eip-4337)
- [ERC-7579: Minimal Modular Smart Accounts](https://ercs.ethereum.org/ERCS/erc-7579)
- [Safe Modules](https://docs.safe.global/advanced/smart-account-modules)
- [Safe.sol](https://github.com/safe-fndn/safe-smart-account/blob/main/contracts/Safe.sol)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967)

Source: https://wiki.fcontext.com/ar/crypto/smart-account-owner-recovery-risk/index.mdx