eth_call #35

alita-moore · 2021-04-26T05:11:24Z

No description provided.

…into eth_call

MariusVanDerWijden

Mostly nitpicks,
Some thing that's missing from the spec is overrides I think

MariusVanDerWijden · 2021-04-26T05:47:22Z

json-rpc/eth_call.md

+4.1.2.1   | `eth_call` MUST only accept requests with the `from` parameter defined as a hex string with length 40
+4.1.2.1.1 | `eth_call` SHOULD throw error `-32602` [!] on improper length with message as `invalid argument 0: hex string has length {length}, want 40 for common.Address`
+4.1.2.2   | `eth_call` MUST NOT accept `from` hex strings with invalid characters
+4.1.2.2.1 | `eth_call` SHOULD throw error `-32602` [!] on improper hex string and return message `invalid argument 0: json: cannot unmarshal invalid hex string into Go struct field CallArgs.from of type common.Address`


That's pretty golang specific

I don't think the message itself should be explicitly specified at all. The message is for humans, and implementors may want to augment it with additional metadata (which is especially useful in Ganache and other blockchain simulators).

MariusVanDerWijden · 2021-04-26T05:53:02Z

json-rpc/eth_call.md

+4         | `eth_call` MUST accept a `params` parameter [JSON Array](https://tools.ietf.org/html/rfc7159#section-5) of length 2, and its first item containing a [JSON Object](https://tools.ietf.org/html/rfc7159#section-4) with keys known here as the `input parameters`
+4.1       | `eth_call` MUST accept an input parameter `from` of type `DATA` [!]
+4.1.1     | `eth_call` MUST accept requests with the from input parameter undefined
+4.1.1.1   | `eth_call` MUST consider CALLER account to be `0x0000000000000000000000000000000000000000000000000000000000000000` if `from` is not defined


Suggested change

4.1.1.1 | `eth_call` MUST consider CALLER account to be `0x0000000000000000000000000000000000000000000000000000000000000000` if `from` is not defined

4.1.1.1 | `eth_call` MUST consider CALLER account to be `0x000000000000000000000000000000000000000` if `from` is not defined

Adresses are 20 bytes in Ethereum

There are 39 zeros here 😇

MariusVanDerWijden · 2021-04-26T05:53:36Z

json-rpc/eth_call.md

+4.1.2.1.1 | `eth_call` SHOULD throw error `-32602` [!] on improper length with message as `invalid argument 0: hex string has length {length}, want 40 for common.Address`
+4.1.2.2   | `eth_call` MUST NOT accept `from` hex strings with invalid characters
+4.1.2.2.1 | `eth_call` SHOULD throw error `-32602` [!] on improper hex string and return message `invalid argument 0: json: cannot unmarshal invalid hex string into Go struct field CallArgs.from of type common.Address`
+4.1.2.3   | `eth_call` MUST consider CALLER account to equal a 32 byte hex string [!] of the `from` parameter


Suggested change

4.1.2.3 | `eth_call` MUST consider CALLER account to equal a 32 byte hex string [!] of the `from` parameter

4.1.2.3 | `eth_call` MUST consider CALLER account to equal a 20 byte hex string [!] of the `from` parameter

MariusVanDerWijden · 2021-04-26T05:54:16Z

json-rpc/eth_call.md

+4.1.2.2.1 | `eth_call` SHOULD throw error `-32602` [!] on improper hex string and return message `invalid argument 0: json: cannot unmarshal invalid hex string into Go struct field CallArgs.from of type common.Address`
+4.1.2.3   | `eth_call` MUST consider CALLER account to equal a 32 byte hex string [!] of the `from` parameter
+4.1.2.3.1 | `eth_call` MUST accept a `from` account that does not exist on-chain
+4.1.2.3.2 | `eth_call` MUST consider CALLER account to equal the `from` parameter if the account does not exist on-chain 


Isn't that the same as 4.1.2.3.?

MariusVanDerWijden · 2021-04-26T05:56:09Z

json-rpc/eth_call.md

+4.2       | `eth_call` MUST accept an input parameter `to` of type `DATA` [!]
+4.2.1     | `eth_call` MUST accept requests with `to` equal to null
+4.2.1.1   | `eth_call` MUST return empty hex string [!] if `to` input parameter is equal to null
+4.2.2     | `eth_call` MUST only accept hex encoded address strings as specified by [!] 


As specified by?

MariusVanDerWijden · 2021-04-26T05:59:52Z

json-rpc/eth_call.md

+4.3.4.1   | `eth_call` SHOULD throw exception `-32000` with message `err: intrinsic gas too low: have 13107, want 21000 (supplied gas 13107)`[!] if the `gas` input parameter is less than `implicit gas`[!]
+4.3.4.2   | `eth_call` SHOULD throw exception `-32000` with message `out of gas`
+4.3.5     | `eth_call` MUST NOT accept requests if the `gas` input parameter is not properly formatted
+4.3.5.1   | `eth_call` SHOULD throw exception `-32602` with message `invalid argument 0: json: cannot unmarshal hex number with leading zero digits into Go struct field CallArgs.gas of type hexutil.Uint64`[!] if the `gas` input parameter does not meet `hex encoded`[!] specifications


Again, error message go-specific

MariusVanDerWijden · 2021-04-26T06:00:12Z

json-rpc/eth_call.md

+4.3.5     | `eth_call` MUST NOT accept requests if the `gas` input parameter is not properly formatted
+4.3.5.1   | `eth_call` SHOULD throw exception `-32602` with message `invalid argument 0: json: cannot unmarshal hex number with leading zero digits into Go struct field CallArgs.gas of type hexutil.Uint64`[!] if the `gas` input parameter does not meet `hex encoded`[!] specifications
+4.3.6     | `eth_call` MUST NOT accept requests if the `gas` input parameter is greater than `2^64 - 1` or `0xffffffffffffffff`
+4.3.6.1   | `eth_call` SHOULD throw exception `-32602` with message `invalid argument 0: json: cannot unmarshal hex number > 64 bits into Go struct field CallArgs.gas of type hexutil.Uint64` if the `gas` input parameter is greater than the hex string encoded decimal `2^64 - 1`


go specific

MariusVanDerWijden · 2021-04-26T06:01:09Z

json-rpc/eth_call.md

+4.4.1.1   | `eth_call` MUST consider `GASPRICE`[!] as equal to 0 if `gasPrice` input parameter is equal to `null`[!]
+4.4.2     | `eth_call` MUST consider `GASPRICE`[!] as equal to `gasPrice` input parameter if `gasPrice` input parameter is not equal to null and meets `Quantity` requirements
+4.4.2.1   | `eth_call` SHOULD throw exception `-32000` with message `err: insufficient funds for gas * price + value: address {from} have {from account balance} want {gas * gasPrice + value} (supplied gas {gas})` if the `gasPrice` input parameter multiplied by `gas` input parameter added to `value` input paremeter are greater than the balance of the account associated with the `from` input parameter
+4.4.2.2   | `eth_call` SHOULD throw exception `-32000` with message `err: insufficient funds for gas * price + value: address 0x0000000000000000000000000000000000000000 have 0 want {gas * gasPrice + value} (supplied gas {gas})` if the `gasPrice` input parameter multiplied by `gas` input parameter added to `value` input paremeter are greater than 0 and the `from` input parameter is equal to null


Suggested change

4.4.2.2 | `eth_call` SHOULD throw exception `-32000` with message `err: insufficient funds for gas * price + value: address 0x0000000000000000000000000000000000000000 have 0 want {gas * gasPrice + value} (supplied gas {gas})` if the `gasPrice` input parameter multiplied by `gas` input parameter added to `value` input paremeter are greater than 0 and the `from` input parameter is equal to null

4.4.2.2 | `eth_call` SHOULD throw exception `-32000` with message `err: insufficient funds for gas * price + value: address {from} have 0 want {gas * gasPrice + value} (supplied gas {gas})` if the `gasPrice` input parameter multiplied by `gas` input parameter added to `value` input paremeter are greater than 0 and the `from` input parameter is equal to null

MariusVanDerWijden · 2021-04-26T06:03:44Z

json-rpc/eth_call.md

+4.5.1.2.1 | `eth_call` SHOULD throw exception `-32000` with message `err: insufficient funds for transfer: address {from} (supplied gas {gas || 25000000[!]})` if the value of `BALANCE`[!] of `CALLER`[!] on-chain is less than the `value` input parameter AND `to` input parameter is equal to `null`[!]
+4.5.1.2.2 | `eth_call` SHOULD throw exception `-32000` with message `err: insufficient funds for transfer: address {from} (supplied gas {gas || 25000000[!]})` if the `value` input parameter is greater than 0 AND the `from` input parameter is equal to `null`[!]
+5         | `eth_call` MUST accept a `params` parameter [JSON Array](https://tools.ietf.org/html/rfc7159#section-5) of length 2, and its second item (index = 1) containing a `Block Identifier`[!] parameter that specifies the block height of the best block ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) to assume the state of
+5.1       | `eth_call` MUST assume the on-chain state of the latest best block ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) if the `Block Identifier` parameter is equal to the [JSON String](https://tools.ietf.org/html/rfc7159#section-7) of "latest"; the latest best block height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) is equal to the current best block height minus one.


Suggested change

5.1 | `eth_call` MUST assume the on-chain state of the latest best block ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) if the `Block Identifier` parameter is equal to the [JSON String](https://tools.ietf.org/html/rfc7159#section-7) of "latest"; the latest best block height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) is equal to the current best block height minus one.

5.1 | `eth_call` MUST assume the on-chain state of the latest best block ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) if the `Block Identifier` parameter is equal to the [JSON String](https://tools.ietf.org/html/rfc7159#section-7) of "latest"; the latest best block height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) is equal to the current best block height.

MariusVanDerWijden · 2021-04-26T06:04:17Z

json-rpc/eth_call.md

+4.5.1.2.2 | `eth_call` SHOULD throw exception `-32000` with message `err: insufficient funds for transfer: address {from} (supplied gas {gas || 25000000[!]})` if the `value` input parameter is greater than 0 AND the `from` input parameter is equal to `null`[!]
+5         | `eth_call` MUST accept a `params` parameter [JSON Array](https://tools.ietf.org/html/rfc7159#section-5) of length 2, and its second item (index = 1) containing a `Block Identifier`[!] parameter that specifies the block height of the best block ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) to assume the state of
+5.1       | `eth_call` MUST assume the on-chain state of the latest best block ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) if the `Block Identifier` parameter is equal to the [JSON String](https://tools.ietf.org/html/rfc7159#section-7) of "latest"; the latest best block height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) is equal to the current best block height minus one.
+5.2       | `eth_call` MUST assume the on-chain state of the current best block with the greatest height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf))  if the `Block Identifier` parameter is equal to the [JSON String](https://tools.ietf.org/html/rfc7159#section-7) of "pending"; the pending best block height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) is equal to the current best block height.


Suggested change

5.2 | `eth_call` MUST assume the on-chain state of the current best block with the greatest height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) if the `Block Identifier` parameter is equal to the [JSON String](https://tools.ietf.org/html/rfc7159#section-7) of "pending"; the pending best block height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) is equal to the current best block height.

5.2 | `eth_call` MUST assume the on-chain state of the current best block with the greatest height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) if the `Block Identifier` parameter is equal to the [JSON String](https://tools.ietf.org/html/rfc7159#section-7) of "pending"; the pending best block height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) is equal to the current best block height plus a block with the best pending transactions.

MicahZoltu · 2021-04-26T06:10:12Z

json-rpc/eth_call.md

+Specification | Description 
+--|--
+1         | `eth_call` MUST NOT affect on-chain state|
+2         | `eth_call` MUST NOT accept requests that are not in valid JSON format


I think this is implicit, since the RPC is JSON-RPC so it is unnecessary to repeat it here. Similar to how we don't specify how TCP or HTTP works in this specification as it is handled at the transport layer.

MicahZoltu · 2021-04-26T06:10:40Z

json-rpc/eth_call.md

+--|--
+1         | `eth_call` MUST NOT affect on-chain state|
+2         | `eth_call` MUST NOT accept requests that are not in valid JSON format
+3         | `eth_call` MUST return a response in valid JSON format


Same as above, this is redundant with JSON-RPC specification.

MicahZoltu · 2021-04-26T06:16:58Z

json-rpc/eth_call.md

+2         | `eth_call` MUST NOT accept requests that are not in valid JSON format
+3         | `eth_call` MUST return a response in valid JSON format
+4         | `eth_call` MUST accept a `params` parameter [JSON Array](https://tools.ietf.org/html/rfc7159#section-5) of length 2, and its first item containing a [JSON Object](https://tools.ietf.org/html/rfc7159#section-4) with keys known here as the `input parameters`
+4.1       | `eth_call` MUST accept an input parameter `from` of type `DATA` [!]


It appears the specification is worded with a target audience of server developers in mind. This API is bi-directional and this document is likely to be read by both client developers and server developers. In this case, the from property is optional but this line makes it sound like it is required if you are reading from the point of view of a client. Consider trying to phrase things in this document in a way that is neutral to whether the reader is a server or client developer.

The from property is optional, but if present its type MUST be 20 byte DATA.

MicahZoltu · 2021-04-26T06:19:11Z

json-rpc/eth_call.md

+4.1.2.1.1 | `eth_call` SHOULD throw error `-32602` [!] on improper length with message as `invalid argument 0: hex string has length {length}, want 40 for common.Address`
+4.1.2.2   | `eth_call` MUST NOT accept `from` hex strings with invalid characters


As mentioned above, I think parsing errors like this should be generalized at a higher layer, otherwise we'll have to re-specify them over and over again. We should define an ADDRESS type for the JSON-RPC protocol and define how parsing errors should be handled in a top level spec, then in the individual specs like this one we can just say "from MUST be of type ADDRESS and not have to specify all of the details of what that means.

lightclient · 2021-04-26T21:08:25Z

This is just a general comment, but I think the way this spec is laid out is really verbose. I think it would be helpful to discuss things in terms of the inputs and outputs. The JSON-RPC spec sort of does this: https://www.jsonrpc.org/specification

alita-moore · 2021-04-29T07:09:04Z

@lightclient from the perspective of requirement definition, it's important to be very clear. While verbose, it also minimizes ambiguity. Which, is the goal of the specification. It's not necessarily meant to be readable by anyone other than someone implementing a JSON RPC. At least that's how I understand the task, but I'm happy to reconsider the approach of course.

ryanschneider · 2021-05-10T00:36:19Z

json-rpc/eth_call.md

+5.2       | `eth_call` MUST assume the on-chain state of the current best block with the greatest height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf))  if the `Block Identifier` parameter is equal to the [JSON String](https://tools.ietf.org/html/rfc7159#section-7) of "pending"; the pending best block height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) is equal to the current best block height.
+5.3       | `eth_call` MUST assume the on-chain state of the genesis best block ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) if the `Block Identifier` parameter is equal to the [JSON String](https://tools.ietf.org/html/rfc7159#section-7) of "earliest"; the earliest best block height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) is equal to 0.
+5.4       | `eth_call` MUST assume the on-chain state of the best blockchain block with height equal to the `Quantity`[!] value of the `Block Identifier` parameter if the `Block Identifier` parameter is equal to a hex encoded `Quantity`[!] value. Height is equal to the number of blocks after the genesis block on the best blockchain (block number).
+5.5       | `eth_call` SHOULD throw exception `-32602` [1] with message `invalid argument 1: hex string without 0x prefix` if the provided `Block Identifier` parameter is neither a [JSON String](https://tools.ietf.org/html/rfc7159#section-7) value equal to `earliest`, `latest`, `pending` nor a hex encoded `Quantity`[!] value.


EIP-1898 allows more block identifiers such as the block hash.

timbeiko · 2021-06-02T15:56:45Z

Is this PR still relevant, @alita-moore ?

SamWilsn · 2021-08-11T14:35:06Z

Should be migrated to https://github.com/ethereum/eth1.0-apis

alita-moore added 3 commits April 26, 2021 00:10

add sepcifications

aa646be

rfc-2119

b4e7116

Update eth_call.md

ffd3b4e

alita-moore mentioned this pull request Apr 26, 2021

eth_blockNumber #27

Closed

alita-moore added 5 commits April 26, 2021 00:39

reformat

6ac6270

Merge branch 'eth_call' of https://github.com/alita-moore/eth1.0-specs …

b2f8d15

…into eth_call

move rfc

998b5b7

fix headers

b24905c

capitalize column headers

e22a860

MariusVanDerWijden suggested changes Apr 26, 2021

View reviewed changes

MicahZoltu reviewed Apr 26, 2021

View reviewed changes

ryanschneider reviewed May 10, 2021

View reviewed changes

alita-moore mentioned this pull request May 19, 2021

eth_call #62

Closed

alcuadrado mentioned this pull request Jun 9, 2021

WTF NomicFoundation/hardhat-boilerplate#9

Closed

SamWilsn added the A-rpc Area: JSON RPC label Aug 5, 2021

SamWilsn closed this Aug 11, 2021

MansurovB-source mentioned this pull request Sep 3, 2021

Support various eth_call invocations post 1559 NethermindEth/nethermind#3317

Closed

12 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

eth_call #35

eth_call #35

alita-moore commented Apr 26, 2021

MariusVanDerWijden left a comment

MariusVanDerWijden Apr 26, 2021

davidmurdoch May 5, 2021

MariusVanDerWijden Apr 26, 2021

fvictorio Jun 1, 2021

MariusVanDerWijden Apr 26, 2021

MariusVanDerWijden Apr 26, 2021

MariusVanDerWijden Apr 26, 2021

MariusVanDerWijden Apr 26, 2021

MariusVanDerWijden Apr 26, 2021

MariusVanDerWijden Apr 26, 2021

MariusVanDerWijden Apr 26, 2021

MariusVanDerWijden Apr 26, 2021

MicahZoltu Apr 26, 2021

MicahZoltu Apr 26, 2021

MicahZoltu Apr 26, 2021

MicahZoltu Apr 26, 2021

lightclient commented Apr 26, 2021

alita-moore commented Apr 29, 2021

ryanschneider May 10, 2021

timbeiko commented Jun 2, 2021

SamWilsn commented Aug 11, 2021

	4.1.1.1 \| `eth_call` MUST consider CALLER account to be `0x0000000000000000000000000000000000000000000000000000000000000000` if `from` is not defined
	4.1.1.1 \| `eth_call` MUST consider CALLER account to be `0x000000000000000000000000000000000000000` if `from` is not defined

	4.1.2.3 \| `eth_call` MUST consider CALLER account to equal a 32 byte hex string [!] of the `from` parameter
	4.1.2.3 \| `eth_call` MUST consider CALLER account to equal a 20 byte hex string [!] of the `from` parameter

	4.4.2.2 \| `eth_call` SHOULD throw exception `-32000` with message `err: insufficient funds for gas * price + value: address 0x0000000000000000000000000000000000000000 have 0 want {gas * gasPrice + value} (supplied gas {gas})` if the `gasPrice` input parameter multiplied by `gas` input parameter added to `value` input paremeter are greater than 0 and the `from` input parameter is equal to null
	4.4.2.2 \| `eth_call` SHOULD throw exception `-32000` with message `err: insufficient funds for gas * price + value: address {from} have 0 want {gas * gasPrice + value} (supplied gas {gas})` if the `gasPrice` input parameter multiplied by `gas` input parameter added to `value` input paremeter are greater than 0 and the `from` input parameter is equal to null

		4.1.2.1.1 \| `eth_call` SHOULD throw error `-32602` [!] on improper length with message as `invalid argument 0: hex string has length {length}, want 40 for common.Address`
		4.1.2.2 \| `eth_call` MUST NOT accept `from` hex strings with invalid characters

eth_call #35

eth_call #35

Conversation

alita-moore commented Apr 26, 2021

MariusVanDerWijden left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lightclient commented Apr 26, 2021

alita-moore commented Apr 29, 2021

Choose a reason for hiding this comment

timbeiko commented Jun 2, 2021

SamWilsn commented Aug 11, 2021