Phase 2 execution prototyping engine (Ewasm Scout)

[axic]

Thanks for the response!

@matt

Therefore in the relayer runtime there should be a way for retrieving and saving the modified state, but not in a shard node.

Exactly. And the script needs a way to expose the modified state. The shard node can ignore it. I may need to explore one implementation as part of writing the “deposit manager”.

@matt

I definitely agree with providing a single implementation of these, but I would argue that it would be better to provide them as another execution scripts – aka wasm precompiles.

Please have a look at the “system libraries” tag on the Ewasm design repo. We use the term quite liberally. In short, the idea would be to specify a standard interface for the ones I’ve suggested and provide a wasm implementation of them. They can be dynamically linked or the node can decide to natively implement (some of) them and link against those.

The speed and overheads are yet to be discovered and real decisions cannot be made without benchmarking. For the time being likely whatever is easier for the given case will be done and we can iterate on that.