理想以太坊钱包的愿景:从跨链体验到隐私保护的全方位升级

以太坊基础设施堆栈中钱包层至关重要,却常被核心研究人员和开发者低估。作为用户与以太坊世界的窗口,钱包自身必须具备去中心化、抗审查、安全和隐私等特性,用户才能真正享受到以太坊及其应用所提供的这些属性。

近期以太坊钱包在用户体验、安全性和功能方面都有显著进步。本文旨在分享我对理想以太坊钱包应具备特性的一些看法。这并非一个完整列表,更多反映了我的密码朋克倾向,聚焦于安全和隐私,在用户体验方面可能不够全面。不过我认为,相比单纯根据反馈部署和迭代来优化用户体验,关注安全和隐私属性可能更有价值。

跨L2交易的用户体验

目前已有一个日趋完善的改善跨L2用户体验路线图,包括短期和长期部分。这里我将讨论短期可实施的想法。

核心思路是:(1)内置跨L2发送功能,(2)链特定地址和支付请求。钱包应能为用户提供一个遵循ERC草案风格的地址。

当用户收到这种格式的地址时,只需将其粘贴到钱包的"收件人"字段并点击"发送",钱包就应自动处理发送:

• 如目标链上已有足够代币,直接发送
• 如其他链上有所需代币,使用跨链DEX协议发送
• 如有不同类型代币,使用DEX转换为正确类型后发送(需用户确认)

对于dapp请求存款的场景,理想做法是扩展web3 API,允许dapp发出链特定的支付请求。钱包需要标准化getAvailableBalance请求,并认真考虑用户资产默认存储在哪些链上,以兼顾安全性和转账便利性。

链特定支付请求也可放入二维码,供移动钱包扫描。在面对面或在线支付场景中,接收方发出的QR码或API调用表明"我想要X链上Y单位的Z代币,参考ID为W",钱包可自由选择满足该请求的方式。另一种选择是索赔链接协议,用户钱包生成包含授权的QR码或URL,接收方负责提取资金。

gas支付也是一个相关话题。如用户在某个L2上收到资产但没有ETH,钱包应能自动使用协议在用户有ETH的链上支付gas。如钱包预计用户未来会在该L2上进行更多交易,也可使用DEX发送一定数量ETH作为gas储备。

账户安全

我认为账户安全的关键在于同时保护用户免受钱包开发者的黑客攻击或恶意行为,以及用户自身错误的影响。

我长期以来倾向的解决方案是具有分级访问控制的社交恢复和多重签名钱包。用户账户有两层密钥:主密钥和N个监护人(如N=5)。主密钥可进行低价值和非财务操作。大多数监护人需要执行:(1)高价值操作,如发送账户全部资金,(2)更改主密钥或任何监护人。必要时可允许主密钥通过时间锁执行高价值操作。

这一基本设计可进一步扩展。会话密钥和权限机制可支持不同应用在便利性和安全性间取得平衡。更复杂的监护人架构,如在不同阈值下设置多个时间锁定期,有助于在最大化恢复合法账户成功率的同时,最大限度降低盗窃风险。

对于监护人的选择,有几种方案:

1. 对有经验的加密用户,可以选择朋友和家人的密钥。
2. 机构监护人:专门提供签名服务的公司,需要额外确认信息。
3. 多个个人设备(如手机、电脑、硬件钱包),但新用户可能难以设置管理。
4. 基于密码管理器的方案,可本地或云端备份,但仅靠它们还不足以保护用户全部资产。
5. ZK包装的中心化ID:如zk-email、Anon Aadhaar等,可将中心化ID转换为以太坊地址。

ZK包装的中心化ID对新用户较为友好。钱包应提供简化集成的UI,允许用户直接指定邮箱作为监护人,自动生成相应的zk-email以太坊地址。高级用户应能验证生成地址的正确性。

对于新用户,钱包可提供简单选项,如基于zk-email、本地存储密钥和提供商备份密钥的2-of-3方案。随着用户经验增长或资产增加,应提示添加更多监护人。

应用内钱包集成是不可避免的,但用户应能将所有钱包链接在一起,统一管理访问控制。一种简单方法是采用分层方案,允许用户将主钱包设置为所有应用内钱包的监护人。

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

除账户安全外,当前钱包在识别虚假地址、网络钓鱼、诈骗等方面做了大量工作。但许多对策仍较为原始,如统一要求点击确认才能向新地址发送代币,无论金额大小。这需要针对不同类别威胁持续改进,没有一劳永逸的解决方案。

