Alert Source Discuss
🚧 Stagnant Standards Track: ERC

ERC-2525: ENSLogin

Authors Hadrien Croubois (@amxx)
Created 2020-02-19
Discussion Link https://ethereum-magicians.org/t/discussion-ens-login/3569
Requires EIP-137, EIP-634, EIP-1193, EIP-2304

1. 摘要

本文提出了一种改进的以太坊区块链通用登录方法,利用了 ENS 提供的元数据存储。当拥有一个可以代表用户签署交易和消息的 EIP-1193 provider 时,我们认为用户已登录。此方法受到 Alex Van de Sande 的工作Web3Connect 的启发。将来,此处描述的方法应扩展到适用于任何区块链。

2. 动机

可以使用多种钱包解决方案与以太坊区块链进行交互。有些(metamask, gnosis, …)是兼容的,因为它们在浏览器中注入了一个标准化的钱包对象,而无需 Dapp 开发人员进行任何努力,但它们需要用户方面的努力(用户必须安装插件)。其他解决方案(Portis, Authereum, Torus, Universal Login, …)为非加密货币用户提出了更无缝的流程,但需要 Dapp 开发人员进行集成工作。硬件钱包(ledger, trezor, keepkey, …)也需要 Dapp 开发人员进行集成工作。

当 Dapp 集成多种解决方案的登录时,它们依赖于用户选择正确的钱包 provider。随着钱包 provider 数量的增加,这可能会变得越来越困难,尤其是对于新手用户。此外,如果去中心化应用程序仅挑选并选择少量钱包来支持,则当前的现有钱包将具有明显的优势,并且新钱包将难以获得采用。这将创建一个竞争力较弱的环境并扼杀创新。 ENSLogin 建议使用用户拥有的 ENS 域名作为切入点,而不是像 Web3Connect 那样依赖用户选择要连接的钱包 provider。附加到这些 ENS 域的元数据用于检测相应帐户使用的钱包 provider。

这样,ENSLogin 将允许任何用户使用简单的域名作为登录名连接到任何具有任何钱包的 Dapp。

3. 描述

3.1. 概述

