ترقية إثيريوم Pectra: تحليل عميق لـ EIP-7702 وأفضل ممارسات الدليل

المقدمة

إثيريوم ستستقبل ترقية Pectra، وهو تحديث ذو أهمية كبيرة. من ضمن ذلك، فإن EIP-7702 قامت بإجراء تغييرات ثورية على حسابات إثيريوم الخارجية (EOA). هذا الاقتراح غامض الحدود بين EOA وحسابات العقود CA، وهو خطوة رئيسية نحو تجريد الحسابات الأصلية، مما يجلب أنماط تفاعل جديدة إلى نظام إثيريوم البيئي.

تم نشر Pectra على شبكة الاختبار، ومن المتوقع أن يتم إطلاقها على الشبكة الرئيسية في المستقبل القريب. ستقوم هذه المقالة بتحليل آلية تنفيذ EIP-7702 بشكل عميق، واستكشاف الفرص والتحديات المحتملة التي قد تجلبها، وتقديم دليل عملي للمشاركين المختلفين.

تحليل البروتوكول

نظرة عامة

EIP-7702 قدم نوعًا جديدًا من المعاملات، يسمح لـ EOA بتحديد عنوان العقد الذكي وتعيين التعليمات البرمجية له. هذا يمكّن EOA من تنفيذ التعليمات البرمجية مثل العقود الذكية، مع الاحتفاظ بقدرة بدء المعاملات. هذه الميزة تمنح EOA القابلية للبرمجة والتركيب، حيث يمكن للمستخدمين تنفيذ ميزات مثل الاستعادة الاجتماعية، التحكم في الأذونات، إدارة التوقيع المتعدد، التحقق من zk، الدفع القائم على الاشتراك، رعاية المعاملات ومعالجة دفعات المعاملات. من الجدير بالذكر أن EIP-7702 متوافق تمامًا مع محفظة العقود الذكية التي تنفذها EIP-4337، مما يبسط عملية تطوير وتطبيق الميزات الجديدة.

EIP-7702 قدم نوع المعاملة SET_CODE_TX_TYPE (0x04)، وهيكل بياناتها مُعرّف كما يلي:

rlp([معرّف_السلسلة, عدد_المرات, أقصى_رسوم_الأولوية_لكل_وحدة_غاز, أقصى_رسوم_لكل_وحدة_غاز, حد_الغاز, وجهة, قيمة, بيانات, قائمة_الوصول, قائمة_التفويض, التوقيع_y_الزوجية, التوقيع_r, التوقيع_s])

حقل authorization_list معرف على النحو التالي:

authorization_list = [[chain_id ، العنوان ، nonce ، y_parity ، r ، s] ، ...]

في هيكل المعاملات الجديد، باستثناء حقل authorization_list، تتبع البقية نفس الدلالة مثل EIP-4844. authorization_list هو نوع قائمة، ويمكن أن يحتوي على مدخلات تفويض متعددة. في كل مدخل تفويض:

• chain_id تشير إلى سلسلة تفويض التفويض المعتمد.
• العنوان يشير إلى عنوان الهدف للتفويض
• يجب أن يتطابق nonce مع nonce الحساب المخول الحالي
• y_parity, r, s هي بيانات توقيع الحساب المصرح له بتوقيع التفويض

قائمة التفويض في صفقة واحدة يمكن أن تحتوي على عدة حسابات تفويض مختلفة ( EOA ) الموقعة لعناصر التفويض، مما يتيح إجراء عمليات تفويض على المفوض مع دفع رسوم الغاز.

تحقيق

عند توقيع بيانات التفويض من قبل المفوض، يجب أولاً ترميز chain_id و address و nonce باستخدام RLP. ثم يتم إجراء عملية تجزئة keccak256 على البيانات المشفرة مع عدد MAGIC، للحصول على البيانات التي سيتم توقيعها. أخيرًا، يتم توقيع البيانات المجزأة باستخدام المفتاح الخاص بالمفوض للحصول على بيانات y_parity و r و s. يتم استخدام MAGIC (0x05) كفاصل نطاق لضمان عدم تعارض نتائج التوقيعات من أنواع مختلفة.

