بيكارا 7702

ملخص

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

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

[معرف_السلسلة, العنوان, y_parity, ق, s]

العنوان هو التفويض (البرمجيات المطورة بالفعل التي ستستخدمها EOA) معرف السلسلة يقفل الإذن لسلسلة معينة (أو 0 لجميع السلاسل) nonce يقفل الإذن إلى nonce حساب معين (y_parity, r, s) هو توقيع زوج التفويض، يُعرف على أنه keccak(0x05 || rlp ([معرف السلسلة, العنوان, nonce])) بواسطة المفتاح الخاص لـ EOA الذي ينطبق عليه التفويض (يسمى أيضاً السلطة)

يمكن إعادة تعيين الوفد من خلال التفويض إلى العنوان صفر.

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

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

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

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

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

بعبارة أخرى، يجب أن يكون بإمكان أي شخص أن دور الراعي/الوسيط للمعاملة مادام. هذا يضمن مقاومة الرقابة: إذا لم تكن هناك بنية تحتية مخصصة مطلوبة، فلا يمكن حجب معاملات المستخدم بشكل تعسفي الحماية. على سبيل المثال، مجموعة أدوات تفويض (https://github.com/delegation-framework/releases/tag/v1.3.0 (opens in a new tab)) تعمل بشكل صريح مع أي مجمع أو موفر دفع وفقًا لمعيار ERC-4337 على أي سلسلة، بدلاً من الحاجة إلى خادم محدد لـ.

دمج التطبيقات اللامركزية من خلال واجهات المحفظة:

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

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

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

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

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

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

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

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

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

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

فوائد نمط الوكيل:

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

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

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

عيوب نمط الوكيل:

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

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

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

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

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

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

تقديم عقود تفويض EIP-7702 يطرح تحديات أمنية محددة، لا سيما فيما يتعلق بعملية التهيئة. تظهر ثُغْرَة حاسمة عندما يتم ربط دالة التهيئة () بحركة التفويض بشكل ذري. في مثل هذه الحالات، قد يتمكن المتصدر من اعتراض توقيع الوفد وتنفيذ دالة بمعلمات معدلة، مما قد يتيح له السيطرة على الحساب.

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

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

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

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

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

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

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

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

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

تنفيذات معروفة

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

إرشادات محفظة الأجهزة

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

سيناريوهات الدمج لتطبيقات الرفيق

كسلان

نظرًا لأن EOA لا تزال تعمل كالمعتاد، فلا يوجد ما ينبغي فعله.

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

واعٍ

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

وفد مشترك

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

ستُعالج الحسابات العامة التي تم تفويضها إلى حساب آخر على أنها حسابات عامة عادية.

تفويض مخصص

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

ستُعالج الحسابات العامة التي تم تفويضها إلى حساب آخر على أنها حسابات عامة عادية.

آخر تحديث للصفحة: 22 أكتوبر 2025

p (opens in a new tab)

c (opens in a new tab)

j (opens in a new tab)

+6

عرض المساهمين