未来的区块链钱包畅想

1. 引言

以太坊基础设施栈的一个关键层是钱包，但核心 L1 研究人员和开发人员往往低估了这一点。钱包是用户和以太坊世界之间的窗口，用户只有在钱包本身也具有去中心化、抗审查、安全性、隐私性或其他属性的情况下，才能从以太坊及其应用程序提供的这些属性中受益。

最近，以太坊钱包在用户体验、安全性和功能方面的改进取得了很大进展。

本文目的是给出Vitalik对理想以太坊钱包应具备的一些属性的看法。这并不是一个完整的清单——反映了Vitalik的密码朋克倾向，侧重于安全性和隐私，在用户体验方面几乎肯定是不完整的。
然而，Vitalik认为该愿望清单在优化用户体验方面不如简单地根据反馈进行部署和迭代有效，所以Vitalik认为最有价值的是关注安全性和隐私属性。

2. 跨 L2 交易的用户体验

现在，跨 L2 用户体验的改善路线图越来越详细，分为短期路线图和长期路线图。本文主要关注短期路线图——即使在今天，理论上也可以实现的想法。

核心思想是：

• 1）内置跨 L2 发送，以及
• 2）链特定的地址和支付请求。
  • 钱包应该能够给一个（遵循Add ERC: Chain-specific addresses using ENS #735 ERC 草案风格的）地址，如：
    
  • 当某人（或某个应用程序）提供此格式的地址时，应该能够将其粘贴到钱包的“to”字段中，然后单击“发送”。钱包应以任何可能的方式自动处理该发送：
    • a）如果在目标链上已经拥有足够数量的所需类型的代币，则直接发送该代币。
    • b）如果在另一条链（或多条其他链）上有所需类型的代币，可使用ERC-7683: Cross Chain Intents——An interface for cross-chain trade execution systems之类的协议 （实际上是跨链 DEX）来发送该代币。
    • c）如果在同一条链或其他链上有不同类型的代币， 可使用去中心化交易所将它们转换为正确链上的正确代币类型并发送。这应该需要用户的明确许可：用户将看到他们支付了多少钱，以及收款人获得了多少钱。

支持跨链地址的钱包接口原型示意如下：

以上内容适用于“复制粘贴地址（或 ENS，如，vitalik.eth @ optimism.eth）以便某人向你付款”的用例。如果 dapp 请求存款（如，参见 此 Polymarket 示例），那么理想的流程是扩展 web3 API 并允许 dapp 发出特定于链的付款请求。然后，钱包将能够以任何需要的方式满足该请求。要使用户体验良好，还需要标准化 getAvailableBalance 请求，并且钱包需要认真考虑默认情况下将用户资产存储在哪些链上，以最大限度地提高安全性和转账的便利性。
下图为当前向Polymarket存款操作现状：

下图为Polymarket存款所期望的状态：

特定于链的支付请求也可以放入二维码中，移动钱包可以扫描二维码。在面对面（或在线）消费者支付场景中：

• 收款人将进行二维码或 web3 API 调用，表示“我想要链Z上的 X个Y代币，带有参考 ID 或回调 W”，钱包可以自由地以任何可能的方式满足该请求。
• 另一种选择是claim link协议，用户的钱包会生成一个二维码或 URL，其中包含从其链上合约中claim一定数量资金的授权，收款人的工作就是弄清楚如何将这些资金转移到自己的钱包中。

另一个相关主题是 gas 支付。如果在尚未拥有 ETH 的 L2 上接收资产，且需要在该 L2 上发送交易，则钱包应该能够自动使用协议（如RIP-7755: Contract standard for cross-L2 calls facilitation）在你拥有ETH 的链上支付 gas 。如果钱包预计你将来会在 L2 上进行更多交易，它也应该使用 DEX 发送价值数百万 gas 的 ETH，以便未来的交易可以直接在那里使用 gas（因为这样更便宜）。

3. 钱包安全（账户安全）

概念化账户安全挑战的一种方式是，一个好的钱包应该同时在两个方面表现良好：

• 1）保护用户免受钱包开发者的黑客攻击或恶意攻击，以及
• 2）保护用户免受他们自己错误的影响。

上图左侧的拼写错误“mistakles”并非故意的。但是，它非常适合上下文，所以决定保留。

根据Vitalik 2014年博客Bitcoin Multisig Wallet: The Future of Bitcoin 以及 2021年博客Why we need wide adoption of social recovery wallets可知，过去十年来，Vitalik对账户安全的首选解决方案一直是社交恢复和多签钱包，并采用分级访问控制。
用户帐户有两层密钥：

• 1）主密钥。主密钥能够执行低价值和非金融操作。如果有必要，可允许主密钥使用时间锁执行高价值操作。
• 2）和 N 个guardians监护人（如 N = 5）。大多数监护人需要执行：
  • a）高价值操作，如发送帐户中的全部价值，或
  • b）更改主密钥或任何监护人。

以上是基本设计，可以进行扩充。会话密钥和ERC-7715: Adds JSON-RPC method for granting permissions from a wallet等权限机制可以帮助支持不同应用程序在便利性和安全性之间的不同平衡。更复杂的监护架构（如在不同阈值处具有多个时间锁持续时间）可以帮助最大限度地提高合法账户恢复成功的机会，同时最大限度地降低被盗风险。

3.1 谁能成为监护人？

关于“谁能成为监护人”这个问题，目前主要有4个选项：

• 1）选项一：使用朋友和家人的密钥。
• 2）选项二：使用机构监护人。
• 3）选项三：使用多个个人设备，或者，passkeys。
• 4）选项四：ZK-wrapped中心化ID。

对于身处经验丰富的加密用户社区的经验丰富的加密用户来说，一个可行的选择是使用朋友和家人的密钥。如果你要求每个人为你提供一个新地址，那么没有人需要知道他们是谁——事实上，你的监护人甚至不需要知道彼此是谁。他们合谋而没有一个人向你透露消息的可能性很小。然而，对于大多数新用户来说，这个选项是不可用的。

第二种选择是机构监护人：专门提供仅在收到其他确认请求来自你时才签署交易服务的公司，如确认码，或针对高价值用户的视频通话。人们已经尝试了很长时间，如Vitalik在 2014 年对 CryptoCorp 进行了分析（详情见比特币杂志2014年博客Multisig: A Revolution Incomplete）。然而，到目前为止，这类公司并没有取得太大成功。

第三种选择是多个个人设备（如手机、台式电脑、硬件钱包）。这种方法可行，但对于缺乏经验的用户来说，设置和管理起来也很困难。设备还存在同时丢失或被盗的风险，尤其是当它们位于同一位置时。

最近，开始看到更多基于passkeys的钱包。passkeys可以只备份在你的设备上，使其成为一种个人设备解决方案，也可以备份在云中，使其安全性依赖于复杂的密码安全性、机构和可信硬件假设的混合 。实际上，passkeys对于普通用户来说是一项宝贵的安全保障，但仅凭它们还不足以保护用户一生的积蓄。

更多passkeys信息可参看：

• 苹果2024年9月博客 About the security of passkeys
• 谷歌2022年10月博客 Security of Passkeys in the Google Password Manager

幸运的是，有了 ZK-SNARKs，就有了第四种选择：ZK-wrapped中心化ID。这种类型包括zk-email、Anon Aadhaar、Myna Wallet 等等。基本上，可以采用多种形式的（企业或政府）中心化 ID，并将其转换为以太坊地址，只能通过生成证明拥有该中心化 ID 的 ZK-SNARK 来从该地址发送交易。

有了这个补充，现在有了更广泛的选择，而且 ZK-wrapped中心化ID 是独一无二的“新手友好型”。

为了实现这一点，需要使用精简且集成的用户界面来实现：

• 你应该能够只指定你想要“example@gmail.com”作为监护人，它应该会自动在后台生成相应的 zk-email 以太坊地址。
• 高级用户应该能够将他们的电子邮件（以及可能用于隐私的盐值，该值将保存在该电子邮件中）输入到开源第三方应用程序中，并确认生成的地址是正确的。
• 对于任何其他受支持的监护人类型也应该如此。

可能的安全接口模型示意如下：

请注意，目前 zk-email 面临的一个实际挑战是：

• 它依赖于DKIM 签名，DKIM 签名使用每隔几个月轮换一次的密钥，并且这些密钥本身未由任何其他机构签名。（详情见2023年博客What is DKIM for Email Authentication and How Does it Work?）
• 这意味着如今 zk-email 除了提供商本身之外还有一定程度的信任要求。
  • 如果 zk-email 在受信任的硬件中使用TLSNotary来验证更新的密钥，则可以降低信任要求，但这并不理想。
  • 希望电子邮件提供商能够开始直接签署他们的 DKIM 密钥。
  • 目前，Vitalik建议对一位监护人使用 zk-email，但不要对大多数监护人使用：不要将资金存储在 “zk-email 中断意味着你将无法访问资金” 的设置中。

3.2 新用户和in-app钱包

新用户实际上并不想在首次注册时输入大量监护人。因此，钱包应该为他们提供一个非常简单的选项。一种自然的方法是使用电子邮件地址上的 zk-email、用户设备本地存储的密钥（可以是passkeys）和提供商持有的备份密钥进行 2-of-3 操作。随着用户变得更加有经验或积累了更多资产，在某个时候应该提示他们添加更多监护人。

应用程序中集成钱包是不可避免的，因为试图吸引非加密用户的应用程序不希望让用户同时下载两个新应用程序（应用程序本身加上以太坊钱包），从而带来令人困惑的用户体验。但是，许多应用程序钱包的用户应该能够将他们的所有钱包链接在一起，这样他们就只需要担心一个“访问控制问题”。最简单的方法是分层方案，其中有一个快速的“链接”过程，允许用户将他们的主钱包设置为所有应用内钱包的守护者。Farcaster 客户端 Warpcast 已经支持这一点：

默认情况下，Warpcast 帐户的恢复由 Warpcast 团队控制。但是，你可以“掌控”你的 Farcaster 帐户，并将恢复更改为你自己的地址。

3.3 保护用户免受诈骗和其他外部威胁

除了账户安全之外，如今的钱包还采取了很多措施来识别虚假地址、网络钓鱼、诈骗和其他外部威胁，并试图保护用户免受此类威胁。与此同时，许多对策仍然相当原始：如，要求点击才能将 ETH 或其他代币发送到任何新地址，无论你发送的是 100 美元还是 100,000 美元。这里没有单一的灵丹妙药解决方案，它是一系列缓慢持续的修复和对不同类别威胁的改进。然而，继续努力改进这里有很多价值。

4. 隐私

现在是时候开始更加认真地对待以太坊上的隐私问题了。ZK-SNARK 技术现在非常先进，无需依赖后门即可减轻监管风险的隐私技术（如隐私池（见2023年9月论文Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium））正变得越来越成熟，而Waku和 ERC-4337 内存池等二级基础设施也正在慢慢变得更加稳定。然而，到目前为止，在以太坊上进行私人转账需要用户明确下载并使用“隐私钱包”，如Railway（或用于stealth address隐身地址的Umbra）。这带来了极大的不便，并减少了愿意进行私人转账的人数。解决方案是：将私人转账直接集成到钱包中。

一个简单的实现如下，钱包可以将用户的部分资产作为“私人余额”存放在隐私池中，当用户进行转账时，会自动先从隐私池中提现，如果用户需要收款，钱包可以自动生成一个隐身地址。

此外，钱包可以自动为用户参与的每个应用程序生成一个新地址（如 defi 协议）。存款将来自隐私池，取款将直接进入隐私池。这允许用户在任何一个应用程序中的活动与他们在其他应用程序中的活动脱钩。

这种技术的一个优点是，它不仅是保护隐私的资产转移的自然途径，也是保护隐私的身份的自然途径。身份已经发生在链上：任何使用proof-of-personhood gating的应用程序（如 Gitcoin Grants）、任何token-gated chat、Ethereum Follow Protocol | efp.eth 等等都是链上身份。
希望这个生态系统也能保护隐私。这意味着用户的链上活动不应收集在一个地方：每个项目都应单独存储，并且用户的钱包应该是唯一具有“全局视图”的东西，可以同时看到你的所有证明。原生的每个用户多账户生态系统有助于实现这一点，Ethereum Attestation Service（EAS）和Zupass等链下attestation协议也是如此。

这代表了以太坊中期隐私的务实愿景。它今天就可以实现，尽管可以在 L1 和 L2 引入一些功能，使隐私保护传输更加高效和可靠。一些隐私倡导者认为，唯一可接受的事情是完全隐私：

• 加密整个 EVM。

Vitalik认为这可能是长期的理想结果，但它需要对编程模型进行更根本的重新思考，而且它目前还没有成熟到可以在以太坊上部署的程度。
确实需要默认隐私来获得足够大的匿名集。然而，首先关注：

• 1）账户之间的转账，以及
• 2）身份和身份相关用例（如attestations）的私密性

是一个务实的第一步，它更容易实现，钱包今天就可以开始使用它。

4.1 以太坊钱包也需要成为数据钱包

任何有效的隐私解决方案（无论是用于支付、身份或其他用例）都会产生一个后果，即用户需要存储链下数据。这在 Tornado Cash 中很明显，它要求用户保存代表 0.1-100 ETH 存款的每个“note票据”。更现代的隐私协议有时会将加密的数据保存在链上，并使用单个私钥对其进行解密。这是有风险的，因为如果该私钥泄露，或者量子计算机变得可行，那么所有数据都会公开。像 EAS 和 Zupass 这样的链下attestations对链下数据存储的需求更加明显。

钱包不仅需要成为存储链上访问权限的软件，还需要成为存储私人数据的软件。这也是非加密世界越来越认识到的一点，如参见 Tim Berners-Lee在个人数据存储方面的最新工作，详情见2024年3月博客Your personal data all over the web - is there a better way?。

所需解决的所有问题都是围绕稳健地保证访问权限控制，还需要解决围绕稳健地保证数据的可访问性和不泄漏的问题。也许这些解决方案可以叠加在一起：如果你有 N 个监护人，那么请在这 N 个监护人之间使用 M-of-N 秘密共享来存储你的数据。数据本质上更难保护，因为你不能撤销某人的份额，但人们应该想出尽可能安全的去中心化托管解决方案。

5. 安全链访问

如今，钱包信任其 RPC 提供商会向其提供有关链的任何信息。这在两个方面存在漏洞：

• 1）漏洞1：RPC 提供商可能会试图通过提供虚假信息（如有关市场价格的信息）来窃取资金
• 2）漏洞2：RPC 提供程序可以提取有关 用户正在与哪些应用程序和其他帐户交互的私人信息

理想情况下，希望堵住这两个漏洞。要堵住第一个漏洞，需要为 L1 和 L2 提供标准化的轻客户端，它们可以直接验证区块链共识。Helios已经为L1实现了这一点，并且一直在做一些前期工作来支持某些特定的 L2。为了正确覆盖所有 L2，需要一个标准，代表 L2（也用于链特定地址）的 config contract 可以声明一个函数，可能类似于ERC-3668: CCIP Read—Secure offchain data retrieval. CCIP Read provides a mechanism to allow a contract to fetch external data.的方式，包含获取最近状态根的逻辑，并根据这些状态根验证状态证明和收据。这样就可以有一个通用的轻客户端，允许钱包安全地验证 L1 和 L2 上的任何状态或事件。

对于隐私，如今唯一现实的方法是运行自己的全节点。但是，现在 L2 正在进入市场，运行一个包含所有内容的全节点变得越来越困难。这里与轻客户端相当的是私人信息检索（Private information retrieval，PIR）。PIR 涉及一个持有所有数据副本的服务器，以及一个向服务器发送加密请求的客户端。服务器对所有数据执行计算，返回客户端所需的数据（使用客户端的密钥加密），而不会向服务器透露客户端访问了哪些数据。

为了保证服务器的诚实，各个数据库项本身将是 Merkle 分支，因此客户端可以使用他们的轻客户端来验证这些数据。

PIR 的计算成本非常高。有几种方法可以解决这个问题：

• 蛮力攻击：算法或专用硬件的改进可能会使 PIR 运行得足够快。这些技术可能依赖于预处理：服务器可以为每个客户端存储 encrypted-and-shuffled 数据，客户端可以查询这些数据。以太坊环境中的主要挑战是将这些技术应用于快速变化的数据集（就像状态一样）。这使得实时计算成本更低，但可能会使总计算和存储成本更高。
• 削弱隐私要求：如，每次查找只能有 100 万个“mixins”，因此服务器会知道客户端可以访问的一百万个可能的值，但无法知道更细粒度的值
• 多服务器 PIR：如果使用多台服务器，并且这些服务器之间有 1-of-N 诚实假设，则 PIR 算法通常会更快。
• 匿名而非保密（Anonymity instead of confidentiality）：请求可以通过混合网络发送，从而隐藏请求的发送者，而不是隐藏请求的内容。然而，这样做不可避免地会增加延迟，从而降低用户体验。

在以太坊环境下，找到正确的技术组合来最大化隐私同时保持实用性是一个开放的研究问题，欢迎密码学家尝试一下。

6. 理想的keystore密钥库钱包

除了转账和状态访问之外，另一个需要在跨 L2 环境中顺利运行的重要工作流程是更改帐户的验证配置：无论是更改其密钥（如恢复），还是对帐户的整个逻辑进行更深入的更改。这里有三层解决方案，按难度递增顺序排列：

• 1）方案一：Replayed updates重播更新：当用户更改其配置时，授权此更改的消息将在钱包检测到用户拥有资产的每个链上重播。消息格式和验证规则可以独立于链，因此可以在尽可能多的链上自动重播。
• 2）方案二：L1 上的密钥库：配置信息位于 L1 上，L2 上的钱包使用RIP-7728: L1SLOAD precompile 或Foundation Mission Request: Remote Static Call Proof of Concept #76 读取配置信息。这样，只需在 L1 上更新配置，配置就会自动生效。
• 3）方案三：L2 上的密钥库：配置信息位于 L2 上，L2 上的钱包使用 ZK-SNARK 读取。这与2）相同，只是密钥库更新成本更低，但另一方面，读取成本更高。

