WalletConnect v1.0 概述

本文介绍了 WalletConnect 协议,该协议通过安全连接促进 dApp 和钱包之间的通信。WalletConnect 通过扫描二维码建立安全连接并通过端到端加密消息发送,从而允许加密钱包连接到桌面 dApp,允许用户签署消息,而无需私钥离开其移动钱包。

本文概述了 WalletConnect,这是一种用于将移动钱包连接到 dApp 的协议。

来源:https://raw.githubusercontent.com/WalletConnect/walletconnect-assets/master/png/original/walletconnect-banner.png

简介

WalletConnect 是一种协议,它通过安全连接促进 dApp 和钱包之间的通信。WalletConnect 允许加密钱包通过扫描二维码与桌面 dApp 简单连接,从而建立安全连接并通过端到端加密消息发送消息,允许用户签署这些消息,而私钥不会离开他们的移动钱包。

图片:Web 2.0 & Web 3.0 架构

如上所示,在 web2.0 中,身份验证由中心化服务器使用用户名/密码处理,从而提供对数据库的访问。将这些映射到 web3.0 意味着此身份验证通过钱包(例如 metamask)完成,dApp 和区块链作为 web3 领域的其他组件,允许 dApp 和钱包之间进行此身份验证/连接的协议就是 WalletConnect。

为什么我们需要 WalletConnect?

在 WalletConnect 启动之前或目前作为它的替代方案,将任何钱包连接到 dApp 的唯一方法是使用浏览器扩展程序或在移动钱包中使用 dApp 浏览器。浏览器扩展程序最常见的例子是 metamask 扩展程序,它支持 Chrome、Edge 等流行的浏览器。第二种替代方案是嵌入在钱包中的 dApp 浏览器,常见的例子是 Trust Wallet 在 android Trust Wallet 应用程序中提供 dApp 浏览器。

这些选项对于各种用例来说似乎都不错,但仍然存在缺点,其中一些列在下面:

  • 浏览器钱包本身不收集任何个人信息。 但是,安装它的浏览器可以收集有关你如何使用已安装的钱包扩展程序的信息,即暴露浏览数据泄露,并进一步使用此数据进行货币化。
  • 易受攻击的浏览器或钱包会影响你的浏览器钱包扩展程序,从而导致存储在钱包中的资金丢失。 因此,使用浏览器钱包来存储私钥和大量代币余额并不安全。
  • 基于浏览器的钱包也容易受到网络钓鱼攻击。
  • 这些浏览器扩展程序依赖于浏览器,即如果浏览器删除对这些扩展程序的支持,将导致用户难以使用其钱包访问 dApp。
  • 在钱包移动应用程序中使用 dApp 浏览器会破坏用户体验。 因为 dApp 不会提供与其桌面版本相同的用户体验。
  • 使用 dApp 浏览器意味着钱包开发人员需要付出额外的努力来构建这些浏览器,而不是专注于实际的钱包功能和安全性,从而造成开销。
  • 无法将 dApp 浏览器添加到 iOS 钱包。 在基于 iOS 的钱包中,为了让任何应用程序在 AppStore 上架,dApp 浏览器支持已被删除,以响应 iOS 提供的应用程序指南。 最近的例子是 Trust Wallet,它从其钱包的 iOS 应用程序中删除了 dApp 浏览器功能,以遵守 AppStore 指南。

为了克服所有这些缺点并提供流畅的用户体验,WalletConnect 提出了一个开放协议,通过简单的二维码将任何移动钱包连接到基于桌面的 dApp,或者借助深度链接将任何来自移动浏览器的 dApp 连接到移动钱包。

WalletConnect 如何工作?

简而言之,WalletConnect 协议使用桥接服务器在两个应用程序之间建立连接,该服务器将在连接的设备之间中继对称加密的 payload。该协议依赖于对等方(dApp)之一通过显示二维码或通过深度链接发起连接,只有当用户在钱包上批准连接请求时,连接才会建立。

架构

