Alert Source Discuss
🚧 Stagnant Standards Track: ERC

ERC-1775: 应用密钥，特定于应用程序的钱包账户

Authors Vincent Eli (@Bunjin), Dan Finlay (@DanFinlay)
Created 2019-02-20
Discussion Link https://ethereum-magicians.org/t/eip-erc-app-keys-application-specific-wallet-accounts/2742

Table of Contents

简单概要

除其他加密应用程序外，以太坊区块链的可扩展性和隐私解决方案要求用户执行大量的签名操作。它还可能要求她监视某些状态并准备自动签名数据（例如，签署状态或质疑提款）。 目前钱包实现账户的方式，在用户体验、安全性和隐私性方面，对完整 web3.0 体验的开发构成了一些障碍。

本提案描述了一种新型钱包账户的标准和 API，这些账户是专门为每个给定的应用程序派生的。我们建议将它们称为 app keys（应用密钥）。 它们允许隔离每个应用程序使用的帐户，从而可能提高隐私性。 它们还允许应用程序开发者对帐户管理和签名委托进行更多控制。 对于这些应用密钥，钱包可以具有更宽松的安全级别（例如，不请求用户的确认），同时保持主账户的安全。 最后，钱包还可以实现不同的行为，例如允许签署交易而不广播它们。

这种新的账户类型可以显著改善用户体验，并为加密许可网络的应用提供新的设计。

摘要

在钱包中，用户通常将其大部分资金保存在其主账户中。 这些账户需要很高的安全性，并且不应以任何方式被委托，如果用户必须手动确认每个操作，这将严重影响加密应用程序的设计。 此外，用户通常在不同的应用程序中使用相同的账户，这是一个隐私问题，并且可能也是一个安全问题。

我们在此介绍一种新的账户类型，即应用密钥，它允许跨应用程序进行签名委托和账户隔离，以实现隐私和安全。

在本 EIP 中，我们提供了一个提案，内容是如何唯一标识和验证每个应用程序，如何从用户私钥（她的根私钥或从她的根私钥派生的账户的任何其他私钥）中为域派生一个主账户（或应用密钥）。 本 EIP 旨在成为一个标准，即如何在不需用户进一步输入的情况下，派生特定于每个应用程序的密钥，如果用户恢复她的钱包并再次使用为此密钥派生的应用程序，则可以从头开始重新生成密钥。 然后，可以赋予这些应用密钥一组不同的权限（通过 EIP-2255 中引入的 requestPermission 模型）。 这将可能允许用户部分信任某些应用程序代表他们执行某些加密操作，而不会对其主账户的任何安全性造成损害。

动机

钱包开发者已经就使用 BIP32、BIP44、SLIP44 的以太坊账户的 HD 推导路径达成一致，(请参见此处的讨论)。 Web3 钱包以大致相似的方式实现了 rpc eth api。EIP-1102 通过非自动选择加入钱包账户到应用程序来增加隐私。

但是，为了允许为加密许可应用程序进行适当的设计和 UX，仍然存在一些限制。

大多数基于 GUI 的当前钱包不允许：

  • 能够自动且毫不费力地为每个应用程序使用不同的密钥/账户，
  • 能够签署某些应用程序的操作，而无需以与其主账户发送资金相同的安全级别提示用户，
  • 能够使用可抛弃的密钥来提高匿名性，
  • 毫不费力地为应用程序签署交易而不广播这些交易，同时仍然能够像往常一样从其主账户执行其他交易签名，
  • 所有这些都可以使用用户的助记词或硬件钱包以及由应用程序的 ens 名称唯一确定的 HD 路径完全恢复。

我们试图通过引入一种新的账户类型 app keys 来克服这些限制，这种账户类型与现有的主账户一起使用。

这些新的应用密钥可以允许向加密应用程序开发者提供更多功能和灵活性。 这可以大大改善加密 dapps 的用户体验，并创建以前不可能的新设计，利用创建和处理多个账户、预签名消息并在以后广播它们的能力。 这些功能与我们为主账户要求的安全级别不兼容，主账户持有用户的大部分资金。

规范

应用程序

应用程序是一个网站（或其他），它希望从钱包请求访问专门为此使用派生的加密密钥。 它可以是任何形式的加密/身份验证应用程序，基于以太坊但不限于此。

连接到钱包后，应用程序可以使用以下算法请求访问专门为该应用程序派生的账户。

私有应用密钥生成算法

我们现在提出一种生成应用程序密钥的算法，该算法：

  • 相对于用户选择生成这些密钥的账户而言，是唯一确定的，
  • 因此可以在更改用户帐户时隔离，从而允许角色管理（请参见下一部分），
  • 特定于每个应用程序，
  • 可以从用户主种子助记词和应用程序名称中完全恢复。

将不同的账户用作角色

我们允许用户通过更改选择用于生成每个密钥的账户来展开一组不同的应用程序密钥。 因此，从相同的主种子助记词中，用户可以使用其每个账户索引来生成一组替代应用程序密钥。 可以将此描述为使用不同的角色。 这可能允许用户完全隔离她与给定应用程序跨角色的交互。 例如，可以使用它来为给定的域名创建个人和商业资料，这两者都从同一个助记词备份，使用 2 个不同的账户来生成这些资料。 应用程序或域将不知道背后是同一个人和助记词。 如果应用程序与用户的多个主账户交互，则其中一个账户（主账户）可以用作角色，而其他账户可以用作辅助账户。

本 EIP 与生成用于扩展不同应用密钥空间的私钥的方式无关。 但是，为了兼容性以及人员角色和加密货币账户之间的清晰区分，即将提出一个新的 EIP，该 EIP 不同于本 EIP，但将与本 EIP 一起使用，引入清晰的人员角色生成和管理。

应用程序的唯一标识符

每个应用程序都由其来源（域名字符串）唯一确定和验证。 它可以是域名服务 (DNS) 名称，也可以是未来的以太坊域名服务 (ENS) 名称或 IPFS 哈希。

对于 Ipfs 或 swam 来源，但我们可能可以使用 ipfs 或 swarm 地址作为来源，或者我们可以要求通过 ENS 条目指向这些地址，并使用 ENS 地址作为来源，尽管这意味着它引用的内容可能会更改。 因此，它将允许不同的安全和可更新性模型。

当使用 ENS 域指向 IPFS 地址时，我们可能需要协议前缀： ens://ipfs.snap.eth

私有应用密钥生成算法

使用应用程序的域名，我们为每个应用程序（以及每个主账户）生成一个私钥：

const appKeyPrivKey = keccak256(privKey + originString)

其中 + 是串联，privKey 是用户选择扩展应用程序密钥的账户的私钥，originString 表示从中发起访问应用程序密钥的权限调用的源 url。

这公开为一个 RPC 方法，允许任何域请求其自己的与当前请求的账户关联的应用密钥（如果可用）：

const appKey = await provider.send({
  method: 'wallet_getAppKeyForAccount',
  params: [address1]
});

有关实现，请参见此处： https://github.com/MetaMask/eth-simple-keyring/blob/master/index.js#L169

应用密钥和分层确定性密钥

使用上一节中描述的算法生成的应用密钥将不符合 BIP32 标准。 因此，应用程序将无法创建多个应用密钥或直接使用非硬化和扩展的公钥技术。 它们获得一个私钥（每个来源，每个人员角色）。 但是，它们可以使用它作为初始熵来扩展新的 HD 树并生成可以硬化或不硬化的地址。 因此，我们不应丢失用例。

理由

跨域共享应用程序密钥：

虽然这没有明确涵盖在页面之间共享这些应用程序密钥的情况，但是这种需求可以通过组合来满足：

由于域将获得每个人员角色的唯一密钥，并且由于域可以相互通信，因此一个域（应用程序）可以请求另一个域（签名者）对其某些数据执行加密操作，并将其 appKey 作为种子，从而可能允许像添加新网站一样轻松地添加新的签名策略。

这也可以将其传递给加载特定签名策略的域。 这乍一听可能很危险，但是如果域表示受信任的加密函数实现的静态哈希，则它可能与调用任何经过审核的内部依赖项一样安全。

隐私和资金追踪

如果应用程序对其密钥所需要做的只是对消息进行签名，并且不需要资金，那么本 EIP 允许通过对每个应用程序使用不同的密钥，并使用跨钱包兼容的简单确定性标准来保护隐私。

但是，如果这些应用程序密钥需要资金，则可能会有追踪，并且使用应用程序密钥无法完全解决隐私问题。

混合器或为以太坊地址提供资金的匿名方式（环签名）以及本提案将保证隐私。

即使没有这种匿名资金方法，隐私也无法完全解决，我们仍然需要一种为每个应用程序轻松创建和恢复不同账户/地址的方法

向后兼容性

从钱包的角度来看，似乎没有兼容性问题，因为这些账户与钱包以前使用的账户是分开的，并且它们应该协同使用。

但是，对于以某种方式将其用户与其主要账户关联的应用程序，可能需要考虑是否以及如何利用 app keys 提供的功能来迁移到它们并利用它们允许的新应用程序设计。

实现

这是用于标准（非 HW）MetaMask 帐户的应用程序密钥的早期实现。 https://github.com/MetaMask/eth-simple-keyring/blob/6d12bd9d73adcccbe0b0c7e32a99d279085e2934/index.js#L139-L152

请参见此处，了解实现应用密钥以及插件的 MetaMask 分支： https://github.com/MetaMask/metamask-snaps-beta https://github.com/MetaMask/metamask-snaps-beta/wiki/Plugin-API

用例示例

  • 签署交易而不广播它们 https://github.com/MetaMask/metamask-extension/issues/3475

  • token 合约 https://github.com/ethereum/EIPs/issues/85

  • dapps 的默认账户 https://ethereum-magicians.org/t/default-accounts-for-dapps/904

  • 非钱包/加密货币账户 EIP1581：从 BIP32 树派生的密钥的非钱包使用

  • 状态通道应用程序

  • 隐私解决方案

  • 非托管跨加密货币交易所…

致谢

MetaMask 团队、Christian Lundkvist、Counterfactual 团队、Liam Horne、Erik Bryn、Richard Moore、Jeff Coleman。

参考文献

HD 和助记词

BIPs

eth 的推导路径

与应用密钥相关的先前提案和讨论

版权

在 CC0 下放弃版权及相关权利。

Citation

Please cite this document as:

Vincent Eli (@Bunjin), Dan Finlay (@DanFinlay), "ERC-1775: 应用密钥，特定于应用程序的钱包账户 [DRAFT]," Ethereum Improvement Proposals, no. 1775, February 2019. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-1775.