ما تفويض EIP-7702؟ شرح الحسابات الذكية لـ EOA

تتيح تفويضات EIP-7702 للحساب المملوك خارجيًا (EOA) إسناد منطق تنفيذه إلى عقد آخر دون تغيير عنوانه أو التخلي عن مفتاحه الخاص. يُضبط حقل الكود على 0xef0100 بالإضافة إلى عنوان المفوَّض، وتُشغِّل الاستدعاءات اللاحقة ذلك الكود ضمن سياق EOA نفسه، بينما يبقى الرصيد والـ nonce والتخزين ملكًا للحساب.

يناسب هذا الموضوع القراء الذين يعرفون بالفعل محافظ الحفظ الذاتي ونموذج حسابات EVM. لطالما كان لدى Ethereum نوعان من الحسابات: حسابات EOA التي يتحكم فيها مفتاح، وحسابات العقود التي تحتوي على كود. ولم يكن بإمكان حمل منطق تحقق مخصص سوى النوع الثاني، مقابل إنشاء عنوان جديد. وقد طُرح مع ترقية Pectra، ونقل التحقق المخصص من فتح حساب جديد إلى كتابة كود على عنوان مستخدم بالفعل.

يتضمن صف التفويض ستة حقول، ويشغل معرّف التفويض 23 بايتًا: بادئة من ثلاثة بايتات بالإضافة إلى عنوان من 20 بايتًا. ويحدد مسار الكتابة وحدود الإمكانات الجديدة والفصل عن ERC-4337 ومدى موثوقية المفوَّض مقدار التحكم الذي يحتفظ به الحساب بعد ذلك التوقيع.

النقاط الرئيسية

• يحافظ تفويض EIP-7702 على العنوان والمفتاح الخاص والرصيد والـ nonce كما هي، ويوجه حقل الكود فقط إلى عقد مفوَّض.

• تكتب معاملة من النوع 0x04 التفويض عبر صف تفويض؛ ولا تحمل الرسالة الموقعة حقول رسوم، وليس من الضروري أن يكون المرسل هو المالك.

• لا يملك التفويض تاريخ انتهاء؛ إذ تلغي الإزالة الكود، لكنها لا تلغي التخزين أو موافقات الرموز أو توقيعات Permit.

• يؤدي المفوَّض الذي لا يحتوي على receive() أو fallback() إلى عكس عمليات تحويل ETH العادية، ولم يعد tx.origin يعني أن الحساب لا يحتوي على كود.

• ينشئ ERC-4337 نظام حسابات منفصلًا، بينما يضيف EIP-7702 كودًا إلى حسابات EOA الحالية، لذا يمكن استخدامهما معًا.

ما الذي يغيره تفويض EIP-7702 في الحساب المملوك خارجيًا؟

لدى Ethereum نوعان من الحسابات: حساب مملوك خارجيًا يتحكم فيه مفتاح خاص، وحساب عقد يحتوي على كود.

مع EIP-7702، يكون التغيير في حقل الكود وليس في هوية الحساب، لأن حساب EOA يمكنه الإشارة مؤقتًا إلى كود عقد دون تغيير عنوانه. ويبقى العنوان والمفتاح الخاص والرصيد والـ nonce في أماكنها؛ والفرق هو أن العنوان يحمل الآن كودًا قابلًا للتنفيذ مأخوذًا من عقد آخر منشور.

يحتوي الحقل على معرّف تفويض من 23 بايتًا: البادئة 0xef0100 بالإضافة إلى عنوان من 20 بايتًا. عند استهداف ذلك الـ EOA باستدعاء، تقرأ EVM المعرّف وتحمّل كود المفوَّض، بحيث يمكن للحساب أن يتصرف كحساب ذكي بينما يبقى المفتاح الخاص مسيطرًا، ويُقرأ كل من المرسل والرصيد والتخزين بوصفه تابعًا للـ EOA.

لا يستطيع المفوَّض رؤية حالته الخاصة؛ إذ يُحمَّل منطق تنفيذه من العقد المستهدف، بينما يبقى التخزين وسياق المرسل تابعين للـ EOA، وتتبع عمليات الكتابة المنطق نفسه إلى تخزين لم يستخدمه EOA من قبل.

تظل التوقيعات صادرة عن المفتاح الخاص الأصلي، لذا لا يتحول الحساب إلى محفظة متعددة التوقيعات، ويُعد هذا التصميم خطوة نحو تجريد الحسابات، بما في ذلك النسخة الأصلية، وليس تغييرًا لنوع الحساب.

النوع 0x04 وصفوف التفويض: كيف يصل التفويض إلى كود العقد

تتطلب الكتابة نوع معاملة جديدًا، 0x04، يحمل جسمه قائمة تفويضات؛ يوقّع صاحب الحساب كل صف، بينما يمكن إرسال المعاملة نفسها ودفع رسومها من أي عنوان، ويحدد التفويض الكود الذي يسمح الحساب بتشغيله.

الصف هو [chain_id, address, nonce, y_parity, r, s]، والرسالة الموقعة هي keccak(0x05 || rlp([chain_id, address, nonce]))؛ تستخدم مواصفة EIP-7702 البادئة 0x05 لفصل توقيعات التفويض عن توقيعات المعاملات العادية، ولا تحمل الرسالة أي حقول للغاز أو الرسوم.

ما يُوقّع هو العنوان الذي يجب أن يشير إليه الكود، وليس معاملة محددة، لذا تقرن بعض الأنظمة التفويض بنية تنفيذ بدلًا من ذلك. ويمكن للحساب أيضًا التوقيع مرة واحدة دون اتصال، بينما يدفع راعٍ رسوم الغاز.

يُجري التحقق في العقدة ست خطوات، ويجعل ربط الـ nonce التفويض صالحًا للاستخدام مرة واحدة عند تطابق الـ nonce.

تُضمّن قائمة التفويضات في جسم المعاملة كما توسع قائمة الوصول تنسيق المعاملة: يكون معرّف السلسلة 0 أو مطابقًا للسلسلة المحلية (0 يعني صالحًا على أي سلسلة)؛ ويكون الـ nonce أقل من 2^64-1؛ ويتحقق ecrecover من التوقيع؛ ويكون كود الحساب فارغًا أو مفوضًا بالفعل؛ ويتطابق الـ nonce مع القيمة الحالية؛ ويُكتب الكود على هيئة 0xef0100 || address مع زيادة الـ nonce.

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

ما خصائص الحساب التي تبقى دون تغيير؟

تبقى أربع خصائص كما كانت، ولا يتغير سوى الكود والتخزين: ينتقل الكود من 0x إلى المعرّف، وتبدأ فتحات التخزين غير المستخدمة بتلقي عمليات الكتابة، وتبقى هذه القيم بعد الإزالة. وتورد المواصفة بشكل منفصل ثلاثة ثوابت على السلسلة لم تعد قائمة، تغطي الرصيد والـ nonce وهوية المستدعي؛ ويتناولها قسم المخاطر.

1. العنوان: لا يتغير، لذا يظل السجل وموافقات الرموز وسجلات الأسماء تشير إلى عنوان واحد.

2. المفتاح الخاص: لا يتغير، ويوقّع المعاملات العادية بالإضافة إلى تفويض جديد يستبدل التفويض أو يلغيه.

3. الرصيد: لا يتغير، لأن التفويض لا ينقل أي أصول، ويستمر الحساب في الاحتفاظ بها مباشرةً.

4. الـ nonce: يستمر في الزيادة، لأن التفويض يستهلك واحدًا، مما يمنع إعادة تشغيل التوقيع نفسه.

هل يستطيع الحساب المفوَّض تلقي ETH بصورة طبيعية؟

ليس افتراضيًا. بمجرد أن يحمل الحساب كودًا، يدخل تحويل ETH العادي مسار تنفيذ الكود؛ وإذا لم ينفذ المفوَّض receive() أو fallback()، تُعكس عملية التحويل وتُعاد الأموال إلى المرسل.

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

الشكل 1. مسار كتابة EIP-7702: يوقّع EOA صف التفويض، وتضبط معاملة من النوع 0x04 الكود على 0xef0100 بالإضافة إلى عنوان المفوَّض، ثم تنفذ الاستدعاءات اللاحقة ذلك الكود ضمن سياق EOA.

ماذا يستطيع الحساب المفوَّض فعله؟ التجميع ورعاية الغاز والاسترداد

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

يُعد التجميع المكسب الأكثر وضوحًا: يمكن تنفيذ الموافقة والمبادلة في معاملة واحدة، كما يمكن للراعي تسهيل الانضمام أو التجميع عبر المساعدة على إكمال خطوات متعددة في الخلفية في الوقت المناسب، بحيث يسوي توقيع واحد العملية مرة واحدة ولا تبقى أي موافقة غير مستخدمة بين الخطوات.

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

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

