شرح تفصيلي لاقتراح Vitalik الأخير EIP-7702: يمكن أن يحل محل EIP-3074

المؤلف: فيتاليك، مؤسس Ethereum الترجمة: xiaozou@金财经

1، نظرة عامة

أضف نوع معاملة جديدًا يضيف حقل رمز_العقد وتوقيعًا، وسيوقع الحساب أثناء المعاملة (ليس بالضرورة نفس txt .origin) بعد تحويله إلى محفظة عقد ذكية، الهدف هو توفير وظائف مشابهة لـ EIP-3074.

2، التحفيز

إضافة تحسينات وظيفية قصيرة المدى إلى EOA ، وزيادة سهولة استخدام التطبيقات، وفي بعض الحالات دعم التحسينات الأمنية، والتي يهتم بها الكثير من الأشخاص. ثلاثة تطبيقات محددة هي كما يلي:

• المعالجة المجمعة: تسمح لنفس المستخدم بإجراء عمليات متعددة في معاملة ذرية واحدة. ومن الأمثلة الشائعة على ذلك هو إنفاق ERC-20 مرة أخرى بعد الموافقة عليه، وهو سير عمل شائع في البورصات اللامركزية اليوم والذي يتطلب معاملتين. تتضمن حالات الاستخدام المتقدمة لمعالجة الدُفعات أحيانًا تبعيات: يكون مخرجات العملية الأولى جزءًا من مدخلات العملية الثانية.

• الرعاية: يدفع الحساب X رسوم المعاملات نيابة عن الحساب Y. حساب

• التنازل عن الامتياز: يمكن للمستخدمين التوقيع على المفاتيح الفرعية ومنحهم أذونات محددة أضعف من أذونات الوصول العامة للحساب وأكثر من ذلك بكثير. على سبيل المثال، يمكنك أن تتخيل أن هذا الإذن يتم دفعه باستخدام رموز ERC-20 بدلاً من ETH، أو إنفاق 1% من رصيدك الإجمالي كل يوم، أو التفاعل مع تطبيقات محددة فقط.

يعالج EIP-3074 كل تحديات حالة الاستخدام هذه، ولكن هناك مخاوف بشأن التوافق المستقبلي:

• يقدم اثنين من أكواد التشغيل AUTH و AUTHCALL، والتي لا فائدة منها في عالم "نهاية الحساب التجريدي" حيث يستخدم جميع المستخدمين في النهاية محافظ العقود الذكية (وهو ما يبدو أنه هو الحال في النهاية، على الأقل لأن أجهزة الكمبيوتر الكمومية ستنهي في نهاية المطاف ECDSA الذي تستخدمه EOA).

• سيؤدي ذلك إلى تطوير النظام البيئي "لعقد الاستدعاء"، والذي سيكون مستقلاً عن محفظة "العقد الذكي" النظام البيئي، مما أدى إلى جهود متفرقة وعدم وجود تآزر.

الهدف من EIP هذا هو تمكين جميع حالات استخدام EIP-3074 بدون هاتين المشكلتين.

3، المواصفات

الكلمات الرئيسية في هذا المستند "يجب" "، "يجب ألا"، "مطلوب"، "يجب"، "يجب ألا"، "ينبغي"، "لا ينبغي"، "موصى به"، "قد" و"اختياري" يتم تفسيرها كما هو موضح في RFC 2119 المتسق.

المعلمات:

• FORK_BLKNUM = TBD

• TX_TYPE = TBD

• MAGIC = TBD

• PER_CONTRACT_CODE_BASE_COST = 5000

بدءًا من FORK_BLOCK_NUMBER، تم تقديم معاملة EIP-2718 جديدة، TransactionType = TX_TYPE(TBD).

حمولة المعاملات EIP-2718 لهذه المعاملة هي:

rlp([chain_id, nonce ، max_priority_fee_per_gas، max_fee_per_gas، Gas_limit، الوجهة، البيانات، قائمة الوصول، [[contract_code، y_parity، r، s]، ...]، التوقيع_y_parity، التوقيع_r، التوقيع_s])

