Display "data" Field and Expand Event Log Decoding

[mshakeg]

Problem

• Understanding events on the Hedera blockchain is crucial for transparency and analysis of network activity. While the current explorer displays event topics for unverified contracts the data field is also crucial to fully decoding an event.
• The data field within event logs is not currently displayed, limiting the contextual data available to users.
• Event decoding is primarily dependent on the contract being verified on sourcify. This creates limitations for analyzing events emitted by unverified contracts.

Solution

1. Include the data field below the topics for all event listings. Allow users to easily view the complete event log information.

2. Expand Decoding Capabilities:

   • Verified Contracts: Continue to utilize the available ABI for verified contracts to decode event logs.
   • Unverified Contracts: Implement a fallback mechanism similar to the existing 4byte.directory usage in transaction call tracing:
     • Extract the event signature (topics[0]).
     • Query https://www.4byte.directory/api/v1/event-signatures/... for a matching signature.
     • If a match is found, decode the event using the text_signature from the response

Alternatives

No response

[mshakeg]

Hi @ericleponner and @svienot just wanted to follow up on this request, it would be really helpful.

[ericleponner]

Hi @mshakeg Do you have test data ? I mean log events emitted by a verified contracts and not decoded. We normally put some logic dedicated to event decoding (based on etherjs library). May be it's "suboptimal" … test data would help us.

[mshakeg]

Hi @ericleponner yes I do, the following tx is an HTS approval tx, the function call decoding to the HTS system contract seems to also be problematic so the approve isn't clear from the call trace.

https://hashscan.io/mainnet/transaction/1718133892.513390003

However, if you decode the event log(using a tool such as https://tools.deth.net/event-decoder which relies on the 4byte directory), it's very clearly an ERC20 event Approval(address indexed, address indexed, uint256) log:

{
    "address": "0x00000000000000000000000000000000005c9f6b",
    "bloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000002000000200200000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000000000010020000010000008000000000000000000000000000000000000000000000",
    "contract_id": "0.0.6070123",
    "data": "0x00000000000000000000000000000000000000000000000000000000000f4240",
    "index": 0,
    "topics": [
        "0x8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925",
        "0x0000000000000000000000004403b424ea406b9fbb8bf1169e8447f658cd776b",
        "0x0000000000000000000000001b0ef045830466171d617dd0f1142ad699a4cd63"
    ]
}

NOTE: the indexed field in the event log, which AFAIK the 4byte directory does not return, so you'll likely have to trial and error insert indexed in the fields from left to right if you can't decode it without any an indexed(as is the case for many logs).

[ericleponner]

@mshakeg Thanks a lot. Let us investigate and come back later.

[mshakeg]

Hey @ericleponner just want to check in on the progress of this issue.

[mshakeg]

@ericleponner @svienot a friendly nudge :)

It's quite simple and I imagine would make a lot of devs happy.

[ericleponner]

@mshakeg Thanks for the reminder :) We don't forget it but lowered a bit its priority.