EIP-7702: إثيريوم تجريد الحساب فصل جديد ضبابي بين EOA والعقد

إثيريوم Pectra ترقية و EIP-7702: خطوة مهمة في توضيح حدود EOA والحسابات العقدية

المقدمة

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

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

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

ملخص

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

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

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

شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
  • أعجبني
  • 8
  • مشاركة
تعليق
0/400
BearMarketSurvivorvip
· 07-13 15:27
هل يبدو أن الغزال قد ضل طريقه إلى ساحة المعركة؟ يبدو أن الإصلاح الجريء قد يحتاج إلى الانتقال من حرب المواقع إلى حرب الشوارع.
شاهد النسخة الأصليةرد0
quietly_stakingvip
· 07-12 15:35
مع سرعة التحديث هذه، السوق الصاعدة القادمة مضمونة.
شاهد النسخة الأصليةرد0
DAOdreamervip
· 07-11 11:22
مرة أخرى يقومون بوضع معايير جديدة، ألا يكفي أن الأمور فوضوية؟
شاهد النسخة الأصليةرد0
MEVSandwichvip
· 07-11 11:21
مرة أخرى تجريد الحساب؟ لم يعد بإمكان EOA العمل
شاهد النسخة الأصليةرد0
zkProofInThePuddingvip
· 07-11 11:18
Pectra قد أكملت نشر الاختبار.
شاهد النسخة الأصليةرد0
FunGibleTomvip
· 07-11 11:05
لا تزعجني، أنا أبحث في كيفية القيام بالمراجحة مسبقًا
شاهد النسخة الأصليةرد0
BlockchainArchaeologistvip
· 07-11 11:01
متى سيتم الانتهاء من الترقية بهذه السرعة؟
شاهد النسخة الأصليةرد0
SnapshotDayLaborervip
· 07-11 10:58
هذا التحديث لا يبدو مختلفًا عن الإصدار السابق.
شاهد النسخة الأصليةرد0
  • تثبيت