عندما يكون chain_id المصرح به من قبل المصرح 0، فهذا يعني أن المصرح يسمح بإعادة تشغيل التفويض على جميع سلاسل EVM المتوافقة التي تدعم EIP-7702 (بشرط أن يتطابق nonce أيضًا).

بعد توقيع المصرح عليه على بيانات التفويض، يقوم مُقدم المعاملة بتجميعها في حقل authorization_list للتوقيع ثم يبث المعاملة عبر RPC. قبل تنفيذ المعاملة، يقوم المُقترح بإجراء فحص مسبق لضمان أن هذه المعاملة ليست معاملة إنشاء عقد، أي عند إرسال معاملة من نوع EIP-7702، يجب ألا يكون عنوان to فارغًا.

تتطلب هذه المعاملات أن يحتوي حقل authorization_list على عنصر تفويض واحد على الأقل. إذا تم التوقيع على عدة عناصر تفويض من قبل نفس المفوّض، فإن العنصر الأخير فقط يكون ساري المفعول.

عند تنفيذ المعاملة، يقوم العقد بزيادة قيمة nonce للمرسل أولاً، ثم يقوم بإجراء عملية applyAuthorization لكل عنصر تفويض في authorization_list. في عملية applyAuthorization، يتحقق العقد أولاً من nonce للموكل، ثم يزيد nonce للموكل. هذا يعني أنه إذا كان مرسل المعاملة والموكل هما نفس المستخدم (EOA)، يجب أن تزيد قيمة nonce عند توقيع معاملة التفويض بمقدار 1.

عند تطبيق إدخالات تفويض العقد، إذا حدثت أي أخطاء، فسيتم تخطي هذا الإدخال، ولن تفشل المعاملة، وستستمر إدخالات التفويض الأخرى في التطبيق، لتجنب مخاطر DoS في سيناريوهات التفويض الجماعي.

بعد اكتمال تطبيق التفويض، سيتم تعيين حقل code لعنوان المفوض إلى 0xef0100 || address، حيث 0xef0100 هو معرف ثابت، وaddress هو عنوان التفويض المستهدف. تضمن قيود EIP-3541 أن مثل هذه التعريفات يمكن نشرها فقط من خلال معاملات من نوع 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.

يجب على المطورين إجراء فحص للأذونات (مثل التحقق من عنوان التوقيع من خلال ecrecover) أثناء عملية تهيئة المحفظة عند دمج EIP-7702 مع محفظة EIP-4337 الموجودة، لتجنب مخاطر سرقة عملية تهيئة المحفظة.

إدارة التخزين

عند استخدام المستخدمين لوظيفة التفويض EIP-7702، قد يحتاجون إلى إعادة التفويض إلى عنوان عقد مختلف بسبب تغييرات في متطلبات الوظيفة، أو تحديثات المحفظة، وما إلى ذلك. ولكن قد تكون هناك اختلافات في بنية التخزين لعقود مختلفة (مثل أن يمثل slot0 لعقد مختلف أنواع بيانات مختلفة)، وقد يؤدي إعادة التفويض إلى استخدام العقد الجديد بشكل غير متوقع لبيانات العقد القديم، مما يتسبب في قفل الحساب، وفقدان الأموال، وغيرها من العواقب السلبية.

يجب على المستخدمين التعامل بحذر مع حالات إعادة التفويض.

يجب على المطورين اتباع صيغة الفضاء الاسم الذي اقترحته ERC-7201 خلال عملية التطوير، وتخصيص المتغيرات لمواقع تخزين مستقلة محددة، لتخفيف مخاطر تضارب التخزين. بالإضافة إلى ذلك، قدمت ERC-7779 (draft) عملية معيارية لإعادة التفويض مصممة خصيصًا لـ EIP-7702: بما في ذلك استخدام ERC-7201 لمنع تضارب التخزين، والتحقق من توافق التخزين قبل إعادة التفويض، واستدعاء واجهة التفويض القديم لتنظيف البيانات القديمة المخزنة.

شحن زائف

بعد قيام المستخدم بالتفويض، يمكن أيضًا استخدام EOA كعقد ذكي، لذلك قد تواجه البورصات المركزية (CEX) حالة عمومية لإعادة شحن العقود الذكية.

يجب على CEX فحص حالة كل عملية إيداع من خلال تتبع لتجنب مخاطر الإيداعات المزيفة للعقود الذكية.

تحويل الحساب

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