سلسلة مبتدئي Web3: هل يمكن أن يؤدي النقر على MetaMask إلى استدعاء محفظة أخرى؟ حالة حل الصراع في المحفظة

الفوضى عند استدعاء المحفظة

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

المحفظة

تخيل سيناريو يقوم فيه مستخدم Web3 جديد (قام بتثبيت محافظ بها أطول مكونات إضافية بدافع الفضول) ، بزيارة موقع ويب DApp ، ويريد استخدام محفظة المكونات الإضافية للمتصفح للاتصال بها ، ولكن عندما ينقرون على زر “Connect المحفظة” الذي يوفره موقع الويب ويختارون محفظة بحيث يرغبون في استخدامها للاتصال DApp ، قد يجدون أن المحفظة المنبثقة ليست اختيارهم. من المحتمل أن يجعله هذا يشعر بالارتباك والاختناق ، معتقدا أن جهاز الكمبيوتر الخاص به به فيروس ، لذلك يقوم بعمل لم يكن يتوقعه.

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

في منطق تنفيذ محفظة المتصفح الحالي، يتم حقن متغيرات عامة إلى المتصفح لتعريض الوظائف المقدمة من المحفظة (على سبيل المثال، ستقوم محفظة منصة إثيريوم بحقن وظائفها في “ethereum”)، لتمكين التطبيقات اللامركزية من استدعاء الوظائف المقدمة من المحفظة للتفاعل معها.

ومع ذلك، نظرًا لأن العديد من المحافظ ستقوم بحقن نفسها في نفس المتغير ethereum، فإن ذلك يؤدي إلى أن المحافظ المُسجَّلة في وقت لاحق ستقوم بتغطية المحافظ المُسجَّلة سابقًا، بحيث يمكن استدعاء آخر محفظة تم تسجيلها فقط بهذه الطريقة.

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

قد يتساءل بعض الأصدقاء لماذا يجب حقًا حقنها في نفس المتغير؟ فلنفترض أن هناك محفظتان: A و B ، في الواقع فقط عندما يقوم A بحقن نفسه في ‘a’ ، ويقوم B بحقن نفسه في ‘b’ ، فإنه يمكن استدعاء المحفظة التي ترغب في تشغيلها عن طريق استدعاء الطرق المقدمة في الكائن المقابل ، ولن يحدث مشكلة تشغيل B بدلاً من A. هذا بالفعل يمكن أن يحل مشكلة التنافس ، ولكن المشكلة هي أنه إذا كان DApp يرغب في دعم العديد من اتصالات المحفظة ، فيجب تعريف جميع أسماء المحافظ التي يرغب المطور في تكييفها مسبقًا في الكود وأثناء تحديد المستخدم لمحفظة معينة ، يتم استدعاء الطرق ذات الصلة لتلك المحفظة ، مما يتسبب في صعوبة كبيرة في صيانة الكود ذي الصلة. بينما حقن المحفظة في كائن واحد يمكن تجنب هذه المشكلة.

حلول

للخروج من هذا الوضع المأزوم ، هناك اثنين من المعايير المشابهة في المجتمع.

حلول إيثيريوم: EIP-6963

اقترح مجتمع إثيريوم EIP-6963 في مايو 2023.

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

بشكل محدد، بمجرد أن يتم تحميل محفظة المكون الإضافي بنجاح، يتم إطلاق حدث “eip6963:announceProvider” الذي يعلم DApp بأن هناك محفظة جديدة متاحة. وبينما يقوم DApp بالاستماع إلى هذا الحدث، يعرف بأنه يمكنه استخدام أي محفظة حالياً.

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

معيار المحفظة: معيار المجتمع

EIP-6963 هو معيار البيئة الإيثيريومية ، ولكن ليس فقط الإيثيريوم ، فستواجه منصات السلسلة الأخرى مشكلات مماثلة. على سبيل المثال ، ستقوم محافظ سلسلة Solana بحقن نفسها على متغير “solana” ، مما يؤدي إلى حالة من المنافسة.

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

المحفظة القياسية تقوم بالعمل الأساسي من خلال توفير وظيفتين: “registerWallet” و “getWallets”، الأولى تستخدم للمحفظة، والثانية تستخدم لـ DApp.

يتم استدعاء المحفظة باستخدام “registerWallet” ، ويتم تمرير كائن محفظة يقوم بتغليف الوظائف التي تقدمها المحفظة (مثل طريقة الاتصال ، والتي تستخدم للاتصال بالمحفظة) إلى الدالة. يتم تشغيل حدث “RegisterWalletEvent” داخل الوظيفة ، والذي يتم تمرير وظيفة رد الاستدعاء كمعلمة ، والتي يتم استخدامها لل Permite DApp للاستماع إلى حدث “RegisterWalletEvent” واستدعاءه عند الحاجة. والوظيفة الفعلية لهذه الوظيفة هي نقل كائن المحفظة ، حتى يمكن لـ DApp الحصول على مرجع لكائن المحفظة والتفاعل معه.

