Is it possible to store the evm-tracing runtimes inside a pallet storage instead of off-chain place?

[boundless-forest]

There are already some discussions #703, #1007 and attempts #768 about how the debug API is implemented in the Frontier framework. The currently most used solution comes from the Moonbeam team(thanks for their hard work), but the solution relies on the offchain runtime overrides files. The network maintainers need to maintain a runtime overrides repo, adding a new dedicated one with tracing feature for each runtime upgrade. The dedicated tracing node needs to be restarted to load the new runtime overrides. I have an idea that if we can store the evm tracing runtime overrides on a pallets, just like what we did when uploaded the runtime upgrade code to the relay chain. Hacking the cli command to add a gate to control which runtime to execute, the one uploaded to the relay chain or the one stored in the parachain pallet. Obviously, the tracing node has to open the gate, while the normal node does not. In this way, the tracing node maintain is much easier than the current workflow.

Any insight on this? @sorpaas @crystalin

[sorpaas]

We can probably just compile the debug EVM pallet, include it in the runtime, and then expose a separate API to invoke it. Because you're including the debugging code on-chain, you'll be paying for the extra storage cost anyway.

We can also just store a hash of the override runtime and then continue with the current workflow.

For compiling a debug EVM pallet, the only problem at this moment is that features in cargo are accumulative (if it's enabled by a dep then it's always enabled). But I'm doing some major refactoring on the EVM engine, and I'll see if it's possible to get something nicer.