Flat call tracer

[ziogaschr]

No description provided.

[s1na]

Hm I notice the context doesn't have the block number which is usually part of the parity trace. I'll have to look into why

[ziogaschr]

BlockNumber has to be added, as said the PR is not finished.
I would like to know your thoughts on using a proxy tracers to call_tracer or a new tracer for flat_tracer.

The one thing I liked with the proxy one, is that we will have a single point in codebase to maintain the tracer logic. Although this approach, has some nitpicks in order to work.

Example nitpick which is not pushed here follows. Here and because we don't have access to callTracer.callstack we have to keep track of some stuff in this tracer ourselves. Making the callTracer.**C**allstack public will help, but then it will make more trivial to maintain the callTracer if we want to apply any changes.

// CaptureStart implements the EVMLogger interface to initialize the tracing operation.
func (t *flatCallTracer) CaptureStart(env *vm.EVM, from common.Address, to common.Address, create bool, input []byte, gas uint64, value *big.Int) {
	// Update list of precompiles based on current block
	rules := env.ChainConfig().Rules(env.Context.BlockNumber, env.Context.Random != nil)
	t.activePrecompiles = vm.ActivePrecompiles(rules)

	// this is a workaround in order to exclude precompile calls in CaptureExit where we don't have the proxied tracer context
	t.currentCall = flatCallFrame{
		Type: strings.ToLower(vm.CALL.String()),
		Action: FlatCallTraceAction{
			From: &from,
			To:   &to,
			// Gas:   gas,
			// Value: value,
		},
	}

	if create {
		t.currentCall.Type = strings.ToLower(vm.CREATE.String())
	}

	t.tracer.CaptureStart(env, from, to, create, input, gas, value)
}

[s1na]

is that we will have a single point in codebase to maintain the tracer logic

I agree with that. As long as there aren't many work-arounds needed because of differences between parity-vs-geth styles like the one mentioned. That depends on whether we want a flatTracer or we want the parityTracer. Because as you mentioned parity tracer has some non-cosmetic differences like precompiles being excluded. Do you know what are the other differences?

You can cast the t.tracer.(*callTracer) and then you'll have access to callstack since they're in the same package. That should make things easier.

Comparing this version and the one in core-geth I must admit I like this one more. Even if we don't go with the proxy approach I think we should track the calls in the same shape that they will be returned (i.e. flat) so we don't need post-processing apart from toHex and toJSON conversions. I.e. avoid the Finalize method in your code. I realize a challenge is that we need access to the call in CaptureExit. But we can find the index of the call in the flat list by storing an additional stack that only tracks indices.

[ziogaschr]

Because as you mentioned parity tracer has some non-cosmetic differences like precompiles being excluded.

Do you find a bad idea to add an option in CallTracer that allows user to decide? excludePrecompiles: boolean

You can cast the t.tracer.(*callTracer) and then you'll have access to callstack since they're in the same package. That should make things easier.

Nice one. Will check it and think if it adds more complexity than needed for maintenance later on.

[s1na]

Here we're doing an extra marshal and unmarshal. A call to t.tracer.GetResult is not necessary. We can directly access its callstack and process the output.

[ziogaschr]

Yes, this make things a lot easier. Will try to work on this direction using this proxy tracer and see how it goes.
Will be nice if you can reply here and with a go/no-go.

[ziogaschr]

What do you think of these changes here @s1na? Was thinking that even this PR doesn't need this change, it is good to have it upstream for gen_callframe_json.go, so as if/when needed to be used, it will work as expected.