理想以太坊钱包:跨链、安全与隐私的全面升级

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

以太坊基础设施堆栈中的钱包层至关重要,但常常被核心研究人员和开发者低估。钱包是用户与以太坊世界交互的窗口,只有当钱包本身具备相应属性时,用户才能真正享受到以太坊及其应用程序提供的去中心化、抗审查、安全和隐私等特性。

近期以太坊钱包在改善用户体验、安全性和功能方面取得了显著进展。本文旨在探讨理想以太坊钱包应具备的一些特性。这并非一份完整清单,而是反映了作者的密码朋克倾向,聚焦于安全和隐私方面。虽然在用户体验方面可能不够全面,但考虑到优化用户体验更适合通过部署和迭代来实现,因此本文将重点关注安全和隐私属性。

Vitalik新文:理想钱包的愿景,从跨链体验到隐私保护的全方位升级

跨L2交易的用户体验

目前已有一个日益详细的路线图来改善跨L2用户体验,包括短期和长期部分。这里主要讨论短期可实施的想法。

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

当用户收到这种格式的地址时,只需将其粘贴到钱包的"收款人"栏并点击"发送",钱包就会自动处理发送操作:

  • 如果目标链上已有足够所需代币,直接发送
  • 如果其他链上有所需代币,使用跨链DEX协议发送
  • 如果有其他类型代币,使用DEX转换后发送

对于dapp请求存款的场景,理想的流程是扩展web3 API,允许dapp发出链特定的支付请求。钱包可以灵活处理这些请求。为了良好的用户体验,还需要标准化查询可用余额的请求,钱包也需要慎重考虑默认将用户资产存储在哪些链上。

链特定支付请求也可以放入二维码中供移动钱包扫描。在面对面或在线支付场景中,接收方可以发出二维码或web3 API调用,表明"我希望在X链上收到Y单位的Z代币,参考ID为W"。钱包可以自由选择满足该请求的方式。

另一个相关主题是gas费支付。如果用户在某个L2上收到资产但没有ETH支付gas,钱包应该能自动使用协议从其他有ETH的链上支付gas。如果钱包预计用户未来会在该L2上进行更多交易,也可以只通过DEX发送足够支付一定数量gas的ETH,以便未来直接在该链上支付gas(因为这样更便宜)。

Vitalik新文:理想钱包的愿景,从跨链体验到隐私保护的全方位升级

账户安全

账户安全的一个概念化方式是,一个好的钱包应该同时在两个方面发挥作用:(1)保护用户免受钱包开发人员的攻击或恶意行为,(2)保护用户免受自身错误的影响。

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

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

Vitalik新文:理想钱包的愿景,从跨链体验到隐私保护的全方位升级

监护人的选择

对于经验丰富的加密用户,一个可行的选择是使用朋友和家人的密钥作为监护人。如果每个人提供一个新地址,甚至不需要知道彼此的身份,这降低了串通的可能性。但对大多数新用户来说,这个选项不太可行。

第二种选择是机构监护人:专门提供仅在收到额外确认信息(如确认码或视频通话)时才签署交易的服务。这种尝试由来已久,但目前还不是很成功。

第三种选择是多个个人设备(如手机、电脑、硬件钱包)。这可行但对新手用户来说设置和管理较困难,且存在设备同时丢失或被盗的风险。

近期出现了更多基于万能密钥的方案。密钥可以只备份在设备上,也可以备份在云端,安全性依赖于复杂的混合密码、机构和可信硬件假设。虽然对普通用户来说是宝贵的安全增益,但仅靠它们还不足以保护用户的全部资产。

幸运的是,ZK-SNARK技术为我们提供了第四种选择:ZK包装的中心化ID。这包括zk-email、Anon Aadhaar、Myna Wallet等。基本思路是将各种形式(公司或政府)的中心化ID转换为以太坊地址,用户只能通过生成证明拥有该中心化ID的ZK-SNARK来发送交易。

这种方案需要通过简化且集成的UI来实现:用户应该能够仅指定想要使用的邮箱地址作为监护人,系统就会自动在后台生成相应的zk-email以太坊地址。高级用户应该能够将邮箱(及可能保存的隐私盐值)输入到开源第三方应用中,并确认生成的地址是否正确。其他支持的监护人类型也应如此。

