proof_call currently routes the request transaction through tx.ToTransaction(validateUserInput: true, gasCap: jsonRpcConfig.GasCap) in Nethermind.JsonRpc/Modules/Proof/ProofRpcModule.cs, but the test suite does not lock the gas semantics on that path.
The underlying converter in Nethermind.Facade/Eth/RpcTransaction/LegacyTransactionForRpc.cs already documents the current contract:
Gas is null -> default to gasCap- explicit gas, including
0, -> keep the literal gas value and cap it only from above
I probed that behavior on current master with two focused tests:
Proof_call_without_gas_defaults_to_gas_cap_not_block_gas_limitProof_call_with_zero_gas_keeps_literal_zero_gas_semantics
Both passed.
That gives us a narrow regression-coverage gap:
- omitted gas should keep following the
gasCap path for proof_call
- explicit
gas: 0x0 should keep returning the current literal zero-gas failure instead of silently following the omitted-gas path
The missing piece is focused coverage for that existing contract.
proof_call currently routes the request transaction through
tx.ToTransaction(validateUserInput: true, gasCap: jsonRpcConfig.GasCap)inNethermind.JsonRpc/Modules/Proof/ProofRpcModule.cs, but the test suite does not lock the gas semantics on that path.The underlying converter in
Nethermind.Facade/Eth/RpcTransaction/LegacyTransactionForRpc.csalready documents the current contract:Gas is null-> default togasCap0, -> keep the literal gas value and cap it only from aboveI probed that behavior on current
masterwith two focused tests:Proof_call_without_gas_defaults_to_gas_cap_not_block_gas_limitProof_call_with_zero_gas_keeps_literal_zero_gas_semanticsBoth passed.
That gives us a narrow regression-coverage gap:
gasCappath forproof_callgas: 0x0should keep returning the current literal zero-gas failure instead of silently following the omitted-gas pathThe missing piece is focused coverage for that existing contract.