إثيريوم 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. هذا الحقل هو نوع قائمة، حيث يمكن أن تحتوي القائمة على عدة إدخالات تفويض، في كل إدخال تفويض:

• حقل 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) القدرة على البرمجة والتنظيم، مما يblur الحدود بين EOA وحسابات العقود. نظرًا لعدم وجود معيار عقود ذكية متوافق مع نوع EIP-7702 قد تم اختباره في الممارسة العملية حتى الآن، فإن المشاركين في النظام البيئي المختلفين، مثل المستخدمين ومزودي خدمات المحفظة والمطورين والبورصات المركزية (CEX) يواجهون العديد من التحديات والفرص في التطبيقات العملية. المحتوى المتعلق بأفضل الممارسات الموضح في هذه المقالة لا يمكن أن يغطي جميع المخاطر المحتملة، ولكنه لا يزال يستحق أن يتم الاقتباس منه وتطبيقه من قبل جميع الأطراف في العمليات الفعلية.