مقدمة

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

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

لتمكين EOAs من العمل كمحافظ عقود ذكية، قمنا بتطوير EIP7702Proxy، وهو خفيف الوزنوكيل ERC-1967 عقد مصمم ليكون بمثابة EIP-7702 deleGate لـ EOA. بالإضافة إلى النقل المنطقي الأساسي الذي يتم بواسطة وكيل، يحتوي EIP7702Proxy على ميزات وخيارات تصميم إضافية تحل العديد من التحديات الفريدة لحسابات EIP-7702-deleGated. كان أحد الأهداف في تصميم EIP7702Proxy هو تمكين أقرب توافق ممكن بين "محافظ Coinbase الذكية القياسية" و "محافظ Coinbase الذكية المخصصة EIP-7702-deleGated"، مما يعني تجريد التعقيد الإضافي المطلوب من ميكانيكا EIP-7702 إلى الوكيل المخصص والاستمرار في الاعتماد على التنفيذ الأصلي لـ CoinbaseSmartWallet. يمكن تطبيق الحل لهذه التحدي بشكل مفيد على أي منطق تنفيذ، وليس فقط تنفيذ CoinbaseSmartWallet، مع مساعدة EOAs على البقاء آمنين في بيئة مدعومة بـ 7702.

نصف أدناه التحديات المحددة والحلول التصميمية المقابلة التي تسمح لنا بتكييف أي تنفيذ لمحفظة عقد ذكي موجود بأمان ليتم استخدامه في ترقيات EIP-7702.

التحدي #1: فرض التهيئة الآمنة

ت stems من قيود التهيئة. والمحافظ الذكية التقليدية، بما في ذلك CoinbaseSmartWallet، تتعامل عادةً مع التهيئة الآمنة (إقامة ملكية الحساب) بشكل ذري أثناء نشرها عبر عقد مصنع منفصل. تعني هذه الذرية أن العديد من مثل هذه التطبيقات لديها وظائف مُهيئة غير محمية يمكن استدعاؤها مرة واحدة بالضبط. ومع ذلك، فإن تصميم EIP-7702 لا يسمح بتنفيذ بيانات تهيئة الاتصال أثناء عملية تفويض الكود (الخطوة المقابلة لـ "النشر") وبالتالي لا يمكن القيام بذلك ذريًا.

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

الحل: تطلب توقيع EOA لضبط التنفيذ وتهيئته بشكل ذري

يرجى ملاحظة أن المحافظ الذكية الحالية من Coinbase تم نشرها خلفوكيل ERC-1967 مع UUPSUpgradeableالتنفيذ (منطق CoinbaseSmartWallet الفعلي). الكود الموجود في عنوان الحساب الفعلي هو وكيل، ويستخدم الوكيل موقع تخزين تقليدي محدد بواسطة ERC-1967 للاحتفاظ بمؤشر إلى منطق التنفيذ الخاص به. تتمثل الحلول الخاصة بنا لثغرة التهيئة في سياق 7702 في الاعتراف بأن أي منطق تنفيذ لا يصبح نشطًا (وبالتالي خطيرًا) إلا عندما يقوم الوكيل فعليًا بإنشاء اتصال به. لذلك، إذا لم نتمكن من فرض النشر الذري مع التهيئة، يمكننا بدلاً من ذلك فرض تعيين تنفيذ ذري مع التهيئة.

EIP-7702 هيكل عقد CoinbaseSmartWallet وتدفق التفويض المنطقي

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

1. يحقق في صحة توقيع من EOA عبر بيانات رئيسية مثل عنوان عقد التنفيذ الجديد، وبيانات استدعاء التهيئة، وعنوان عقد المدقق الذي سيقيم أمان حالة الحساب الناتجة، وحماية أساسية من إعادة تشغيل التوقيعات مثل nonce وexpiry.
2. يحدد قيمة مؤشر ERC-1967 للتنفيذ الجديد وينفذ بيانات الاستدعاء المقدمة ضد التنفيذ المنطقي الجديد
3. يجري استدعاء لدالة validateAccountState التي يجب أن يتم تنفيذها بواسطة المدقق المشمول في التوقيع.

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

التحدي #2: التخزين المشترك عبر مفوضي EIP-7702

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

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

مثال على حالة غير صالحة لـ DeleGate A ناتجة عن نمط تفويض A → B → A

الحل: خارجة تخزين القيم الحرجة للأمان

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

لقد صممنا EIP7702Proxy ليكون دفاعيًا ذاتيًا ضد المشكلات المتوقعة في نظام بيئي متعدد المحافظ وممكن بـ 7702 يضم فاعلين حسن النية ولكنهم قد يكونون فوضويين. لا يمكنه حماية EOAs التي تفوض deleGates خبيثة حقًا أو تحتوي على أخطاء.

تتعلق إحدى المشكلات المتوقعة بالتوقيعات لاستدعاءات setImplementation والمخاطر التي تقدمها حالة الحساب القابلة للتغيير. يعتمد EIP7702Proxy على توقيعات EOA لتعيين منطق التنفيذ وت初始化 إلى حالة آمنة. يمكن أن تصبح هذه التوقيعات مسؤوليات إذا كانت قابلة لإعادة التشغيل. على سبيل المثال، إذا كانت التوقيع يخول مالكًا أوليًا تم اختراقه لاحقًا وإزالته، فإن توقيعًا قابلاً لإعادة التشغيل يمكن أن يعيد إنشاء المالك المخترق أو يجبر على تخفيض التنفيذ.

