TL;DR

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

ومع ذلك، تواجه EIP-4337 لا يزال نقاط الألم مثل تجزئة الحساب الذكي وتجارب المستخدم المتجزئة للغاية عبر السلاسل. يأخذ هذا المقال مشاريع مثل Biconomy و Safe Core و Particle Network كأمثلة لاستكشاف كيفية تعزيز تطوير مجال تجريد الحساب داخل إطار EIP-4337 بشكل أكبر.

من وجهة نظر تجريد عملية العملية، فهم مفهوم "تجريد الحساب"

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

المقترحات السابقة غير القائمة على تجريد الحساب أو محافظ العقود الذكية، على الرغم من أنها قد تحقق تجارب مماثلة، إلا أنها لا تزال غير مرنة وفعالة بما يكفي. على سبيل المثال، ما زال يتطلب Gnosis Safe عنوان EOA لتنشيط المعاملات، وتكلفة الغاز مرتفعة للغاية.

تعتزم تجريد الحساب تحسين الهيكل الأساسي لحسابات العقود الذكية، ممهدة الطريق لجيل جديد من أنظمة الحساب الذكية.

ومع ذلك، إذا نظرنا إلى مقترحات تجريد الحساب الفعلية، سنجد أن تركيزها ليس على نموذج الحساب نفسه. على سبيل المثال، تتركز مقترحات تجريد الحساب مثل EIP-86، EIP-4337، وEIP-6900 على تجريد/تجزئة تدفق المعالجة بأكمله للمعاملة من البدء إلى استقبالها من قبل العقد، التحقق من التوقيع، دفع الغاز، الخ، بدلاً من التركيز حقًا على تجريد هيكل الحساب. لذلك، يبدو من المناسب أكثر الإشارة إلى هذه المقترحات المختلفة باسم "تجريد المعاملة".

إذا فهمنا اقتراحات تجريد الحساب المعروفة جيدًا من منظور 'تجريد تدفق معالجة المعاملات' ، يمكننا فهم نقاطهم الرئيسية بشكل أسهل: هذا النوع من تجريد المعاملات يهدف في الواقع إلى جلب تجربة مستخدمي المستوى Web2 الدخول واستخدام المنتجات في نظام Ethereum بشكل أسهل ، مثل القوائم السوداء / البيضاء ، المعاملات التي بدأت خلال فترة من دون التحقق من الهوية ، المعاملات بدون رسوم غاز ، الدفع بالعملة الورقية للرسوم ، الخ.

بعض الأشخاص قد يشككون: هل لا يمكن تحقيق هذه الوظائف في الماضي باستخدام محافظ العقود الذكية الحالية؟ ما هو قيمة مخططات تجريد الحساب مثل EIP-4337؟

جوهر EIP-4337: تجريد الحساب كحل مثلى محلي في النظام الإيثريوم

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

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

هذا يشبه الوضع قبل ظهور ERC-20 أو ERC-721، حيث كانت طرق التنفيذ والوظائف والوظائف / الواجهات المقدمة للعديد من الرموز غير متناسقة. لم تكن هذه التناقضات مفيدة لتطوير وتدقيق رموز الوصول الطرف الثالث المكملة والتدقيق الشفوي (من الصعب تصور مدى ازدهار تطبيقات DeFi بدون بروتوكول ERC-20).

البروتوكولات الموحّدة / معايير تنفيذ الوظائف هي شرط أساسي للسرد القابل للتعديل، والنهج التطويري المرن هو شرط تقريبي للتنمية النابضة بالحياة في أي مجال (حيث يعتبر تقسيم العمل المبدأ الأساسي لتحسين الكفاءة).

في النهاية، ظهر EIP-4337.

EIP-4337 هو حلاً محليًا مثلى، ولكن هناك زوايا متعددة داخل إطاره تحتاج بشكل عاجل إلى تحسين.

يحدد EIP-4337 مجموعة كاملة من معايير الواجهة، موضحًا الوحدات التي يجب أن يحتوي عليها محفظة ذكية تتبع بروتوكول 4337، والوظائف/الواجهات التي يجب تنفيذها لكل وحدة، مثل Bundler، وEntryPoint، وPaymaster، والوظائف التي يجب أن توفرها هذه المكونات.

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

