status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-23 12:18:16 +00:00
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 1193 (#2694)

Browse Source 
Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
Erik Marks 2020-06-03 22:26:29 -07:00 committed by GitHub
parent c9d2ba10ee
commit 6e68ede11f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 53 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

65
EIPS/eip-1193.md
View File

@ -51,8 +51,8 @@ You can find a list of common methods [here](https://eips.ethereum.org/EIPS/eip-
Multiple RPC protocols may be available. For examples, see:
- [EIP 1474](https://eips.ethereum.org/EIPS/eip-1474), the Ethereum JSON-RPC API
- [EIP 1767](https://eips.ethereum.org/EIPS/eip-1767), the Ethereum GraphQL schema
- [EIP-1474](https://eips.ethereum.org/EIPS/eip-1474), the Ethereum JSON-RPC API
- [EIP-1767](https://eips.ethereum.org/EIPS/eip-1767), the Ethereum GraphQL schema
### sendAsync (DEPRECATED)
@ -125,7 +125,7 @@ The event emits a hexadecimal string `chainId` per the `eth_chainId` Ethereum RP
The event `networkChanged` is deprecated in favor of [`chainChanged`](#chainchanged).
For details, see [EIP 155: Simple replay attack protection](https://eips.ethereum.org/EIPS/eip-155) and [EIP 695: Create eth_chainId method for JSON-RPC](https://eips.ethereum.org/EIPS/eip-695).
For details, see [EIP-155: Simple replay attack protection](https://eips.ethereum.org/EIPS/eip-155) and [EIP-695: Create eth_chainId method for JSON-RPC](https://eips.ethereum.org/EIPS/eip-695).
#### accountsChanged
@ -279,9 +279,11 @@ _This section is non-normative._
- Provider
- A JavaScript object made available to a dapp, that provides access to Ethereum by means of a Client.
- Client
- An endpoint accessed by a Provider, that receives Remote Procedure Call (RPC) requests and returns their results.
- An endpoint that receives Remote Procedure Call (RPC) requests from the Provider, and returns their results.
- Wallet
- An end-user application that manages private keys, performs signing operations, and acts as a middleware between the Provider and the Client.
- Remote Procedure Call (RPC)
- A Remote Procedure Call (RPC), is any request submitted to a Provider for some procedure that is to be processed by a Provider or its Client.
- A Remote Procedure Call (RPC), is any request submitted to a Provider for some procedure that is to be processed by a Provider, its Wallet, or its Client.
### Availability
@ -341,8 +343,8 @@ If the returned Promise rejects, it **MUST** reject with a `ProviderRpcError` as
The returned Promise **MUST** reject if any of the following conditions are met:
- The client returns an error for the RPC request.
- If the error returned from the client is compatible with the `ProviderRpcError` interface, the Promise **MAY** reject with that error directly.
- The Client returns an error for the RPC request.
- If the error returned from the Client is compatible with the `ProviderRpcError` interface, the Promise **MAY** reject with that error directly.
- The Provider encounters an error or fails to process the request for any reason.
> If the Provider implements any kind of authorization logic, the authors recommend rejecting with a `4100` error in case of authorization failures.
@ -480,15 +482,54 @@ If the accounts available to the Provider change, the Provider **MUST** emit the
The "accounts available to the Provider" change when the return value of `eth_accounts` changes.
## Security Considerations
_This section and its sub-sections are non-normative._
The Provider is intended to pass messages between an Ethereum Client and an Ethereum application.
It is _not_ responsible for private key or account management; it merely processes RPC messages and emits events.
Consequently, account security and user privacy need to be implemented in middlewares between the Provider and its Ethereum Client.
In practice, we call these middleware applications "Wallets," and they usually manage the user's private keys and accounts.
The Provider can be thought of as an extension of the Wallet, exposed in an untrusted environment, under the control of some third party (e.g. a dapp).
### Handling Adversarial Behavior
Since it is a JavaScript object, consumers can generally perform arbitrary operations on the Provider, and all its properties can be read or overwritten.
Therefore, it is best to treat the Provider object as though it is controlled by an adversary.
It is paramount that the Provider implementer protects the user, Wallet, and Client by ensuring that:
- The Provider does not contain any private user data.
- The Provider and Wallet programs are isolated from each other.
- The Wallet and/or Client rate-limit requests from the Provider.
- The Wallet and/or Client validate all data sent from the Provider.
### Chain Changes
Since all Ethereum operations are directed at a particular chain, it's important that the Provider accurately reflects the Client's configured chain, per the `eth_chainId` Ethereum RPC method (see [EIP-695](https://eips.ethereum.org/EIPS/eip-155)).
This includes ensuring that `eth_chainId` has the correct return value, and that the `chainChanged` event is emitted whenever that value changes.
### User Account Exposure and Account Changes
Many Ethereum write operations (e.g. `eth_sendTransaction`) require a user account to be specified.
Provider consumers access these accounts via the `eth_accounts` RPC method, and by listening for the `accountsChanged` event.
As with `eth_chainId`, it is critical that `eth_accounts` has the correct return value, and that the `accountsChanged` event is emitted whenever that value changes.
The return value of `eth_accounts` is ultimately controlled by the Wallet or Client.
In order to protect user privacy, the authors recommend not exposing any accounts by default.
Instead, Providers should support RPC methods for explicitly requesting account access, such as `eth_requestAccounts` (see [EIP-1102](https://eips.ethereum.org/EIPS/eip-1102)) or `wallet_requestPermissions` (see [EIP-2255](https://eips.ethereum.org/EIPS/eip-2255).
## References
- [Initial discussion in `ethereum/interfaces`](https://github.com/ethereum/interfaces/issues/16)
- [Ethereum Magicians thread](https://ethereum-magicians.org/t/eip-1193-ethereum-provider-javascript-api/640)
- [Continuing EIP-1193 discussion](https://github.com/ethereum/EIPs/issues/2319)
- [Deprecated Ethereum Magicians thread](https://ethereum-magicians.org/t/eip-1193-ethereum-provider-javascript-api/640)
- [Continuing discussion](https://github.com/ethereum/EIPs/issues/2319)
- Related EIPs
- [EIP 1102](https://eips.ethereum.org/EIPS/eip-1102)
- [EIP 1474](https://eips.ethereum.org/EIPS/eip-1474)
- [EIP 1767](https://eips.ethereum.org/EIPS/eip-1767)
- [EIP-1102 (`eth_requestAccounts`)](https://eips.ethereum.org/EIPS/eip-1102)
- [EIP-1474 (JSON-RPC specification)](https://eips.ethereum.org/EIPS/eip-1474)
- [EIP-1767 (GraphQL RPC specification)](https://eips.ethereum.org/EIPS/eip-1767)
- [EIP-2255 (wallet permissions)](https://eips.ethereum.org/EIPS/eip-2255)
## Copyright