You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The tracing code is currently written with the json-rpc in mind - the exposed types are easily serializable. But if one wishes to use the Revm inspectors directly, much of the information generated is hidden behind the parity/geth trace conversions.
Without an API in mind yet, it would be nice to expose some of the internal types for ease of manipulation to avoid conversion to the json-rpc api and back.
Two example use cases:
I have some transaction that reverts. I'd like to bubble up the internal calls that led to this revert. CallTraceNode has useful fields like parent/children, but it is not available. Instead, the CallTraceNodes are converted into TransactionTrace types for serialization, and the trace_address fields need to be parsed back and converted into the tree to find parents.
I want both the VMTrace and the CallTraces. But I create an Inspector, and need to convert it to either a parity builder or a geth builder to be able to see the results of the trace - both of which consume the inspector.
Additional context
No response
The text was updated successfully, but these errors were encountered:
Describe the feature
The tracing code is currently written with the json-rpc in mind - the exposed types are easily serializable. But if one wishes to use the Revm inspectors directly, much of the information generated is hidden behind the parity/geth trace conversions.
Without an API in mind yet, it would be nice to expose some of the internal types for ease of manipulation to avoid conversion to the json-rpc api and back.
Two example use cases:
Additional context
No response
The text was updated successfully, but these errors were encountered: