إثيريوم 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)، وهيكل بياناته محدد على النحو التالي:
في الهيكل الجديد للتداول، بخلاف حقل 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 في سيناريوهات التفويض الجماعي.
بعد اكتمال تطبيق التفويض، سيتم تعيين حقل الكود لعنوان المفوض إلى 0xef0100 || العنوان، حيث 0xef0100 هو معرف ثابت، والعنوان هو عنوان التفويض المستهدف. نظرًا لقيود 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 نوعًا جديدًا من المعاملات، مما يمنح EOA القابلية للبرمجة والتوافق، ويجعل الحدود بين EOA وحسابات العقود غير واضحة. نظرًا لعدم وجود معيار لعقود ذكية متوافقة مع EIP-7702 تم اختباره في الميدان حتى الآن، فإن المشاركين المختلفين في النظام البيئي، مثل المستخدمين، ومزودي خدمات المحفظة، والمطورين، وCEX، يواجهون العديد من التحديات والفرص في التطبيق العملي. إن المحتوى المتعلق بأفضل الممارسات الذي تم توضيحه في هذه المقالة لا يمكن أن يشمل جميع المخاطر المحتملة، لكنه لا يزال يستحق أن تستفيد منه الأطراف في العمليات الفعلية.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 14
أعجبني
14
5
مشاركة
تعليق
0/400
ser_ngmi
· 07-21 20:33
نسخ الواجب صار مملًا، أليس فقط من أجل الحصول على eoa و ca؟
شاهد النسخة الأصليةرد0
ParanoiaKing
· 07-20 23:50
مجموعة أخرى من التحديثات الصعبة الفهم، لا أستطيع التعبير عن ذلك.
شاهد النسخة الأصليةرد0
YieldHunter
· 07-20 23:49
تقنيًا، يبدو أن هذا EIP مشبوه قليلاً... هل هناك أي بيانات عن تكاليف معاملات الشبكة التجريبية؟
شاهد النسخة الأصليةرد0
EyeOfTheTokenStorm
· 07-20 23:26
هل هي فرصة جديدة للتخطيط المسبق؟ من خلال البيانات التاريخية، عادةً ما يرتفع eth بعد الترقية، لكن السوق يبدو أنه يحتوي على بعض الفقاعة.
شاهد النسخة الأصليةرد0
SchrodingerPrivateKey
· 07-20 23:23
يوجد EIP جديد آخر، وقد جاء حساب العقد النسخة المجانية.
تحليل EIP-7702: كيف يمنح ترقية إيثر بكترا قابلية البرمجة لـ EOA
إثيريوم 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 في سيناريوهات التفويض الجماعي.
بعد اكتمال تطبيق التفويض، سيتم تعيين حقل الكود لعنوان المفوض إلى 0xef0100 || العنوان، حيث 0xef0100 هو معرف ثابت، والعنوان هو عنوان التفويض المستهدف. نظرًا لقيود 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 نوعًا جديدًا من المعاملات، مما يمنح EOA القابلية للبرمجة والتوافق، ويجعل الحدود بين EOA وحسابات العقود غير واضحة. نظرًا لعدم وجود معيار لعقود ذكية متوافقة مع EIP-7702 تم اختباره في الميدان حتى الآن، فإن المشاركين المختلفين في النظام البيئي، مثل المستخدمين، ومزودي خدمات المحفظة، والمطورين، وCEX، يواجهون العديد من التحديات والفرص في التطبيق العملي. إن المحتوى المتعلق بأفضل الممارسات الذي تم توضيحه في هذه المقالة لا يمكن أن يشمل جميع المخاطر المحتملة، لكنه لا يزال يستحق أن تستفيد منه الأطراف في العمليات الفعلية.