إثيريوم على وشك استقبال ترقية 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 تشير إلى السلسلة التي يتم تفعيل هذا التفويض عليها
العنوان يشير إلى عنوان الهدف للتفويض
يجب أن يتطابق 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 أيضًا من العمل كعقد ذكي، لذا قد تواجه البورصات حالة من انتشار إعادة شحن العقود الذكية.
يجب على البورصة التحقق من حالة كل عملية إيداع من خلال 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 من خلال إدخال نوع جديد من المعاملات، إمكانية برمجة وتكوين EOA، مما يblur الحدود بين EOA وحسابات العقود. نظرًا لعدم وجود معيار لعقود ذكية متوافقة مع نوع EIP-7702 تم اختباره في المعارك حتى الآن، يواجه المشاركون المختلفون في النظام البيئي، مثل المستخدمين، مزودي خدمات المحافظ، المطورين، والبورصات، العديد من التحديات والفرص في التطبيقات العملية. المحتوى الذي تم توضيحه في هذه المقالة حول أفضل الممارسات لا يمكن أن يغطي جميع المخاطر المحتملة، ولكنه يستحق أن يتم الاستفادة منه من قبل جميع الأطراف في العمليات الفعلية.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 6
أعجبني
6
5
مشاركة
تعليق
0/400
PermabullPete
· منذ 19 س
التوافق مع الفكرة就卷 دفاتر الطلبات又得炸咯
شاهد النسخة الأصليةرد0
StablecoinEnjoyer
· منذ 19 س
لقد تقدمنا قليلاً، أشعر أن فيتاليك بوتيرين يقوم بشيء كبير مرة أخرى.
شاهد النسخة الأصليةرد0
Token_Sherpa
· منذ 19 س
مه... اقتراح آخر لن يحل المشاكل الحقيقية للإيثيريم بصراحة
تحليل عميق لـ EIP-7702: ترقية إثيريوم Pectra ستجعل الحدود بين EOA و CA غير واضحة
إثيريوم Pectra ترقية: EIP-7702 تحليل العمق
المقدمة
إثيريوم على وشك استقبال ترقية 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 أيضًا من العمل كعقد ذكي، لذا قد تواجه البورصات حالة من انتشار إعادة شحن العقود الذكية.
يجب على البورصة التحقق من حالة كل عملية إيداع من خلال 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 من خلال إدخال نوع جديد من المعاملات، إمكانية برمجة وتكوين EOA، مما يblur الحدود بين EOA وحسابات العقود. نظرًا لعدم وجود معيار لعقود ذكية متوافقة مع نوع EIP-7702 تم اختباره في المعارك حتى الآن، يواجه المشاركون المختلفون في النظام البيئي، مثل المستخدمين، مزودي خدمات المحافظ، المطورين، والبورصات، العديد من التحديات والفرص في التطبيقات العملية. المحتوى الذي تم توضيحه في هذه المقالة حول أفضل الممارسات لا يمكن أن يغطي جميع المخاطر المحتملة، ولكنه يستحق أن يتم الاستفادة منه من قبل جميع الأطراف في العمليات الفعلية.