Beosin: EIP-7702 والجيل التالي من تحليل تدقيق أمان محفظة AA

تجريد الحساب (AA) اتجاها مهما للاستكشاف طويل الأجل في نظام Ethereum البيئي ، ويهدف إلى كسر الحدود بين الحسابات الخارجية (EOA) وحسابات العقود ، بحيث تتمتع المحفظة بقابلية برمجة وأمان وقابلية ترقية أقوى. يعد EIP-4337 حاليا حل تنفيذ AA الأكثر شيوعا ، وقد تم استخدامه على نطاق واسع في عدد من محافظ العقود الذكية المستندة إلى EntryPoint (مثل Safe و Stacks و Argent). ومع ذلك ، لا يزال لدى EIP-4337 قيود معينة من حيث الأصالة على السلسلة والتعقيد التشغيلي والتوافق البيئي بسبب تقديمه لمجمع معاملات مستقل وآلية عقد على منحدر.

لتقليل حاجز الدخول وتعزيز الدعم الأصلي لتجريدات الحسابات ، اقترح فيتاليك EIP-7702 في عام 2024 وأدرجه في ترقية Pectra. تتمثل الفكرة الأساسية ل EIP-7702 في السماح ل EOA الأصلي بتنفيذ رمز العقد (contract_code) لعنوان محدد عند بدء معاملة ، واستخدام هذا الرمز لتحديد منطق تنفيذ المعاملة.

يقدم EIP-7702 آلية جديدة ل "حقن التعليمات البرمجية على مستوى المعاملة" ، والتي تسمح لحسابات المستخدمين بتحديد منطق التنفيذ ديناميكيا في كل معاملة ، بدلا من الاعتماد على رمز العقد المنشور مسبقا. هذا يكسر نموذج الإذن التقليدي المستند إلى التعليمات البرمجية الثابتة ، ويجلب قدرا أكبر من المرونة ، ويقدم تحديات أمنية جديدة: قد تصبح العقود التي تعتمد على منطق الحكم مثل isContract و extcodehash غير صالحة ، ويمكن أيضا تجاوز بعض الأنظمة التي تفترض أن المتصل هو EOA خالص. بالنسبة لمراجعي الحسابات ، من المهم ليس فقط التحقق من أمان التعليمات البرمجية المحقونة نفسها ، ولكن أيضا تقييم تأثيرها المحتمل على أنظمة العقود الأخرى في سياق ديناميكي.

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

1. مقدمة إلى EIP-77021

. نظرة عامة فنية على EIP-7702يقدم

EIP-7702 نوعا جديدا من المعاملات، 0x 04 (SetCode)، والذي يسمح ل EOA بتفويض رمز العقد الذي يجب تنفيذه من خلال هذه المعاملة، مع هيكل المعاملة التالي:

1. rlp([chain_id، nonce، max_priority_fee_per_gas، max_ fee_per_gas ، gas_limit ،

2. الوجهة ، القيمة ، البيانات ، access_list ، authorization_list ، signature_y_parity ، signature_r ، signature_s])

عندما يحتوي authorization_list على قوائم تفويض متعددة، ويمكن أن يحتوي أيضا على إجراءات تفويض لجهات عدم المبادرين بالمعاملات، يكون الهيكل الداخلي هو:

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

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

بعد اكتمال التفويض، سيقوم النظام بتعديل حقل الرمز الخاص بالمستخدم المفوض إلى عنوان 0x ef 0100 ||، حيث يكون العنوان هو عنوان العقد المصرح به. إذا كنت ترغب في إلغاء التفويض ، فما عليك سوى بدء معاملة SetCode مع تعيين العنوان إلى 0.

2. مزايا EIP 7702

(1) المرونة والتخصيص

الحسابات المجردةمن خلال كتابة منطق الحساب في العقود الذكية ، يمكنك تخصيص الوظائف بمرونة وفقا لاحتياجاتك. على سبيل المثال، يمكن للمستخدمين تكوين التوقيعات المتعددة والاسترداد الاجتماعي والتحكم في الحصة النسبية لتلبية احتياجات الأفراد أو المؤسسات في سيناريوهات مختلفة. يعمل هذا التصميم على تحسين قابلية التوسع الوظيفي للحساب بشكل كبير واختراق قيود الحسابات الخارجية التقليدية (EOA).

