Add support for the Debug/Trace API

[a-moreira]

Motivation

The debug API is necessary for getting information about the so-called "internal transactions", which are very important for smart contract developers. Currently, Frontier does not support this API, so it's not possible to have a information about internal transactions in a Frontier-based chain.

Looks like Moonbeam team have implemented these APIs on their client, and it is working (check these internal transactions)

Suggested Solution

Try to port Moonbeam's RPC code to Frontier

Additional Information

check #267 for previous related issue

[a-moreira]

If it seems like a good idea to have the Moonbeam code ported to Frontier's repo, I will start working on it.

[crystalin]

I'm not sure why it was ported to Moonbeam only and not Frontier. (cc @tgmichel )
@sorpaas what's your opinion on pushing it to Frontier ?

[tgmichel]

@crystalin in the past the debug and txpool namespaces have been under heavy development, so having them in our repo felt more convenient to us. That's the only reason, moving them to Frontier seems like a good idea to me.

That being said, any project can currently add Moonbeam evm-tracing modules as a dependency if they want to.

[boundless-forest]

@a-moreira Any update about this?

[a-moreira]

hey @AsceticBear, I'm working on it, using this moonbeam-foundation/moonbeam#196 as reference. Both Substrate and Moonbeam have changed a lot since the PR, though, and I haven't been able to make everything work on Frontier yet.
Should I open a PR already to get some feedback?

[boundless-forest]

using this moonbeam-foundation/moonbeam#196 as reference. Both Substrate and Moonbeam have changed a lot since the PR.

@a-moreira Why not use the latest version of frontier and moonbeam?

Should I open a PR already to get some feedback?

Nice

[a-moreira]

hey people @AsceticBear @crystalin @tgmichel I opened a PR here #768

[a-moreira]

I am only getting two build errors, and they are exactly the same as reported here by another user: #737

[ozgunozerk]

I think a status update on this issue and elaboration on why it's blocked or not planned in the near future will be helpful for the community. Maybe someone will unblock it :) (tbh, I can volunteer to work on this if I can get a deeper understanding)

Let me try to summarize what I gathered from my own research and also the discussion in the related pr #768.

Problems

• you cannot enable environmental or emit events in your on-chain runtime - unless you want your regular transactions to be in orders of magnitude slower than a regular EVM execution -
• if you are a LIVE chain and you want to use the Debug and Trace namespaces you need dedicated tracing nodes that point to a full-set of runtime overrides following religiously your on-chain runtime version history but compiled with the provided environmental feature flags

---

There are 2 existing implementations of tracing module in the ecosystem (please let me know if there are more):

• moonbeam
• acala

---

Moonbeam

From what I've gathered, and also stated in the PR's discussion: moonbeam requires an extra node instance for tracing, and exposes a lot of tracing functionality via rpc from client. So, this falls under the category:

if you are a LIVE chain and you want to use the Debug and Trace namespaces you need dedicated tracing nodes

---

Acala

Couldn't find any discussion about this online, but inspected the source-code myself. To me, it seems like acala is enabling environmental on their implementation for on-chain runtime. So, this falls under the category:

you cannot enable environmental or emit events in your on-chain runtime - unless you want your regular transactions to be in orders of magnitude slower than a regular EVM execution -

But I honestly don't know if their regular transactions are magnitude slower, or are there any other drawbacks to their implementation.

---

Why Moonbeam Approach did not work for Frontier

Found this in the closed PR:

In order to move the tracing code here we need a fully compliant solution, otherwise external projects relying on it will 100% malfunction.

Consider the following: we don't use runtime overrides and we use purely Native somehow conditionally loading EVM configuration depending on the block we are tracing.

What about precompiles? Precompiles code is part of the runtime and often needs to be revisited. How it can be managed without overrides?

Regarding what @sorpaas mentioned on using Native executor for Frame extrinsics and selectively switch to wasm execution for the tracing-target Ethereum extrinsic. This is not clear to me, how does it work? Can I create a single overlayed state using multiple executors?

These problems are still not 100% clear to me, and most probably to some others in the community who might want to help. So, further elaboration on them may be helpful.

Using Acala's Approach?

The PR #768 was following the Moonbeam's approach. Does it make sense to use Acala's approach and implement tracing for this repository? If a detailed answer can be given, I think it might foster further brainstorming and possibly a good solution to enable tracing within Frontier.