Alert Source Discuss
🚧 Stagnant Standards Track: Interface

EIP-1102: 选择加入的账户暴露

Authors Paul Bouchon <mail@bitpshr.net>, Erik Marks (@rekmarks)
Created 2018-05-04
Discussion Link https://ethereum-magicians.org/t/eip-1102-opt-in-provider-access/414
Requires EIP-1474

简述

此提案描述了DApp和启用以太坊的DOM环境之间的通信协议,该协议允许启用以太坊的DOM环境选择向DApp提供哪些信息以及何时提供。

摘要

上一代的启用以太坊的DOM环境遵循一种模式,即在未经用户同意的情况下注入一个填充了账户的provider。这会使此类环境的用户面临风险,因为恶意网站可以使用这些帐户来查看详细的帐户信息,并且任意地代表用户发起不需要的交易。

此提案概述了一种协议,其中启用以太坊的DOM环境可以选择不暴露任何帐户,直到用户批准帐户访问为止。

规范

概念

RFC-2119

本文档中的关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY”和“OPTIONAL”应按照RFC-2119中的描述进行解释。

eth_requestAccounts

由启用以太坊的DOM环境暴露的Provider定义了一个新的RPC方法:eth_requestAccounts。调用此方法可能会触发一个用户界面,允许用户批准或拒绝给定DApp的帐户访问。此方法返回一个Promise,该Promise解析为一个账户Array,如果账户不可用,则会使用一个Error拒绝。

ethereum.send('eth_requestAccounts'): Promise<Array<string>>

Provider#enable (已弃用)

注意:此方法已被弃用,推荐使用 RPC 方法 eth_requestAccounts

由启用以太坊的DOM环境暴露的Provider定义了一个新的RPC方法:ethereum.enable()。调用此方法会触发一个用户界面,允许用户批准或拒绝给定DApp的帐户访问。如果用户批准访问,此方法将返回一个解析为账户ArrayPromise;如果用户拒绝访问,则会使用Error拒绝。

ethereum.enable(): Promise<any>

协议

传统 DApp 初始化

START dapp
IF web3 is defined
    CONTINUE dapp
IF web3 is undefined
    STOP dapp

提出的 DApp 初始化

START dapp
IF provider is defined
    REQUEST[1] account access
    IF user approves
        RESOLVE[2] account access
        CONTINUE dapp
    IF user rejects
        REJECT[3] account access
        STOP dapp
IF provider is undefined
    STOP dapp
[1] REQUEST

DApp 必须 通过在 window.ethereum 暴露的Provider上调用 eth_requestAccounts RPC方法来请求账户。调用此方法 可以 触发一个用户界面,允许用户批准或拒绝给定DApp的账户访问。此方法 必须 返回一个 Promise,如果有一个或多个用户账户可用,则使用一个或多个用户账户的数组来解析,如果账户不可用(例如,用户拒绝账户访问),则拒绝该 Promise

[2] RESOLVE

当调用 eth_requestAccounts RPC方法时返回的 Promise 必须 使用用户账户的 Array 来解析。

[3] REJECT

如果由于任何原因没有可用的账户,则当调用 eth_requestAccounts RPC方法时返回的 Promise 必须 使用一个包含信息的 Error 来拒绝。

初始化示例

try {
    // Request account access if needed
    // 如果需要,请求账户访问权限
    const accounts = await ethereum.send('eth_requestAccounts');
    // Accounts now exposed, use them
    // 账户现在已暴露,使用它们
    ethereum.send('eth_sendTransaction', { from: accounts[0], /* ... */ })
} catch (error) {
    // User denied account access
    // 用户拒绝了账户访问权限
}

约束

  • 浏览器 必须window.ethereum 暴露一个provider。
  • 浏览器 必须 定义一个 eth_requestAccounts RPC方法。
  • 浏览器 可以 在解析/拒绝 eth_requestAccounts promise之前等待用户交互。
  • 如果 eth_requestAccounts promise被解析,浏览器 必须 至少包含一个账户。
  • 如果没有可用的账户,浏览器 必须 使用一个包含信息的错误来拒绝promise。

理由

上一代启用以太坊的DOM环境所遵循的自动账户暴露模式未能保护用户隐私,也未能维持安全的用户体验:不受信任的网站既可以查看详细的账户信息,也可以任意地代表用户发起交易。即使大多数用户可能会拒绝不受信任网站上的未经请求的交易,但账户访问协议应使此类未经请求的请求成为不可能。

此提案建立了一种新的模式,其中DApp必须请求访问用户账户。该协议通过允许浏览器隐藏用户账户并防止不受信任站点上的未经请求的交易请求,从而直接加强了用户隐私。

立即增加的价值

  • 用户可以拒绝不受信任站点上的账户访问权限以隐藏账户。
  • 用户可以拒绝不受信任站点上的账户访问权限以防止未经请求的交易。

长期增加的价值

  • DApp可以根据用户同意请求特定的账户信息。
  • DApp可以根据用户同意请求特定的用户信息(uPort,DIDs)。
  • DApp可以根据用户同意请求特定的网络。
  • DApp可以根据用户同意请求上述多个实例。

向后兼容性

此提案会影响DApp开发者,并要求他们按照上述协议请求访问用户账户。同样,此提案会影响DApp浏览器开发者,并要求他们仅按照上述定义的协议暴露用户账户。

实现

MetaMask团队已经实现了上述策略。

版权

版权及相关权利已通过 CC0 放弃。

Citation

Please cite this document as:

Paul Bouchon <mail@bitpshr.net>, Erik Marks (@rekmarks), "EIP-1102: 选择加入的账户暴露 [DRAFT]," Ethereum Improvement Proposals, no. 1102, May 2018. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-1102.