需要注意的是,目前zk-email面临的一个实际挑战是它依赖于每隔几个月轮换一次的DKIM签名密钥,而这些密钥本身并未由其他机构签名。这意味着当前的zk-email在某种程度上需要信任提供商本身。如果在可信硬件内使用TLSNotary来验证更新的密钥,可以减少这种依赖,但仍不理想。希望邮件提供商能够开始直接签署其DKIM密钥。目前建议将zk-email作为监护人之一使用,但不建议大多数监护人都使用:不要将资金存储在zk-email出现问题就无法使用资金的设置中。

Vitalik新文:理想钱包的愿景,从跨链体验到隐私保护的全方位升级

新用户和应用内钱包

新用户实际上不希望在首次注册时输入大量监护人信息。因此,钱包应该为他们提供一个非常简单的选择。一种自然的方式是使用邮箱地址的zk-email、本地存储在用户设备上的密钥(可能是万能密钥)以及由提供商持有的备份密钥,进行2-of-3的选择。随着用户积累更多经验或资产,应该在适当时机提示他们添加更多监护人。

将钱包集成到应用中是不可避免的,因为面向非加密用户的应用不希望用户同时下载两个新应用(应用本身加上以太坊钱包)而带来混乱的用户体验。然而,许多应用内钱包的用户应该能够将所有钱包链接在一起,这样就只需关注一个"访问控制问题"。最简单的方法是采用分层方案,通过一个快速的"链接"过程,允许用户将主钱包设置为所有应用内钱包的监护人。

Vitalik新文:理想钱包的愿景,从跨链体验到隐私保护的全方位升级

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

除了账户安全,当今的钱包还在识别虚假地址、网络钓鱼、诈骗等外部威胁方面做了大量工作,并努力保护用户免受这些威胁。同时,许多对策仍然相当原始,如无论发送100美元还是10万美元都要求点击确认。在这方面并不存在单一的完美解决方案,而是需要针对不同类别的威胁进行一系列持续的改进。继续在这方面努力很有价值。

Vitalik新文:理想钱包的愿景,从跨链体验到隐私保护的全方位升级

隐私

现在是时候更加认真地对待以太坊的隐私了。ZK-SNARK技术已经非常先进,不依赖后门来降低监管风险的隐私技术(如隐私池)越来越成熟,二层基础设施如Waku和ERC-4337 mempools也逐渐稳定。然而,目前在以太坊上进行私密转账仍需用户明确下载并使用"隐私钱包",这增加了不便并减少了愿意进行私密转账的人数。解决方案是将私密转账直接集成到钱包中。

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

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

这种技术不仅是保护隐私资产转移的自然途径,也是保护隐私身份的自然途径。身份已经发生在链上:任何使用身份证明门控的应用、代币门控聊天、以太坊遵循协议等都是链上身份。我们希望这个生态系统也能保护隐私。这意味着用户的链上活动不应集中在一处:每个项目都应单独存储,用户的钱包应该是唯一具有"全局视图"的地方,可以同时看到所有证明。每个用户拥有多个账户的原生生态系统有助于实现这一目标,EAS和Zupass等链下证明协议也是如此。

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

Vitalik新文:理想钱包的愿景,从跨链体验到隐私保护的全方位升级

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

任何有效的隐私解决方案都会产生用户存储链

ETH2.19%
此页面可能包含第三方内容,仅供参考(非陈述/保证),不应被视为 Gate 认可其观点表述,也不得被视为财务或专业建议。详见声明
  • 赞赏
  • 4
  • 分享
评论
0/400
GasFeeCriervip
· 21小时前
手续费又要涨到天上了吧?
回复0
rug_connoisseurvip
· 21小时前
升级升级 还不如先把gas费降了
回复0
币圈疯批女友vip
· 21小时前
钱包到位 其他都是扯淡
回复0
周一梭哈周五哭vip
· 21小时前
又梭到准备卖肾了吗
回复0
交易,随时随地
qrCode
扫码下载 Gate APP
社群列表
简体中文
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)