spec: allow EIP-1898 block objects in BlockNumberOrTagOrHash - #859
Open
MysticRyuujin wants to merge 1 commit into
Open
spec: allow EIP-1898 block objects in BlockNumberOrTagOrHash#859MysticRyuujin wants to merge 1 commit into
MysticRyuujin wants to merge 1 commit into
Conversation
EIP-1898 lets state-access methods take the block parameter as an object,
either {"blockNumber": "0x..."} or {"blockHash": "0x...",
"requireCanonical": bool}. The spec only described the string forms, so
speccheck rejected the object form outright.
Add both shapes as anyOf branches and cover them with tests on
eth_getBalance, eth_call and eth_getProof. The branches set
additionalProperties: false, so an object combining blockNumber and
blockHash is invalid.
The non-canonical case stays untested: the test chain has no sidechain, so
there is no way to reference a non-canonical block.
looks good
4 tasks
lightclient
reviewed
Aug 10, 2026
| $ref: '#/components/schemas/BlockTag' | ||
| - title: Block hash | ||
| $ref: '#/components/schemas/hash32' | ||
| - title: EIP-1898 block number object |
Member
There was a problem hiding this comment.
does this have to be a separate object? ideally it would be an optional value on "Block Number" and "Block hash" object?
Contributor
Author
There was a problem hiding this comment.
Can you elaborate on this question?
The options are basically:
"0x1234" - a Block Number
"0x..." - a Block Hash
or and object {} that object can be one of:
{"blockNumber":"0x1234"...}
{"blockHash":"0x...","requireCanonical":true|false,...}
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #713 (mostly)
EIP-1898 defines two object forms for the block parameter:
{"blockNumber": ...}and{"blockHash": ..., "requireCanonical": ...}. Clients accept them, but the schema onlyallowed a number, a tag, or a bare hash. So the spec rejected valid requests.
This adds both object forms to the union.
additionalProperties: falsekeeps the twoshapes distinct, and
requireCanonicalstays optional on the hash form.The change applies to every method that uses
BlockNumberOrTagOrHash:eth_call,eth_simulateV1,eth_getBlockReceipts,eth_getBlockAccessList,eth_getBalance,eth_getStorageAt,eth_getStorageValues,eth_getTransactionCount,eth_getCodeand
eth_getProof.On errors, the schema documents what EIP-1898 recommends:
-32000: Invalid inputwhenrequireCanonicalis true and the block is not canonical, and-32001: Resource not foundwhen the block does not exist. A missing block takes precedence. This is adescriptiononly. The codes are not added to the methods'errorslists, so nothingenforces them. Say the word if you want them enforced instead.
New tests cover the object forms in three parameter positions:
eth_getBalancewithblockNumber, withblockHash, and withblockHashplusrequireCanonicaleth_call, which uses the callenv contract so a client that ignores the blockparameter fails
eth_getProof, which targets head rather than a historical block, because clientsbound how far back they serve proofs