يعد تجريد الحساب (AA) اتجاها مهما للاستكشاف طويل الأجل في نظام Ethereum البيئي ، ويهدف إلى كسر الحدود بين الحسابات الخارجية (EOA) وحسابات العقود ، بحيث تتمتع المحفظة بقابلية أقوى للبرمجة والأمان والترقية. تم استخدام EIP-4337 ، باعتباره حل تنفيذ AA الأكثر شيوعا ، على نطاق واسع في عدد من محافظ العقود الذكية المستندة إلى EntryPoint (مثل Safe و Stacks و Argent). ومع ذلك ، لا يزال لدى EIP-4337 قيود معينة من حيث الأصالة على السلسلة والتعقيد التشغيلي والتوافق البيئي بسبب تقديمه لمجمع معاملات مستقل وآلية عقد على منحدر.
لخفض عتبة استخدام تجريد الحسابات بشكل أكبر وتعزيز الدعم الأصلي لها، اقترح فيتالك في عام 2024 EIP-7702، وتم تضمين هذا الاقتراح في ترقية بيكترا. الفكرة الأساسية لـ EIP-7702 هي: السماح لـ EOA الأصلي عند بدء المعاملة، بتنفيذ كود العقد (contract_code) من عنوان محدد، حيث يحدد هذا الكود منطق تنفيذ المعاملة.
يقدم EIP-7702 آلية جديدة ل "حقن التعليمات البرمجية على مستوى المعاملة" ، والتي تسمح لحسابات المستخدمين بتحديد منطق التنفيذ ديناميكيا في كل معاملة ، بدلا من الاعتماد على رمز العقد المنشور مسبقا. هذا يكسر نموذج الإذن التقليدي المستند إلى التعليمات البرمجية الثابتة ، ويجلب قدرا أكبر من المرونة ، ويقدم تحديات أمنية جديدة: قد تصبح العقود التي تعتمد على منطق الحكم مثل isContract و extcodehash غير صالحة ، وقد يتم تجاوز بعض الأنظمة التي تفترض أن المتصل هو EOA خالص. وبالنسبة لمراجعي الحسابات، من المهم ليس فقط التحقق من أمن الشفرة المحقونة نفسها، ولكن أيضا تقييم تأثيرها المحتمل على أنظمة العقود الأخرى في سياق ديناميكي.
في هذه المقالة ، سيركز فريق أمان Beosin على مبادئ التصميم والميزات الرئيسية ل EIP-7702 ، وفرز المخاطر الأمنية التي قد تواجهها محفظة AA التي تم إنشاؤها بناء عليها بشكل منهجي في التدقيق ، وطرح عملية التدقيق والاقتراحات من منظور عملي لمساعدة الباحثين الأمنيين على التعامل بشكل أفضل مع التحديات التقنية في ظل هذا النموذج الجديد.
أولاً، مقدمة EIP-7702
نظرة عامة على التقنية EIP-7702
EIP-7702 قدم نوعًا جديدًا من المعاملات 0x04 (SetCode) ، والذي يسمح لـ EOA بتفويض كود العقد المطلوب تنفيذه من خلال هذه المعاملة ، وهيكل المعاملة كما يلي:
تشمل authorization_list عدة قوائم تفويض، ويمكن أن تحتوي أيضًا على سلوك تفويض غير المبادرين بالمعاملات، والهيكل الداخلي هو:
حيث أن chain_id يشير إلى السلسلة التي يتم تفعيل تفويض المستخدم عليها، ويجب أن تكون قيمته مساوية لرقم تعريف السلسلة المنفذة أو 0. عندما يكون chain_id 0، فهذا يعني أن التفويض ساري على جميع سلاسل EVM التي تدعم EIP-7702، شريطة أن تتطابق المعلمات الأخرى (مثل nonce). أما address فهو يشير إلى عنوان العقد المستهدف الذي تم تفويضه من قبل المستخدم.
بعد الانتهاء من التفويض، ستقوم النظام بتعديل حقل code الخاص بالمستخدم المفوض إلى 0xef0100 || address، حيث address هو عنوان العقد المصرح به. إذا كنت ترغب في إلغاء التفويض، ما عليك سوى بدء صفقة SetCode وتعيين address إلى عنوان 0.
مزايا EIP7702
(1) المرونة والتخصيص
تتيح الحسابات المجردة تخصيص الوظائف بشكل مرن بناءً على المتطلبات من خلال كتابة منطق الحساب في العقود الذكية. على سبيل المثال، يمكن للمستخدمين تكوين التوقيعات المتعددة، واستعادة الحسابات الاجتماعية، وفرض قيود على الحدود، لتلبية الاحتياجات المختلفة للأفراد أو الشركات. يزيد هذا التصميم بشكل كبير من إمكانية توسيع وظائف الحساب، ويتجاوز قيود الحسابات الخارجية التقليدية (EOA).
(2) تعزيز الأمان
تقدم الحسابات المجردة آليات أمان متعددة الطبقات، بما في ذلك المصادقة المتعددة، وحدود المعاملات، واستعادة اجتماعية. حتى إذا فقد المستخدم مفتاحه الخاص، يمكنه استعادة حسابه من خلال جهات اتصال موثوقة أو من خلال التحقق المتعدد، مما يتجنب الخسارة الدائمة للأصول بسبب فقدان المفتاح الخاص في الحسابات التقليدية. في الوقت نفسه، يمكن أن تمنع وظائف مثل التحكم في الحدود من سرقة الأموال الكبيرة بشكل خبيث.
(3) تحسين الغاز
تدعم الحسابات المجردة آلية مرنة لتجريد الغاز، مما يسمح للمستخدمين بدفع الغاز من خلال طرف ثالث، أو حتى الدفع مباشرة باستخدام رموز أخرى لتكاليف المعاملات. لا تقلل هذه الآلية من تكلفة العمليات للمستخدمين فحسب، بل تبسط أيضًا عملية استخدام blockchain، مما يجعلها مناسبة بشكل خاص للمستخدمين الجدد أو سيناريوهات المعاملات المعقدة متعددة الخطوات.
(4) تعزيز انتشار Web3
من خلال تحسين التجربة والأمان، تخفي الحسابات المجردة تعقيدات blockchain في أماكن لا يستطيع المستخدم رؤيتها، مما يوفر عمليات أكثر سهولة تشبه Web2. يقلل هذا التصميم من تكلفة التعلم للمستخدمين العاديين، مما يجعل المزيد من الأشخاص قادرين على المشاركة بسهولة في تطبيقات Web3، مما يعزز انتشار التقنية اللامركزية.
ثانياً، تحليل مخاطر الأمان في ممارسة EIP-7702
على الرغم من أن EIP-7702 قد أضفى حيوية جديدة على نظام إيثيريوم البيئي ووسع من مجموعة التطبيقات الغنية، إلا أنه في الوقت نفسه، لا بد أنه قد أدخل بعض المخاطر الأمنية الجديدة.
هجوم إعادة التشغيل المعتمد
في نموذج EIP-7702، إذا قام المستخدم بتعيين حقل chain_id في التفويض إلى 0، فهذا يعني أن هذا التفويض يمكن أن يكون ساري المفعول عبر سلاسل متعددة. على الرغم من أن تصميم "التفويض العام عبر السلاسل" هذا يزيد من المرونة في بعض السيناريوهات، إلا أنه في الوقت نفسه يقدم مخاطر أمان واضحة.
من المهم ملاحظة أنه حتى إذا كان معرف الحساب هو نفسه على عناوين مختلفة في سلاسل مختلفة، فإن تنفيذ العقد وراء ذلك قد يكون مختلفًا تمامًا. وهذا يعني أن المهاجم قد ينشر نسخة خبيثة من العقد على سلسلة أخرى، مستفيدًا من سلوك التفويض على نفس العنوان على السلسلة، مما يؤدي إلى تنفيذ عمليات غير متوقعة، وبالتالي تعريض أصول المستخدمين للخطر.
لذا، بالنسبة لمزودي خدمات المحفظة أو منصات التفاعل الأمامية، عند قيام المستخدم بإجراء عمليات التفويض من هذا النوع، يجب التحقق بوضوح مما إذا كان chainId المصرح به من قبل المستخدم يتطابق مع الشبكة المتصلة حاليًا؛ وإذا تم اكتشاف أن المستخدم قد قام بتعيين chainId إلى 0، يجب تقديم تحذير واضح من المخاطر، مما ينبه المستخدم أن هذا التفويض سيكون ساري المفعول على جميع سلاسل EVM المتوافقة وقد يتم استغلاله من قبل العقود الضارة.
بالإضافة إلى ذلك، يجب على جهة الخدمة تقييم ما إذا كان ينبغي تقييد أو منع بشكل افتراضي في واجهة المستخدم إذن chainId يساوي 0، لتقليل مخاطر الأخطاء أو هجمات التصيد.
مشكلة التوافق العقدي
(1) توافقية استدعاء العقد
ستستدعي عقود الرمز المميز الحالية مثل ERC-721 و ERC-777 و ERC1155 واجهات معاودة الاتصال القياسية (مثل onERC721Received و tokensReceived) لإكمال عملية التحويل عند تحويل الأموال إلى عنوان العقد. إذا لم يقم عنوان الاستلام بتنفيذ الواجهة المقابلة، فسيفشل النقل أو حتى يتسبب في تأمين الأصل.
في EIP-7702، يمكن تعيين عنوان المستخدم كرمز عقد من خلال عملية "set_code"، مما يحوله إلى حساب عقد. في هذه الحالة:
سيتم اعتبار عنوان المستخدم كعقد؛
إذا لم ينفذ العقد واجهات الاسترجاع الضرورية، فسوف يؤدي ذلك إلى فشل تحويل الرمز المميز؛
قد لا يتمكن المستخدمون من تلقي الرموز الرئيسية دون علمهم.
لذلك، يجب على المطورين التأكد من أن العقد الهدف الذي يعينه المستخدم ينفذ واجهات الاستدعاء ذات الصلة لضمان التوافق مع الرموز الرئيسية.
(2) فشل التحقق من "tx.origin"
في العقود التقليدية، غالبًا ما يُستخدم "tx.origin" لتحديد ما إذا كانت المعاملة قد تمinitiated من قبل المستخدم مباشرة، وذلك للوقاية من استدعاء العقود وغيرها من ضوابط الأمان.
لكن في سيناريو EIP-7702:
توقيع المستخدم على تفويض المعاملة، يتم بثها فعليًا بواسطة المكرر أو خدمة التجميع (bundler)؛ عند تنفيذ المعاملة، يكون "tx.origin" هو عنوان المكرر، وليس عنوان المستخدم.
"msg.sender" هو عقد المحفظة الذي يمثل هوية المستخدم.
لذا ، فإن التحقق من الأذونات بناءً على "tx.origin == msg.sender" سيؤدي إلى رفض عمليات المستخدمين الشرعيين وفقدان موثوقيتها ، وبالمثل فإن استخدام "tx.origin == user" كقيود لاستدعاء العقود سيفشل أيضًا. يُنصح بالتخلي عن "tx.origin" كأساس للحكم على الأمان والانتقال إلى التحقق من التوقيع أو آلية التفويض.
(3) خطأ في تقييم 「isContract」
تمنع العديد من العقود حسابات العقود من المشاركة في بعض العمليات مثل الإيجارات وعمليات الشراء من خلال "isContract (address)" (التحقق من طول كود العنوان):
تحت آلية EIP-7702، يمكن أن تتحول عناوين المستخدمين إلى حسابات عقود من خلال معاملة "set_code"، وتعيد "isContract" القيمة true، مما يؤدي إلى خطأ في تصنيف المستخدمين الشرعيين كحسابات عقود، مما يرفض مشاركتهم في العمليات، مما يؤدي إلى عدم قدرة المستخدمين على استخدام بعض الخدمات، مما يعرقل التجربة.
مع انتشار محافظ العقود، لم يعد تصميم الاعتماد على "isContract" لتحديد "ما إذا كان المستخدم إنسانًا" آمنًا، يُوصى باستخدام وسائل تحديد الهوية الأكثر دقة مثل التحقق من التوقيع.
هجوم التصيد
بعد تنفيذ آلية التفويض لـ EIP-7702، ستخضع الأصول في حساب المستخدم بالكامل لسيطرة العقد الذكي المفوض. بمجرد أن يمنح المستخدم الإذن لعقد خبيث، قد يتمكن المهاجمون من الحصول على السيطرة الكاملة على أصول الحساب، مما يؤدي إلى تحويل الأموال بسرعة أو سرقتها، مما يشكل خطرًا أمنيًا كبيرًا.
لذلك ، من المهم لمزودي خدمات المحفظة دعم EIP-7702 لحل المعاملات وآليات تحديد المخاطر في أسرع وقت ممكن. عندما يوقع مستخدم على معاملة عهدة، يجب أن تعرض الواجهة الأمامية عنوان العقد المستهدف بوضوح وبشكل بارز، وأن تجمع بين المعلومات الداعمة مثل مصدر العقد ومعلومات النشر لمساعدة المستخدمين على تحديد التصيد الاحتيالي المحتمل أو السلوكيات الاحتيالية، وبالتالي تقليل مخاطر التوقيع الخاطئ. علاوة على ذلك ، يجب أن تدمج خدمة المحفظة إمكانات تحليل الأمان الآلي للعقد المستهدف ، مثل التحقق من حالة المصدر المفتوح لرمز العقد ، وتحليل نموذج الأذونات ، وتحديد العملية التي يحتمل أن تكون خطرة ، لمساعدة المستخدمين على إصدار أحكام أكثر أمانا قبل التفويض.
من المهم بشكل خاص ملاحظة أن تنسيق التوقيع المفوض الذي قدمه EIP-7702 غير متوافق مع معايير التوقيع الحالية EIP-191 و EIP-712. يمكن أن يتجاوز التوقيع بسهولة تحذيرات التوقيع والتفاعلات الأصلية في المحفظة، مما يزيد من خطر تعرض المستخدمين للخداع لتوقيع عمليات ضارة. لذلك، فإن إدخال آلية التعرف والتعامل مع هيكل التوقيع هذا في تنفيذ المحفظة سيكون نقطة حاسمة لضمان سلامة المستخدم.
مخاطر عقد المحفظة
(1) إدارة أذونات عقد المحفظة
تتبنى العديد من عقود محافظ EIP-7702 بنية وكيل ( أو حقوق إدارة مدمجة ) لدعم ترقية المنطق. ومع ذلك، فإن هذا يجلب أيضًا مخاطر أعلى في إدارة الصلاحيات. إذا لم يتم تقييد حقوق الترقية بشكل صارم، قد يقوم المهاجمون باستبدال تنفيذ العقد وحقن شفرات خبيثة، مما يؤدي إلى تعديل حسابات المستخدمين أو سرقة الأموال.
نصائح الأمان:
استخدام التوقيع المتعدد، المصادقة متعددة العوامل أو آلية قفل الوقت للتحكم في أذونات الترقية.
يجب أن تخضع تغييرات التعليمات البرمجية والصلاحيات لعمليات تدقيق صارمة والتحقق من الأمان.
عملية الترقية الشفافة والمفتوحة تضمن حق المستخدم في المعرفة والمشاركة.
(2) خطر تعارض التخزين وعزل البيانات
قد تعيد إصدارات عقود المحفظة أو مزودي المحفظة المختلفين استخدام نفس فتحة التخزين. إذا قام المستخدم بتغيير مزود خدمة المحفظة أو ترقية منطق المحفظة ، فإن إعادة استخدام فتحة التخزين ستؤدي إلى تعارض متغير الحالة ، وستكون هناك مشاكل مثل الكتابة فوق البيانات واستثناءات القراءة. لا يمكن أن يؤدي ذلك إلى تعطيل الأداء الطبيعي للمحفظة فحسب ، بل يمكن أن يؤدي أيضا إلى فقدان الأموال أو الأذونات غير الطبيعية.
نصائح الأمان:
استخدم حلول التخزين المعزولة المتخصصة (مثل معيار EIP-1967) أو استعن بمساحة أسماء فريدة لإدارة فتحات التخزين.
عند ترقية العقد، تأكد من توافق تخطيط التخزين وتجنب تداخل المتغيرات.
اختبار صحة حالة التخزين في عملية ترقية صارمة.
( إدارة nonce داخل المحفظة
عادة ما تحتوي عقود المحفظة على nonce داخليا وتدير نفسها لضمان ترتيب تنفيذ عمليات المستخدم ومنع هجمات الإعادة. إذا لم يتم استخدام nonce بشكل صحيح ، فلن يتم تنفيذ عملية المستخدم بشكل صحيح.
نصائح الأمان:
يجب أن يكون nonce متساويًا (أو متزايدًا) ولا يمكن تخطيه.
يُمنع تعديل nonce مباشرة بواسطة الدالة، يجب أن يتم تحديث nonce فقط عند تنفيذ العمليات بواسطة المستخدم.
تصميم آليات التحمل والاسترداد لحالات استثناء nonce لتجنب توقف nonce.
)4( فحص صلاحيات مستدعي الدالة
لتأمين الأمان، يجب على عقد المحفظة التأكد من أن المتصل بالوظائف الأساسية هو حساب مالك المحفظة. تشمل الطريقتان الشائعتان:
تفويض التوقيع خارج السلسلة
يقوم المستخدم بتوقيع مجموعة من العمليات باستخدام المفتاح الخاص، ويتحقق عقد المحفظة على السلسلة من صحة التوقيع وما إذا كان قد انتهت صلاحيته وما إذا كان يفي بال nonce المقابل. هذه الطريقة مناسبة لنموذج المعاملات الوسيطة الذي يروج له EIP-7702 (توقيع المستخدم غير المتصل + إرسال المعاملات بواسطة الوسيط).
استدعاء القيود (msg.sender == address )this()
تسمح وظائف العمليات الخاصة بالمستخدم بالاستدعاء فقط من قبل العقد نفسه، وهي في جوهرها آلية للتحكم في مسارات الاستدعاء، تضمن أن يكون المحفز الخارجي هو نفس الحساب. وهذا يعادل فعليًا أن يكون المستدعي هو EOA الأصلي، لأن عنوان العقد في هذه الحالة هو عنوان EOA.
ثالثاً، التطلع: EIP-7702 ومعايير محفظة AA المستقبلية
إن تقديم EIP-7702 ليس فقط تجديدًا لنموذج الحساب التقليدي، ولكنه أيضًا دفعة كبيرة لبيئة تجريد الحساب (Account Abstraction). إن القدرة التي تم إدخالها على تحميل المستخدم لرمز العقد توفر مساحة واسعة من الاستكشاف لتصميم المحفظة ونظام العقود في المستقبل، كما أنها تضع متطلبات جديدة لمعايير التدقيق الأمني.
التطور المتزامن مع EIP-4337: نحو التوافق الثنائي النمط
على الرغم من أن EIP-7702 و EIP-4337 لهما أهداف تصميمية مختلفة، فإن الأول يعيد بناء آلية تحميل كود الحسابات، بينما الثاني يبني مدخلات كاملة للمعاملات وبيئة تعبئة. ولكن لا يتعارض الاثنان مع بعضهما البعض، بل يتمتعان بتكامل قوي.
EIP-4337 يوفر "قناة تداول عامة" و"واجهة تنفيذ الحسابات المجردة"؛
يسمح EIP-7702 لحسابات المستخدمين بتخصيص قدرات منطقية للعقد ديناميكيًا دون تغيير العنوان؛
لذلك، قد تعتمد المحفظة المستقبلية "هيكل دعم مزدوج النمط": استخدام EIP-7702 كبديل خفيف الوزن على السلاسل التي لا تدعم EIP-4337، بينما تظل تعتمد على مجموعة البروتوكولات الكاملة لـ EIP-4337 في السيناريوهات التي تتطلب التعبئة خارج السلسلة، وتجميع المستخدمين المتعددين.
سوف تعزز هذه الآلية الثنائية الوضع من دعم المحفظة لنموذج صلاحيات الحسابات الأكثر مرونة على مستوى النواة، وآلية التراجع وخطط الاسترجاع.
دعم وإلهام منطق المحفظة الجديدة مثل MPC و ZK
تتمتع آلية تحويل الحسابات إلى عقود التي دعا إليها EIP-7702 بإمكانيات اندماج طبيعية مع البنى الجديدة الشائعة حاليًا مثل محافظ MPC، ومحافظ ZK، والمحافظ المعيارية:
في وضع MPC، لم يعد سلوك التوقيع يعتمد على مفتاح خاص واحد، بل يعتمد على اتخاذ قرارات مشتركة من عدة أطراف. يمكن أن تتحكم التواقيع الناتجة عن دمج EIP-7702 و MPC في منطق العقد المحمّل ديناميكيًا، مما يتيح استراتيجيات تنفيذ أكثر مرونة.
تتحقق محفظة ZK من هوية المستخدم أو تفويضه من خلال إثبات المعرفة الصفري، دون الحاجة إلى الكشف عن معلومات المفتاح الخاص. بعد دمج EIP-7702، يمكن لمحفظة ZK حقن عقود منطقية محددة مؤقتًا بعد الانتهاء من التحقق، مما يتيح تنفيذ سلوك شخصي بعد الحسابات الخاصة، مثل تنفيذ منطق معين تلقائيًا فقط عند استيفاء بعض الشروط الخاصة.
تسمح المحافظ المودولارية (Modular Wallets) باستخدام EIP-7702 لتفكيك منطق الحساب إلى عدة وحدات، وتحميلها ديناميكيًا عند الحاجة.
لذلك، يوفر EIP-7702 "حاوية التنفيذ" الأصلية بشكل أكبر للمحافظ المتقدمة المذكورة أعلاه: يمكن حقن منطق عقود مختلفة مع الحفاظ على عنوان المستخدم كما هو، مما يتجنب مشكلة الاعتماد على العنوان في عملية نشر العقود التقليدية، دون الحاجة إلى النشر المسبق، مما يعزز بشكل كبير مرونة وسعة سلوك الحسابات.
الدروس المستفادة من مطوري العقود والمراجعين
EIP-7702 ستدفع نحو تغيير عميق في نماذج التطوير. لم يعد مطورو العقود يعتبرون المتصلين مجرد EOAs تقليدية أو حسابات عقود ثابتة، بل يجب عليهم التكيف مع آلية جديدة تمامًا: يمكن لهوية المتصل أن تتحول ديناميكيًا بين EOA وحالة العقد أثناء عملية المعاملة، لم تعد منطق سلوك الحسابات ثابتة، بل يمكن تغييرها بمرونة حسب الحاجة. يتطلب هذا من المطورين والمراجعين أن يمتلكوا:
إدخال منطق تحقق أكثر صرامة من caller وتحديد الأذونات.
تحقق مما إذا كان مسار الاستدعاء يتأثر بمنطق العقد الديناميكي؛
تحديد نقاط الضعف المحتملة للسلوكيات مثل msg.sender.code.length == 0، isContract )(.
توضيح "اعتماد السياق" في منطق العقد، مثل التحكم في حدود الاستدعاء الثابت و deleGatecall؛
يدعم مستوى سلسلة الأدوات محاكاة وتحليل استعادة سيناريو setCode.
بعبارة أخرى، لم تعد أمان الكود مجرد "مشكلة قبل النشر"، بل أصبحت "عملية ديناميكية يجب التحقق منها أيضًا أثناء الاستدعاء والمعاملات".
أربعة، الخلاصة
يقدم EIP-7702 تنفيذا أخف وزنا وأصليا ومرنا لتجريد الحساب (AA) ، والذي يسمح ل EOA العادي بحمل منطق العقد وتنفيذه في معاملة واحدة. تكسر هذه الآلية الافتراضات الثابتة التقليدية حول سلوك الحساب ، ولم يعد بإمكان المطورين الاعتماد ببساطة على حالة التعليمات البرمجية لعنوان الحساب للحكم على نموذج السلوك الخاص به ، ولكنهم يحتاجون إلى إعادة بناء فهم حدود الهوية والسلطة للمتصل. مع ذلك يأتي نقلة نوعية في تحليلات الأمان. لم يعد تركيز التدقيق يقتصر على "ما إذا كان العنوان لديه أذونات" ، ولكنه ينتقل إلى "ما يمكن أن يفعله منطق العقد في المعاملة في السياق الحالي". قد تحمل كل معاملة تعريفا مستقلا للسلوك ، مما يمنح الحساب وظائف أكبر ويضع متطلبات أعلى لعمليات التدقيق الأمني.
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
Beosin: تحليل تدقيق أمان المحفظة AA من الجيل التالي EIP-7702
كتبه: Beosin
يعد تجريد الحساب (AA) اتجاها مهما للاستكشاف طويل الأجل في نظام Ethereum البيئي ، ويهدف إلى كسر الحدود بين الحسابات الخارجية (EOA) وحسابات العقود ، بحيث تتمتع المحفظة بقابلية أقوى للبرمجة والأمان والترقية. تم استخدام EIP-4337 ، باعتباره حل تنفيذ AA الأكثر شيوعا ، على نطاق واسع في عدد من محافظ العقود الذكية المستندة إلى EntryPoint (مثل Safe و Stacks و Argent). ومع ذلك ، لا يزال لدى EIP-4337 قيود معينة من حيث الأصالة على السلسلة والتعقيد التشغيلي والتوافق البيئي بسبب تقديمه لمجمع معاملات مستقل وآلية عقد على منحدر.
لخفض عتبة استخدام تجريد الحسابات بشكل أكبر وتعزيز الدعم الأصلي لها، اقترح فيتالك في عام 2024 EIP-7702، وتم تضمين هذا الاقتراح في ترقية بيكترا. الفكرة الأساسية لـ EIP-7702 هي: السماح لـ EOA الأصلي عند بدء المعاملة، بتنفيذ كود العقد (contract_code) من عنوان محدد، حيث يحدد هذا الكود منطق تنفيذ المعاملة.
يقدم EIP-7702 آلية جديدة ل "حقن التعليمات البرمجية على مستوى المعاملة" ، والتي تسمح لحسابات المستخدمين بتحديد منطق التنفيذ ديناميكيا في كل معاملة ، بدلا من الاعتماد على رمز العقد المنشور مسبقا. هذا يكسر نموذج الإذن التقليدي المستند إلى التعليمات البرمجية الثابتة ، ويجلب قدرا أكبر من المرونة ، ويقدم تحديات أمنية جديدة: قد تصبح العقود التي تعتمد على منطق الحكم مثل isContract و extcodehash غير صالحة ، وقد يتم تجاوز بعض الأنظمة التي تفترض أن المتصل هو EOA خالص. وبالنسبة لمراجعي الحسابات، من المهم ليس فقط التحقق من أمن الشفرة المحقونة نفسها، ولكن أيضا تقييم تأثيرها المحتمل على أنظمة العقود الأخرى في سياق ديناميكي.
في هذه المقالة ، سيركز فريق أمان Beosin على مبادئ التصميم والميزات الرئيسية ل EIP-7702 ، وفرز المخاطر الأمنية التي قد تواجهها محفظة AA التي تم إنشاؤها بناء عليها بشكل منهجي في التدقيق ، وطرح عملية التدقيق والاقتراحات من منظور عملي لمساعدة الباحثين الأمنيين على التعامل بشكل أفضل مع التحديات التقنية في ظل هذا النموذج الجديد.
أولاً، مقدمة EIP-7702
EIP-7702 قدم نوعًا جديدًا من المعاملات 0x04 (SetCode) ، والذي يسمح لـ EOA بتفويض كود العقد المطلوب تنفيذه من خلال هذه المعاملة ، وهيكل المعاملة كما يلي:
تشمل authorization_list عدة قوائم تفويض، ويمكن أن تحتوي أيضًا على سلوك تفويض غير المبادرين بالمعاملات، والهيكل الداخلي هو:
حيث أن chain_id يشير إلى السلسلة التي يتم تفعيل تفويض المستخدم عليها، ويجب أن تكون قيمته مساوية لرقم تعريف السلسلة المنفذة أو 0. عندما يكون chain_id 0، فهذا يعني أن التفويض ساري على جميع سلاسل EVM التي تدعم EIP-7702، شريطة أن تتطابق المعلمات الأخرى (مثل nonce). أما address فهو يشير إلى عنوان العقد المستهدف الذي تم تفويضه من قبل المستخدم.
بعد الانتهاء من التفويض، ستقوم النظام بتعديل حقل code الخاص بالمستخدم المفوض إلى 0xef0100 || address، حيث address هو عنوان العقد المصرح به. إذا كنت ترغب في إلغاء التفويض، ما عليك سوى بدء صفقة SetCode وتعيين address إلى عنوان 0.
(1) المرونة والتخصيص
تتيح الحسابات المجردة تخصيص الوظائف بشكل مرن بناءً على المتطلبات من خلال كتابة منطق الحساب في العقود الذكية. على سبيل المثال، يمكن للمستخدمين تكوين التوقيعات المتعددة، واستعادة الحسابات الاجتماعية، وفرض قيود على الحدود، لتلبية الاحتياجات المختلفة للأفراد أو الشركات. يزيد هذا التصميم بشكل كبير من إمكانية توسيع وظائف الحساب، ويتجاوز قيود الحسابات الخارجية التقليدية (EOA).
(2) تعزيز الأمان
تقدم الحسابات المجردة آليات أمان متعددة الطبقات، بما في ذلك المصادقة المتعددة، وحدود المعاملات، واستعادة اجتماعية. حتى إذا فقد المستخدم مفتاحه الخاص، يمكنه استعادة حسابه من خلال جهات اتصال موثوقة أو من خلال التحقق المتعدد، مما يتجنب الخسارة الدائمة للأصول بسبب فقدان المفتاح الخاص في الحسابات التقليدية. في الوقت نفسه، يمكن أن تمنع وظائف مثل التحكم في الحدود من سرقة الأموال الكبيرة بشكل خبيث.
(3) تحسين الغاز
تدعم الحسابات المجردة آلية مرنة لتجريد الغاز، مما يسمح للمستخدمين بدفع الغاز من خلال طرف ثالث، أو حتى الدفع مباشرة باستخدام رموز أخرى لتكاليف المعاملات. لا تقلل هذه الآلية من تكلفة العمليات للمستخدمين فحسب، بل تبسط أيضًا عملية استخدام blockchain، مما يجعلها مناسبة بشكل خاص للمستخدمين الجدد أو سيناريوهات المعاملات المعقدة متعددة الخطوات.
(4) تعزيز انتشار Web3
من خلال تحسين التجربة والأمان، تخفي الحسابات المجردة تعقيدات blockchain في أماكن لا يستطيع المستخدم رؤيتها، مما يوفر عمليات أكثر سهولة تشبه Web2. يقلل هذا التصميم من تكلفة التعلم للمستخدمين العاديين، مما يجعل المزيد من الأشخاص قادرين على المشاركة بسهولة في تطبيقات Web3، مما يعزز انتشار التقنية اللامركزية.
ثانياً، تحليل مخاطر الأمان في ممارسة EIP-7702
على الرغم من أن EIP-7702 قد أضفى حيوية جديدة على نظام إيثيريوم البيئي ووسع من مجموعة التطبيقات الغنية، إلا أنه في الوقت نفسه، لا بد أنه قد أدخل بعض المخاطر الأمنية الجديدة.
في نموذج EIP-7702، إذا قام المستخدم بتعيين حقل chain_id في التفويض إلى 0، فهذا يعني أن هذا التفويض يمكن أن يكون ساري المفعول عبر سلاسل متعددة. على الرغم من أن تصميم "التفويض العام عبر السلاسل" هذا يزيد من المرونة في بعض السيناريوهات، إلا أنه في الوقت نفسه يقدم مخاطر أمان واضحة.
من المهم ملاحظة أنه حتى إذا كان معرف الحساب هو نفسه على عناوين مختلفة في سلاسل مختلفة، فإن تنفيذ العقد وراء ذلك قد يكون مختلفًا تمامًا. وهذا يعني أن المهاجم قد ينشر نسخة خبيثة من العقد على سلسلة أخرى، مستفيدًا من سلوك التفويض على نفس العنوان على السلسلة، مما يؤدي إلى تنفيذ عمليات غير متوقعة، وبالتالي تعريض أصول المستخدمين للخطر.
لذا، بالنسبة لمزودي خدمات المحفظة أو منصات التفاعل الأمامية، عند قيام المستخدم بإجراء عمليات التفويض من هذا النوع، يجب التحقق بوضوح مما إذا كان chainId المصرح به من قبل المستخدم يتطابق مع الشبكة المتصلة حاليًا؛ وإذا تم اكتشاف أن المستخدم قد قام بتعيين chainId إلى 0، يجب تقديم تحذير واضح من المخاطر، مما ينبه المستخدم أن هذا التفويض سيكون ساري المفعول على جميع سلاسل EVM المتوافقة وقد يتم استغلاله من قبل العقود الضارة.
بالإضافة إلى ذلك، يجب على جهة الخدمة تقييم ما إذا كان ينبغي تقييد أو منع بشكل افتراضي في واجهة المستخدم إذن chainId يساوي 0، لتقليل مخاطر الأخطاء أو هجمات التصيد.
(1) توافقية استدعاء العقد
ستستدعي عقود الرمز المميز الحالية مثل ERC-721 و ERC-777 و ERC1155 واجهات معاودة الاتصال القياسية (مثل onERC721Received و tokensReceived) لإكمال عملية التحويل عند تحويل الأموال إلى عنوان العقد. إذا لم يقم عنوان الاستلام بتنفيذ الواجهة المقابلة، فسيفشل النقل أو حتى يتسبب في تأمين الأصل.
في EIP-7702، يمكن تعيين عنوان المستخدم كرمز عقد من خلال عملية "set_code"، مما يحوله إلى حساب عقد. في هذه الحالة:
سيتم اعتبار عنوان المستخدم كعقد؛
إذا لم ينفذ العقد واجهات الاسترجاع الضرورية، فسوف يؤدي ذلك إلى فشل تحويل الرمز المميز؛
قد لا يتمكن المستخدمون من تلقي الرموز الرئيسية دون علمهم.
لذلك، يجب على المطورين التأكد من أن العقد الهدف الذي يعينه المستخدم ينفذ واجهات الاستدعاء ذات الصلة لضمان التوافق مع الرموز الرئيسية.
(2) فشل التحقق من "tx.origin"
في العقود التقليدية، غالبًا ما يُستخدم "tx.origin" لتحديد ما إذا كانت المعاملة قد تمinitiated من قبل المستخدم مباشرة، وذلك للوقاية من استدعاء العقود وغيرها من ضوابط الأمان. لكن في سيناريو EIP-7702:
توقيع المستخدم على تفويض المعاملة، يتم بثها فعليًا بواسطة المكرر أو خدمة التجميع (bundler)؛ عند تنفيذ المعاملة، يكون "tx.origin" هو عنوان المكرر، وليس عنوان المستخدم.
"msg.sender" هو عقد المحفظة الذي يمثل هوية المستخدم.
لذا ، فإن التحقق من الأذونات بناءً على "tx.origin == msg.sender" سيؤدي إلى رفض عمليات المستخدمين الشرعيين وفقدان موثوقيتها ، وبالمثل فإن استخدام "tx.origin == user" كقيود لاستدعاء العقود سيفشل أيضًا. يُنصح بالتخلي عن "tx.origin" كأساس للحكم على الأمان والانتقال إلى التحقق من التوقيع أو آلية التفويض.
(3) خطأ في تقييم 「isContract」
تمنع العديد من العقود حسابات العقود من المشاركة في بعض العمليات مثل الإيجارات وعمليات الشراء من خلال "isContract (address)" (التحقق من طول كود العنوان):
تحت آلية EIP-7702، يمكن أن تتحول عناوين المستخدمين إلى حسابات عقود من خلال معاملة "set_code"، وتعيد "isContract" القيمة true، مما يؤدي إلى خطأ في تصنيف المستخدمين الشرعيين كحسابات عقود، مما يرفض مشاركتهم في العمليات، مما يؤدي إلى عدم قدرة المستخدمين على استخدام بعض الخدمات، مما يعرقل التجربة. مع انتشار محافظ العقود، لم يعد تصميم الاعتماد على "isContract" لتحديد "ما إذا كان المستخدم إنسانًا" آمنًا، يُوصى باستخدام وسائل تحديد الهوية الأكثر دقة مثل التحقق من التوقيع.
بعد تنفيذ آلية التفويض لـ EIP-7702، ستخضع الأصول في حساب المستخدم بالكامل لسيطرة العقد الذكي المفوض. بمجرد أن يمنح المستخدم الإذن لعقد خبيث، قد يتمكن المهاجمون من الحصول على السيطرة الكاملة على أصول الحساب، مما يؤدي إلى تحويل الأموال بسرعة أو سرقتها، مما يشكل خطرًا أمنيًا كبيرًا.
لذلك ، من المهم لمزودي خدمات المحفظة دعم EIP-7702 لحل المعاملات وآليات تحديد المخاطر في أسرع وقت ممكن. عندما يوقع مستخدم على معاملة عهدة، يجب أن تعرض الواجهة الأمامية عنوان العقد المستهدف بوضوح وبشكل بارز، وأن تجمع بين المعلومات الداعمة مثل مصدر العقد ومعلومات النشر لمساعدة المستخدمين على تحديد التصيد الاحتيالي المحتمل أو السلوكيات الاحتيالية، وبالتالي تقليل مخاطر التوقيع الخاطئ. علاوة على ذلك ، يجب أن تدمج خدمة المحفظة إمكانات تحليل الأمان الآلي للعقد المستهدف ، مثل التحقق من حالة المصدر المفتوح لرمز العقد ، وتحليل نموذج الأذونات ، وتحديد العملية التي يحتمل أن تكون خطرة ، لمساعدة المستخدمين على إصدار أحكام أكثر أمانا قبل التفويض.
من المهم بشكل خاص ملاحظة أن تنسيق التوقيع المفوض الذي قدمه EIP-7702 غير متوافق مع معايير التوقيع الحالية EIP-191 و EIP-712. يمكن أن يتجاوز التوقيع بسهولة تحذيرات التوقيع والتفاعلات الأصلية في المحفظة، مما يزيد من خطر تعرض المستخدمين للخداع لتوقيع عمليات ضارة. لذلك، فإن إدخال آلية التعرف والتعامل مع هيكل التوقيع هذا في تنفيذ المحفظة سيكون نقطة حاسمة لضمان سلامة المستخدم.
(1) إدارة أذونات عقد المحفظة
تتبنى العديد من عقود محافظ EIP-7702 بنية وكيل ( أو حقوق إدارة مدمجة ) لدعم ترقية المنطق. ومع ذلك، فإن هذا يجلب أيضًا مخاطر أعلى في إدارة الصلاحيات. إذا لم يتم تقييد حقوق الترقية بشكل صارم، قد يقوم المهاجمون باستبدال تنفيذ العقد وحقن شفرات خبيثة، مما يؤدي إلى تعديل حسابات المستخدمين أو سرقة الأموال.
نصائح الأمان:
استخدام التوقيع المتعدد، المصادقة متعددة العوامل أو آلية قفل الوقت للتحكم في أذونات الترقية.
يجب أن تخضع تغييرات التعليمات البرمجية والصلاحيات لعمليات تدقيق صارمة والتحقق من الأمان.
عملية الترقية الشفافة والمفتوحة تضمن حق المستخدم في المعرفة والمشاركة.
(2) خطر تعارض التخزين وعزل البيانات
قد تعيد إصدارات عقود المحفظة أو مزودي المحفظة المختلفين استخدام نفس فتحة التخزين. إذا قام المستخدم بتغيير مزود خدمة المحفظة أو ترقية منطق المحفظة ، فإن إعادة استخدام فتحة التخزين ستؤدي إلى تعارض متغير الحالة ، وستكون هناك مشاكل مثل الكتابة فوق البيانات واستثناءات القراءة. لا يمكن أن يؤدي ذلك إلى تعطيل الأداء الطبيعي للمحفظة فحسب ، بل يمكن أن يؤدي أيضا إلى فقدان الأموال أو الأذونات غير الطبيعية.
نصائح الأمان:
استخدم حلول التخزين المعزولة المتخصصة (مثل معيار EIP-1967) أو استعن بمساحة أسماء فريدة لإدارة فتحات التخزين.
عند ترقية العقد، تأكد من توافق تخطيط التخزين وتجنب تداخل المتغيرات.
اختبار صحة حالة التخزين في عملية ترقية صارمة.
( إدارة nonce داخل المحفظة
عادة ما تحتوي عقود المحفظة على nonce داخليا وتدير نفسها لضمان ترتيب تنفيذ عمليات المستخدم ومنع هجمات الإعادة. إذا لم يتم استخدام nonce بشكل صحيح ، فلن يتم تنفيذ عملية المستخدم بشكل صحيح.
نصائح الأمان:
يجب أن يكون nonce متساويًا (أو متزايدًا) ولا يمكن تخطيه.
يُمنع تعديل nonce مباشرة بواسطة الدالة، يجب أن يتم تحديث nonce فقط عند تنفيذ العمليات بواسطة المستخدم.
تصميم آليات التحمل والاسترداد لحالات استثناء nonce لتجنب توقف nonce.
)4( فحص صلاحيات مستدعي الدالة
لتأمين الأمان، يجب على عقد المحفظة التأكد من أن المتصل بالوظائف الأساسية هو حساب مالك المحفظة. تشمل الطريقتان الشائعتان:
تفويض التوقيع خارج السلسلة
يقوم المستخدم بتوقيع مجموعة من العمليات باستخدام المفتاح الخاص، ويتحقق عقد المحفظة على السلسلة من صحة التوقيع وما إذا كان قد انتهت صلاحيته وما إذا كان يفي بال nonce المقابل. هذه الطريقة مناسبة لنموذج المعاملات الوسيطة الذي يروج له EIP-7702 (توقيع المستخدم غير المتصل + إرسال المعاملات بواسطة الوسيط).
استدعاء القيود (msg.sender == address )this()
تسمح وظائف العمليات الخاصة بالمستخدم بالاستدعاء فقط من قبل العقد نفسه، وهي في جوهرها آلية للتحكم في مسارات الاستدعاء، تضمن أن يكون المحفز الخارجي هو نفس الحساب. وهذا يعادل فعليًا أن يكون المستدعي هو EOA الأصلي، لأن عنوان العقد في هذه الحالة هو عنوان EOA.
ثالثاً، التطلع: EIP-7702 ومعايير محفظة AA المستقبلية
إن تقديم EIP-7702 ليس فقط تجديدًا لنموذج الحساب التقليدي، ولكنه أيضًا دفعة كبيرة لبيئة تجريد الحساب (Account Abstraction). إن القدرة التي تم إدخالها على تحميل المستخدم لرمز العقد توفر مساحة واسعة من الاستكشاف لتصميم المحفظة ونظام العقود في المستقبل، كما أنها تضع متطلبات جديدة لمعايير التدقيق الأمني.
على الرغم من أن EIP-7702 و EIP-4337 لهما أهداف تصميمية مختلفة، فإن الأول يعيد بناء آلية تحميل كود الحسابات، بينما الثاني يبني مدخلات كاملة للمعاملات وبيئة تعبئة. ولكن لا يتعارض الاثنان مع بعضهما البعض، بل يتمتعان بتكامل قوي.
EIP-4337 يوفر "قناة تداول عامة" و"واجهة تنفيذ الحسابات المجردة"؛
يسمح EIP-7702 لحسابات المستخدمين بتخصيص قدرات منطقية للعقد ديناميكيًا دون تغيير العنوان؛
لذلك، قد تعتمد المحفظة المستقبلية "هيكل دعم مزدوج النمط": استخدام EIP-7702 كبديل خفيف الوزن على السلاسل التي لا تدعم EIP-4337، بينما تظل تعتمد على مجموعة البروتوكولات الكاملة لـ EIP-4337 في السيناريوهات التي تتطلب التعبئة خارج السلسلة، وتجميع المستخدمين المتعددين.
سوف تعزز هذه الآلية الثنائية الوضع من دعم المحفظة لنموذج صلاحيات الحسابات الأكثر مرونة على مستوى النواة، وآلية التراجع وخطط الاسترجاع.
تتمتع آلية تحويل الحسابات إلى عقود التي دعا إليها EIP-7702 بإمكانيات اندماج طبيعية مع البنى الجديدة الشائعة حاليًا مثل محافظ MPC، ومحافظ ZK، والمحافظ المعيارية:
في وضع MPC، لم يعد سلوك التوقيع يعتمد على مفتاح خاص واحد، بل يعتمد على اتخاذ قرارات مشتركة من عدة أطراف. يمكن أن تتحكم التواقيع الناتجة عن دمج EIP-7702 و MPC في منطق العقد المحمّل ديناميكيًا، مما يتيح استراتيجيات تنفيذ أكثر مرونة.
تتحقق محفظة ZK من هوية المستخدم أو تفويضه من خلال إثبات المعرفة الصفري، دون الحاجة إلى الكشف عن معلومات المفتاح الخاص. بعد دمج EIP-7702، يمكن لمحفظة ZK حقن عقود منطقية محددة مؤقتًا بعد الانتهاء من التحقق، مما يتيح تنفيذ سلوك شخصي بعد الحسابات الخاصة، مثل تنفيذ منطق معين تلقائيًا فقط عند استيفاء بعض الشروط الخاصة.
تسمح المحافظ المودولارية (Modular Wallets) باستخدام EIP-7702 لتفكيك منطق الحساب إلى عدة وحدات، وتحميلها ديناميكيًا عند الحاجة.
لذلك، يوفر EIP-7702 "حاوية التنفيذ" الأصلية بشكل أكبر للمحافظ المتقدمة المذكورة أعلاه: يمكن حقن منطق عقود مختلفة مع الحفاظ على عنوان المستخدم كما هو، مما يتجنب مشكلة الاعتماد على العنوان في عملية نشر العقود التقليدية، دون الحاجة إلى النشر المسبق، مما يعزز بشكل كبير مرونة وسعة سلوك الحسابات.
EIP-7702 ستدفع نحو تغيير عميق في نماذج التطوير. لم يعد مطورو العقود يعتبرون المتصلين مجرد EOAs تقليدية أو حسابات عقود ثابتة، بل يجب عليهم التكيف مع آلية جديدة تمامًا: يمكن لهوية المتصل أن تتحول ديناميكيًا بين EOA وحالة العقد أثناء عملية المعاملة، لم تعد منطق سلوك الحسابات ثابتة، بل يمكن تغييرها بمرونة حسب الحاجة. يتطلب هذا من المطورين والمراجعين أن يمتلكوا:
إدخال منطق تحقق أكثر صرامة من caller وتحديد الأذونات.
تحقق مما إذا كان مسار الاستدعاء يتأثر بمنطق العقد الديناميكي؛
تحديد نقاط الضعف المحتملة للسلوكيات مثل msg.sender.code.length == 0، isContract )(.
توضيح "اعتماد السياق" في منطق العقد، مثل التحكم في حدود الاستدعاء الثابت و deleGatecall؛
يدعم مستوى سلسلة الأدوات محاكاة وتحليل استعادة سيناريو setCode.
بعبارة أخرى، لم تعد أمان الكود مجرد "مشكلة قبل النشر"، بل أصبحت "عملية ديناميكية يجب التحقق منها أيضًا أثناء الاستدعاء والمعاملات".
أربعة، الخلاصة
يقدم EIP-7702 تنفيذا أخف وزنا وأصليا ومرنا لتجريد الحساب (AA) ، والذي يسمح ل EOA العادي بحمل منطق العقد وتنفيذه في معاملة واحدة. تكسر هذه الآلية الافتراضات الثابتة التقليدية حول سلوك الحساب ، ولم يعد بإمكان المطورين الاعتماد ببساطة على حالة التعليمات البرمجية لعنوان الحساب للحكم على نموذج السلوك الخاص به ، ولكنهم يحتاجون إلى إعادة بناء فهم حدود الهوية والسلطة للمتصل. مع ذلك يأتي نقلة نوعية في تحليلات الأمان. لم يعد تركيز التدقيق يقتصر على "ما إذا كان العنوان لديه أذونات" ، ولكنه ينتقل إلى "ما يمكن أن يفعله منطق العقد في المعاملة في السياق الحالي". قد تحمل كل معاملة تعريفا مستقلا للسلوك ، مما يمنح الحساب وظائف أكبر ويضع متطلبات أعلى لعمليات التدقيق الأمني.