ENSLogin 的工作方式如下:

  • 从用户处请求一个 ENS 域名
  • 解析 ENS 域名以检索(参见 EIP-137
    • 一个地址(参见 EIP-137
    • 一个文本条目(参见 EIP-634
  • 解释文本条目并下载它指向的文件
  • 评估下载文件的内容
  • 将相应的对象返回给 Dapp

此时,应用程序应像使用任何 web3 provider 一样进行处理。 如果需要,调用 enable() 函数应要求用户提供钱包特定凭据。

此工作流程将由 Dapp 可以轻松导入的 SDK 来实现。 该 SDK 将包含解析机制,并支持集中式和去中心化存储解决方案。 钱包 provider 的特定代码不应属于 SDK 的一部分。 钱包 provider 的特定代码应仅存在用于生成 web3 provider 的外部文件中。

3.2. 详情

  • 文本条目解析: 使用 ENS 对文本条目的支持来记录实例化钱包 provider 所需的代码指针(参见 EIP-634)。 相应的键为 enslogin (可能会更改)。 如果在目标域的键 enslogin 处没有关联任何值,我们将回退到父节点的元数据存储,键为 enslogin-default (可能会更改)。 示例: 对于 ens 域名 username.domain.eth,解析将查找(按顺序):
    • resolver.at(ens.owner(nodehash("username.domain.eth"))).text(nodehash("username.domain.eth"), 'enslogin')
    • resolver.at(ens.owner(nodehash("domain.eth"))).text(nodehash("domain.eth"), 'enslogin-default')
  • Provider 链接: 必须以标准化方式指向用于实例化钱包 provider 的代码。 尚未指定。 当前方法使用人类可读的格式 scheme://path,例如:

    • ipfs://Qm12345678901234567890123456789012345678901234
    • https://server.com/enslogin-module-someprovider

    并根据目标区块链类型(参见 SLIP 44)和语言添加后缀。 规范案例是使用以太坊的 webapp,因此目标将是:

    • ipfs://Qm12345678901234567890123456789012345678901234/60/js
    • https://server.com/enslogin-module-someprovider/60/js

    请注意,此后缀机制与 http/https 以及 IPFS 兼容。 这是对存储层的约束,因为某些存储层可能无法执行此类解析。

  • Provider 实例化:
    • [JAVASCRIPT/ETHEREUM] 包含钱包 provider 代码的文件应注入一个函数 global.provider: (config) => Promise<web3provider>,该函数返回对标准化 provider 对象的承诺。 对于 EVM 区块链,该对象应遵循 EIP-1193
    • 其他区块链类型/语言应在将来详细说明。
  • 配置对象: 除了用户名(ENS 域名)之外,Dapp 还应能够传递一个配置对象,该对象可供实例化函数的钱包 provider 使用。 此配置应包括:
    • 一个正文(所有 provider 通用),用于指定有关目标链的详细信息(网络名称/节点,ens 入口点的地址…)。 如果缺少其中任何一个,则可以使用回退(主网作为默认网络,引导浏览器内 IPFS 节点…)。
    • 可以添加钱包 provider 特定的字段(可选,以下划线开头 _)以传递其他钱包 provider 特定的参数/调试标志。
    • SDK 特定的字段(可选,以双下划线开头 __)可用于传递其他参数。

    最小配置:

      {
          provider: {
              network: 'goerli'
          }
      }
    

    高级配置对象示例:

      {
          provider: {
              network: 'goerli',
              ens:     '0x112234455c3a32fd11230c42e7bccd4a84e02010'
          },
          ipfs: {
              host: 'ipfs.infura.io',
              port: 5001,
              protocol: 'https'
          },
          _authereum: {...},
          _portis: {...},
          _unilogin: {...},
          _torus: {...},
          __callbacks: {
              resolved: (username, addr, descr) => {
                  console.log(`[CALLBACKS] resolved: ${username} ${addr} ${descr}`);
              },
              loading: (protocol, path) => {
                  console.log(`[CALLBACKS] loading: ${protocol} ${path}`);
              },
              loaded: (protocol, path) => {
                  console.log(`[CALLBACKS] loaded: ${protocol} ${path}`);
              }
          }
      }
    

TODO (也许可以将这部分移到 6.1 节): 将 SLIP 44 兼容的区块链描述添加到配置中,以获得更好的多链支持。 这将需要一个附加字段“ENS network”,以了解在目标区块链/网络不是以太坊时使用哪个以太坊网络进行解析(也可以用于以太坊上的跨链解析,例如使用存储在主网上的元数据登录 xDAI)

3.3. 去中心化

与 Web3Connect 之类的解决方案不同,ENSLogin 提出了一种本质上是去中心化的模块化方法。 Dapp 使用 ENSLogin 所需的代码(以下称为 SDK)仅包含以太坊区块链和数据存储解决方案的查找机制。 该解决方案受到 SDK 可以与之交互的协议(https / ipfs / …)的限制。 除此之外,任何遵循预期结构并通过受支持协议之一提供的钱包 provider 都会自动与所有提供 ENSLogin 支持的 Dapp 兼容。 无需经过集中式审批流程。 此外,无需升级已部署的 SDK 即可从最新的钱包更新中受益。 协议中唯一需要许可的部分是用户对描述其钱包 provider 实现的元数据的 ENS 控制。 用户还可以依靠回退机制来让钱包 provider 为其更新它。

3.4. 激励

我们认为 ENSLogin 最大的优势在于它使 Dapp 开发人员和钱包 provider 遵循此标准的激励措施保持一致。

  • 实施所需文件并使其可用的钱包 provider 将确保其钱包与使用 ENSLogin 的所有 Dapp 兼容。 这将消除要求所有 Dapp 集成其解决方案的负担,除非钱包拥有强大的用户群,否则 Dapp 不太可能这样做。 因此,ENSLogin 将改善钱包 provider 之间的竞争,并鼓励该领域的创新
  • 通过包含 ENSLogin 的 SDK 或通过实施兼容行为来使用 ENSLogin 协议的 Dapp 将使其自身可供所有兼容钱包的所有用户使用。 在某种程度上,与 ENSLogin 兼容将是最容易接触到庞大用户群的方式。
  • ENSLogin 对于用户而言应该是透明的。 大多数钱包 provider 将设置必要的条目,而无需用户进行任何努力。 高级用户可以控制钱包解析过程,一旦合适的工具可用,这将很简单。

3.5. 缺点

虽然 ENSLogin 允许 dapps 支持任何钱包登录,但 dapps 仍然必须选择他们建议用户注册哪些钱包。 这可以通过像 Web3Connect 或 BlockNative 这样的组件来完成

4. 原型

TODO

5. 社区支持

5.1. 采用

名字 线上 模块 分配 ENS 名称 默认支持
Argent
Authereum
Fortmatic
Gnosis Safe 是*
Ledger 测试版
KeepKey
Metamask
Opera 是*
Portis
SquareLink
Shipl
Torus
Trezor
UniLogin 测试版 测试版

*使用 metamask 模块

6. 可能的演变

6.1. 多链支持

TODO

7. 常见问题解答

7.1. 任何人都可以使用我的登录名连接吗? 我的私钥存储在哪里?

ENSLogin 只能访问 ENS 上记录的内容,即您的地址和您使用的 provider。 私钥管理由 provider 处理,并且超出 ENSLogin 的范围。 有些人可能会将密钥存储在磁盘上。 其他人可能依赖于存储在远程(希望是安全的)服务器上的托管密钥。 其他人可能使用专用的硬件组件来处理签名,并且永远无法直接访问私钥。

7.2. 如何获得 ENS 登录名?

TODO (这可能需要一个单独的 ERC)

Citation

Please cite this document as:

Hadrien Croubois (@amxx), "ERC-2525: ENSLogin [DRAFT]," Ethereum Improvement Proposals, no. 2525, February 2020. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2525.