作者 | Billy Rennekamp
在论坛帖子《作为通用钱包的 Cosmos Hub》中，我提出了用户和区块链之间的未来主义关系，这涉及到当前 Cosmos-SDK 和即将到来的功能的组合。「子私钥」（或 Msg 授权）被称为 Interchain Accounts （ICS-27）的标准以及 Cosmos Hub 本身的安全性。https://www.albrow.com/things
这是一种充满想象力提案，但它让我思考我们需要进入一个安全且易与许多区块链交互的未来。不过这到底需要哪些步骤，我提出了一条前进的道路，其结果是将关注点分离，并建立一类新的钱包，创立账户协调功能。
当前的钱包状况
到目前为止，我们已经看到了很多钱包解决方案，它们试图同时做很多事情。到目前为止，钱包的功能还不完备，但随着我们进入一个用户希望与许多网络交互的世界，当前无法扩展的架构尚无法满足这一需求。在一个高层次上，钱包的各种职责包括：
-
私钥管理
-
应用界面
-
交易管理
Ethereum 已经经历了一些这样的成长之痛，因为像 EVM 这样的图灵完整的虚拟机几乎允许任何种类的应用存在，而且它们都期望从一个钱包中工作。虽然 Ethereum 钱包已经提出了协议和巧妙的解决方案，为各种各样的应用提供接口，但他们仍然期望这些应用是来自一个通用的 EVM 基础设施。随着我们看到特定应用区块链的模式成为现实，通过 IBC 连接，Ethereum 如何处理各种应用的界限将被打破。
切实可行的方法是将关注点分离。让这三个任务作为独立的解决方案存在，每个都可以专注于做好自己的唯一任务。这将揭示出对一种新型服务的需求，我一直称之为账户协调功能。
私钥管理
密码学是很难的。如果你不是专家，犯错误的几率很高，后果可能是灾难性的。期望所有钱包和 dApp 开发者都在内部拥有这种专业知识是不公平的。传统的应用程序已经认识到了这一点，并且经常通过将认证委托给使用 oAuth 标准的第三方来解决。
你可能认为这是钱包唯一的真正责任是保证你的私钥安全。但当我介绍其他常见的功能时，你会发现这远非如此。事实上，这往往是钱包建设者最不具备的能力。密码学和安全专家应该负责开发行业标准的解决方案，并实施私钥存储的最佳实践。这应该是他们的全部业务，然而相反，我们看到现在的钱包在安全性方面做的不错--但当涉及到密码学时，这并不够好。
如果将私钥存储的责任从钱包中移除，可能会导致更多种类的安全解决方案，这些解决方案依赖于不同的假设并提供不同的功能。目前已经有很多超越传统软件存储的私钥解决方案：像 Ledger 中的硬件安全模块，或者其他加密技术，比如 Torus 使用的 shamir 秘密共享，像 ZenGo 使用的阈值方案，多方计算，或者新颖的零知识技术。郑重声明，我认为保管私钥管理的共同责任空间也完全没有被开发出来。
不管私钥到底是如何存储的，存储方案的责任其实应该止于此。其只做一件事，而且要做好--存储私钥。对私钥的访问应该由类似的安全授权技术来处理。
WalletConnect，或者类似的用于在私钥管理器和应用程序之间传输数据的协议是进一步授权应该发生的地方。
应用界面
如今，一个钱包对应用接口的范围相当广泛。一方面，一些钱包提供了对应用功能的深度集成访问。Argent 和 Gnosis Safe 都在每个应用的基础上支持越来越多的自定义接口。这也是大多数 Cosmos 钱包的路线，网络期望最低限度的 stake 和治理接口。直接在钱包内提供自定义接口意味着你可以确保更好的用户体验，但它限制了钱包可以访问的应用数量，也限制了钱包变成新的应用。
在另一端，是试图将大部分接口责任推给应用开发者的钱包。一般来说，钱包使用 web3.js 或 cosmJS 将一个 API 或接口接入到应用程序中。或者，钱包可能包含它自己的浏览器，并已经集成了 API （Mist、Metamask Mobile、Status 和 Coinbase Wallet）。它们也可以利用浏览器扩展来接入 API （Metamask，Keplr）。WalletConnect 允许接口在移动和桌面浏览器之间以及移动和移动之间传输。无论哪种方式，都要由应用开发者来访问和利用钱包 API，以便为用户提供签名功能。这条路径消除了钱包作为访问应用的瓶颈，但也带来了自身的挑战--即安全性和流畅的用户体验。
应该考虑一种安全的授权技术，以确保应用程序能够访问签名功能，而不会因为确认的界面而劝退用户同时也不会使用户陷入不小心签名的境地。MetaMask 一直在尝试解决这个问题，它创建了一个可组合的安全接口，用于私钥与应用程序的通信，称为「Snaps」。它在很大程度上借鉴了 Agoric 的首席科学家 Mark Miller 在对象能力方面的工作，对象能力对可以跨环境传输的精确对象级控制进行编码。Snaps 提供了连接应用程序和私钥管理器所需的安全性和标准化，但我认为 Metamask 在这个架构上走得还不够远，因为所有三个钱包功能都可能被隔离并使用这个模型组成。
交易管理
虽然我们已经看到很多钱包承担了提供应用接口的重任，但我还是认为，到目前为止，钱包的主要职责是私钥管理。这使得钱包的第三个职责--交易管理的资源严重不足。我希望看到这成为钱包的主要职责，因为应用接口和私钥管理成为指定第三方的责任。
交易管理可以被认为是应用和签名解决方案之间的实际接口。这是一些操作的请求被解析成可以被私钥签名的格式的步骤。它包括与应用的通信以及与私钥管理的通信。在这两者之间，需要签署的数据应该被解析，并以一种用户可以理解他们正在签署的内容和原因的方式显示给用户。此外，这些签名请求的历史和状态应该被记录下来并提供给用户。
当使用 Ethereum 时，交易管理是很棘手的，因为基本上只有一种交易类型（eth_send），但它包括一个数据字段，当针对智能合约时，可以引用任何数量的方法。如果你很幸运，钱包能够访问与它交互的特定合约的 ABI 文件，允许将数据字段转换为函数名和参数。ABI 文件还可以让钱包显示交易成功处理后发出的事件。这就进入了区块浏览器的领域，它是一个完整的服务，基本上专门用于账户历史--以及整个网络的历史。然而到目前为止，区块浏览器在网络方面大多是单一的。
在这空间中，有许多不同的消息可以包含在交易中。这些消息中的每一个都有不同的功能，但传统上都是自行运行的，所以不需要外部的 ABI 文件。随着向 protobuf 的迁移，我们看到正在进行的讨论是如何保留这些性质，同时确保 protobuf 带来的所有性能的提高。一个选择将是在 protobuf 文件中像 ABI 一样使用，但还有许多其他解决方案仍在探索中。
无论网络架构如何，这都是一个棘手的问题，但对于确保用户能够验证他们到底在做什么是至关重要的。当额外的私钥被添加到这个组合中时，这个问题会变得更加复杂。一些钱包已经允许你创建许多账户，这些账户都来自于一个共同的助记词与私钥派生路径。这对于那些不想把自己的 DeFi 账户和游戏账户混在一起的用户来说，是一个很有用的功能。通过私钥派生可以在网络之间进行切换，尽管我不知道有哪个 Ethereum 钱包允许你通过支持多个助记词和私钥来合并账户（不过 Keplr 有）。这就给用户带来了负担，要跟踪哪个身份与哪个私钥相关联。
账户协调功能
交易管理一直没有得到充分的服务，随着网络的增加和相应 私 钥的增多，这个问题只会越来越严重。随着子私钥将账户能力分配给特定私钥的能力的增加，这一问题将成倍增加。职责范围的扩大，值得为这个角色起一个新的名字。我想为一种新型的钱包提出一个理由，它主要关注的是成为一个账户协调服务。
账户协调功能的主要目标是跟踪哪些私钥在哪些网络上具有哪些功能--以及如何使用 WalletConnect 等协议访问这些私钥的签名功能。虽然它应该努力实现外部的隐私和匿名性，但从用户的角度来看，它应该对所有 dApp、私钥存储和网络的活动进行完整的概述。它可能会要求一个私钥助记词的主公钥，以便得出所有可能的公钥。这将允许账户协调功能检查所有可能的网络上的所有可能的账户，看看你是否曾经在那里进行过交互。它将检测私钥是否是多签名、基于合同的钱包、组模块或子私钥的一部分。随着您的确认，它将开始为您跟踪所有这些账户，记住您的偏好，以便在何时使用哪个私钥。
账户协调功能应该允许你审计你在每个应用程序上的互动，同时保留一个连贯的历史-想想谷歌的 oAuth 告诉你当前登录了哪些服务和设备。最终，这应该看起来像一个以用户为中心的多网络区块浏览器，跟踪你自己的所有私钥并代表你协调它们。这将需要大量关于你使用过的或未来可能与之交互的众多网络的资料。这种资料可以从不同的来源收集，并将取决于你所面对的到底是哪种应用。我想象大多数信息应该是来自应用程序本身，通过像 WalletConnect 这样的界面。
账户协调功能将牢牢地站在你的私钥和应用程序之间，它将作为双方之间的中介，并将加入你在基于区块链的网络上的所有互动。它的建立将只为你服务，所以虽然它将拥有你的信息宝库，但只能由你自行决定是否访问。
