إثيريوم 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 تشير إلى السلسلة التي يتم تفعيل هذه التفويضات بها
• العنوان يمثل عنوان الهدف للتفويض
• يجب أن يتطابق 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 لضمان أن هذه المعاملة ليست معاملة إنشاء عقد.

في الوقت نفسه، تتطلب هذه الأنواع من المعاملات أن يحتوي حقل 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 تم اختباره في الممارسة العملية، يواجه المشاركون في النظام البيئي المختلفون، مثل المستخدمين ومقدمي خدمات المحافظ والمطورين والبورصات، العديد من التحديات والفرص. المحتوى المقدم حول الممارسات المثلى في هذه المقالة لا يمكن أن يغطي جميع المخاطر المحتملة، ولكنه لا يزال يستحق الاستفادة منه من قبل الأطراف في العمليات الفعلية.