Wasm Executor local-blob overwrite

[gnunicorn]

Our Wasm Executor should allow us to specify a set of wasm blobs to run instead (or aside) of the on-chain specified one.

Background

When working on being able to collect state tracing (ref #6916 ), we've quickly come to the conclusion that only a wasm-based approach would actually be future and backwards compatible. But there is no way we can retro-actively fit the existing canon-wasm-blobs on the chain (e.g. polkadot) with tracing. The only reasonable way to do that is to backport the changes to the older runtimes and build an alternative wasm-blob that should be run instead.

This also makes this future proof: as the tracing is an additional burden on the runtime, we will not build it in by default but instead ship two wasm-binaries: one with and one without tracing. The one without tracing will become the canon on-chain one, the other is an optional feature certain nodes – like for debugging or archive – can use to extract extra information. In order to be able to do that, the executor must allow us to provide an alternative wasm-blob per each runtime-version.

Approach

Easiest would probably be if we had another CLI-argument --wasm-runtimes-overwrite PATH_TO_FOLDER (and default being $BASE_PATH/$chain/wasm_runtime_overwrites). When given that argument, the folder is scraped for wasm-blobs at the start and they are loaded into the executor, matching for runtime_version they provide on-execute (log the path and versions found, warn on mismatches or overrides). When the executor is now asked to run a wasm at a certain block, it should check that runtime_version to figure out whether it has an overwrite for it. In case it does, it should run the overwrite.

Additional enhancemens

• notice when a new file was dropped into the folder and live-load that, too
• rather than overwrite, run the canon and the local one in parallel and warn/error on differences in state root or alike

[xlc]

This will be part of #2082

[bkchr]

Actually it is the same. @gnunicorn maybe you could post your ideas about the folder structure idea there and close this.

[gnunicorn]

I agree there is overlap and also that what is described here might be sufficient to implement the high-level-features requested there, but from what I am reading they are distinct in that this has a more narrow focus and thus is a bit more confined, and as I result, to me, this here seem more achievable and simply less work. I don't mind merging them but don't want to delay the specific thing here for something with a much wider scope and feature-list. I also don't mind having a PR that closes two issues. Would leave it up to @pepyakin to decide whether this is to be considered a duplicate.

[bkchr]

You don't need to close an issue with a pr. You can have an pr that works towards a given issue. Which will be done by the pr for this issue.

[pepyakin]

The original proposal would actually encompass something like what @gnunicorn writes about here. In a nutshell, the main points were about re-executing blocks or extrinsics with code that is different. There are numerous use-cases that has been discussed within this framework: debugging and tracing the existing code, running data analytics, querying the historical non indexed blockchain data (i.e. reconstructing different state) from it.

Alas, the original issue didn't go too far in actually specifying how all that would work neither it got enough attention to actually get implemented.

I don't have a strong opinion on how that should be implemented. But, FWIW, I proposed it in the way of an RPC call because it seemed to allow to implement a sheer variety of use-cases by implementing those off-process.

For example, given an archive node, if we wanted to run some tracing across all blocks, we can get all finalized block hashes and re-execute a modified runtime against them. At the same time, reusing the same node, we could get diagnostic (incl. tracing) information from something from the tip of the chain.

As long as we don't introduce a primitive for each use-case it should be fine

[pepyakin]

Seeing the #7317 I see that in the end the decision was to go with the solution outlined in the original post.

Just for the record, was there any further discussion for this and if so what were the points?