ليس من الضروري أن يقوم مطورو DApp بكتابة الشفرة للاستماع واستقبال كائن المحفظة بأنفسهم ، فقد تم دمج هذا الجزء بالفعل في Wallet Standard في “getWallets”. ومع ذلك ، يقوم getWallets بمجرد الاستماع للأحداث ، والمطور لا يزال مسؤولاً عن كيفية معالجة هذه الأحداث. على سبيل المثال ، أين يتم وضع المحافظ التي تم الحصول عليها؟ بعض المحافظ قد تم تحميلها قبل تحميل DApp ، بينما قد يتم تحميل بعض المحافظ في وقت لاحق ، فكيفية الحفاظ على حالة هذه المحافظ؟ بالنسبة لهذه التفاصيل ، يقدم Wallet Standard أيضًا حزمة “@wallet-standard/react” ، حيث يمكن للمطورين استخدامها مباشرة للحصول على البيانات المطلوبة ، بما في ذلك قائمة المحافظ ، والمحفظة المتصلة حاليًا ، والوظائف التي تقدمها المحفظة وغيرها.

ميزات محفظة قياسية

بالإضافة إلى الحصول على كائن محفظة الأساسي، يحدد معيار المحفظة أيضًا بعض تنسيقات الميزات.

في الواقع، جميع المحافظ تحتوي على بعض الوظائف الأساسية مثل الاتصال ومراقبة أحداث المحفظة. يوفر معيار المحفظة “standard:connect” و “standard:events” وظائف أخرى. بمجرد تنفيذ مزود المحفظة لهذه الخصائص، يمكن لتطبيق DApp تحديد ما إذا كانت المحفظة تدعم بعض العمليات مباشرة استنادًا إلى هذه القيم.

المذكور أعلاه “standard:*” هو الخصائص المحددة داخليًا ، في الواقع ليس لديها متطلبات صارمة خاصة بقيمها ، لذلك يمكن توسيعها بحرية. قد تحتوي منصات السلاسل المختلفة على خصائص فريدة ، مثل Solana ، حيث يتم التوافق مباشرة على “solana:*”. تشمل ميزات منصة Solana الشائعة “solana:signTransaction” ، “solana:signMessage” الخ.

حالة معيار المحفظة

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

في محول Solana لـ Ant Design Web3 ، تم دعم كشف المحفظة التي تم تكييفها لمعيار المحفظة أيضًا ، حيث يحتاج المطورون في الأساس فقط إلى تمكين “autoAddRegisteredWallets” دون الحاجة إلى تكوين مجموعة كبيرة من بيانات المحفظة ، مما يؤدي إلى تحسين تجربة التطوير وتجربة استخدام المستخدم بشكل كبير.

تعرضت منطق الارتباط ZAN.TOP بمحفظة العملات الرقمية لنفس المشكلة في وقت مبكر، ولكن الآن، بفضل التكوين المقدم من قِبَل Ant Design Web3، تم تكييفه بسهولة مع المعيار EIP-6963. يجب أن يكون الجميع قد شعروا بهذا عند ربط العنوان _wxdyh.

تحقيق بيئة سلسلة الكتل لكل منطقة

حاليًا، ليس لدى منصات سلسلة الكتل توجهًا موحدًا تجاه معيار Wallet Standard (أو EIP-6963)، هنا بعض الأمثلة:

بيتكوين

حتى الآن، يبدو أن لا يوجد معيار مماثل لبيتكوين، هناك مشروع يتبع معيار Wallet Standard ولكنه لم يحظ بالكثير من المتابعة ولم يتم تقديم أي كود جديد منذ فترة طويلة.

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

إيثريوم

منصة إيثيريوم لديها بالفعل معيار EIP-6963، وقدمت معظم المكتبات والمحافظ الدعم.

Solana

كما هو مذكور في النص أعلاه، قدمت الشركة تنفيذًا:

سوي

Sui حاليا قدمت تنفيذًا لمعيار Wallet Standard، يمكن العثور على كيفية الاستخدام في الوثائق الرسمية:

دعم مكتبة تطوير تطبيقات اللامركزية

واجمي

وقد قدم wagmi دعمًا لـ EIP-6963 من خلال مكتبة mipd()، يمكنك الاطلاع على التفاصيل في وثائق wagmi.

رينبو كيت

يعتمد منطق RainbowKit () الداخلي على wagmi ، لذلك تم دمج الدعم المضمن لـ EIP-6963 أيضًا.

تصميم النملة ويب3

أداة Ant Design Web3 أجرت دعمًا جيدًا جدًا لكل من Ethereum و Solana في هذين المعيارين ، ويعد الفتح المطورين مريحًا للغاية.

بالنسبة لمطوري تطبيقات الويب اللامركزية (DApp) على منصة إثيريوم (Ethereum) ، يكفي إضافة تكوين eip6963 ، وتنبيه: الجزء المتعلق بـ EIP-6963 يمكن العثور عليه في السطور 23-25:

وإذا كنت مطورًا لتطبيقات DApp في بيئة Solana ، فإن الطريقة مشابهة أيضًا. إنه يوفر خاصية autoAddRegisteredWallets:

ملخص

EIP-6963 و Wallet Standard يمكن أن تحسن بشكل كبير تجربة المستخدم في الاتصال بالمحافظ، وتقليل عتبة الدخول لمزودي المحافظ الجديدة. نأمل في المستقبل أن تتمكن المزيد من منصات السلاسل ومطوري المحافظ وDApp من توفير أو تنفيذ المعايير ذات الصلة، مما يسهم في تطوير Web3 في اتجاه أفضل.

كتب هذا المقال من قبل gin-lsl من فريق ZAN (X الحساب الرسمي @zan_team).