Серия новичоков Web3: нажатие MetaMask может ошибочно вызвать другой кошелек? Текущее состояние решения конфликта кошельков

Путаница при запуске кошелька

Подключение кошелька - это ключевой шаг для входа в мир Web3, пользователи Web3 часто должны подключаться к кошельку на некоторых веб-сайтах DApp. Однако даже этот простой шаг может вызвать серьезные неудобства для пользователя.

Подключить кошелек

Представьте себе такую ​​ситуацию: новый пользователь Web3 (из любопытства он установил множество кошельков-плагинов) посещает веб-сайт DApp и хочет подключить его с помощью своего кошелька-плагина в браузере. Однако, когда он нажимает кнопку “Подключить кошелек”, предоставленную сайтом, и выбирает кошелек, чтобы использовать его для подключения к DApp, он может обнаружить, что появившийся кошелек не тот, который он выбрал. Это может вызвать у него панику и удушье, и он может подумать, что его компьютер заражен вирусом, и поэтому выполняет неожиданные действия.

Кошелек блокчейна - это важный вход в блокчейн, и для того, чтобы занять этот вход, каждый кошелек использует все возможные способы. Среди них наибольшие проблемы для разработчиков DApp и пользователей DApp вызывает изменение глобальных переменных каждым кошельком.

В текущей логике реализации браузерного кошелька все функции, предоставляемые кошельком, экспонируются путем внедрения глобальных переменных в браузер (например, кошелек платформы Ethereum внедряет свои функции в ‘ethereum’), чтобы DApp мог использовать методы, предоставленные кошельком, для взаимодействия с ним.

Однако поскольку многие кошельки внедряют себя в одну и ту же переменную ethereum, кошельки, зарегистрированные позже, замещают ранее зарегистрированные, так что можно вызвать только последний зарегистрированный кошелек этим способом.

Иногда пользователи DApp вынуждены временно отключать другие плагины кошелька или устанавливать только один кошелек, чтобы использовать свой предпочитаемый кошелек. Это противоречит исходным намерениям разработчиков кошелька. Даже если новый кошелек работает лучше, он трудно привлечь пользователей, которые уже пользуются другими кошельками.

Некоторые друзья могут задаться вопросом, почему нужно внедрять в одну и ту же переменную? Предположим, есть два кошелька: A и B. Фактически, достаточно, чтобы A внедрил себя в ‘a’, а B внедрил себя в ‘b’, и чтобы вызвать нужный кошелек, нужно вызвать соответствующий метод в соответствующем объекте, чтобы не возникала проблема, когда вызывается A, но вместо этого вызывается B. Это действительно может решить проблему конкуренции, но проблема в том, что если DApp должно поддерживать несколько подключений к кошелькам, то все имена кошельков, которые разработчик хочет адаптировать, должны быть предопределены в коде, и когда пользователь выбирает определенный кошелек, вызываются соответствующие методы этого кошелька. Это усложняет поддержку связанного кода. А если кошельки будут внедрены в один объект, то можно избежать этой проблемы.

Решение

Для того чтобы избежать вышеупомянутого дилеммы, в сообществе есть два похожих стандарта.

Решение Ethereum: EIP-6963

В мае 2023 года сообщество Ethereum представило предложение EIP-6963.

Основная логика здесь очень проста: отказаться от глобальных переменных и вместо этого использовать соглашенность событий для решения проблем регистрации и обнаружения кошелька.

Конкретно, после успешной загрузки кошелька-плагина возникает единое событие ‘eip6963:announceProvider’, уведомляющее DApp о наличии нового кошелька. В свою очередь, DApp путем прослушивания этого события узнает, какие кошельки в настоящее время доступны.

Таким образом, путем использования абстрактной логики прослушивания событий избегаются проблемы, вызванные прямым использованием глобальных переменных, и автоматически обнаруживаются доступные кошельки в текущей среде пользователя. Таким образом, двойная проблема разрешается.

Стандарт кошелька: Стандарт сообщества

EIP-6963 является стандартом экосистемы Ethereum, но не только Ethereum, у других платформ цепей также могут быть похожие проблемы. Например, кошельки на цепочке Solana, как правило, инъектируются в переменную «solana», что также приводит к конкуренции.

Так может ли экосистема Solana также реализовать этот стандарт? Хотя EIP-6963 разработана только для решения проблемы обнаружения кошельков в экосистеме Ethereum, но идея, заключенная в ней, может быть применена на любой блокчейн-платформе. Таким образом, мы можем предоставить универсальный стандарт, который позволит кошелькам и DApp на всех блокчейн-платформах использовать преимущества, предоставленные EIP-6963. В теории это абсолютно возможно, и уже есть разработчики, работающие в этом направлении, например, Wallet Standard.

Ключевая работа, выполненная в рамках стандарта кошелька, заключается в предоставлении двух функций: «registerWallet» и «getWallets», первая из которых предназначена для кошелька, а вторая - для DApp.