الحد واضح: يمكن لمن يملك المفتاح الخاص دائمًا توقيع تفويض جديد يستبدل التفويض الحالي، لذا يكون الاسترداد هنا أضعف مما هو عليه في حساب ذكي أصلي ولا يقلل سوى تكلفة فقدان المفتاح.

لا يملك التفويض تاريخ انتهاء. يظل نشطًا حتى يستبدله تفويض جديد أو يُلغى بعنوان صفري، لذا فإن الإذن طويل الأمد ويتطلب إدارة نشطة؛ ومن منظور أمني، راجع نطاق ما يمكن للكود المفوَّض الوصول إليه والتحكم فيه.

كيف يختلف تفويض EIP-7702 عن ERC-4337 وتجريد الحسابات؟

يضيف EIP-7702 كودًا إلى EOA قائم، بينما ينشئ ERC-4337 نظام حسابات منفصلًا؛ وباعتبارهما نهجين متكاملين لتجريد الحسابات، يمكن استخدامهما معًا بدلًا من أن يحل أحدهما محل الآخر.

يبدأ ERC-4337 بعقد منشور حديثًا، لذا تنتقل الأصول والموافقات عبره؛ بينما يبدأ 7702 من العنوان الأصلي ويضيف كودًا، متجنبًا الترحيل عبر السماح للحسابات الحالية باستخدام سلوك العقد الذكي دون نشر محفظة منفصلة أولًا.

معًا، يتيحان لحساب 7702 أن يعمل كتنفيذ حساب لـ ERC-4337، ويمكن للمطورين بناء تدفقات متوافقة مع 4337 فوق حساب مفوَّض عبر 7702. وهذا يعيد إدخال سباق تهيئة: بين وصول التفويض واكتمال التهيئة، يمكن لأي شخص استدعاء المُهيئ وتعيين نفسه مالكًا.

يوجد حلان: initWithSig، الذي يربط التوقيع بمعاملات التهيئة، أو قصر التهيئة على EntryPoint.

هل المفوَّض موثوق؟ كيف تتحقق من أنه غير قابل للتغيير

فوّض فقط إلى عقود غير قابلة للتغيير منشورة من CREATE2 initcode القياسي؛ وينبغي أن تفضّل آلية التحقق الأهداف التي لا تملك مسار ترقية، لأن العقود الوكيلة والعقود القابلة للترقية والعقود التي لديها مسار self-destruct كلها أهداف غير مناسبة.

يمنح التفويض حقوق التنفيذ لذلك الكود، ولا يتلقى الحامل إشعارًا بالتغيير. ويعني الهدف القابل للترقية أن من يملك صلاحية الترقية يملك سلطة التنفيذ على كل حساب يفوض إليه؛ أما الهدف غير القابل للتغيير فيثبت على الأقل سطح الهجوم مقدمًا، حيث يمكن تدقيقه. ويزداد التعرض الأمني إذا أمكن تغيير الكود المفوَّض بعد التفويض.

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

1. اقرأ فتحات التنفيذ والإدارة: تشير فتحة EIP-1967 غير الصفرية التي تبدأ بـ 0x360894 إلى وكيل أو مسار ترقية.

2. قارن البايت كود على السلسلة بالمصدر المتحقق منه، مع تأكيد تطابق معاملات المُنشئ والبايت كود المنشور.

3. ابحث عن selfdestruct وdelegatecall، وتأكد من عدم وجود فرع يمكنه مسح الكود أو توجيه التنفيذ إلى مكان آخر.

4. أعد حساب عنوان CREATE2 من initcode وsalt، وتأكد من أن الناشر لا يستطيع استبدال العقد بعقد آخر على عنوان مختلف.

ما مخاطر تفويض EIP-7702؟

تكمن المخاطر في ثلاثة مواضع: الأخطاء في المفوَّض، ودلالات الحساب التي يغيرها التفويض، وعدم قابلية التراجع عن توقيع لمرة واحدة — وهي مقايضة أمنية بقدر ما هي ترقية وظيفية، ويتمثل القلق الرئيسي في النطاق الواسع للكود الذي يمكنه التحكم في الحساب بمجرد منح التفويض.

يحمل صف tx.origin أوسع نطاق تأثير. يمكن للحساب المفوَّض تنفيذ كود ضمن مكدس الاستدعاءات، لذا لم تعد msg.sender == tx.origin تعني أن المستدعي لا يملك كودًا، وتتوقف وسائل الحماية المبنية على هذه المقارنة عن توفير الحماية؛ ولا تعتمد أقفال nonReentrant أو أقفال التخزين المؤقت على هوية المستدعي.

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

