البنية التحتية للمحفظة: تمكين الجيل القادم من التطبيقات اللامركزية
البنية التحتية للمحفظة تلعب دوراً حاسماً في فتح تجربة الويب3 لجيل التطبيقات اللامركزية القادم.
حتى الآن، كان على المستخدمين تثبيت برامج إضافية ومصادرها وتمويلها بعملة جديدة، ومواجهة شاشات تأكيد غير مألوفة قبل أن يقوموا حتى بأول تفاعل في web3. على الرغم من تحسين جدار الحماية والانتقال بعيدًا عن عبارات البذور، هذه العقبات لا تزال نقاط تحول عالية لتطبيقات اللامركزية.
كانت البيئة مهيأة للابتكارات التي تجرد الطبقات التقنية بعيدًا، مما يمكن من الانضمام بشكل بديهي إلى تجارب مالية واجتماعية ولعب دون المساس بالوجدان الأصلي للحفظ الذاتي واللامركزية.
2023 كان عامًا حاسمًا لنظام المحفظة، مع التجريد من الحساب والتطورات عبر جميع طبقات الشبكة مما يغير هياكل السوق ويغير كيفية تفكيرنا في العلاقة بين المستخدمين والتطبيقات اللامركزية والمحافظ.
تجريد الحساب: ماذا، ولماذا، وكيف
يمكننا التفكير في التجريد الحسابي كفصل إدارة الحساب عن إدارة المفتاح. الحساب هو كيان على سلسلة الكتل يمكنه الاحتفاظ بالأصول ويملك تاريخ المعاملات. الموقعون (المفاتيح) هم الكيانات التي لديها السلطة للقيام بإجراءات نيابة عن الحسابات.
مع الحسابات التقليدية (EOAs)، تحتفظ المفتاح الخاص بالسيطرة الكاملة والحصرية على حسابه المرتبط. الربط الصارم بنسبة 1 إلى 1 بين المفتاح الخاص والحساب يعني أن:
يتم تقييد المستخدمين باستخدام حلول إدارة المفاتيح المخصصة (على سبيل المثال Metamask, Ledger) عند التفاعل مع تقنية البلوكشين.
لا يوجد طريق للاسترداد من فقدان مفتاح خاص، ولا يمكن استبدال المفتاح الذي يتحكم في حساب.
يتم التعامل مع جميع الإجراءات التي أنشأها هذا المفتاح الخاص على قدم المساواة ، من سك NFT مجاني إلى نقل ملايين الدولارات.
تجعل تجريب الحساب الحساب عقد ذكي مع منطقه الديناميكي لما يمكن أن تنفذه المفاتيح على حسابه، ونطاق الأذونات، وتنفذ فحوصات ورصيد إضافية وفقًا لحالة الاستخدام.
يمكننا تقسيم فوائدها بشكل أكبر من خلال فحص ما يتم تجريده.
لأن بروتوكول Ethereum يعترف فقط بالمعاملات التي جاءت من EOA، فإن التجريد الحسابي يتطلب بنية خارج السلسلة لنقل المعاملات التي جاءت من العقود الذكية إلى السلسلة.
تم تقديم ERC-4337 في عام 2021 كطريقة موحدة للقيام بذلك دون تغييرات في البروتوكول الأساسي. ومع ذلك، كان بعض المشاريع قد قدمت فوائد AA قبل أن يتم تطوير المعيار بشكل كامل.
تم إطلاق محفظة متعددة التوقيع الآمنة في عام 2017 وقد نمت لتأمين قيمة تزيد عن 50 مليار دولار من الأصول للمنظمات اللائحة ذاتيًا، والشركات، والأفراد على حد سواء
تم تشغيل محفظة Argent على الهواتف النقالة بواسطة حسابات العقود الذكية منذ عام 2018
محفظة التسلسل، التي تم إطلاقها في عام 2021، سمحت لـ Skyweaver بإنشاء حساباتهم الذكية وتسجيل الدخول إليها باستخدام بريدهم الإلكتروني ودفع الرسوم باستخدام رموز غير أصلية
كان ذلك يتطلب بناء وصيانة بنية توجيه مخصصة من قبل المشروع المعني.
أدخل ERC-4337. يقدم المعيار بديلًا للطبقة البديلة للتوجيه المركزي والمقاوم للرقابة، ويحدد واجهة لحسابات، ومدفوعات، ومجمعي التوقيع للتفاعل مع الموجهين من الطرف الثالث عبر حوض ذاكرة مشترك بديل للعمليات النقدية المجردة عن الحسابات ("عمليات المستخدم").
يقوم الموجهون (المجمعون) بتجميع عمليات المستخدم المتعددة معًا في عملية لإرسالها إلى عقد نقطة الدخول الفردية، الذي بدوره يتحقق من أن الرسوم ستُدفع (بواسطة الحساب نفسه أو من خلال الجهات المدفوعة)، وينفذ عمليات المستخدم المتعلقة بالحسابات الذكية.
يمكننا التباين في هذا مع كيفية حدوث التحقق والتنفيذ على السلاسل التي تقدم تجريب الحساب بشكل أصلي وبالتالي لا يتطلب الوسائط الإضافية (مثل zkSync* و Starknet)، بالإضافة إلى اقتراح RIP-7560 الذي تم نشره مؤخرًا للحساب الأصلي على إيثريوم ولفاته.
في مارس 2023، تم نشر عقد 4337 EntryPoint على الشبكة الرئيسية. لقد حققت مجتمعه نجاحًا هائلاً في جذب المطورين للمشاركة في حركة التجريد الحسابي.
هذا الأمر أدى إلى موجة جديدة من مزودي البنية التحتية والخدمات إلى نظام المحفظة، ودفع المشاريع القائمة لضمان استمرار إستراتيجياتها التجارية ومجموعات منتجاتها لتلبية احتياجات مطوري التطبيقات الذين يسعون إلى الاستفادة من AA لتقديم تجربة web3 سلسة لمستخدميهم.
البنية التحتية للمحفظة وكومة AA
الموقعون وإدارة المفتاح
البوابة وبنية إدارة المفاتيح مسؤولة عن إنشاء وتأمين أزواج المفاتيح العامة المستخدمة لتوقيع الرسائل والمعاملات وعمليات التشغيل للمستخدم. أبسط مثال هنا هي المحافظ التقليدية EOA، ولكن قد ظهرت مزودات المحفظة كخدمة لتمكين التسجيل بدون بذور وإدارة المحفظة عبر طرق المصادقة البديلة مثل الاجتماعية والبريد الإلكتروني.
تحت الغطاء، تقوم هذه الخدمات إما بتخزين المواد الرئيسية في HSMs مثل AWS KMS التي يمكن للمستخدم الوصول إليها فقط عبر بيانات اعتمادهم (Magic، Turnkey)، أو تعمل بموجب بعض نظام SSS/MPC (Privy، Web3Auth، Portal، Capsule) لحماية المواد.
يقوم Lit * بتحسين تصميم متجر المفتاح على الخادم هذا من خلال تجعيل المفاتيح. يخزن كل عقد في الشبكة جزءًا من مفتاح خاص ECDSA تم إنشاؤه عبر خوارزمية DKG، حيث تتم جميع العمليات في التجاهل الظاهري المشفر. يمكن تعيين قواعد مصادقة تعسفية لزوج المفتاح، مما يمنح التطبيق أو المستخدم التحكم الكامل في العمليات المسموح بها، وفرض حدود الإنفاق على سبيل المثال. يمكن استغلال الشبكة بشكل إضافي من قبل محافظ MPC بنسبة 2 من N كخيار للنسخ الاحتياطي واستعادة البيانات.
هذا العام، حدث تجربة سريعة للاستفادة من الموقعين الأجهزة ومفاتيح المرور كموقع للحساب لتقديم إدارة مفتاح المستخدمين بشكل فوري مع أجهزة الجوال أو سطح المكتب الحديثة. يعمل هؤلاء الموقعون بشكل طبيعي مع المصادقة البيومترية (مثل FaceID، TouchID) لتوفير أمان إضافي مع تجربة مستخدم مألوفة.
يستخدم Hardware Signers نظماً معزولة مثل iPhone Secure Enclave و Android Titan HSM لتوليد المفاتيح وتوقيع الرسائل، مما يضمن أمانًا على مستوى الأجهزة. نظرًا لعدم إمكانية استخراج المفاتيح من الجهاز، يعتبر هذا النظام الأكثر فاعلية عند استخدامه مع أساليب استعادة إضافية أو كجزء من نظام 2FA.
تعتبر مفاتيح العبور معيارًا للمصادقة بدون كلمة مرور يعتمد على نظام WebAuthn. هنا، يتم إنشاء زوج مفاتيح في نظام تشغيل الجهاز، ويمكن مزامنته عبر الأجهزة من خلال خدمات مثل iCloud، لذا يكون الاسترداد ممكنًا إذا اختار المستخدم القيام بذلك.
إحدى القيود هنا هي أن مفاتيح السرور والتوقيع الأجهزة المُنتَجة غير معترف بها بشكل أصلي من قبل سلاسل مثل بيتكوين وإيثيريوم. إذ يتم استخدام منحنى الإليبتيك secp256r1 (R1)، في حين تعمل هذه السلاسل بالتباين K1. بالرغم من أن هناك عملًا مستمرًا للتحقق من R1 بشكل موثوق وفعال، فإن بعض المنتجات التي تدعم مفتاح السر تمر عبر خدمات مثل ليت وتيرنكي لإنتاج توقيع K1 بمجرد موافقة المستخدم بمفتاحهم.
معيار يجب متابعته هو EIP-7212، الذي يقترح إضافة منحنى R1 مباشرة إلى EVM كعقد مُعدّ مُسبقًا بحيث يمكن لكل جهاز حديث توقيع المعاملات بشكل طبيعي دون الحاجة إلى خدمات الطرف الثالث أو الوسطاء.
مع زيادة حجم المعاملات المجردة عن الحساب، يمكن أن يؤدي تجميع التوقيعات باستخدام توقيعات BLS إلى تقليل رسوم الحساب الذكية بشكل أرخص من حسابات العقود الذكية على L2s. 4337 يحدد واجهة لعقود مساعد المجمع التي تقوم بالتحقق من توقيع مجمع واحد يوافق على عمليات مستخدم متعددة بدلاً من التحقق من كل واحدة على حدة.
المحفظة
المتوسطون (على سبيل المثال 4337 المجمعون) يقومون بنقل المعاملات أو عمليات المستخدمين إلى مجموعة ذاكرة مؤقتة. على السلاسل التي تحتوي على AA أصلية، يقوم مشغلو الشبكة والمتسلسلون بأداء هذا الدور، مما يُزيل الحاجة إلى المتوسطين المخصصين الخارجيين.
على غرار وجود تنفيذات عميل متعددة لـ Ethereum (على سبيل المثال، geth، erigon، reth)، فإن نظام 4337 يحتوي على تنفيذات حزمة متعددة بلغات مختلفة، مما يجعل الشبكة أكثر صلابة ضد الثغرات في تنفيذ واحد. تشمل مواصفات 4337 مجموعة اختبارات لضمان توافق حزمة البيانات عبر الشبكة. تشمل المنفذون Stackup (Golang)، Pimlico، Biconomy، Etherspot (Typescript)، Candide (Python)، OKX (Java)، و Alchemy (Rust).
نموذج الحوافز للمجمعين مماثل لبناة الكتل، حيث يأخذ الرسوم من عمليات المستخدم التي يجمعها بدلاً من المعاملات. في الممارسة، يحتاج المجمعون إلى واجهة برمجة تطبيقات إلى بنّاء الكتل لرؤية الكتلة الحالية وإنشاء حزمة تكون صالحة ضد تلك الكتلة وبالتالي يجب أن تُعتبر جزءًا من بنّاء الكتل.
مع نمو 4337 الجر معقول، يمكننا توقع أن يكون المُبنّون أيضًا مُجمّعين حيث سيكون هذا الهجين أكثر ربحية من المُبنّين وحدهم حيث يمكنهم اختيار من كل من حمامات الصفقة وحمامات المستخدم.
بايماسترز
تمكن Paymasters التجريب بواسطة السماح للتطبيقات اللامركزية برعاية الغاز للمستخدمين، مما يسمح للمستخدمين بدفع الرسوم باستخدام الرموز غير الأصلية، أو تسوية الأمور خارج السلسلة عبر قنوات الدفع التقليدية. تحتوي خدمات Paymaster على عنصرين رئيسيين:
مدير سياسة الغاز للمطورين لتحديد الشروط التي سيتبرعون بها بالغاز. يمكن تحديد هذا لمشروع بأكمله، أو على أساس كل عقد أو عنوان محفظة. يمكن للمطورين أيضًا تحديد كيف يرغبون في فرض قيود على تمويل الغاز على سبيل المثال عن طريق سعر الغاز، عدد الطلبات، أو المبلغ المتبرع به شهريًا. تكلفة تمويل الغاز عادة ما تدرج في فاتورة الشهرية للمطورين من مزود الخدمة مع رسم إضافي بنسبة ~5% على المبلغ المتبرع به.
يقوم عقد الدفع الذكي بالتحقق مما إذا كانت الصفقة المعطاة مؤهلة للتغطية، سواء على أساس حالة السلسلة مثل أرصدة الحسابات أو سياسات إدارة الغاز الخارجية. يحتوي عقد الدفع الذكي على رصيد من الرموز الأصلية التي تُستخدم لدفع تكاليف الغاز، وقد يحتوي على منطق أوراق البيانات السعرية التي تفحص بانتظام سعر صرف الرمز الدفع (على سبيل المثال USDC) والرمز الأصلي (على سبيل المثال ETH).
يمكن تصنيف أمناء الدفع إلى داخل السلسلة أو خارجها:
يعتمد Paymasters Onchain (مثل ERC20Paymaster، StablecoinPaymaster) فقط على حالة السلسلة للتحقق مما إذا كان بإمكان المعاملة أن تُغطى من قبل الـ paymaster أم لا. وهذا يعني أنه يمكن جعل بعض المدفوعات مثل تلك التي تقبل دفع الغاز بـ ERC-20s، الذي يمكن تقديمه دون إذن، مع الشرط أن يتمتع الـ paymaster بالموافقة من الحساب لتحويل الرموز الدفعية. يمكن لمسؤولي عقد Paymaster سحب الرموز وتحويلها مرة أخرى إلى العملة الأصلية لإعادة تعبئة العقد، ضبط هامش على أساس سعر ERC20، تحديد عتبة لفارق السعر الذي يُحدث الـ paymaster سعر ERC20 لعملية المستخدم التالية، أو تحديث السعر يدوياً.
مدفوعات السلسلة الجانبية (على سبيل المثال، VerifyingPaymaster) تشمل تفاعلات مع واجهة برمجة تطبيقات راعي خدمة مزود الخدمة لرعاية UserOp. يقوم الخدمة الجانبية بالتحقق من الأهلية والتوقيع على المعاملة باستخدام مفاتيح راعي الدفع. بينما تكون هذه الحلول ذات إذن، تأتي مدفوعات السلسلة الجانبية مع فوائد توفير الغاز من خلال تقليل الفحوصات على السلسلة. يمكن جعل سياسات الغاز أكثر تفصيلًا، وأخذ النشاط السلسلي مثل نشاط Discord في الاعتبار.
مصانع الحسابات والأطر
توفر مصانع الحسابات والأطر إمكانيات تنفيذ الحسابات الذكية "بدون رأس" ومجموعات تطوير البرمجيات التطبيقية التي يمكن لتطبيقات الويب اللامركزية وعملاء المحافظ بناءها عليها، مما يخلق حسابات مضمنة تحت تصرف المستخدمين لنفسهم. تعتبر الحسابات ذاتيًا محافظ عقود ذكية تتمتع بتحقق توقيعها الخاص، ومنطق تنفيذها، وحماية الإعادة (إدارة الرقم العشوائي). يقوم المالكون بالتصديق على عمليات المستخدم الناشئة من حساباتهم الذكية باستخدام مفتاحهم.
على مستوى عالٍ، يوفر بائعو الحسابات الذكية 3 أشياء أساسية:
تنفيذ أساسي لمحفظة عقد ذكي، مع منطقها الخاص لكيفية تحقق، تنفيذ المعاملات، وأي إجراءات إضافية للقيام بها قبل وبعد التنفيذ. كما تحتوي على منطق لكيفية إضافة ميزات إضافية إلى المحفظة عبر الوحدات الأساسية والطرف الثالث.
عقد مصنع ينشئ حالات جديدة من تنفيذ المحفظة، تم تنشيطه بالتوقيع الأولي لهذا الحساب. بموجب ERC-4337، يمكن لتطبيقات الويب اللامركزية إنشاء حسابات ذكية لمستخدميها عن طريق تحديد عنوان عقد المصنع من موفر خدمة الخيار الخاص بهم.
مجموعة أدوات توفر للمطورين إمكانية تخصيص واجهات متوافقة للحسابات الذكية التي يقومون بإنشائها. يمكن أن تشمل هذه الخيارات توقيع مختلف، وتقنيات التشغيل والإيقاف، والتقنيات الخاصة بالتوجيه.
تحت ERC-4337، الالمرسلحقل UserOp يشير إلى الحساب الذكي الذي تتم فيه المعاملة. إذا لم يتم نشر الحساب بعد، يقوم EntryPoint بنشر الحساب من عقد المصنع المحدد في initCode. يمكن استخدام مفاتيح المستخدم للمطالبة بالحساب الذكي لإجراء تفاعلات DApp اللاحقة.
مزودو الحسابات مثل Safe و Zerodev و Biconomy يدمجون مع مديري المفاتيح والبنية التحتية للمصادقة ليمنحوا تطبيقات الويب اللامركزية خيارات بشأن كيفية رغبتهم في إدارة حساباتهم الذكية. على سبيل المثال، يمكن لتكامل Web3Auth لـ Safe أن يمكن المستخدمين من استخدام حساباتهم باستخدام وسائل التواصل الاجتماعي أو البريد الإلكتروني، وتوفير خيار إدارة الحسابات بواسطة Passkeys من خلال تكامل Zerodev مع Turnkey.
المحفظة هي الأكثر شهرة لمنتج المحفظة الذكية التي تم اختبارها بشكل جيد والتي يستخدمها على نطاق واسع الأفراد والفرق ومنظمات السلطة اللامركزية. حتى الآن، تم نشر أكثر من 5 ملايين محفظة عبر أكثر من 12 سلسلة، تنفيذ أكثر من 22 مليون عملية. قبل الإصدار v1.4.1 (الذي تم إطلاقه في يوليو 2023)، كان بإمكان المطورين استخدام ريلي Gelato لتمكين عمليات التحويل المجردة للغاز. تقوم هذه الجمعية حاليًا بتشغيل منتجات بطاقات الخصم الرقمية مثل Gnosis Pay وBasedApp حيث يمكن للمستخدمين شراء من أي بائع يقبل فيزا باستخدام الأموال في محفظتهم. يقدم الإصدار v1.4.1 دعم ERC-4337 من خلال وحدات لتوفير خيارات إضافية في موفري الريلي.
صفر ديف هو مزود حساب ذكي تم إطلاقه في وقت سابق من هذا العام والذي تم بناؤه لـ ERC-4337 من البداية. يقوم زيرو ديف بتجميع مزودي الحزم المتعددين لتجريد خدمات ريلي UserOp، ويكشف لوحة تحكم مدير الغاز حيث يمكن للمطورين تحديد نطاق ومنطق تحديد حدود السعر لرسوم الرعاية للمستخدمين. يهيمن زيرو ديف و Biconomy (الذي يدير أيضًا شبكة الحزم الخاصة به) حاليًا على حصة السوق لحسابات 4337 الممكّنة.
تتميز حساب Alchemy's AccountKit بتنفيذ حساب ذكي متوافق مع 4337 "LightAccount"، والذي يعتمد على تنفيذ EF ويضيف دعم EIP-1271 (للتحقق من التوقيعات الناتجة من العقود الذكية) بالإضافة إلى نقل الملكية وتدوير المفاتيح وتخزين مساحة الأسماء.
وحدات الحساب
وحدات الحسابات هي عقود ذكية تعمل كمكونات قابلة للتثبيت على حساب ذكي. على الرغم من أن بنية الوحدة لا تزال في مراحلها الأولى جدًا، إلا أننا نتصور أنه ستكون الوحدات قابلة للاكتشاف والتثبيت بواسطة:
المطورون: يمكن أن تأتي الحسابات الذكية المضمنة مع وحدات "مثبتة مسبقًا" كما يقررها مطور تطبيق الويب اللامركزي، مما يؤدي إلى إنشاء محفظة بداية بميزات مخصصة لحالة استخدامهم
المستخدمون النهائيون: يمكن لواجهات المحفظة أن تكشف عن "متجر الوحدات" حيث يمكن للمستخدمين اكتشاف ميزات جديدة وإضافتها إلى محفظتهم
مع فصل AA رسمياً حول كيفية معالجة التحقق من صحة UserOp وتنفيذه، يمكن أن تحتوي الوحدات على منطق للتحقق فقط أو تنفيذ فقط.
المحققون. يتم استدعاؤهم أثناء مرحلة التحقق من عملية المستخدم. وظيفتهم الأساسية هي التحقق من توقيع عملية المستخدم وتحديد ما إذا كانت صالحة ويجب تنفيذها. تشمل الأمثلة التحقق المتعدد التوقيعات، ECDSA، مفاتيح العبور، التحقق متعدد السلاسل، ومفاتيح الجلسة. تتيح مفاتيح الجلسة للتطبيقات اللامركزية التوقيع نيابة عن المستخدم لتبسيط تجربة المستخدم، مع تصرف مثل مفاتيح خاصة مؤقتة مع صلاحيات قابلة للتخصيص ووقت انتهاء صلاحيتها.
المنفذون. يتم استدعاؤهم خلال مرحلة التنفيذ لعملية المستخدم. إنهم يوسعون منطق التنفيذ للحساب ويسمحون بمجموعة متنوعة أكبر من الإجراءات التي يمكنها القيام بها بشكل أصلي. وتشمل الأمثلة الإجراءات التلقائية التي تُشغل خارج تدفق التنفيذ العادي لـ ERC-4337 مثل تبادل الرموز تلقائيًا عندما يصل السعر إلى عتبة معينة.
يعمل الخطافات قبل أو بعد التنفيذ ويفرض controles ضد الحساب. على سبيل المثال، يمكن لخطاف أن يعمل بعد التنفيذ ويعيد أي معاملات تفي بمعايير معينة لتحقيق أمان متزايد للمستخدم.
بينما قامت بعض المحافظ مثل Candide بتطوير وحدات يمكن لمستخدميها تثبيتها مباشرة، نتوقع بيئة غنية من الوحدات من جهات خارجية التي يمكن اكتشافها في واجهة متجر التطبيقات الخاصة بمحافظهم، أو دمجها في محفظة مدمجة "بداية" من قبل مطوري التطبيقات اللامركزية.
تم تصميم أنظمة الحسابات الذكية بالفعل مع الوحدات في الاعتبار. يتعامل العقد الأساسي لـ Safe مع منطق إدارة الوحدات لإضافة وإزالة الوحدات من الحساب، لكنه يترك منطق الوحدة الفعلي والتخزين متعلقًا بالوحدة تمامًا محصورًا في عقد منفصل. يخفف هذا الفصل بين الاهتمامات من مخاطر أن تقوم الوحدات الخارجية بكتابة نفس الحالة، مما يعرض الأمان والسلوك المتوقع للحساب للخطر.
يقدم بروتوكول Safe{Core} إطارًا مفتوحًا يحتوي على وحدات، وخطافات، ومدير، وسجلات تهدف إلى تعزيز نظام الحسابات الذكية القابل للتركيب المستوحى من الدروس المستفادة من منتج المحفظة Safe.
يصنف ZeroDev صراحة وحداته ("المكونات الإضافية") على أنها تحقق من الصحة أو التنفيذ. تم تصميم وحدات المنفذ ليتم إقرانها بوحدات المدقق ، مما يسمح "بتوجيه" الوظائف المخصصة من خلال مدققين مختلفين. على سبيل المثال ، وظيفة "نقل NFT" التي تسمح فقط بنقل NFTs عبر المصادقة الثنائية (2FA).
بعض الاعتبارات في بناء نظام بيئي قوي من الحسابات الذكية القابلة للتعديل:
التوافق. مع عدة بائعين للحسابات الذكية كل منهم لديه نهجه الخاص لكيف يمكن للأطراف الثالثة إضافة ميزات جديدة إلى الحسابات ، فإن مطوري الوحدات في طريقهم نحو الانغلاق مع البائع أو الاضطرار إلى إدارة العبء التقني لتطوير نفس الميزات لتكون متوافقة مع تنفيذات الحسابات المتعددة. بعض الحلول للتخفيف من هذا:
يحدد ERC-6900 لحسابات العقود الذكية المعيارية والمكونات الإضافية واجهات حسابات العقود الذكية المعيارية (MSCAs) والوحدات النمطية ("المكونات الإضافية) مما يسمح لأي تطبيقات حساب متوافقة مع المعايير والمكونات الإضافية بأن تكون قابلة للتشغيل البيني مع بعضها البعض.
يوفر ModuleKit من Rhinestone لبناء واختبار وحدات الحساب الذكية قوالب وأطرًا لاختبار الوحدات ضد تنفيذات حساب مختلفة، ومكتبة للتكاملات (على سبيل المثال، بروتوكولات DeFi)، وشروط مُبنية مُسبقًا للتنفيذ، وأتمتة الأمان لتحليل كود الوحدة وتحديد الثغرات الأمنية.
الأمان. إعطاء المستخدمين القدرة على تثبيت البرمجيات من الطرف الثالث في محافظهم يأتي مع أسئلة مهمة حول كيفية يجب أن تقوم الواجهات بتنسيق وعرض معلومات ذات صلة حول الوحدات.
يوفر EIP-7484 وسيلة للتحقق من شرعية وأمان وحدات الحساب الذكية المبنية بشكل مستقل. هنا، يسمح سجل المراجعين للقيام بشهادات حول أمان تلك الوحدات. يمكن لواجهات المستخدم والحسابات الذكية الاستعلام عن السجل لاستدعاء بيانات الشهادة، للتحقق من أن الوحدة آمنة للاستخدام. انظر سجل الراينستون لتنفيذ مرجعي لهذا.
بشكل أوسع، يهدف EIP-7512 إلى إنشاء معيار لتمثيل على السلسلة لتقارير التدقيق يمكن تحليلها بواسطة العقود الذكية لاستخراج معلومات ذات الصلة حول من قام بالتدقيق والمعايير التي تم التحقق منها.
القابلية للكشف. يمكن تعريض السجلات واستعلامها عن طريق منصات الحسابات الذكية وواجهات المحافظ المثبتة من قبل المطورين أو المستخدمين النهائيين.
القدرة على توسيع وظائف المحفظة تحول الحسابات إلى منصات للمطورين وقنوات توزيع جديدة لمنتجات وخدمات web3. نحن بالفعل نرى هذا مع Metamask Snaps الذي يسمح للمستخدمين بتخصيص محفظة تمديد المتصفح الخاصة بهم مع تنبيهات الأمان (من خلال WalletGuard)، وميزات الخصوصية (من خلال Nocturne)، والتوافق مع سلاسل غير EVM مثل Starknet وBitcoin.
عندما أتاح Chrome بيئة للمطورين لتوسيع وظائف المتصفح من خلال الامتدادات، دفع ذلك بهم نحو الهيمنة على السوق فوق الحدائق المحيطة الحالية على الرغم من أنهم أصغر بعقد. على الرغم من أنه من الصعب على معظمنا تصور كيف قد تبدو تجربة المحفظة عندما تصبح الحسابات القابلة للتعديل شائعة، فإن المسارات بالفعل تُمهَّد لتأخذ الابتكارات غير المرخصة مجراها.
أنماط التطور الناشئة وتداعياتها
المحفظة المتطورة تعني ذلك:
يمكن للمطورين إنشاء حسابات غير تابعة للعميل لمستخدميهم في سياق تطبيقاتهم، وسيتطلعون إلى أدوات مثل مجموعات تطوير برامج تطبيقات لإعطائهم خيارات في كيفية بناء رحلة التسجيل من البداية إلى النهاية.
المحافظ المضمنة هي فئة جديدة من المحافظ، كل بائع لديه ميزاته الخاصة وتنازلاته من حيث قابلية نقل الحساب، وقابلية التخصيص، وافتراضات الثقة.
إذا قمت بالتلاعب بتطبيقات Ethereum في عام 2018، فقد تتذكر الحصول على نافذة منبثقة لـ Metamask بمجرد تحميل الموقع. كان ذلك بسبب نقص الممارسات الجيدة في تجربة المستخدم حول ربط المحافظ وتطبيقات الويب، وكان يلجأ المطورون في كثير من الأحيان إلى فحوصات البرمجة الصعبة لمعرفة ما إذا كان المستخدم قد قام بتثبيت محفظة الامتداد باستخدام متصفحهwindow.ethereumهذا أدى إلى سلوك غير متوقع إذا كان لدى المستخدمين عدة محافظ تمديد مثبتة، مما اضطر المستخدمين إلى اختيار واحدة وخلق سوق أقل تنافسية للمحافظ.
ظهر بروتوكول الاتصال WalletConnect* للسماح للمستخدمين بربط أي محفظة بأي تطبيق لامركزي، جنبًا إلى جنب مع Web3Modal، وهو مكتبة تغلف الأزرار ومكونات النموذج الظاهري للسماح للمستخدمين باختيار المحفظة التي يرغبون في استخدام التطبيق اللامركزي معها.
اليوم، يعتبر Web3Modal أحد مكتبات ربط المحافظ المتعددة مثل RainbowKit و Web3Onboard و ConnectKit التي تبسط عملية كشف المحفظة والمصادقة على أساس المحفظة لمطوري التطبيقات الموزعة. تقدم هذه المكتبات خيارات تصميم جاهزة، وميزات بحث عن المحافظ، وشاشات توجه المستخدمين لتثبيت المحافظ إذا لم يكن لديهم واحدة بالفعل.
في الآونة الأخيرة، تم الانتهاء من EIP-6963 كآلية بديلة لاكتشاف المحفظةwindow.ethereum، مما يسمح لتطبيقات الويب اللامركزية والنصوص المدخلة المقدمة من قبل الامتدادات بالتواصل بطريقة قابلة للتنبؤ. بفضل هذا الاستاندرد، يمتلك المستخدمون الآن خيارات أكثر في اختيار محفظة الامتداد المفضلة للاتصال بتطبيقات الويب اللامركزية، ويفتح سوقًا أكثر تنافسية للمحافظ.
بينما قد قامت مكتبات الاتصال بتحسين تجربة تطوير التطبيقات وتجربة المستخدم بشكل كبير، إلا أن التوقع بأن المستخدمين يمتلكون بالفعل أو سيقومون بتثبيت برامج إضافية للتفاعل مع التطبيقات اللامركزية ما زال يشكل عائقًا كبيرًا أمام الاعتماد.
نحن بالفعل نرى لمحة عما سيبدو عليه مستقبل تجربة مستخدم تطبيقات القرصنة، حيث تقوم الجيل القادم من مكتبات المحفظة، التي سنطلق عليها هنا "مجموعات تطبيقات SDK الكاملة"، بالانتشار. بالإضافة إلى المصادقة القائمة على المحفظة، توفر هذه SDKs خيارات بديلة للتسجيل وتسجيل الدخول مثل البريد الإلكتروني ووسائل التواصل الاجتماعي والرسائل القصيرة، وتنشئ محافظ مضمنة للمستخدمين بدون الحاجة لتثبيت برامج إضافية أو الانتقال بعيدًا عن تطبيق القرصنة.
يمكن للمطورين دمج الموصلات المقدمة من قبل مقدمي المفاتيح مباشرة (على سبيل المثال Magic، Privy، Web3Auth) أو استخدام تلك التي تلف خدمات متعددة (على سبيل المثال Dynamic، Thirdweb، 0xPass) لتوفير خيارات توصيل وتشغيل على الخيارات المصادقة التي يريدون تعريضها ونوع المحفظة التي يريدون إنشائها، مخصصة تمامًا لتخصيص تدفق الانضمام. يمكن أن تدمج مجموعات تطوير البرمجيات لتسجيل الدخول أيضًا مع موفري الحسابات الذكية لإنشاء محافظ ذكية مضمنة، مما يقدم تحسينات تجربة المستخدم الإضافية مثل المعاملات بدون رسوم وممرات الدخول والخروج.
مع ازدياد اعتماد "المحافظ الرأسية" والحركة نحو المحافظ المضمنة، بدأ الفصل الواضح بين المحافظ والتطبيقات اللامركزية في التلاشي.
المحافظ المستقلة مقابل المحافظ المضمنة مقابل المحافظ ذات التطبيقات
مستخدمو Web3 اليوم معتادون على التفاعل مع تطبيقات الويب اللامركزية من خلال محافظ مستقلة مثل Metamask أو تلك المقدمة من خلال WalletConnect، متراكمين أصولهم وبصمتهم على السلسلة الزمنية لحساب واحد أو عدة حسابات.
كلما ازداد عدد التطبيقات اللامركزية التي تبحث عن جذب المستخدمين من خلال المحافظ المضمنة والعديد من البائعين المتاحين، يصبح إدارة الحسابات معقدة بسرعة لكل من مطوري التطبيقات اللامركزية والمستخدمين النهائيين. سيضطر مطورو التطبيقات اللامركزية إلى تقييم وإدارة العديد من البائعين محاولين تجنب الاحتجاز. بالنسبة للمستخدمين النهائيين، إنشاء محفظة جديدة لكل تطبيق لامركزي سيؤدي إلى تجزئة تجربة إدارة الأصول والهوية.
في حين أن المحافظ التي تخصص التطبيق مرغوب فيها لبعض حالات الاستخدام مثل الألعاب، إلا أن هناك العديد من الحالات التي قد يقوم فيها المستخدمون بالانضمام إلى تطبيقهم الأول، وإنشاء محفظة مضمنة مع موقع التوقيع الخاص بهم أو المفتاح السري، ويرغبون في استخدام الأصول التي يجنونها في تلك الحساب على تطبيق آخر عن طريق تسجيل الدخول بنفس الموقع التوقيع.
Capsule هو موفر محفظة مدمجة قائم على تقنية MPC والذي يتميز بقابلية نقل المحفظة عبر تطبيقات الويب اللامركزية التي تستخدم خدماتهم، مما يمنح المستخدمين الوصول إلى محفظة موجودة باستخدام نفس تسجيل الدخول بالبريد الإلكتروني. يمكننا توقع أن يكون هذا قريبًا عرضًا أساسيًا عبر مزودي خدمات الويب اللامركزية.
يساعد Moonchute المستخدمين على إدارة عدة حسابات ذكية مؤقتًا. مدير حساباتهم الموحد هو تطبيق وواجهة برمجة تطبيقات لاكتشاف محافظ ذكية تم إنشاؤها بواسطة الموقع الذي تم منحه، مما يتيح للمستخدمين إدارة الأصول من حسابات متعددة في مكان واحد.
يقترح ERC-7555 واجهة موحدة مستوحاة من SSO ونمط طلب/استجابة لتطبيقات لاكتشاف حسابات المستخدمين التي تم إنشاؤها باستخدام مخططات تسجيل بديلة. هنا، سيقوم التطبيق بإعادة توجيه المستخدم إلى عنوان URI المعطى لمزود معين (والذي يمكن أن يكون نطاقًا مستضافًا ذاتيًا)، وتحليل الاستجابة للحصول على موقع توقيع وعنوان الحساب الذكي المرتبط.
التحول من EOAs
تحدي آخر بارز لشركة AA هو الطريقة السلسة للمستخدمين الحاليين، الذين لديهم بالفعل أصول وتاريخ سلسلة كتل متراكمة على العديد من حسابات العقود الذكية، للانتقال إلى الحسابات الذكية.
EIP-7377 يقترح آلية في البروتوكول للسماح لحسابات الأفراد ذوي الصلاحيات الخاصة بإرسال عملية تحويل لمرة واحدة تنشئ الشيفرة في حسابهم، مما يُسهّل "ترقية" حساب فردي ذو صلاحيات خاصة إلى محفظة ذكية.
تهدف Aarc إلى حل مشكلة هجرة الأصول لتطبيقات الويب اللامركزية والمستخدمين النهائيين. يُفهم واجهة المستخدم الخاصة بهم وفهارس SDK الأصول والصلاحيات لعنوان المصدر المحدد، ويسمح للمستخدمين بتحديد الأصول التي يرغبون في نقلها إلى أي عنوان وجهة، والذي يمكن أن يكون حساب ذكي، أو عنوان EOA آخر، أو محفظة MPC مضمنة تم إنشاؤها باستخدام تسجيل الدخول الاجتماعي. بالنسبة لتطبيقات الويب اللامركزية التي تمتلك مستخدمين قائمين يعتادون على سير تشغيل المحفظة المستقلة، تقدم Aarc حلاً لتبسيط عملية الهجرة حيث تسعى إلى إضافة محافظ مضمنة أو ميزات AA إلى منتجها.
تداعيات AA على إدارة الحساب متعدد السلاسل
نظرًا لزخم النشاط في AA و L2، يمكننا توقع مستقبل حيث تصبح الحسابات الذكية شائعة على حسابات العقود الذكية الخارجية مع المستخدمين الذين لديهم أصول عبر عدة سلاسل.
ميزة واحدة لتجربة المستخدم الخاصة بحسابات الإيثريوم الخارجية هي أن المستخدمين يمتلكون تلقائيًا نفس العنوان عبر سلاسل EVM مختلفة باستخدام نفس المفتاح الخاص. العيب يكمن في أنه ليس من الممكن تغيير المفاتيح التي تتحكم في عنوان معين، ويمكن أن تضيع جميع الأموال إذا فقد المستخدم مفتاحه الخاص.
نظرًا لأن التجريد الحسابي يفصل متجر المفتاح عن متجر الأصول، يمكن تدوير المفاتيح لحساب معين دون الحاجة إلى ترحيل الأموال مع الاحتفاظ بنفس العنوان. الحسابات الذكية قادرة على الحفاظ على نفس العنوان عبر الشبكات باستخدام CREATE2، مما يمنح المستخدمين الوصول إلى الحساب حتى لو لم يتم نشر العقد على سلسلة معينة بعد باستخدام نفس المفتاح التحقق الأولي وتنفيذ الحساب.
ومع ذلك، قد يكون الاحتفاظ بنفس العنوان عبر سلاسل مختلفة نمطًا ضارًا على المدى الطويل.
إن إنشاء 2 ممكن فقط على السلاسل ذات التكافؤ لبايت الشيفرة التنفيذية للآلة الظاهرية. في عالم متعدد السلاسل مع zk-Rollups (على سبيل المثال zkSync) مع انحرافات طفيفة إلى الآلة الظاهرية، لن تكون هذه الطريقة كافية.
يمكننا توقع أن المفاتيح اللازمة للوصول إلى الحسابات المختلفة ستتغير مع مرور الوقت مع تعريض المحافظ إلى ميزات توقيع وتدوير مفاتيح إضافية. في الإعداد الحالي، يمكن أن يتسبب ذلك بسرعة في تسبب تغيير حالة أذونات الحساب عبر السلاسل، حيث لا تنتقل التغييرات إلى الموقعين على حساب في سلسلة واحدة تلقائيًا إلى تلك في السلاسل الأخرى.
الحلول طويلة الأجل التي تم اقتراحها لشبكة AA متعددة السلاسل تشمل:
عقد مخزن مفتاح مخصص يقوم حساب مستخدم عبر السلاسل بقراءته عند التحقق من الأذونات. انظر إلى تنفيذ هذا من محفظة الروح.
استخدام حلول ENS متعددة السلاسل كطبقة تجريد لعناوين مختلفة.
إدارة حساب ومفتاح توقيع عبر السلاسل لا تزال مجالًا يخضع للبحث النشط. الهدف النهائي هنا هو أن يتمكن المستخدم من تغيير المفاتيح التي تمتلك وصولًا إلى حسابات متعددة على سلاسل مختلفة دون إجراء عدد هائل من المعاملات.
الاستنتاج والأفكار الختامية
تجريد الحساب هو حركة لفصل الموقعين عن الحسابات من خلال جعل الحسابات القائمة على العقد (بدلاً من EOAs) ككيانات من الدرجة الأولى على سلسلة الكتل، مما يمنح المستخدمين مرونة في إدارة المفاتيح وتصريح الحساب.
ERC-4337 كمعيار لإعادة توجيه المعاملات الذكية التي بدأتها الحسابات قد حفز تطور بنية الجيب لاستيعاب AA، مما أدى إلى ظهور هياكل سوق جديدة وفئات جيب جديدة وتطوير dapp وأنماط انضمام المستخدمين.
تم فك تجميع مكدس المحفظة إلى الموقعين، والمعادين، ومزودي الحسابات ووحدات الحسابات مما يمنح المطورين خيارات في كيفية تخصيص تجربة المستخدم النهائية. يأتي هذا مع التكلفة الإضافية لتقييم كل مزود من حيث التضحيات فيما يتعلق بتكاليف الغاز الزائدة، ومقاومة الرقابة، وقفل البائع، وقابلية التشغيل.
مسارات الهجرة من حسابات التنفيذ الخارجية والتجريد الحسابي في سياق متعدد السلاسل لا تزال مجالات بحث مستمرة. نتوقع رؤية أولى تنفيذات الحلول المقترحة في العام القادم.
نحن نعتقد أن هذه التطورات لها تأثيرات كبيرة عبر النظام البيئي:
بالنسبة للمستخدمين الجدد، لم تعد المحافظ الوحيدة نقطة الدخول الوحيدة إلى web3. ستكون التطبيقات قد تحسنت بشكل كبير في عملية الانضمام من خلال المحافظ المضمنة، والمعاملات بدون رسوم، ونقاط الوصول في المحفظة.
بالنسبة للمستخدمين الحاليين، ستصبح التجارب على السلسلة الكتلية أكثر سلاسة مع استفادة التطبيقات من ميزات مثل مفاتيح الجلسة. يحصل المستخدمون على تحكم دقيق أكثر في أذونات الحساب وميزات المحفظة الإضافية من خلال الوحدات.
بالنسبة للمطورين، تحويل البنية التحتية للحسابات إلى وحدات يتيح للمحافظ أداء وظائف نظام التشغيل. أسواق الوحدات هي قناة توزيع جديدة بدون إذن لمنتجات وخدمات web3.
سيستمر البنية التحتية للمحفظة في تحفيز اعتماد web3. نحن في 1kx نفخر بدعم الفرق التي رائدت في الأفكار التي ناقشت في هذه المقالة، وسنستمر في مراقبة المساحة لما هو قادم.
إذا كنت تعمل على حلول في هذا المجال أو لديك أفكار إضافية حول الموضوع، يرجى التواصل@nichanank - سأحب الدردشة معك.
العديد من الشكر لديفيد سنيدر، جون رايزينج، كونراد كوب، كورت لارسن، مارك سدناوي، دوغان ألبارسلان، فيفيان فونغ، ديريك رين، توم تيرادو، ديانا بيغس، ميل كوارتو، وبيتربان على مراجعة مسودات هذا.
*يشير إلى شركات محفظة 1kx
بيان:
- هذه المقالة مأخوذة من[1kx]، حقوق الطبع والنشر محفوظة للكاتب الأصلي[1kx]، كما أنه يتوجب على الأشخاص الذين يعارضون إعادة النشر الاتصالفريق Gate Learn، سيقوم الفريق بمعالجة العملية ذات الصلة في أقرب وقت ممكن.
- 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
- النسخة باللغة الأخرى من قبل فريق Gate Learn، عندما لم يتم ذكرهاGate.ioفي حالة عدم السماح بنسخ أو نشر أو اقتباس المقالات المترجمة.
مقالات ذات صلة
كيف تعمل بحوثك الخاصة (Dyor)؟
ما هو سولانا？
ما هو التحليل الأساسي؟
البنية التحتية للمحفظة: تمكين الجيل القادم من التطبيقات اللامركزية
تجريد الحساب: ماذا، ولماذا، وكيف
البنية التحتية للمحفظة وكومة AA
أنماط التطور الناشئة وتداعياتها
الختام والأفكار الختامية
البنية التحتية للمحفظة تلعب دوراً حاسماً في فتح تجربة الويب3 لجيل التطبيقات اللامركزية القادم.
حتى الآن، كان على المستخدمين تثبيت برامج إضافية ومصادرها وتمويلها بعملة جديدة، ومواجهة شاشات تأكيد غير مألوفة قبل أن يقوموا حتى بأول تفاعل في web3. على الرغم من تحسين جدار الحماية والانتقال بعيدًا عن عبارات البذور، هذه العقبات لا تزال نقاط تحول عالية لتطبيقات اللامركزية.
كانت البيئة مهيأة للابتكارات التي تجرد الطبقات التقنية بعيدًا، مما يمكن من الانضمام بشكل بديهي إلى تجارب مالية واجتماعية ولعب دون المساس بالوجدان الأصلي للحفظ الذاتي واللامركزية.
2023 كان عامًا حاسمًا لنظام المحفظة، مع التجريد من الحساب والتطورات عبر جميع طبقات الشبكة مما يغير هياكل السوق ويغير كيفية تفكيرنا في العلاقة بين المستخدمين والتطبيقات اللامركزية والمحافظ.
تجريد الحساب: ماذا، ولماذا، وكيف
يمكننا التفكير في التجريد الحسابي كفصل إدارة الحساب عن إدارة المفتاح. الحساب هو كيان على سلسلة الكتل يمكنه الاحتفاظ بالأصول ويملك تاريخ المعاملات. الموقعون (المفاتيح) هم الكيانات التي لديها السلطة للقيام بإجراءات نيابة عن الحسابات.
مع الحسابات التقليدية (EOAs)، تحتفظ المفتاح الخاص بالسيطرة الكاملة والحصرية على حسابه المرتبط. الربط الصارم بنسبة 1 إلى 1 بين المفتاح الخاص والحساب يعني أن:
يتم تقييد المستخدمين باستخدام حلول إدارة المفاتيح المخصصة (على سبيل المثال Metamask, Ledger) عند التفاعل مع تقنية البلوكشين.
لا يوجد طريق للاسترداد من فقدان مفتاح خاص، ولا يمكن استبدال المفتاح الذي يتحكم في حساب.
يتم التعامل مع جميع الإجراءات التي أنشأها هذا المفتاح الخاص على قدم المساواة ، من سك NFT مجاني إلى نقل ملايين الدولارات.
تجعل تجريب الحساب الحساب عقد ذكي مع منطقه الديناميكي لما يمكن أن تنفذه المفاتيح على حسابه، ونطاق الأذونات، وتنفذ فحوصات ورصيد إضافية وفقًا لحالة الاستخدام.
يمكننا تقسيم فوائدها بشكل أكبر من خلال فحص ما يتم تجريده.
لأن بروتوكول Ethereum يعترف فقط بالمعاملات التي جاءت من EOA، فإن التجريد الحسابي يتطلب بنية خارج السلسلة لنقل المعاملات التي جاءت من العقود الذكية إلى السلسلة.
تم تقديم ERC-4337 في عام 2021 كطريقة موحدة للقيام بذلك دون تغييرات في البروتوكول الأساسي. ومع ذلك، كان بعض المشاريع قد قدمت فوائد AA قبل أن يتم تطوير المعيار بشكل كامل.
تم إطلاق محفظة متعددة التوقيع الآمنة في عام 2017 وقد نمت لتأمين قيمة تزيد عن 50 مليار دولار من الأصول للمنظمات اللائحة ذاتيًا، والشركات، والأفراد على حد سواء
تم تشغيل محفظة Argent على الهواتف النقالة بواسطة حسابات العقود الذكية منذ عام 2018
محفظة التسلسل، التي تم إطلاقها في عام 2021، سمحت لـ Skyweaver بإنشاء حساباتهم الذكية وتسجيل الدخول إليها باستخدام بريدهم الإلكتروني ودفع الرسوم باستخدام رموز غير أصلية
كان ذلك يتطلب بناء وصيانة بنية توجيه مخصصة من قبل المشروع المعني.
أدخل ERC-4337. يقدم المعيار بديلًا للطبقة البديلة للتوجيه المركزي والمقاوم للرقابة، ويحدد واجهة لحسابات، ومدفوعات، ومجمعي التوقيع للتفاعل مع الموجهين من الطرف الثالث عبر حوض ذاكرة مشترك بديل للعمليات النقدية المجردة عن الحسابات ("عمليات المستخدم").
يقوم الموجهون (المجمعون) بتجميع عمليات المستخدم المتعددة معًا في عملية لإرسالها إلى عقد نقطة الدخول الفردية، الذي بدوره يتحقق من أن الرسوم ستُدفع (بواسطة الحساب نفسه أو من خلال الجهات المدفوعة)، وينفذ عمليات المستخدم المتعلقة بالحسابات الذكية.
يمكننا التباين في هذا مع كيفية حدوث التحقق والتنفيذ على السلاسل التي تقدم تجريب الحساب بشكل أصلي وبالتالي لا يتطلب الوسائط الإضافية (مثل zkSync* و Starknet)، بالإضافة إلى اقتراح RIP-7560 الذي تم نشره مؤخرًا للحساب الأصلي على إيثريوم ولفاته.
في مارس 2023، تم نشر عقد 4337 EntryPoint على الشبكة الرئيسية. لقد حققت مجتمعه نجاحًا هائلاً في جذب المطورين للمشاركة في حركة التجريد الحسابي.
هذا الأمر أدى إلى موجة جديدة من مزودي البنية التحتية والخدمات إلى نظام المحفظة، ودفع المشاريع القائمة لضمان استمرار إستراتيجياتها التجارية ومجموعات منتجاتها لتلبية احتياجات مطوري التطبيقات الذين يسعون إلى الاستفادة من AA لتقديم تجربة web3 سلسة لمستخدميهم.
البنية التحتية للمحفظة وكومة AA
الموقعون وإدارة المفتاح
البوابة وبنية إدارة المفاتيح مسؤولة عن إنشاء وتأمين أزواج المفاتيح العامة المستخدمة لتوقيع الرسائل والمعاملات وعمليات التشغيل للمستخدم. أبسط مثال هنا هي المحافظ التقليدية EOA، ولكن قد ظهرت مزودات المحفظة كخدمة لتمكين التسجيل بدون بذور وإدارة المحفظة عبر طرق المصادقة البديلة مثل الاجتماعية والبريد الإلكتروني.
تحت الغطاء، تقوم هذه الخدمات إما بتخزين المواد الرئيسية في HSMs مثل AWS KMS التي يمكن للمستخدم الوصول إليها فقط عبر بيانات اعتمادهم (Magic، Turnkey)، أو تعمل بموجب بعض نظام SSS/MPC (Privy، Web3Auth، Portal، Capsule) لحماية المواد.
يقوم Lit * بتحسين تصميم متجر المفتاح على الخادم هذا من خلال تجعيل المفاتيح. يخزن كل عقد في الشبكة جزءًا من مفتاح خاص ECDSA تم إنشاؤه عبر خوارزمية DKG، حيث تتم جميع العمليات في التجاهل الظاهري المشفر. يمكن تعيين قواعد مصادقة تعسفية لزوج المفتاح، مما يمنح التطبيق أو المستخدم التحكم الكامل في العمليات المسموح بها، وفرض حدود الإنفاق على سبيل المثال. يمكن استغلال الشبكة بشكل إضافي من قبل محافظ MPC بنسبة 2 من N كخيار للنسخ الاحتياطي واستعادة البيانات.
هذا العام، حدث تجربة سريعة للاستفادة من الموقعين الأجهزة ومفاتيح المرور كموقع للحساب لتقديم إدارة مفتاح المستخدمين بشكل فوري مع أجهزة الجوال أو سطح المكتب الحديثة. يعمل هؤلاء الموقعون بشكل طبيعي مع المصادقة البيومترية (مثل FaceID، TouchID) لتوفير أمان إضافي مع تجربة مستخدم مألوفة.
يستخدم Hardware Signers نظماً معزولة مثل iPhone Secure Enclave و Android Titan HSM لتوليد المفاتيح وتوقيع الرسائل، مما يضمن أمانًا على مستوى الأجهزة. نظرًا لعدم إمكانية استخراج المفاتيح من الجهاز، يعتبر هذا النظام الأكثر فاعلية عند استخدامه مع أساليب استعادة إضافية أو كجزء من نظام 2FA.
تعتبر مفاتيح العبور معيارًا للمصادقة بدون كلمة مرور يعتمد على نظام WebAuthn. هنا، يتم إنشاء زوج مفاتيح في نظام تشغيل الجهاز، ويمكن مزامنته عبر الأجهزة من خلال خدمات مثل iCloud، لذا يكون الاسترداد ممكنًا إذا اختار المستخدم القيام بذلك.
إحدى القيود هنا هي أن مفاتيح السرور والتوقيع الأجهزة المُنتَجة غير معترف بها بشكل أصلي من قبل سلاسل مثل بيتكوين وإيثيريوم. إذ يتم استخدام منحنى الإليبتيك secp256r1 (R1)، في حين تعمل هذه السلاسل بالتباين K1. بالرغم من أن هناك عملًا مستمرًا للتحقق من R1 بشكل موثوق وفعال، فإن بعض المنتجات التي تدعم مفتاح السر تمر عبر خدمات مثل ليت وتيرنكي لإنتاج توقيع K1 بمجرد موافقة المستخدم بمفتاحهم.
معيار يجب متابعته هو EIP-7212، الذي يقترح إضافة منحنى R1 مباشرة إلى EVM كعقد مُعدّ مُسبقًا بحيث يمكن لكل جهاز حديث توقيع المعاملات بشكل طبيعي دون الحاجة إلى خدمات الطرف الثالث أو الوسطاء.
مع زيادة حجم المعاملات المجردة عن الحساب، يمكن أن يؤدي تجميع التوقيعات باستخدام توقيعات BLS إلى تقليل رسوم الحساب الذكية بشكل أرخص من حسابات العقود الذكية على L2s. 4337 يحدد واجهة لعقود مساعد المجمع التي تقوم بالتحقق من توقيع مجمع واحد يوافق على عمليات مستخدم متعددة بدلاً من التحقق من كل واحدة على حدة.
المحفظة
المتوسطون (على سبيل المثال 4337 المجمعون) يقومون بنقل المعاملات أو عمليات المستخدمين إلى مجموعة ذاكرة مؤقتة. على السلاسل التي تحتوي على AA أصلية، يقوم مشغلو الشبكة والمتسلسلون بأداء هذا الدور، مما يُزيل الحاجة إلى المتوسطين المخصصين الخارجيين.
على غرار وجود تنفيذات عميل متعددة لـ Ethereum (على سبيل المثال، geth، erigon، reth)، فإن نظام 4337 يحتوي على تنفيذات حزمة متعددة بلغات مختلفة، مما يجعل الشبكة أكثر صلابة ضد الثغرات في تنفيذ واحد. تشمل مواصفات 4337 مجموعة اختبارات لضمان توافق حزمة البيانات عبر الشبكة. تشمل المنفذون Stackup (Golang)، Pimlico، Biconomy، Etherspot (Typescript)، Candide (Python)، OKX (Java)، و Alchemy (Rust).
نموذج الحوافز للمجمعين مماثل لبناة الكتل، حيث يأخذ الرسوم من عمليات المستخدم التي يجمعها بدلاً من المعاملات. في الممارسة، يحتاج المجمعون إلى واجهة برمجة تطبيقات إلى بنّاء الكتل لرؤية الكتلة الحالية وإنشاء حزمة تكون صالحة ضد تلك الكتلة وبالتالي يجب أن تُعتبر جزءًا من بنّاء الكتل.
مع نمو 4337 الجر معقول، يمكننا توقع أن يكون المُبنّون أيضًا مُجمّعين حيث سيكون هذا الهجين أكثر ربحية من المُبنّين وحدهم حيث يمكنهم اختيار من كل من حمامات الصفقة وحمامات المستخدم.
بايماسترز
تمكن Paymasters التجريب بواسطة السماح للتطبيقات اللامركزية برعاية الغاز للمستخدمين، مما يسمح للمستخدمين بدفع الرسوم باستخدام الرموز غير الأصلية، أو تسوية الأمور خارج السلسلة عبر قنوات الدفع التقليدية. تحتوي خدمات Paymaster على عنصرين رئيسيين:
مدير سياسة الغاز للمطورين لتحديد الشروط التي سيتبرعون بها بالغاز. يمكن تحديد هذا لمشروع بأكمله، أو على أساس كل عقد أو عنوان محفظة. يمكن للمطورين أيضًا تحديد كيف يرغبون في فرض قيود على تمويل الغاز على سبيل المثال عن طريق سعر الغاز، عدد الطلبات، أو المبلغ المتبرع به شهريًا. تكلفة تمويل الغاز عادة ما تدرج في فاتورة الشهرية للمطورين من مزود الخدمة مع رسم إضافي بنسبة ~5% على المبلغ المتبرع به.
يقوم عقد الدفع الذكي بالتحقق مما إذا كانت الصفقة المعطاة مؤهلة للتغطية، سواء على أساس حالة السلسلة مثل أرصدة الحسابات أو سياسات إدارة الغاز الخارجية. يحتوي عقد الدفع الذكي على رصيد من الرموز الأصلية التي تُستخدم لدفع تكاليف الغاز، وقد يحتوي على منطق أوراق البيانات السعرية التي تفحص بانتظام سعر صرف الرمز الدفع (على سبيل المثال USDC) والرمز الأصلي (على سبيل المثال ETH).
يمكن تصنيف أمناء الدفع إلى داخل السلسلة أو خارجها:
يعتمد Paymasters Onchain (مثل ERC20Paymaster، StablecoinPaymaster) فقط على حالة السلسلة للتحقق مما إذا كان بإمكان المعاملة أن تُغطى من قبل الـ paymaster أم لا. وهذا يعني أنه يمكن جعل بعض المدفوعات مثل تلك التي تقبل دفع الغاز بـ ERC-20s، الذي يمكن تقديمه دون إذن، مع الشرط أن يتمتع الـ paymaster بالموافقة من الحساب لتحويل الرموز الدفعية. يمكن لمسؤولي عقد Paymaster سحب الرموز وتحويلها مرة أخرى إلى العملة الأصلية لإعادة تعبئة العقد، ضبط هامش على أساس سعر ERC20، تحديد عتبة لفارق السعر الذي يُحدث الـ paymaster سعر ERC20 لعملية المستخدم التالية، أو تحديث السعر يدوياً.
مدفوعات السلسلة الجانبية (على سبيل المثال، VerifyingPaymaster) تشمل تفاعلات مع واجهة برمجة تطبيقات راعي خدمة مزود الخدمة لرعاية UserOp. يقوم الخدمة الجانبية بالتحقق من الأهلية والتوقيع على المعاملة باستخدام مفاتيح راعي الدفع. بينما تكون هذه الحلول ذات إذن، تأتي مدفوعات السلسلة الجانبية مع فوائد توفير الغاز من خلال تقليل الفحوصات على السلسلة. يمكن جعل سياسات الغاز أكثر تفصيلًا، وأخذ النشاط السلسلي مثل نشاط Discord في الاعتبار.
مصانع الحسابات والأطر
توفر مصانع الحسابات والأطر إمكانيات تنفيذ الحسابات الذكية "بدون رأس" ومجموعات تطوير البرمجيات التطبيقية التي يمكن لتطبيقات الويب اللامركزية وعملاء المحافظ بناءها عليها، مما يخلق حسابات مضمنة تحت تصرف المستخدمين لنفسهم. تعتبر الحسابات ذاتيًا محافظ عقود ذكية تتمتع بتحقق توقيعها الخاص، ومنطق تنفيذها، وحماية الإعادة (إدارة الرقم العشوائي). يقوم المالكون بالتصديق على عمليات المستخدم الناشئة من حساباتهم الذكية باستخدام مفتاحهم.
على مستوى عالٍ، يوفر بائعو الحسابات الذكية 3 أشياء أساسية:
تنفيذ أساسي لمحفظة عقد ذكي، مع منطقها الخاص لكيفية تحقق، تنفيذ المعاملات، وأي إجراءات إضافية للقيام بها قبل وبعد التنفيذ. كما تحتوي على منطق لكيفية إضافة ميزات إضافية إلى المحفظة عبر الوحدات الأساسية والطرف الثالث.
عقد مصنع ينشئ حالات جديدة من تنفيذ المحفظة، تم تنشيطه بالتوقيع الأولي لهذا الحساب. بموجب ERC-4337، يمكن لتطبيقات الويب اللامركزية إنشاء حسابات ذكية لمستخدميها عن طريق تحديد عنوان عقد المصنع من موفر خدمة الخيار الخاص بهم.
مجموعة أدوات توفر للمطورين إمكانية تخصيص واجهات متوافقة للحسابات الذكية التي يقومون بإنشائها. يمكن أن تشمل هذه الخيارات توقيع مختلف، وتقنيات التشغيل والإيقاف، والتقنيات الخاصة بالتوجيه.
تحت ERC-4337، الالمرسلحقل UserOp يشير إلى الحساب الذكي الذي تتم فيه المعاملة. إذا لم يتم نشر الحساب بعد، يقوم EntryPoint بنشر الحساب من عقد المصنع المحدد في initCode. يمكن استخدام مفاتيح المستخدم للمطالبة بالحساب الذكي لإجراء تفاعلات DApp اللاحقة.
مزودو الحسابات مثل Safe و Zerodev و Biconomy يدمجون مع مديري المفاتيح والبنية التحتية للمصادقة ليمنحوا تطبيقات الويب اللامركزية خيارات بشأن كيفية رغبتهم في إدارة حساباتهم الذكية. على سبيل المثال، يمكن لتكامل Web3Auth لـ Safe أن يمكن المستخدمين من استخدام حساباتهم باستخدام وسائل التواصل الاجتماعي أو البريد الإلكتروني، وتوفير خيار إدارة الحسابات بواسطة Passkeys من خلال تكامل Zerodev مع Turnkey.
المحفظة هي الأكثر شهرة لمنتج المحفظة الذكية التي تم اختبارها بشكل جيد والتي يستخدمها على نطاق واسع الأفراد والفرق ومنظمات السلطة اللامركزية. حتى الآن، تم نشر أكثر من 5 ملايين محفظة عبر أكثر من 12 سلسلة، تنفيذ أكثر من 22 مليون عملية. قبل الإصدار v1.4.1 (الذي تم إطلاقه في يوليو 2023)، كان بإمكان المطورين استخدام ريلي Gelato لتمكين عمليات التحويل المجردة للغاز. تقوم هذه الجمعية حاليًا بتشغيل منتجات بطاقات الخصم الرقمية مثل Gnosis Pay وBasedApp حيث يمكن للمستخدمين شراء من أي بائع يقبل فيزا باستخدام الأموال في محفظتهم. يقدم الإصدار v1.4.1 دعم ERC-4337 من خلال وحدات لتوفير خيارات إضافية في موفري الريلي.
صفر ديف هو مزود حساب ذكي تم إطلاقه في وقت سابق من هذا العام والذي تم بناؤه لـ ERC-4337 من البداية. يقوم زيرو ديف بتجميع مزودي الحزم المتعددين لتجريد خدمات ريلي UserOp، ويكشف لوحة تحكم مدير الغاز حيث يمكن للمطورين تحديد نطاق ومنطق تحديد حدود السعر لرسوم الرعاية للمستخدمين. يهيمن زيرو ديف و Biconomy (الذي يدير أيضًا شبكة الحزم الخاصة به) حاليًا على حصة السوق لحسابات 4337 الممكّنة.
تتميز حساب Alchemy's AccountKit بتنفيذ حساب ذكي متوافق مع 4337 "LightAccount"، والذي يعتمد على تنفيذ EF ويضيف دعم EIP-1271 (للتحقق من التوقيعات الناتجة من العقود الذكية) بالإضافة إلى نقل الملكية وتدوير المفاتيح وتخزين مساحة الأسماء.
وحدات الحساب
وحدات الحسابات هي عقود ذكية تعمل كمكونات قابلة للتثبيت على حساب ذكي. على الرغم من أن بنية الوحدة لا تزال في مراحلها الأولى جدًا، إلا أننا نتصور أنه ستكون الوحدات قابلة للاكتشاف والتثبيت بواسطة:
المطورون: يمكن أن تأتي الحسابات الذكية المضمنة مع وحدات "مثبتة مسبقًا" كما يقررها مطور تطبيق الويب اللامركزي، مما يؤدي إلى إنشاء محفظة بداية بميزات مخصصة لحالة استخدامهم
المستخدمون النهائيون: يمكن لواجهات المحفظة أن تكشف عن "متجر الوحدات" حيث يمكن للمستخدمين اكتشاف ميزات جديدة وإضافتها إلى محفظتهم
مع فصل AA رسمياً حول كيفية معالجة التحقق من صحة UserOp وتنفيذه، يمكن أن تحتوي الوحدات على منطق للتحقق فقط أو تنفيذ فقط.
المحققون. يتم استدعاؤهم أثناء مرحلة التحقق من عملية المستخدم. وظيفتهم الأساسية هي التحقق من توقيع عملية المستخدم وتحديد ما إذا كانت صالحة ويجب تنفيذها. تشمل الأمثلة التحقق المتعدد التوقيعات، ECDSA، مفاتيح العبور، التحقق متعدد السلاسل، ومفاتيح الجلسة. تتيح مفاتيح الجلسة للتطبيقات اللامركزية التوقيع نيابة عن المستخدم لتبسيط تجربة المستخدم، مع تصرف مثل مفاتيح خاصة مؤقتة مع صلاحيات قابلة للتخصيص ووقت انتهاء صلاحيتها.
المنفذون. يتم استدعاؤهم خلال مرحلة التنفيذ لعملية المستخدم. إنهم يوسعون منطق التنفيذ للحساب ويسمحون بمجموعة متنوعة أكبر من الإجراءات التي يمكنها القيام بها بشكل أصلي. وتشمل الأمثلة الإجراءات التلقائية التي تُشغل خارج تدفق التنفيذ العادي لـ ERC-4337 مثل تبادل الرموز تلقائيًا عندما يصل السعر إلى عتبة معينة.
يعمل الخطافات قبل أو بعد التنفيذ ويفرض controles ضد الحساب. على سبيل المثال، يمكن لخطاف أن يعمل بعد التنفيذ ويعيد أي معاملات تفي بمعايير معينة لتحقيق أمان متزايد للمستخدم.
بينما قامت بعض المحافظ مثل Candide بتطوير وحدات يمكن لمستخدميها تثبيتها مباشرة، نتوقع بيئة غنية من الوحدات من جهات خارجية التي يمكن اكتشافها في واجهة متجر التطبيقات الخاصة بمحافظهم، أو دمجها في محفظة مدمجة "بداية" من قبل مطوري التطبيقات اللامركزية.
تم تصميم أنظمة الحسابات الذكية بالفعل مع الوحدات في الاعتبار. يتعامل العقد الأساسي لـ Safe مع منطق إدارة الوحدات لإضافة وإزالة الوحدات من الحساب، لكنه يترك منطق الوحدة الفعلي والتخزين متعلقًا بالوحدة تمامًا محصورًا في عقد منفصل. يخفف هذا الفصل بين الاهتمامات من مخاطر أن تقوم الوحدات الخارجية بكتابة نفس الحالة، مما يعرض الأمان والسلوك المتوقع للحساب للخطر.
يقدم بروتوكول Safe{Core} إطارًا مفتوحًا يحتوي على وحدات، وخطافات، ومدير، وسجلات تهدف إلى تعزيز نظام الحسابات الذكية القابل للتركيب المستوحى من الدروس المستفادة من منتج المحفظة Safe.
يصنف ZeroDev صراحة وحداته ("المكونات الإضافية") على أنها تحقق من الصحة أو التنفيذ. تم تصميم وحدات المنفذ ليتم إقرانها بوحدات المدقق ، مما يسمح "بتوجيه" الوظائف المخصصة من خلال مدققين مختلفين. على سبيل المثال ، وظيفة "نقل NFT" التي تسمح فقط بنقل NFTs عبر المصادقة الثنائية (2FA).
بعض الاعتبارات في بناء نظام بيئي قوي من الحسابات الذكية القابلة للتعديل:
التوافق. مع عدة بائعين للحسابات الذكية كل منهم لديه نهجه الخاص لكيف يمكن للأطراف الثالثة إضافة ميزات جديدة إلى الحسابات ، فإن مطوري الوحدات في طريقهم نحو الانغلاق مع البائع أو الاضطرار إلى إدارة العبء التقني لتطوير نفس الميزات لتكون متوافقة مع تنفيذات الحسابات المتعددة. بعض الحلول للتخفيف من هذا:
يحدد ERC-6900 لحسابات العقود الذكية المعيارية والمكونات الإضافية واجهات حسابات العقود الذكية المعيارية (MSCAs) والوحدات النمطية ("المكونات الإضافية) مما يسمح لأي تطبيقات حساب متوافقة مع المعايير والمكونات الإضافية بأن تكون قابلة للتشغيل البيني مع بعضها البعض.
يوفر ModuleKit من Rhinestone لبناء واختبار وحدات الحساب الذكية قوالب وأطرًا لاختبار الوحدات ضد تنفيذات حساب مختلفة، ومكتبة للتكاملات (على سبيل المثال، بروتوكولات DeFi)، وشروط مُبنية مُسبقًا للتنفيذ، وأتمتة الأمان لتحليل كود الوحدة وتحديد الثغرات الأمنية.
الأمان. إعطاء المستخدمين القدرة على تثبيت البرمجيات من الطرف الثالث في محافظهم يأتي مع أسئلة مهمة حول كيفية يجب أن تقوم الواجهات بتنسيق وعرض معلومات ذات صلة حول الوحدات.
يوفر EIP-7484 وسيلة للتحقق من شرعية وأمان وحدات الحساب الذكية المبنية بشكل مستقل. هنا، يسمح سجل المراجعين للقيام بشهادات حول أمان تلك الوحدات. يمكن لواجهات المستخدم والحسابات الذكية الاستعلام عن السجل لاستدعاء بيانات الشهادة، للتحقق من أن الوحدة آمنة للاستخدام. انظر سجل الراينستون لتنفيذ مرجعي لهذا.
بشكل أوسع، يهدف EIP-7512 إلى إنشاء معيار لتمثيل على السلسلة لتقارير التدقيق يمكن تحليلها بواسطة العقود الذكية لاستخراج معلومات ذات الصلة حول من قام بالتدقيق والمعايير التي تم التحقق منها.
القابلية للكشف. يمكن تعريض السجلات واستعلامها عن طريق منصات الحسابات الذكية وواجهات المحافظ المثبتة من قبل المطورين أو المستخدمين النهائيين.
القدرة على توسيع وظائف المحفظة تحول الحسابات إلى منصات للمطورين وقنوات توزيع جديدة لمنتجات وخدمات web3. نحن بالفعل نرى هذا مع Metamask Snaps الذي يسمح للمستخدمين بتخصيص محفظة تمديد المتصفح الخاصة بهم مع تنبيهات الأمان (من خلال WalletGuard)، وميزات الخصوصية (من خلال Nocturne)، والتوافق مع سلاسل غير EVM مثل Starknet وBitcoin.
عندما أتاح Chrome بيئة للمطورين لتوسيع وظائف المتصفح من خلال الامتدادات، دفع ذلك بهم نحو الهيمنة على السوق فوق الحدائق المحيطة الحالية على الرغم من أنهم أصغر بعقد. على الرغم من أنه من الصعب على معظمنا تصور كيف قد تبدو تجربة المحفظة عندما تصبح الحسابات القابلة للتعديل شائعة، فإن المسارات بالفعل تُمهَّد لتأخذ الابتكارات غير المرخصة مجراها.
أنماط التطور الناشئة وتداعياتها
المحفظة المتطورة تعني ذلك:
يمكن للمطورين إنشاء حسابات غير تابعة للعميل لمستخدميهم في سياق تطبيقاتهم، وسيتطلعون إلى أدوات مثل مجموعات تطوير برامج تطبيقات لإعطائهم خيارات في كيفية بناء رحلة التسجيل من البداية إلى النهاية.
المحافظ المضمنة هي فئة جديدة من المحافظ، كل بائع لديه ميزاته الخاصة وتنازلاته من حيث قابلية نقل الحساب، وقابلية التخصيص، وافتراضات الثقة.
إذا قمت بالتلاعب بتطبيقات Ethereum في عام 2018، فقد تتذكر الحصول على نافذة منبثقة لـ Metamask بمجرد تحميل الموقع. كان ذلك بسبب نقص الممارسات الجيدة في تجربة المستخدم حول ربط المحافظ وتطبيقات الويب، وكان يلجأ المطورون في كثير من الأحيان إلى فحوصات البرمجة الصعبة لمعرفة ما إذا كان المستخدم قد قام بتثبيت محفظة الامتداد باستخدام متصفحهwindow.ethereumهذا أدى إلى سلوك غير متوقع إذا كان لدى المستخدمين عدة محافظ تمديد مثبتة، مما اضطر المستخدمين إلى اختيار واحدة وخلق سوق أقل تنافسية للمحافظ.
ظهر بروتوكول الاتصال WalletConnect* للسماح للمستخدمين بربط أي محفظة بأي تطبيق لامركزي، جنبًا إلى جنب مع Web3Modal، وهو مكتبة تغلف الأزرار ومكونات النموذج الظاهري للسماح للمستخدمين باختيار المحفظة التي يرغبون في استخدام التطبيق اللامركزي معها.
اليوم، يعتبر Web3Modal أحد مكتبات ربط المحافظ المتعددة مثل RainbowKit و Web3Onboard و ConnectKit التي تبسط عملية كشف المحفظة والمصادقة على أساس المحفظة لمطوري التطبيقات الموزعة. تقدم هذه المكتبات خيارات تصميم جاهزة، وميزات بحث عن المحافظ، وشاشات توجه المستخدمين لتثبيت المحافظ إذا لم يكن لديهم واحدة بالفعل.
في الآونة الأخيرة، تم الانتهاء من EIP-6963 كآلية بديلة لاكتشاف المحفظةwindow.ethereum، مما يسمح لتطبيقات الويب اللامركزية والنصوص المدخلة المقدمة من قبل الامتدادات بالتواصل بطريقة قابلة للتنبؤ. بفضل هذا الاستاندرد، يمتلك المستخدمون الآن خيارات أكثر في اختيار محفظة الامتداد المفضلة للاتصال بتطبيقات الويب اللامركزية، ويفتح سوقًا أكثر تنافسية للمحافظ.
بينما قد قامت مكتبات الاتصال بتحسين تجربة تطوير التطبيقات وتجربة المستخدم بشكل كبير، إلا أن التوقع بأن المستخدمين يمتلكون بالفعل أو سيقومون بتثبيت برامج إضافية للتفاعل مع التطبيقات اللامركزية ما زال يشكل عائقًا كبيرًا أمام الاعتماد.
نحن بالفعل نرى لمحة عما سيبدو عليه مستقبل تجربة مستخدم تطبيقات القرصنة، حيث تقوم الجيل القادم من مكتبات المحفظة، التي سنطلق عليها هنا "مجموعات تطبيقات SDK الكاملة"، بالانتشار. بالإضافة إلى المصادقة القائمة على المحفظة، توفر هذه SDKs خيارات بديلة للتسجيل وتسجيل الدخول مثل البريد الإلكتروني ووسائل التواصل الاجتماعي والرسائل القصيرة، وتنشئ محافظ مضمنة للمستخدمين بدون الحاجة لتثبيت برامج إضافية أو الانتقال بعيدًا عن تطبيق القرصنة.
يمكن للمطورين دمج الموصلات المقدمة من قبل مقدمي المفاتيح مباشرة (على سبيل المثال Magic، Privy، Web3Auth) أو استخدام تلك التي تلف خدمات متعددة (على سبيل المثال Dynamic، Thirdweb، 0xPass) لتوفير خيارات توصيل وتشغيل على الخيارات المصادقة التي يريدون تعريضها ونوع المحفظة التي يريدون إنشائها، مخصصة تمامًا لتخصيص تدفق الانضمام. يمكن أن تدمج مجموعات تطوير البرمجيات لتسجيل الدخول أيضًا مع موفري الحسابات الذكية لإنشاء محافظ ذكية مضمنة، مما يقدم تحسينات تجربة المستخدم الإضافية مثل المعاملات بدون رسوم وممرات الدخول والخروج.
مع ازدياد اعتماد "المحافظ الرأسية" والحركة نحو المحافظ المضمنة، بدأ الفصل الواضح بين المحافظ والتطبيقات اللامركزية في التلاشي.
المحافظ المستقلة مقابل المحافظ المضمنة مقابل المحافظ ذات التطبيقات
مستخدمو Web3 اليوم معتادون على التفاعل مع تطبيقات الويب اللامركزية من خلال محافظ مستقلة مثل Metamask أو تلك المقدمة من خلال WalletConnect، متراكمين أصولهم وبصمتهم على السلسلة الزمنية لحساب واحد أو عدة حسابات.
كلما ازداد عدد التطبيقات اللامركزية التي تبحث عن جذب المستخدمين من خلال المحافظ المضمنة والعديد من البائعين المتاحين، يصبح إدارة الحسابات معقدة بسرعة لكل من مطوري التطبيقات اللامركزية والمستخدمين النهائيين. سيضطر مطورو التطبيقات اللامركزية إلى تقييم وإدارة العديد من البائعين محاولين تجنب الاحتجاز. بالنسبة للمستخدمين النهائيين، إنشاء محفظة جديدة لكل تطبيق لامركزي سيؤدي إلى تجزئة تجربة إدارة الأصول والهوية.
في حين أن المحافظ التي تخصص التطبيق مرغوب فيها لبعض حالات الاستخدام مثل الألعاب، إلا أن هناك العديد من الحالات التي قد يقوم فيها المستخدمون بالانضمام إلى تطبيقهم الأول، وإنشاء محفظة مضمنة مع موقع التوقيع الخاص بهم أو المفتاح السري، ويرغبون في استخدام الأصول التي يجنونها في تلك الحساب على تطبيق آخر عن طريق تسجيل الدخول بنفس الموقع التوقيع.
Capsule هو موفر محفظة مدمجة قائم على تقنية MPC والذي يتميز بقابلية نقل المحفظة عبر تطبيقات الويب اللامركزية التي تستخدم خدماتهم، مما يمنح المستخدمين الوصول إلى محفظة موجودة باستخدام نفس تسجيل الدخول بالبريد الإلكتروني. يمكننا توقع أن يكون هذا قريبًا عرضًا أساسيًا عبر مزودي خدمات الويب اللامركزية.
يساعد Moonchute المستخدمين على إدارة عدة حسابات ذكية مؤقتًا. مدير حساباتهم الموحد هو تطبيق وواجهة برمجة تطبيقات لاكتشاف محافظ ذكية تم إنشاؤها بواسطة الموقع الذي تم منحه، مما يتيح للمستخدمين إدارة الأصول من حسابات متعددة في مكان واحد.
يقترح ERC-7555 واجهة موحدة مستوحاة من SSO ونمط طلب/استجابة لتطبيقات لاكتشاف حسابات المستخدمين التي تم إنشاؤها باستخدام مخططات تسجيل بديلة. هنا، سيقوم التطبيق بإعادة توجيه المستخدم إلى عنوان URI المعطى لمزود معين (والذي يمكن أن يكون نطاقًا مستضافًا ذاتيًا)، وتحليل الاستجابة للحصول على موقع توقيع وعنوان الحساب الذكي المرتبط.
التحول من EOAs
تحدي آخر بارز لشركة AA هو الطريقة السلسة للمستخدمين الحاليين، الذين لديهم بالفعل أصول وتاريخ سلسلة كتل متراكمة على العديد من حسابات العقود الذكية، للانتقال إلى الحسابات الذكية.
EIP-7377 يقترح آلية في البروتوكول للسماح لحسابات الأفراد ذوي الصلاحيات الخاصة بإرسال عملية تحويل لمرة واحدة تنشئ الشيفرة في حسابهم، مما يُسهّل "ترقية" حساب فردي ذو صلاحيات خاصة إلى محفظة ذكية.
تهدف Aarc إلى حل مشكلة هجرة الأصول لتطبيقات الويب اللامركزية والمستخدمين النهائيين. يُفهم واجهة المستخدم الخاصة بهم وفهارس SDK الأصول والصلاحيات لعنوان المصدر المحدد، ويسمح للمستخدمين بتحديد الأصول التي يرغبون في نقلها إلى أي عنوان وجهة، والذي يمكن أن يكون حساب ذكي، أو عنوان EOA آخر، أو محفظة MPC مضمنة تم إنشاؤها باستخدام تسجيل الدخول الاجتماعي. بالنسبة لتطبيقات الويب اللامركزية التي تمتلك مستخدمين قائمين يعتادون على سير تشغيل المحفظة المستقلة، تقدم Aarc حلاً لتبسيط عملية الهجرة حيث تسعى إلى إضافة محافظ مضمنة أو ميزات AA إلى منتجها.
تداعيات AA على إدارة الحساب متعدد السلاسل
نظرًا لزخم النشاط في AA و L2، يمكننا توقع مستقبل حيث تصبح الحسابات الذكية شائعة على حسابات العقود الذكية الخارجية مع المستخدمين الذين لديهم أصول عبر عدة سلاسل.
ميزة واحدة لتجربة المستخدم الخاصة بحسابات الإيثريوم الخارجية هي أن المستخدمين يمتلكون تلقائيًا نفس العنوان عبر سلاسل EVM مختلفة باستخدام نفس المفتاح الخاص. العيب يكمن في أنه ليس من الممكن تغيير المفاتيح التي تتحكم في عنوان معين، ويمكن أن تضيع جميع الأموال إذا فقد المستخدم مفتاحه الخاص.
نظرًا لأن التجريد الحسابي يفصل متجر المفتاح عن متجر الأصول، يمكن تدوير المفاتيح لحساب معين دون الحاجة إلى ترحيل الأموال مع الاحتفاظ بنفس العنوان. الحسابات الذكية قادرة على الحفاظ على نفس العنوان عبر الشبكات باستخدام CREATE2، مما يمنح المستخدمين الوصول إلى الحساب حتى لو لم يتم نشر العقد على سلسلة معينة بعد باستخدام نفس المفتاح التحقق الأولي وتنفيذ الحساب.
ومع ذلك، قد يكون الاحتفاظ بنفس العنوان عبر سلاسل مختلفة نمطًا ضارًا على المدى الطويل.
إن إنشاء 2 ممكن فقط على السلاسل ذات التكافؤ لبايت الشيفرة التنفيذية للآلة الظاهرية. في عالم متعدد السلاسل مع zk-Rollups (على سبيل المثال zkSync) مع انحرافات طفيفة إلى الآلة الظاهرية، لن تكون هذه الطريقة كافية.
يمكننا توقع أن المفاتيح اللازمة للوصول إلى الحسابات المختلفة ستتغير مع مرور الوقت مع تعريض المحافظ إلى ميزات توقيع وتدوير مفاتيح إضافية. في الإعداد الحالي، يمكن أن يتسبب ذلك بسرعة في تسبب تغيير حالة أذونات الحساب عبر السلاسل، حيث لا تنتقل التغييرات إلى الموقعين على حساب في سلسلة واحدة تلقائيًا إلى تلك في السلاسل الأخرى.
الحلول طويلة الأجل التي تم اقتراحها لشبكة AA متعددة السلاسل تشمل:
عقد مخزن مفتاح مخصص يقوم حساب مستخدم عبر السلاسل بقراءته عند التحقق من الأذونات. انظر إلى تنفيذ هذا من محفظة الروح.
استخدام حلول ENS متعددة السلاسل كطبقة تجريد لعناوين مختلفة.
إدارة حساب ومفتاح توقيع عبر السلاسل لا تزال مجالًا يخضع للبحث النشط. الهدف النهائي هنا هو أن يتمكن المستخدم من تغيير المفاتيح التي تمتلك وصولًا إلى حسابات متعددة على سلاسل مختلفة دون إجراء عدد هائل من المعاملات.
الاستنتاج والأفكار الختامية
تجريد الحساب هو حركة لفصل الموقعين عن الحسابات من خلال جعل الحسابات القائمة على العقد (بدلاً من EOAs) ككيانات من الدرجة الأولى على سلسلة الكتل، مما يمنح المستخدمين مرونة في إدارة المفاتيح وتصريح الحساب.
ERC-4337 كمعيار لإعادة توجيه المعاملات الذكية التي بدأتها الحسابات قد حفز تطور بنية الجيب لاستيعاب AA، مما أدى إلى ظهور هياكل سوق جديدة وفئات جيب جديدة وتطوير dapp وأنماط انضمام المستخدمين.
تم فك تجميع مكدس المحفظة إلى الموقعين، والمعادين، ومزودي الحسابات ووحدات الحسابات مما يمنح المطورين خيارات في كيفية تخصيص تجربة المستخدم النهائية. يأتي هذا مع التكلفة الإضافية لتقييم كل مزود من حيث التضحيات فيما يتعلق بتكاليف الغاز الزائدة، ومقاومة الرقابة، وقفل البائع، وقابلية التشغيل.
مسارات الهجرة من حسابات التنفيذ الخارجية والتجريد الحسابي في سياق متعدد السلاسل لا تزال مجالات بحث مستمرة. نتوقع رؤية أولى تنفيذات الحلول المقترحة في العام القادم.
نحن نعتقد أن هذه التطورات لها تأثيرات كبيرة عبر النظام البيئي:
بالنسبة للمستخدمين الجدد، لم تعد المحافظ الوحيدة نقطة الدخول الوحيدة إلى web3. ستكون التطبيقات قد تحسنت بشكل كبير في عملية الانضمام من خلال المحافظ المضمنة، والمعاملات بدون رسوم، ونقاط الوصول في المحفظة.
بالنسبة للمستخدمين الحاليين، ستصبح التجارب على السلسلة الكتلية أكثر سلاسة مع استفادة التطبيقات من ميزات مثل مفاتيح الجلسة. يحصل المستخدمون على تحكم دقيق أكثر في أذونات الحساب وميزات المحفظة الإضافية من خلال الوحدات.
بالنسبة للمطورين، تحويل البنية التحتية للحسابات إلى وحدات يتيح للمحافظ أداء وظائف نظام التشغيل. أسواق الوحدات هي قناة توزيع جديدة بدون إذن لمنتجات وخدمات web3.
سيستمر البنية التحتية للمحفظة في تحفيز اعتماد web3. نحن في 1kx نفخر بدعم الفرق التي رائدت في الأفكار التي ناقشت في هذه المقالة، وسنستمر في مراقبة المساحة لما هو قادم.
إذا كنت تعمل على حلول في هذا المجال أو لديك أفكار إضافية حول الموضوع، يرجى التواصل@nichanank - سأحب الدردشة معك.
العديد من الشكر لديفيد سنيدر، جون رايزينج، كونراد كوب، كورت لارسن، مارك سدناوي، دوغان ألبارسلان، فيفيان فونغ، ديريك رين، توم تيرادو، ديانا بيغس، ميل كوارتو، وبيتربان على مراجعة مسودات هذا.
*يشير إلى شركات محفظة 1kx
بيان:
- هذه المقالة مأخوذة من[1kx]، حقوق الطبع والنشر محفوظة للكاتب الأصلي[1kx]، كما أنه يتوجب على الأشخاص الذين يعارضون إعادة النشر الاتصالفريق Gate Learn، سيقوم الفريق بمعالجة العملية ذات الصلة في أقرب وقت ممكن.
- 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
- النسخة باللغة الأخرى من قبل فريق Gate Learn، عندما لم يتم ذكرهاGate.ioفي حالة عدم السماح بنسخ أو نشر أو اقتباس المقالات المترجمة.
مقالات ذات صلة
كيف تعمل بحوثك الخاصة (Dyor)؟
ما هو سولانا？