التكلفة المتأصلة للمعاملات الجديدة موروثة من EIP-2930، على وجه التحديد: 21000 + 16 * بايتات بيانات المكالمات غير الصفرية + 4 * صفر بايتات بيانات المكالمات + 1900 * عدد مفاتيح تخزين قائمة الوصول + 2400 * عدد عناوين قائمة الوصول

بالإضافة إلى ذلك، نضيف 16 * بايتات بيانات اتصال غير صفرية + 4 * بايتات بيانات اتصال صفرية على كل رمز_عقد، بالإضافة إلى PER_CONTRACT_CODE_BASE_COST مضروبًا في طول مصفوفة كود_العقد.

في بداية تنفيذ المعاملة، لكل صف [contract_code, y_parity, r, s]:

• Setsigner = ecrecover(keccak(MAGIC + Contract_code), y_parity, r, s] < /p>

• تأكد من أن رمز العقد الخاص بالموقع فارغ

• اضبط رمز عقد المُوقع على Contract_code

في نهاية المعاملة، أعد تعيين رمز العقد الخاص بـ كل موقع فارغ

لاحظ أن مغني أي توقيع Contract_code وtxt .origin للمعاملة يمكن أن يكونا مختلفين

4، المبادئ الأساسية

(1)EIP-3074< /strong>تحويل حالات الاستخدام

في هذا التصميم، يمكن تحويل مسارات عمل EIP-3074 الحالية دون بذل جهد كبير، على وجه التحديد، AUTH وAUTHCALL سيتم استبداله باستدعاء EOA، وسيكون رمز العقد عبارة عن محفظة مستخدم (لتوفير الوقود، ويمكن أن يكون معيد توجيه DELEGATECALL)، وسيكشف عن وظيفتين، التحقق والتنفيذ "list-style-type: disk;">

لذلك، يعد التحويل من "سير عمل EIP-3074 الموجود" إلى سير العمل بموجب هذا المخطط الجديد أمرًا بسيطًا للغاية.

(2) إعادة توجيه متوافقة مع تجريدات الحساب المستقبلية

تم تصميم EIP بحيث يتمتع بدرجة عالية جدًا من التوافق المستقبلي مع مستقبل تجريد الحساب، دون الإفراط في الحفاظ على أي تفاصيل خاصة بـ ERC-4337 أو RIP-7560.

التفاصيل كالتالي:

• يمكن أن يكون رمز العقد الذي يحتاج المستخدمون إلى التوقيع عليه هو رمز المحفظة ERC-4337 الحالي.

• تستمر "مسارات التعليمات البرمجية" المستخدمة في كثير من الحالات (على الرغم من أنها ليست كلها على الأرجح) في عالم محافظ العقود الذكية الخالصة المسارات التي "تعمل فقط".

• وبالتالي فهو يتجنب مشكلة "إنشاء بيئتين مستقلتين للأكواد" لأنهما إلى حد كبير سيكونان نفس النظام البيئي. قد تكون هناك بعض مسارات العمل التي يلزم دمجها ضمن هذا الحل والتي قد تعمل بشكل أفضل في بيئات متنوعة "أكثر أصالة" ضمن لعبة نهاية تجريد الحساب، ولكن هذا جزء صغير نسبيًا.

• لا يتطلب إضافة أي أكواد تشغيل وسيصبح عديم الفائدة في عالم ما بعد EOA.

• يسمح لـ EOA بتحويل نفسها مؤقتًا إلى عقد لإدراجه في حزمة معاملات ERC- 4337.

• بمجرد نشره، سيكون EIP-5003 عبارة عن "سطر واحد فقط من التعليمات البرمجية": فقط أضف علامة ولا تقم بإضافتها في نهاية المعاملة، يكون إعداد الرمز فارغًا.

5، التوافق مع الإصدارات السابقة

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

6، مخاوف أمنية

حول EIP-3074 كثيرة المخاوف الأمنية شائعة. على وجه الخصوص، يجب أن تكون محافظ المستخدم حذرة للغاية عند التوقيع على رمز العقد.