Кошелек вызывает ‘registerWallet’, передавая объект кошелька, который инкапсулирует функции, предоставляемые кошельком (например, метод Connect для подключения кошелька). Внутри функции сначала вызывается событие RegisterWalletEvent, фактический параметр события - это функция обратного вызова, которая позволяет DApp вызывать при обнаружении события RegisterWalletEvent, и эта функция обратного вызова фактически передает объект кошелька, так что DApp может получить ссылку на объект кошелька и взаимодействовать с ним.

Разработчикам DApp не нужно писать код для прослушивания и получения объекта кошелька самостоятельно, этот функционал уже встроен в «getWallets». Однако, getWallets только прослушивает события, а как обрабатывать события, это все еще нужно решать разработчикам. Например, где хранить полученные кошельки? Некоторые кошельки могут быть загружены до загрузки DApp, а другие - после. Как поддерживать состояние этих кошельков? Для решения этих вопросов Wallet Standard предоставляет пакет «@wallet-standard/react», который предоставляет разработчикам необходимые данные, такие как список кошельков, текущий подключенный кошелек, предоставляемые кошельком методы и т. д.

Стандартные функции кошелька

В дополнение к основному получению объекта Wallet, Wallet Standard также определяет некоторые форматы функций.

На самом деле у кошельков есть несколько базовых функций, таких как подключение, прослушивание событий кошелька и т. д. Стандарт кошелька предоставляет функции, такие как «standard:connect», «standard:events» и т. д. После реализации этих функций поставщиками кошельков, DApp может напрямую определить, поддерживает ли кошелек определенные операции, исходя из этих значений.

Упомянутый выше “стандарт: *” - это встроенные в него определенные свойства, фактически их значения не имеют особенно жестких требований, поэтому их можно свободно расширять. Различные платформы цепочек также могут иметь свои уникальные свойства, такие как Solana, которая непосредственно договаривается о "solana: * ". Общие функции платформы Solana включают в себя «solana: signTransaction», «solana: signMessage» и т.д.

Текущее положение в стандарте кошелька

В настоящее время реализовано довольно мало проектов, соответствующих стандарту Wallet Standard, и здесь следует отметить Solana и Sui.

В адаптере Solana для Ant Design Web3 также поддерживается автоматическое обнаружение кошельков, совместимых с стандартом Wallet. Разработчику в основном нужно только включить «autoAddRegisteredWallets», не нужно настраивать множество метаданных кошелька, что значительно улучшает опыт разработчика и пользователей.

Логика подключения кошелька ZAN.TOP также сталкивалась с теми же проблемами в ранних версиях, но сейчас, благодаря предоставленной Ant Design Web3 конфигурации, она легко соответствует стандарту EIP-6963. Вы, наверное, уже заметили это при привязке адреса в _wxdyh.

Реализация экосистемы каждого блокчейна

По отношению к стандарту Wallet Standard (или EIP-6963) позиции различных блокчейн-платформ в настоящее время различны. Вот несколько примеров:

Биткойн

На данный момент, кажется, что у Bitcoin нет похожих стандартов. Есть проект, который реализует стандарт Wallet Standard, но он не привлекает много внимания, и давно не обновлялся.

В настоящее время разработчики могут только вручную поддерживать состояние или использовать некоторые пакеты разработки для помощи. Например, в реализации адаптера Bitcoin в Ant Design Web3, для разных кошельков данные извлекаются из разных глобальных переменных и сохраняются в едином состоянии. Это, по сути, означает, что разработчики библиотеки берут на себя трудоемкую работу по поддержке состояния. Кроме того, это только решает проблему конфликта кошельков, а проблема автоматического обнаружения доступных кошельков все еще существует.

Ethereum

На платформе Ethereum уже есть стандарт EIP-6963, и большинство связанных библиотек и кошельков уже поддерживают его.

Solana

Как указано в предыдущем тексте, официально было предоставлено решение:

Суи

Sui уже реализовал стандарт Wallet и методы его использования можно найти в официальной документации:

Поддержка библиотеки разработки DApps

Вагми

wagmi поддерживает EIP-6963 с помощью библиотеки mipd(), подробнее можно узнать из документации wagmi.

RainbowKit

Внутренняя логика RainbowKit () основана на wagmi, поэтому он также имеет встроенную поддержку EIP-6963.

Муравьиный дизайн Web3

Адаптеры Ethereum и Solana для Ant Design Web3 отлично поддерживают оба этих стандарта и очень удобны в использовании для разработчиков.

Для разработчиков DApp Ethereum достаточно добавить конфигурацию eip6963, обратите внимание, что связанные с EIP-6963 на 23-25 строках:

Если вы разработчик DApp в экосистеме Solana, то и способ аналогичен. Он предоставляет свойство autoAddRegisteredWallets:

Заключение

EIP-6963 и стандарт кошелька могут значительно улучшить опыт пользователей при подключении кошелька, снизить порог входа для новых поставщиков кошельков. Надеюсь, в будущем будет больше платформ цепочек, а также разработчиков кошельков и DApp, которые могут предоставлять или реализовывать соответствующие стандарты, что способствует развитию Web3 в лучшем направлении.

Этот текст написан gin-lsl от ZAN Team (официальный аккаунт @zan_team).