RPC Standards 3, March 31, 2025

[jflo]

RPC Standards 3, March 31, 2025

Date & Time: March 31th, 2025, 15:00 UTC

• Duration in minutes : 60
• Recurring meeting : true (true will trigger reccuring meeting with youtube streams on Ethereum protocol youtube channel)
• Occurrence rate : bi-weekly
• Other optional resources

Agenda

• resolving site generation issues and "We should just move to docusaurus" --lightclient, probably
• standardize the API to prefer decimal integers over hex for all numbers. Hex should be reserved for raw data fields. Large integers will likely need to be quoted strings.
  • decent sized proposal, should this be an issue or just straight to a pr?
• removing "aged out" fields whats it take to get this merged?
• error code standardized whats it take to get this merged?

Other comments and resources

The zoom link will be sent to the facilitator (please fill in the email and telegram)
Facilitator email: justin@florentine.us
Facilitator telegram: @RoboCopsGoneMad

[macfarla]

I've been looking at hive rpc-compat results for besu and have found a few things that I think need clarifying in the spec.
Rpc-compat hive failures analysis - it's a public google sheet

• hex type used for keys should not allow 0x empty values - draft PR use uint256 for keys to disallow 0x empty execution-apis#641
• Hex strings - odd-length strings and representation of zero
  • this one came up for discussion because there's a test that besu is failing where we had 0x (resulting from a call to trimLeadingZeros but if it's a zero we have to add a zero back on - I had a hacky fix that made the test pass but the PR raised this question)
  • defined https://github.com/ethereum/execution-apis/blob/40088597b8b4f48c45184da002e27ffc3c37641f/src/schemas/base-types.yaml
  • this is the definition used most places uint256 regex ^0x(0|[1-9a-f][0-9a-f]*)$ which allows odd and even length, without leading zeros unless the value is 0x0
  • representation of zero in hex - 0x00 is arguably more correct (even length hex string) but we allow/expect 0x0
• null vs "not found" - what should be returned in the case where the thing you're asking for is not found or doesn't exist
  • Some RPCs have this spec'd but not all
  • does this need to change with history expiry? Do we need to distinguish between past and future "not found"?
  • eg eth_getBlockReceipts, eth_getTransactionByHash, eth_getBlockTransactionCountByHash - the spec says the result will be null or data
  • debug_getRawTransaction, debug_getRawBlock, eth_getProof - no provision in spec for null or not found
• totalDifficulty - this field would still be included in historical (pre-merge) blocks - can it be optional in the blockResult spec?

[macfarla]

Also raised an issue for some errors I'm getting running speccheck and spellcheck ethereum/execution-apis#642

[jflo]

The issue of odd length uint256 encoded strings was discussed, and determined to be a non-issue, as odd length numbers are common.

[jflo]

Null vs. Not Found - determine how widely this is a problem, and propose how to more explicitly specify these cases.

[jflo]

We'd like to make totalDifficult optional ( present in the json for pre-merge blocks, missing post-merge) in responses, but will not propose any changes till we hear from wallet and dapp devs.

[poojaranjan]

Recording: https://youtu.be/hS7bEvHW5nY