Discussion: Add input and output fields to InternalTransactions

[roseshahar]

Summary

This proposal adds input (call data) and output (return data) fields to InternalTransactions in the TRON protocol.

The Problem

TRON currently does not persist these specific fields in its database. As a result, indexers and explorers cannot fetch critical information regarding internal actions, such as:

• Function call parameters within contract-to-contract interactions.
• Deployment data for contracts created via factory patterns (internal CREATE/CREATE2).

The Solution

By capturing and storing these fields, TRON will provide complete execution traces (similar to EVM standards). This will:

• Improve Transparency: Provide full visibility into nested contract execution.
• Enable Better Indexing: Allow tools to accurately track internal state changes and factory deployments.
• Enhance Developer Experience: Simplify debugging by exposing return values from internal calls.

Reference Implementation

The code changes for java-tron are available here:
tronprotocol/java-tron#6511

[roseshahar]

Related Pull Request: #817

[lxcmyf]

@roseshahar
Could you clarify the concrete use cases and consumers for this data, and whether
full persistence is required versus trace-based or optional solutions?

[roseshahar]

@lxcmyf This change only affects nodes that use saveInternalTx

Example use cases:

1. Data indexers - currently no one can index what an internal transaction did (sighash, output, etc...). For example you can see that Allium's TRON contracts table is very partial.
2. Contract deployments via factories - Contract constructors cannot be found. Also, the only way currently to get the bytecode of a contract that was deployed via a factory is by using an external node call GetContract / eth_getCode, and can't be found via block endpoints. This means you can't fully index these contracts the same as normal deployments
3. Security providers - You can't understand what a transaction did on-chain other than emitted events and native transfers. For example - see how the Bybit attack used internal calls and storage changes

[waynercheung]

@roseshahar Will input/output data for historical transactions be accessible? If yes, through what mechanism?

[roseshahar]

@waynercheung The data will not be accessible historical because it does not exist in the database currently. However, if you will re-sync a node from Genesis after this change, that data will be available

[waynercheung]

@roseshahar If input/output is added, the node database may expand, especially for transactions with frequent internal calls. It is suggested to introduce configuration options that allow users to configure on their own whether to enable the addition of input/output. Also, evaluate the average field size (input may be hundreds of bytes) and test the impact on node synchronization time.

[lxcmyf]

@roseshahar
Since the agreement of internal transactions does not participate in consensus, it is recommended to customize and develop fullnode and add these two fields to meet your needs.

[yuval99g]

This change makes a lot of sense - being able to see input and output data from internal transactions will really help developers understand what’s actually happening under the hood. Right now a lot of important context (like contract call params and return values) is basically invisible, which makes debugging and building tooling harder than it needs to be. Capturing these fields would bring TRON’s execution traces closer to what developers are used to on EVM-style chains, and I’d love to see this move forward.

[waynercheung]

@lxcmyf
Thanks for suggesting the custom fullnode development as an option. I think this is a solid alternative since internal tx don't affect consensus, making it low-risk and quick to implement for those who need it right away. It avoids bloating the core protocol and lets users fork java-tron to add input/output fields locally, similar to how some Ethereum nodes handle custom tracing.

[roseshahar]

@waynercheung This is absolutely not the case.

First of all, you can read about how custom tracers work on Geth here. The Geth team developed a solid API where you can just "drop-in" your tracer file, and it has access to a very defined set of input. In this case, the data is not saved, it can not be accessed even if you gave a plugin API.

When you say "just run a custom node" you are just inviting builders to the mess of merge-conflicts, running your own node which is not that simple on TRON, and getting your database conflicting with upstream changes.

Second, this is not bloating, this is a must have for supporting builders on your chain. If you have access to Allium's tables you can see that most of the Contracts table is empty because they just don't have the data. Adding the input and output is not bloating since the InternalTransaction is already feature-flagged.

[roseshahar]

@lxcmyf Since one of the most active issues on TRON is an archive node I think that any step in this direction does help the consensus, even if the people who upvoted are not active here.

[317787106]

@roseshahar It seems useful. Have you estamated the volume size of these input and output? Data is constantly expanding, this is a big problem.

[waynercheung]

@roseshahar
Adding input/output fields may not be necessary for all developers, so having saveInternalTx automatically include input/output data isn't an optimal approach.
It would be better to provide a separate configuration flag allowing developers to choose whether to store this data.

[lxcmyf]

@roseshahar
I think the archive node is not a good idea. Due to the large amount of data generated by archive node snapshots, Tron currently does not support providing snapshots of archive nodes.