ETH 1.x JSON RPC API Standards Meeting 4 Agenda

[tkstanczak]

ETH 1.x JSON RPC API Standard Meeting 4 Agenda

• Meeting Date/Time (please note there will be two separate meetings held by me on that date - you can attend any of these or both):

Europe / East Coast Edition
Wednesday 17 March 2021, 14:00 UTC.
Meeting Duration: 45 minutes

Asia / Pacific Edition
Wednesday 17 March 2021, 22:00 UTC.
Meeting Duration: 45 minutes

Agenda

We agree, we know what to build. On this meeting we will build together a sample spec page for a single method.
ethereum/EIPs#3410

Next Call:

Europe / East Coast Edition
Wednesday 31 March 2021, 14:00 UTC.

Asia / Pacific Edition
Wednesday 31 March 2021, 22:00 UTC.

[tkstanczak]

This is what EIP-1474 says about the block number:

eth_blockNumber
Description
Returns the number of the most recent block seen by this client

Parameters
(none)

Returns
{Quantity} - number of the latest block

Example

Request

curl -X POST --data '{
"id": 1337,
"jsonrpc": "2.0",
"method": "eth_blockNumber",
"params": []
}'

Response

{
"id": 1337,
"jsonrpc": "2.0",
"result": "0xc94"
}

[tkstanczak]

https://eips.ethereum.org/EIPS/eip-1474

[tkstanczak]

Chat content:

#27
https://eips.ethereum.org/EIPS/eip-1474
Me to Everyone (2:06 pm)
eth_blockNumber
eth_call
eth_getTransactionByHash
Me to Everyone (2:08 pm)
This is what EIP-1474 says about the block number:

eth_blockNumber
Description
Returns the number of the most recent block seen by this client

Parameters
(none)

Returns
{Quantity} - number of the latest block

Example

Request
curl -X POST --data '{
"id": 1337,
"jsonrpc": "2.0",
"method": "eth_blockNumber",
"params": []
}'

Response
{
"id": 1337,
"jsonrpc": "2.0",
"result": "0xc94"
}
Me to Everyone (2:10 pm)
What it is during syncing?
Head of the chain
BeSu: Number of the head block of the chain -> if it is synced it is the most recent block
What happens during the reorganisations?
Pivot blocks in Geth returned eth_block number
Me to Everyone (2:42 pm)
1474 to refer to JSON RPC 2.0 spec
HTTP error codes / return codes vs JSON RPC errors
Nicolas Massart to Everyone (2:45 pm)
For what I was able to find in jsonrpc specs, there was some confusing http error code mapping in 1.0 spec that were removed from 2.0
So now it look completely transport agnostic
Micah Zoltu to Everyone (2:46 pm)
👋

[tkstanczak]

General agreement to be added in EIP-3410:

eth_blockNumber should return a fully validated and verified block number of the highest total difficulty chain and make a promise that if instead of receiving eth_blockNumber, the node would receive a body, header or state request for the given block number, it would be able to provide a response within a finite amount of time.

we do not make a promise of for how long after the eth_blockNumber response we can serve such requests (state, body, header)

[tkstanczak]

We covered one edge case -> if genesis processing fails
Some clients (BeSu, TurboGeth) do not launch JSON RPC in such cases, other (Nethermind) enable JSON RPC.
Suggestion is to, if JSON RPC is enabled to return an error code (instead of returning 0)

[tkstanczak]

We suggested that it may be reasonable to add additional methods for querying other types of block numbers -> best known among peers, best validated, etc.

[tkstanczak]

During the Asia/Pacific timezone call we added a few comments on eth_blockNumber:

1. reminder to warn inside the spec about possible behaviour of node possibly returning lower eth_blockNumber after returning higher eth_blockNumber (reorg to shorter chain on Clique chains)
2. that for the same block number we can have different block hashes behind
3. if we reorganize from a longer chain, shall we ever serve eth_getByBlockNumber for the number higher than chain head? (this is conversation for eth_getBlockByNumber)

and for eth_getTransactionByHash

1. requirement to clearly specify DATA and QUANTITY types inside Open RPC
2. required clarification on int64, int53, QUANTITY
3. discussion on title vs type in OpenRPC
4. possibly a new eth_getRawTransactionByHash
5. need for specification of pre-EIP155 and post-EIP-155 transactions
6. optional vs required fields (access list missing should be no fields or empty array?)
7. handling of 'extra info' fields in different clients - shall we forbid them? require the underscore '_' to be used as a prefix for these fields?
8. handling serving transactions and receipts by nodes depending on whether they were stored during fast sync or after fast sync (eth63 delivers basic receipt data while node can store rich receipt info when processing transactions in the full mode) <- how the node should inform what format it can deliver?
9. it was mentioned that transaction formats differ between different networks / clients / versions of clients and are changing often

[MicahZoltu]

handling of 'extra info' fields in different clients - shall we forbid them? require the underscore '_' to be used as a prefix for these fields?

I like how browsers do it, where non-standard extensions are prefixed with the browser name. Once standardization is achieved, they get moved to a new name that doesn't have a prefix. This allows individual browsers to experiment with new tech without worry of clobbering anything in the global space. It also makes it very clear to readers whether they are working with a standardized feature or a feature only available in a particular browser.

[MicahZoltu]

optional vs required fields (access list missing should be no fields or empty array?)

I think there is a difference between an array of length 0 and an undefined/null array. If you have an empty set (e.g., no parameters) then it should be an array of length 0. If you explicitly have no array for some reason (e.g., it doesn't make any sense in the context) then it should be undefined/null. In most cases, what you actually have is an empty set so in most cases [] is appropriate.

[chaals]

@MicahZoltu wrote

how browsers do it, where non-standard extensions are prefixed with the browser name.

They don't do that much any more, because people started writing code that relied on the browser-prefixed version, and that meant everyone had to implement that. (There was a webkit-something method whose name I forget that for a long time was implemented in every browser except Safari because they didn't like it much). If there is a strict policy that says those methods will stop working after a known time or event (e.g a specific network upgrade) that problem might be made small enough to allow the approach.

[MicahZoltu]

how browsers do it, where non-standard extensions are prefixed with the browser name.

They don't do that much any more, because people started writing code that relied on the browser-prefixed version, and that meant everyone had to implement that. (There was a webkit-something method whose name I forget that for a long time was implemented in every browser except Safari because they didn't like it much). If there is a strict policy that says those methods will stop working after a known time or event (e.g a specific network upgrade) that problem might be made small enough to allow the approach.

I believe they still do it, for very early stuff, but users have gotten better about not suggesting their use to each other and browsers have gotten better at coming to consensus on standards quickly so you don't have features like that outstanding for a decade like we used to. 😄