سواء كان سوقًا صاعدًا أو سوقًا هابطة ، فإن النظام البيئي Ethereum يبني باستمرار ويحسن نفسه. من بينها ، حقق Account Abstraction (AA) تقدمًا مهمًا في السنوات الأخيرة وتغلغل في جميع أجزاء النظام البيئي Ethereum ، بما في ذلك التطبيقات والبنية التحتية والمستخدمين والمطورين. يمكننا أن نتوقع أن اعتماد AA على نطاق واسع سيقلل من عتبة استخدام blockchain ككل ويقدم تجربة مستخدم web2 في صناعة web3.
لاغتنام فرصة سوق AA الذي يحتمل أن يكون بمليارات الدولارات ، تخطط BlockPI لدمج AA في خدمات البنية التحتية الخاصة بها. من خلال التكامل والابتكار في مجال AA ، تلتزم BlockPI بتزويد مستخدمي AA بطريقة أكثر ملاءمة وفعالية للتفاعل مع حسابات محفظة عقود blockchain ، وتأمل أن تصبح رائدة في هذه الصناعة.
في هذه المقالة ، سيتعمق فريق BlockPI في فهمهم لـ AA ومشاركة الأفكار من منظور مزود خدمة البنية التحتية.
EOA ومحفظة العقد
ينبع مفهوم AA من قيود حسابات EOA. حساب EOA (حساب مملوك خارجيًا) هو حساب مستخدم في Ethereum ، يتم تمثيله بمفتاح عام (عنوان blockchain) ويتم الوصول إليه من خلال مفتاح خاص. إنه مكون رئيسي في النظام البيئي Ethereum ، مما يسمح للمستخدمين بتحويل الأموال على blockchain أو التفاعل مع العقود الذكية. ومع ذلك ، بالنسبة للعديد من الأشخاص ، يمكن أن يكون استخدام EOA مهمة صعبة في حد ذاته. علاوة على ذلك ، لا يزال حساب EOA الحالي به بعض الإزعاج قيد الاستخدام ، مما يؤثر على تجربة المستخدم.
الأول هو قضية رسوم الغاز. ستكلف كل معاملة المستخدم مبلغًا كبيرًا من ETH كرسوم غاز (خذ سعر الغاز البالغ 25 Gwei كمثال ، تبلغ رسوم الغاز لتحويل ETH البسيط حوالي 0.5 دولار أمريكي ، وستكون أكثر تكلفة للتفاعل مع العقد أو عندما يكون سعر الغاز أعلى). وهذا يجعل المعاملات الصغيرة مكلفة للغاية ، خاصة خلال فترات الازدحام الشديد في الشبكة. بالإضافة إلى ذلك ، يمكن استخدام ETH فقط للدفع مقابل Gas ، مما يعني أنه يجب على المستخدمين الاحتفاظ بـ 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". وبهذه الطريقة ، فإنه يكرر فعليًا تجمع ذاكرة إيثيريوم بوظائف مماثلة على الطبقة العليا من نظام blockchain. ما يقدمه المستخدم لم يعد معاملة واحدة ، ولكنه عملية مستخدم. يمكن تجميع عمليات المستخدم هذه في معاملة واحدة وإرسالها إلى 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.
** المُجمِّع ** - عقد إضافي تثق به الحسابات للتحقق من التوقيعات المُجمَّعة. يقوم المجمّعون / العملاء بإدراج مجمّعي التوقيع المدعومين في القائمة البيضاء. يجب أن يقوم العارضون بتكوين واجهة IAggregator باتباع معيار ERC-4337.
** Paymaster ** - عقد ذكي يمكنه دفع الغاز نيابة عنك. إذا قامت بإيداع ما يكفي من ETH في عقد EntryPoint ، فيمكنها دفع العقد الذكي للمرسل مقابل رسوم غاز UserOperation ، وتنفيذ استخراج الغاز بشكل فعال. يجب أن يتبع مسؤول الدفع معيار 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 Gas من رصيد حسابها الخاص ، أو طلب عقد Paymaster لدفع ثمنها. لا يمكن لعمليات UserOperations اجتياز خطوة التحقق خارج السلسلة بدون غاز كافٍ ، أي أنها تفشل قبل تنفيذ المعاملة على السلسلة. حتى إذا كان هناك غاز كافٍ ، فقد تستمر عمليات المستخدم في الفشل بسبب أخطاء وقت التشغيل وأسباب أخرى أثناء التنفيذ. بالنسبة لعملية المستخدم ، بغض النظر عما إذا كان تنفيذ العقد ناجحًا أم لا ، فإن عقد EntryPoint سيدفع رسوم الغاز إلى Bundler الذي يقوم بتشغيل وظيفة handleOps.
بعد دخول ERC-4337 حيز التنفيذ ، يمكن للمستخدمين الآن بدء معاملات blockchain بطريقتين. أحدهما هو الطريقة التقليدية ، أي أن EOA يبدأ المعاملة مباشرة. والآخر هو استخدام معيار ERC-4337 لبدء UserOperation من خلال Bundler ، ثم يقوم Bundler بحزمه مع عمليات المستخدم الأخرى وإرساله إلى سلسلة الشبكة. يوضح الرسم البياني أدناه الفرق بين معاملة إرسال EOA عادية ومحفظة عقد ERC-4337 ترسل UserOperation.
الطريق ممهد ، لكن لا يوجد الكثير من المشاة حتى الآن
يوفر ERC-4337 إطارًا قويًا للمستخدمين والمطورين لاستخدام وبناء AA على Ethereum. على الرغم من أن هذا الإطار يمثل تقدمًا مهمًا ، إلا أنه لا تزال هناك بعض التحديات والشكوك التي يجب معالجتها وحلها.
لا يزال اعتماد AA في مهده. وفقًا للوحة تحليل Dune ERC-4337 [تجريد حساب ERC-4337] ، تم تنفيذ 65 ألف + فقط من عمليات المستخدم على السلسلة ، 90٪ منها جاءت من Polygon. لذلك ، لا يزال عدد عمليات المستخدم التي يتم إجراؤها حاليًا صغيرًا جدًا ، ومعظمها اختبارات للمطورين ، وجزء صغير فقط يأتي من مستخدمين حقيقيين. نلاحظ أن المنتجات التي تم دمج AA لا تزال في مراحلها الأولى. في الوقت الحاضر ، يمكننا أن نلاحظ أن Bundlers ككل لا تزال في حالة خسارة ، والخسارة الحالية هي أكثر من 700 MATIC. يرجع هذا بشكل أساسي إلى قيام بعض التجميعين على Polygon بتقدير خاطئ للغاز المطلوب ، مما أدى إلى أن الغاز الذي يتم إرجاعه بواسطة EntryPoint يكون أقل من الغاز الذي تستهلكه الحزمة المقدمة. يجب حل هذه المشكلة على مستوى عميل Bundler.
علاوة على ذلك ، هناك عدد قليل من القضايا التي تحتاج إلى معالجة. تتمثل إحدى هذه المشكلات في كيفية تعامل Bundlers مع فشل المعاملات.
بعد تجميع عمليات مستخدم متعددة معًا ، سيحاكي Bundlers المعاملة أولاً ، ويكتشفوا ما إذا كان هناك فشل في تنفيذ العقد ، ويحسب ما إذا كانت رسوم الغاز التي يتم إرجاعها بواسطة المرسل أو Paymaster أكبر من رسوم الغاز المدفوعة.
إذا كانت مربحة ، يرسل Bundler هذه المجموعة من UserOperations إلى عقدة الكتلة كمعاملة. ومع ذلك ، لا يزال من الممكن أن تفشل المعاملة ، مما يؤدي إلى قيام Bundler بدفع رسوم الغاز ولكن لا يتلقى استرداد الغاز من EntryPoint. على سبيل المثال ، قد يرسل المستخدم إجراءات إلى حزم مختلفة. إذا كان هناك مجال للربح ونجحت المحاكاة ، فإن Bundlers تلزمها بالسلسلة. في هذه الحالة ، إذا تم إرسال UserOperation إلى عقدة الحظر بواسطة حزم مختلفة في نفس الوقت ، فستنجح معاملة واحدة فقط ، مما يعني أن Bundler واحدًا فقط سيتلقى رسوم الغاز التي يتم إرجاعها بواسطة EntryPoint ، وستفشل جميع الحزم الأخرى بسبب للتسلسل وفقدان الغاز. على الرغم من أن بعض الأشخاص قد يعتقدون أن هذا السلوك يجب اعتباره هجومًا ضارًا ، ويجادلون بأن Bundler يمكنها حظر عنوان المرسل ورفض أي طلبات مستقبلية من هذا العنوان ، إلا أن هذا ليس حلاً معقولاً ، لأن المستخدمين قد يتخذون هذا الإجراء عن غير قصد. السلوك . يجب معالجة هذه المشكلة بشكل صحيح في التعليمات البرمجية ، ربما من خلال شبكة mempool العامة قيد التطوير. علاوة على ذلك ، قد يتعرض 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 لتنفيذ الفرز العادل. سيؤدي هذا الأخير إلى القضاء تمامًا على إمكانية استخراج MEVs في 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 من أجل حسابات التحقق والسياسة هذه. بالإضافة إلى ذلك ، تحتاج الحزم أيضًا إلى ضمان تجربة مستخدم جيدة للمستخدمين والتأكد من أن المستخدمين لا يواجهون تأخيرات مفرطة بعد إرسال عمليات المستخدم.
على الرغم من أن الحلول لهذه التحديات لا تزال غير واضحة ، يمكننا القول بثقة أن تطوير صناعة AA والجهود المشتركة للمطورين ستحل هذه المشكلات في النهاية. بصفتها منشئ البنية التحتية ، تأمل BlockPI في لعب دور حل المشكلات في تطوير صناعة AA ، سواء كمطور أو لتوفير بنية تحتية متوافقة مع AA للمطورين الآخرين.
\ * يجب أن تتكيف البنية التحتية مع AA
يلخص AA الأدوار المختلفة التي تنطوي عليها المعاملات على السلسلة ، بما في ذلك Sender و Bundlers و Gas payers ومحافظ العقود والموقِّعون ، بحيث يتمتع المستخدمون بدرجة أعلى من الحرية عند استخدام blockchain. في الوقت نفسه ، يمكن لمزودي البنية التحتية نشر هذه الخدمات بشكل مستقل وفقًا لتقديراتهم الخاصة في السوق.
من أجل التكيف مع اعتماد AA على نطاق واسع ، يحتاج مقدمو البنية التحتية أولاً إلى تقديم خدمتين أساسيتين على الأقل: خدمة Bundler وخدمة Paymaster.
في خدمة Bundler ، قد يحتاج مزود البنية التحتية إلى تطوير مجموعة ذاكرة خاصة مع 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 أكثر كفاءة وأمانًا وملاءمة.
حاليًا ، تعمل BlockPI بجد لتحقيق الأهداف المذكورة أعلاه. ليس ذلك فحسب ، فقد تواصلنا مع جميع عملاء Bundler وموفري خدمات Paymaster تقريبًا في المجتمع ، وسنقوم بدمج AA في شبكة BlockPI كأهم مهمة تطوير لدينا. في الوقت نفسه ، أجرينا أيضًا اتصالات متعمقة مع مطوري محافظ AA لفهم احتياجات المستخدم. نرحب ترحيبا حارا بجميع Bundlers و Paymasters والمحافظ للتواصل والتعاون معنا.
الهدف من BlockPI هو بناء وتطوير النظام البيئي AA مع المجتمع ، والقيام بكل ما هو ممكن لتعزيز تقدم وازدهار النظام البيئي AA. نأمل أنه من خلال التعاون مع المجتمع ، سنساهم في صناعة AA بأكملها كرائد في الصناعة وندعم عملية التطوير اللاحقة ، بحيث يمكن لمستخدمي Web2 تجربة تقنية blockchain دون حواجز.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
كيف تدعم البنية التحتية مليارات المستخدمين من خلال استخراج الحساب؟
سواء كان سوقًا صاعدًا أو سوقًا هابطة ، فإن النظام البيئي Ethereum يبني باستمرار ويحسن نفسه. من بينها ، حقق Account Abstraction (AA) تقدمًا مهمًا في السنوات الأخيرة وتغلغل في جميع أجزاء النظام البيئي Ethereum ، بما في ذلك التطبيقات والبنية التحتية والمستخدمين والمطورين. يمكننا أن نتوقع أن اعتماد AA على نطاق واسع سيقلل من عتبة استخدام blockchain ككل ويقدم تجربة مستخدم web2 في صناعة web3.
لاغتنام فرصة سوق AA الذي يحتمل أن يكون بمليارات الدولارات ، تخطط BlockPI لدمج AA في خدمات البنية التحتية الخاصة بها. من خلال التكامل والابتكار في مجال AA ، تلتزم BlockPI بتزويد مستخدمي AA بطريقة أكثر ملاءمة وفعالية للتفاعل مع حسابات محفظة عقود blockchain ، وتأمل أن تصبح رائدة في هذه الصناعة.
في هذه المقالة ، سيتعمق فريق BlockPI في فهمهم لـ AA ومشاركة الأفكار من منظور مزود خدمة البنية التحتية.
EOA ومحفظة العقد
ينبع مفهوم AA من قيود حسابات EOA. حساب EOA (حساب مملوك خارجيًا) هو حساب مستخدم في Ethereum ، يتم تمثيله بمفتاح عام (عنوان blockchain) ويتم الوصول إليه من خلال مفتاح خاص. إنه مكون رئيسي في النظام البيئي Ethereum ، مما يسمح للمستخدمين بتحويل الأموال على blockchain أو التفاعل مع العقود الذكية. ومع ذلك ، بالنسبة للعديد من الأشخاص ، يمكن أن يكون استخدام EOA مهمة صعبة في حد ذاته. علاوة على ذلك ، لا يزال حساب EOA الحالي به بعض الإزعاج قيد الاستخدام ، مما يؤثر على تجربة المستخدم.
الأول هو قضية رسوم الغاز. ستكلف كل معاملة المستخدم مبلغًا كبيرًا من ETH كرسوم غاز (خذ سعر الغاز البالغ 25 Gwei كمثال ، تبلغ رسوم الغاز لتحويل ETH البسيط حوالي 0.5 دولار أمريكي ، وستكون أكثر تكلفة للتفاعل مع العقد أو عندما يكون سعر الغاز أعلى). وهذا يجعل المعاملات الصغيرة مكلفة للغاية ، خاصة خلال فترات الازدحام الشديد في الشبكة. بالإضافة إلى ذلك ، يمكن استخدام ETH فقط للدفع مقابل Gas ، مما يعني أنه يجب على المستخدمين الاحتفاظ بـ 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". وبهذه الطريقة ، فإنه يكرر فعليًا تجمع ذاكرة إيثيريوم بوظائف مماثلة على الطبقة العليا من نظام blockchain. ما يقدمه المستخدم لم يعد معاملة واحدة ، ولكنه عملية مستخدم. يمكن تجميع عمليات المستخدم هذه في معاملة واحدة وإرسالها إلى 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.
** المُجمِّع ** - عقد إضافي تثق به الحسابات للتحقق من التوقيعات المُجمَّعة. يقوم المجمّعون / العملاء بإدراج مجمّعي التوقيع المدعومين في القائمة البيضاء. يجب أن يقوم العارضون بتكوين واجهة IAggregator باتباع معيار ERC-4337.
** Paymaster ** - عقد ذكي يمكنه دفع الغاز نيابة عنك. إذا قامت بإيداع ما يكفي من ETH في عقد EntryPoint ، فيمكنها دفع العقد الذكي للمرسل مقابل رسوم غاز UserOperation ، وتنفيذ استخراج الغاز بشكل فعال. يجب أن يتبع مسؤول الدفع معيار ERC-4337 لتكوين واجهة Paymaster. يمكن أن يعقد Paymaster اتفاقية مع المرسل. على سبيل المثال ، يدفع المرسل USDC إلى Paymaster ، ويستخدم Paymaster ETH لدفع غاز عمليات المستخدم التي يرسلها. في الواقع ، يمكن أن يختار Paymaster دعم أي ملف
رمز
، بما في ذلك ERC-20
رمز
حتى سلاسل أخرى
رمز
。
يوضح الرسم البياني أدناه كيفية تفاعل عقد EntryPoint مع الجهات الفاعلة الأخرى.
تستدعي Bundlers وظيفة handleOps لعقد EntryPoint ، والتي تقبل عملية المستخدم كمدخلات.
سوف تتحقق handleOps من UserOperation على السلسلة ، وتتحقق مما إذا كانت موقعة من خلال عنوان محفظة العقد الذكي المحدد ، وتأكيد ما إذا كانت المحفظة بها ما يكفي من الغاز لتعويض Bundler.
إذا تم تمرير التحقق ، فسيقوم handleOps بتنفيذ وظيفة محفظة العقد الذكية وفقًا للوظيفة ومعلمات الإدخال المحددة في بيانات استدعاء UserOperation.
من ناحية أخرى ، عندما يستخدم Bundler EOA لتشغيل وظيفة handleOps ، سيتم فرض رسوم غاز. يمكن لمحفظة العقد الذكية دفع رسوم Bundlers Gas من رصيد حسابها الخاص ، أو طلب عقد Paymaster لدفع ثمنها. لا يمكن لعمليات UserOperations اجتياز خطوة التحقق خارج السلسلة بدون غاز كافٍ ، أي أنها تفشل قبل تنفيذ المعاملة على السلسلة. حتى إذا كان هناك غاز كافٍ ، فقد تستمر عمليات المستخدم في الفشل بسبب أخطاء وقت التشغيل وأسباب أخرى أثناء التنفيذ. بالنسبة لعملية المستخدم ، بغض النظر عما إذا كان تنفيذ العقد ناجحًا أم لا ، فإن عقد EntryPoint سيدفع رسوم الغاز إلى Bundler الذي يقوم بتشغيل وظيفة handleOps.
بعد دخول ERC-4337 حيز التنفيذ ، يمكن للمستخدمين الآن بدء معاملات blockchain بطريقتين. أحدهما هو الطريقة التقليدية ، أي أن EOA يبدأ المعاملة مباشرة. والآخر هو استخدام معيار ERC-4337 لبدء UserOperation من خلال Bundler ، ثم يقوم Bundler بحزمه مع عمليات المستخدم الأخرى وإرساله إلى سلسلة الشبكة. يوضح الرسم البياني أدناه الفرق بين معاملة إرسال EOA عادية ومحفظة عقد ERC-4337 ترسل UserOperation.
الطريق ممهد ، لكن لا يوجد الكثير من المشاة حتى الآن
يوفر ERC-4337 إطارًا قويًا للمستخدمين والمطورين لاستخدام وبناء AA على Ethereum. على الرغم من أن هذا الإطار يمثل تقدمًا مهمًا ، إلا أنه لا تزال هناك بعض التحديات والشكوك التي يجب معالجتها وحلها.
لا يزال اعتماد AA في مهده. وفقًا للوحة تحليل Dune ERC-4337 [تجريد حساب ERC-4337] ، تم تنفيذ 65 ألف + فقط من عمليات المستخدم على السلسلة ، 90٪ منها جاءت من Polygon. لذلك ، لا يزال عدد عمليات المستخدم التي يتم إجراؤها حاليًا صغيرًا جدًا ، ومعظمها اختبارات للمطورين ، وجزء صغير فقط يأتي من مستخدمين حقيقيين. نلاحظ أن المنتجات التي تم دمج AA لا تزال في مراحلها الأولى. في الوقت الحاضر ، يمكننا أن نلاحظ أن Bundlers ككل لا تزال في حالة خسارة ، والخسارة الحالية هي أكثر من 700 MATIC. يرجع هذا بشكل أساسي إلى قيام بعض التجميعين على Polygon بتقدير خاطئ للغاز المطلوب ، مما أدى إلى أن الغاز الذي يتم إرجاعه بواسطة EntryPoint يكون أقل من الغاز الذي تستهلكه الحزمة المقدمة. يجب حل هذه المشكلة على مستوى عميل Bundler.
علاوة على ذلك ، هناك عدد قليل من القضايا التي تحتاج إلى معالجة. تتمثل إحدى هذه المشكلات في كيفية تعامل Bundlers مع فشل المعاملات.
بعد تجميع عمليات مستخدم متعددة معًا ، سيحاكي Bundlers المعاملة أولاً ، ويكتشفوا ما إذا كان هناك فشل في تنفيذ العقد ، ويحسب ما إذا كانت رسوم الغاز التي يتم إرجاعها بواسطة المرسل أو Paymaster أكبر من رسوم الغاز المدفوعة.
إذا كانت مربحة ، يرسل Bundler هذه المجموعة من UserOperations إلى عقدة الكتلة كمعاملة. ومع ذلك ، لا يزال من الممكن أن تفشل المعاملة ، مما يؤدي إلى قيام Bundler بدفع رسوم الغاز ولكن لا يتلقى استرداد الغاز من EntryPoint. على سبيل المثال ، قد يرسل المستخدم إجراءات إلى حزم مختلفة. إذا كان هناك مجال للربح ونجحت المحاكاة ، فإن Bundlers تلزمها بالسلسلة. في هذه الحالة ، إذا تم إرسال UserOperation إلى عقدة الحظر بواسطة حزم مختلفة في نفس الوقت ، فستنجح معاملة واحدة فقط ، مما يعني أن Bundler واحدًا فقط سيتلقى رسوم الغاز التي يتم إرجاعها بواسطة EntryPoint ، وستفشل جميع الحزم الأخرى بسبب للتسلسل وفقدان الغاز. على الرغم من أن بعض الأشخاص قد يعتقدون أن هذا السلوك يجب اعتباره هجومًا ضارًا ، ويجادلون بأن Bundler يمكنها حظر عنوان المرسل ورفض أي طلبات مستقبلية من هذا العنوان ، إلا أن هذا ليس حلاً معقولاً ، لأن المستخدمين قد يتخذون هذا الإجراء عن غير قصد. السلوك . يجب معالجة هذه المشكلة بشكل صحيح في التعليمات البرمجية ، ربما من خلال شبكة mempool العامة قيد التطوير. علاوة على ذلك ، قد يتعرض 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 لتنفيذ الفرز العادل. سيؤدي هذا الأخير إلى القضاء تمامًا على إمكانية استخراج MEVs في 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 من أجل حسابات التحقق والسياسة هذه. بالإضافة إلى ذلك ، تحتاج الحزم أيضًا إلى ضمان تجربة مستخدم جيدة للمستخدمين والتأكد من أن المستخدمين لا يواجهون تأخيرات مفرطة بعد إرسال عمليات المستخدم.
على الرغم من أن الحلول لهذه التحديات لا تزال غير واضحة ، يمكننا القول بثقة أن تطوير صناعة AA والجهود المشتركة للمطورين ستحل هذه المشكلات في النهاية. بصفتها منشئ البنية التحتية ، تأمل BlockPI في لعب دور حل المشكلات في تطوير صناعة AA ، سواء كمطور أو لتوفير بنية تحتية متوافقة مع AA للمطورين الآخرين.
\ * يجب أن تتكيف البنية التحتية مع AA
يلخص AA الأدوار المختلفة التي تنطوي عليها المعاملات على السلسلة ، بما في ذلك Sender و Bundlers و Gas payers ومحافظ العقود والموقِّعون ، بحيث يتمتع المستخدمون بدرجة أعلى من الحرية عند استخدام blockchain. في الوقت نفسه ، يمكن لمزودي البنية التحتية نشر هذه الخدمات بشكل مستقل وفقًا لتقديراتهم الخاصة في السوق.
من أجل التكيف مع اعتماد AA على نطاق واسع ، يحتاج مقدمو البنية التحتية أولاً إلى تقديم خدمتين أساسيتين على الأقل: خدمة Bundler وخدمة Paymaster.
في خدمة Bundler ، قد يحتاج مزود البنية التحتية إلى تطوير مجموعة ذاكرة خاصة مع 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 أكثر كفاءة وأمانًا وملاءمة.
حاليًا ، تعمل BlockPI بجد لتحقيق الأهداف المذكورة أعلاه. ليس ذلك فحسب ، فقد تواصلنا مع جميع عملاء Bundler وموفري خدمات Paymaster تقريبًا في المجتمع ، وسنقوم بدمج AA في شبكة BlockPI كأهم مهمة تطوير لدينا. في الوقت نفسه ، أجرينا أيضًا اتصالات متعمقة مع مطوري محافظ AA لفهم احتياجات المستخدم. نرحب ترحيبا حارا بجميع Bundlers و Paymasters والمحافظ للتواصل والتعاون معنا.
الهدف من BlockPI هو بناء وتطوير النظام البيئي AA مع المجتمع ، والقيام بكل ما هو ممكن لتعزيز تقدم وازدهار النظام البيئي AA. نأمل أنه من خلال التعاون مع المجتمع ، سنساهم في صناعة AA بأكملها كرائد في الصناعة وندعم عملية التطوير اللاحقة ، بحيث يمكن لمستخدمي Web2 تجربة تقنية blockchain دون حواجز.