الحماية الشائعة ضد إعادة تشغيل التوقيعات تستخدم النونسات في الرسائل الموقعة، ويتم وضع علامة عليها على أنها مستهلكة عند التحقق. خطر حسابات 7702: يمكن أن يقوم المندوبون الآخرون بخرق تخزين تتبع النونسات هذا. إذا تم مسح تتبع تخزين استخدام النونسات، يمكن إعادة تطبيق توقيع setImplementation الخاص بـ EOA (المتاح علنًا في mempool) عند التفويض مرة أخرى إلى EIP7702Proxy.

لضمان عدم إعادة استخدام التوقيع، قمنا بتنفيذ كائن NonceTracker منفصل يحتفظ بحالة nonce في موقع عقد غير قابل للتغيير خارج تخزين الحساب. يمكن فقط لـ EOA التأثير على nonces الخاصة بهم (بشكل متزايد فقط)، مما يمنع الآخرين من تعديل هذه القيم الحرجة للأمان. يضمن NonceTracker أن كل توقيع setImplementation يعمل مرة واحدة فقط، بغض النظر عن تغييرات تخزين الحساب.

التحدي رقم 3: زيادة خطر مواقع التخزين التقليدية المشتركة

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

لتوضيح المشكلة التي يتم حلها بشكل أكثر وضوحًا، لاحظ أنه عندما ينتقل حساب بين مختلف المفوضين (A→B→A) حيث يقوم كلا المفوضين بتنفيذ أنماط وكيل ERC-1967، سيستخدم المفوض B بشكل طبيعي نفس فتحة التخزين التي كان يستخدمها المفوض A لتخزين عنوان التنفيذ الخاص به. خلال فترة ولايته، قد يقوم المفوض B بتعديل أو كتابة فوق هذه الفتحة، إما عمدًا أو كجزء طبيعي من عملياته الخاصة بالوكيل. في نمط الوكيل القابل للترقية UUPS، يتم تحديد المنطق لترقية التنفيذ في عقد التنفيذ نفسه. إذا كان التنفيذ الموضوعة في مكان المؤشر هذا بواسطة المفوض B لا يحتوي على واجهة upgradeToAndCall المتوقعة في التنفيذ، فعند العودة إلى المفوض A، قد لا توجد الآلية نفسها لتغيير تنفيذها على المنطق المتاح الحالي.

مثال على استبدال موقع التخزين التقليدي المشترك بواسطة deleGate جديد

الحل: آلية الترقية متاحة على EIP7702Proxy

ي addresses EIP7702Proxy هذا من خلال دالة setImplementation الخاصة به، التي توفر آلية ترقية مستقلة عن التنفيذ مباشرة على الوكيل نفسه. هذا يضمن أنه حتى إذا كان deleGate المتداخل قد وجه تنفيذ ERC-1967 إلى تنفيذ غير صالح (أو أزالها تمامًا)، فإن EOA الأصلي، بعد أن قام بالتفويض مرة أخرى إلى EIP7702Proxy، يحتفظ بالقدرة على إعادة تكوين مؤشر ERC-1967 للوكيل إلى تنفيذهم المنطقي المختار.

التحدي #4: التوافق العكسي مع سلوك EOA القياسي

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

تحقق من التوقيع

تتمتع العقود الذكية بمعيار مختلف للتحقق من التوقيع مقارنةً بالحسابات العادية (EOAs). تنفذ العقود الذكية واجهة isValidSignature المعرفة بواسطة ERC-1271ويمكنك تعريف منطق تعسفي يحدد ما إذا كان العقد يعتبر التوقيع صالحًا. بالنسبة لـ EOAs القياسية، يتم التحقق من صحة التوقيع من خلال فحص ecrecover القياسي الذي يضمن أن الموقع يستعيد عنوان EOA المتوقع.

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

إيصال التوكن

بعض معايير الرموز (على وجه التحديد ERC-1155 و ERC-721) محاولة لحماية ضد تعطل الرموز في العقود الذكية التي قد لا تكون لديها القدرة على إدارتها. تتطلب هذه الرموز من أي عقد ذكي سيتلقى مثل هذه الرموز أن يعلن عن هذه القدرة من خلال تنفيذ واجهات استقبال الرموز القياسية التي يتم استدعاؤها من قبل عقد الرمز أثناء إرسال الرمز. من الضروري أيضًا أن تحتوي المنطق في EOA المحدث على دالة استقبال قياسية أو عودة قابلة للدفع لتكون قادرة على استقبال الرموز الأصلية. يجب ألا يكون الحساب أبدًا في حالة تتركه غير قادر على استقبال ETH أو رموز أخرى، مهما كانت فترة قصيرة.

نظرًا لأن وكيلنا يفتقر إلى تنفيذ أولي، فإننا نضمّن تنفيذ DefaultReceiver غير القابل للتغيير كمنطق افتراضي لـ EIP7702Proxy في غياب مؤشر ERC-1967. يقوم هذا المستلم بتنفيذ وظيفة استقبال وخطافات المستلم لهذه المعايير الشائعة للتوكن، مما يضمن أن الحساب يمكنه قبول تحويلات التوكن قبل تعيين تنفيذ جديد بشكل صريح.

الخاتمة

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

إخلاء المسؤولية:

1. تم إعادة طباعة هذه المقالة من [مدونة الهندسة الأساسية]. جميع حقوق الطبع والنشر تعود إلى المؤلف الأصلي [أمي كورسو]. إذا كانت هناك اعتراضات على هذا النشر، يرجى الاتصال بــتعلم البوابة الفريق، وسيقومون بمعالجته على الفور.
2. تنصل المسؤولية: الآراء والأفكار المعبر عنها في هذه المقالة هي فقط آراء الكاتب ولا تشكل أي نصيحة استثمارية.
3. ترجمات المقال إلى لغات أخرى تمت بواسطة فريق Gate Learn. ما لم يُذكر خلاف ذلك، فإن نسخ أو توزيع أو انتحال المقالات المترجمة محظور.