بيكترا ⁦7702⁩

الملخص

يحدد EIP-7702 آلية لإضافة كود إلى حساب مملوك خارجياً (EOA). يسمح هذا المقترح للحسابات المملوكة خارجياً (EOAs)، وهي حسابات إيثيريوم القديمة، بتلقي تحسينات وظيفية قصيرة الأجل، مما يزيد من قابلية استخدام التطبيقات. يتم ذلك عن طريق تعيين مؤشر إلى كود تم نشره بالفعل باستخدام نوع معاملة جديد: 4.

يقدم نوع المعاملة الجديد هذا قائمة تفويض. يتم تعريف كل مجموعة تفويض في القائمة على النحو التالي:

[ 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 لا يجعل الحساب متعدد التوقيعات (multisig) لأنه لا يزال هناك مفتاح واحد يمكنه تجاوز أي سياسة توقيع. للمضي قدماً، يجب على المطورين التصميم بافتراض أن أي مشارك في النظام يمكن أن يكون عقداً ذكياً. بالنسبة لمطوري العقود الذكية، لم يعد من الآمن افتراض أن tx.origin يشير إلى حساب مملوك خارجياً.

أفضل الممارسات

تجريد الحساب: يجب أن يتوافق عقد التفويض مع معايير تجريد الحساب (AA) الأوسع في إيثيريوم لزيادة التوافق إلى أقصى حد. على وجه الخصوص، يجب أن يكون متوافقاً بشكل مثالي مع ERC-4337.

تصميم غير مقيد بإذن ومقاوم للرقابة: تُقدر إيثيريوم المشاركة غير المقيدة بإذن. يجب ألا يقوم عقد التفويض ببرمجة ثابتة (hard-code) أو الاعتماد على أي مُرحّل (relayer) أو خدمة واحدة "موثوقة". سيؤدي هذا إلى تعطيل الحساب إذا أصبح المُرحّل غير متصل بالإنترنت. يمكن استخدام ميزات مثل التجميع في دفعات (مثل approve+transferFrom) بواسطة الحساب المملوك خارجياً نفسه بدون مُرحّل. بالنسبة لمطوري التطبيقات الذين يرغبون في استخدام الميزات المتقدمة التي يتيحها 7702 (تجريد الغاز، عمليات السحب التي تحافظ على الخصوصية)، ستحتاجون إلى مُرحّل. في حين أن هناك بنيات مختلفة للمُرحّلين، فإن توصيتنا هي استخدام مُجمِّعات ⁦4337⁩ (opens in a new tab) التي تشير على الأقل إلى نقطة الدخول ⁦0.8⁩ (opens in a new tab) للأسباب التالية:

• توفر واجهات موحدة للترحيل
• تتضمن أنظمة مدير الدفع مدمجة
• تضمن التوافق المستقبلي
• يمكن أن تدعم مقاومة الرقابة من خلال مجمع الذاكرة العام (opens in a new tab)
• يمكن أن تشترط استدعاء دالة التهيئة (init) فقط من EntryPoint (opens in a new tab)

بمعنى آخر، يجب أن يكون أي شخص قادراً على العمل كراعٍ/مُرحّل للمعاملة طالما أنه يوفر التوقيع الصالح المطلوب أو عملية المستخدم (UserOperation) من الحساب. يضمن هذا مقاومة الرقابة: إذا لم تكن هناك حاجة إلى بنية تحتية مخصصة، فلا يمكن حظر معاملات المستخدم بشكل تعسفي بواسطة مُرحّل يتحكم في الوصول. على سبيل المثال، تعمل مجموعة أدوات التفويض الخاصة بـ ميتاماسك (opens in a new tab) بشكل صريح مع أي مُجمِّع ERC-4337 أو مدير الدفع على أي سلسلة، بدلاً من اشتراط خادم خاص بـ ميتاماسك.

تكامل التطبيقات اللامركزية (dapps) عبر واجهات المحفظة:

نظراً لأن المحافظ ستضع عقود تفويض محددة في القائمة البيضاء لـ EIP-7702، يجب ألا تتوقع التطبيقات اللامركزية (dapps) طلب تفويضات 7702 بشكل مباشر. بدلاً من ذلك، يجب أن يتم التكامل من خلال واجهات المحفظة الموحدة:

• ERC-5792 (wallet_sendCalls): يُمكّن التطبيقات اللامركزية (dapps) من طلب تنفيذ استدعاءات مجمعة من المحافظ، مما يسهل وظائف مثل التجميع في دفعات للمعاملات وتجريد الغاز.

• ERC-6900: يسمح للتطبيقات اللامركزية (dapps) بالاستفادة من قدرات الحساب الذكي المعيارية، مثل مفاتيح الجلسة واسترداد الحساب، من خلال وحدات تديرها المحفظة.

من خلال استخدام هذه الواجهات، يمكن للتطبيقات اللامركزية (dapps) الوصول إلى وظائف الحساب الذكي التي يوفرها EIP-7702 دون إدارة التفويضات بشكل مباشر، مما يضمن التوافق والأمان عبر تطبيقات المحافظ المختلفة.

ملاحظة: لا توجد طريقة موحدة للتطبيقات اللامركزية (dapps) لطلب توقيعات تفويض 7702 بشكل مباشر. يجب أن تعتمد التطبيقات اللامركزية على واجهات محفظة محددة مثل ERC-6900 للاستفادة من ميزات EIP-7702.

لمزيد من المعلومات:

• مواصفات ERC-5792 (opens in a new tab)
• مواصفات ERC-6900 (opens in a new tab)

تجنب تقييد المورد (Vendor Lock-In): تماشياً مع ما سبق، فإن التنفيذ الجيد يكون محايداً للموردين وقابلاً للتشغيل البيني. هذا يعني غالباً الالتزام بالمعايير الناشئة للحسابات الذكية. على سبيل المثال، يستخدم الحساب المعياري من Alchemy (opens in a new tab) معيار ERC-6900 للحسابات الذكية المعيارية وهو مصمم مع وضع "الاستخدام القابل للتشغيل البيني وغير المقيد بإذن" في الاعتبار.

الحفاظ على الخصوصية: في حين أن الخصوصية على السلسلة محدودة، يجب أن يسعى عقد التفويض إلى تقليل كشف البيانات وقابلية الربط. يمكن تحقيق ذلك من خلال دعم ميزات مثل مدفوعات الغاز برموز ERC-20 (بحيث لا يحتاج المستخدمون إلى الاحتفاظ برصيد ETH عام، مما يحسن الخصوصية وتجربة المستخدم) ومفاتيح الجلسة لمرة واحدة (والتي تقلل الاعتماد على مفتاح واحد طويل الأجل). على سبيل المثال، يُمكّن EIP-7702 من دفع الغاز بالرموز عبر المعاملات المدعومة، وسيجعل التنفيذ الجيد من السهل دمج مديري الدفع (paymasters) هؤلاء دون تسريب معلومات أكثر من اللازم. بالإضافة إلى ذلك، فإن التفويض خارج السلسلة لبعض الموافقات (باستخدام التوقيعات التي يتم التحقق منها على السلسلة) يعني معاملات أقل على السلسلة باستخدام المفتاح الأساسي للمستخدم، مما يساعد في الخصوصية. الحسابات التي تتطلب استخدام مُرحّل تجبر المستخدمين على الكشف عن عناوين IP الخاصة بهم. تعمل مجمعات الذاكرة العامة (PublicMempools) على تحسين ذلك، فعندما تنتشر معاملة/عملية مستخدم (UserOp) عبر مجمع الذاكرة، لا يمكنك معرفة ما إذا كانت قد نشأت من عنوان IP الذي أرسلها، أو تم ترحيلها من خلاله عبر بروتوكول الند للند (p2p).

القابلية للتوسعة والأمان المعياري: يجب أن تكون تطبيقات الحساب قابلة للتوسعة بحيث يمكن أن تتطور مع الميزات الجديدة والتحسينات الأمنية. القابلية للترقية ممكنة بطبيعتها مع EIP-7702 (نظراً لأن الحساب المملوك خارجياً يمكنه دائماً التفويض إلى عقد جديد في المستقبل لترقية منطقه). وراء القابلية للترقية، يسمح التصميم الجيد بالنمطية (modularity) - على سبيل المثال، وحدات إضافية لمخططات توقيع مختلفة أو سياسات إنفاق - دون الحاجة إلى إعادة النشر بالكامل. تعد مجموعة أدوات الحساب (Account Kit) من Alchemy مثالاً رئيسياً، حيث تسمح للمطورين بتثبيت وحدات التحقق (لأنواع التوقيع المختلفة مثل ECDSA و BLS وما إلى ذلك) ووحدات التنفيذ للمنطق المخصص. لتحقيق قدر أكبر من المرونة والأمان في الحسابات التي تدعم EIP-7702، يُشجع المطورون على التفويض إلى عقد وكيل بدلاً من التفويض المباشر لتنفيذ معين. يسمح هذا النهج بترقيات سلسة ونمطية دون الحاجة إلى تفويضات EIP-7702 إضافية لكل تغيير.

فوائد نمط الوكيل (Proxy Pattern):

• القابلية للترقية: تحديث منطق العقد عن طريق توجيه الوكيل إلى عقد تنفيذ جديد.

• منطق التهيئة المخصص: دمج دوال التهيئة داخل الوكيل لإعداد متغيرات الحالة الضرورية بشكل آمن.

على سبيل المثال، يوضح SafeEIP7702Proxy (opens in a new tab) كيف يمكن استخدام الوكيل لتهيئة وإدارة التفويضات بشكل آمن في الحسابات المتوافقة مع EIP-7702.

سلبيات نمط الوكيل:

• الاعتماد على جهات خارجية: يجب عليك الاعتماد على فريق خارجي لعدم الترقية إلى عقد غير آمن.

اعتبارات أمنية

واقي إعادة الدخول: مع إدخال تفويض EIP-7702، يمكن لحساب المستخدم التبديل ديناميكياً بين حساب مملوك خارجياً (EOA) وعقد ذكي (SC). تتيح هذه المرونة للحساب بدء المعاملات وأن يكون هدفاً للاستدعاءات. نتيجة لذلك، فإن السيناريوهات التي يستدعي فيها الحساب نفسه ويقوم باستدعاءات خارجية سيكون فيها msg.sender مساوياً لـ tx.origin، مما يقوض بعض الافتراضات الأمنية التي كانت تعتمد سابقاً على أن tx.origin هو دائماً حساب مملوك خارجياً.

بالنسبة لمطوري العقود الذكية، لم يعد من الآمن افتراض أن tx.origin يشير إلى حساب مملوك خارجياً. وبالمثل، فإن استخدام msg.sender == tx.origin كإجراء وقائي ضد هجمات إعادة الدخول لم يعد استراتيجية موثوقة.

للمضي قدماً، يجب على المطورين التصميم بافتراض أن أي مشارك في النظام يمكن أن يكون عقداً ذكياً. بدلاً من ذلك، يمكنهم تنفيذ حماية صريحة من إعادة الدخول باستخدام واقي إعادة الدخول مع أنماط المُعدِّل (modifier) nonReentrant. نوصي باتباع مُعدِّل تم تدقيقه مثل واقي إعادة الدخول من Open Zeppelin (opens in a new tab). يمكنهم أيضاً استخدام متغير تخزين مؤقت (transient storage variable) (opens in a new tab).

اعتبارات أمان التهيئة

يؤدي تنفيذ عقود تفويض EIP-7702 إلى إدخال تحديات أمنية محددة، لا سيما فيما يتعلق بعملية التهيئة. تنشأ ثغرة أمنية حرجة عندما تقترن دالة التهيئة (init) ذرياً (atomically) بعملية التفويض. في مثل هذه الحالات، يمكن للمهاجم الاستباقي (frontrunner) اعتراض توقيع التفويض وتنفيذ دالة init بمعلمات معدلة، مما قد يؤدي إلى السيطرة على الحساب.

هذا الخطر وثيق الصلة بشكل خاص عند محاولة استخدام تطبيقات حساب العقد الذكي (SCA) الحالية مع EIP-7702 دون تعديل آليات التهيئة الخاصة بها.

حلول للتخفيف من ثغرات التهيئة

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

• استخدام EntryPoint الخاص بـ ERC-4337
  اشتراط استدعاء دالة التهيئة حصرياً من عقد EntryPoint الخاص بـ ERC-4337. تستفيد هذه الطريقة من إطار عمل التحقق والتنفيذ الموحد الذي يوفره ERC-4337، مما يضيف طبقة إضافية من الأمان إلى عملية التهيئة.
  (انظر: مستندات Safe (opens in a new tab))

من خلال اعتماد هذه الحلول، يمكن للمطورين تعزيز أمان عقود تفويض EIP-7702، والحماية من هجمات الاستباق (frontrunning) المحتملة أثناء مرحلة التهيئة.

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

مخاطر التصيد الاحتيالي: مع تنفيذ تفويض EIP-7702، قد يتم التحكم في الأصول الموجودة في حساب المستخدم بالكامل بواسطة العقود الذكية. إذا قام المستخدم بتفويض حسابه دون علمه إلى عقد ضار، فيمكن للمهاجم بسهولة السيطرة وسرقة الأموال. عند استخدام chain_id=0 يتم تطبيق التفويض على جميع معرفات السلاسل. قم بالتفويض فقط إلى عقد غير قابل للتغيير (لا تفوض أبداً إلى وكيل)، وفقط للعقود التي تم نشرها باستخدام CREATE2 (مع كود التهيئة القياسي - لا توجد عقود متحولة) حتى لا يتمكن الناشر من نشر شيء مختلف على نفس العنوان في مكان آخر. خلاف ذلك، فإن تفويضك يعرض حسابك للخطر على جميع سلاسل EVM الأخرى.

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

الحد الأدنى من السطح الموثوق والأمان: مع توفير المرونة، يجب أن يحافظ عقد التفويض على منطقه الأساسي في حده الأدنى وقابلاً للتدقيق. العقد هو في الواقع امتداد للحساب المملوك خارجياً للمستخدم، لذا فإن أي خلل يمكن أن يكون كارثياً. يجب أن تتبع التطبيقات أفضل الممارسات من مجتمع أمان العقود الذكية. على سبيل المثال، يجب تأمين دوال المُنشئ (constructor) أو المُهيئ (initializer) بعناية - كما أبرزت Alchemy، إذا تم استخدام نمط وكيل ضمن 7702، فإن المُهيئ غير المحمي يمكن أن يسمح للمهاجم بالاستيلاء على الحساب. يجب أن تهدف الفرق إلى إبقاء الكود على السلسلة بسيطاً: عقد 7702 الخاص بـ Ambire يتكون من حوالي 200 سطر فقط من Solidity، مما يقلل من التعقيد عمداً لتقليل الأخطاء. يجب إيجاد توازن بين المنطق الغني بالميزات والبساطة التي تسهل التدقيق.

التطبيقات المعروفة

نظراً لطبيعة EIP-7702، يوصى بأن تتوخى المحافظ الحذر عند مساعدة المستخدمين في التفويض إلى عقد تابع لجهة خارجية. فيما يلي مجموعة من التطبيقات المعروفة التي تم تدقيقها:

إرشادات المحفظة العتادية

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

سيناريوهات التكامل للتطبيقات المرافقة

الكسول (Lazy)

نظراً لأن الحساب المملوك خارجياً لا يزال يعمل كالمعتاد، فلا يوجد شيء للقيام به.

ملاحظة: يمكن رفض بعض الأصول تلقائياً بواسطة كود التفويض، مثل رموز ERC-1155 غير القابلة للاستبدال (NFTs)، ويجب أن يكون الدعم على دراية بذلك.

المدرك (Aware)

إخطار المستخدم بوجود تفويض للحساب المملوك خارجياً عن طريق التحقق من الكود الخاص به، وتقديم خيار إزالة التفويض اختيارياً.

التفويض الشائع

يقوم مزود الأجهزة بوضع عقود التفويض المعروفة في القائمة البيضاء وينفذ دعمها في البرنامج المرافق. يوصى باختيار عقد يدعم ERC-4337 بالكامل.

سيتم التعامل مع الحسابات المملوكة خارجياً المفوضة إلى عقد مختلف كحسابات مملوكة خارجياً قياسية.

التفويض المخصص

يقوم مزود الأجهزة بتنفيذ عقد التفويض الخاص به ويضيفه إلى القوائم وينفذ دعمه في البرنامج المرافق. يوصى ببناء عقد يدعم ERC-4337 بالكامل.

سيتم التعامل مع الحسابات المملوكة خارجياً المفوضة إلى عقد مختلف كحسابات مملوكة خارجياً قياسية.