core/tracing: register live tracer APIs

[jsvisa]

Hi @s1na, could you please review this pre-PR for the live trace_xxx RPC? Below are the main points covered in this PR:

1. The live tracer is registered with the tracing.Backend interface, which will be utilized internally.
2. Within the live tracer, I’ve added another field, which is []rpc.API, so we can use stack.RegisterAPIs to register the JSON-RPC interfaces.
3. A new function BlockChain.SetLogger, has been added to enable setting the live tracer once it is fully initialized.

[s1na]

I pushed a change to allow tracers to add their API methods to the console. the rpc.API type has now a ConsoleExtension field for this purpose.

[s1na]

I tested with the following tracer and it correctly registers the API. The method is also invokable through the console.

package live

import (
	"encoding/json"

	"github.com/ethereum/go-ethereum/common"
	"github.com/ethereum/go-ethereum/core/tracing"
	"github.com/ethereum/go-ethereum/eth/tracers"
	"github.com/ethereum/go-ethereum/rpc"
)

func init() {
	tracers.LiveDirectory.Register("chainTracker", newChainTracker)
}

type chainTracker struct {
	lastBlockHash common.Hash
}

func newChainTracker(_ json.RawMessage, node tracers.LiveApiRegister, _ tracing.Backend) (*tracing.Hooks, error) {
	t := &chainTracker{}
	node.RegisterAPIs([]rpc.API{
		{
			Namespace: "eth",
			Version:   "1.0",
			Service:   &chainAPI{tracer: t},
			Public:    true,
			ConsoleExtension: `
web3._extend({
	property: 'eth',
	methods: [
		new web3._extend.Method({
			name: 'lastBlockHash',
			call: 'eth_lastBlockHash',
			params: 0,
		})
	]
});
`,
		},
	})
	return &tracing.Hooks{
		OnBlockStart: t.OnBlockStart,
	}, nil
}

type chainAPI struct {
	tracer *chainTracker
}

func (api *chainAPI) LastBlockHash() string {
	return api.tracer.lastBlockHash.Hex()
}

func (t *chainTracker) OnBlockStart(event tracing.BlockEvent) {
	t.lastBlockHash = event.Block.Hash()
}

[s1na]

This makes me realize the whole tracing interface is in one place (tracing/hooks.go) except for the constructor. It is harder to catch backwards-incompatible changes to the interface because of this. Gonna move it out.

[jsvisa]

yeah, agree with it, move the apis into one place(hooks.go) will make it more obvious.

[s1na]

LGTM

[s1na]

@fjl PTAL

[fjl]

This GetTransaction method is not great for several reasons. First, it requires us to have an index of txhash -> tx, which is strictly optional. The index we have is not complete, we only keep a limited horizon worth of blocks in it. The indexing is also async with block execution and so it may not lead to a repeatable tracing result.

Another problem is the amount of return values. A signature with this number of return values implies there may be more values returned in the future. If we wanted to change this, it would break the interface. So we need to either define a new struct which is to be returned by this method, or break it up into multiple methods.

I also wonder why a tracer would need to query transactions by hash. I think it's a niche use case and we might be better off not allowing it.

[jsvisa]

This method will be used for the trace_transaction RPC, ref https://github.com/ethereum/go-ethereum/blob/c8dfa31422/eth/tracers/live/live_api_trace.go#L93-L116

[s1na]

I also wonder why a tracer would need to query transactions by hash.

I think a tracer will almost never need this in and out of itself. Only in the case where the tracer is exposing an API. Which makes me think if live tracers exposing an API is a good abstraction. It is easy to abuse the live tracing interface to expose an API that doesn't need tracing hooks at all. I wonder if we should introduce plugins that can also register live tracers and/or APIs instead.

[jsvisa]

I wonder if we should introduce plugins that can also register live tracers and/or APIs instead.

agree with it, plugins will be more flexible and useful for different use cases.