Coinbase: الوضع الحالي لمحافظ الحسابات الذكية

ستعتمد التكاليف الاقتصادية على موقع المورد - على الرغم من أنه بشكل عام، فإن المستخدم هو الذي يدفع تكلفة الغاز الخاصة بـ UserOps ( يتم جمع/بث رسوم الغاز إلى المحزم)، ويمكن لجهة صرف الرواتب رعاية الغاز في حدود ميزانية العميل. وفيما يلي بعض الأمثلة على نماذج الأعمال اليوم:

• النسبة المئوية للرسوم: يدفع المستخدم رسوم الغاز في UserOp — يتولى Bundler العملية ويجمع الرسوم

• < strong>SaaSالحزمة: ستفرض الشركة على فريق التطوير "رسوم منتج" إجمالية في نهاية الشهر بناءً على نسبة مئوية من كل استدعاء Bundler API بالإضافة إلى رعاية الغاز مقدما.

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

2، اعتماد الحساب الذكي

(1)ما هو استخدام AA بالضبط؟ كيف تم اعتماده؟

• الغازالرعاية:يُمكّن هذا النموذج المشاركين في الشبكة بخلاف المستخدمين النهائيين من دفع ثمن الغاز. قد تكون رسوم معاملات الحساب الذكي أعلى قليلاً من معاملات المحفظة المُدارة ذاتيًا، ولكن يمكن دعمها من قبل أطراف ثالثة. يمكن دفع تكاليف معاملات المستخدم (مثل أموال تسجيل الدخول/الجسر) من قبل أصحاب المصلحة المهتمين.

• معاملة بنقرة واحدة:يمكن للمستخدمين استخدام مفاتيح الجلسة "لتسجيل الدخول مرة واحدة" (بدلاً من إذن التوقيع المتعدد)، ومكالمات متعددة لمعاملة واحدة من خلال المعالجة المجمعة، وتدعم أنظمة التوقيع المختلفة أجهزة مختلفة "لتوقيع" المعاملات من خلال منطق التحقق التعسفي (على عكس المحافظ التي تدعم توقيعات ECDSA فقط).

• مفتاح المرور:استخدم SCW ومفتاح المرور (على أجهزة Apple أو Google أعلاه) يمكنه توقيع المعاملات للمستخدمين. يستفيد المستخدمون من نموذج أمان Apple (على سبيل المثال، القياسات الحيوية، والمصادقة الفعلية الخاصة بالجهاز).

(2)< ما هو الوضع الحالي للاعتماد القوي>AA؟

• إجمالي الحساب الحجم: 3.2 مليون، إجمالي UserOps: 12.7 مليون، إجمالي رسوم الغاز لمسؤول الدفع: 1.7 مليون دولار أمريكي

إجمالي عدد الحسابات يشير إلى إنشاء عدد SCWs المتوافقة مع AA - يمكن إنشاؤها تلقائيًا في واجهة المحفظة أو بشكل غير مباشر من خلال تطبيقات الشركاء. إجمالي UserOps هو عدد المعاملات التي تدعمها AA. إجمالي رسوم الغاز لدى Paymaster هو إجمالي رسوم الغاز التي يدفعها طرف ثالث.

• المطورين الكبار (مثل Alchemy) ، ThirdWeb، Circle) والشركات الناشئة الناشئة في دخول مجال AA.

(3) ما الذي يمنعAA التنمية؟

• تحليل التكلفة والفائدة:

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

التكلفة المتعلقة بخيارات النطاق الحالية: الممارسة الشائعة بين المستهلكين اليوم هي استخدام المحافظ المُدارة ذاتيًا أو محافظ MPC - إنشاء المحفظة مجاني ويقوم المستخدم بالإرسال والتوقيع المعاملات، ولكن المستخدمين يدفعون رسوم الغاز لكل معاملة. بالنسبة لـ SCW، يكون التفاعل عبر AA (عبر Bundler) أبطأ (بالمناسبة، أبطأ من 2 إلى 5 ثوانٍ)، كما تعد تكلفة النشر على نطاق واسع عاملًا مقيدًا آخر.

