Support the debug_traceCall API

[Federico2014]

Background

debug_traceCall is a method in the EVM that allows developers and users to trace the execution of a particular transaction or contract function call. This functionality is primarily used for debugging purposes, to understand how smart contracts are behaving during execution or to diagnose issues with transactions.

The EVM then executes the transaction or call in a special mode where it records detailed information about each step of the execution process. This information typically includes details such as:

1. Opcode: The specific operation being executed.
2. Gas consumption: The amount of gas consumed by each operation.
3. Stack and memory state: The state of the EVM's stack and memory at each step.
4. Contract calls: Details of any calls made to other contracts during execution.
5. Storage changes: Any changes made to contract storage during execution.

The account abstract ERC4337 specification need to run debug_traceCall to enforce the validation rules on opcode and storage access, as well as to verify the entire batch transaction, and use the consumed gas for the actual transaction execution.

But debug_traceCall is not supported on Tron currently, so it may influence the implement of account abstract infrastracture on TRON.

Rationale

Smart contract wallets containing arbitrary verification logic instead of EOAs will be more and more popular in Web3, it is necessary to support account abstract on TRON. The Bundler module of account abstract infrastracture needs the debug_traceCall to enforce the user operation validation rules according to ERC4337 specification. So it may be necessary to support the debug_traceCall API on TRON.

[forfreeday]

That's good advice.

[bladehan1]

Is the call actually executed? And can you provide a return sample?

[Federico2014]

Is the call actually executed? And can you provide a return sample?

The call is simulation executed, similar to eth_call, you can try the example on BTTC testnet:

curl -X POST -H "Content-Type: application/json"  'https://pre-rpc.bt.io/' --data '{"method":"debug_traceCall","params":[{"from":"0x567F96aB219a733eF5284F519386c9EeFCA6207C","to":"0xc9dc0c4a79cc03b264310ebc994e92ab428bac6c","gas":"0xffff","data":"0x9b249f6900000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000058db3a1d8533607c04ea5d23b5edf0883d1646455b5fbfb9cf000000000000000000000000567f96ab219a733ef5284f519386c9eefca6207c00000000000000000000000000000000000000000000000000000000000000000000000000000000"},"latest",{"disableStorage":true,"disableMemory":true}],"id":44,"jsonrpc":"2.0"}'

The result is tedious, the API should support custom trace by javascript to filter the required results.

[bladehan1]

Thanks,it 's really tedious.
So our ultimate goal is to achieve account abstraction, and supporting this API is the only way to go.Is there an easier way to only support necessary functionality?

[endiaoekoe]

As an Ethereum developer. the debug_traceCall API is a highly useful debugging tool in Ethereum development. It allows developers to simulate and observe the execution process of smart contracts without altering the blockchain state.
It has some classic scenarios， as below:

• Smart Contract Development and Testing
• Troubleshooting(smart contract has been deployed on the Ethereum mainnet but encounters issues during actual execution.)
• Performance Optimization(need to optimize the performance of a smart contract and reduce gas consumption)
• Security Checks(security checks are required before deploying a smart contract.)

But from an implementation perspective, implementing debug_traceCall API in Java-TRON requires considering the following technical aspects:

1. Instruction Set Differences: EVM and TVM may have different instruction sets. It is necessary to analyze these differences and ensure that debug_traceCall can accurately simulate the execution environment of TVM.

2. State Management: Smart contract state management may have different implementations in different VMs. It is important to ensure that the tracing and rollback mechanisms for the state align with the workings of TVM(currently not supported as far as I know).

3. Data Structures and API Interfaces
   Transaction and Block Data: The data structures for transactions and blocks in Java-TRON may differ from Ethereum. Adjustments to debug_traceCall need to be made to accommodate these data structures.
   API Parameters and Return Values: API parameter and return value formats compatible with Java-TRON need to be defined to ensure seamless usage by developers.

4. Resource Consumption: Considering the performance requirements and resource limitations of Java-TRON, performance optimization of debug_traceCall is necessary to reduce unnecessary computation and storage overhead.

[Federico2014]

Thanks,it 's really tedious. So our ultimate goal is to achieve account abstraction, and supporting this API is the only way to go.Is there an easier way to only support necessary functionality?

The account abstract runs debug_traceCall to enforce the validation rules on opcode and storage access for the account factory, paymaster, and aggregator contracts. We have considered other two ways to avoid the debug_traceCall:

• the bundler whitelists the account factory, paymaster, and aggregator contracts by auditing the contract source code ahead of time, which is not flexible, and is quite limited.
• omit the validation rules on opcode and storage access directly. I think It mainly has a negative influence on the bundler module, such as denial-of-service attack, refer ERC7562. But there may be some other potential uncertain risks.

[dubuqingfeng]

Is there any progress on this?

[Federico2014]

Is there any progress on this?

As far as I know, no progress yet.