从v1.x迁移

WalletConnect 1.0和2.0提供了基本相同的终端用户体验，但它们内部的工作方式截然不同。这意味着开发人员将不得不考虑不同的api和sdk。此外，在集成2.0版本时还需要考虑一些UX方面的问题

迁移计划

WalletConnect v2.0与v1.0不向后兼容。因此，我们必须协调迁移计划，以确保最终用户不受这种迁移的影响。

最重要的是，在Dapps开始支持2.0版本之前，我们必须迁移钱包。这是因为钱包可以同时支持两个版本，并使用二维码或深度链接中URI中指定的版本号将连接请求路由到相应的客户端。

一旦我们达到了支持2.0版本的大量钱包的配额，我们就可以开始迁移dapp，因为它们将能够简单地在NPM上升级其包的主要版本。

多链支持

大多数接口与之前的版本非常相似，但两个版本之间最明显的区别在于它的多链支持。

WalletConnect v1.0 模仿了 Metamask 的浏览器扩展中的许多行为，这意味着会话跟踪单个 chainId，一个帐户数组和钱包控制 chainId，而 dapps 紧随其后。

WalletConnect v2.0 允许 dapp 请求一组链作为会话范围的一部分，当满足兼容性时，钱包会以成功或错误消息进行响应。此外，这意味着钱包不再控制链的chainId，而是会话跟踪多个chainId。最后，钱包将公开一个或多个与 Dapp 请求的每个链匹配的帐户，这些帐户可以在其生命周期内更新会话状态。

Chain-Agnostic interface

在之前的 v1.0 版本中，WalletConnect 预计只有与 EVM 兼容的钱包和 Dapp 才能使用其协议进行互操作。然而，这种假设带来了其自身的限制，这些限制使其他链生态系统无法使用满足兼容性并利用该协议。

WalletConnect v2.0 引入了一组允许在会话生命周期内使用的 JSON-RPC 方法。这意味着 Dapp 可以请求满足与钱包兼容性所需的最少方法集，当满足兼容性时，可以通过成功或错误消息进行响应。此外，这意味着 Dapp 不仅可以确定钱包是否可以为其所需的链签署交易和/或消息，而且还可以检测对实验方法的支持（例如 eth_signTypedData）。最后，钱包可以升级它在会话生命周期内公开的一组方法。

会话生命周期

以前在 v1.0 上，WalletConnect 具有无限的会话生命周期，这意味着客户端将保持会话状态，直到其中一个客户端发出断开连接的事件。然而，这引入了许多停滞的会话状态，其中一个客户端将失去其状态并且永远不会发出断开连接的事件。

因此，WalletConnect v2.0 为当前默认为 7 天的会话引入了到期时间戳。这意味着与对等客户端未发出断开连接事件无关，客户端将在到期后断开连接并删除会话状态。

会话请求包括一个 TTL（生存时间）值，它可以延长会话的默认生命周期（7 天）。会话到期时间戳也由响应者客户端计算，然后在其会话响应中共享时间戳。

配对 & 会话

WalletConnect v2.0 引入的最新概念是 WalletConnect v1.0 中不存在的配对。配对是特殊用途的会话，用于提出默认生命周期为 30 天的新会话。每当生成二维码或深度链接以连接 Dapp 和钱包时，它都会用于建立配对，因此当会话过期或终止时，如果客户端仍然具有活动配对，则不再需要客户端再次配对。

Pairings 比 Sessions 有更长的有效期，因为它们旨在被重新用于会话提案，并且它们可以在 Dapps 和钱包之间请求无限数量的会话提案ave longer expiration than Sessions because they are meant to be re-used for session proposals and they can request an infinite number of session proposals between Dapps and Wallets

Single Client

在 v1.0 之前，WalletConnect 为每个客户端管理一个会话，该客户端本身与 Relay（又名桥接器）服务器保持 WebSocket 连接。这种设计并不高效，并且还引入了很多复杂性，专门为钱包管理多个会话。

WalletConnect v2.0 客户端更加单一，但在一个客户端中管理多个会话，并通过单个 WebSocket 连接传输所有消息。这也意味着 WalletConnect v2.0 客户端还管理他们的存储以保持多个会话的状态，因此也保持配对。

消息确认

WalletConnect v1.0 的最大缺点可能是客户端没有确认从服务器收到的消息，也没有跟踪收到的 JSON-RPC 请求的历史记录

WalletConnect v2.0 客户端跟踪客户端发送和接收的所有 JSON-RPC 请求，可以忽略重复并确认收到的消息。这基本上意味着独立于 WalletConnect v2.0 连接的服务器或节点不会影响会话的行为，并且可以在不中断的情况下恢复其状态。

Project ID

对于 WalletConnect 的云版本，v2.0 将需要Project ID ，但自托管 WalletConnect 中继不需要此ID。阅读有关Project ID's.