التحليل الفني: طبقة الوصول إلى شبكة الويب المفتوحة التي أنشأتها شبكة الجسيمات

مقدمة: في حين أن محافظ AA خفضت بشكل كبير حواجز دخول المستخدم وحققت مدفوعات الغاز وتسجيلات الدخول إلى حساب web2، فإن الجوانب المتعلقة بالاعتماد الجماعي، مثل تسجيل الدخول السري، والمعاملات السرية، وomnichain AA، وبروتوكول دمج الهدف، لا تزال تتطلب مزيدًا من التطوير على أساس أأ.

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

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

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

انهيار هيكل المنتج الجسيمات

تتبنى Particle Network، مع تركيزها الأساسي على تقليل حواجز الاستخدام، نهج بناء المنتجات B2B2C والتنمية البيئية، مما يوفر حلاً شاملاً لاعتماد Web3 على نطاق واسع. تتكون وحداتها الأساسية من ثلاثة مكونات رئيسية:

يشير zkWaaS إلى محفظة صفر المعرفة كخدمة. يمكن للمطورين دمج وحدات المحفظة الذكية بسرعة في تطبيقاتهم اللامركزية باستخدام Particle's SDK. المحفظة عبارة عن محفظة عقود ذكية بدون مفتاح تعتمد على تجريد الحساب، مما يتيح مدفوعات الغاز وتقدم تسجيل دخول سري عبر OAuth على نمط Web2 ومعاملات سرية.

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

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

zkWaaS - محفظة المعرفة الصفرية كخدمة

من ناحية المحفظة، توفر Particle بشكل أساسي حزم SDK لمطوري التطبيقات اللامركزية في شكل Wallet-as-a-Service (WaaS). الهدف هو تمكين المطورين من الاندماج في إطار التبني الشامل لـ Web3. يحمل نهج BtoBtoC العديد من المزايا من منظور الأعمال والنظام البيئي:

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

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

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

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

لإنشاء حل يلبي احتياجات المستخدم، ويقلل من حواجز الدخول، ويسهل تكامل المطورين، يعمل zkWaaS الخاص بـ Particle كمكون محوري مع ثلاث ميزات أساسية:

1. تسجيل الدخول السري: الاستفادة من أساليب تسجيل الدخول التقليدية إلى Web2 مثل التحقق من OAuth من منصات مثل Twitter وGoogle وWeChat وما إلى ذلك، على محفظة العقود الذكية. يتيح ذلك للمستخدمين تحرير أنفسهم تمامًا من قيود إدارة المفاتيح الخاصة، والدخول إلى Web3 بالطريقة الأكثر شيوعًا والمباشرة. وفي الوقت نفسه، يتم إخفاء هوية المستخدم باستخدام إثباتات المعرفة الصفرية.

2. المعاملات السرية: تنفيذ عمليات نقل الخصوصية من نقطة إلى نقطة من خلال آلية Smart Stealth Address، مما يضمن الخصوصية العالمية في المعاملات. بالإضافة إلى ذلك، فإن استخدام Paymaster الخاص بـ ERC-4337 يتيح الاستخدام بدون غاز للأصول لعناوين التخفي الذكية (رعاية الغاز).

3. وظائف محفظة AA الشاملة: تتوافق وحدة محفظة Particle تمامًا مع المتطلبات الأساسية لـ ERC-4337. يتضمن مكونات أساسية مثل Bundler وEntryPoint وPaymaster وSmart Wallet Account والمزيد، مما يغطي جميع الجوانب المهمة لسير عمل ERC-4337. يلبي هذا الحل الشامل بشكل فعال المتطلبات الوظيفية للتطبيقات اللامركزية أو مستخدمي المحافظ الذكية.

تسجيل الدخول السري للمحافظ الموجودة على السلسلة بناءً على حسابات Web2

يستخدم حل تسجيل الدخول السري الخاص بـ Particle رموز JSON Web Tokens (JWT)، مما يتيح مصادقة هوية Web2 وعمليات المحفظة ضمن العقد الذكي.

