This proposal defines a standard set of remote procedure call methods that an Ethereum node should implement.
Abstract
Nodes created by the current generation of Ethereum clients expose inconsistent and incompatible remote procedure call (RPC) methods because no formal Ethereum RPC specification exists. This proposal standardizes such a specification to provide developers with a predictable Ethereum RPC interface regardless of underlying node implementation.
Specification
Concepts
RFC-2119
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119.
If an Ethereum RPC method encounters an error, the error member included on the response object MUST be an object containing a code member and descriptive message member. The following list contains all possible error codes and associated messages:
Specific types of values passed to and returned from Ethereum RPC methods require special encoding:
Quantity
A Quantity value MUST be hex-encoded.
A Quantity value MUST be "0x"-prefixed.
A Quantity value MUST be expressed using the fewest possible hex digits per byte.
A Quantity value MUST express zero as "0x0".
Examples Quantity values:
Value
Valid
Reason
0x
invalid
empty not a valid quantity
0x0
valid
interpreted as a quantity of zero
0x00
invalid
leading zeroes not allowed
0x41
valid
interpreted as a quantity of 65
0x400
valid
interpreted as a quantity of 1024
0x0400
invalid
leading zeroes not allowed
ff
invalid
values must be prefixed
Block Identifier
The RPC methods below take a default block identifier as a parameter.
eth_getBalance
eth_getStorageAt
eth_getTransactionCount
eth_getCode
eth_call
eth_getProof
Since there is no way to clearly distinguish between a Data parameter and a Quantity parameter, EIP-1898 provides a format to specify a block either using the block hash or block number. The block identifier is a JSON object with the following fields:
The block uniquely identified by this hash. The blockNumber and blockHash properties are mutually exclusive; exactly one of them must be set.
requireCanonical
{boolean}
(optional) Whether or not to throw an error if the block is not in the canonical chain as described below. Only allowed in conjunction with the blockHash tag. Defaults to false.
If the block is not found, the callee SHOULD raise a JSON-RPC error (the recommended error code is -32001: Resource not found. If the tag is blockHash and requireCanonical is true, the callee SHOULD additionally raise a JSON-RPC error if the block is not in the canonical chain (the recommended error code is -32000: Invalid input and in any case should be different than the error code for the block not found case so that the caller can distinguish the cases). The block-not-found check SHOULD take precedence over the block-is-canonical check, so that if the block is not found the callee raises block-not-found rather than block-not-canonical.
Data
A Data value MUST be hex-encoded.
A Data value MUST be "0x"-prefixed.
A Data value MUST be expressed using two hex digits per byte.
Examples Data values:
Value
Valid
Reason
0x
valid
interpreted as empty data
0x0
invalid
each byte must be represented using two hex digits
0x00
valid
interpreted as a single zero byte
0x41
true
interpreted as a data value of 65
0x004200
true
interpreted as a data value of 16896
0xf0f0f
false
bytes require two hex digits
004200
false
values must be prefixed
Proposing changes
New Ethereum RPC methods and changes to existing methods MUST be proposed via the traditional EIP process. This allows for community consensus around new method implementations and proposed method modifications. RPC method proposals MUST reach "draft" status before being added to this proposal and the official Ethereum RPC specification defined herein.
Executes a new message call immediately without submitting a transaction to the network
Parameters
#
Type
Description
1
{object}
@property {Data} [from] - transaction sender @property {Data} to - transaction recipient or null if deploying a contract @property {Quantity} [gas] - gas provided for transaction execution @property {Quantity} [gasPrice] - price in wei of each gas used @property {Quantity} [value] - value in wei sent with this transaction @property {Data} [data] - contract code or a hashed method call with encoded args
Estimates the gas necessary to complete a transaction without submitting it to the network
Note: The resulting gas estimation may be significantly more than the amount of gas actually used by the transaction. This is due to a variety of reasons including EVM mechanics and node performance.
Parameters
#
Type
Description
1
{object}
@property {Data} [from] - transaction sender @property {Data} [to] - transaction recipient @property {Quantity} [gas] - gas provided for transaction execution @property {Quantity} [gasPrice] - price in wei of each gas used @property {Quantity} [value] - value in wei sent with this transaction @property {Data} [data] - contract code or a hashed method call with encoded args
{boolean} removed - true if this filter has been destroyed and is invalid
Note: The return value of eth_getFilterChanges when retrieving logs from eth_newBlockFilter and eth_newPendingTransactionFilter filters will be an array of hashes, not an array of Log objects.
{Array<Log>} - array of log objects with the following members:
{Data} address - address from which this log originated
{Data} blockHash - hash of block containing this log or null if pending
{Data} data - contains the non-indexed arguments of the log
{Data} transactionHash - hash of the transaction that created this log or null if pending
{Quantity} blockNumber - number of block containing this log or null if pending
{Quantity} logIndex - index of this log within its block or null if pending
{Quantity} transactionIndex - index of the transaction that created this log or null if pending
{Array<Data>} topics - list of order-dependent topics
{boolean} removed - true if this filter has been destroyed and is invalid
Note: The return value of eth_getFilterLogs when retrieving logs from eth_newBlockFilter and eth_newPendingTransactionFilter filters will be an array of hashes, not an array of Log objects.
Returns a list of all logs based on a filter object
Parameters
#
Type
Description
1
{object}
@property {Quantity|string} [fromBlock] - block number, or one of "latest", "earliest" or "pending" @property {Quantity|string} [toBlock] - block number, or one of "latest", "earliest" or "pending" @property {Data|Data[]} [address] - contract address or a list of addresses from which logs should originate @property {Data[]} [topics] - list of order-dependent topics @property {Data} [blockhash] - restrict logs to a block by hash
Note: If blockhash is passed, neither fromBlock nor toBlock are allowed or respected.
Returns
{Array<Log>} - array of log objects with the following members:
{Data} address - address from which this log originated
{Data} blockHash - hash of block containing this log or null if pending
{Data} data - contains the non-indexed arguments of the log
{Data} transactionHash - hash of the transaction that created this log or null if pending
{Quantity} blockNumber - number of block containing this log or null if pending
{Quantity} logIndex - index of this log within its block or null if pending
{Quantity} transactionIndex - index of the transaction that created this log or null if pending
Creates a filter to listen for specific state changes that can then be used with eth_getFilterChanges
Parameters
#
Type
Description
1
{object}
@property {Quantity|string} [fromBlock] - block number, or one of "latest", "earliest" or "pending" @property {Quantity|string} [toBlock] - block number, or one of "latest", "earliest" or "pending" @property {Data|Data[]} [address] - contract address or a list of addresses from which logs should originate @property {Data[]} [topics] - list of order-dependent topics
Note: Topics are order-dependent. A transaction with a log with topics [A, B] will be matched by the following topic filters:
[] - "anything"
[A] - "A in first position (and anything after)"
[null, B] - "anything in first position AND B in second position (and anything after)"
[A, B] - "A in first position AND B in second position (and anything after)"
[[A, B], [A, B]] - "(A OR B) in first position AND (A OR B) in second position (and anything after)"
Returns
{Quantity} - ID of the newly-created filter that can be used with eth_getFilterChanges
Creates, signs, and sends a new transaction to the network
Parameters
#
Type
Description
1
{object}
@property {Data} from - transaction sender @property {Data} [to] - transaction recipient @property {Quantity} [gas="0x15f90"] - gas provided for transaction execution @property {Quantity} [gasPrice] - price in wei of each gas used @property {Quantity} [value] - value in wei sent with this transaction @property {Data} [data] - contract code or a hashed method call with encoded args @property {Quantity} [nonce] - unique number identifying this transaction
Returns
{Data} - transaction hash, or the zero hash if the transaction is not yet available
Signs a transaction that can be submitted to the network at a later time using with eth_sendRawTransaction
Parameters
#
Type
Description
1
{object}
@property {Data} from - transaction sender @property {Data} [to] - transaction recipient @property {Quantity} [gas="0x15f90"] - gas provided for transaction execution @property {Quantity} [gasPrice] - price in wei of each gas used @property {Quantity} [value] - value in wei sent with this transaction @property {Data} [data] - contract code or a hashed method call with encoded args @property {Quantity} [nonce] - unique number identifying this transaction
Note: This should only be called if a filter and its notifications are no longer needed. This will also be called automatically on a filter if its notifications are not retrieved using eth_getFilterChanges for a period of time.
Much of Ethereum's effectiveness as an enterprise-grade application platform depends on its ability to provide a reliable and predictable developer experience. Nodes created by the current generation of Ethereum clients expose RPC endpoints with differing method signatures; this forces applications to work around method inconsistencies to maintain compatibility with various Ethereum RPC implementations.
Both Ethereum client developers and downstream dapp developers lack a formal Ethereum RPC specification. This proposal standardizes such a specification in a way that's versionable and modifiable through the traditional EIP process.
Backwards compatibility
This proposal impacts Ethereum client developers by requiring that any exposed RPC interface adheres to this specification. This proposal impacts dapp developers by requiring that any RPC calls currently used in applications are made according to this specification.
Implementation
The current generation of Ethereum clients includes several implementations that attempt to expose this RPC specification: