بأخذ شبكة الجسيمات كمثال ، تفسر التكنولوجيا مشاكل تجربة منتجات Web3 الحالية

المؤلف: Wuyue ، المهوس Web3

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

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

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

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

**هيكل منتج الجسيمات الحل الكامل **

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

** zkWaaS ، خدمة المحفظة كخدمة (WaaS) تستند إلى إثباتات المعرفة الصفرية. ** يمكن للمطورين دمج وحدة المحفظة الذكية بسرعة في dApp الخاص بهم بناء على SDK الذي توفره Particle. المحفظة عبارة عن محفظة عقود ذكية بدون مفتاح تعتمد على تجريد الحساب ، والتي لا يمكنها فقط تحقيق سيناريوهات AA الأساسية مثل دفع الغاز ، ولكنها توفر أيضا طرق تسجيل الدخول إلى خصوصية OAuth على غرار Web2 والمعاملات الخاصة والوظائف الأخرى.

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

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

zkWaaS - المحفظة الذكية كخدمة مدمجة مع ZK

على جانب المحفظة ، يوفر Particle بشكل أساسي حزم SDK لمطوري dApp في شكل WaaS (محفظة العقد الذكي كخدمة) ، من أجل السماح للمطورين بالوصول إلى إطار خيار Web3 الشامل الكامل. يتميز حل BtoBtoC هذا بالعديد من المزايا من وجهة نظر تجارية وبيئية:

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

** تكلفة اكتساب العملاء مرتفعة على الجانب C ، لكنها مختلفة على الجانب B. ** نمو مستخدمي WaaS مدفوع بشكل أساسي ب dApps المدمجة مع SDKs. طالما أن العلاقة بين BD والمطورين جيدة ، يمكن توسيع النظام البيئي بأكمله بأسلوب “المدينة المحيطة بالريف”.

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

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

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

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

2. معاملات الخصوصية. ** تنفيذ عمليات النقل الخاصة العالمية من نظير إلى نظير من خلال آلية Smart Stealth Address ، واستخدام ERC4337 Paymaster للسماح ل Stealth Address باستخدام الأصول (رعاة الغاز) بدون غاز.

**3. أكمل وظيفة محفظة AA. ** تتوافق وحدة محفظة Particle تماما مع المتطلبات الأساسية ل ERC-4337 ، بما في ذلك Bundler و EntryPoint و Paymaster وحساب المحفظة الذكية وأجزاء مهمة أخرى من سير عمل ERC-4337 ، وقفة واحدة لتلبية المتطلبات الوظيفية ل DAPP أو المستخدمين للمحافظ الذكية.

تسجيل الدخول إلى خصوصية المحفظة على السلسلة بناء على حسابات web2

يستخدم حل تسجيل الدخول الخاص ب Particle JWT (Json Web Token) ، والذي يمكن استخدامه لمصادقة هوية Web2 وتشغيل المحفظة ضمن العقد.

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

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

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

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

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

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

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

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

يظهر تدفق حل تسجيل الدخول الخاص ب Particle في الشكل التالي:

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

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

Eph \ _pk (زوج مفاتيح سريع الزوال) هو زوج مفاتيح يستخدم في جلسة واحدة ، وليس المفتاح العام أو الخاص للمحفظة ، ولا يحتاج المستخدم إلى الاهتمام.

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

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

المعاملات الخاصة على أساس طريقة تبادل مفاتيح DH

قبل الحديث عن حل المعاملات الخاصة من Particle ، دعنا أولا نفحص كيفية تحقيق المعاملات الخاصة ل ** المستلم ** داخل نظام EVM الحالي ، أي إخفاء عنوان المستلم.

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

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

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

3. تنشئ أليس مفتاحا خاصا مؤقتا r ، وتستخدم generate_address الخوارزمي (r ، M) لإنشاء عنوان مخفي A. ** هذا العنوان هو عنوان Bob الحصري **** ، ويتحكم Bob في العنوان بعد استلام الأصول. **

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

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

6. يقوم بوب بمسح كل سجل محدث وإجراء generate_address (R ، m) لحساب العنوان المنقح. إذا كان هناك أصل في العنوان ، يتم إنشاؤه بواسطة Alice والمصرح له بالتحكم فيه من قبل Bob ، وإلا فلن يكون له علاقة ب Bob.

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

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

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

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

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

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

