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

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

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

فيما يتعلق بتجريد الحساب ، أشار فيتاليك عدة مرات إلى أنه شرط ضروري لخفض عتبة مستخدمي Ethereum وتحقيق التبني الجماعي. تتمثل رؤيتها الأساسية في السماح للمستخدمين بتخصيص طريقة التحقق من التوقيع والاستمتاع بدفع الغاز ، ويمكنهم بدء معاملة على السلسلة دون أي أصول (المعروفة باسم المعاملة الخالية من الغاز). فقط من خلال تحقيق هذه المتطلبات الأساسية ، يمكن لتطبيقات Web3 تحسين معدلات تحويل المستخدم الخاصة بها. على الرغم من أن المقترحات المجردة السابقة غير الحسابية أو محافظ العقود الذكية يمكن أن تحقق تجارب مماثلة ، إلا أنها بعيدة كل البعد عن المرونة والكفاءة الكافية. على سبيل المثال ، لا يزال Gnosis Safe يتطلب عنوان EOA لبدء المعاملات ، وتكاليف الغاز التي ينطوي عليها مرتفعة للغاية. يهدف تجريد الحساب إلى تحسين الهيكل الأساسي لحسابات العقود الذكية ، مما يمهد الطريق للجيل التالي من أنظمة الحسابات الذكية. ولكن إذا نظرنا إلى مقترحات تجريد الحساب الفعلية ، فسنجد أن تركيزها ليس على نموذج الحساب نفسه. على سبيل المثال ، تركز المقترحات المتعلقة بتجريد الحساب مثل EIP-86 و EIP-4337 و EIP-6900 على تجريد / تعديل عملية المعالجة الكاملة للمعاملة من البداية إلى استلامها بواسطة العقد ، بالإضافة إلى التحقق من التوقيع ، ودفع الغاز ، وما إلى ذلك ، بدلا من التركيز على تجريد هيكل الحساب في حد ذاته. تجريد هيكل الحساب. لذلك ، يبدو من الأنسب تسمية المقترحات الحالية المختلفة "تجريدات تدفق المعاملات". إذا فهمنا مقترحات تجريد الحساب المعروفة هذه من منظور تجريد تدفق المعاملات ، فيمكننا فهم نقاطها الرئيسية بسهولة أكبر: يهدف هذا النوع من تجريد المعاملات في الواقع إلى جلب تجربة المستخدم لإدخال مستوى Web2 واستخدام المنتج في نظام Ethereum. قد يتخذ هذا شكل قوائم سوداء / قوائم بيضاء ، وبدء عمليات التتبع دون التحقق من الهوية خلال فترة زمنية معينة ، والمعاملات الخالية من الغاز ، ومدفوعات العملات الورقية ، وما إلى ذلك.

(مصدر الصورة: زينجو)

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

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

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

(مصدر الصورة: رابط سبرنجر)

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

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

في نهاية المطاف، يبرز EIP-4337.

EIP-4337 هو حلاً محليًا مثلى، ولكن هناك عدة وجهات نظر ضمن إطاره تحتاج إلى تحسين

يحدد EIP-4337 مجموعة كاملة من معايير الواجهة ، موضحا الوحدات المتوقعة في المحافظ الذكية التي تلتزم ببروتوكول 4337 والوظائف / الواجهات التي يجب على كل وحدة تنفيذها. على سبيل المثال ، ما هي الوظائف القابلة للاستدعاء التي يجب أن تقدمها مكونات مثل المجمع ونقاط الدخول ومسؤول الدفع خارجيا. مع وجود هذه الإرشادات ، تصبح التفاعلات بين المكونات المختلفة أكثر وضوحا ، مما يسهل دمج أفكار التصميم المعيارية في تصميم تجريد الحساب والمحافظ الذكية. يستفيد المطورون الذين يعملون على وحدات المحفظة أيضا بشكل كبير. ومع ذلك ، بالنظر إلى وجهة نظر المستخدم البحتة ، قد لا تكون القيمة التي يجلبها نموذج تطوير المحفظة الذكية المعيارية واضحة على الفور لأن التغييرات في محافظ تجريد الحساب نفسها قد لا تكون واضحة على المدى القصير. ومع ذلك ، بالنظر إلى المدى المتوسط إلى الطويل ، فإن قيمة البروتوكولات مثل EIP-4337 تشبه قيمة ERC-20 و ERC-721. إنه يضع الأساس لتطوير محافظ تجريد الحساب على المدى الطويل ، مما يمثل علامة فارقة مهمة. ومع ذلك ، لا يزال لدى EIP-4337 العديد من المشكلات التي لم يتم حلها ، مثل:

1. تجريم التجريم غير سهل بما فيه الكفاية للدمج، مما يؤدي إلى أن يقوم مطورون مختلفون بإعادة اختراع العجلة دون قصد.

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

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

أدناه، سنتناول حلول لهذه المشكلات.

الحل الأمثل 1: سيصبح ملحق التجريد الحسابي الإعداد الأساسي

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

(مصدر الصورة: Biconomy)

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

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

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

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

