eth_call does not accept EIP-1898 'blockHash' param

[dankostiuk]

eth_call does not accept EIP-1898 'blockHash' param

Description

We noticed some RPC errors come up while making calls to eth_call using the EIP-1898 blockHash param (see https://eips.ethereum.org/EIPS/eip-1898).

It looks like the current unmarshaling logic fails on trying to validate the params arary as a result of this new field.

Note that Geth 1.9.6 implements this proposal in ethereum/go-ethereum#19491.

Your environment

• OS and version Ubuntu 20
• version of the Polygon SDK 0a30e47
• branch that causes this issue develop

Steps to reproduce

1. Make eth_call request containing blockHash param:

{"jsonrpc":"2.0","method":"eth_call","params":[{"data":"0x313ce567","gas":"0x2faf080","to":"0xfb70fca25af612114672118941fe7ec0b0734658"},{"blockHash":"0xeb3f1429c8868cf7d4d3db207fd9466fa31072928c59ac00f7079343fb085e07"}],"id":277408}`

2. Observe that the dispatcher cannot properly unmarshal the req.Params, responding with a -32602 Invalid Params error.
3. Calls to eth_call without this new param object still work:

{"method":"eth_call","params":[{"to":"0xbec64eaab6fa7ca0184b9f264c7f80318cc04f34","data":"0x70a082310000000000000000000000002079a994e9bbc88496df03a59a0cfa2c9e2af473"},"latest"],"id":122723,"jsonrpc":"2.0"}

Expected behaviour

JSON-RPC methods should support this and all variations of request bodies. This would allow for more flexible integrations with the SDK and therefore better user adoption.

Actual behaviour

eth_call as well as the following methods return an error response when including the blockHash param as a second object within the params array:

• eth_getBalance
• eth_getStorageAt
• eth_getTransactionCount
• eth_getCode
• eth_getProof

[mrwillis]

Just to comment on this. blockHash is used extensively in indexing protocols such as https://thegraph.com/en/ and related services which power a lot of dapps. Would be really helpful to improve compatibility across the EVM ecosystem.

[zivkovicmilos]

Hey @mrwillis and @dankostiuk,

Thank you for bringing this feature up, it seems like a logical addition to the SDK.

We'll definitely be adding it in the current (or next) sprint, as it's not a huge refactor. I'll ping you guys here once the PR is up and ready 👍

[dankostiuk]

Thanks @zivkovicmilos ,

Related to this issue it seems like the second value of req.Params is always assumed to be the blockNumber param. So even so a request like this unmarshals successfully:

{
	"id": 0,
	"jsonrpc": "2.0",
	"method": "eth_call",
	"params": [{
		"data": "0x70a082310000000000000000000000000cd01b344f086d814c72a8d8195b3349f186eabf",
		"from": null,
		"to": "0xeafbbf62dffba085b717e215d82223fe2f212268"
	}, "0xF9309"]
}

This request fails:

{
	"id": 0,
	"jsonrpc": "2.0",
	"method": "eth_call",
	"params": ["0xF9309", {
		"data": "0x70a082310000000000000000000000000cd01b344f086d814c72a8d8195b3349f186eabf",
		"from": null,
		"to": "0xeafbbf62dffba085b717e215d82223fe2f212268"
	}]
}