احسب عنوانا مخالفا للواقع باستخدام طريقة حساب العنوان في طريقة CREATE2 عند نشر العقد ، مع المعلمات المقابلة (تعيين عنوان التخفي A كمالك للعقد ، وما إلى ذلك). هذا عنوان عقد محسوب ، لكن العقد لم يتم نشره بعد ، ولا يزال EOA في الوقت الحالي.

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

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

أعد شحن Paymaster من خلال أي من عناوينك الخاصة ، وسيقوم Paymaster بإرجاع إثبات الأموال (ZK).

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

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

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

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

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

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

قد لا يكون عنوان المستخدم نفسه في سلاسل مختلفة موحدا ، اعتمادا على تصميم العقد.

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

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

** يعالج تجريد حساب السلسلة الكاملة لسلسلة الجسيمات نقاط الألم المذكورة أعلاه: **

بناء محفظة AA على سلسلة الجسيمات.

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

** عقد الموزع مع معلمات متسقة لضمان أن عنوان المحفظة في كل سلسلة هو نفسه. **

يمكن للمحافظ بين السلاسل أيضا الاتصال ببعضها البعض من خلال AMB ، ولا يتم تشغيلها جميعا من سلسلة الجسيمات.

** إصدار رمز الغاز الموحد ، عملة غاز كاملة السلسلة. ** يتم تنفيذ ERC20 بواسطة آلية Paymaster كرسوم غاز. حتى إذا لم يكن هناك غاز أو أموال Paymaster مودعة مسبقا على سلسلة معينة ، يمكنك بدء معاملة عبر السلسلة على سلسلة مؤهلة لاستهلاك رمز الغاز الموحد.

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

شبكة لامركزية تم إنشاؤها بواسطة دليل zkWaaS والملح.

تساعد طبقة الحوافز لكل سلسلة Bundler Bundler على تحقيق لامركزية أفضل.

شبكة Solver كبروتوكول دمج النوايا.

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

وظيفة دفع رسوم الغاز هي طلب قوي ومنطق التقاط القيمة الذي تم التحقق منه مرارا وتكرارا في العملات المشفرة.

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

الغاز الموحد هو أيضا أحد العوامل الدافعة لتحقيق Chainless. بالنسبة للمستخدمين ، فإن الدفع بعملة واحدة يبسط العملية وفهم التكاليف إلى حد كبير. في المستقبل ، حتى في السيناريو متعدد السلاسل ، من المحتمل أن يكون المستخدمون غير حساسين ، ولا يحتاجون إلى الاهتمام بتشغيل البنية التحتية الأساسية. تماما كما هو الحال حاليا في Web2 ، لا نهتم بالمنطقة التي تقع فيها غرفة الكمبيوتر ، والتكوين ، واللغة المستخدمة ، وقاعدة البيانات التي تعمل.

يقوم المستخدمون الذين تم استيرادهم بواسطة dApp بتمكين رمز الغاز الموحد مباشرة ، وسيناريوهات الاستخدام غنية جدا.

بروتوكول الانصهار المتعمد

** عادة ، نحتاج إلى التفكير باستمرار في مسار الاستخدام عند استخدام dApps المختلفة: **

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

لا أعرف أي dApp من نفس الفئة يجب أن يختار لإكمال المعاملة أو المعاملة بشكل أفضل.

· الموافقة إذن لديها الكثير من الميزات لاستخدامها ، وما هي الموافقة؟

غبار المحفظة ، العديد من الرموز الصغيرة إلى عملة معينة ، العملية مرهقة.

من أجل تحقيق الهدف النهائي ، يتطلب الأمر تطبيقات متعددة. مثل الإقراض عالي الرافعة المالية: المبادلة ، التعهد ، الاقتراض ، الحصول على الرمز المميز ثم المبادلة ، التعهد ، الاقتراض …

ما سبق هو مجرد غيض من فيض في عالمنا الحالي DeFi ، وفي عصر التبني الجماعي ل Web3 حيث أصبحت dApps أكثر تنوعا ، يمكن أن تكون التفاعلات أكثر تعقيدا مما تعتقد.

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

ثم استخدام النوايا ليست استثناء ، وتحتاج أيضا إلى دعمها من قبل مجموعة من المرافق. دعونا نلقي نظرة على العملية برمتها:

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

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

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

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

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

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

ملخص

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

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