(2)

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

المحسن للغاز

آلية مرنة لاستخراج الغاز ، مما يسمح للمستخدمين بالدفع مقابل الغاز من خلال طرف ثالث ، وحتى استخدام الرموز المميزة الأخرى مباشرة لدفع رسوم المعاملات. لا تقلل هذه الآلية من تكلفة تشغيل المستخدمين فحسب ، بل تعمل أيضا على تبسيط استخدام blockchain ، وهو مناسب بشكل خاص للمستخدمين المبتدئين أو سيناريوهات المعاملات المعقدة متعددة الخطوات.

(4) تعزيز تعميم Web3من خلال

تحسين التجربة والأمان ، تخفي الحسابات المجردة تعقيد blockchain في الأماكن التي لا يستطيع المستخدمون رؤيتها ، مما يوفر عمليات مريحة أقرب إلى Web2. يقلل هذا التصميم من تكلفة التعلم للمستخدمين العاديين ، ويسمح لمزيد من الأشخاص بالمشاركة في تطبيقات Web3 دون حواجز ، ويعزز تعميم التكنولوجيا اللامركزية.

2. تحليل المخاطر الأمنية في EIP-7702 من الناحية العملية

على الرغم من أن EIP-7702 قد ضخ زخما جديدا في نظام Ethereum البيئي ووسع ثروة من سيناريوهات التطبيق ، إلا أنه في الوقت نفسه ، فقد قدم حتما بعض المخاطر الأمنية الجديدة:

1. هجوم إعادة تشغيل التفويض

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

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

لذلك ، بالنسبة لموفري خدمة المحفظة أو منصات التفاعل الأمامية ، عندما يقوم المستخدمون بعمليات التفويض هذه ، يجب عليهم التحقق بوضوح مما إذا كان chainId المعلن في تفويض المستخدم متوافقا مع شبكة الاتصال الحالية ؛ إذا تم اكتشاف مستخدم وهو يضبط chainId على 0 ، فيجب إعطاء تحذير واضح من المخاطر لتذكير المستخدم بأن التفويض سيدخل حيز التنفيذ على جميع السلاسل المتوافقة مع EVM وقد يتم إساءة استخدامه من خلال العقود الضارة.

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

2. توافق العقد

1) توافق معاودة الاتصال بالعقد

تحويل الأموال إلى عنوان عقد لعقود الرمز المميز الحالية مثل ERC-721 و ERC-777 و ERC 1155 ، سيستدعيون واجهات معاودة الاتصال القياسية (مثل onERC 721 Received و tokensReceived) لإكمال عملية النقل. إذا لم يقم عنوان الاستلام بتنفيذ الواجهة المقابلة، فسيفشل النقل أو حتى يتسبب في تأمين الأصل.

في EIP-7702 ، يمكن تحويل عنوان المستخدم إلى حساب عقد من خلال إعطائه رمز عقد من خلال عملية "set_code". في هذه الحالة:

• يعتبر عنوان المستخدم عقدا.

• إذا لم ينفذ العقد واجهة معاودة الاتصال الضرورية ، فسيفشل نقل الرمز المميز ؛

• قد لا يتمكن المستخدمون من تلقي الرموز المميزة السائدة دون علمهم.

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

(2) فشل التحقق من "tx.origin"في

العقود التقليدية، غالبا ما تستخدم "tx.origin" لتحديد ما إذا كانت المعاملة قد بدأها المستعمل مباشرة، وتستخدم لمنع ضوابط الأمان مثل استدعاءات العقود.

ومع ذلك، في سيناريو EIP-7702،

• يوقع المستخدم على معاملة تخويل، وتقوم إعادة الطبقة أو التجميع بثها نيابة عن المستخدم. عند تنفيذ معاملة ، "tx.origin" هو عنوان إعادة الطبقة ، وليس عنوان المستخدم.

• "msg.sender" هو عقد محفظة يمثل هوية المستخدم.