方案三特别强大，因为它可以很好地与隐私叠加。在正常的“隐私解决方案”中，用户有一个秘密s，一个“叶子值”L在链上发布，用户证明L = hash(s, 1) 和 N = hash(s, 2)，其中s为其控制的某（从未透露的）秘密。nullifier N被发布，确保同一叶子的未来支出失败，而不会泄露 L。这取决于用户保持s安全。 恢复友好的隐私解决方案会改为说： s是链上的位置（如地址和存储槽），用户必须证明状态查询：L = hash(sload(s), 1)。

7. Dapp 安全

用户安全中最薄弱的环节往往是 dapp。大多数情况下，用户通过访问网站与应用程序进行交互，该网站会从服务器实时隐式下载用户界面代码，然后在浏览器中执行。如果服务器被黑客入侵，或者 DNS 被黑客入侵，用户将获得界面的假副本，这可能会诱骗用户做任意的事情。交易模拟等钱包功能对于降低风险非常有帮助，但它们远非完美。

理想情况下，会将生态系统转移到链上内容版本控制：用户将通过其 ENS 名称访问 dapp，该名称将包含接口的 IPFS 哈希。需要来自多签或 DAO 的链上交易来更新接口。钱包会向用户显示他们正在与更安全的链上接口交互，还是与不太安全的 web2 接口交互。钱包还可以向用户显示他们是否正在与安全链交互（如Stage 1+，多次安全审计）。

对于注重隐私的用户，钱包还可以添加paranoid 偏执模式，要求用户点击接受 HTTP 请求，而不仅仅是 web3 操作，偏执模式可能的界面模型示意如下：

更先进的方法是超越 HTML + Javascript，用专用语言编写 dapp 的业务逻辑，也许是 Solidity 或 Vyper 上相对较薄的覆盖。然后浏览器可以自动为任何所需功能生成 UI。OKContract已经在这样做了。

另一个方向是加密经济信息防御：dapp 开发者、安全公司、链部署人员和其他人员可以建立债券，如果某个 dapp 被黑客入侵或以高度误导的方式损害了用户，则将向受影响的用户支付债券，这由某些链上裁决 DAO 确定。钱包可以根据债券的大小向用户显示分数。

8. 长期未来

以上内容都是在传统界面的背景下进行的，这些界面涉及指向和点击内容以及在文本字段中输入内容。然而，当前也正处于范式更深刻变革的边缘：

• 1）人工智能，它将带领我们从点击输入模式转向“说出你想做什么，机器人就会帮你做”的模式
• 2）脑机接口（Brain-computer interface，BCI），既有眼动追踪等“温和”的方法，也有更直接甚至侵入性的技术（参见：今年首位 Neuralink 患者，参见2024年5月新闻Neuralink’s First User Is ‘Constantly Multitasking’ With His Brain Implant）。
• 3）客户端主动防御：Brave 浏览器主动保护用户免受广告、跟踪器和许多其他不良对象的侵害（详情见：Brave Shields: Default protection. On every web page you visit.）。许多浏览器、插件和加密钱包都有整个团队积极致力于保护用户免受各种安全和隐私威胁。这些“主动守护者”在未来十年将变得更加强大。

这三种趋势将共同引发对界面工作方式的更深入的重新思考。通过自然语言输入、眼动追踪或最终更直接的 BCI，再加上对历史记录的了解（可能包括短信，只要所有数据都在本地处理），“钱包”可以清晰直观地了解你想要做什么。然后，人工智能可以将这种直觉转化为具体的“行动计划”：一系列链上和链下交互，以实现你想要的目标。这可以大大减少对第三方用户界面的需求。如果用户确实与第三方应用程序（或其他用户）交互，人工智能应该代表用户进行对抗性思考，识别任何威胁并提出避免这些威胁的行动计划。理想情况下，这些人工智能将有一个开放的生态系统，由具有不同偏见和激励结构的不同团体生产。

这些更激进的想法依赖于 目前极其不成熟的技术，所以Vitalik不会将其资产投入到依赖它们的钱包中。然而，这样的事情似乎很明显是未来的趋势，因此值得开始更积极地朝这个方向探索。

参考资料

[1] Vitalik 2024年12月3日博客 What I would love to see in a wallet