钱包与用户入门：三密钥系统足够安全吗？

我为 0xFable 思考了一些关于钱包和用户入门的问题。以下一些热点话题。我们将讨论：

- 我理想的账户架构

- 安全考虑

- 现有 web3 登录提供商的概况

显然，在用户入门过程中，让用户安装钱包软件并保护助记词是行不通的。 我们需要一些友好的、相当安全的、并且相当面向未来的东西。

架构

每个用户都有自己的智能账户，有三个密钥：

1. 设备密钥 ， 最初是本地存储，但希望以后是密钥/网络身份验证。

2. 补充密钥，例如由提供商控制并通过社交登录解锁的密钥。

3. 备份密钥，例如由第三方保管（可以像电子邮件附件或 Dropbox / Google Drive 一样简单）。

如果这听起来技术含量低或不安全，恐怕您已经被提供商的谎言迷惑了，因为它们实际上并没有比这更安全（而且往往不如这种方法安全，例如，(2) 和 (3) 都由同一方控制）。 稍后将详细介绍。

在此设置中，您可以使用设备密钥进行游戏操作，无需用户交互。 对于资产转账和交易，您可能需要补充密钥。

简单模式是让用户使用Google/Apple/Facebook/…登录，然后添加确认提示。 这使得入门变得容易。 但如果用户需要更高的安全性，则可以用传统的 EOA 替换该密钥（尽管这可能应该位于另一台设备或硬件钱包上）。

任何一对密钥都可以用来代替第三把钥匙。

因此，备份密钥是指在其他密钥之一丢失（特别是设备密钥）或提供商不可用或受到威胁的情况下。 将备份密钥简单地作为托管在云上的文件使此入门变得简单且无成本。 如果需要，该密钥也可以由硬件钱包或优质提供商替换。

安全分析

这有多安全？大体上来说，是相对安全的！要同时侵入两个设备或实体才能导致资金丢失，但系统是十分强大的。

大多数情况下，存在会降低安全性的配置风险。 例如，将备份密钥托管在您的 Google 云端硬盘上，同时将补充密钥分配给您的 Google 账户。 或者使用热钱包作为补充密钥，与设备密钥具有相同的风险。

用户可能会丢失备份。 定期提示他轮换设备密钥可能是个好主意，这会迫使他找到备用密钥。

如果备份密钥被简单地存储，它也很容易被盗。 这比热钱包更糟糕，热钱包在磁盘上加密密钥（并且需要密码才能在内存中解密）。 所以定期更换密钥似乎是个好主意。 无论如何，增加的密钥可用性（允许您使用设备身份验证登录应用程序）将解决此问题。

了解社交登录意味着对提供商的信任。 提供商本质上有一个密钥，他可以随心所欲地使用，但他向您保证，在您使用社交账户登录后，他只会根据您的需要使用。 不要被看似奇特的密码学主张所愚弄——这也是它的结论。

最后，请注意，只要免费密钥是 dapp 创建者提供的登录名，或者没有确认提示，那么 dapp 创建者就很容易欺骗用户（因为他们编写了拥有设备密钥的前端，以及拥有或可以控制免费密钥）。

供应商情况

到目前为止，据我所知，没有提供这种功能的人。通常问题在于要么没有备份密钥，要么由同一实体（例如Coinbase钱包）提供安全保障。

市场主要分为：

提供综合多密钥解决方案的供应商，可以使用智能合约或使用多方计算（MPC，一种密码学技术）将多个密钥合并为单个EOA。

低层级供应商会代管用户的密钥，并允许他们在登录后对事务进行签名。

全栈供应商，例如：Particle Network、Privy、Alembic Tech、Magic、Web3Auth、Turnkey、Dynamic、0xPass、Fireblocks、Portal、Capsule、ZeroDev、Keyp、Circle Developers。

密钥保管商，例如：Lit Protocol 、Amazon 。

是的，有很多。 他们都没有区别，这也有点滑稽。

无论何时，只要商业模式是透明的，这些服务通常会向您收取每用户每年0.02到0.05美元。这对我来说似乎相当合理。

有趣的是，所有这些工具都被定位为开发工具。似乎没有一家公司试图将这些技术应用于成为用户的主要钱包。

当然，要与现有的 dapp 一起使用，你需要安装钱包软件。所以这个系统的好处被减少到了去掉助记词。但你也可以让 dapp 推广你最容易入门的方式（如果它们集成你甚至无需安装钱包软件）。你获得了用户，dapp 获得了零成本的轻松入门。双赢。

对供应商的担忧

除了没有实现我的理想架构之外，这些解决方案通常会引入大型集中化向量，例如 REST API，或一些 MPC 计算，如果它们宕机，您将无法自己进行这些计算（是否公开发布？经过审计？）。

目前还不清楚如果您想与提供商终止合作会发生什么。 他们拥有（一些）您用户的密钥！ 这与我对 Rollups 即服务表达的担忧非常相似：https://twitter.com/norswap/status/1714386634299314563

在这条推文之后，一位 RaaS 创始人告诉我，在允许轻松退出和避免创始人欺骗用户（这会对 RaaS 造成不良影响）之间需要进行权衡。 这也适用于这里！

以下是如何使用上述架构轻松切换提供商：用户在链上提交其社交帐户（例如 [email protected]）的哈希值。 每个社交登录提供商都有自己的私钥（每个用户不需要有一个密钥，而且通常也不会更安全）。 智能账户是指保存当前提供者账户的单例合约。 切换提供商就像更改此账户一样简单。

最后，我鼓励您阅读这条推文：https://twitter.com/gregthegreek/status/1716390418156281993

他的一个要点是，为每个应用程序发行一个账户将是一场用户体验噩梦。 我同意，这是这些提供商应该真正考虑成为可以跨应用程序运行的成熟钱包的另一个原因。

最后的思考

我们显然正在向理想的入门目标迈进。 理想的情况是这些易于使用的钱包与用户直接建立关系。 然后，dapp 可以完全忽略这个问题，只需与钱包建立合作伙伴关系，确定默认的登录钱包是谁。

如果做不到这一点，我的解决方案必须是推出我自己的系统 - 将您自己的社交登录提供程序插入到上面的架构中并不难。 然而，我“宁愿”使用外部提供商。 如上所述，如果 dapp 创建者控制免费密钥，那么系统就不是完全去中心化的。