4byteTracer implementation for debug_trace json-rpc

[JukLee0ira]

PR description

Hi,team! I noticed the issue #8326, so I added this 4byteTracer. The 4byte Tracer is used to identify function signatures in transactions and is a very useful tool. It creates a mapping from 4-byte signatures to call counts, helping us in scenarios like analyzing contract function call patterns, security analysis, and audits.

Call Example

Before using it, make sure to enable the feature with --Xenable-extra-debug-tracers=true

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "debug_traceTransaction",
    "params": [
      $hash,
      {
        "tracer": "4byteTracer"
      }
    ],
    "id": 1
  }' \
  http://localhost:8545

Expected Return Results

The return result is as follows, it's a mapping table:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "0x9dc2c8f5-0": 1
  }
}

In this example, "0x9dc2c8f5-0": 1 means:

• The function selector 0x9dc2c8f5 was called 1 time
• The parameter data size is 0 bytes (meaning only the 4-byte function selector, no extra parameters)

Implementation Logic

1. Function Selector Extraction: Extract the first 4 bytes of call data as the function selector
2. Parameter Data Size Calculation: Use len(input)-4 to calculate parameter data size (excluding the selector)
3. Opcode Filtering: Only process operations that handle execution context like CALL, CALLCODE, DELEGATECALL, STATICCALL
4. Edge Cases: Skip calls to precompiled contracts to avoid noise, as they are just opcode behaviors, not valid contract method call information

I'd greatly appreciate any feedback or guidance you might have. I'm happy to make adjustments based on your thoughts!

Fixed Issue(s)

#8326

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?

[usmansaleem]

@JukLee0ira Can you update your branch with latest changes. The changes look straight forward, I need to do some manual testing before we can get it merge.

[jframe]

@JukLee0ira Looks like there is an issue with formatting, spotless is failing. You can run ./gradlew spotlessApply to fix that.

[usmansaleem]

Implemented by #9642 with credits.