Add support for 4byteTracer in debug_trace* methods

[usmansaleem]

PR description

Implements Geth's 4byteTracer for debug_traceTransaction, debug_traceBlock, and related debug trace methods. The 4byteTracer collects function selectors (the first 4 bytes of call data) from all internal calls made during transaction execution, along with the size of the remaining call data (excluding the 4-byte selector).

Changes

• Add FOUR_BYTE_TRACER to TracerType enum
• Create FourByteTracerResult class for JSON output formatting
• Create FourByteTracerResultConverter to process transaction traces
• Wire 4ByteTracer into DebugTraceTransactionStepFactory
• Add comprehensive unit tests

Implementation Details

The implementation matches Geth's 4byteTracer behavior:

• Only processes CALL-type operations (CALL, CALLCODE, DELEGATECALL, STATICCALL)
• Excludes CREATE/CREATE2 operations and precompiled contracts
• Only counts calls that successfully enter (depth increases in next frame)
• Calculates size as input_length - 4 (excluding the selector)
• Correctly handles nested sub-calls at any depth with proper occurrence counting
• Uses ProtocolSpec's precompile registry for accurate precompile detection across different protocol specifications
• Injects ProtocolSpec into DebugTraceTransactionStepFactory for protocol-aware tracing

Output Format

Returns a map where keys are in the format "0x[4-byte-selector]-[remaining-size]" and values are occurrence counts:

{
  "0x27dc297e-128": 1,
  "0x38cc4831-0": 2,
  "0x524f3889-96": 1
}

Testing

• Added FourByteTracerResultConverterTest with comprehensive test cases covering:
  • Null/empty input handling
  • Function selector extraction from CALL operations
  • Filtering (precompiles, non-entered calls, CREATE ops, short input)
  • Multiple calls with same/different selectors
  • All CALL-type operations (CALL, CALLCODE, DELEGATECALL, STATICCALL)
  • Nested sub-calls with multiple occurrences
  • Edge cases (exactly 4 bytes of input)
• Updated DebugTraceTransactionStepFactoryTest to include 4ByteTracer
• All existing tests pass

References

• https://geth.ethereum.org/docs/developers/evm-tracing/built-in-tracers#4byte-tracer

Acknowledgements

Based on original contribution PR: #9202 by @JukLee0ira

Fixed Issue(s)

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• spotless: ./gradlew spotlessApply
• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests
• hive tests: Engine or other RPCs modified?

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[lu-pinto]

I see that you are using a post processing approach where you are collecting all traces and then filtering out/picking up the information you are interested on afterwards. I would have done an in-EVM approach to build this data while tracing. The current approach could easily blow up memory usage for transactions with large enough executions.

I have already bumped into a case on hoodi where tracing timed out with one of the blocks. To debug that block I added an in-EVM tracing option to only capture specific selected opcodes and ignore all others that I didn't need. Idea: maybe these tracer types could be implemented with that feature.

Having said that, I understand that what I ask above should not be part of this PR since it's a lot of work. Pretty much all TracerTypes are already implemented with post processing so makes sense to be consistent too. Just letting you know my thoughts about this code.

[lu-pinto]

tests named with ...And... generally mean you need 2 separate tests. This test is more than 100 lines long!
I'm even for duplicating setup code that asserts different things, this way unit tests are cleaner.

[usmansaleem]

👍🏼 Refactored it into two methods.

[lu-pinto]

Would have liked to see at least a test end to end showing the new tracer type working.

[usmansaleem]

@lu-pinto I've also added spec tests generated against Geth for 4ByteTracer.

[lu-pinto]

LGTM