fix: reject non-hex block numbers in debug_getRawBlock, debug_getRawHeader, debug_getRawReceipts, and eth_getProof

[sridhar-panigrahi]

Summary

debug_getRawBlock, debug_getRawHeader, debug_getRawReceipts, and eth_getProof previously accepted decimal block numbers via Long.decode() and silently succeeded. Hive's rpc-compat suite sends "2" and expects -32602 INVALID_PARAMS.

What this PR does:

• Adds the hex-prefix check inside BlockParameter and BlockParameterOrBlockHash, so every RPC using those parameter types gets the same validation. Named tags (earliest/latest/pending/finalized/safe) and block hashes still pass through.
• Per the execution-apis spec, debug_getRawBlock, debug_getRawHeader, and debug_getRawReceipts are BlockNumberOrTag (not OrHash), so all three use AbstractBlockParameterMethod / BlockParameter. This is what closes the remaining debug_getRawReceipts/get-invalid-number hive failure.
• eth_getProof is BlockNumberOrTagOrHash per spec, so it stays on BlockParameterOrBlockHash — it just picks up the new hex validation for free.

CHANGELOG breaking-changes entry now names debug_getRawBlock, debug_getRawHeader, debug_getRawReceipts, and eth_getProof explicitly, and the corresponding upcoming-breaking-changes note has been removed.

refs #9636

Test plan

• BlockParameterTest / BlockParameterOrBlockHashTest cover the new hex-prefix rejection
• EthGetProofTest and DebugSetHeadTest updated to use hex block numbers and pass
• spotlessCheck clean
• Hive rpc-compat: debug_getRawBlock / debug_getRawHeader / debug_getRawReceipts / eth_getProof reject "2" with -32602 INVALID_PARAMS, and accept "0x2" / named tags as before

[fab-10]

@macfarla since this fix is also a braking change, not sure IIRC about some kind of backward compatibility we want to keep, at least for some time.

[macfarla]

I will plan to review this week. Re the breaking change - we have flagged this as an upcoming breaking change so I think we just need to wait for 1 more release (I don't think we need to preserve the non-hex functionality).

[macfarla]

we don't want to target this change to specific RPC methods, we already have a BlockParameterOrBlockHash class that encapsulates this functionality but debug methods don't use it.

[sridhar-panigrahi]

@macfarla all three debug methods are now aligned:

• DebugGetRawBlock and DebugGetRawHeader switched from AbstractBlockParameterMethod to AbstractBlockParameterOrBlockHashMethod, accepting block hashes as well as block numbers
• Hex-prefix validation moved into BlockParameterOrBlockHash itself so it's enforced centrally for any method using that parameter type
• DebugGetRawReceipts had its redundant per-method check removed — it now relies on the same central validation

Could you take another look when you get a chance? Happy to adjust anything.

[macfarla]

@sridhar-panigrahi spotless check is failing. can you ensure you run spotless and tests locally. gradlew build now takes only about 20 min and will massively speed up the feedback cycle

[macfarla]

also will need a changelog entry

[sridhar-panigrahi]

@macfarla — the spotless and changelog issues from your last review are resolved.

I also added a small follow-on change in the latest commits: txpool_content and txpool_contentFrom now return sender addresses in EIP-55 checksummed form (Address#toChecksumString()), since they were returning lowercase hex inconsistently with the rest of the JSON-RPC surface. Happy to move that to a separate PR if you'd prefer to keep this one focused on the debug_getRaw* validation fix.

[macfarla]

@macfarla — the spotless and changelog issues from your last review are resolved.

I also added a small follow-on change in the latest commits: txpool_content and txpool_contentFrom now return sender addresses in EIP-55 checksummed form (Address#toChecksumString()), since they were returning lowercase hex inconsistently with the rest of the JSON-RPC surface. Happy to move that to a separate PR if you'd prefer to keep this one focused on the debug_getRaw* validation fix.

yes please keep this PR focussed on the original fix

[macfarla]

@sridhar-panigrahi are you still working on this PR - if you remove the changes to Address I think it's pretty close to being ready

[sridhar-panigrahi]

@macfarla , I'll get this resolved by tomorrow

I was occupied with my exams so wasn't able to look into this 😅

[sridhar-panigrahi]

@macfarla rebased onto current main and dropped the Address / txpool_content checksum changes — this PR is now just the debug_getRaw* hex validation as you asked. Conflict on CHANGELOG resolved. Spotless + DebugSetHeadTest pass locally.

[macfarla]

spotless is failing.

one last suggestion on hardcoded values in EthGeProofTest

Assuming all the tests pass (did you run them?) I'm about ready to approve

[macfarla]

@sridhar-panigrahi please fix spotless and confirm you have run the tests locally

[sridhar-panigrahi]

@macfarla ran the suite locally and it caught a real regression — the new hex check was rejecting -0x10 too eagerly, so the illegalRangeLessThan spec tests were getting the wrong error code. Relaxed the prefix check to allow a leading - and let the existing negative-number guard downstream do its job. The earlier Spotless red was a gradle wrapper download timeout, not a format issue — ./gradlew spotlessCheck and :ethereum:api:test are both clean on my end. Pushed as e8d3421.

my requested changes have been made

[macfarla]

@macfarla ran the suite locally and it caught a real regression — the new hex check was rejecting -0x10 too eagerly, so the illegalRangeLessThan spec tests were getting the wrong error code. Relaxed the prefix check to allow a leading - and let the existing negative-number guard downstream do its job. The earlier Spotless red was a gradle wrapper download timeout, not a format issue — ./gradlew spotlessCheck and :ethereum:api:test are both clean on my end. Pushed as e8d3421.

yes running the tests caught a change in behavior! that is why we have them. In this case though, I think the negative hex carve out is confusing so I have pushed an update to those 4 tests (altering the expected error message) and removing the carve out. Running the checks now, and I'll have to get someone else to review.

[sridhar-panigrahi]

Thanks for picking that up, @macfarla — much appreciated. Agreed, one consistent rule reads cleaner than the carve-out, and the generic message is fine for a negative block number anyway. Looks good to me. 🙏

[macfarla]

eth_getProof spec says BlockNumberOrTagOrHash
https://github.com/ethereum/execution-apis/blob/0e93eea98dbf02ed02bf38d3f49d06d21762c7ec/src/eth/state.yaml#L156

but for all the debug_getRawXXX methods, it's BlockNumberOrTag
https://github.com/ethereum/execution-apis/blob/0e93eea98dbf02ed02bf38d3f49d06d21762c7ec/src/eth/state.yaml#L156

so we need to make sure we match that. DebugGetRawReceipts should be changed to match, and changes to DebugGetRaw[Header,Block] should be reverted

So actually, with the accompanying changes in other PRs, the only related hive test still failing is debug_getRawReceipts/get-invalid-number

[sridhar-panigrahi]

Thanks @macfarla — good catch on the spec mismatch. Reverted DebugGetRawBlock and DebugGetRawHeader back to BlockParameter, and switched DebugGetRawReceipts the same way so all three line up with BlockNumberOrTag. eth_getProof stays on BlockParameterOrBlockHash since its spec allows hashes. Also tidied the CHANGELOG so the three debug_getRaw* methods and eth_getProof are listed by name. Local spotless + the touched tests are green — should clear that debug_getRawReceipts/get-invalid-number hive failure too.