feat: small defense in depth check for the evm inspector

[gilcu3]

Closes #3681

[claude]

Pull request overview

Adds a small defense-in-depth layer to the EVM inspector: the receipt returned by eth_getTransactionReceipt must echo the requested transaction hash, and any log selected by index must be internally bound to that receipt (matching tx hash, block hash, and block height). Closes 3681. Only guards against inconsistent/tampered RPC responses — a fully Byzantine provider returning internally consistent forged data still passes (out of scope, per the linked issue).

Changes:

• Add transaction_hash: H256 to GetTransactionReceiptResponse (deserialized from transactionHash).
• In EvmInspector::extract, reject a receipt whose transaction_hash differs from the requested hash (reusing InconsistentRpcResponse).
• In EvmExtractor::extract_value for Log, verify log.transaction_hash == receipt.transaction_hash, log.block_hash == receipt.block_hash, and log.block_number == receipt.block_number; return a new LogNotBoundToReceipt error variant otherwise.
• Add four new unit tests for the mismatch paths and backfill transaction_hash on every existing test fixture.

Reviewed changes

Per-file summary

File	Description
crates/foreign-chain-rpc-interfaces/src/evm.rs	Adds transaction_hash: H256 field to GetTransactionReceiptResponse.
crates/foreign-chain-inspector/src/evm/inspector.rs	Adds the receipt-hash check in extract and the log-to-receipt binding check in EvmExtractor::extract_value.
crates/foreign-chain-inspector/src/lib.rs	Rewords InconsistentRpcResponse message; adds new LogNotBoundToReceipt error variant.
crates/foreign-chain-inspector/tests/evm_inspector.rs	Enables non_snake_case, backfills transaction_hash on existing fixtures, adds four new tests plus an extract_log_from_receipt_with helper.

Findings

Non-blocking (nits, follow-ups, suggestions):

• crates/foreign-chain-rpc-interfaces/src/evm.rs:14 — transaction_hash is now a required field on GetTransactionReceiptResponse. Any Ethereum-compatible RPC provider currently returns transactionHash, so this is safe in practice, but note that this is a wire-format breaking change: a previously-serialized GetTransactionReceiptResponse (e.g. cached JSON without the field) would now fail to deserialize. No such consumers were found in-tree, so this is a heads-up rather than a blocker.
• crates/foreign-chain-inspector/src/evm/inspector.rs:204-206 — The check omits log.removed and log.transaction_index. removed should be false after the canonical/finality checks (side-block reorg), but explicitly rejecting log.removed == true would be a cheap and mirrored defense. transaction_index is transitively bound by transaction_hash, so leaving it unchecked is fine.
• crates/foreign-chain-inspector/src/evm/inspector.rs:201-203 — Comment states the transitive binding argument, which is genuinely useful "why" content. Consider adding one line noting that the receipt has also had its block hash verified as canonical (verify_block_is_canonical), so the log block-hash check transitively pins the log to a canonical block too. Not required.
• crates/foreign-chain-inspector/src/evm/inspector.rs:67-68 — Small phrasing nit: the comment describes the "well-behaved backend" case, but the actual value of the check is catching misbehaving backends. Consider rephrasing as "a well-behaved backend always echoes the hash we queried, so a mismatch means the backend is buggy or dishonest".
• crates/foreign-chain-inspector/src/starknet/inspector.rs:38-47 — Original issue 3681 notes "the Bitcoin inspector already echoes back and checks the queried hash; the EVM path (and similarly Starknet) does not." Starknet remains unbound after this PR. If that is intentionally deferred, consider filing a follow-up issue and linking it in the PR description; otherwise it is a scope gap.
• crates/foreign-chain-inspector/tests/evm_inspector.rs:566-604 — New tests follow the required <sut>__should_<assertion> convention with // Given / When / Then sections, but the file mixes them with older extract_returns_X_when_Y tests. Not a blocker (existing tests predate the convention), just worth flagging that future work in this file should keep the new convention.

✅ Approved

[haiyuechen-nearone]

Should we add this guard for Starknet as well?

[gilcu3]

Should we add this guard for Starknet as well?

I thought about it but it seems not simple for Starknet, as the receipts have a different structure (but I do not understand the details very well, as this is Starknet specific stuff)

[haiyuechen-nearone]

I think we have transaction hashes for the Starknet providers as well:

https://github.com/starkware-libs/starknet-specs/blob/c2765866e1d5f2e62c5649f7baf5ca53d0e84872/api/starknet_api_openrpc.json#L2975-L2979

https://www.alchemy.com/docs/chains/starknet/starknet-api-endpoints/starknet-get-transaction-receipt

https://www.quicknode.com/docs/starknet/starknet_getTransactionReceipt

@anodar please keep me honest on this

[haiyuechen-nearone]

Starknet tx hash check can be added as a follow up, I think this is good to go.

[anodar]

LGTM. Dropped some optional nits.

[anodar]

Thank you!