مقدمة
هذا النص ينقسم إلى قسمين رئيسيين:
في الجزء العلوي ، سنقوم بتنظيم المحتوى الرئيسي لاقتراح Eip حتى الآن منذ عرض أول اقتراح AA في عام 2015 ، ونأمل في استخلاص تاريخ اقتراحات AA من الأثرياء وتقييم الجوانب الإيجابية والسلبية لكل برنامج بشكل شامل.
في النصف الثاني، يركز بشكل خاص على مواجهة التراجع السوقي الذي Enfrenta بعد اقتراح EIP4337، ثم يقوم بتحليل معمق لـ EIP7702 الذي سيتم دمجه في الترقية القادمة لإيثريوم، وبمجرد دمج هذا الاقتراح، سيغير شكل التطبيقات داخل السلسلة بشكل شامل.
EIP-7702 لديها تغيير ثوري، واسمع ما يقوله الربع عشر بعناية
قام مؤسس إيثيريوم Vitalik بتحديث خريطة تطوير ETH مرة أخرى في نهاية عام 2023 ، ولكن لم يتم تغيير إعدادات التجريد المتعلقة بالحساب. النمط السائد اليوم يتحول من EIP-4337 إلى المرحلة التالية للتحويل الطوعي لحساب EOA.
منذ أكثر من عام من إطلاق EIP4337 (في حدث WalletCon في دنفر في 1 مارس 2023 ، تم الإعلان رسميًا أن العقد الأساسي لـ ERC-4337 ، الذي تم تصميمه وتنفيذه بواسطة مطوري ETH Foundation ، قد تمت مراجعته بواسطة OpenZeppelin ويعتبر إطلاقًا رسميًا للعقد).
استنادا إلى الاعتراف الواسع النطاق من قبل المستخدمين ولكنها ليست مستخدمة على نطاق واسع، في هذا البيئة التناقضية، تم تقديم تقدم كبير في EIP-7702 مما أدى إلى تأكيد أنه سيتم دمجه في الترقية التالية.
لا حاجة للكلام كثيرًا، دعنا ننظر مباشرة إلى البيانات.
بعد عام ونصف من التطور، يوجد فقط 12 مليون عنوان تحت مجموعة الحسابات الرئيسية في EIP4337، والمفاجئ هو العدد القليل جدًا من العناوين النشطة على شبكة ETH الرئيسية، حيث يبلغ 6,764 عنوانًا فقط، قد يكون هناك بعض المشكلات في الإحصاءات، ولكن على الأقل هناك فارق كبير بين عدد العناوين المستقلة وعدد عناوين EOA و CA، يجب ملاحظة أن عدد العناوين المستقلة على شبكة ETH الرئيسية قد وصل إلى 270 مليون (بيانات المصدر:)
يمكن القول إن EIP4337 على الشبكة الرئيسية لم يحقق أي تقدم فعلي.
(مصدر بيانات الرسم البياني: )
ومع ذلك ، فإن هذا لا يزيل القيمة الأساسية لطراز AA ، لأنه من المحتمل منذ بداية تصميم EIP4337 أنه لن يكون قادرًا على حل مشكلة التوافق السابق الخطيرة على الشبكة الرئيسية ، لذلك تم تضمين AA الأصلي في مجموعة متنوعة من سلاسل L2 ، وحصلت EIP4337 على عناوين كبيرة على L2 ، بما في ذلك 100 ألف و 300 ألف مستخدم نشط شهريًا في سلسلة القاعدة وسلسلة البوليجون ، مما يعتبر مشجعًا بشكل كبير.
لذلك، لم يكن تصميم EIP4337 خاطئًا، لديه العديد من المزايا، سنلخص النقاط بشكل شامل في وقت لاحق، والحالة الحالية تعود إلى الاختلافات بين الشبكة الرئيسية وL2، حيث يحتاجون إلى حلول مناسبة لكل منها.
تجريد الحساب، يبدو أمرًا غامضًا، ولكنه في الواقع يحل مشكلة الفصل بين الملكية.
هناك نوعان من بنية EVM (على سبيل المثال ، ETH Square الآلة الافتراضية) ، والحساب الخارجي (EOA) وحساب العقد (حساب العقد) ، وحقوق الملكية والتوقيع للحساب الخارجي مملوكة بالفعل من قبل نفس الكيان. الشخص الذي يمتلك المفتاح الخاص ** ليس لديه “ملكية” هذا الحساب فحسب ، بل له أيضا الحق في “توقيع ونقل جميع الأصول”.
هذا محدد بناءً على هيكل حساب ETH
من بنية الشكل أدناه يمكن ملاحظة أن المعاملات القياسية في إيثيريوم ليست لديها الجانب من الجهة المرسلة، لذا عندما أقوم بتحويل الأموال مرة واحدة، فإن الأموال هي في الواقع مصروفة من العنوان المحدد. في الواقع، يتم استخراج العنوان المرسل (From) من معلمات VRS (أي التوقيع الخاص بالمستخدم).
يتضمن هذا الموضوع أفكارًا مثل التشفير غير المتماثل ECDSA ووظيفة الحاجز الأحادية الاتجاه وما إلى ذلك. لن نفتح هذا النقاش هنا، ولكن الأهم هو أن الأمان هنا يتم ضمانه بواسطة علم التشفير، وهذا بالطبع يؤدي إلى مشكلة عنوان EOA لدمج حقوق الملكية الفكرية في الوقت الحاضر.
والتأثير الأساسي لـ EIP4337 هو إضافة حقل عنوان المرسل في حقل الصفقة ، مما يمكن فصل المفتاح الخاص عن العنوان المستهدف.
لماذا الفصل بين حقوق الملكية مهم جدًا؟
وذلك لأن تصميم الحساب الخارجي (EOA) يثير المزيد من الأسئلة:
قيود الطعن تجعل من الصعب على المستخدمين العاديين استخدام إثيريوم:
أولاً، يجب أن يكون لدى المستخدم ETH (ويتحمل مخاطر تقلب السعر) لاستخدام أي تطبيق على ETH.
ثانيًا، يحتاج المستخدمون إلى التعامل مع منطق التكلفة المعقدة، مثل سعر الغاز، حد الغاز، وتعطيل المعاملات (ترتيب الـ nonce)، وهذه المفاهيم معقدة جدًا بالنسبة للمستخدمين.
أخيراً ، على الرغم من محاولة العديد من كتلة البلوكتشين أو المحفظة أو التطبيقات تحسين تجربة المستخدم من خلال تحسين المنتجات ، إلا أن تأثيرها الفعلي ضئيل للغاية.
لذلك، الطريق لحل المشكلة هو تحقيق تجريد الحساب، وفصل حقوق الملكية (Owner) وحقوق التوقيع (Signer)، وحل تلك المشكلات تدريجيًا.
في الواقع، هناك العديد من الخطط التاريخية، وسيتم التقاءها في النهاية إلى نوعين من المسارات
حل المشكلة يبدو أن لديه العديد من اقتراحات EIP ، ولكن في النهاية ، هناك فقط نوعان من الأفكار الرئيسية ، لذلك فإن كل EIP لم يتم الموافقة عليه في الماضي ، انطوت مشكلته في نهاية المطاف على طريقة الحل الحالية.
منذ نوفمبر 2015 ، قدم Vitalik مقترحًا حول EIP-101 لاستخدام العقود كبنية حسابية جديدة. يتم تغيير العنوان ليكون لديه فقط الشفرة والمساحة التخزينية ، وتغيير دعم رسوم التحويل ليتم دفعها بواسطة ERC20 ، وتحويل العملة الأصلية إلى أرصدة ERC20 المشابهة (قد تحتوي على وظائف مثل التفويض للاستقطاع) باستخدام العقود المعدة مسبقًا ، وتبسيط حقول المعاملات لتكون لديها فقط to و startgas و data و code.
الآن يبدو أنها تغيير ثوري بمعنى الكلمة، سيغير بشكل كبير التصميم الأساسي، مما سيجعل كل الحسابات تمتلك “الشفرة” الخاصة بها (وهذا بالفعل هو التأثير الذي يجب أن يحققه EIP-7702 الآن).
يمكن أن يشتق وظائف أخرى مثل
ليس هناك سبب للمضي قدمًا وهذا واضح جدًا ، وهو أن الخطوة كانت كبيرة جدًا ، ولم يتم النظر بشكل جيد في مشكلة التوافق مع الالتجزئة التجارية الحالية ومشاكل الأمان ، لذلك تم تأجيلها باستمرار ، ولكن فكرة كل ميزة أصبحت واحدة من وظائف EIP4337 و EIP7702 في الاستمرار.
ثم جاءت سلسلة من محاولات EIP لتحسين هذا النوع من المنطق
EIP-859: الحساب تجريد الحساب الرئيسي - 2018-01-30
محاولة حل مشكلة نشر Code، الوظيفة الرئيسية هي استخدام معلمة code المرفقة بالصفقة لتنفيذ نشر المحفظة إذا لم يتم نشر عقد الطرف المتعاقد. بالإضافة إلى ذلك، تم طرح رمز عملية PAYGAS الجديدة، حيث يعمل كفاصل بين الجزء الذي يتحقق منه المعلمة في جزء الصفقة والجزء الذي يتم تنفيذه.
على الرغم من أنها انتهت بدون مرض في ذلك الوقت، إلا أنها أصبحت أحد أساسيات EIP7702 الآن، حيث يمكن لكل صفقة في EIP7702 أن تحتوي على هيكل تنفيذ خاص يمكن أن يحتوي على بعض الشفرة، وبالتالي يمكن لحسابEOAالعنوان أن يمتلك قدرات العقد في هذه الصفقة.
EIP-7702: تعيين رمز الحساب EOA 2024-05-07
هذا هو جوهر EIP الذي سيتم مناقشته في هذه المقالة، حيث قدم فيتاليك EIP-7702 كبديل لـ EIP-3074 (2024-05-07). لذا تم التخلي عن EIP-3074، وتم تأكيد تضمين EIP-7702 في الشوكة القادمة ETH Prague/Electra (Pectra)، سنستعرض التفاصيل في الجزء التالي.
**EIP-3074: إضافة AUTH و AUTHCALL إلى رموز العمليات–2020-10-15
إضافة أوب كودين جديدين (AUTH و AUTHCALL) إلى EVM لتمكين الحسابات الخارجية من تفويض العقود للقيام بعمليات الاستدعاء بدلاً منها.
باستخدام الرسم البياني أدناه ، يمكن لـ EOA بشكل عام إرسال رسالة (معاملة) موقعة بالفعل إلى عقد يثق فيه (يُشار إليه بـ Invoker) ، ويمكن لهذا العقد Invoker استخدام أوامر التشغيل AUTH و AUTHCALL بدلاً من EOA لإرسال هذه المعاملة.
EIP-4337: استخدام مجمع الذاكرة للمعاملات لتحقيق تجريد الحساب–2021-09-29
بالمجمل، كان مستوحى من MEV للقيام بالتصميم، والقيمة الأساسية له هي القدرة على تجنب تغيير بروتوكول طبقة الاتفاق تمامًا.
يقترح eip4337 كائن معاملة جديد UserOperation ، والذي يتم إرساله من قبل المستخدم إلى mempool ، وحزمة الحزم وتسليم العقد على دفعات من بعد عامل المنجم لتنفيذ معاملة المعاملة ، والتي تسحب بشكل أساسي المعاملة الأساسية وعملية الحساب إلى مستوى العقد للتنفيذ.
EIP-5189: العمل بحساب تجريبي من خلال شخص يقوم بالتوقيع - 2022-06-29
هذا يعتبر تحسينًا للمنطق EIP4337. إنه يواجه Bundler الخبيث من خلال إنشاء آلية للعقوبة المالية للموافقة على الدعاية لمنع هجمات Dos الحجب.
EIP-2718: ظرف تعبئة نوع معاملة جديد - 2020-06-13
هذا هو مقترح نهائي بالفعل ، حيث يحدد نوع تجارة جديد كظرف لأنواع التجارة الجديدة المضافة في المستقبل.
النتيجة النهائية هي تمييز نوع المعاملة الجديد عند إدخاله باستخدام ترميز محدد ، مما يجعلها متوافقة مع الإصدارات السابقة فقط دون الحاجة إلى التوافق السابق. أحد الأمثلة الأكثر شيوعًا هو EIP1559 ، الذي يميز رسوم المعاملات ويستخدم ترميزًا جديدًا لنوع المعاملة ، دون التأثير على النوع الأصلي القديم من المعاملات.
EIP-3607: تجعل العنوان EOA غير قابل لنشر العقود - 2021-06-10
هذا هو خطة إضافية على مسار AA لمنع تعارض العناوين بين العقد وعناوين EOA. سيتحكم في طريقة إنشاء العقود لمنع نظام من تنصيب الشيفرة على عنوان EOA موجود بالفعل. هذا الخطر في الواقع صغير جدًا ، بعد كل شيء ، تحتوي عناوين Ethereum على 160 بتًا ، وعلى الرغم من وجود طرق لاصطدام المفتاح الخاص بعنوان العقد المحدد ، فإنه سيستغرق أيضًا عامًا من الزمن بالنظر إلى قدرة الحساب الكلية لبيتكوين.
أولاً، يجب فهم القيمة بعد التحويل إلى CA
في الأساس ، هو تنفيذ تأثير EIP-4337 ، ويمكنه تحقيق ذلك
ومع ذلك ، يتعارض العيب الأساسي لـ EIP-4337 مع مبدأ دوافع الإنسانية.
يبدو أنه تحسن، ولكنه وقع في حلقة مغلقة لتطوير السوق، حيث أن العديد من تطبيقات العقود الذكية لا تزال غير متوافقة، وبالتالي فإن المستخدمين لا يرغبون في استخدام عناوين CA، وحتى عند استخدام CA في سيناريوهات النقل العادية، فإنه يوجد تكلفة عملية أعلى (قد يصل إلى غسيل أموال مضاعفة)، وهو معتمد بشكل كبير على توافق تطبيقات العقود الذكية نفسها.
لذلك، حتى الآن، لم ينتشر ذلك على شبكة الإيثريوم الرئيسية.
التكلفة هي المعيار الأهم الذي يقيسه المستخدمون، يجب اسقاط التكلفة.
ولكن إذا كنت ترغب في إسقاط الغاز الحقيقي، فيجب أن تقوم بترقية فورك ليننوض على الإيثريوم نفسه، وتعديل حساب الغاز أو استهلاك الغاز للعمليات التي تستخدم الأكواد العملية، ومع ذلك، إذا كان الهدف هو عمل soft fork، فلماذا لا يتم النظر مباشرةً في EIP-7702؟
يتم التمييز بينها بواسطة أنواع المعاملات الجديدة، ويمكن لحساب المالك أن يحمل مؤقتًا وظيفة العقد الذكي في معاملة واحدة، وبالتالي يدعم المعاملات الجماعية والمعاملات بدون رسوم وإدارة الصلاحيات المخصصة وما إلى ذلك بدون الحاجة إلى إدخال أوامر EVM جديدة (مما يؤثر على التوافقية السابقة).
يمكنه أن يمنح المستخدمين قدرات معظم AA دون الحاجة إلى نشر العقد الذكي، وحتى القدرة على توفير قدرة الجهات الخارجية على إطلاق المعاملات بالنيابة عن المستخدمين، دون الحاجة إلى توفير المفتاح الخاص للمستخدمين، فقط قم بتوقيع المعلومات المصرح بها.
هو قام بتحديد نوع معاملة جديد 0x04، حيث أن TransactionPayload لهذا النوع من المعاملات هو نتيجة التسلسل للمحتوى التالي
الشيء المهم هو إضافة كائن authorization_list فيها تخزين المستخدمون الذين يرغبون في تنفيذ رمز في حسابهم الشخصي. يقوم المستخدمون بتوقيع المعاملة وفي نفس الوقت يوقعون على رمز العقد الذي يرغبون في تنفيذه. يتم تخزينه كقائمة ثنائية الأبعاد، وهذا يشير إلى إمكانية تخزين معلومات عملية متعددة بشكل جماعي وتنفيذ عمليات دفعة واحدة.
4.3.1 مرحلة التحقق
في مرحلة بدء تنفيذ المعاملات ، بالنسبة لكل قائمة تفويض [chain_id ، address ، nonce ، y_parity ، r ، s] :
4.3.2 مرحلة تنفيذ العملية
أين يتم وضع كود العقد الذكي المطلوب تنفيذه وتعليمات العمل؟
الإصدار الجديد يغير فقط سلوك النصوص المصدرية.
لم يعد يقوم بتعيين رمز الحساب كـ contract_code ، بل يسترد رمز العنوان من قائمة الترخيص ويقوم بتعيين ذلك الرمز كرمز الحساب.
لذا، عند الحاجة إلى تنفيذ رمز الترخيص، قم بتحميل الرمز من العنوان المحدد في حقل العنوان في authorization_list وتنفيذه في سياق الحساب الموقع.
هذا يعني أن كود العقد الذكي الخاص بالمستخدم يتم تخزينه في عنوان معين داخل السلسلة بدلاً من أن يكون مضمنًا مباشرة في المعاملة.
أما تعليمات العمليات والمعلمات ذات الصلة فهي مخزنة في حقل البيانات لحمولة التداول.
سيتغير كل شيء في سلسلة الوصل الكاملة لمحفظة Web3، وبالتالي ستتغير تجربة المستخدم، حيث يمكن للمعاملات العادية التي تبدأ بواسطة EOA أيضًا تنفيذ العديد من العقود المنطقية، مثل النقل بالجملة. ستؤثر على التحقق من المعاملات في سيفي وستؤثر أيضًا على رسوم التحويل وتجميعها
نظرًا لظهوره، فإنه يكسر العديد من الثوابت السابقة، مثل:
1. مزايا EIP-7702
الغاز أقل لأنه لا يحتاج إلى مرور عبر وحدة نقطة الدخول، مما يقلل من العمليات داخل السلسلة.
تكلفة الهجرة للمستخدم أقل، لا حاجة لنشر العقود داخل السلسلة مسبقا ككيان رئيسي
بالمقارنة مع Eip4337، سيتم تنفيذ الوكالة البرمجية بنفس الطريقة، وسيكون هناك نوعان من الطرق:
الوفد الكامل (Full Delegation)
المفوضية الكاملة تشير إلى تفويض جميع الأذونات لعملية ما إلى العنوان المحدد. على سبيل المثال، يمكن للمستخدم تفويض صلاحيات إدارة جميع عملات ERC-20 لالعقد الذكي الذي يمثله العنوان، وبالتالي يمكن للعقد الذكي تنفيذ جميع العمليات ذات الصلة نيابة عن المستخدم.
التفويض المحمي (Protected Delegation)
الوكالة المحمية هي عملية يتم فيها إضافة بعض القيود والتدابير الوقائية خلال عملية الوكالة لضمان الأمان والتحكم في العملية.
على سبيل المثال، يمكن للمستخدم أن يفوض صلاحيات إدارة جزء من العملة ERC-20 إلى عقد ذكي واحد، أو يضع بعض الشروط المقيدة (مثل الحد الأقصى لإنفاق 1% من الرصيد الإجمالي يوميًا).
2. عيوب EIP-7702
أساسي عيوبه تنتمي إلى ترقية سوفت فورك، وتحتاج إلى إجماع الجميع للدفع بها، والتي تتطلب تغييرات جذرية وتؤثر بشكل كبير على البيئة داخل السلسلة. بناءً على تقييم أولي، هناك تحديات تالية، ولكن التحديات هي فرص السوق أيضًا:
هذه مجرد بعض العيوب التي تم تلخيصها من خلال مقترح EIP 7702 الحالي والنقاش الرسمي المقابل، ولا يمكن تحليلها بشكل كامل إلا عندما يتم استنتاجها بناءً على الشفرة التنفيذية النهائية.
يرجى الرجوع إلى ما يلي:
يبدو هذا المقال طويلًا ، ولكن في الواقع فإن محتوى النص يحتوي فقط على أكثر من 6 آلاف حرف ، والعديد من تفسيرات EIP السابقة التي تم ذكرها في النص تتوفر في الروابط الموجودة في النص ولن أتعمق فيها.
حالياً، يبدو أن تجريد الحساب، يجب بالفعل أن يتم وضعه في الوحدة السادسة، أي إصلاح كل شيء، وأيضاً في نهاية المطاف في التنفيذ، والآن يتم تسريع تقدم EIP7702 بشكل كبير، مما يعرض النظام لمزيد من التحديات فيما يتعلق بالأمان، يمكن التنبؤ بأنه في النهاية سيتم تحقيقه، بعد كل شيء، يمكن أن يحدث حتى أحداث مثل دمج ETH، وتعديل الإجماع وخوارزمية الإجماع هذه المدمرة، فكيف يمكن التحدث عن أنواع جديدة بسيطة من المعاملات؟
لكن هذه المرة كان هناك الكثير من المحتوى المقلوب ، حطم العديد من القواعد السرية التي لا يمكن كسرها داخل السلسلة ، كما حطم العديد من الخوارزميات المطبقة في معظم تطبيقات Dapp. لكنه حافظ بشكل كبير على النقطة الأساسية ، وهي تكلفة المستخدم أقل! مقارنةً بتكلفة العملية القريبة من الضعف لـ EIP4337.
المستخدم في حد ذاته هو EOA العنوان ، ولكنه يقوم بتنشيط واستخدام منطق CA فقط عند الحاجة ، مما يقلل من تكلفة الحيازة. لا حاجة لتحويل هوية CA على السلسلة ثم القيام بالعمليات ، مما يعني أن المستخدم لا يحتاج إلى التسجيل.
يمكن للمستخدمين بسهولة القيام بمعاملات متعددة بتقنية EOA، مثل تفويض الدفع وتنفيذ الدفع في نفس الوقت، مما يؤدي إلى تقليل تكلفة العملية بالنسبة للمستخدمين، بينما يؤدي ذلك إلى تحسين كبير بالنسبة لـ Dapp، وخاصةً لفرق المشاريع التي تحتاج إلى إدارة شبكية داخل السلسلة، مثل تبادلات وغيرها، وبمجرد تحقيق تجميع الكميات الضخمة بشكل أساسي، يمكن تقليل تكلفة التبادل بنسبة 50٪ على الفور ويمكن أن يستفيد المستخدمون من ذلك.
لذلك، على الرغم من تغييره في العديد من الأشياء، إلا أن الاحتكار التكلفة هذا البعد يستحق بحث وتكييف جميع التطبيقات اللامركزية، لأن المستخدمين يقفون هذه المرة بالتأكيد مع EIP7702.