بالطبع، من وجهة نظر المستخدم، ليس واضحًا بعد قيمة النمط التنموي لتطوير المحفظة الذكية القابلة للتعديل لأن المستخدمين قد لا يشعرون بتغيير كبير في محفظة تجريد الحساب نفسها على المدى القصير. ومع ذلك، على المدى المتوسط ​​إلى الطويل، تكمن قيمة البروتوكولات مثل EIP-4337 في أنها مماثلة لـ ERC-20 و ERC-721. إنها تُمهّد الطريق لتطوير محافظ تجريد الحساب على المدى الطويل وتمثل نقطة تحول ذات أهمية تاريخية.

ومع ذلك، لا يزال لدى EIP-4337 العديد من القضايا الغير محلولة، مثل:

1. وظيفة تجريد الحساب ليست كافية لتكون سهلة الاستخدام، مما يجعل من السهل على المطورين المختلفين إعادة اختراع العجلة.

2. ضعف توافق وحدات الحساب يؤدي إلى نظام بيئي متشظي لأنظمة الحساب.

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

في الأقسام التالية، سنناقش حلولاً لهذه المشاكل.

اتجاه الأمثلية الأول: سيصبح تجريد الحساب معمولًا بأساسيات توصيل وتشغيل الوحدات

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

على سبيل المثال، تعتمد Biconomy على EIP-4337 (وستقدم EIP-6900 الأدق في المستقبل)، وتقترح سرد وظيفة تجريد الحساب القابلة للتوصيل والتشغيل لتعزيز تطوير النظام البيئي لتجريد الحساب بشكل أكثر تفصيلًا.

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

نسخة V2 من Biconomy، استنادًا إلى EIP-4337 كإطار بروتوكول، قد وضعت معايير أكثر تفصيلًا وأضافت مجموعة من الواجهات لم تذكر في 4337. بينما تحدد الوظائف التي يجب أن تكون لديها مجموعة Bundler ومحفظة العقد الذكي و Paymaster، وغيرها من الوحدات، يسمح Biconomy للمطورين الطرف الثالث بتنفيذ وحدات بتفاصيل كود مختلفة ولكن بميزات مماثلة وإصدارات مختلفة، طالما أنها تتوافق مع قواعد البروتوكول المحددة مسبقًا من قبل Biconomy (متوافقة مع EIP-4337)

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

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

تشير Biconomy إلى أن كلما زادت درجة التعددية في محافظ العقود الذكية ، كلما قلت الحاجة إلى التغييرات عند التحديث أو الترقية (لا حاجة لتحديث عقود محافظ العقود الذكية الحالية للمستخدمين أو استخدام DelegateCall ، فقط الوحدات الخارجية المعينة تحتاج إلى تحديث) ، مما يجعل من الأسهل لمختلف المستخدمين أو المطورين استبدال مكونات معينة.

في الإصدار المستقبلي لحل تجريد الحساب الجديد من Biconomy، سيشير أيضًا إلى EIP-6900، والذي يعد أكثر ملاءمة للتعددية من EIP-4337.

الاتجاه التحسيني الثاني: تقسيم الوحدة الناعمة لمعالجة مشاكل تجزئة الحسابات

بالنسبة لاقتراح EIP-6900، أصدرت Safe (المعروفة سابقًا باسم Gnosis Safe) في الواقع ورقة بيضاء حول بروتوكول Safe Core المتعلق به في أغسطس من هذا العام، والتي تستمد بشكل كبير من EIP-6900.

يشير EIP-6900 إلى أن المشكلة الحالية مع تجريد الحساب المعياري هي مشكلة "التشتت" أو "الجزيرة" للحسابات. على سبيل المثال، في حين أن مزودي وحدة تجريد الحساب المختلفة أو تطبيقات DApp المختلفة قد تكون متوافقة مع EIP-4337، إلا أن مستوى التجريد لـ EIP-4337 للوحدات المختلفة ليس كافياً، والحبيبات نسبياً كبيرة. وهذا يترك "حرية زائدة" لمطوري وحدة الحساب الذكي (حيث تخزن الحسابات الذكية معلومات المستخدم وتسجل الجزء الأساسي من التحقق المخصص للمعاملات ومنطق دفع الغاز).

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

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

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

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

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

يقدم بروتوكول Safe Core أيضًا سجلًا، شبيه بمتجر تطبيقات iPhone، الذي يحتوي على جميع الوحدات المعتمدة والمتاحة. يمكن للمستخدمين اختيار الوحدات التي يرغبون في تنشيطها، وعند تنشيط وحدة جديدة في كل مرة، يجب أن تمر عبر عقد المدير.