WalletConnect 协议架构有 3 个主要组成部分:

  1. dApp: 在区块链上提供服务的 web3 应用程序,它使用客户端连接到钱包。
  2. 钱包: 存储私钥并负责签署 payload 的应用程序。
  3. 桥接服务器: 负责在 dApp 和钱包之间中继消息的 web socket 服务器。

工作原理

图片:建立连接, 来源: https://docs.walletconnect.com/tech-spec

  1. dApp 发布加密数据,其中包含 peerID(dApp 的客户端 ID)和 peerMeta(dApp 的元数据,包括 dApp 名称、徽标和描述)。 在后台,dApp 发送 “pub” 请求,其中 topic=>handshake topic,peerID =>dapp 客户端 ID。 此外,dApp 发送 “sub” 请求,其中 topic=>dapp 客户端 ID
  2. dApp 使用标准 walletconnect URI 格式 显示二维码,其中包括 walletconnect 协议、handshake topic、版本、桥接服务器 URL、对称密钥十六进制字符串。
  3. 钱包将使用二维码或深度链接读取 URI。 读取 URI 后,对等方将接收并解密连接请求 payload。 在后台,钱包发送 “sub” 请求,其中 topic=>handshake topic 以获取加密的连接请求。 钱包还向 topic=>wallet 客户端 ID 发送 “sub” 请求。
  4. 然后,钱包将显示一个弹出窗口,其中包含 dApp 提供的连接请求详细信息。 然后,用户将批准或拒绝连接。
  5. 如果用户批准了连接请求,则钱包将共享帐户地址和链 ID,如果被拒绝,则钱包将发送适当的响应。 为此,钱包会发送 “pub” 请求,其中 topic => dApp 客户端 ID,peerID=>wallet 客户端 ID 和连接响应。
  6. 因此,dApp 将从桥接服务器获取此数据。
对交易不熟悉? 可以尝试 [加密货币交易机器人](https://learnblockchain.cn/article/12442) 或 [跟单交易](https://learnblockchain.cn/article/12441)

完成握手后,两个对等方都会将这些客户端 ID(用于接收消息的主题)和对等 ID(用于发送消息的主题)topic 添加到其持久本地存储中。

图片:调用请求, 来源: https://docs.walletconnect.com/tech-spec

  1. 建立连接后,dApp 将向桥接服务器发送加密的 JSON-RPC 调用请求,这将触发推送通知。
  2. 钱包收到通知后,将从桥接服务器获取 payload。
  3. 当用户批准请求时,钱包将签署 payload 并将加密的 payload 发送到桥接服务器。
  4. 因此,dApp 会从桥接服务器接收到响应。

WalletConnect 实践

带有 WalletConnect 集成的示例 dApp 可以在这里找到:

WalletConnect v1.0 的改进

  • WalletConnect v1.0 使用对称密钥,该密钥通过二维码直接共享,因此由于该密钥容易受到浏览器攻击,因此不安全。— v2.0 通过使用使用 X25519 共享密钥推导得出的非对称密钥解决了这个问题。
  • WalletConnect v1.0 需要切换链才能连接到不同的链。— v2.0 提供了一项功能,其中 dApp 必须提前请求链,并且用户将能够从 dApp 进行控制,从而避免链切换。
  • 在 WalletConnect v1.0 中,会话生命周期是无限的(直到其中一个对等方发出断开连接事件),因此导致会话停滞。— v2.0 使用默认会话时间为 7 天和默认时间线为 30 天的配对来管理这些会话。

有关 WalletConnect v2.0 测试版中添加的其他改进和附加功能,请参见 v2.0 beta docs

参考:

加入 Coinmonks [Telegram 频道](https://t.me/coincodecap) 和 [Youtube 频道](https://www.youtube.com/c/coinmonks/videos) 了解加密货币交易和投资

此外,阅读

  • 原文链接: medium.com/coinmonks/wal...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
vineetaparodkar
vineetaparodkar
江湖只有他的大名,没有他的介绍。