إثيريوم Pectra ترقية: EIP-7702 يجلب تحولاً ثورياً لـ EOA
مقدمة
سيشهد إثيريوم ترقية Pectra قريبًا، وهي تحديث ذو أهمية كبيرة، حيث سيتم إدخال العديد من اقتراحات التحسين الهامة. من بينها، فإن EIP-7702 أجرى تحولًا ثوريًا على الحساب الخارجي لإثيريوم (EOA). هذا الاقتراح ضباب الحدود بين EOA وحساب العقد CA، وهو خطوة رئيسية نحو تجريد الحسابات الأصلية بعد EIP-4337، مما يجلب نمط تفاعل جديد تمامًا إلى نظام إثيريوم البيئي.
تم نشر Pectra على شبكة الاختبار، ومن المتوقع أن يتم إطلاقها على الشبكة الرئيسية قريبًا. ستقوم هذه المقالة بتحليل آلية تنفيذ EIP-7702 بعمق، واستكشاف الفرص والتحديات المحتملة التي قد تجلبها، وتقديم إرشادات عملية للمشاركين المختلفين.
تحليل البروتوكول
نظرة عامة
EIP-7702 قدم نوع جديد من المعاملات، يسمح لـ EOA بتحديد عنوان عقد ذكي، لإعداد الكود له. هذا يمكّن EOA من تنفيذ الكود مثل العقد الذكي، مع الاحتفاظ بقدرة بدء المعاملات. هذه الميزة تمنح EOA القابلية للبرمجة والتجميع، حيث يمكن للمستخدمين تنفيذ ميزات مثل الاسترداد الاجتماعي، التحكم في الأذونات، إدارة التوقيع المتعدد، التحقق من zk، الدفع القائم على الاشتراك، رعاية المعاملات، وتجميع المعاملات. من الجدير بالذكر أن EIP-7702 متوافق تمامًا مع محفظة العقد الذكي التي تم تنفيذها بواسطة EIP-4337، حيث أن التكامل السلس بينهما يبسط بشكل كبير عملية تطوير وتطبيق الميزات الجديدة.
EIP-7702 قدم نوع المعاملة SET_CODE_TX_TYPE (0x04)، وهيكل بياناتها معرف كالتالي:
في الهيكل الجديد للتداول، باستثناء حقل authorization_list، يتبع الباقي نفس الدلالة كما هو الحال في EIP-4844. هذا الحقل هو من نوع القائمة، ويمكن أن يحتوي على عدة إدخالات تفويض، كل إدخال تفويض يحتوي على:
chain_id يشير إلى السلسلة التي يكون فيها هذا التفويض ساري المفعول
address يمثل عنوان الهدف للتفويض
يجب أن يتطابق nonce مع nonce للحساب المصرح الحالي
y_parity, r, s هي بيانات التوقيع الموقعة من قبل حساب التفويض
يمكن أن يحتوي حقل authorization_list في صفقة واحدة على عدة حسابات تفويض مختلفة ( EOA ) التي وقعت على إدخالات التفويض، أي أن مُصدر المعاملة يمكن أن يكون مختلفًا عن المفوض، من أجل تنفيذ عملية تفويض المفوض لدفع تكلفة الغاز.
تحقيق
عند توقيع البيانات من قبل المصرح, يجب أولاً ترميز chain_id و address و nonce باستخدام RLP. ثم يتم إجراء عملية تجزئة keccak256 على البيانات المشفرة مع عدد MAGIC للحصول على البيانات المراد توقيعها. أخيرًا, يتم استخدام المفتاح الخاص للمرخص لتوقيع البيانات المجزأة, للحصول على بيانات y_parity و r و s. يتم استخدام MAGIC (0x05) كفاصل حقل, والهدف هو ضمان عدم تعارض نتائج التوقيعات من أنواع مختلفة.
يجب الانتباه، عندما يكون chain_id المصرح به من قبل المصرح 0، فهذا يعني أن المصرح يسمح بإعادة استخدام التفويض ( على جميع سلاسل EVM المتوافقة التي تدعم EIP-7702 بشرط أن يتطابق nonce أيضًا مع ).
بعد أن يوقع الموكل بيانات التفويض، سيجمع مبادر المعاملة هذه البيانات في حقل authorization_list للتوقيع ويقوم ببث المعاملة عبر RPC. قبل تضمين المعاملة في الكتلة وتنفيذها، سيقوم المقترح بإجراء فحص مسبق للمعاملة، حيث يتم فحص عنوان to بشكل إلزامي للتأكد من أن هذه المعاملة ليست معاملة إنشاء عقد، أي أنه عند إرسال معاملة من نوع EIP-7702، يجب ألا يكون عنوان to فارغاً.
في الوقت نفسه، تتطلب هذه المعاملات بشكل إلزامي أن يحتوي حقل authorization_list على عنصر تفويض واحد على الأقل، وإذا كانت هناك عدة عناصر تفويض موقعة من قبل نفس المفوض، فإن العنصر الأخير فقط هو الذي يصبح ساري المفعول.
خلال تنفيذ المعاملة، سيقوم العقد أولاً بزيادة قيمة nonce للجهة المرسلة للمعاملة، ثم يقوم بتنفيذ عملية applyAuthorization لكل إدخال تفويض في authorization_list. في عملية applyAuthorization، سيتحقق العقد أولاً من nonce للموكل، ثم يزيد nonce للموكل. هذا يعني أنه إذا كانت الجهة المرسلة للمعاملة والموكل هما نفس المستخدم (EOA)، فيجب أن تكون قيمة nonce عند توقيع معاملة التفويض مضافة إليها 1.
عند تطبيق العقدة لأي إدخال تفويض معين، إذا واجهت أي خطأ، سيتم تخطي هذا الإدخال، ولن تفشل المعاملة، وستستمر إدخالات التفويض الأخرى في التطبيق، لضمان عدم ظهور مخاطر DoS في سيناريو التفويض بالجملة.
بعد الانتهاء من تطبيق التفويض، سيتم تعيين حقل code لعنوان المفوض إلى 0xef0100 || address، حيث 0xef0100 هو معرف ثابت، وaddress هو عنوان التفويض المستهدف. بسبب قيود EIP-3541، لا يمكن للمستخدمين نشر شفرة العقد التي تبدأ بـ 0xef بالطريقة المعتادة، مما يضمن أن هذا النوع من المعرفات يمكن نشره فقط بواسطة معاملات من نوع SET_CODE_TX_TYPE ( 0x04).
بعد اكتمال التفويض، إذا أراد المفوض إلغاء التفويض، فما عليه سوى تعيين عنوان الهدف المفوض إلى عنوان 0.
من خلال نوع المعاملة الجديد الذي تم تقديمه عبر EIP-7702، يسمح للموكل (EOA) بتنفيذ التعليمات البرمجية مثل العقود الذكية، مع الاحتفاظ بقدرة بدء المعاملات. مقارنةً بـ EIP-4337، يوفر هذا للمستخدمين تجربة أقرب إلى تجريد الحسابات الأصلية (Native AA)، مما يقلل بشكل كبير من عتبة استخدام المستخدمين.
أفضل الممارسات
على الرغم من أن EIP-7702 قد أضفى حيوية جديدة على إثيريوم، إلا أن السيناريوهات الجديدة ستجلب أيضًا مخاطر جديدة. فيما يلي الجوانب التي يجب أن يكون المشاركون في النظام الإيكولوجي حذرين منها أثناء الممارسة:
تخزين المفتاح الخاص
حتى مع إمكانية استخدام EOA لطرق مثل الاسترداد الاجتماعي المدمجة في العقود الذكية لحل مشكلة فقدان الأموال بسبب فقدان المفتاح الخاص بعد التفويض، إلا أنه لا يمكن تجنب مخاطر تسرب مفتاح EOA. من المهم توضيح أنه بعد تنفيذ التفويض، لا يزال مفتاح EOA يمتلك أعلى سلطة على الحساب، حيث يمكن لأي شخص يمتلك المفتاح التصرف بحرية في الأصول الموجودة في الحساب. بعد أن يكمل المستخدم أو مزود خدمة المحفظة التفويض لـ EOA، حتى مع الحذف الكامل للمفتاح الخاص المخزن محليًا، لا يمكن القضاء تمامًا على مخاطر تسرب المفتاح الخاص، خاصة في السيناريوهات التي يوجد فيها مخاطر هجوم سلسلة التوريد.
بالنسبة للمستخدمين، عند استخدام الحسابات بعد التفويض، يجب عليهم دائمًا وضع حماية المفاتيح الخاصة في المقام الأول، والانتباه دائمًا: Not your keys, not your coins.
إعادة تشغيل متعددة السلاسل
عند توقيع المستخدم على تفويض التفويض، يمكنه اختيار سلسلة التفويض الفعالة من خلال chainId، كما يمكنه اختيار استخدام chainId = 0 للتفويض، مما يسمح بالتفويض بالعمل عبر سلاسل متعددة، مما يسهل على المستخدم إجراء التفويض بتوقيع واحد فقط على عدة سلاسل. ولكن يجب الانتباه إلى أنه في عنوان العقد نفسه على سلاسل متعددة، قد توجد شيفرات تنفيذ مختلفة.
بالنسبة لمزودي خدمات المحفظة، عند قيام المستخدم بالتفويض، يجب التحقق من توافق سلسلة التفويض الفعالة مع الشبكة المتصلة الحالية، وإخطار المستخدم بالمخاطر المحتملة الناتجة عن توقيع التفويض الذي يكون فيه chainId 0.
يجب على المستخدمين أيضًا أن يلاحظوا أن عنوان العقد نفسه على سلاسل مختلفة قد لا تكون له نفس الشفرة العقدية، ويجب عليهم فهم الهدف من التفويض بوضوح أولاً.
غير قادر على التهيئة
تستخدم معظم محافظ العقود الذكية الرائجة حالياً نموذج الوكيل، حيث يقوم وكيل المحفظة عند نشره باستدعاء دالة التهيئة للعقد من خلال DELEGateCALL، وذلك لتحقيق عملية تهيئة المحفظة ونشر الوكيل بشكل ذري، مما يتجنب مشكلة التهيئة المسبقة. لكن عند استخدام المستخدم لـ EIP-7702 للتفويض، سيتم تحديث حقل code فقط لعنوانه، ولن يتمكن من تهيئة العقد عن طريق استدعاء عنوان التفويض. وهذا يجعل EIP-7702 غير قادر على استدعاء دالة التهيئة لتكوين المحفظة في صفقة نشر العقد كما هو الحال مع عقود الوكيل الشائعة ERC-1967.
بالنسبة للمطورين، عند دمج EIP-7702 مع محافظ EIP-4337 الحالية، يجب الانتباه إلى إجراء فحص الأذونات في عملية تهيئة المحفظة، على سبيل المثال، من خلال استعادة عنوان التوقيع باستخدام ecrecover لإجراء فحص الأذونات، لتجنب مخاطر استباق عملية تهيئة المحفظة.
( إدارة التخزين
عند استخدام المستخدمين وظيفة التفويض EIP-7702، قد يحتاجون إلى إعادة التفويض إلى عنوان عقد مختلف بسبب تغييرات في متطلبات الوظيفة أو تحديثات المحفظة. ولكن قد تكون هناك اختلافات في بنية التخزين للعقود المختلفة )، مثل أن الفتحة slot0 لعقد مختلف قد تمثل أنواعًا مختلفة من البيانات ###، وفي حالة إعادة التفويض، قد يؤدي ذلك إلى إعادة استخدام العقد الجديد للبيانات القديمة دون قصد، مما قد يؤدي إلى قفل الحسابات، وفقدان الأموال، وغيرها من العواقب السلبية.
بالنسبة للمستخدمين، يجب التعامل بحذر مع حالات إعادة التفويض.
بالنسبة للمطورين، يجب اتباع صيغة Namespace التي اقترحتها ERC-7201 خلال عملية التطوير، لتخصيص المتغيرات إلى مواقع تخزين مستقلة محددة، لتخفيف مخاطر تعارض التخزين. بالإضافة إلى ذلك، قدمت ERC-7779 (draft) عملية إعادة تفويض قياسية مصممة خصيصًا لـ EIP-7702: تشمل استخدام ERC-7201 لمنع تعارض التخزين، والتحقق من توافق التخزين قبل إعادة التفويض، فضلاً عن استدعاء واجهة التفويض القديمة لتنظيف البيانات القديمة المخزنة.
( شحن وهمي
بعد أن يقوم المستخدم بالتفويض، ستتمكن EOA أيضًا من استخدامها كعقد ذكي، وبالتالي قد تواجه بورصات مركزية )CEX### حالة تعميم إعادة شحن العقود الذكية.
يجب على CEX التحقق من حالة كل عملية إيداع من خلال trace، لمنع مخاطر الإيداع الوهمي للعقود الذكية.
( تحويل الحساب
بعد تنفيذ تفويض EIP-7702، يمكن لنوع حسابات المستخدمين التحويل بحرية بين EOA و SC، مما يتيح للحسابات إمكانية بدء المعاملات وكذلك أن يتم استدعاؤها. وهذا يعني أنه عندما يستدعي الحساب نفسه ويقوم باستدعاء خارجي، سيكون msg.sender هو tx.origin، مما سيكسر بعض الفرضيات الأمنية التي تقتصر على مشاركة EOA في المشاريع.
بالنسبة لمطوري العقود، فإن الافتراض بأن tx.origin هو دائمًا EOA لن يكون ممكنًا بعد الآن. وبالمثل، فإن استخدام فحص msg.sender == tx.origin للدفاع ضد هجمات إعادة الدخول سيكون غير فعّال أيضًا.
يجب على المطورين في عملية التطوير أن يفترضوا أن المشاركين في المستقبل قد يكونون جميعًا عقودًا ذكية.
) توافق العقد
تتمتع الرموز الحالية ERC-721 وERC-777 بوظيفة Hook عند إجراء التحويلات إلى العقود، مما يعني أن المستلم يجب أن ينفذ وظيفة الاستدعاء المناسبة لاستلام الرموز بنجاح.
بالنسبة للمطورين، يجب أن تحقق العقود المستهدفة التي يفوضها المستخدم الوظائف الاسترجاعية المناسبة لضمان التوافق مع الرموز الرئيسية.
فحص الصيد
بعد تنفيذ تفويض EIP-7702، قد يتم التحكم في الأصول في حسابات المستخدمين بواسطة العقود الذكية، وبمجرد أن يفوض المستخدم حسابه إلى عقد خبيث، سيصبح من السهل على المهاجمين سرقة الأموال.
بالنسبة لمزودي خدمات المحفظة، من المهم دعم معاملات من نوع EIP-7702 في أقرب وقت ممكن، وعند قيام المستخدمين بالتوقيع بالتفويض، يجب عليهم عرض العقد المستهدف بوضوح للمستخدمين، لتخفيف مخاطر التعرض لهجمات التصيد.
بالإضافة إلى ذلك، فإن إجراء تحليل تلقائي أعمق لعقد الهدف المفوض للحساب ### وفحص المصدر، وفحص الأذونات، وما إلى ذلك ### يمكن أن يساعد المستخدمين بشكل أفضل في تجنب مثل هذه المخاطر.
ملخص
تتناول هذه المقالة اقتراح EIP-7702 في ترقية Pectra القادمة الخاصة بإثيريوم. من خلال تقديم نوع جديد من المعاملات، فإن EIP-7702 يمنح حسابات المستخدمين القدرة على البرمجة والتركيب، مما يblur الحدود بين حسابات المستخدمين وحسابات العقود. نظرًا لعدم وجود معيار لعقود ذكية متوافقة مع نوع EIP-7702 تم اختباره في المعارك، فإن المشاركين المختلفين في النظام البيئي، مثل المستخدمين ومزودي خدمات المحفظة والمطورين ومنصات التداول المركزية، يواجهون العديد من التحديات والفرص في التطبيق العملي. المحتوى المتعلق بأفضل الممارسات التي تم تناولها في هذه المقالة لا يمكن أن يغطي جميع المخاطر المحتملة، ولكنه لا يزال يستحق أن يحتذى به من قبل جميع الأطراف في العمليات الفعلية.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 17
أعجبني
17
9
إعادة النشر
مشاركة
تعليق
0/400
notSatoshi1971
· 07-26 08:08
قبل أن يبدأ السوق في الارتفاع، يجب أن نكون في الترصد في الكمين. 7702必起飞
شاهد النسخة الأصليةرد0
0xSunnyDay
· 07-24 10:37
هذا التحديث قوي جدًا 8 اندفع
شاهد النسخة الأصليةرد0
BasementAlchemist
· 07-23 13:37
هل هناك موجة جديدة من تجديد حساب العقود؟ هذا غير منطقي جداً.
شاهد النسخة الأصليةرد0
MEVHunterX
· 07-23 13:21
هذه هي القصة التالية لـ 4337 ~ إنها رائعة، دعنا نذهب!
شاهد النسخة الأصليةرد0
PanicSeller69
· 07-23 13:20
一看就要 الارتفاع咯 啥时候开始 شراء الانخفاضv神
شاهد النسخة الأصليةرد0
FastLeaver
· 07-23 13:14
مرة أخرى ترقية?? Rug Pull تحذير
شاهد النسخة الأصليةرد0
PerennialLeek
· 07-23 13:12
ارتفعت عدة مرات، من يفهم يفهم
شاهد النسخة الأصليةرد0
WinterWarmthCat
· 07-23 13:12
قالت ماكينة الصرافة هل تم ترقية جديدة؟ دعنا نتحدث عن سحب الأموال.
شاهد النسخة الأصليةرد0
Web3ExplorerLin
· 07-23 13:07
مثير للاهتمام... قد تكون eip-7702 القفزة الكمومية التي تحتاجها الإيثيريوم الآن
ترقية إثيريوم Pectra: EIP-7702 ضبابية حدود EOA و CA تفتح عصر جديد من تجريد الحسابات الأصلية
إثيريوم Pectra ترقية: EIP-7702 يجلب تحولاً ثورياً لـ EOA
مقدمة
سيشهد إثيريوم ترقية Pectra قريبًا، وهي تحديث ذو أهمية كبيرة، حيث سيتم إدخال العديد من اقتراحات التحسين الهامة. من بينها، فإن EIP-7702 أجرى تحولًا ثوريًا على الحساب الخارجي لإثيريوم (EOA). هذا الاقتراح ضباب الحدود بين EOA وحساب العقد CA، وهو خطوة رئيسية نحو تجريد الحسابات الأصلية بعد EIP-4337، مما يجلب نمط تفاعل جديد تمامًا إلى نظام إثيريوم البيئي.
تم نشر Pectra على شبكة الاختبار، ومن المتوقع أن يتم إطلاقها على الشبكة الرئيسية قريبًا. ستقوم هذه المقالة بتحليل آلية تنفيذ EIP-7702 بعمق، واستكشاف الفرص والتحديات المحتملة التي قد تجلبها، وتقديم إرشادات عملية للمشاركين المختلفين.
تحليل البروتوكول
نظرة عامة
EIP-7702 قدم نوع جديد من المعاملات، يسمح لـ EOA بتحديد عنوان عقد ذكي، لإعداد الكود له. هذا يمكّن EOA من تنفيذ الكود مثل العقد الذكي، مع الاحتفاظ بقدرة بدء المعاملات. هذه الميزة تمنح EOA القابلية للبرمجة والتجميع، حيث يمكن للمستخدمين تنفيذ ميزات مثل الاسترداد الاجتماعي، التحكم في الأذونات، إدارة التوقيع المتعدد، التحقق من zk، الدفع القائم على الاشتراك، رعاية المعاملات، وتجميع المعاملات. من الجدير بالذكر أن EIP-7702 متوافق تمامًا مع محفظة العقد الذكي التي تم تنفيذها بواسطة EIP-4337، حيث أن التكامل السلس بينهما يبسط بشكل كبير عملية تطوير وتطبيق الميزات الجديدة.
EIP-7702 قدم نوع المعاملة SET_CODE_TX_TYPE (0x04)، وهيكل بياناتها معرف كالتالي:
rlp( [chain_id ، nonce ، max_priority_fee_per_gas ، max_fee_per_gas ، gas_limit ، الوجهة ، القيمة ، البيانات ، access_list ، authorization_list ، signature_y_parity ، signature_r ، signature_s])
حقل authorization_list يُعرَّف على أنه:
authorization_list = [[chain_id ، العنوان ، nonce ، y_parity ، r ، s] ، ...]
في الهيكل الجديد للتداول، باستثناء حقل authorization_list، يتبع الباقي نفس الدلالة كما هو الحال في EIP-4844. هذا الحقل هو من نوع القائمة، ويمكن أن يحتوي على عدة إدخالات تفويض، كل إدخال تفويض يحتوي على:
يمكن أن يحتوي حقل authorization_list في صفقة واحدة على عدة حسابات تفويض مختلفة ( EOA ) التي وقعت على إدخالات التفويض، أي أن مُصدر المعاملة يمكن أن يكون مختلفًا عن المفوض، من أجل تنفيذ عملية تفويض المفوض لدفع تكلفة الغاز.
تحقيق
عند توقيع البيانات من قبل المصرح, يجب أولاً ترميز chain_id و address و nonce باستخدام RLP. ثم يتم إجراء عملية تجزئة keccak256 على البيانات المشفرة مع عدد MAGIC للحصول على البيانات المراد توقيعها. أخيرًا, يتم استخدام المفتاح الخاص للمرخص لتوقيع البيانات المجزأة, للحصول على بيانات y_parity و r و s. يتم استخدام MAGIC (0x05) كفاصل حقل, والهدف هو ضمان عدم تعارض نتائج التوقيعات من أنواع مختلفة.
يجب الانتباه، عندما يكون chain_id المصرح به من قبل المصرح 0، فهذا يعني أن المصرح يسمح بإعادة استخدام التفويض ( على جميع سلاسل EVM المتوافقة التي تدعم EIP-7702 بشرط أن يتطابق nonce أيضًا مع ).
بعد أن يوقع الموكل بيانات التفويض، سيجمع مبادر المعاملة هذه البيانات في حقل authorization_list للتوقيع ويقوم ببث المعاملة عبر RPC. قبل تضمين المعاملة في الكتلة وتنفيذها، سيقوم المقترح بإجراء فحص مسبق للمعاملة، حيث يتم فحص عنوان to بشكل إلزامي للتأكد من أن هذه المعاملة ليست معاملة إنشاء عقد، أي أنه عند إرسال معاملة من نوع EIP-7702، يجب ألا يكون عنوان to فارغاً.
في الوقت نفسه، تتطلب هذه المعاملات بشكل إلزامي أن يحتوي حقل authorization_list على عنصر تفويض واحد على الأقل، وإذا كانت هناك عدة عناصر تفويض موقعة من قبل نفس المفوض، فإن العنصر الأخير فقط هو الذي يصبح ساري المفعول.
خلال تنفيذ المعاملة، سيقوم العقد أولاً بزيادة قيمة nonce للجهة المرسلة للمعاملة، ثم يقوم بتنفيذ عملية applyAuthorization لكل إدخال تفويض في authorization_list. في عملية applyAuthorization، سيتحقق العقد أولاً من nonce للموكل، ثم يزيد nonce للموكل. هذا يعني أنه إذا كانت الجهة المرسلة للمعاملة والموكل هما نفس المستخدم (EOA)، فيجب أن تكون قيمة nonce عند توقيع معاملة التفويض مضافة إليها 1.
عند تطبيق العقدة لأي إدخال تفويض معين، إذا واجهت أي خطأ، سيتم تخطي هذا الإدخال، ولن تفشل المعاملة، وستستمر إدخالات التفويض الأخرى في التطبيق، لضمان عدم ظهور مخاطر DoS في سيناريو التفويض بالجملة.
بعد الانتهاء من تطبيق التفويض، سيتم تعيين حقل code لعنوان المفوض إلى 0xef0100 || address، حيث 0xef0100 هو معرف ثابت، وaddress هو عنوان التفويض المستهدف. بسبب قيود EIP-3541، لا يمكن للمستخدمين نشر شفرة العقد التي تبدأ بـ 0xef بالطريقة المعتادة، مما يضمن أن هذا النوع من المعرفات يمكن نشره فقط بواسطة معاملات من نوع SET_CODE_TX_TYPE ( 0x04).
بعد اكتمال التفويض، إذا أراد المفوض إلغاء التفويض، فما عليه سوى تعيين عنوان الهدف المفوض إلى عنوان 0.
من خلال نوع المعاملة الجديد الذي تم تقديمه عبر EIP-7702، يسمح للموكل (EOA) بتنفيذ التعليمات البرمجية مثل العقود الذكية، مع الاحتفاظ بقدرة بدء المعاملات. مقارنةً بـ EIP-4337، يوفر هذا للمستخدمين تجربة أقرب إلى تجريد الحسابات الأصلية (Native AA)، مما يقلل بشكل كبير من عتبة استخدام المستخدمين.
أفضل الممارسات
على الرغم من أن EIP-7702 قد أضفى حيوية جديدة على إثيريوم، إلا أن السيناريوهات الجديدة ستجلب أيضًا مخاطر جديدة. فيما يلي الجوانب التي يجب أن يكون المشاركون في النظام الإيكولوجي حذرين منها أثناء الممارسة:
تخزين المفتاح الخاص
حتى مع إمكانية استخدام EOA لطرق مثل الاسترداد الاجتماعي المدمجة في العقود الذكية لحل مشكلة فقدان الأموال بسبب فقدان المفتاح الخاص بعد التفويض، إلا أنه لا يمكن تجنب مخاطر تسرب مفتاح EOA. من المهم توضيح أنه بعد تنفيذ التفويض، لا يزال مفتاح EOA يمتلك أعلى سلطة على الحساب، حيث يمكن لأي شخص يمتلك المفتاح التصرف بحرية في الأصول الموجودة في الحساب. بعد أن يكمل المستخدم أو مزود خدمة المحفظة التفويض لـ EOA، حتى مع الحذف الكامل للمفتاح الخاص المخزن محليًا، لا يمكن القضاء تمامًا على مخاطر تسرب المفتاح الخاص، خاصة في السيناريوهات التي يوجد فيها مخاطر هجوم سلسلة التوريد.
بالنسبة للمستخدمين، عند استخدام الحسابات بعد التفويض، يجب عليهم دائمًا وضع حماية المفاتيح الخاصة في المقام الأول، والانتباه دائمًا: Not your keys, not your coins.
إعادة تشغيل متعددة السلاسل
عند توقيع المستخدم على تفويض التفويض، يمكنه اختيار سلسلة التفويض الفعالة من خلال chainId، كما يمكنه اختيار استخدام chainId = 0 للتفويض، مما يسمح بالتفويض بالعمل عبر سلاسل متعددة، مما يسهل على المستخدم إجراء التفويض بتوقيع واحد فقط على عدة سلاسل. ولكن يجب الانتباه إلى أنه في عنوان العقد نفسه على سلاسل متعددة، قد توجد شيفرات تنفيذ مختلفة.
بالنسبة لمزودي خدمات المحفظة، عند قيام المستخدم بالتفويض، يجب التحقق من توافق سلسلة التفويض الفعالة مع الشبكة المتصلة الحالية، وإخطار المستخدم بالمخاطر المحتملة الناتجة عن توقيع التفويض الذي يكون فيه chainId 0.
يجب على المستخدمين أيضًا أن يلاحظوا أن عنوان العقد نفسه على سلاسل مختلفة قد لا تكون له نفس الشفرة العقدية، ويجب عليهم فهم الهدف من التفويض بوضوح أولاً.
غير قادر على التهيئة
تستخدم معظم محافظ العقود الذكية الرائجة حالياً نموذج الوكيل، حيث يقوم وكيل المحفظة عند نشره باستدعاء دالة التهيئة للعقد من خلال DELEGateCALL، وذلك لتحقيق عملية تهيئة المحفظة ونشر الوكيل بشكل ذري، مما يتجنب مشكلة التهيئة المسبقة. لكن عند استخدام المستخدم لـ EIP-7702 للتفويض، سيتم تحديث حقل code فقط لعنوانه، ولن يتمكن من تهيئة العقد عن طريق استدعاء عنوان التفويض. وهذا يجعل EIP-7702 غير قادر على استدعاء دالة التهيئة لتكوين المحفظة في صفقة نشر العقد كما هو الحال مع عقود الوكيل الشائعة ERC-1967.
بالنسبة للمطورين، عند دمج EIP-7702 مع محافظ EIP-4337 الحالية، يجب الانتباه إلى إجراء فحص الأذونات في عملية تهيئة المحفظة، على سبيل المثال، من خلال استعادة عنوان التوقيع باستخدام ecrecover لإجراء فحص الأذونات، لتجنب مخاطر استباق عملية تهيئة المحفظة.
( إدارة التخزين
عند استخدام المستخدمين وظيفة التفويض EIP-7702، قد يحتاجون إلى إعادة التفويض إلى عنوان عقد مختلف بسبب تغييرات في متطلبات الوظيفة أو تحديثات المحفظة. ولكن قد تكون هناك اختلافات في بنية التخزين للعقود المختلفة )، مثل أن الفتحة slot0 لعقد مختلف قد تمثل أنواعًا مختلفة من البيانات ###، وفي حالة إعادة التفويض، قد يؤدي ذلك إلى إعادة استخدام العقد الجديد للبيانات القديمة دون قصد، مما قد يؤدي إلى قفل الحسابات، وفقدان الأموال، وغيرها من العواقب السلبية.
بالنسبة للمستخدمين، يجب التعامل بحذر مع حالات إعادة التفويض.
بالنسبة للمطورين، يجب اتباع صيغة Namespace التي اقترحتها ERC-7201 خلال عملية التطوير، لتخصيص المتغيرات إلى مواقع تخزين مستقلة محددة، لتخفيف مخاطر تعارض التخزين. بالإضافة إلى ذلك، قدمت ERC-7779 (draft) عملية إعادة تفويض قياسية مصممة خصيصًا لـ EIP-7702: تشمل استخدام ERC-7201 لمنع تعارض التخزين، والتحقق من توافق التخزين قبل إعادة التفويض، فضلاً عن استدعاء واجهة التفويض القديمة لتنظيف البيانات القديمة المخزنة.
( شحن وهمي
بعد أن يقوم المستخدم بالتفويض، ستتمكن EOA أيضًا من استخدامها كعقد ذكي، وبالتالي قد تواجه بورصات مركزية )CEX### حالة تعميم إعادة شحن العقود الذكية.
يجب على CEX التحقق من حالة كل عملية إيداع من خلال trace، لمنع مخاطر الإيداع الوهمي للعقود الذكية.
( تحويل الحساب
بعد تنفيذ تفويض EIP-7702، يمكن لنوع حسابات المستخدمين التحويل بحرية بين EOA و SC، مما يتيح للحسابات إمكانية بدء المعاملات وكذلك أن يتم استدعاؤها. وهذا يعني أنه عندما يستدعي الحساب نفسه ويقوم باستدعاء خارجي، سيكون msg.sender هو tx.origin، مما سيكسر بعض الفرضيات الأمنية التي تقتصر على مشاركة EOA في المشاريع.
بالنسبة لمطوري العقود، فإن الافتراض بأن tx.origin هو دائمًا EOA لن يكون ممكنًا بعد الآن. وبالمثل، فإن استخدام فحص msg.sender == tx.origin للدفاع ضد هجمات إعادة الدخول سيكون غير فعّال أيضًا.
يجب على المطورين في عملية التطوير أن يفترضوا أن المشاركين في المستقبل قد يكونون جميعًا عقودًا ذكية.
) توافق العقد
تتمتع الرموز الحالية ERC-721 وERC-777 بوظيفة Hook عند إجراء التحويلات إلى العقود، مما يعني أن المستلم يجب أن ينفذ وظيفة الاستدعاء المناسبة لاستلام الرموز بنجاح.
بالنسبة للمطورين، يجب أن تحقق العقود المستهدفة التي يفوضها المستخدم الوظائف الاسترجاعية المناسبة لضمان التوافق مع الرموز الرئيسية.
فحص الصيد
بعد تنفيذ تفويض EIP-7702، قد يتم التحكم في الأصول في حسابات المستخدمين بواسطة العقود الذكية، وبمجرد أن يفوض المستخدم حسابه إلى عقد خبيث، سيصبح من السهل على المهاجمين سرقة الأموال.
بالنسبة لمزودي خدمات المحفظة، من المهم دعم معاملات من نوع EIP-7702 في أقرب وقت ممكن، وعند قيام المستخدمين بالتوقيع بالتفويض، يجب عليهم عرض العقد المستهدف بوضوح للمستخدمين، لتخفيف مخاطر التعرض لهجمات التصيد.
بالإضافة إلى ذلك، فإن إجراء تحليل تلقائي أعمق لعقد الهدف المفوض للحساب ### وفحص المصدر، وفحص الأذونات، وما إلى ذلك ### يمكن أن يساعد المستخدمين بشكل أفضل في تجنب مثل هذه المخاطر.
ملخص
تتناول هذه المقالة اقتراح EIP-7702 في ترقية Pectra القادمة الخاصة بإثيريوم. من خلال تقديم نوع جديد من المعاملات، فإن EIP-7702 يمنح حسابات المستخدمين القدرة على البرمجة والتركيب، مما يblur الحدود بين حسابات المستخدمين وحسابات العقود. نظرًا لعدم وجود معيار لعقود ذكية متوافقة مع نوع EIP-7702 تم اختباره في المعارك، فإن المشاركين المختلفين في النظام البيئي، مثل المستخدمين ومزودي خدمات المحفظة والمطورين ومنصات التداول المركزية، يواجهون العديد من التحديات والفرص في التطبيق العملي. المحتوى المتعلق بأفضل الممارسات التي تم تناولها في هذه المقالة لا يمكن أن يغطي جميع المخاطر المحتملة، ولكنه لا يزال يستحق أن يحتذى به من قبل جميع الأطراف في العمليات الفعلية.