بشكل عام، سيقوم UserOperation أولاً بتشغيل Plugin معين، ثم سيقوم عقد المدير بالتحقق مما إذا كانت حالة الـ Plugin طبيعية (مسجلة في السجل) أم لا. إذا كانت طبيعية، سيسمح عقد المدير بطلب الـ Plugin بالمتابعة. إذا لزم الأمر، قد يقوم الـ Plugin باستدعاء بعض الوظائف المقدمة من بعض الـ Hooks، أو قد لا يفعل ذلك. بعد ذلك، سيتم تعديل حالة الحساب الذكي المتورط في UserOperation.

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

تحسين الاتجاه الثالث: تجريد الحساب الموحد عبر السلاسل، تحقيق حسابات متسقة على سلاسل مختلفة

ومع ذلك، حتى مع الحلول المذكورة، هناك لا يزال قضية رئيسية غير محلولة: تقدم سلاسل مختلفة وحلول Layer 2 مختلفة مخططات تنفيذ تجريد الحساب المتنوعة بأشكال متضاربة، كثير منها يتعارض مع EIP-4337، مثل zkSync Era، Starknet، Flow، إلخ. هذا التجزؤ في تجربة المحفظة، على سبيل المثال، يجعل من المستحيل توحيد عنوان محفظة المستخدم الذكي على Starknet مع ذلك على Arbitrum.

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

اقترح فيتاليك نفسه سابقًا حلا موحدًا وسهل الإدارة للحساب الذكي عبر جميع الشبكات. يستخدم هذا الحل إثريوم أو ZKRollup الآمن بشكل كبير كسلسلة مصدرية، وينتشر عقد Keystore لتخزين المفاتيح العالمية للمستخدمين، ثم يشارك جميع حسابات العقد الذكي على الطبقة 2 المفاتيح العالمية المخزنة في عقد Keystore.

ومع ذلك، تأتي هذه الحلول بتكاليف عالية للغاية. كلما حدث تغيير في المفاتيح العالمية المسجلة بواسطة عقد Keystore على السلسلة المصدر، يحتاج كل حساب على سلسلة L2/الهدف إلى مزامنة المفاتيح الجديدة من خلال تفاعلات السلسلة العابرة. ومع ذلك، فإن تكلفة التفاعلات العابرة بين إيثريوم وL2 مرتفعة جدًا بحيث لا يستطيع المستخدمون تحملها. بالإضافة إلى ذلك، من المهم ملاحظة أن حسابات العقود الذكية تختلف عن حسابات EOA. بينما الأخيرة، بسبب طريقة توليد العناوين الفريدة الخاصة بها، موحدة بشكل طبيعي عبر سلاسل متعددة (Dentro del EVM ecosystem)، فإن حسابات العقود الذكية مختلفة تمامًا، مما يجعل من الصعب على المستخدمين الحصول على حسابات عقود ذكية بنفس العنوان على سلاسل مختلفة.

ردًا على ذلك، اقترح شبكة الجسيم نهجها الخاص. على الرغم من أن الفكرة العامة تتماشى مع مفهوم فيتاليك لفصل التخزين والشفرة للحسابات الذكية، تعتزم شبكة الجسيم استخدام سلسلة منفصلة—سلسلة شبكة الجسيم— كقاعدة بيانات تخزين كاملة للحسابات الذكية. من خلال حلول الرسائل بين السلاسل الجانبية من جهات خارجية (مثل LayerZero، CCIP، Axelar، Connext، الخ)، تعتزم شبكة الجسيم مزامنة التغييرات على تخزين الحساب مع حسابات محلية لسلاسل أخرى.

(هيكل تجريد الحساب متعدد السلاسل لشبكة الجسيمات)

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

يتيح تجريد الحساب الكامل أيضًا عمليات المستخدم عبر السلاسل الكاملة، مما يتيح للمستخدمين تشغيل المعاملات على السلسلة المستهدفة من خلال عمليات المستخدم ودفع الغاز المقابل على السلسلة المصدرية. على سبيل المثال، يسمح بشراء NFTs على Base باستخدام USDC من Polygon.

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

ومع ذلك، يمكن تكوين مزامنة حسابات المستخدمين عبر السلاسل الجانبية بشكل مرن باستخدام تركيبات مختلفة من جسور الرسائل، بدلاً من الاعتماد على جسر واحد. على سبيل المثال، يمكن تكوينه بسياسة 2/3، حيث لا يتم تأكيد تغييرات التخزين على السلسلة الهدف إلا بعد تأكيد أي اثنين من LayerZero، Axelar، أو Connext للتغيير، مما يمكن أن يخفف من مشكلة الاعتماد على نقطة واحدة فقط.