يوسع chain_id بقيمة 0 الفئة الثالثة: يكون التوقيع نفسه صالحًا على سلاسل EVM أخرى، لذا يمكن منح الحساب كودًا على سلسلة لم يفكر فيها حامله مطلقًا. وغالبًا ما تغفل أجهزة التوقيع معرّف السلسلة، وهنا تكمن المقايضة وراء تفعيل التفويض على محفظة باردة.

كيف تتحقق من التفويض وتلغيه؟

يتطلب التحقق قراءة واحدة للكود: تعني نتيجة eth_getCode بقيمة 0x عدم وجود تفويض، وتعني 23 بايتًا تبدأ بـ 0xef0100 أن الحساب هو حساب مملوك خارجيًا مفوَّض، بينما يعني أي بايت كود آخر أنه حساب عقد.

التفويض هو حالة على مستوى السلسلة، لذا يمكن تفويض عنوان واحد على سلسلة وتركه دون تغيير على أخرى، وتتطلب كل سلسلة فحصها الخاص؛ وتمثل آخر 20 بايتًا المفوَّض، ويمكن لمحفظة أو منصة أتمتة هذه الفحوصات عبر السلاسل مع الاحتفاظ بسجلات فحوصات الحالة أو تغييراتها لأغراض التدقيق والمراقبة.

لإجراء مراجعة يدوية سريعة، يشرح التحقق من تفويض وإلغاؤه الخطوات المعتادة.

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

تزيل الإزالة الكود المفوَّض، لكنها لا تزيل موافقات العقود الذكية السابقة أو أي وصول آخر ممنوح بالفعل للتطبيقات، وتوضح ملاحظات تفويض EOA من OpenZeppelin هذا الحد.

الملخص

يوفر EIP-7702 قابلية البرمجة لـ EOA بتوقيع واحد: يبقى العنوان والمفتاح في مكانهما، ويشير حقل الكود إلى مفوَّض، ويجري التنفيذ ضمن سياق الحساب نفسه.

والثمن هو دلالات متغيرة وإذن طويل الأمد: قد تفشل المدفوعات الواردة العادية، ولم يعد tx.origin يمثل EOA، وينتقل توقيع chain_id بقيمة 0 عبر السلاسل، ولا تمسح الإزالة سوى الكود.

الأسئلة الشائعة

هل يحول EIP-7702 محفظتي إلى محفظة متعددة التوقيعات؟

لا. يغير التفويض حقل الكود فقط، وتظل التوقيعات صادرة عن المفتاح الخاص الأصلي، لذا يمكن لحامل مفتاح واحد إجراء المعاملات بشكل مستقل واستبدال التفويض بتفويض جديد. ويمكن أيضًا تجاوز المفوَّض الذي يطلب توقيعات متعددة باستخدام ذلك المفتاح.

كيف يمكنني التحقق مما إذا كانت محفظتي مفوَّضة بموجب EIP-7702؟

استدعِ eth_getCode على العنوان. تعني نتيجة 0x عدم وجود تفويض؛ وتعني 23 بايتًا تبدأ بـ 0xef0100 أن الحساب مفوَّض، مع تحديد آخر 20 بايتًا للمفوَّض؛ بينما يعني أي بايت كود آخر أنه حساب عقد.

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

كيف ألغي تفويض EIP-7702؟

وقّع تفويضًا جديدًا مع ضبط حقل العنوان على الصفر من داخل المحفظة، وستلغي العقدة تجزئة الكود بمجرد اجتياز التحقق. ولا يستطيع توقيعه سوى حامل الحساب، وعادةً لا تستطيع التطبيقات اللامركزية الخارجية التصرف نيابةً عنه.

هل ينتهي التفويض، وهل تبقى موافقات الرموز السابقة بعد الإزالة؟

لا يملك التفويض تاريخ انتهاء ويبقى نشطًا حتى يُستبدل أو يُلغى. وتلغي الإزالة الكود فقط، وتترك التخزين وموافقات ERC-20 وتوقيعات Permit دون تغيير.

لم يُسرّب مفتاحي مطلقًا — فهل يمكن لتفويض EIP-7702 ضار أن يستنزف الحساب رغم ذلك؟

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

تحقق من معرّف السلسلة والعنوان المستهدف في الصف، ووقّع فقط للعقود غير القابلة للتغيير؛ وينبغي لفرق المحافظ أيضًا التحقق من صلاحية الموقّع قبل منح موافقات داخلية مرتبطة بالتفويض نيابةً عن مؤسسة.