في مخطط التجريد الحسابي المحدث القادم من Biconomy، سينظرون أيضًا في EIP-6900، والذي يعزز من التقسيم الوحدوي أكثر من EIP-4337.

الحل الأمثل 2: تقسيم الوحدة النمطية إلى مزيد من التفصيل لعنونة مشاكل تجزئة الحسابات

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

(EIP-6900 تخطيطي) يسلط EIP-6900 الضوء على مشكلة سائدة في تجريد الحساب المعياري الحالي ، وهي "تجزئة" الحسابات ، أو مشكلة الجزيرة. على سبيل المثال ، في حين أن موفري وحدات تجريد الحساب المختلفين أو التطبيقات اللامركزية المختلفة قد يكونون متوافقين مع EIP-4337 ، فإن مستوى التجريد عبر الوحدات المختلفة غير كاف ، مع دقة منخفضة نسبيا. يسمح هذا السيناريو بالحرية "المفرطة" لمطوري وحدات الحساب الذكي (الحساب الذكي هو المكون الأساسي الذي يخزن معلومات المستخدم ويسجل التحقق من صحة المعاملات المخصصة ويتعامل مع منطق دفع الغاز) لإنشاء وحدات ذات سمات فريدة. نتيجة لذلك ، بمرور الوقت ، تميل مشاريع المحفظة المختلفة إلى تصميم وحدات حساب ذكية ذات خصائص مميزة. يجبر هذا الاتجاه موفري وحدات تجريد الحساب الآخرين على إعطاء الأولوية للتوافق مع موفري وحدات الحسابات الذكية المحددين ، مما يشكل تدريجيا سلاسل توريد ثابتة في المنبع والمصب. يؤدي هذا حتما إلى تجزئة وعزل النظام البيئي لوحدة تجريد الحساب (على غرار الأيام الأولى في صناعة الكمبيوتر ، حيث كان على مطوري أنظمة التشغيل التفكير في التوافق مع الأجهزة من مختلف الشركات المصنعة). لمعالجة مسألة تجزئة النظام البيئي وتعزيز التوافق بين وحدات تجريد الحساب التي طورها مختلف مقدمي الخدمات ، فإن النهج الأمثل هو زيادة تجريد حسابات محفظة العقود الذكية وتحسين دقة تجزئة الوحدة. باتباع المبادئ الموضحة في EIP-6900 ، أجرى المستند التقني للبروتوكول الأساسي الآمن تحسينات مفصلة على الحسابات الذكية (حسابات المحفظة الذكية للمستخدمين). يقسم بروتوكول Safe Core الوحدات القابلة للاستدعاء داخل كل حساب محفظة ذكية إلى فئات مختلفة مثل المكونات الإضافية والخطافات ومدققي التوقيع ومعالجات الوظائف والمزيد. تهدف وحدات الحساب الذكية إلى أن تكون خفيفة الوزن قدر الإمكان ، حيث تخزن البيانات والوظائف الأساسية فقط ، مع تفويض الوظائف المنقولة إلى "معالجات الوظائف" أو الوحدات النمطية المماثلة المجزأة. يتماشى هذا النهج مع مبدأ Occam's Razor - "لا ينبغي مضاعفة الكيانات دون داع". إذا كانت الحسابات الذكية نفسها خفيفة الوزن بما فيه الكفاية ولا تتضمن تفاصيل معقدة للغاية ، فإن الحسابات الذكية التي طورها مزودون مختلفون ستظهر هياكل داخلية أوثق وتوافقا أعلى.

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

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

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

الحل الأمثل 3: التجريب الشامل للحسابات للحسابات الموحدة عبر سلاسل مختلفة

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