التوافق التشغيلي السلس عبر سلاسل EVM وغير EVM يمثل خطوة إضافية في تجريد الحساب الكامل داخل نظام الأثيريوم. على الرغم من التقدم في إدارة المفاتيح الرئيسية والحسابات الموحدة عبر سلاسل EVM، إلا أن هناك مساحة للتحسين في تجريد الحساب الكامل. السلاسل التي لا تتوافق مع EVM، مثل Aptos وSolana وSui، لا يمكنها ضمان توافق عناوين حسابات العقد الذكية التي يتم إنشاؤها بواسطة المستخدمين مع تلك الموجودة على سلاسل EVM. بالإضافة إلى ذلك، قد تواجه السلاسل غير EVM صعوبة في اعتماد مفهوم تجريد الحساب الكامل الذي اقترحه فيتاليك وشبكة الجسيمات دون تنفيذ حلول مكافئة لبروتوكول EIP-4337.

ومع ذلك، هناك مجال للتحسين في مشاريع المحافظ المتوافقة مع EIP-4337. معظم المحافظ الذكية تستخدم عقد الحزمة Bundler الذي تديره بشكل مستقل منصاتها الخاصة، والتي غالبًا ما لا تكون متصلة ببعضها البعض. يشكل هذا العزل مخاطر مثل مقاومة الرقابة والتوفر. سيكون بناء واجهة أمامية موحدة عبر معظم الشبكات تحديًا شديد الصعوبة. يمكن أن يكون أحد النهج للتعامل مع هذا هو إدخال تصميم مركزي حول النية، عن طريق إضافة طبقة فوق تجريد الحساب الكامل للسلسلة، عند التعامل مع بيئة Ethereum’s EIP-4337 أو مرافق تجريد الحساب الأصلية لسلاسل أخرى (مثل zkSync) كحالات محددة تحت فئة Solver/Reactor، مع اختيار الحلول المناسبة كمهمة على مستوى أعلى.

على سبيل المثال، يقترح شبكة الجسيمات تجريدًا موجزًا لتنفيذ منحى مركزي للنية، حيث تعتبر مشاريع تجريد الحساب المختلفة مثاليات بسيطة مدرجة في فئة المحلل ضمن نظام النية.

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

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

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

النية الحالية تحمي بشكل أساسي التفاصيل المعقدة الأساسية وتجرد طبقة أعلى. تصميم متدرج من هذا القبيل الذي يشبه بروتوكول TCP/IP ضروري لتجارب المستخدم والمطور في التوافق السلس عبر الشبكات.

اعتناق اعتماد واسع الانتشار لتجريد الحساب

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

واحدة من أفضل المنتجات للعب هذا الدور هي منتج Modular Smart Wallet-as-a-Service (المحفظة الذكية القابلة للتعديل كخدمة) من شبكة Particle.

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

بالإضافة إلى الميزات الصديقة للمطور المذكورة أعلاه، أهم جانب هو أن منتج شبكة Particle Network’s Modular Smart Wallet-as-a-Service (Modular Smart Wallet-as-a-Service) قام ببناء نظام بيئي مفتوح لتجريد الحساب في مجتمع المطورين، استنادًا إلى عملية التوقيع. بالإضافة إلى توفير وحدات منتج تجريد الحساب المطورة ذاتيًا، يقوم بدمج مختلف أنواع منتجات وخدمات تجريد الحساب، مما يسهل اعتماد منتجات وخدمات سريعة من مطورين مختلفين في مجال تجريد الحساب بأكمله.

من خلال مواءمة التكنولوجيا مع الطلب ومعالجة قيود إطار ERC-4337 من جميع الزوايا، ستسهم التحسينات في تجربة المطور في تعزيز ظهور المزيد من المنتجات ذات التجارب المستخدم المتميزة. وسيسرع ذلك في انتقال صناعة الويب3 من كونها موجهة نحو عشاق العملات الرقمية إلى صديقة للمستهلك وشائعة.

إخلاء المسؤولية:

1. تم نقل هذه المقالة من[腾讯网], جميع حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [بيتر بان، المؤسس المشارك والمدير التقني لشبكة الجسيمات &Faust، جيك Web3]. إذا كانت هناك اعتراضات على هذا النشر، يرجى الاتصال بالبوابة تعلمالفريق، وسوف يتعاملون معه بسرعة.
2. إخلاء المسؤولية عن المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك الكاتب ولا تشكل أي نصيحة استثمارية.
3. تقوم فرق Gate Learn بترجمة المقال إلى لغات أخرى. ما لم يذكر غير ذلك، فإن نسخ أو توزيع أو سرقة المقالات المترجمة ممنوع.