لذلك، سيؤدي التحقق من الإذن المستند إلى "tx.origin == msg.sender" إلى رفض عمليات المستخدم المشروعة وفقدان الموثوقية، وسيتم أيضا إبطال استدعاءات العقد المقيدة نفسها مثل "tx.origin == user". يوصى بالتخلي عن "tx.origin" كأساس للحكم الأمني واستخدام آلية التحقق من التوقيع أو التفويض بدلا من ذلك.

(3) "isContract" يسيء تقديرهالعديد من

العقود تمنع حسابات العقود من المشاركة في عمليات معينة، مثل عمليات الإسقاط الجوي والمبيعات السريعة وما إلى ذلك، من خلال "isContract(address)":

require(!isContract(msg.sender), "العقود غير مسموح بها"

). بموجب آلية EIP-7702 ، يمكن تغيير عنوان المستخدم إلى حساب عقد من خلال معاملة "set_code" ، ويرجع "isContract" true ، وسيقوم العقد عن طريق الخطأ بتحديد المستخدم الشرعي على أنه حساب العقد ويرفض المشاركة في العملية ، مما يؤدي إلى عدم قدرة المستخدم على استخدام خدمات معينة وحظر التجربة.

مع الانتشار التدريجي لمحافظ العقود ، تصميم الاعتماد على "isContract" لتحديد ما إذا كان "المستخدم البشري" لم يعد آمنا ، ويوصى باستخدام طرق أكثر دقة لتحديد هوية المستخدم مثل التحقق من التوقيع.

3. هجوم التصيد الاحتيالبعد

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

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

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

4. مخاطر عقد المحفظة

(1) إدارة سلطة عقود المحفظة

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

توصيات الأمان

• : استخدم آليات التوقيع المتعدد أو المصادقة متعددة العوامل أو القفل الزمني للتحكم في امتيازات التصعيد.

• تخضع تغييرات التعليمات البرمجية والأذونات لتدقيق صارم والتحقق من صحة الأمان.

• عملية الترقية مفتوحة وشفافة لضمان حق المستخدمين في المعرفة والمشاركة.

(2) قد يعيد مزودي

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

توصيات الأمان:

• استخدم مخطط عزل تخزين متخصص، مثل معيار EIP-1967، أو استفد من مساحة اسم فريدة لإدارة فتحات التخزين.

• عند ترقية العقد، تأكد من أن تخطيط التخزين متوافق وتجنب تداخل المتغيرات.

• اختبر بدقة معقولية الحالة المخزنة أثناء عملية الترقية.

(3) إدارة nonce داخل المحفظة

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

توصية الأمان:

• يجب التحقق من nonce بالقوة للحصول على قيمة مكافئة (أو زيادة) ولا يمكن تخطيها.

• يحظر على الوظائف تعديل nonce مباشرة ، ولن يتم تحديث nonce إلا عند تنفيذ عملية المستخدم.

• تصميم آليات التسامح مع الأخطاء والاسترداد لاستثناءات nonce لتجنب الجمود غير المستمر.

(4) التحقق من إذن المتصل الوظيفيمن أجل

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

• التوقيع خارج السلسلة

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

• قيد الاستدعاء (msg.sender == address(this))

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

3. التوقعات: إن اقتراح EIP-7702 ومعيار محفظة AA المستقبلي

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

1. التطور المشترك مع EIP-4337: نحو التوافق مع الوضع المزدوج على الرغم من

أن EIP-7702 و EIP-4337 لهما أهداف تصميم مختلفة ، إلا أن الأول يعيد بناء آلية تحميل الكود للحساب ، والثاني يبني نظاما بيئيا كاملا لإدخال المعاملات والتغليف. ومع ذلك ، فإن الاثنين ليسا متعارضين ، ولكن لديهما تكامل قوي:

● يوفر EIP-4337 "قناة معاملات مشتركة" و "واجهة تنفيذ حساب مجردة".

● يسمح EIP-7702 لحسابات المستخدمين بمنح إمكانات منطق العقد ديناميكيا دون تغيير العنوان ؛