隐私

是时候更认真地对待以太坊的隐私了。ZK-SNARK技术已相当先进,不依赖后门的隐私技术(如隐私池)日渐成熟,二级基础设施如Waku和ERC-4337 mempools也逐步稳定。但目前进行私密转账仍需用户明确下载使用"隐私钱包",这增加了不便并减少了使用人数。解决方案是将私密转账直接集成到钱包中。

一种简单实现是:钱包将用户部分资产作为"私密余额"存储在隐私池中。转账时自动退出隐私池,接收资金时自动生成隐形地址。

此外,钱包可为用户参与的每个应用自动生成新地址。存款来自隐私池,提款直接进入隐私池。这允许用户将在不同应用中的活动解耦。

这不仅是保护资产转移隐私的自然途径,也是保护身份隐私的方式。链上身份已经存在,如使用身份证明的应用、代币门控聊天等。我们希望这个生态系统也能保护隐私,即用户的链上活动不应集中在一处:每个项目应单独存储,只有用户钱包能同时看到所有证明。原生支持每用户多账户的生态系统有助于实现这一目标,链下证明协议如EAS和Zupass也是如此。

这代表了以太坊隐私的中期务实愿景。虽然可以在L1和L2引入一些功能使隐私保护传输更高效可靠,但现在就可以实现。一些隐私倡导者认为只有完全隐私才可接受,如加密整个EVM。这可能是理想的长期结果,但需要对编程模型进行更根本的重新思考,目前尚未达到可部署成熟度。我们确实需要默认隐私以获得足够大的匿名集。然而,首先关注(1)账户间转账,(2)身份和相关用例(如私密证明)是务实的第一步,更易实现,钱包现在就可以开始使用。

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

任何有效的隐私解决方案都会产生用户存储链下数据的需求,无论是用于支付、身份还是其他用例。现代隐私协议有时在链上保存加密数据,使用单个私钥解密。这有风险,因为如果密钥泄露或量子计算机可行,所有数据都会公开。链下证明更显著地需要链下数据存储。

钱包不仅需要存储链上访问权限,还需要存储用户私人数据。非加密世界也越来越认识到这一点。我们需要围绕数据的可访问性和防泄漏构建稳健保证。也许可以将这些解决方案叠加:如果有N个监护人,就在这N个监护人之间使用M-of-N秘密共享来存储数据。数据本质上更难保护,因为无法撤销某人的数据份额,但我们应该提出尽可能安全的去中心化托管解决方案。

安全的链访问

目前钱包依赖RPC提供商获取链信息,这存在两个漏洞:

1. RPC提供商可能通过提供虚假信息(如市场价格)来窃取资金。
2. RPC提供商可以获取用户与应用程序交互的私密信息。

理想情况下,我们希望堵住这两个漏洞。解决第一个问题需要L1和L2的标准化轻客户端,直接验证区块链共识。Helios已为L1实现,并开始支持一些L2。为覆盖所有L2,我们需要一个标准,通过代表L2的配置合约声明获取最近状态根并验证状态和收据证明的逻辑。这样就可以有一个通用轻客户端,允许钱包安全验证L1和L2上的任何状态或事件。

对于隐私,目前唯一现实的方法是运行自己的完整节点。但随着L2的普及,运行所有内容的完整节点变得越来越困难。这里的轻客户端等价物是私有信息检索(PIR)。PIR涉及保存所有数据副本的服务器和向服务器发送加密请求的客户端。服务器对所有数据执行计算,返回客户端所需的加密数据,而不知道客户端访问了哪条数据。

为保证服务器诚实,各个数据库项本身就是Merkle分支,客户端可用轻客户端验证。

PIR计算量很大。解决方案包括:

• 蛮力:算法或专用硬件改进可能使PIR运行足够快。
• 削弱隐私要求:如每次查找只有100万个"mixins"。
• 多服务器PIR:使用多个服务器,假设1-of-N诚实,PIR算法通常更快。
• 匿名而非机密性:通过混合网络发送请求,隐藏发送者而非内容。但这会增加延迟。

在以太坊环境中找出正确的技术组合来最大化隐私同时保持实用性是一个开放的研究问题。

理想的密钥库钱包

在跨L2上下文中,另一个需要顺畅工作的重要流程是更改账户验证