当前位置:首页 > 资讯 >

探讨账户架构:为什么三密钥系统是理想的解决方案?

原文作者:Norswap

原文编译:深潮 TechFlow

我为 0x Fable 思考了很多关于钱包和用户入门的问题。以下我的一些观点。我们将讨论:

  • 我理想的账户架构;

  • 安全考虑;

  • 现有 Web3 登录提供商的概况,

显然,在入门过程中要求用户安装钱包软件并保存助记词是不可取的。我们需要一个友好、相对安全、并有一定前瞻性的方法。

架构

每个用户都会获得自己的智能帐户,其中包含三个密钥:

  • 设备密钥——最初可以存储在本地,但希望未来能使用通行密钥/webauthn。

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

  • 备份密钥,例如由第三方保管(可以简单地作为电子邮件附件或存放在 Dropbox /

    Google

    Drive 上)。

如果这听起来技术含量不高或不安全,恐怕你已经被提供商甜言蜜语所迷惑,因为它们实际上并没有比这更安全(很多时候甚至更少——例如,密钥(2)和(3)都由同一方控制)。

在这个设置中,你可以使用设备密钥进行操作,不需要用户互动。对于涉及资产的转账和交易,你可以要求使用补充密钥。

简单的模式是让用户用 Google/

Apple

/Facebook 等登录,然后添加一个确认提示。这使得入门变得简单。但是,如果用户需要更多的安全性,就可以用传统的 EOA 来代替这把密钥。此外,任何一对密钥都可以用来替换备份密钥,备份密钥只需是一个托管在云端的文件。

安全分析

这有多安全?大部分情况下,他是安全的。两个设备或实体必须在同一时间被破坏才会发生资金损失。

主要的是,有一些配置风险可能降低安全性。例如,在 Google Drive 上托管备份密钥,同时将补充密钥分配给你的 Google 帐户。或者使用一个热钱包作为补充密钥,这与设备密钥有着相同的风险。用户可能会弄丢他的备份。最好定期提示用户轮换设备密钥,迫使他找到备份密钥。

如果备份密钥是公开存储的,它也非常容易被盗。这比热钱包还要糟糕,后者在磁盘上加密密钥(并需要密码在内存中解密)。无论如何,通行密钥的增加(允许你使用设备认证登录应用程序)将解决这个问题。

要明白,社交登录意味着信任一个提供商。提供商基本上有一个他可以随心所欲使用的密钥,但他向你承诺,只有在你使用社交账户登录后,他才会按照你的要求使用它。最后,请注意,当补充密钥是由 dapp 创作者提供的,或者没有确认提示时,那么 dapp 创建者就很容易欺骗用户(因为他们编写了拥有设备密钥的前端,并且拥有或可以控制补充密钥)。

现有提供商概况

今天有谁提供这个?据我所知,没有。问题通常是,要么没有备份密钥,要么它是由相同的实体保管的(例如

Coinbase

钱包)。

市场主要分为两类:

  • 提供集成多密钥解决方案的提供商,要么使用智能账户,要么使用 MPC(多方计算,一种密码学技术)将多个密钥组合成单个 EOA。

  • 更低级别的提供商,为你保管用户密钥,并允许他们在登录后签名。

这里有很多全栈提供商:

Particle Network

Privy

、Alembic Tech、

Magic

、Web3 Auth、

Turnkey

Dynamic

、0x Pass、

Fireblocks

Portal

Capsule

、ZeroDev、Keyp、

Circle

Developers。

密钥保管商如:

Lit Protocol

、Amazon 。

是的,有很多这样的东西。他们之间基本上没有什么区别。当商业模式透明时,这些通常每年每用户收费 0.02 到 0.05 美元。对我来说,这似乎是相当合理的。

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

当然,要与现有的 dapps 合作,你需要安装钱包软件。所以,系统的优势减少到去除助记词。但你也可以让 dapps 推广你作为最容易入门的方式(如果他们集成了你,甚至无需安装钱包软件)。你获得用户,dapp 可以免费轻松入门。双赢。

对提供商的担忧

除了不实现我理想的架构,这些解决方案往往还引入了大的中心化因素,比如 REST API,或者一些 MPC 计算,如果它们停业,您将无法自己进行这些计算(甚至公开发布吗?已审核?) .

目前还不清楚如果您停止与提供商的合作会发生什么。他们拥有(部分)你的用户的密钥!这与我对 Rollups-as-a-service 的担忧非常相似。

在这之后,一个 RaaS 创始人告诉我,允许轻松退出和避免创始人欺骗他们的用户(这将对 RaaS 产生不良影响)之间存在权衡。

以下是如何使用上述架构轻松切换提供商:用户在链上提交他们社交账户的哈希(例如 [email protected])。每个社交登录提供商都有自己的私钥(没有必要为每个用户拥有一个密钥,而且通常也不更安全)。智能账户引用一个单例合约,该合约保存当前提供商的账户。切换提供商就像更改这个账户一样简单。

最后的思考

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

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

猜你喜欢

关注我们

微信二维码

微信