--- title: "بيكترا ⁦7702⁩" metaTitle: Pectra EIP-7702 guidelines description: "تعرف على المزيد حول ⁦7702⁩ في إصدار بيكترا" lang: ar --- ## الملخص يحدد EIP-7702 آلية لإضافة كود إلى حساب مملوك خارجياً (EOA). يتيح هذا المقترح للحسابات المملوكة خارجياً (EOAs)، وهي حسابات إيثيريوم القديمة، تلقي تحسينات وظيفية قصيرة الأجل، مما يزيد من قابلية استخدام التطبيقات. يتم ذلك عن طريق تعيين مؤشر إلى كود تم نشره بالفعل باستخدام نوع معاملة جديد: 4. يقدم نوع المعاملة الجديد هذا قائمة تفويض. يتم تعريف كل مجموعة تفويض (tuple) في القائمة على النحو التالي: ``` [ chain_id, address, nonce, y_parity, r, s ] ``` **address** هو التفويض (رمز البايت المنشور بالفعل والذي سيتم استخدامه بواسطة الحساب المملوك خارجياً) **chain_id** يقفل التفويض بسلسلة معينة (أو 0 لجميع السلاسل) **nonce** يقفل التفويض برقم فريد لحساب معين (**y_parity, r, s**) هو توقيع مجموعة التفويض، ويُعرّف كـ `keccak(0x05 || rlp ([chain_id ,address, nonce]))` بواسطة المفتاح الخاص للحساب المملوك خارجياً الذي ينطبق عليه التفويض (يُسمى أيضاً السلطة) يمكن إعادة تعيين التفويض عن طريق التفويض إلى العنوان الفارغ (null address). يحتفظ المفتاح الخاص للحساب المملوك خارجياً بالسيطرة الكاملة على الحساب بعد التفويض. على سبيل المثال، التفويض إلى Safe لا يجعل الحساب متعدد التوقيعات لأنه لا يزال هناك مفتاح واحد يمكنه تجاوز أي سياسة توقيع. للمضي قدماً، يجب على المطورين التصميم بافتراض أن أي مشارك في النظام يمكن أن يكون عقداً ذكياً. بالنسبة لمطوري العقود الذكية، لم يعد من الآمن افتراض أن `tx.origin` يشير إلى حساب مملوك خارجياً. ## أفضل الممارسات **تجريد الحساب**: يجب أن يتوافق عقد التفويض مع معايير تجريد الحساب (AA) الأوسع في إيثيريوم لزيادة التوافق إلى أقصى حد. على وجه الخصوص، يجب أن يكون متوافقاً بشكل مثالي مع ERC-4337. **تصميم غير مقيد بإذن ومقاوم للرقابة**: تقدر إيثيريوم المشاركة غير المقيدة بإذن. يجب ألا يقوم عقد التفويض ببرمجة ثابتة (hard-code) أو الاعتماد على أي مُرحّل (relayer) أو خدمة "موثوقة" واحدة. سيؤدي هذا إلى تعطيل الحساب إذا أصبح المُرحّل غير متصل بالإنترنت. يمكن استخدام ميزات مثل التجميع في دفعات (على سبيل المثال، approve+transferFrom) بواسطة الحساب المملوك خارجياً نفسه بدون مُرحّل. بالنسبة لمطوري التطبيقات الذين يرغبون في استخدام الميزات المتقدمة التي يتيحها EIP-7702 (تجريد الغاز، عمليات السحب التي تحافظ على الخصوصية)، ستحتاج إلى مُرحّل. في حين أن هناك بنيات مختلفة للمُرحّلين، فإن توصيتنا هي استخدام [مُجمِّعات ERC-4337](https://www.erc4337.io/bundlers) التي تشير على الأقل إلى [نقطة الإدخال 0.8](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0) للأسباب التالية: - توفر واجهات موحدة للترحيل - تتضمن أنظمة مدير الدفع مدمجة - تضمن التوافق المستقبلي - يمكن أن تدعم مقاومة الرقابة من خلال [مجمع ذاكرة عام](https://notes.ethereum.org/@yoav/unified-erc-4337-mempool) - يمكن أن تشترط استدعاء دالة التهيئة (`init`) فقط من [EntryPoint](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0) بمعنى آخر، يجب أن يكون أي شخص قادراً على العمل كراعٍ/مُرحّل للمعاملة طالما أنه يوفر التوقيع الصالح المطلوب أو عملية المستخدم من الحساب. يضمن هذا مقاومة الرقابة: إذا لم تكن هناك بنية تحتية مخصصة مطلوبة، فلا يمكن حظر معاملات المستخدم بشكل تعسفي بواسطة مُرحّل يتحكم في الوصول. على سبيل المثال، تعمل [مجموعة أدوات التفويض الخاصة بـ ميتاماسك](https://github.com/MetaMask/delegation-framework/releases/tag/v1.3.0) بشكل صريح مع أي مُجمِّع ERC-4337 أو مدير الدفع على أي سلسلة، بدلاً من اشتراط خادم خاص بـ ميتاماسك. **تكامل التطبيقات اللامركزية (dapps) عبر واجهات المحفظة**: نظراً لأن المحافظ ستضع عقود تفويض محددة في القائمة البيضاء لـ EIP-7702، يجب ألا تتوقع التطبيقات اللامركزية (dapps) طلب تفويضات EIP-7702 بشكل مباشر. بدلاً من ذلك، يجب أن يتم التكامل من خلال واجهات المحفظة الموحدة: - **ERC-5792 (`wallet_sendCalls`)**: يُمكّن التطبيقات اللامركزية (dapps) من طلب المحافظ لتنفيذ استدعاءات مجمعة، مما يسهل وظائف مثل التجميع في دفعات للمعاملات وتجريد الغاز. - **ERC-6900**: يسمح للتطبيقات اللامركزية (dapps) بالاستفادة من قدرات الحساب الذكي المعيارية، مثل مفاتيح الجلسة واسترداد الحساب، من خلال وحدات تديرها المحفظة. من خلال استخدام هذه الواجهات، يمكن للتطبيقات اللامركزية (dapps) الوصول إلى وظائف الحساب الذكي التي يوفرها EIP-7702 دون إدارة التفويضات بشكل مباشر، مما يضمن التوافق والأمان عبر تطبيقات المحفظة المختلفة. > ملاحظة: لا توجد طريقة موحدة للتطبيقات اللامركزية (dapps) لطلب توقيعات تفويض EIP-7702 بشكل مباشر. يجب أن تعتمد التطبيقات اللامركزية (dapps) على واجهات محفظة محددة مثل ERC-6900 للاستفادة من ميزات EIP-7702. لمزيد من المعلومات: - [مواصفات ERC-5792](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5792.md) - [مواصفات ERC-6900](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6900.md) **تجنب التقيد بمورد معين (Vendor Lock-In)**: تماشياً مع ما سبق، فإن التنفيذ الجيد يكون محايداً للموردين وقابلاً للتشغيل البيني. غالباً ما يعني هذا الالتزام بالمعايير الناشئة للحسابات الذكية. على سبيل المثال، يستخدم [الحساب المعياري الخاص بـ Alchemy](https://github.com/alchemyplatform/modular-account) معيار ERC-6900 للحسابات الذكية المعيارية وهو مصمم مع وضع "الاستخدام القابل للتشغيل البيني غير المقيد بإذن" في الاعتبار. **الحفاظ على الخصوصية**: في حين أن الخصوصية على السلسلة محدودة، يجب أن يسعى عقد التفويض إلى تقليل كشف البيانات وقابلية الربط. يمكن تحقيق ذلك من خلال دعم ميزات مثل مدفوعات الغاز برموز ERC-20 (بحيث لا يحتاج المستخدمون إلى الاحتفاظ برصيد ETH عام، مما يحسن الخصوصية وتجربة المستخدم) ومفاتيح الجلسة لمرة واحدة (والتي تقلل الاعتماد على مفتاح واحد طويل الأجل). على سبيل المثال، يتيح EIP-7702 دفع الغاز بالرموز عبر المعاملات المدعومة، وسيجعل التنفيذ الجيد من السهل دمج مديري الدفع هؤلاء دون تسريب معلومات أكثر من اللازم. بالإضافة إلى ذلك، فإن التفويض خارج السلسلة لبعض الموافقات (باستخدام التوقيعات التي يتم التحقق منها على السلسلة) يعني معاملات أقل على السلسلة باستخدام المفتاح الأساسي للمستخدم، مما يساعد في الخصوصية. الحسابات التي تتطلب استخدام مُرحّل تجبر المستخدمين على الكشف عن عناوين IP الخاصة بهم. تعمل مجمعات الذاكرة العامة (PublicMempools) على تحسين ذلك، فعندما تنتشر معاملة/عملية المستخدم عبر مجمع الذاكرة، لا يمكنك معرفة ما إذا كانت قد نشأت من عنوان IP الذي أرسلها، أو تم ترحيلها من خلاله عبر بروتوكول الند للند (p2p). **قابلية التوسعة والأمان المعياري**: يجب أن تكون تطبيقات الحساب قابلة للتوسعة بحيث يمكن أن تتطور مع الميزات الجديدة والتحسينات الأمنية. قابلية الترقية ممكنة بطبيعتها مع EIP-7702 (نظراً لأن الحساب المملوك خارجياً يمكنه دائماً التفويض إلى عقد جديد في المستقبل لترقية منطقه). إلى جانب قابلية الترقية، يسمح التصميم الجيد بالنمطية (modularity) - على سبيل المثال، وحدات إضافية لمخططات التوقيع المختلفة أو سياسات الإنفاق - دون الحاجة إلى إعادة النشر بالكامل. تعد مجموعة أدوات الحساب (Account Kit) الخاصة بـ Alchemy مثالاً رئيسياً، حيث تسمح للمطورين بتثبيت وحدات التحقق (لأنواع التوقيع المختلفة مثل ECDSA و BLS وما إلى ذلك) ووحدات التنفيذ للمنطق المخصص. لتحقيق قدر أكبر من المرونة والأمان في الحسابات التي تدعم EIP-7702، يُشجع المطورون على التفويض إلى عقد وكيل بدلاً من التفويض المباشر إلى تنفيذ محدد. يسمح هذا النهج بإجراء ترقيات سلسة ونمطية دون الحاجة إلى تفويضات EIP-7702 إضافية لكل تغيير. فوائد نمط الوكيل (Proxy Pattern): - **قابلية الترقية**: تحديث منطق العقد عن طريق توجيه الوكيل إلى عقد تنفيذ جديد. - **منطق تهيئة مخصص**: دمج دوال التهيئة داخل الوكيل لإعداد متغيرات الحالة الضرورية بشكل آمن. على سبيل المثال، يوضح [SafeEIP7702Proxy](https://docs.safe.global/advanced/eip-7702/7702-safe) كيف يمكن استخدام وكيل لتهيئة وإدارة التفويضات بشكل آمن في الحسابات المتوافقة مع EIP-7702. سلبيات نمط الوكيل: - **الاعتماد على جهات خارجية**: يجب عليك الاعتماد على فريق خارجي لعدم الترقية إلى عقد غير آمن. ## اعتبارات أمنية {#security-considerations} **واقي إعادة الدخول**: مع إدخال تفويض EIP-7702، يمكن لحساب المستخدم التبديل ديناميكياً بين حساب مملوك خارجياً (EOA) وعقد ذكي (SC). تتيح هذه المرونة للحساب بدء المعاملات وأن يكون هدفاً للاستدعاءات. نتيجة لذلك، فإن السيناريوهات التي يستدعي فيها الحساب نفسه ويقوم باستدعاءات خارجية سيكون فيها `msg.sender` مساوياً لـ `tx.origin`، مما يقوض بعض الافتراضات الأمنية التي كانت تعتمد سابقاً على أن `tx.origin` هو دائماً حساب مملوك خارجياً. بالنسبة لمطوري العقود الذكية، لم يعد من الآمن افتراض أن `tx.origin` يشير إلى حساب مملوك خارجياً. وبالمثل، فإن استخدام `msg.sender == tx.origin` كإجراء وقائي ضد هجمات إعادة الدخول لم يعد استراتيجية موثوقة. للمضي قدماً، يجب على المطورين التصميم بافتراض أن أي مشارك في النظام يمكن أن يكون عقداً ذكياً. بدلاً من ذلك، يمكنهم تنفيذ حماية صريحة من إعادة الدخول باستخدام واقي إعادة الدخول مع أنماط المُعدِّل (modifier) `nonReentrant`. نوصي باتباع مُعدِّل تم تدقيقه مثل [واقي إعادة الدخول من Open Zeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/ReentrancyGuard.sol). يمكنهم أيضاً استخدام [متغير تخزين مؤقت (transient storage variable)](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html). **اعتبارات أمان التهيئة** يؤدي تنفيذ عقود تفويض EIP-7702 إلى إدخال تحديات أمنية محددة، لا سيما فيما يتعلق بعملية التهيئة. تنشأ ثغرة أمنية حرجة عندما تقترن دالة التهيئة (`init`) ذرياً (atomically) بعملية التفويض. في مثل هذه الحالات، يمكن للمهاجم الاستباقي (frontrunner) اعتراض توقيع التفويض وتنفيذ دالة `init` بمعلمات معدلة، مما قد يؤدي إلى السيطرة على الحساب. هذا الخطر وثيق الصلة بشكل خاص عند محاولة استخدام تطبيقات حساب العقد الذكي (SCA) الحالية مع EIP-7702 دون تعديل آليات التهيئة الخاصة بها. **حلول للتخفيف من ثغرات التهيئة** - تنفيذ `initWithSig` استبدل دالة `init` القياسية بدالة `initWithSig` التي تشترط على المستخدم توقيع معلمات التهيئة. يضمن هذا النهج أن التهيئة لا يمكن أن تستمر إلا بموافقة صريحة من المستخدم، وبالتالي التخفيف من مخاطر التهيئة غير المصرح بها. - استخدام EntryPoint الخاص بـ ERC-4337 اشتراط استدعاء دالة التهيئة حصرياً من عقد EntryPoint الخاص بـ ERC-4337. تستفيد هذه الطريقة من إطار عمل التحقق والتنفيذ الموحد الذي يوفره ERC-4337، مما يضيف طبقة إضافية من الأمان إلى عملية التهيئة. _(انظر: [مستندات Safe](https://docs.safe.global/advanced/eip-7702/7702-safe))_ من خلال اعتماد هذه الحلول، يمكن للمطورين تعزيز أمان عقود تفويض EIP-7702، والحماية من هجمات الاستباق (frontrunning) المحتملة أثناء مرحلة التهيئة. **تعارضات التخزين**: لا يؤدي تفويض الكود إلى مسح التخزين الحالي. عند الترحيل من عقد تفويض إلى آخر، تظل البيانات المتبقية من العقد السابق. إذا كان العقد الجديد يستخدم نفس خانات التخزين ولكنه يفسرها بشكل مختلف، فقد يتسبب ذلك في سلوك غير مقصود. على سبيل المثال، إذا كان التفويض الأولي لعقد تمثل فيه خانة التخزين `bool`، والتفويض اللاحق لعقد تمثل فيه نفس الخانة `uint`، فإن عدم التطابق يمكن أن يؤدي إلى نتائج غير متوقعة. **مخاطر التصيد الاحتيالي**: مع تنفيذ تفويض EIP-7702، قد يتم التحكم في الأصول الموجودة في حساب المستخدم بالكامل بواسطة العقود الذكية. إذا قام المستخدم بتفويض حسابه دون علمه إلى عقد ضار، فيمكن للمهاجم بسهولة السيطرة وسرقة الأموال. عند استخدام `chain_id=0` يتم تطبيق التفويض على جميع معرفات السلاسل. قم بالتفويض فقط إلى عقد غير قابل للتغيير (لا تفوض أبداً إلى وكيل)، وفقط للعقود التي تم نشرها باستخدام CREATE2 (مع كود التهيئة القياسي - لا توجد عقود متحولة) حتى لا يتمكن الناشر من نشر شيء مختلف على نفس العنوان في مكان آخر. خلاف ذلك، فإن تفويضك يعرض حسابك للخطر على جميع سلاسل EVM الأخرى. عندما يقوم المستخدمون بإجراء توقيعات مفوضة، يجب عرض العقد المستهدف الذي يتلقى التفويض بشكل واضح وبارز للمساعدة في التخفيف من مخاطر التصيد الاحتيالي. **الحد الأدنى من السطح الموثوق والأمان**: مع توفير المرونة، يجب أن يحافظ عقد التفويض على منطقه الأساسي في حده الأدنى وقابلاً للتدقيق. العقد هو في الواقع امتداد للحساب المملوك خارجياً للمستخدم، لذا فإن أي خلل يمكن أن يكون كارثياً. يجب أن تتبع التطبيقات أفضل الممارسات من مجتمع أمان العقود الذكية. على سبيل المثال، يجب تأمين دوال المُنشئ (constructor) أو المُهيئ (initializer) بعناية - كما أبرزت Alchemy، إذا تم استخدام نمط وكيل ضمن 7702، فإن المُهيئ غير المحمي يمكن أن يسمح للمهاجم بالاستيلاء على الحساب. يجب أن تهدف الفرق إلى إبقاء الكود على السلسلة بسيطاً: عقد 7702 الخاص بـ Ambire يتكون من حوالي 200 سطر فقط من Solidity، مما يقلل من التعقيد عمداً لتقليل الأخطاء. يجب إيجاد توازن بين المنطق الغني بالميزات والبساطة التي تسهل التدقيق. ### تطبيقات معروفة نظراً لطبيعة EIP-7702، يُوصى بأن تتوخى المحافظ الحذر عند مساعدة المستخدمين في التفويض إلى عقد تابع لجهة خارجية. فيما يلي مجموعة من التطبيقات المعروفة التي تم تدقيقها: | عنوان العقد | المصدر | عمليات التدقيق | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 0x000000009B1D0aF20D8C6d0A44e162d11F9b8f00 | [Uniswap/calibur](https://github.com/Uniswap/calibur) | [عمليات التدقيق](https://github.com/Uniswap/calibur/tree/main/audits) | | 0x69007702764179f14F51cdce752f4f775d74E139 | [alchemyplatform/modular-account](https://github.com/alchemyplatform/modular-account) | [عمليات التدقيق](https://github.com/alchemyplatform/modular-account/tree/develop/audits) | | 0x5A7FC11397E9a8AD41BF10bf13F22B0a63f96f6d | [AmbireTech/ambire-common](https://github.com/AmbireTech/ambire-common/blob/feature/eip-7702/contracts/AmbireAccount7702.sol) | [عمليات التدقيق](https://github.com/AmbireTech/ambire-common/tree/feature/eip-7702/audits) | | 0x63c0c19a282a1b52b07dd5a65b58948a07dae32b | [MetaMask/delegation-framework](https://github.com/MetaMask/delegation-framework) | [عمليات التدقيق](https://github.com/MetaMask/delegation-framework/tree/main/audits) | | 0x4Cd241E8d1510e30b2076397afc7508Ae59C66c9 | [فريق تجريد الحساب (AA) في مؤسسة إيثيريوم](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/accounts/Simple7702Account.sol) | [عمليات التدقيق](https://github.com/eth-infinitism/account-abstraction/blob/develop/audits/SpearBit%20Account%20Abstraction%20Security%20Review%20-%20Mar%202025.pdf) | | 0x17c11FDdADac2b341F2455aFe988fec4c3ba26e3 | [Luganodes/Pectra-Batch-Contract](https://github.com/Luganodes/Pectra-Batch-Contract) | [عمليات التدقيق](https://certificate.quantstamp.com/full/luganodes-pectra-batch-contract/23f0765f-969a-4798-9edd-188d276c4a2b/index.html) | ## إرشادات المحفظة العتادية {#hardware-wallet-guidelines} يجب ألا تعرض المحافظ العتادية تفويضاً تعسفياً. الإجماع في مجال المحفظة العتادية هو استخدام قائمة بعقود المفوضين الموثوقة. نقترح السماح بالتطبيقات المعروفة المذكورة أعلاه والنظر في التطبيقات الأخرى على أساس كل حالة على حدة. نظراً لأن تفويض الحساب المملوك خارجياً الخاص بك إلى عقد يمنح السيطرة على جميع الأصول، يجب أن تكون المحافظ العتادية حذرة في الطريقة التي تنفذ بها 7702. ### سيناريوهات التكامل للتطبيقات المرافقة {#integration-scenarios-for-companion-apps} #### الكسول (Lazy) {#lazy} نظراً لأن الحساب المملوك خارجياً لا يزال يعمل كالمعتاد، فلا يوجد شيء للقيام به. ملاحظة: يمكن رفض بعض الأصول تلقائياً بواسطة كود التفويض، مثل رموز ERC-1155 غير القابلة للاستبدال (NFTs)، ويجب أن يكون الدعم على دراية بذلك. #### المدرك (Aware) {#aware} إخطار المستخدم بوجود تفويض للحساب المملوك خارجياً عن طريق التحقق من الكود الخاص به، وتقديم خيار إزالة التفويض اختيارياً. #### التفويض الشائع يضع مزود الأجهزة عقود التفويض المعروفة في القائمة البيضاء وينفذ دعمها في البرنامج المرافق. يُوصى باختيار عقد يدعم ERC-4337 بالكامل. سيتم التعامل مع الحسابات المملوكة خارجياً (EOAs) المفوضة إلى عقد مختلف كحسابات مملوكة خارجياً قياسية. #### التفويض المخصص ينفذ مزود الأجهزة عقد التفويض الخاص به ويضيفه إلى القوائم وينفذ دعمه في البرنامج المرافق. يُوصى ببناء عقد يدعم ERC-4337 بالكامل. سيتم التعامل مع الحسابات المملوكة خارجياً (EOAs) المفوضة إلى عقد مختلف كحسابات مملوكة خارجياً قياسية.