原标题《观点|可组合钱包的重要性》
我曾经讲解过去中心化应用（dApp）的产品可组合性，当然，用的是非常简单的层叠示意图：
实际上，有两个层级被我省略掉了，就是钱包和 SDK；而且，还可以再加上有关 “链” 的一层：
本文我准备谈谈，为什么这些额外的复杂性会导致人们的视角发生转变：可组合的钱包会对用户和开发者两端都产生越来越重要的影响。一般来说，在走到产品开发的 “最后一公里” 的时候，也就是开发团队要决定接入尽可能多的钱包时，人们才会想起还有钱包这回事（假设这个团队既负责产品的智能合约后端，也负责前端）。目前来说这没什么大问题，因为大多数 dApp 在用户交互上都是很简单的（即，授权 + 存入、拍卖/买入，以及互换）。在互动的 前/后 没有太多需要管理或表示的东西。
但我们的生态还会变得更加复杂的，那时候怎么办呢？在可预见的未来，我们都要着手管理自己的以 token 形式体现的数字身份，比如 skills、credit scores、social circles，等等。这就会在接入我们今天所用的标准协议前产生额外的一个交互步骤、要管理更复杂的网路和用户关系，以及相应的市场。思索这个前景，我们会自问：每个产品都要自己管理一个特定的前景，这合理吗？Web 2.0 时代的方法就是创建另一个 应用市场/网站，但我觉得我不会喜欢再有一个网站来跟踪我怎么管理自己的身份和自己所用的网络。我认为，这样私人的东西应该在钱包层完成处理，因为在这个环境中，个人自主和隐私性是第一位的。
虽然我不介意为了使用不同的协议而跳转到不同的网站，但我也不希望为了管理我的链上交互的不同部分而使用多个钱包。这样很蠢，而且每多一个就多一些安全风险。但如果我只使用一种钱包，那我就把自己跟这个钱包背后的开发团队的内在风险绑定起来了 —— 更不用说总会有他们还没开发的新功能。请记住，我们已经身处一个迅猛发展的世界中，没有哪个团队可以样样精通。
这就是为什么我们需要钱包的可组合性。虽然我想直接开始，但我还没讲到钱包是由哪些部分组成的。在谈到 DeFi 和 许多以太坊 dApp 时，我们已经有了 “货币积木” 这个词；因此我准备把钱包的可组合性模块称为 “通道积木（access lego）”。
四个层级中的每一个都应允许用户灵活地选择产品，而每个层级都应由产品提供者提供定制化的积木。
这里有很多东西可以深挖，所以我们先快速回顾下密码学货币钱包的历史，以便更好地理解这些积木，以及我们今天所用的先进钱包服务是如何得来的。
以太坊钱包简史
第一个以太坊钱包的灵感来自 Bitcoin Qt 钱包，是由 Mist 团队做出来的。
- 图片来源 -
Mist 钱包看起来跟 Qt 非常像，都是一个需要下载的软件，然后可以导出交易数据，也支持 区块同步/区块浏览：
- 图片来源 -
这个钱包其实是想把一个以太坊节点能够做到的事情都装进一个软件里 —— 那就需要安装大量依赖，整体的用户体验也不好。到 2016 年，MetaMask 出现，是最早的基于浏览器的钱包之一。自此，dApp 可以从钱包中解耦出来，只需嵌入钱包的连接方式即可。这一点随着生态系统的成长变得非常重要，因为此前单个团队想跟踪所有 EIP 的进展和发展出来的 token/协议 是非常困难的（现在也仍然如此）。我想指出的是，虽然这增加了 dApp 产品的可组合性，这 还不是 上面的 “通道积木示意图” 中所指的 钱包内 的智能合约集成。这一部分一直到新的集成方式如 WalletConnect 出现之后才有所改变。
- 钱包连接方式嵌入示例 -
这样一来，钱包的一些责任和负担就移除了，现在它的重点变成了交易构建、签名以及维持与区块链的连接。我不想深究细节，但交易构建意味着要从 dApp 处接收一些交易参数、并且其它参数要保证完全在钱包控制之下。这使我们走向了对钱包（也可称为 “提供者”）可用的 RPC 调用，最早由 EIP-1193 定义。dApp 可以发送一些参数如目标地址、数据、gas limit/price、数值给钱包，但 无法 控制链 ID、发送者地址以及 nonce 等涉及钱包安全的参数。
有了这种新型钱包之后，我们又多了两种复杂的用户体验：
记住 其他用户/朋友 的地址是很困难的，不安全，而且容易发生人为的错误交易附带的字节码是不可阅读的，除非你非常熟悉函数选择器以及 数据/参数 的哈希值。要是你没有合约的 ABI，那就有你好看的了。
为了解决第一点，ENS 在 2016/2017 年月 EIP-137 一起推出，成为了我们的第一块社交积木。现在，大家都可以用一个网站域名来表示自己的以太坊地址（比如 vitalik.eth），在 消息/转账 中使用即可免去输入长长的地址。这只是社交智能合约层的一部分；其余部分要花更大的精力来 解耦/实现可组合性。
关于第二点，Parity 创建了一个 “方法注册表”，被广泛用户在钱包的签名界面给出人类可读的信息。EIP-712 在此发挥了重要作用，尽管它到最近才获得更多关注。不过，即使有了这些设置，还是很难保证你的浏览器没有被黑或被欺骗从而显示出不真实的 交易/信息。这是使用热钱包（即总是连接到互联网、并且没有与你的计算机环境的其余部分隔离开来的钱包服务）的最大问题之一。
常见的解决方案是一个硬件钱包，开拓者是 Ledger，从 2014 年起步。MetaMask 在 2018 年首日添加硬件钱包支持，正式地解耦了安全层和 交易层/连接层。我们后面还会再回顾这一点，因为 Ledger 作为冷存储钱包固然很棒，但一些新产品也有很大改进。
- 正上方的即是一个 Ledger 钱包 -
于此同时，我们看到，许多复杂的协议在 2020 年夏天开始在 DeFi 世界里领一时之风气（其中大部分都开发了超过 2～3 年）。这给了我们越来越多的代币，学会安全管理也变得越来越重要。为了帮助大家跟上圈子的进步，人们创建了一种新的 RPC 端点，让 dApp 可以在钱包所跟踪的代币列表中添加种类。更多管理资产的工具被创建出来，比如 Argent vaults 和 Gnosis multi-sig safes（我还认为这两款产品与社交层有关，因为他们都有多用户机制以及 DAO 机制）。人们还给 dApp 的数据分享创建了 “许可连接” 标准（EIP-2255），以防止对钱包的恶意访问。资产管理/资产聚合器、分析器，也因为 Zerion 和 Zapper 而从钱包中解耦了出来（下一章节我们还会回头讲解这两个产品）。
自 2019 年开始，手机钱包也出现了增长。Rainbow wallet 是最佳范例之一，他们的用户体验设计得非常好。但要讲到无缝集成，他们也才刚刚开始。
大多数其它手机钱包（比如 MetaMask 手机版和 Coinbase Wallet）都尝试并且在应用内开发了一个 dApp 浏览器，依赖于 deeplink 而非直接集成。这些 deeplink 无法提供很好的用户体验，但在以太坊上开发的产品又多到钱包团队无法设计出一个可以与所有产品交互的大一统接口。假设每个钱包应用团队都专门为一个应用场景（消息、NFT/市场、DeFi，等等）做优化 —— 那么，我的安全风险都跟我所用的钱包数量成正比。也许它们都是最小化的，因为安全模块已经完全解耦 —— 但因为市场已变得碎片化，开发者就必须为进入不同的系统排定优先级。Rainbow 钱包团队一开始想做 钱包聚合器/管理器（基于他们 从 2019 开始构建的早期 GitHub 库），所以我认为他们已经考虑过这个问题了。也就是说，我们可以看到，智能合约的接口已经是半解耦的了，但这一集成还不能自由组合，因为钱包团队正是瓶颈。换句话说，所有 dApp 都可推送到某个钱包来使用，但一个钱包并不能保证所有 dApp 都支持他们。
现在，一个钱包的所有层级，我们都或多或少有所了解了，现在我们再回头讨论通道积木。这些积木和下列的分析，部分基于我自己的信念：我们未来会走向在钱包产品中直接使用 dApp，比如 MetaMask 提供的币币互换 和 Rainbow 的展示功能。
这些分析是我个人经验和几个星期的研究工作的总结，我完全有可能弄混了一些项目的时间线。如有错漏，请联系我，我可以编辑文章及作出必要的 订正/补充。
分析通道积木
有了对以太坊钱包的更多了解，我们就可以谈谈我所谓的 “access（通道）” 的意思了。这里的 “Access” 通常代表用户对资金和协议的方案，也代表协议（经允许的方式）访问用户以及他们回传的数据。有了通道积木，我们就可以想象出五种关键的属性、帮助我们更好地定义钱包可组合性的基本要求：
安全性可以从用户界面中解耦出来，放到任意硬件或软件的解决方案中，且无需牺牲定制化特性；用户能够访问任意应用，而不必担心换代和集成时间；协议可以访问用户，而不必担心被弃用和需要手动推动钱包集成自己的产品没有人能控制整个集成市场不必牺牲用户和开发者体验
一个一个聊 : )
安全定制化
我相信 硬件-钱包服务 的连接方式会越来越标准，对我看过的每一款钱包几乎都如此，无论连接方式是 USB 接口、无线连接或是蓝牙连接。所以，解耦通常不是问题所在；相反，问题在于硬件钱包本身。
助记词存储、生成和恢复都是值得一读的话题，但当我们都开始使用纯粹的 “冷存储” 时，就只是硬件钱包的一部分。合约的 ABI、解码消息的签名、交易的限制/灵活性 给用户带来了定制化的空间（和可阅读性），我在上面介绍每一层时都提到了其重要性。
一个很好的产品案例是来自 GridPlus 团队的 Lattice1；这种硬件钱包要搭配专门的 SafeCard 使用，并用 SafeCard 实现了地址的可变更。钱包硬件有一个 64 GB 的固件环境，你可以从任意合约导入 ABI，来帮助解码你正在签名的交易的数据。
- 来自 https://wallet.gridplus.io/，教导用户管理 Lattice1。这种办法可以说比 “方法注册表” 更安全（尤其是当智能合约的所有人没有注册他们的合约时）-
我相信这种类型的集成方法会变得越来越重要，因为与你的钱包绑定的价值和 身份/声誉 会日渐提升。
集成市场
第二、三、四种属性都可以归结为一个概念 —— 为你所用的钱包创建一种集成 dApp 的市场。从某种意义上上，这里的主要 “钱包” 是一个平台，所有安全模块和集成都可以接入的平台。几乎总会是 “交易和连接” 层。
我相信 MetaMask snaps 是朝着正确的方向迈出了一步：所有 dApp 开发者都可以接入已有的 MetaMask 钱包 UI，只需自己开发接口和集成方法即可；而用户可以自己挑选这些碎片的组合 —— 由此形成了钱包内的一个市场。如果我喜欢某一套用户投资、收藏或社交的产品，我可以从 dApp 团队处获得产品，然后私下在我的钱包里使用。既不需要钱包团队手动开发对下一个 ENS、BrightID 或者 proof token 的支持，也不需要给每个月都有成打出现的新 DeFi 协议服务。这样的市场对于小众的社区和 DAO 来说也很重要，他们可能有自己的 常用 dApp/产品 列表（或者说更有可能自己开发）。如果集成工作总要由钱包团队来做、来推动，那 99% 的时间里都只会有主流应用。
至于市场的所有权，我乐观地相信，这些插件都应被列在一个开源的库中（类似于 Dune Analytics 在一个库中展示所有的幕后情形）。我不会希望 Web 3.0 世界再来一个 Google Play 或者 Apple 应用市场，不论从准入限制还是价值抽取来说。最重要的是，没人希望所有这些 dApp 插件都会因为 MetaMask 被弃用而烟消云散。
用户和开发者体验
用户体验不应受制于 集成速度/dApp 功能缺失。我相信这一点上面已经说得很清楚了。开发者体验当前主要受制于两个问题：
因为产品的可组合性，任何人都能开发任何应用。但谁来负责开发特定的某个东西呢？得到钱包或者一个集成平台支持的条件是什么呢？
我认为，因为缺乏标准化的协议 SDK，所有人都很受罪，尤其许多 前端/钱包 开发者不得不开发自己的连接方式。此外，大多数钱包都没有一个清楚的 dApp 集成方法（deeplink 可不算），而 Zapper 依赖于一个不透明的请求系统。这对所有人都不好。
但也有一些正面案例。一些协议，比如 Uniswap 和 Superfluid，就多有自己的很棒的 Javascript SDK。我在钱包集成环节提过 MetaMask snaps，但 Zerion（虽然不是一个钱包）也有很好的集成方法 SDK 和开放的适配器市场。拥有一个迅捷且独立的 协议-钱包 集成方法，可以极大优化开发者体验，任何一个开发者都可以将所有部件装在一起。我还要强调，基础协议的接口也是如此，额外的功能如分析和用户教育，应该直接做在 dApp 页面上（而不是钱包里），以提供更稳健、更分众化的用户体验，捕获仅凭钱包不足于捕获的用户。我觉得这样做是对的，因为这些功能对于访问功能来说都不是核心。
把所有这些都放在心上，钱包团队就可以专注于开发可组合的平台和市场，而 dApp 开发者则专注于开发 SDK 和插件以方便集成。有更多的标准也会有所帮助，因为许多 EIP 都是为钱包和库而提出的（如果有人有志与我一同工作，欢迎联系我）。
结语
本文的观念是我在为 Build With Consensys 作研究并与钱包开发交流时产生的。在我研究期间，我看了 Dan Finlay（MetaMask 创始人）在 Devcon 5（2019）上的演讲的视频。我感觉他对钱包可组合性的想法并没有获得 dApp 可组合性那么多的关注。他从很早开始就一直在推进这一点，因为 Dan 曾在这篇文章中写道：
"在 Devcon 2 上，我上台呼吁创建一个去中心化的标准化机构。我请求其他 web3 钱包的开发者加入，围绕一个共享的测试套件，为开发者提供一个跨客户端的、稳定的平台。虽然有人表露出真切的激情和兴趣（感谢 Casey Detrio），最终，无动于衷和协调的代价，使这个梦想变成幻想。"
因此，虽然本文提供了一些信息，但它也是一种请求，希望我们（作为用户也作为开发者）能够花些时间思考这个问题，并开发这个重要的领域，直至我在上面设想的新应用成为现实。在 Dan 的文章中，他认为这会给我们提供给一个更安全、更好用、更有用的以太坊体验。而在我看来，这意味着每个人都有可组合的通道来访问以太坊。
感谢 Thomas Rush 的编辑。
（完）
原文链接:
https://medium.com/coinmonks/1the-importance-of-composable-wallets-for-users-and-developers-accb2aadff49
作者: Andrew Hong
翻译: 阿剑