لذلك ، في المستقبل ، قد تتبنى المحافظ "بنية دعم مزدوجة الوضع": استخدم EIP-7702 كبديل خفيف الوزن على السلاسل التي لا تدعم EIP-4337 ، والاستمرار في الاعتماد على مكدس البروتوكول الكامل ل EIP-4337 في السيناريوهات التي تتطلب تغليفا خارج السلسلة وتجميعا متعدد المستخدمين.

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

2. الدعم والإلهام لمنطق المحفظة الجديد مثل MPC و ZK ، وآلية

عقد الحساب التي يدافع عنها EIP-7702 لديها إمكانات تكامل طبيعية مع محفظة MPC الشهيرة الحالية ومحفظة ZK والمحفظة المعيارية وغيرها من البنى الجديدة:

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

● تتحقق محفظة ZK من هوية المستخدم أو تفويضه من خلال إثباتات المعرفة الصفرية ، دون الكشف عن معلومات المفتاح الخاص. بالاقتران مع EIP-7702 ، يمكن لمحافظ ZK إدخال عقود منطقية محددة مؤقتا بعد اكتمال التحقق ، وذلك لتحقيق نشر السلوكيات الشخصية بعد حوسبة الخصوصية ، مثل التنفيذ التلقائي لمنطق معين فقط بعد استيفاء شروط خصوصية معينة.

● يمكن للمحافظ المعيارية استخدام EIP-7702 لتفكيك منطق الحساب إلى وحدات متعددة وتحميلها ديناميكيا عند الحاجة.

لذلك ، يوفر EIP-7702 "حاوية تنفيذ" أصلية أكثر للمحافظ المتقدمة المذكورة أعلاه: يمكن حقن منطق عقد مختلف بنفس عنوان المستخدم ، وتجنب مشكلة تبعية العنوان في عملية نشر العقد التقليدية ، والقضاء على الحاجة إلى النشر المسبق ، مما يحسن بشكل كبير من المرونة والجمع بين سلوك الحساب.

3. الآثار المترتبة على مطوري العقود ومدققي

إلى إحداث تغيير عميق في نموذج التطوير. لم يعد مطورو العقود يتعاملون مع المتصل ببساطة على أنه حساب EOA تقليدي أو حساب عقد ثابت ، ولكن يجب عليهم التكيف مع آلية جديدة: يمكن تبديل هوية المتصل ديناميكيا بين EOA وحالة العقد أثناء المعاملة ، ولم يعد منطق سلوك الحساب مثبتا بشكل ثابت ، ولكن يمكن تغييره بمرونة وفقا للطلب. يتطلب ذلك من المطورين والمدققين ما يلي:

• تقديم منطق أكثر صرامة للتحقق من المتصل والحكم على الإذن ؛

• تحقق مما إذا كان مسار الاستدعاء يتأثر بمنطق العقد الديناميكي؛

• تحديد الثغرات الأمنية المحتملة التي تعتمد على سلوكيات مثل msg.sender.code.length == 0 ، isContract() ، وما إلى ذلك ؛

• توضيح "تبعيات السياق" لمنطق العقد، مثل التحكم في حدود المكالمات الثابتة ومكالمات التفويض؛

• على مستوى سلسلة الأدوات، يتم دعم تحليل المحاكاة والرجوع إلى سيناريوهات setCode.

بمعنى آخر ، لم يعد أمان التعليمات البرمجية مجرد "مشكلة ما قبل النشر" ولكن "عملية ديناميكية يجب التحقق منها أثناء الاستدعاء والمعاملة".

4.

تنفيذا أخف وزنا وأصليا ومرنا لتجريد الحساب (AA) ، بحيث يمكن ل EOA العادي حمل منطق العقد وتنفيذه في معاملة واحدة. تكسر هذه الآلية الافتراضات الثابتة التقليدية حول سلوك الحساب ، ولم يعد بإمكان المطورين الاعتماد ببساطة على حالة التعليمات البرمجية لعنوان الحساب للحكم على نموذج السلوك الخاص به ، ولكنهم يحتاجون إلى إعادة بناء فهم حدود الهوية والسلطة للمتصل.

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