JWT هو نموذج يستخدم على نطاق واسع لإثبات الهوية في تطبيقات الإنترنت التقليدية، يصدره الخادم إلى العميل. يستخدم العميل هذا الدليل لمصادقة الهوية في كل تفاعل مع الخادم.

(المصدر: مستندات FlutterFlow)

هناك العديد من الحقول الرئيسية في JWT والتي تعتبر أساس التحقق من الهوية من خلال العقد:

· يشير "iss" (المصدر) إلى جهة إصدار JWT، أي الخادم، مثل Google وTwitter وما إلى ذلك.

· "aud" (الجمهور): يحدد الخدمة أو التطبيق الذي تم تصميم JWT له. على سبيل المثال، عند تسجيل الدخول إلى Medium باستخدام Twitter، سيتضمن JWT الصادر عن Twitter هذا الحقل الذي يشير إلى إمكانية تطبيقه على Medium.

·"sub" (الموضوع): يشير إلى هوية المستخدم الذي يتلقى JWT، والتي يتم تحديدها عادةً بواسطة UID.

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

يتوافق JWT مع مفهوم JSON Web Key (JWK)، وهو عبارة عن مجموعة من أزواج المفاتيح الموجودة على الخادم. عند إصدار JWT، يقوم الخادم بتوقيعه باستخدام المفتاح الخاص لـ JWK، بينما يصبح المفتاح العام المقابل عامًا للخدمات الأخرى للتحقق من التوقيع.

على سبيل المثال، عندما يستخدم Medium تويتر لتسجيل الدخول، سيتحقق Medium من صحة JWT باستخدام JWK العام من Google للتأكد من صحته - أنه تم إصداره بالفعل بواسطة Google. سيتضمن التحقق من العقد لـ JWT أيضًا استخدام JWK.

يتم توضيح عملية حل تسجيل الدخول السري لـ Particle في الرسم البياني أدناه:

سوف نتخطى دائرة ZK المحددة هنا، ونسلط الضوء فقط على بعض النقاط الرئيسية في العملية:

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

eph_pk (زوج المفاتيح المؤقت) هو زوج مفاتيح يُستخدم في جلسة واحدة وليس زوج المفاتيح العام والخاص للمحفظة. لا يحتاج المستخدمون إلى الاهتمام به.

يدعم هذا النظام التحقق خارج السلسلة ويمكن استخدامه للمحافظ التعاقدية التي تستخدم منطقًا مثل MPC (الحوسبة متعددة الأطراف).

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

المعاملات السرية بناءً على تبادل مفاتيح DH

قبل مناقشة المعاملات السرية لـ Particle، دعنا نتفحص كيفية تحقيق المعاملات السرية للمستلم ضمن نظام EVM الحالي، وتحديدًا إخفاء عنوان المستلم.

بافتراض أن أليس هي المرسل وبوب هو المتلقي، فإن كلا الطرفين يتشاركان في بعض المعرفة المشتركة:

1. يقوم Bob بإنشاء مفتاح الإنفاق الجذري (m) والعنوان التعريفي الخفي (M). يمكن توليد M بواسطة m، ويتم تمثيل العلاقة بينهما بـ M = G * m، مما يشير إلى وجود علاقة رياضية في عمليات التشفير.

2. تحصل أليس على العنوان التعريفي الخفي لبوب M بأي وسيلة.

3. تقوم أليس بإنشاء مفتاح خاص سريع الزوال (r) وتستخدم الخوارزمية generator_address(r, M) لإنشاء عنوان خفي (A). يعمل هذا العنوان كعنوان خفي مخصص تم إعداده لـ Bob، حيث يكتسب Bob السيطرة بمجرد استلام الأصول.