توضح البيانات القصصية أنه في L2 (مثل Base)، تبلغ التكلفة لكل حساب حوالي 0.15-0.45 دولارًا أمريكيًا. لذا، بالنسبة لتطبيق لامركزي يضم مليون مستخدم، قد يتراوح هذا المبلغ بين 150 ألف دولار و450 ألف دولار (يكلف كل حساب حوالي 7 إلى 10 دولارات على شبكة ETH الرئيسية). قد تنخفض هذه التكاليف مع وصول خطط EIP المستقبلية (4844).

• مفتاح المرور

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

  • "الدجاج والبيض”البداية الباردة:

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

  • المطور

    strong>/تعليم المنتج:

  الخطوات الأولى لـ 4337 المناقشة يعد أمرًا تقنيًا للغاية، ويحتاج تسويق SCW/AA إلى الاستفادة من منظور تجربة المنتج/المستخدم. توجد بالفعل بعض المحافظ المدعومة من AA والتي يمكنها الاتصال بأي تطبيق dapp، مما يتماشى مع محافظ MPC الحالية والمستضافة ذاتيًا. نأمل أنه بمرور الوقت، ستضيف المحافظ المستضافة ذاتيًا المزيد من الدعم لـ SCW.

  3تأثير النظام البيئي للحسابات الذكية

  (1)AAيتزايد معدل التبني، ولكن لم يتم تحقيق قصص نجاح مذهلة بعد . إن التوافق مع سوق المنتجات بدأ يتشكل.

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

  • أكبر عقبة أمام اعتماد SCW هي تكلفة الغاز (على ETH L1). مع L2، تم تخفيض التكاليف بشكل كبير، وتكاليف معاملات SCW أقل بكثير، لكن تكاليف المعاملات واسعة النطاق لا تزال مرتفعة.

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

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

  • ستفيد اتجاهات التكنولوجيا مثل Passkey في اعتماد الحسابات الذكية. يعد مفتاح المرور (أي يقوم FaceID بإنشاء محفظة + علامات المعاملات) بمثابة تعزيز إضافي لتجربة المستخدم للمستهلك.

  • نحن نتطلع إلى استكشاف الحسابات الذكية من خلال محافظ ذاتية الحفظ.

  نتوقع أنه عندما تنخفض التكاليف (EIP-7212, EIP-4844) وتتحرك الصناعة نحو معايير مفتوحة المصدر (نسبية سيتم تحقيق ملاءمة المنتج للسوق أخيرًا عندما تظهر دراسات حالة لبرامج دعم الغاز الناجحة ويكون لدى مطوري التطبيقات اللامركزية الرغبة والميزانية لدفع تكاليف اكتساب المستخدمين.

  (2)AA< قوي>السماح للمطورين بمحاولة الحصول على رعاية العملاء (المستخدم الجديد).

  مع ظهور L2، تم حل الخطوة الأولى من تجربة المستخدم - تم تحسين تكاليف المعاملات/الغاز بشكل كبير. والخطوة التالية هي أن يقوم المطورون بتمكين AA، حيث يريد المستخدمون الآن معاملات سلسة.

  الفكرة هي أنه بمجرد قيام المستخدم بتسجيل الدخول إلى التطبيق، فإنه يستخدم التطبيق ويبدأ في تمكين مفهوم القيمة الدائمة (LTV). طالما أن LTV أكبر من CAC (تكلفة اكتساب العملاء)، فمن المفيد للمطورين استكشاف CAC المدعومة من AA (مثل رعاية الغاز). يمكن لأي صاحب مصلحة يرغب في رعاية المعاملات عبر السلسلة القيام بذلك (سواء L2 أو dapp).

  Dapp POV: بفضل محفظة MPC المضمنة، تم تحسين العوائق التي تحول دون اكتساب المستخدمين من 0 إلى 1 بشكل كبير. يجب أن تساعد AA في بناء الجسر إلى "المعاملة الأولى على السلسلة" وتحقيق تجربة تسجيل دخول فورية في النهاية (لا توجد تكلفة وقود لمعاملات X الأولى، ولا توجد تجربة مستخدم "لكل نقرة"، ولا يلزم إعداد المحفظة). أحد الأمثلة المبكرة هو مفهوم مثل "تسجيل الدخول الموجه للأصول" - سيوفر التطبيق اللامركزي للمستخدم حسابًا ذكيًا ورعاية الغاز/الغبار لأول 5 معاملات، لأن التطبيق اللامركزي يعلم أنه سيحقق التعادل في الاستثمار من خلال الاستجابة للمعاملة السادسة معدل.

  (3)AA< strong>إنها لعبة ميزة المتحرك الأول، والفروق الفنية ليست هي الاختلافات الوحيدة، ولكن يجب النظر إلى الاختلافات من منظور حالة الاستخدامGTM/.

  نظرًا لأن التكوينات الفنية كلها مفتوحة المصدر، فلا يوجد فرق فني كبير في الحسابات الذكية (Paymaster، Bundler، SCW). الفرق هو أننا نقرر كيفية توجيه المعاملة. على سبيل المثال، بما أنه لا يمكن أن يكون هناك سوى صراف صرف واحد لكل معاملة، فإن الأمر متروك لمنسق المعاملة لاتخاذ القرار.

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

  بالإضافة إلى تحديد موضع المنتج، فإن الصيغة الفائزة هي تحديد قصة "CAC" لكيفية إنشاء حسابات ذكية. قد تكون نقطة بيع "الحساب الذكي" هي عرض قصة LTV/CAC - "ينفق المستخدمون سنتًا واحدًا لكل معاملة، لكن التطبيق اللامركزي الخاص بك سيحصل على 3 دولارات لكل معاملة." على سبيل المثال، إذا تم إنشاء تطبيق لامركزي باستخدام حساب ذكي، يمكن للمستخدمين الجدد إجراء المعاملات على الفور (بدون مفاتيح، بدون غاز)، وتكون التكاليف المرتبطة بـ SCW (عمليات النشر، واستدعاءات الوظائف، وما إلى ذلك) أعلى، ولكن سيتم تعويض ذلك وتجاوزه من خلال القيمة الدائمة المجمعة للمستخدمين الجدد.

  (4)AA< strong>قد يكون من المفيد ربط"كلتطبيقمحفظة"< الروايات الشائعة المتعلقة بـ /strong>و"Web3الصفحة الرئيسية" .

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

  تشير الاتجاهات الحديثة بين مستهلكي web3 إلى اتجاه "محفظة واحدة لكل dapp" مدعومة بمحافظ MPC. سيقوم المستخدم بتنزيل تطبيق جوال ويتم توفير المفتاح واستخدامه فقط داخل هذا التطبيق اللامركزي. إذا كان المستخدم يستخدم نفس موفر المحفظة المضمنة (في الخلفية) عبر تطبيقات لامركزية متعددة، فإن موفر المحفظة المضمن هذا قادر على ربط المحافظ "خارج السلسلة" بناءً على معرفات البيانات الشائعة ودمجها في واجهة واحدة. على سبيل المثال، يمكن للمستخدمين الذين يقومون بتسجيل الدخول بنفس البريد الإلكتروني في تطبيقات لامركزية متعددة رؤية المحافظ في هذه التطبيقات اللامركزية بشكل موحد.

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

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

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

  ومع ذلك، قد تكون محافظ AA هي الأنسب لحالات استخدام الشبكة الفردية. بالنسبة للتطبيقات اللامركزية التي تسمح بشبكات متعددة، فإن متاعب الاضطرار إلى التعامل مع SCW المنتشرة على شبكات متعددة قد لا تستحق العناء. اليوم، يركز تطوير AA واعتماده بشكل أساسي على EVM، لكن الشبكات الأخرى (مثل Solana) تستثمر أيضًا في اعتماد AA (مثل Squads Protocol).

  (5) لا تزال الحسابات الذكية في مراحلها الأولى، ولكنها في مرحلة النضج.

  تم وضع أجزاء البنية الأساسية للحساب الذكي، ولكن توقيت السوق يظل عاملاً مهمًا.

  بدأ تنفيذ التقييس (ERC-4337) فقط في بداية هذا العام، ولم يبدأ L2 في جذب الاهتمام إلا في الربع الثاني من عام 2023.

  بدأت المحافظ ذاتية الاستضافة مثل Coinbase Wallet وTrust Wallet في تقديم منتجات الحسابات الذكية.

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

  لا يزال مفتاح المرور بحاجة إلى النضج والتحسين قبل نشره في الحسابات الذكية.

  (6)يتم تعزيز المعايير من خلال ضمان اتساق النظام البيئي AAيلعب دورًا كبيرًا في التبني.

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

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