Native call tracer (block mode) does not have a way to populate txHash

[evanzbitgo]

Rationale

Why should this feature exist?
When tracing a block with call tracer, we need to know the txHash of each transaction. Unfortunately, we have no way to populate that txHash even with custom tracer.

What are the use-cases?
We need have a reliable way to map a txHash to its traces. Without this feature, we have to rely on the transaction order within the block which does not give us a strong confidence of correctness.

Implementation

Do you have ideas regarding the implementation of this feature?
We need to add txHash into TxContext struct

Are you willing to implement this feature?
Yes

[karalabe]

The trace order must be the same as the transaction order in the block. Why would it be different?

[holiman]

We already have this for js-tracers, via the constructor. It would be pretty easy to modify this function, in native/tracers.go

// lookup returns a tracer, if one can be matched to the given name.
func lookup(name string, ctx *tracers.Context) (tracers.Tracer, error) {
	if ctors == nil {
		ctors = make(map[string]func() tracers.Tracer)
	}
	if ctor, ok := ctors[name]; ok {
		return ctor(), nil
	}
	return nil, errors.New("no tracer found")
}

to also pass the ctx to the constructor for the native tracer. The ctx contains the txindex and txhash. cc @s1na

[evanzbitgo]

The trace order must be the same as the transaction order in the block. Why would it be different?

Better to be built in Geth, in case of unforeseen situations such as missing txns and two lists do not exactly match

[s1na]

Now custom native tracers have access to txHash and blockHash but those are not added to the default call tracer. Feel free to open a PR if you need that too.

[evanzbitgo]

Now custom native tracers have access to txHash and blockHash but those are not added to the default call tracer. Feel free to open a PR if you need that too.

Thank you!