سواء كان سوقًا صاعدًا أو سوقًا هابطة ، فإن النظام البيئي Ethereum يبني باستمرار ويحسن نفسه. من بينها ، حقق Account Abstraction (AA) تقدمًا مهمًا في السنوات الأخيرة وتغلغل في جميع أجزاء النظام البيئي Ethereum ، بما في ذلك التطبيقات والبنية التحتية والمستخدمين والمطورين. يمكننا أن نتوقع أن اعتماد AA على نطاق واسع سيقلل من عتبة استخدام blockchain ككل ويقدم تجربة مستخدم web2 في صناعة web3.
في هذه المقالة ، سيتعمق فريق BlockPI في فهمهم لـ AA ويشاركون أفكارهم من منظور مزود خدمة البنية التحتية.
EOA ومحفظة العقد
ينبع مفهوم AA من قيود حسابات EOA. حساب EOA (حساب مملوك خارجيًا) هو حساب مستخدم في Ethereum ، يتم تمثيله بمفتاح عام (عنوان blockchain) ويتم الوصول إليه من خلال مفتاح خاص. إنه مكون رئيسي في النظام البيئي Ethereum ، مما يسمح للمستخدمين بتحويل الأموال على blockchain أو التفاعل مع العقود الذكية. ومع ذلك ، بالنسبة للعديد من الأشخاص ، يمكن أن يكون استخدام EOA مهمة صعبة في حد ذاته. علاوة على ذلك ، لا يزال حساب EOA الحالي به بعض الإزعاج قيد الاستخدام ، مما يؤثر على تجربة المستخدم.
الأول هو قضية رسوم الغاز. ستكلف كل معاملة المستخدم مبلغًا كبيرًا من ETH كرسوم غاز (بأخذ سعر الغاز البالغ 25 Gwei كمثال ، تبلغ رسوم الغاز لتحويل ETH البسيط حوالي 0.5 دولار أمريكي ، وستكون أكثر تكلفة للتفاعل مع العقد أو عندما يكون سعر الغاز أعلى). وهذا يجعل المعاملات الصغيرة مكلفة للغاية ، خاصة خلال فترات الازدحام الشديد في الشبكة. بالإضافة إلى ذلك ، لا يمكن الدفع مقابل الغاز إلا باستخدام ETH ، مما يعني أنه يجب على المستخدمين الاحتفاظ بـ ETH في محافظهم ، مما يشكل عائقًا كبيرًا أمام دخول العديد من المستخدمين.
ثانيًا ، بالنسبة لبعض العمليات المعقدة التي يرغب المستخدمون في تنفيذها ، يجب أن تعتمد EOA على عقود ذكية أخرى. على سبيل المثال ، إذا أراد المستخدم تعيين تحويل دوري محدد بوقت ، يحتاج المستخدم إلى تحويل ETH إلى عقد ذكي مع هذه الوظيفة لتحقيق هذه العملية.
المشكلة الثالثة في EOA هي خوارزمية تشفير التوقيع الثابت. تستخدم شبكة Ethereum خوارزمية توقيع رقمي تسمى secp256k1 لضمان صحة المعاملات وأمانها. يتم ترميز هذه الخوارزمية في النظام ولا يمكن للمستخدمين اختيار استخدام خوارزميات التشفير الأخرى.
بالإضافة إلى المشكلات الثلاث المذكورة أعلاه ، فإن العلاقة الملزمة بين المفتاح العام لـ EOA والمفتاح الخاص تعد أيضًا مشكلة. المفتاح الخاص هو الطريقة الوحيدة للمستخدمين للوصول إلى EOA. إذا فقد المفتاح الخاص ، فلن يتم استعادته. هذا يعني أيضًا أن جميع الأصول داخل EOA المرتبطة بها لن يمكن استرجاعها.
في نفس الوقت ، فإن EOA لها أيضًا قيود عند أداء مهام خطية معينة. على سبيل المثال ، إذا رغب المستخدم في الموافقة على الرموز المميزة وتبديلها وإلغاء الموافقة عليها في عملية واحدة ، فيجب إجراء ثلاث معاملات منفصلة ، وهو أمر غير فعال ويستغرق وقتًا طويلاً.
والخبر السار هو أن محافظ العقود يمكنها حل جميع المشكلات المذكورة أعلاه. تعد محفظة العقد في الأساس نوعًا محددًا من حسابات العقود الذكية التي تنفذ AA ، والتي يمكن استخدامها كمحفظة مستخدم على Ethereum. ويمكن أن يوفر للمستخدمين طريقة أكثر مرونة وتخصيصًا لإدارة الأموال. طالما أنه المنطق الذي يمكن تحقيقه من خلال عقد Ethereum الذكي ، يمكن لمحفظة العقد أن تدرك وتوفر الوظائف المقابلة.
على وجه التحديد ، يمكن تجميع عمليات محفظة العقود المتعددة في معاملة على السلسلة ، ويمكن لهذه العمليات مشاركة تكلفة الغاز لهذه المعاملة. إذا كان الطرف الثالث على استعداد لدفع رسوم الغاز ، فلا داعي لدفع رسوم Gas للمستخدمين الذين يستخدمون محفظة العقد. يمكن لمحافظ العقود أيضًا إكمال مهام خطية متعددة في وقت واحد. بالإضافة إلى ذلك ، تدعم محفظة العقد أيضًا خوارزمية تشفير التوقيعات المخصصة ، وتعيين وظيفة استرداد المحفظة وما إلى ذلك.
مع استمرار مناقشة مزايا محافظ العقود ، أجرى مجتمع Ethereum بالفعل بحثًا طويل الأجل حول محافظ العقود. على الرغم من أن العديد من برامج EIPs قد استكشفت المشكلات المتعلقة بتجريد الحساب ، اعتبارًا من عام 2021 ، لم يتم وضع معيار موحد. يوجد أدناه العديد من برامج EIP التمثيلية.
EIP-86
اقترح في الأصل فيتاليك بوتيرين في عام 2017. ينفذ المخطط سلسلة من التغييرات بهدف مشترك هو "تجريد" التحقق من التوقيع والتحقق من صحة التوقيع ، وبالتالي تمكين المستخدمين من إنشاء "عقود حساب" تؤدي إلى توقيع تعسفي / فحص غير متكرر.
EIP-2938
قدم في 2020. عنوان برنامج EIP هذا هو تجريد الحساب. تم وصف مفهوم AA جيدًا في هذا EIP. يقدم نوعًا جديدًا من المعاملات ، معاملة AA. تبدأ المعاملة من خلال عنوان نقطة الدخول (عنوان نقطة الدخول) وتستدعي محفظة عقد AA. يوفر EIP-2938 مواصفات موحدة ويقدم رسميًا تجريد حساب AA في إجماع Ethereum. على وجه التحديد ، يقدم اثنين من أكواد التشغيل الجديدة ، وثلاثة متغيرات عالمية ، وهيكل حمولة مختلف لتوافق Ethereum.
EIP-3074
قدم في 2020. يقدم برنامج EIP هذا تعليمي EVM ، AUTH و AUTHCALL. يحدد AUTH متغير البيئة وفقًا لسلطة توقيع ECDSA. يرسل AUTHCALL المكالمة باعتباره الحساب المصرح به. هذا يسمح للعقود الذكية بإرسال المعاملات نيابة عن EOA. لكنه لا يزال ليس حلاً مثاليًا لـ AA. في عملية معاملة الترخيص ، يحتوي EIP-3074 على قيود معينة على نقل القيمة الأصلية. وإذا فقد المستخدم الوصول إلى EOA ، فلن تكون هناك طريقة لاسترداد أصوله. في حالة تسريب المفتاح الخاص ، يحتاج المستخدم إلى نقل جميع الأصول إلى الحساب الجديد.
لم يتم دمج أي من المقترحات المذكورة أعلاه رسميًا في بروتوكول Ethereum بسبب الحاجة إلى تغييرات في طبقة الإجماع أو لأن المقترحات لم تكن شاملة بما فيه الكفاية. لذلك ، واصل مجتمع Ethereum استكشاف كيفية إدخال AA في بروتوكول Ethereum دون تغيير الإجماع ، واقترح أخيرًا EIP4337.
ERC - 4337
تم اقتراح EIP-4337 في الأصل في سبتمبر 2021 وتم اعتماده كـ ERC-4337 في مارس 2023. ومن بين مؤلفيها فيتاليك بوتيرين ويواف فايس وكريستوف غازسو ونمرة باتيل ودرور تيروش وشهاف ناكسون وتجادين هيس.
EIP-4337 هو اقتراح معطل يمكنه تقديم AA دون تغيير البروتوكول الأساسي لـ Ethereum. أصبح EIP-4337 في النهاية معيار ERC-4337 ، والذي يمكن للبناة استخدامه لتنفيذ محافظ العقود الذكية الخاصة بهم. في الوقت نفسه ، يقدم المعيار أيضًا بعض البنية التحتية الإضافية بما في ذلك "Bundlers" و "UserOperation mempool". وبهذه الطريقة ، فإنه يكرر فعليًا تجمع ذاكرة إيثيريوم بوظائف مماثلة على الطبقة العليا من نظام بلوكشين. ما يقدمه المستخدم لم يعد معاملة واحدة ، ولكنه عملية مستخدم. يمكن تجميع عمليات المستخدمين المتعددة في معاملة واحدة وإرسالها إلى Ethereum.
فيما يلي شرح تقني مفصل لـ ERC-4337 في Ethereum [الوثائق الرسمية] (جنبًا إلى جنب مع بعض التعليقات المفيدة.
الأدوار والتعريفات الرئيسية لـ ERC-4337
** UserOperation ** - يصف هيكل المعاملة المرسلة نيابة عن المستخدم. لتجنب الالتباس ، لم يتم تسميتها "معاملة" وسيتم إرسالها إلى Bundler ليتم تعبئتها كحزمة مع عمليات مستخدم أخرى. ثم يتم إرسال الحزمة على السلسلة كمعاملة واحدة.
** المرسل ** - حساب العقد الذي يرسل UserOperation. يجب أن يتبع عقد المحفظة معيار ERC-4337 لتكوين واجهة حساب IAccount.
** EntryPoint ** - عقد فردي عالمي ينفذ حزمة UserOperations. الحزم / العملاء القائمة البيضاء المدعومة EntryPoints. يتم تدقيق العقد والموافقة عليه للنشر من قبل فريق Infinitism ، وهو مسؤول عن التعامل مع جميع عمليات المستخدم وربط العقود بأدوار أخرى ، بما في ذلك Wallet Factory و Aggregator و Paymaster. العقد كله في نفس العنوان في سلسلة EVM المتوافقة.
** Bundler ** - العقدة التي تحزم عدة عمليات مستخدم من مجموعة mempool وتقوم بإنشاء معاملة EntryPoint.handleOps () (منتج الكتلة الحالي). يمكن تشغيل خدمة Bundler بشكل مستقل عن عُقد blockchain وإرسال عمليات المستخدم المجمعة عبر RPC.
** المُجمّع ** - عقد إضافي تثق به الحسابات للتحقق من التواقيع المجمّعة. يقوم المجمّعون / العملاء بإدراج مجمّعي التوقيع المدعومين في القائمة البيضاء. يجب أن يتبع العارض معيار ERC-4337 لتكوين واجهة IAggregator.
** Paymaster ** - عقد ذكي يمكنه دفع الغاز نيابة عنك. إذا قام بإيداع ما يكفي من ETH في عقد EntryPoint ، فيمكنه دفع رسوم الغاز لعملية المستخدم الخاصة بالمرسل ، وتنفيذ استخراج الغاز بشكل فعال. يجب أن يتبع مسؤول الدفع معيار ERC-4337 لتكوين واجهة Paymaster. يمكن أن يبرم Paymaster اتفاقية مع المرسل. على سبيل المثال ، يدفع المرسل USDC إلى Paymaster ، ويستخدم Paymaster ETH لدفع غاز عمليات المستخدم التي يرسلها. في الواقع ، يمكن لـ Paymaster اختيار دعم أي رمز مميز ، بما في ذلك الرموز المميزة ERC-20 وحتى الرموز المميزة على السلاسل الأخرى.
** Wallet Factory ** - عقد ذكي يمكنه إنشاء محافظ تعاقدية لمستخدمي ERC-4337. لا يُسمح بنشر Wallet Factory. بصفته عقدًا ذكيًا على السلسلة ، فإن الكود الخاص به مفتوح للجمهور ويمكن لأي شخص مراجعته. يجب أن يخضع مصنع Wallet Factory المستخدم على نطاق واسع للتدقيق الكامل من قبل المتخصصين.
يوضح الرسم البياني أدناه كيفية تفاعل عقد EntryPoint مع الجهات الفاعلة الأخرى.
تستدعي Bundlers وظيفة handleOps لعقد EntryPoint ، والتي تقبل عملية المستخدم كمدخلات.
سوف تتحقق handleOps من UserOperation على السلسلة ، وتتحقق مما إذا كانت موقعة من خلال عنوان محفظة العقد الذكي المحدد ، وتأكيد ما إذا كانت المحفظة بها ما يكفي من الغاز لتعويض Bundler.
إذا تم تمرير التحقق ، فسيقوم handleOps بتنفيذ وظيفة محفظة العقد الذكية وفقًا للوظيفة ومعلمات الإدخال المحددة في بيانات استدعاء UserOperation.
من ناحية أخرى ، عندما يستخدم Bundler EOA لتشغيل وظيفة handleOps ، سيتم فرض رسوم غاز. يمكن لمحفظة العقد الذكية دفع رسوم الغاز إلى Bundlers من رصيد حسابها الخاص ، أو طلب عقد Paymaster لدفع ثمنها. لا يمكن لعمليات UserOperations اجتياز خطوة التحقق خارج السلسلة بدون غاز كافٍ ، أي أنها تفشل قبل تنفيذ المعاملة على السلسلة. حتى إذا كان هناك غاز كافٍ ، فقد تستمر عمليات المستخدم في الفشل لأسباب مثل أخطاء وقت التشغيل أثناء التنفيذ. بالنسبة لعملية المستخدم ، بغض النظر عما إذا كان تنفيذ العقد ناجحًا أم لا ، فإن عقد EntryPoint سيدفع رسوم الغاز إلى Bundler الذي يقوم بتشغيل وظيفة handleOps.
! [كيف تمكّن البنية التحتية مليارات المستخدمين من خلال تجريد الحساب] (https://img-cdn.gateio.im/social/moments-40baef27dd-cabe901f6b-dd1a6f-7649e1)
(مقتطف من الوثائق الرسمية:
بعد دخول ERC-4337 حيز التنفيذ ، يمكن للمستخدمين الآن بدء معاملات blockchain بطريقتين. أحدهما هو الطريقة التقليدية ، أي أن EOA يبدأ المعاملة مباشرة. والآخر هو استخدام معيار ERC-4337 لبدء UserOperation من خلال Bundler ، ثم يقوم Bundler بحزمه مع UserOperations الأخرى وإرساله إلى السلسلة. يوضح الرسم البياني أدناه الفرق بين معاملة إرسال EOA عادية ومحفظة عقد ERC-4337 ترسل UserOperation.
! [كيف تمد البنية التحتية مليارات المستخدمين من خلال تجريد الحساب] (https://img-cdn.gateio.im/social/moments-40baef27dd-2eaed6d2b3-dd1a6f-7649e1)
تم تمهيد الطريق ، لكن لا يوجد الكثير من المشاة حتى الآن
يوفر ERC-4337 إطارًا قويًا للمستخدمين والمطورين لاستخدام وبناء AA على Ethereum. على الرغم من أن هذا الإطار يمثل تقدمًا مهمًا ، إلا أنه لا تزال هناك بعض التحديات والشكوك التي يجب معالجتها وحلها.
لا يزال اعتماد AA في مهده. وفقًا للوحة تحليل Dune ERC-4337 (\ * [ERC-4337 Account Abstraction] (منniftytable) ، تم تنفيذ 65 ألف + فقط من عمليات المستخدم على السلسلة ، 90٪ منها جاءت من Polygon. لذلك ، عدد عمليات المستخدم المنفذة حاليًا لا تزال صغيرة جدًا ، ومعظمها جزء منه اختبار المطور ، وجزء صغير فقط يأتي من مستخدمين حقيقيين. لقد لاحظنا أن المنتجات التي تم دمج AA فيها لا تزال في المرحلة المبكرة. في الوقت الحالي ، يمكننا ملاحظة ذلك لا تزال المجمعات ككل في حالة خسارة ، وتبلغ الخسارة الحالية أكثر من 700 MATICs. ويرجع ذلك أساسًا إلى أن بعض Bundlers on Polygon يخطئ في تقدير الغاز المطلوب ، مما أدى إلى أن الغاز الذي تم إرجاعه بواسطة EntryPoint أقل من الغاز المستهلك من خلال الحزمة المقدمة. يجب حل هذه المشكلة على مستوى عميل Bundler.
علاوة على ذلك ، هناك عدد قليل من القضايا التي تحتاج إلى معالجة. تتمثل إحدى المشكلات في كيفية تعامل Bundlers مع إخفاقات المعاملات.
بعد تجميع عمليات مستخدم متعددة معًا ، سيحاكي Bundlers المعاملة أولاً ، ويكتشفوا ما إذا كان هناك فشل في تنفيذ العقد ، ويحسب ما إذا كانت رسوم الغاز التي أعادها المرسل أو مسؤول الدفع أكبر من رسوم الغاز المدفوعة.
إذا كانت مربحة ، يرسل Bundler هذه الدفعة من UserOperations كمعاملة إلى عقدة الكتلة. ومع ذلك ، لا يزال من الممكن أن تفشل المعاملة ، مما يؤدي إلى قيام Bundler بدفع رسوم الغاز ولكن لا يتلقى استرداد الغاز من EntryPoint. على سبيل المثال ، قد يرسل المستخدم إجراءات إلى حزم مختلفة. إذا كان هناك هامش ربح ونجحت المحاكاة ، فسوف تلتزم Bundlers بالسلسلة. في هذه الحالة ، إذا تم إرسال UserOperation إلى العقدة المنتجة للكتلة من قبل حزم مختلفة في نفس الوقت ، فستنجح معاملة واحدة فقط ، مما يعني أن Bundler واحدًا فقط سيتلقى رسوم الغاز التي يتم إرجاعها بواسطة EntryPoint ، وستفشل جميع الحزم الأخرى بسبب السلاسل وفقدان الغاز. على الرغم من أن المرء قد يجادل بأن هذا السلوك يجب اعتباره هجومًا ضارًا ، ويجادل بأن Bundler يمكنه حظر عنوان المرسل ورفض أي طلبات مستقبلية من هذا العنوان ، إلا أن هذا ليس حلاً معقولاً لأن المستخدمين قد يتخذون هذا الإجراء عن غير قصد. السلوك. يجب معالجة هذه المشكلة بشكل صحيح في الكود ، ربما من خلال مجموعة ذاكرة عامة قيد التطوير. بالإضافة إلى ذلك ، قد يتعرض Bundlers لخسائر بسبب التقلبات المفاجئة في الغاز حتى إذا تم تقديم المعاملة بنجاح وتظهر نتائج المحاكاة أن هناك مجالًا للربح.
هناك مشكلة أخرى وهي القيمة القصوى القابلة للاستخراج (MEV) التي يمكن الحصول عليها من AA. في سياق Ethereum ، يشير MEV عمومًا إلى القيمة التي يستخرجها المعدنون أو معالجات المعاملات الأخرى عن طريق التلاعب بترتيب المعاملات في كتلة أو إدراج معاملاتهم الخاصة في كتلة. قد يلاحظ المرء أن منطق MEV يمكن أيضًا تطبيقه على AA. هذا لأنه في AA ، يمكن لـ Bundlers تسلسل UserOps بحرية ، مما يمنحهم إمكانية الحصول على MEV. ومع ذلك ، يعتمد ما إذا كان بإمكان Bundler استخراج MEV على ما إذا كان يمكن تجميع عدد كافٍ من عمليات المستخدم معًا. الآن لا يزال سوق AA بأكمله في مهده ، لذلك يمكن أيضًا اعتبار Bundler MEV في مهده. يمكن ملاحظة أن MEV الخاص بـ AA قد يتطور في اتجاهين: أحدهما مشابه لشبكة Ethereum mainnet ، بمشاركة مشاركين مثل Flashbots و Ultra Sound و BloXroute ؛ الاتجاه الآخر هو تشكيل إجماع Bundler لتنفيذ الفرز العادل. وهذا الأخير سيقضي تمامًا على إمكانية استخراج MEV في AA.
تطويرات مستقبلية
mempool العامة
بينما يعمل النظام البيئي AA بالفعل ، لا يزال هناك الكثير من أعمال التطوير التي يتعين القيام بها. بالنظر إلى النظام البيئي AA بأكمله ، فإن أكبر قطعة مفقودة الآن هي مجموعة الذاكرة العامة. يقوم فريق Etherspot ، مطورو عميل Skandha Bundler ، حاليًا بتطوير شبكة p2p مع مجموعة mempool العامة. من المتوقع إطلاق شبكة p2p من mempools العامة في أغسطس من هذا العام.
خوارزمية الحزمة
على طول الطريق ، مولت مؤسسة Ethereum العديد من فرق تطوير AA المتميزة. حتى الآن ، تم تطوير العديد من عملاء Bundler وهم متاحون حاليًا. من بينهم ، بعضها ناضج جدًا. هم Candide (Voltaire Bundler مكتوب بلغة Python) ، Pimlico (Alto Bundler مكتوب بالنوع) ، Etherspot (Skandha Bundler مكتوب بالنوع) ، Stackup (Stackup-Bundler مكتوب بلغة Go) ، إلخ.
هنا تأتي مسألة استراتيجية التعبئة والتغليف. حاليًا ، نظرًا لقلة عدد عمليات المستخدم ، يمكن أن تعتمد الحزم منطق تجميع بسيط ، مثل فترة زمنية ثابتة أو عدد معين من عمليات المستخدم في كل حزمة. ومع ذلك ، مع زيادة عدد عمليات المستخدم ، خاصة بعد تقديم مجموعة الذاكرة العامة ، تصبح استراتيجية اختيار عمليات المستخدم وتعبئتها أكثر تعقيدًا. السبب بسيط: في بيئة AA ، لا توجد آلية مشابهة لبروتوكول إجماع blockchain ، وأصبحت مجموعة Bundler عبارة عن غابة مظلمة ، حيث يقوم كل Bundler بتحديد أولويات المهام وفقًا لمصالحه الخاصة ويتنافس مع بعضها البعض. على عكس mempools العامة ، قد تظهر mempools الخاصة في وقت سابق. لأنه عندما لا يكون حزم UserOperations من مجموعة mempool العامة مربحًا ، فلا يزال من الممكن تجميع UserOperations في مجموعة mempool الخاصة. في هذه الحالة ، يكون Bundler أكثر قدرة على المنافسة من Bundler الأخرى عند التعبئة والتغليف.
بالإضافة إلى ذلك ، مع التعميم التدريجي لمجموعة mempool العامة ، فإن عمليات المستخدم فيها لها خصائص مختلفة ، مثل توقعات أرباح الغاز المختلفة وتعقيد التنفيذ على السلسلة. سيجري Bundlers عمليات المحاكاة خارج السلسلة لتقييم ربحية مجموعات مختلفة من UserOperations لتأسيس استراتيجيات التجميع الخاصة بهم. تعبئة المزيد من عمليات المستخدم لديه القدرة على تحقيق أرباح أعلى ، ولكنه يزيد أيضًا من مخاطر فشل التحقق من الصحة. حتى إذا تم اجتياز التحقق ، فإن خطر فشل التنفيذ على السلسلة لا يزال قائماً. في المقابل ، تقوم عمليات المستخدم الأقل حزمًا بالعكس. يحتاج المتعاملون إلى تعيين معاملات الغاز الخاصة بهم ، والتي ستؤثر على أولوية منتجي الكتل لتنفيذ هذه المعاملة. في ظل مختلف أسعار الغاز المقدرة وظروف تقلب الغاز ، قد يكون لدى Bundlers استراتيجيات تعبئة مختلفة. في الوقت نفسه ، من الضروري أيضًا مراعاة تكلفة موارد حوسبة الأجهزة المحلية وموارد عقدة blockchain من أجل حسابات التحقق والسياسة هذه. بالإضافة إلى ذلك ، يحتاج Bundlers أيضًا إلى العمل الجاد لتزويد المستخدمين بتجربة مستخدم جيدة والتأكد من أن المستخدمين لا يواجهون تأخيرات مفرطة بعد إرسال عمليات المستخدم.
على الرغم من أن الحلول لهذه التحديات لا تزال غير واضحة ، يمكننا القول بثقة أن تطوير صناعة AA والجهود المشتركة للمطورين ستحل هذه المشكلات في النهاية. بصفتها منشئ البنية التحتية ، تأمل BlockPI في أن تلعب دورًا في حل المشكلات في تطوير صناعة AA ، سواء كمطور أو لتوفير بنية تحتية متوافقة مع AA للمطورين الآخرين.
يجب أن تتكيف البنية التحتية مع AA
يلخص AA الأدوار المختلفة التي تنطوي عليها المعاملات على السلسلة ، بما في ذلك Sender و Bundlers و Gas payers ومحافظ العقود والموقِّعون ، بحيث يتمتع المستخدمون بدرجة أعلى من الحرية عند استخدام blockchain. في الوقت نفسه ، يمكن لمزودي البنية التحتية نشر هذه الخدمات بشكل مستقل وفقًا لتقديراتهم الخاصة في السوق.
من أجل التكيف مع اعتماد AA على نطاق واسع ، يحتاج مقدمو البنية التحتية أولاً إلى تقديم خدمتين أساسيتين على الأقل: خدمة Bundler وخدمة Paymaster.
في خدمات Bundler ، قد يحتاج مقدمو البنية التحتية إلى تطوير مجموعات memo خاصة مع Bundlers لتوفير تجربة مستخدم جيدة. على وجه التحديد ، يحتاج مقدمو البنية التحتية إلى دمج العديد من عملاء Bundler لضمان استقرار خدمات Bundler. يقوم عملاء Bundler حاليًا بتزويد المستخدمين بالعديد من طرق JSON RPC القياسية المقدمة من مجموعة التطوير الأساسية ERC-4337. من المتوقع أن تتوفر المزيد من أساليب RPC للمستخدمين في المستقبل. يحتاج مقدمو خدمات البنية التحتية إلى تحديث الدعم لهذه الأساليب في الوقت المناسب أثناء هذه العملية.
أيضًا ، من المهم جدًا التحسين بين Bundler API وعميل العقدة الأصلية RPC. لم يتم تحسين عملاء العقدة الحاليين لـ AA. تتطلب بعض طرق Bundler API أن توفر العقدة فهرس بيانات لـ AA. على سبيل المثال ، عندما يبحث العميل الحالي عن UserOperation عن طريق التجزئة ، فإنه يحتاج إلى مسح سجلات عقد EntryPoint في جميع الكتل. إذا لم يكن هناك فهرس بيانات ، فسيكون استهلاك موارد الأجهزة لهذا الطلب الفردي ضخمًا جدًا ، وسيصبح وقت إرجاع الطلب أيضًا طويلاً جدًا.
بالإضافة إلى ذلك ، من أجل تزويد المستخدمين بتجربة مستخدم خالية من الغاز وخدمات متنوعة ، يحتاج موفرو البنية التحتية إلى التعاون مع مختلف مزودي خدمة Paymaster لدمج خدمات Paymaster المختلفة. في الوقت نفسه ، وفقًا لطلب السوق ، يمكن لمزودي البنية التحتية أيضًا تصميم حلول متكاملة أكثر ملاءمة بناءً على خدمات Paymaster الحالية. تعتبر الخدمات الأخرى ، مثل التوقيعات المجمعة ومصانع المحفظة وما إلى ذلك ، أيضًا اتجاهات محتملة للتطوير المستقبلي وتكامل البنية التحتية.
باختصار ، من أجل التكيف مع التطبيق واسع النطاق لـ AA ، يحتاج مقدمو البنية التحتية إلى تحسين وتوسيع خدماتهم باستمرار. يتضمن ذلك تحسين خدمات Bundler ، والتعاون مع مزودي خدمة Paymaster المختلفين ، ودمج واجهات API المختلفة ، وتطوير خدمات محتملة أخرى. مع استمرار تطور صناعة AA ، ستساعد هذه الجهود في توفير تجربة blockchain أكثر كفاءة وأمانًا وملاءمة.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
كيف تعمل البنية التحتية على تمكين مليارات المستخدمين من خلال تجريد الحساب
سواء كان سوقًا صاعدًا أو سوقًا هابطة ، فإن النظام البيئي Ethereum يبني باستمرار ويحسن نفسه. من بينها ، حقق Account Abstraction (AA) تقدمًا مهمًا في السنوات الأخيرة وتغلغل في جميع أجزاء النظام البيئي Ethereum ، بما في ذلك التطبيقات والبنية التحتية والمستخدمين والمطورين. يمكننا أن نتوقع أن اعتماد AA على نطاق واسع سيقلل من عتبة استخدام blockchain ككل ويقدم تجربة مستخدم web2 في صناعة web3.
في هذه المقالة ، سيتعمق فريق BlockPI في فهمهم لـ AA ويشاركون أفكارهم من منظور مزود خدمة البنية التحتية.
EOA ومحفظة العقد
ينبع مفهوم AA من قيود حسابات EOA. حساب EOA (حساب مملوك خارجيًا) هو حساب مستخدم في Ethereum ، يتم تمثيله بمفتاح عام (عنوان blockchain) ويتم الوصول إليه من خلال مفتاح خاص. إنه مكون رئيسي في النظام البيئي Ethereum ، مما يسمح للمستخدمين بتحويل الأموال على blockchain أو التفاعل مع العقود الذكية. ومع ذلك ، بالنسبة للعديد من الأشخاص ، يمكن أن يكون استخدام EOA مهمة صعبة في حد ذاته. علاوة على ذلك ، لا يزال حساب EOA الحالي به بعض الإزعاج قيد الاستخدام ، مما يؤثر على تجربة المستخدم.
الأول هو قضية رسوم الغاز. ستكلف كل معاملة المستخدم مبلغًا كبيرًا من ETH كرسوم غاز (بأخذ سعر الغاز البالغ 25 Gwei كمثال ، تبلغ رسوم الغاز لتحويل ETH البسيط حوالي 0.5 دولار أمريكي ، وستكون أكثر تكلفة للتفاعل مع العقد أو عندما يكون سعر الغاز أعلى). وهذا يجعل المعاملات الصغيرة مكلفة للغاية ، خاصة خلال فترات الازدحام الشديد في الشبكة. بالإضافة إلى ذلك ، لا يمكن الدفع مقابل الغاز إلا باستخدام ETH ، مما يعني أنه يجب على المستخدمين الاحتفاظ بـ ETH في محافظهم ، مما يشكل عائقًا كبيرًا أمام دخول العديد من المستخدمين.
ثانيًا ، بالنسبة لبعض العمليات المعقدة التي يرغب المستخدمون في تنفيذها ، يجب أن تعتمد EOA على عقود ذكية أخرى. على سبيل المثال ، إذا أراد المستخدم تعيين تحويل دوري محدد بوقت ، يحتاج المستخدم إلى تحويل ETH إلى عقد ذكي مع هذه الوظيفة لتحقيق هذه العملية.
المشكلة الثالثة في EOA هي خوارزمية تشفير التوقيع الثابت. تستخدم شبكة Ethereum خوارزمية توقيع رقمي تسمى secp256k1 لضمان صحة المعاملات وأمانها. يتم ترميز هذه الخوارزمية في النظام ولا يمكن للمستخدمين اختيار استخدام خوارزميات التشفير الأخرى.
بالإضافة إلى المشكلات الثلاث المذكورة أعلاه ، فإن العلاقة الملزمة بين المفتاح العام لـ EOA والمفتاح الخاص تعد أيضًا مشكلة. المفتاح الخاص هو الطريقة الوحيدة للمستخدمين للوصول إلى EOA. إذا فقد المفتاح الخاص ، فلن يتم استعادته. هذا يعني أيضًا أن جميع الأصول داخل EOA المرتبطة بها لن يمكن استرجاعها.
في نفس الوقت ، فإن EOA لها أيضًا قيود عند أداء مهام خطية معينة. على سبيل المثال ، إذا رغب المستخدم في الموافقة على الرموز المميزة وتبديلها وإلغاء الموافقة عليها في عملية واحدة ، فيجب إجراء ثلاث معاملات منفصلة ، وهو أمر غير فعال ويستغرق وقتًا طويلاً.
والخبر السار هو أن محافظ العقود يمكنها حل جميع المشكلات المذكورة أعلاه. تعد محفظة العقد في الأساس نوعًا محددًا من حسابات العقود الذكية التي تنفذ AA ، والتي يمكن استخدامها كمحفظة مستخدم على Ethereum. ويمكن أن يوفر للمستخدمين طريقة أكثر مرونة وتخصيصًا لإدارة الأموال. طالما أنه المنطق الذي يمكن تحقيقه من خلال عقد Ethereum الذكي ، يمكن لمحفظة العقد أن تدرك وتوفر الوظائف المقابلة.
على وجه التحديد ، يمكن تجميع عمليات محفظة العقود المتعددة في معاملة على السلسلة ، ويمكن لهذه العمليات مشاركة تكلفة الغاز لهذه المعاملة. إذا كان الطرف الثالث على استعداد لدفع رسوم الغاز ، فلا داعي لدفع رسوم Gas للمستخدمين الذين يستخدمون محفظة العقد. يمكن لمحافظ العقود أيضًا إكمال مهام خطية متعددة في وقت واحد. بالإضافة إلى ذلك ، تدعم محفظة العقد أيضًا خوارزمية تشفير التوقيعات المخصصة ، وتعيين وظيفة استرداد المحفظة وما إلى ذلك.
مع استمرار مناقشة مزايا محافظ العقود ، أجرى مجتمع Ethereum بالفعل بحثًا طويل الأجل حول محافظ العقود. على الرغم من أن العديد من برامج EIPs قد استكشفت المشكلات المتعلقة بتجريد الحساب ، اعتبارًا من عام 2021 ، لم يتم وضع معيار موحد. يوجد أدناه العديد من برامج EIP التمثيلية.
EIP-86
اقترح في الأصل فيتاليك بوتيرين في عام 2017. ينفذ المخطط سلسلة من التغييرات بهدف مشترك هو "تجريد" التحقق من التوقيع والتحقق من صحة التوقيع ، وبالتالي تمكين المستخدمين من إنشاء "عقود حساب" تؤدي إلى توقيع تعسفي / فحص غير متكرر.
EIP-2938
قدم في 2020. عنوان برنامج EIP هذا هو تجريد الحساب. تم وصف مفهوم AA جيدًا في هذا EIP. يقدم نوعًا جديدًا من المعاملات ، معاملة AA. تبدأ المعاملة من خلال عنوان نقطة الدخول (عنوان نقطة الدخول) وتستدعي محفظة عقد AA. يوفر EIP-2938 مواصفات موحدة ويقدم رسميًا تجريد حساب AA في إجماع Ethereum. على وجه التحديد ، يقدم اثنين من أكواد التشغيل الجديدة ، وثلاثة متغيرات عالمية ، وهيكل حمولة مختلف لتوافق Ethereum.
EIP-3074
قدم في 2020. يقدم برنامج EIP هذا تعليمي EVM ، AUTH و AUTHCALL. يحدد AUTH متغير البيئة وفقًا لسلطة توقيع ECDSA. يرسل AUTHCALL المكالمة باعتباره الحساب المصرح به. هذا يسمح للعقود الذكية بإرسال المعاملات نيابة عن EOA. لكنه لا يزال ليس حلاً مثاليًا لـ AA. في عملية معاملة الترخيص ، يحتوي EIP-3074 على قيود معينة على نقل القيمة الأصلية. وإذا فقد المستخدم الوصول إلى EOA ، فلن تكون هناك طريقة لاسترداد أصوله. في حالة تسريب المفتاح الخاص ، يحتاج المستخدم إلى نقل جميع الأصول إلى الحساب الجديد.
لم يتم دمج أي من المقترحات المذكورة أعلاه رسميًا في بروتوكول Ethereum بسبب الحاجة إلى تغييرات في طبقة الإجماع أو لأن المقترحات لم تكن شاملة بما فيه الكفاية. لذلك ، واصل مجتمع Ethereum استكشاف كيفية إدخال AA في بروتوكول Ethereum دون تغيير الإجماع ، واقترح أخيرًا EIP4337.
ERC - 4337
تم اقتراح EIP-4337 في الأصل في سبتمبر 2021 وتم اعتماده كـ ERC-4337 في مارس 2023. ومن بين مؤلفيها فيتاليك بوتيرين ويواف فايس وكريستوف غازسو ونمرة باتيل ودرور تيروش وشهاف ناكسون وتجادين هيس.
EIP-4337 هو اقتراح معطل يمكنه تقديم AA دون تغيير البروتوكول الأساسي لـ Ethereum. أصبح EIP-4337 في النهاية معيار ERC-4337 ، والذي يمكن للبناة استخدامه لتنفيذ محافظ العقود الذكية الخاصة بهم. في الوقت نفسه ، يقدم المعيار أيضًا بعض البنية التحتية الإضافية بما في ذلك "Bundlers" و "UserOperation mempool". وبهذه الطريقة ، فإنه يكرر فعليًا تجمع ذاكرة إيثيريوم بوظائف مماثلة على الطبقة العليا من نظام بلوكشين. ما يقدمه المستخدم لم يعد معاملة واحدة ، ولكنه عملية مستخدم. يمكن تجميع عمليات المستخدمين المتعددة في معاملة واحدة وإرسالها إلى Ethereum.
فيما يلي شرح تقني مفصل لـ ERC-4337 في Ethereum [الوثائق الرسمية] (جنبًا إلى جنب مع بعض التعليقات المفيدة.
الأدوار والتعريفات الرئيسية لـ ERC-4337
** UserOperation ** - يصف هيكل المعاملة المرسلة نيابة عن المستخدم. لتجنب الالتباس ، لم يتم تسميتها "معاملة" وسيتم إرسالها إلى Bundler ليتم تعبئتها كحزمة مع عمليات مستخدم أخرى. ثم يتم إرسال الحزمة على السلسلة كمعاملة واحدة.
** المرسل ** - حساب العقد الذي يرسل UserOperation. يجب أن يتبع عقد المحفظة معيار ERC-4337 لتكوين واجهة حساب IAccount.
** EntryPoint ** - عقد فردي عالمي ينفذ حزمة UserOperations. الحزم / العملاء القائمة البيضاء المدعومة EntryPoints. يتم تدقيق العقد والموافقة عليه للنشر من قبل فريق Infinitism ، وهو مسؤول عن التعامل مع جميع عمليات المستخدم وربط العقود بأدوار أخرى ، بما في ذلك Wallet Factory و Aggregator و Paymaster. العقد كله في نفس العنوان في سلسلة EVM المتوافقة.
** Bundler ** - العقدة التي تحزم عدة عمليات مستخدم من مجموعة mempool وتقوم بإنشاء معاملة EntryPoint.handleOps () (منتج الكتلة الحالي). يمكن تشغيل خدمة Bundler بشكل مستقل عن عُقد blockchain وإرسال عمليات المستخدم المجمعة عبر RPC.
** المُجمّع ** - عقد إضافي تثق به الحسابات للتحقق من التواقيع المجمّعة. يقوم المجمّعون / العملاء بإدراج مجمّعي التوقيع المدعومين في القائمة البيضاء. يجب أن يتبع العارض معيار ERC-4337 لتكوين واجهة IAggregator.
** Paymaster ** - عقد ذكي يمكنه دفع الغاز نيابة عنك. إذا قام بإيداع ما يكفي من ETH في عقد EntryPoint ، فيمكنه دفع رسوم الغاز لعملية المستخدم الخاصة بالمرسل ، وتنفيذ استخراج الغاز بشكل فعال. يجب أن يتبع مسؤول الدفع معيار ERC-4337 لتكوين واجهة Paymaster. يمكن أن يبرم Paymaster اتفاقية مع المرسل. على سبيل المثال ، يدفع المرسل USDC إلى Paymaster ، ويستخدم Paymaster ETH لدفع غاز عمليات المستخدم التي يرسلها. في الواقع ، يمكن لـ Paymaster اختيار دعم أي رمز مميز ، بما في ذلك الرموز المميزة ERC-20 وحتى الرموز المميزة على السلاسل الأخرى.
** Wallet Factory ** - عقد ذكي يمكنه إنشاء محافظ تعاقدية لمستخدمي ERC-4337. لا يُسمح بنشر Wallet Factory. بصفته عقدًا ذكيًا على السلسلة ، فإن الكود الخاص به مفتوح للجمهور ويمكن لأي شخص مراجعته. يجب أن يخضع مصنع Wallet Factory المستخدم على نطاق واسع للتدقيق الكامل من قبل المتخصصين.
يوضح الرسم البياني أدناه كيفية تفاعل عقد EntryPoint مع الجهات الفاعلة الأخرى.
تستدعي Bundlers وظيفة handleOps لعقد EntryPoint ، والتي تقبل عملية المستخدم كمدخلات.
سوف تتحقق handleOps من UserOperation على السلسلة ، وتتحقق مما إذا كانت موقعة من خلال عنوان محفظة العقد الذكي المحدد ، وتأكيد ما إذا كانت المحفظة بها ما يكفي من الغاز لتعويض Bundler.
إذا تم تمرير التحقق ، فسيقوم handleOps بتنفيذ وظيفة محفظة العقد الذكية وفقًا للوظيفة ومعلمات الإدخال المحددة في بيانات استدعاء UserOperation.
من ناحية أخرى ، عندما يستخدم Bundler EOA لتشغيل وظيفة handleOps ، سيتم فرض رسوم غاز. يمكن لمحفظة العقد الذكية دفع رسوم الغاز إلى Bundlers من رصيد حسابها الخاص ، أو طلب عقد Paymaster لدفع ثمنها. لا يمكن لعمليات UserOperations اجتياز خطوة التحقق خارج السلسلة بدون غاز كافٍ ، أي أنها تفشل قبل تنفيذ المعاملة على السلسلة. حتى إذا كان هناك غاز كافٍ ، فقد تستمر عمليات المستخدم في الفشل لأسباب مثل أخطاء وقت التشغيل أثناء التنفيذ. بالنسبة لعملية المستخدم ، بغض النظر عما إذا كان تنفيذ العقد ناجحًا أم لا ، فإن عقد EntryPoint سيدفع رسوم الغاز إلى Bundler الذي يقوم بتشغيل وظيفة handleOps.
! [كيف تمكّن البنية التحتية مليارات المستخدمين من خلال تجريد الحساب] (https://img-cdn.gateio.im/social/moments-40baef27dd-cabe901f6b-dd1a6f-7649e1)
(مقتطف من الوثائق الرسمية:
بعد دخول ERC-4337 حيز التنفيذ ، يمكن للمستخدمين الآن بدء معاملات blockchain بطريقتين. أحدهما هو الطريقة التقليدية ، أي أن EOA يبدأ المعاملة مباشرة. والآخر هو استخدام معيار ERC-4337 لبدء UserOperation من خلال Bundler ، ثم يقوم Bundler بحزمه مع UserOperations الأخرى وإرساله إلى السلسلة. يوضح الرسم البياني أدناه الفرق بين معاملة إرسال EOA عادية ومحفظة عقد ERC-4337 ترسل UserOperation.
! [كيف تمد البنية التحتية مليارات المستخدمين من خلال تجريد الحساب] (https://img-cdn.gateio.im/social/moments-40baef27dd-2eaed6d2b3-dd1a6f-7649e1)
تم تمهيد الطريق ، لكن لا يوجد الكثير من المشاة حتى الآن
يوفر ERC-4337 إطارًا قويًا للمستخدمين والمطورين لاستخدام وبناء AA على Ethereum. على الرغم من أن هذا الإطار يمثل تقدمًا مهمًا ، إلا أنه لا تزال هناك بعض التحديات والشكوك التي يجب معالجتها وحلها.
لا يزال اعتماد AA في مهده. وفقًا للوحة تحليل Dune ERC-4337 (\ * [ERC-4337 Account Abstraction] (منniftytable) ، تم تنفيذ 65 ألف + فقط من عمليات المستخدم على السلسلة ، 90٪ منها جاءت من Polygon. لذلك ، عدد عمليات المستخدم المنفذة حاليًا لا تزال صغيرة جدًا ، ومعظمها جزء منه اختبار المطور ، وجزء صغير فقط يأتي من مستخدمين حقيقيين. لقد لاحظنا أن المنتجات التي تم دمج AA فيها لا تزال في المرحلة المبكرة. في الوقت الحالي ، يمكننا ملاحظة ذلك لا تزال المجمعات ككل في حالة خسارة ، وتبلغ الخسارة الحالية أكثر من 700 MATICs. ويرجع ذلك أساسًا إلى أن بعض Bundlers on Polygon يخطئ في تقدير الغاز المطلوب ، مما أدى إلى أن الغاز الذي تم إرجاعه بواسطة EntryPoint أقل من الغاز المستهلك من خلال الحزمة المقدمة. يجب حل هذه المشكلة على مستوى عميل Bundler.
علاوة على ذلك ، هناك عدد قليل من القضايا التي تحتاج إلى معالجة. تتمثل إحدى المشكلات في كيفية تعامل Bundlers مع إخفاقات المعاملات.
بعد تجميع عمليات مستخدم متعددة معًا ، سيحاكي Bundlers المعاملة أولاً ، ويكتشفوا ما إذا كان هناك فشل في تنفيذ العقد ، ويحسب ما إذا كانت رسوم الغاز التي أعادها المرسل أو مسؤول الدفع أكبر من رسوم الغاز المدفوعة.
إذا كانت مربحة ، يرسل Bundler هذه الدفعة من UserOperations كمعاملة إلى عقدة الكتلة. ومع ذلك ، لا يزال من الممكن أن تفشل المعاملة ، مما يؤدي إلى قيام Bundler بدفع رسوم الغاز ولكن لا يتلقى استرداد الغاز من EntryPoint. على سبيل المثال ، قد يرسل المستخدم إجراءات إلى حزم مختلفة. إذا كان هناك هامش ربح ونجحت المحاكاة ، فسوف تلتزم Bundlers بالسلسلة. في هذه الحالة ، إذا تم إرسال UserOperation إلى العقدة المنتجة للكتلة من قبل حزم مختلفة في نفس الوقت ، فستنجح معاملة واحدة فقط ، مما يعني أن Bundler واحدًا فقط سيتلقى رسوم الغاز التي يتم إرجاعها بواسطة EntryPoint ، وستفشل جميع الحزم الأخرى بسبب السلاسل وفقدان الغاز. على الرغم من أن المرء قد يجادل بأن هذا السلوك يجب اعتباره هجومًا ضارًا ، ويجادل بأن Bundler يمكنه حظر عنوان المرسل ورفض أي طلبات مستقبلية من هذا العنوان ، إلا أن هذا ليس حلاً معقولاً لأن المستخدمين قد يتخذون هذا الإجراء عن غير قصد. السلوك. يجب معالجة هذه المشكلة بشكل صحيح في الكود ، ربما من خلال مجموعة ذاكرة عامة قيد التطوير. بالإضافة إلى ذلك ، قد يتعرض Bundlers لخسائر بسبب التقلبات المفاجئة في الغاز حتى إذا تم تقديم المعاملة بنجاح وتظهر نتائج المحاكاة أن هناك مجالًا للربح.
هناك مشكلة أخرى وهي القيمة القصوى القابلة للاستخراج (MEV) التي يمكن الحصول عليها من AA. في سياق Ethereum ، يشير MEV عمومًا إلى القيمة التي يستخرجها المعدنون أو معالجات المعاملات الأخرى عن طريق التلاعب بترتيب المعاملات في كتلة أو إدراج معاملاتهم الخاصة في كتلة. قد يلاحظ المرء أن منطق MEV يمكن أيضًا تطبيقه على AA. هذا لأنه في AA ، يمكن لـ Bundlers تسلسل UserOps بحرية ، مما يمنحهم إمكانية الحصول على MEV. ومع ذلك ، يعتمد ما إذا كان بإمكان Bundler استخراج MEV على ما إذا كان يمكن تجميع عدد كافٍ من عمليات المستخدم معًا. الآن لا يزال سوق AA بأكمله في مهده ، لذلك يمكن أيضًا اعتبار Bundler MEV في مهده. يمكن ملاحظة أن MEV الخاص بـ AA قد يتطور في اتجاهين: أحدهما مشابه لشبكة Ethereum mainnet ، بمشاركة مشاركين مثل Flashbots و Ultra Sound و BloXroute ؛ الاتجاه الآخر هو تشكيل إجماع Bundler لتنفيذ الفرز العادل. وهذا الأخير سيقضي تمامًا على إمكانية استخراج MEV في AA.
تطويرات مستقبلية
mempool العامة
بينما يعمل النظام البيئي AA بالفعل ، لا يزال هناك الكثير من أعمال التطوير التي يتعين القيام بها. بالنظر إلى النظام البيئي AA بأكمله ، فإن أكبر قطعة مفقودة الآن هي مجموعة الذاكرة العامة. يقوم فريق Etherspot ، مطورو عميل Skandha Bundler ، حاليًا بتطوير شبكة p2p مع مجموعة mempool العامة. من المتوقع إطلاق شبكة p2p من mempools العامة في أغسطس من هذا العام.
خوارزمية الحزمة
على طول الطريق ، مولت مؤسسة Ethereum العديد من فرق تطوير AA المتميزة. حتى الآن ، تم تطوير العديد من عملاء Bundler وهم متاحون حاليًا. من بينهم ، بعضها ناضج جدًا. هم Candide (Voltaire Bundler مكتوب بلغة Python) ، Pimlico (Alto Bundler مكتوب بالنوع) ، Etherspot (Skandha Bundler مكتوب بالنوع) ، Stackup (Stackup-Bundler مكتوب بلغة Go) ، إلخ.
هنا تأتي مسألة استراتيجية التعبئة والتغليف. حاليًا ، نظرًا لقلة عدد عمليات المستخدم ، يمكن أن تعتمد الحزم منطق تجميع بسيط ، مثل فترة زمنية ثابتة أو عدد معين من عمليات المستخدم في كل حزمة. ومع ذلك ، مع زيادة عدد عمليات المستخدم ، خاصة بعد تقديم مجموعة الذاكرة العامة ، تصبح استراتيجية اختيار عمليات المستخدم وتعبئتها أكثر تعقيدًا. السبب بسيط: في بيئة AA ، لا توجد آلية مشابهة لبروتوكول إجماع blockchain ، وأصبحت مجموعة Bundler عبارة عن غابة مظلمة ، حيث يقوم كل Bundler بتحديد أولويات المهام وفقًا لمصالحه الخاصة ويتنافس مع بعضها البعض. على عكس mempools العامة ، قد تظهر mempools الخاصة في وقت سابق. لأنه عندما لا يكون حزم UserOperations من مجموعة mempool العامة مربحًا ، فلا يزال من الممكن تجميع UserOperations في مجموعة mempool الخاصة. في هذه الحالة ، يكون Bundler أكثر قدرة على المنافسة من Bundler الأخرى عند التعبئة والتغليف.
بالإضافة إلى ذلك ، مع التعميم التدريجي لمجموعة mempool العامة ، فإن عمليات المستخدم فيها لها خصائص مختلفة ، مثل توقعات أرباح الغاز المختلفة وتعقيد التنفيذ على السلسلة. سيجري Bundlers عمليات المحاكاة خارج السلسلة لتقييم ربحية مجموعات مختلفة من UserOperations لتأسيس استراتيجيات التجميع الخاصة بهم. تعبئة المزيد من عمليات المستخدم لديه القدرة على تحقيق أرباح أعلى ، ولكنه يزيد أيضًا من مخاطر فشل التحقق من الصحة. حتى إذا تم اجتياز التحقق ، فإن خطر فشل التنفيذ على السلسلة لا يزال قائماً. في المقابل ، تقوم عمليات المستخدم الأقل حزمًا بالعكس. يحتاج المتعاملون إلى تعيين معاملات الغاز الخاصة بهم ، والتي ستؤثر على أولوية منتجي الكتل لتنفيذ هذه المعاملة. في ظل مختلف أسعار الغاز المقدرة وظروف تقلب الغاز ، قد يكون لدى Bundlers استراتيجيات تعبئة مختلفة. في الوقت نفسه ، من الضروري أيضًا مراعاة تكلفة موارد حوسبة الأجهزة المحلية وموارد عقدة blockchain من أجل حسابات التحقق والسياسة هذه. بالإضافة إلى ذلك ، يحتاج Bundlers أيضًا إلى العمل الجاد لتزويد المستخدمين بتجربة مستخدم جيدة والتأكد من أن المستخدمين لا يواجهون تأخيرات مفرطة بعد إرسال عمليات المستخدم.
على الرغم من أن الحلول لهذه التحديات لا تزال غير واضحة ، يمكننا القول بثقة أن تطوير صناعة AA والجهود المشتركة للمطورين ستحل هذه المشكلات في النهاية. بصفتها منشئ البنية التحتية ، تأمل BlockPI في أن تلعب دورًا في حل المشكلات في تطوير صناعة AA ، سواء كمطور أو لتوفير بنية تحتية متوافقة مع AA للمطورين الآخرين.
يجب أن تتكيف البنية التحتية مع AA
يلخص AA الأدوار المختلفة التي تنطوي عليها المعاملات على السلسلة ، بما في ذلك Sender و Bundlers و Gas payers ومحافظ العقود والموقِّعون ، بحيث يتمتع المستخدمون بدرجة أعلى من الحرية عند استخدام blockchain. في الوقت نفسه ، يمكن لمزودي البنية التحتية نشر هذه الخدمات بشكل مستقل وفقًا لتقديراتهم الخاصة في السوق.
من أجل التكيف مع اعتماد AA على نطاق واسع ، يحتاج مقدمو البنية التحتية أولاً إلى تقديم خدمتين أساسيتين على الأقل: خدمة Bundler وخدمة Paymaster.
في خدمات Bundler ، قد يحتاج مقدمو البنية التحتية إلى تطوير مجموعات memo خاصة مع Bundlers لتوفير تجربة مستخدم جيدة. على وجه التحديد ، يحتاج مقدمو البنية التحتية إلى دمج العديد من عملاء Bundler لضمان استقرار خدمات Bundler. يقوم عملاء Bundler حاليًا بتزويد المستخدمين بالعديد من طرق JSON RPC القياسية المقدمة من مجموعة التطوير الأساسية ERC-4337. من المتوقع أن تتوفر المزيد من أساليب RPC للمستخدمين في المستقبل. يحتاج مقدمو خدمات البنية التحتية إلى تحديث الدعم لهذه الأساليب في الوقت المناسب أثناء هذه العملية.
أيضًا ، من المهم جدًا التحسين بين Bundler API وعميل العقدة الأصلية RPC. لم يتم تحسين عملاء العقدة الحاليين لـ AA. تتطلب بعض طرق Bundler API أن توفر العقدة فهرس بيانات لـ AA. على سبيل المثال ، عندما يبحث العميل الحالي عن UserOperation عن طريق التجزئة ، فإنه يحتاج إلى مسح سجلات عقد EntryPoint في جميع الكتل. إذا لم يكن هناك فهرس بيانات ، فسيكون استهلاك موارد الأجهزة لهذا الطلب الفردي ضخمًا جدًا ، وسيصبح وقت إرجاع الطلب أيضًا طويلاً جدًا.
بالإضافة إلى ذلك ، من أجل تزويد المستخدمين بتجربة مستخدم خالية من الغاز وخدمات متنوعة ، يحتاج موفرو البنية التحتية إلى التعاون مع مختلف مزودي خدمة Paymaster لدمج خدمات Paymaster المختلفة. في الوقت نفسه ، وفقًا لطلب السوق ، يمكن لمزودي البنية التحتية أيضًا تصميم حلول متكاملة أكثر ملاءمة بناءً على خدمات Paymaster الحالية. تعتبر الخدمات الأخرى ، مثل التوقيعات المجمعة ومصانع المحفظة وما إلى ذلك ، أيضًا اتجاهات محتملة للتطوير المستقبلي وتكامل البنية التحتية.
باختصار ، من أجل التكيف مع التطبيق واسع النطاق لـ AA ، يحتاج مقدمو البنية التحتية إلى تحسين وتوسيع خدماتهم باستمرار. يتضمن ذلك تحسين خدمات Bundler ، والتعاون مع مزودي خدمة Paymaster المختلفين ، ودمج واجهات API المختلفة ، وتطوير خدمات محتملة أخرى. مع استمرار تطور صناعة AA ، ستساعد هذه الجهود في توفير تجربة blockchain أكثر كفاءة وأمانًا وملاءمة.