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

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

! تعيين رمز حساب EOA

! رمز حساب EOA غير المحدد