الارتباك عند استحضار المحفظة
يعد توصيل المحفظة خطوة أساسية لدخول عالم Web3 غالبًا ما يحتاج المستخدمون إلى أن تكون المحافظ متصلة ببعض مواقع DApp. ومع ذلك، فإن هذا الإجراء البسيط يمكن أن يسبب أيضًا إزعاجًا خطيرًا للمستخدمين.
ربط المحفظة
تخيل هذا السيناريو: مستخدم Web3 جديد (بدافع الفضول، قام بتثبيت العديد من محافظ المكونات الإضافية) ، قاموا بزيارة موقع ويب DApp معين وأرادوا استخدام محفظتهم الإضافية الخاصة بالمتصفح للاتصال به، ولكن عندما نقروا على زر "Connect Wallet" الذي يوفره موقع الويب وقاموا بتحديد محفظة معينة لاستخدامها عند الاتصال بمحفظة DApp، قد تجد أن المحفظة المنبثقة ليست هي المحفظة التي حددتها. وهذا ما قد يجعله يشعر بالذعر والاختناق، معتقداً أن جهاز الكمبيوتر الخاص به مصاب بفيروس، فيقوم بأفعال لم يكن يتوقعها.
تعد محفظة Blockchain مدخلاً مهمًا إلى blockchain، ومن أجل احتلال هذا المدخل، تستخدم كل محفظة كل طريقة يمكن أن تفكر فيها. من بينها، الشيء الأكثر إزعاجًا لمطوري التطبيقات اللامركزية ومستخدمي التطبيقات اللامركزية هو التلاعب بالمتغيرات العامة بواسطة كل محفظة.
في منطق تنفيذ محفظة المتصفح الحالي، يتم الكشف عن الوظائف التي توفرها المحفظة عن طريق حقن المتغيرات العامة في المتصفح (على سبيل المثال، محفظة منصة Ethereum سيتم حقن الوظائف التي توفرها في " window.ethereum ") حتى يتمكن DApp من استدعاء الأساليب التي توفرها المحفظة للتفاعل معها.
ومع ذلك، نظرًا لأن العديد من المحافظ ستدخل نفسها في نفس متغير window.ethereum، فإن المحفظة المسجلة لاحقًا ستحل محل المحفظة المسجلة مسبقًا يمكن استحضار المرء بهذه الطريقة.
في بعض الأحيان، من أجل استخدام المحفظة التي يريدون استخدامها بشكل طبيعي، يتعين على مستخدمي DApp تعطيل المكونات الإضافية الأخرى للمحفظة مؤقتًا، أو تثبيت محفظة معينة فقط مباشرة . وبهذه الطريقة، فهي مختلفة تمامًا عن الفكرة الأولية لمطور المحفظة. وحتى إذا كانت المحفظة الجديدة تعمل بشكل أفضل، فسيكون من الصعب جذب المستخدمين الذين يستخدمون محافظ أخرى بالفعل.
قد يتساءل بعض الأصدقاء، لماذا يجب حقنهم في نفس المتغير؟ لنفترض أن هناك محفظتين: A وB. في الواقع، طالما أن A تقوم بحقن نفسها في " window.a" وB تقوم بحقن نفسها في " window.b"، أيًا كانت المحفظة التي تريد الاتصال بها، اتصل بها الكائن المقابل. باستخدام الطريقة المتوفرة في ، لن تحدث المشكلة المذكورة أعلاه المتمثلة في الرغبة في الاتصال بـ A ولكن الاتصال بـ B بدلاً من ذلك. يمكن أن يحل هذا بالفعل مشكلة المنافسة، ولكن المشكلة هي أنه إذا كان التطبيق اللامركزي يدعم اتصالات المحفظة المتعددة، فيجب أن تكون جميع أسماء المحفظة التي يريد المطور تكييفها محددة مسبقًا في الكود، وعندما يحدد المستخدم اسمًا معينًا عند الإدخال محفظة، اتصل بالطرق ذات الصلة بالمحفظة. نتيجة لذلك، من الصعب جدًا الحفاظ على الرموز ذات الصلة. ومن خلال حقن المحفظة في نفس الكائن بشكل موحد، يمكن تجنب هذه المشكلة.
الحل
للتخلص من المعضلة المذكورة أعلاه، هناك معضلة متشابهة في معيار المجتمع
حل Ethereum: EIP-6963
تم اقتراح مجتمع Ethereum في عام 2023 EIP-6963 المقترحة في مارس.
المنطق الأساسي بسيط للغاية، وهو التخلي عن المتغيرات العامة واستخدام الأحداث المتفق عليها بدلاً من ذلك لحل مشاكل تسجيل المحفظة واكتشافها.
على وجه التحديد، بعد تحميل محفظة المكون الإضافي بنجاح، يتم تشغيل حدث موحد " eip6963:announceProvider " لإعلام التطبيق اللامركزي بوجود محفظة جديدة متاح. يستمع DApp إلى هذا الحدث لمعرفة المحافظ المتاحة له حاليًا.
وبهذه الطريقة، ومن خلال مجموعة من منطق الاستماع للأحداث المجردة، يتم تجنب المشكلات الناجمة عن الاستخدام المباشر للمتغيرات العامة، ويمكن للمحافظ المتاحة في بيئة المستخدم الحالية يتم اكتشافها تلقائيًا. وبهذه الطريقة يتم حل المعضلة.
معيار المجتمع: معيار المحفظة
EIP-6963 هو المعيار البيئي لإيثريوم، لكنه ليس فقط Ethereum ومنصات السلسلة الأخرى ستواجه مشاكل مماثلة. على سبيل المثال، ستحقن المحافظ الموجودة في سلسلة Solana نفسها عمومًا في المتغير " window.solana "، مما سيؤدي أيضًا إلى المنافسة.
هل يمكن لنظام Solana البيئي أيضًا تنفيذ هذا المعيار؟ على الرغم من أن EIP-6963 مصمم فقط لحل مشكلة اكتشاف المحفظة في نظام Ethereum البيئي، إلا أن الأفكار الواردة فيه يمكن تطبيقها فعليًا على جميع منصات السلسلة. لذا، هل يمكننا المضي قدمًا خطوة أخرى وتوفير مجموعة مشتركة من المعايير التي يمكن تنفيذها بواسطة المحافظ والتطبيقات اللامركزية على جميع منصات blockchain، بحيث يمكن للمطورين والمستخدمين لجميع منصات السلسلة الاستمتاع بالراحة التي يوفرها EIP-6963؟ من الناحية النظرية، لا توجد مشكلة على الإطلاق، وهناك بالفعل مطورون يقومون بذلك، وهم Wallet Standard.
العمل الأساسي لـ Wallet Standard هو توفير وظيفتين: "registerWallet " و"getWallets". تستخدم للتطبيقات اللامركزية.
تستدعي المحفظة " registerWallet"، لتمرير كائن المحفظة، والذي يقوم بتغليف الوظائف التي توفرها المحفظة (مثل طريقة الاتصال، المستخدمة للاتصال إلى المحفظة). سيتم تشغيل حدث RegisterWalletEvent داخل الوظيفة. معلمة الحدث هي في الواقع وظيفة رد اتصال، والتي يتم استخدامها للاتصال عندما يستمع DApp إلى حدث RegisterWalletEvent. سوف تمر وظيفة رد الاتصال هذه بالفعل في كائن المحفظة، لذلك يمكن لـ DApp ذلك احصل على مرجع المحفظة، يمكنك التفاعل مع المحفظة.
لا يحتاج مطورو التطبيقات اللامركزية إلى كتابة التعليمات البرمجية لمراقبة واستلام كائنات المحفظة بأنفسهم. وقد تم أيضًا دمج هذا الجزء في " getWallets " بواسطة Wallet Standard. ومع ذلك، يستمع getWallets للأحداث فقط، ولا يزال المطورون بحاجة إلى التفكير في كيفية التعامل مع الأحداث. على سبيل المثال، أين يجب وضع المحافظ التي تم الحصول عليها؟ يتم تحميل بعض المحافظ قبل تحميل التطبيق اللامركزي، بينما قد يتم تحميل المحافظ الأخرى بعد ذلك. كيف يتم الحفاظ على حالة هذه المحافظ؟ توفر Wallet Standard أيضًا حزمة "@wallet-standard/react " للمشكلات المفصلة أعلاه. ويمكن للمطورين استخدام React Hooks التي توفرها مباشرةً للحصول على البيانات المطلوبة، بما في ذلك قائمة المحفظة والمحفظة المتصلة حاليًا والطرق التي يوفرها. المحفظة، الخ.
ميزات المحفظة القياسية
بالإضافة إلى أبسط الميزات الوصول إلى Wallet بالإضافة إلى الكائنات، تحدد Wallet Standard أيضًا بعض تنسيقات الميزات.
في الواقع، تحتوي المحافظ على بعض الوظائف الأساسية، مثل الاتصال والاستماع إلى أحداث المحفظة وما إلى ذلك. يوفر Wallet Standard ميزات مثل "standard:connect" و"standard:events ". بعد أن يقوم موفر المحفظة بتنفيذ هذه الميزات، يمكن لتطبيق DApp تحديد ما إذا كانت المحفظة تدعم عمليات معينة مباشرةً بناءً على هذه القيم.
"المعيار:*" المذكور أعلاه هو خصائصه المحددة المضمنة. في الواقع، لا تحتوي قيمها على متطلبات قوية بشكل خاص يمكن توسيعها في الإرادة. سيكون لمنصات السلسلة المختلفة أيضًا خصائصها الفريدة. على سبيل المثال، Solana، ما عليك سوى الاتفاق على "solana:*". تشمل الميزات الشائعة لمنصة Solana "solana:signTransaction"، و"solana:signMessage"، وما إلى ذلك.
الحالة الحالية لمعيار المحفظة
يتم تطبيق معيار المحفظة حاليًا في الواقع لا يوجد الكثير من المشاريع، لكن سولانا وسوي جديران بالذكر.
في محول Solana الخاص بـ Ant Design Web3، يتم أيضًا دعم الاكتشاف التلقائي للمحافظ التي تم تكييفها مع Wallet Standard، ويحتاج المطورون بشكل أساسي فقط إلى تمرير " autoAddRegisteredWallets ". " فقط قم بتشغيله. ليست هناك حاجة لتكوين الكثير من البيانات الوصفية للمحفظة، وسوف ترتفع تجربة التطوير وتجربة المستخدم بشكل كبير.
واجه منطق اتصال ZAN.TOP بالمحفظة أيضًا نفس المشكلة في الأيام الأولى، ولكن الآن، بفضل التكوين الذي توفره Ant Design Web3، يمكن تكييفه بسهولة مع معيار EIP-6963. يجب أن يكون الجميع قد جربوا هذا عند ربط عنوان على https://zan.top/personal/account?chInfo=ch_wxdyh
تحقيق كل بيئة blockchain
في الوقت الحالي، تدعم كل منصة blockchain معيار Wallet (أو EIP) -6963) تختلف المعايير فيما يلي بعض الأمثلة:
البيتكوين
البيتكوين. لا يبدو أن هناك معيارًا مشابهًا حتى الآن. هناك مشروع يطبق معيار Wallet، لكنه لم يجذب الكثير من الاهتمام، ولم يتم تقديم أي كود جديد لفترة طويلة.
في الوقت الحالي، لا يستطيع المطورون الحفاظ على الحالة إلا يدويًا، أو استخدام بعض حزم التطوير للمساعدة في العمل. على سبيل المثال، في تطبيق محول Bitcoin في Ant Design Web3، يتم الحصول على متغيرات عامة مختلفة من محافظ مختلفة وتخزينها في حالة موحدة. وهذا يعني في الواقع أن مطور المكتبة قد تولى أعمال الصيانة الشاقة. علاوة على ذلك، فإن هذا لا يحل سوى مشكلة تعارضات المحفظة، ولا تزال مشكلة عدم القدرة على اكتشاف المحافظ المتاحة تلقائيًا موجودة.
Ethereum
تحتوي منصة Ethereum بالفعل على معيار EIP-6963 والمكتبات والمحافظ ذات الصلة كما يقدم معظمهم الدعم.
سولانا
كما هو مذكور أعلاه، يتم توفير التنفيذ الرسمي: https://github. com /solana-labs/wallet-standard
Sui
توفر Sui حاليًا خدمة Wallet Standard لـ لتحقيق ذلك، يمكنك العثور على كيفية استخدامه في الوثائق الرسمية: https://docs.sui.io/standards/wallet-standard
مكتبة تطوير التطبيقات اللامركزية الدعم< /h2>wagmi
wagmi عبر mipd (https://github.com/wevm/ mipd) توفر المكتبة الدعم لـ EIP-6963 للحصول على طرق محددة، يمكنك عرض وثائق wagmi.
RainbowKit
RainbowKit (https://www.rainbowkit.com/) المنطق الداخلي استنادًا إلى wagmi، فهو يحتوي أيضًا على دعم مدمج لـ EIP-6963.
Ant Design Web3
Ant Design Web3 (https://web3.ant.design /) تتمتع محولات Ethereum و Solana بدعم جيد جدًا لكلا المعيارين، كما أنها محمولة جدًا ليتمكن المطورون من فتحها.
بالنسبة لمطوري Ethereum DApp، يحتاجون فقط إلى إضافة تكوين eip6963. لاحظ أن الأسطر ذات الصلة بـ EIP-6963 موجودة في الأسطر 23-25:
p>
وإذا كنت أحد مطوري التطبيقات اللامركزية في نظام Solana البيئي، فإن الطريقة مشابهة. يوفر سمة autoAddRegisteredWallets:
الملخص
يمكن أن يؤدي EIP-6963 وWallet Standard إلى تحسين تجربة المستخدم في الاتصال بالمحافظ بشكل كبير وتقليل تكلفة المحافظ الجديدة العوائق التي تحول دون دخول مقدمي المحفظة. من المأمول أن يتمكن المزيد من منصات السلسلة والمحافظ ومطوري التطبيقات اللامركزية من توفير أو تنفيذ المعايير ذات الصلة في المستقبل، مما سيساعد Web3 على التطور في اتجاه أفضل. ص>