4. تقوم أليس بإنشاء مفتاح عمومي سريع الزوال (R) استنادًا إلى المفتاح الخاص سريع الزوال r وترسله إلى عقد تسجيل المفتاح العمومي سريع الزوال (أو أي موقع متفق عليه بشكل متبادل يمكن لبوب الوصول إليه).

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

6. يقوم بوب بمسح كل سجل محدث، وتنفيذ generator_address(R, m) لحساب عنوان التخفي. إذا كانت هناك أصول في هذا العنوان، فهذا يعني أن أليس قد أنشأتها وأذنت بها لتحكم بوب؛ وإلا فإنه لا علاقة له ببوب.

7. ينفذ بوب generator_spending_key(R, m) لإنشاء مفتاح الإنفاق لعنوان التخفي هذا، أي p = m + hash(A). بعد ذلك، يستطيع بوب التحكم في العنوان A الذي تم إنشاؤه بواسطة Alice.

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

تشبه عملية التبادل هذه إلى حد ما طريقة تبادل مفاتيح Diffie-Hellman المعروفة. بدون الكشف عن أسرارهما (مفتاح الإنفاق الجذري لبوب (m) ومفتاح أليس الخاص المؤقت (r)))، يمكن لكلا الطرفين حساب سر مشترك - العنوان الخفي (A) المذكور سابقًا. إذا لم تكن على دراية بتبادل DH، فيمكن تسهيل الفهم المجازي باستخدام الرسم البياني أدناه.

الخطوة المضافة مقارنة بـ DH هي أنه بعد حساب السر المشترك - عنوان التخفي (A)، لا يمكن استخدامه كمفتاح خاص مباشرة لأن أليس تعرف أيضًا A. من الضروري إنشاء مفتاح الإنفاق (p = m + hash) (أ)) التعامل مع A كمفتاح عام. كما ذكرنا سابقًا، وحده بوب يعرف مفتاح إنفاق الجذر (m)، مما يجعل بوب هو المتحكم الوحيد في هذا العنوان المخفي.

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

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

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

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

يمكننا الإشارة إلى العنوان المضاد المذكور أعلاه كعنوان خفي ذكي. يستخدم بوب الأصول بشكل مجهول ضمن عنوان التخفي الذكي هذا من خلال العملية التالية:

· قم بإيداع Paymaster من أي من عناوينه، وسوف يقوم Paymaster بإرجاع إثبات للصندوق (معتمد على ZK).

· باستخدام آلية AA، استخدم أي عنوان آخر، والذي قد لا يحتوي على رصيد، لإرسال UserOperation إلى عقدة Bundler، واستدعاء الأصول الموجودة تحت عنوان التخفي المذكور. يحتاج بوب فقط إلى تقديم إثبات مالي إلى Paymaster باستخدام عنوان جديد، ويدفع Paymaster للمجمع مقابل تغليف المعاملة.

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

باختصار، يجمع Particle بين AA والعناوين الخفية بذكاء، مما يحقق تحويلات سرية من خلال شكل محافظ خفية ذكية.

تجريد سلسلة الجسيمات وحساب Omnichain

Particle Chain عبارة عن سلسلة POS مصممة لتجريد حساب Omnichain. وبالنظر إلى الحاضر والمستقبل، فإن هيمنة السلسلة الواحدة غير محتملة. يعد تحسين تجربة المستخدم في سيناريو متعدد السلاسل أمرًا بالغ الأهمية.

حاليًا، قد يواجه نظام تجريد حساب ERC4337 مشكلات معينة في حالة متعددة السلاسل:

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

يعالج تجريد حساب Omnichain الخاص بـ Particle Chain نقاط الألم المذكورة أعلاه:

• إنشاء محافظ AA على Particle Chain.
• استخدم LayerZero والبروتوكولات عبر السلسلة الأخرى لجسر الرسائل العشوائية (AMB) لمزامنة العمليات المختلفة، مثل إنشاء الأذونات وترقيتها وتغييرها، مع سلاسل أخرى. يمكن فهمها على أنها محافظ على سلاسل أخرى تشير إلى المحفظة الموجودة في تلك السلسلة، مع مزامنة التعديلات على الجسم الرئيسي مع جميع المحافظ.
• تأكد من وجود عناوين موحدة للمحافظ في كل سلسلة من خلال عقد النشر للمعلمة المتسقة.
• يمكن للمحافظ الموجودة في سلاسل مختلفة أيضًا الاتصال ببعضها البعض من خلال AMB، وليس بالضرورة أن يتم البدء بها من Particle Chain.
• إصدار رمز الغاز الموحد. تطبق آلية Paymaster ERC20 كرسوم للغاز. حتى في السلسلة التي لا تحتوي على غاز أو أموال مخزنة مسبقًا في Paymaster، يمكن بدء المعاملات عبر السلسلة التي تستهلك رموز الغاز الموحدة على السلاسل المتوافقة.

بالإضافة إلى حالات الاستخدام المذكورة أعلاه، يمكن أيضًا استخدام سلسلة الجسيمات من أجل:

• الشبكة اللامركزية لإثباتات zkWaaS وتوليد الملح.
• طبقات حوافز لأصحاب الحزم عبر السلاسل المختلفة، مما يساعدهم على تحقيق قدر أكبر من اللامركزية.
• بمثابة شبكة حل لبروتوكول Intent Fusion.

في سرد سلسلة الجسيمات، يعمل رمز الغاز الموحد بمثابة عرض القيمة الأساسية للنظام البيئي بأكمله:

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

بروتوكول الانصهار النية

عادةً، عند استخدام تطبيقات dApps المختلفة، يحتاج المستخدمون دائمًا إلى مراعاة مسارات الاستخدام:

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

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

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

وبالمثل، يتطلب استخدام النوايا دعمًا من سلسلة من المرافق. دعونا نفحص العملية برمتها:

1. يرسل المستخدمون نواياهم، ويصفونها بطريقة ما، مثل اللغة الطبيعية، في شكل RFS (طلب Solver)، الذي يتم إرساله إلى شبكة Solver. يعد Solver بمثابة مترجم للمقاصد، وحلول شائعة مثل 1inch، وهو مجمع، يبحث عن DEX الأمثل للمستخدمين. ومع ذلك، فإن هذه الحلول، بالمقارنة برؤيتنا، قد لا تكون متعددة الاستخدامات وقوية بما فيه الكفاية.

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

3. التوقيع على النية.

4. يحدد Solver جهة تنفيذ محددة لعقد التنفيذ ويرسل النية إلى مفاعل عقد الاستجابة.

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

يمكننا تصور هذه العملية كما لو كنت تشرح متطلباتك لـ ChatGPT. بغض النظر عن مدى تعقيد المتطلبات، يمكن أن تولد لك نتيجة نهائية. طالما أنك راضٍ عن النتيجة، يمكنك استخدامها مباشرة دون الاهتمام بالعملية الأساسية.

خاتمة

اقترحت Particle Network حلاً شاملاً: من خلال النموذج المتكامل لـ zkWaaS وParticle Chain وIntent Fusion Protocol، فإنها تحقق تسجيل دخول خصوصية Web2 OAuth، ومعاملات الخصوصية، وتجريد حساب omnichain، ونموذج المعاملات القائم على النية. تتناول كل ميزة جزءًا من نقاط الألم في استخدام Web3. ستكون هذه التطورات والتحسينات بمثابة الأساس للاعتماد المستقبلي الواسع النطاق لمنتجات وتقنيات Web3. فيما يتعلق بالنظام البيئي ونماذج الأعمال، اعتماد نموذج B2B2C، واستخدام WaaS كنقطة دخول لدفع قابلية التوسع وتوحيد سلسلة المنتجات بأكملها، والمشاركة في بناء النظام البيئي مع مطوري التطبيقات اللامركزية، وإنشاء Web3 منخفض العتبة وعالي الخبرة بشكل مشترك العالم للمستخدمين.

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

تنصل:

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