在区块链开发领域，Dapp 和钱包彼此依存，相互需要。按理说，参考传统互联网应用，它俩之间的关系最好就类似普通应用和支付应用之间的关系：

• 在需要时激活后者
• 后者在完成特定操作
• 之后，它自行关闭，控制权回到前者

但是，Dapp 内部自己开发一个小型专用钱包的却不在少数。抛开业务特殊性不谈，个人认为导致这一现象的原因在于：集成的复杂度。

站在 Dapp 开发的角度，如果不自行开发，就得去集成第三方钱包。考虑到潜在钱包的数量，如果都靠专用 sdk 去集成，工作量可想而知。即便只考虑流行的钱包数量，工作量也不会小。更别提这样还可能导致潜在用户量的影响。

说起钱包 sdk，站在钱包提供商的角度，其实也可以理解。如果只有单纯的简单操作，其价值显然大打折扣。而且，有微信和支付宝珠玉在前，“能被集成”显然可以让自己的产品接触更多的受众。且不说这其中究竟有多少商业价值，单纯从技术人员的自我满足感来讲就值得去干了。

看上去两方都很有道理，那有没有一种两全其美的做法呢？既可以让 Dapp 开发者能快速集成第三方应用，同时又能有一个开放的标准让钱包提供商可以遵循，方便它们的产品被他人集成呢？

答案就是：WalletConnect。

通过本文，你将看到：

• 什么是 WalletConnect？
• WalletConnect 的技术细节。
• 它的使用场景和实际工作的代码示例，以及若干注意事项。此节分为两视角：
  • Dapp 开发者
  • 钱包开发者

同时，文末还会简单聊聊它和 Web3Modal 的关系。

什么是 WalletConnect

经过前面的铺垫，想必你应该已经猜到 WalletConnect 的作用了。简单地讲，它实现了钱包和 Dapp 之间的互联互通，一套开放的协议。

从使用者角度来讲，支持 WalletConnect 的 Dapp 和钱包给他们带来了类似微信和支付宝的使用体验：

1. 在需要时，Dapp 显示二维码。
2. 使用钱包扫描二维码建立连接。
3. 在钱包侧授权用户请求，完成请求动作。

其官网的宣传图很好地体现了这一点，如下图。

除了体验改善和前文提到的“降低集成门槛”，采用 WalletConnect 还有一个巨大的好处：安全性的提高。

何出此言？这是因为：用户不必再为了使用某个 Dapp 就被迫把私钥导入进去。或者退而求其次，创建一堆 Dapp 专用的账户，然后在这些账户之间来回操作，既繁琐，也不见得安全性有质的提高，只是看上去“很安全”。

虽然有 Ethers.js 这样的工具降低了钱包开发的难度，但要想普通 Dapp 对账户管理的安全水平达到专业钱包服务商的水平还是勉为其难。而且，再开发一个内置的钱包不仅增加了工作量，用户还不见得领情。

但是，任何区块链开发者都知道，要想干点啥，账户信息是必需。WalletConnect 很好地解决了这个难题：在不提供私钥信息的情况下，帮助 Dapp 使用者完成其区块链相关操作。下一节会详细说明其技术实现细节。

最后，让我们总结一下以结束本节的内容：

• WalletConnect 的诞生大大降低区块链应用的使用门槛，取得了跟传统互联网应用类似的用户体验。
• 从开发角度看，WalletConnect 的出现对于 Dapp 和钱包都意义重大：
  • Dapp 角度，降低了集成门槛和工作量，不必每次都自行实现一个专用钱包。
  • 钱包角度，基于开放协议即能接入数量巨大的 Dapp 市场，降低了”被集成“的难度。
• 从安全性来看，WalletConnect 避免了用户频繁共享或提供敏感的私钥信息，也降低了用户自行管理多账户的必要性。

WalletConnect 的技术细节

前面说过，WalletConnect 可以在不提供私钥的前提下帮助 Dapp 用户完成其区块链相关操作。实现这一机制的奥秘就在于其 ”Bridge“ 架构。

整个过程并不复杂，Dapp 通过 Bridge Server 将请求传递给钱包，后者完成跟区块链的交互之后将结果原路返回。

当然，我相信仅仅是上面的架构图仍然无法打消你的疑问：

• 那么多的 Dapp 都在运行，钱包如何知道要跟哪个 Dapp 进行交互？
• 并且，即便是同一个 Dapp，又如何区分不同用户呢？