(مصدر الصورة: https://vitalik.ca/general/2023/06/20/deeperdive.html)

ومع ذلك ، فإن هذا الحل يتكبد تكاليف كبيرة. عندما تتغير المفاتيح العامة المسجلة في عقد Keystore على سلسلة المصدر ، يحتاج كل حساب على L2 / السلسلة المستهدفة إلى مزامنة المفاتيح الجديدة من خلال التفاعلات عبر السلسلة. النفقات العامة للتفاعلات عبر السلسلة بين Ethereum و Layer 2 مرتفعة للغاية بحيث لا يستطيع المستخدمون تحملها. علاوة على ذلك ، من الأهمية بمكان ملاحظة أن حسابات العقود الذكية تختلف عن EOAs. هذا الأخير ، نظرا لنهجه الفريد في إنشاء العناوين ، موحد بطبيعته عبر سلاسل EVM متعددة. لكن حسابات العقود الذكية مختلفة تماما ، مما يجعل من الصعب على المستخدمين الحصول على حسابات عقود ذكية بنفس العناوين على سلاسل مختلفة. ردا على ذلك ، اقترحت شبكة الجسيمات طريقتها الخاصة. في حين أن الفكرة العامة لطريقتهم تتوافق مع مفهوم فيتاليك ، مع التركيز على فصل التخزين ورمز الحسابات الذكية ، تعتزم Particle Network استخدام سلسلة مستقلة - سلسلة شبكة الجسيمات - كقاعدة بيانات تخزين كاملة للحسابات الذكية. يخططون لمزامنة التغييرات على مساحة تخزين الحساب مع التخزين المحلي للحساب على سلاسل أخرى عبر حلول المراسلة عبر السلاسل التابعة لجهات خارجية (مثل LayerZero و CIP و Axelar و Connext وما إلى ذلك).

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

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

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

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

توافق التسلسل الزمني الشامل عبر EVM وغير EVM خطوة إضافية نحو التجريب الشامل للحساب داخل النظام البيئي لإثيريوم

على الرغم من وجود إدارة رئيسية وحسابات موحدة عبر سلاسل EVM ، لا تزال هناك مجالات للتحسين ضمن تجريد حساب omnichain. لا يمكن للسلاسل غير المتوافقة مع EVM مثل Aptos و Solana و Sui وما إلى ذلك أن تضمن توافق عناوين حسابات العقود الذكية مع تلك الموجودة في سلاسل EVM. علاوة على ذلك ، ستجد السلاسل غير EVM صعوبة في اعتماد مفهوم تجريد الحساب عبر السلسلة المقترح في المناقشة السابقة إذا لم تنفذ بروتوكول ERC-4337 بحل مكافئ. بالإضافة إلى ذلك ، هناك مجال للتحسين داخل مشاريع المحفظة المتوافقة مع EIP-4337. يتم تشغيل عقد Bundler التي تستخدمها معظم المحافظ الذكية رسميا بشكل مستقل ، وأحيانا بمعزل عن بعضها البعض ، مما يخلق مخاطر مختلفة (مثل المخاطر المتعلقة بمقاومة الرقابة وتوافرها). يثبت إنشاء واجهة أمامية موحدة تمتد عبر غالبية السلاسل أنه يمثل تحديا كبيرا. يتمثل أحد الحلول المحتملة في تقديم تصميم يركز على النية ، وإضافة طبقة إضافية فوق تجريد حساب omnichain. تتضمن هذه الطبقة النظام البيئي EIP-4337 الخاص ب Ethereum أو مرافق تجريد الحساب الأصلي للسلاسل الأخرى (على سبيل المثال ، zkSync) كحالات محددة ضمن نوع Solver / Reactor ، مع مهمة اختيار Solver المناسب كونها مسؤولية المستوى الأعلى. بأخذ شبكة الجسيمات كمثال ، فإنه يقترح تنفيذا موجزا ومجردا يركز على النوايا. مشاريع تجريد الحساب المختلفة هي مجرد حالات مدرجة في فئة Solver ضمن مخطط النية. أولا ، تقوم الواجهة الأمامية للمستخدم بتحويل طلبات اللغة الطبيعية أو أي تفاعل للمستخدم إلى أوصاف برمجية محددة تشمل قيود المدخلات والمخرجات (بمعنى آخر ، هذه هي الشروط التي تسمح بالمدخلات التي تلبي متطلبات المستخدم ونتائج المخرجات التي تقع ضمن نطاق معين). بعد ذلك ، داخل شبكة Solver ، معاملات محددة إلى الأمام Solver (s) تحتوي على قيود إدخال وإخراج دقيقة لعقود Solver المنشورة على السلسلة (لا تشمل Solvers البنية التحتية للعقدة فحسب ، بل تشمل أيضا مكونات العقد على السلسلة). ينقل عقد Solver توجيه النية إلى عقد المفاعل (إدارة حسابات المستخدمين على السلسلة) ، ويفوض الأخير للاتصال بوحدات أخرى لتحقيق التفاعل النهائي. يسمح هذا الإطار بمعالجة طلبات المستخدمين في البداية بواسطة شبكة Solver ، مما يخفف من حاجة المستخدمين إلى فهم السلاسل الأساسية أو مخططات تجريد الحساب المختلفة ، وهي مهمة مفوضة إلى Solver لإنشاء حلول محددة. ومع ذلك ، لا تزال هذه المفاهيم أطرا نظرية ، مع تفاصيل التنفيذ التي تنتظر مزيدا من التفصيل من قبل شبكة الجسيمات. من الواضح أن سوق Solver التنافسي سيظهر في المستقبل ، مما يمكن المستخدمين من بدء تقديم العطاءات حيث يقترح العديد من Solvers حلولا متميزة. من خلال معاملات المحاكاة محليا ، يمكن اختيار الحل الأمثل ويمكن توفير الحوافز المقابلة ل Solver الخاصة بهم. سيتم تشكيل هيكل الحوافز من قبل مصممي البروتوكول لشبكة Solver (تهدف Particle Network إلى استخدام رموز PNT كرموز تحفيزية لسوق مزادات Solver الخاص بها). في الوقت الحاضر ، يحمي جوهر النية التفاصيل المعقدة للطبقات السفلى وتجريد طبقة أعلى. يعد هذا التصميم متعدد الطبقات ، الذي يشبه بروتوكول TCP / IP ، ضروريا لتحسين كل من تجربة المستخدم وتجربة المطور في إمكانية التشغيل البيني السلس عبر السلاسل.

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

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

(بنية خدمة محفظة ذكية كخدمة للشبكة الجزيئية)

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

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

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

تنصل:

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