Add externalities for parachain execution

[rphmeier]

All-in-all, this should be pretty similar to the set required for substrate.

• Post message to another parachain ( Parachain execution yields messages to send #96 )
• Upload balance to an account ( now upwards messages Allow parachains to send messages #274 )
• WASM Sandboxing
• Crypto primitives (Ed25519, perhaps blake2 hashing, secp256k1)

Note that there is nothing about reading or interacting with storage. This is because parachains that require storage proofs will import all needed storage as a part of the BlockData which proves validity of the parachain candidate.

[bkchr]

In Cumulus we will require to have the ext_post_message externality + the Substrate externalities.
I would propose that we support "merging" different externalities declarations in Substrate. So, we can have ext_post_message + the Substrate stuff in Cumulus.

For Polkadot validator, I would use the same strategy, but make sure that storage access and anything else we don't want, traps.

[rphmeier]

@bkchr Note that parachains are not executed within the substrate_executor but rather within a separate executor. This issue is about doing the native side of the externalities for that executor.

[bkchr]

Isn't the substrate executor a subset of the parachain executor? I thought that we specified the substrate executor as the one that needs to be supported for running a parachain? (Especially the crypto functions.)

[rphmeier]

We want to emulate most of the substrate externalities in a sandbox.

[apopiak]

@rphmeier
What's the state of sandbox support (and is there an issue tracking it and its dependencies)?

(Edit: is paritytech/substrate#9354 a blocker?)

[rphmeier]

Yep, that's a blocker in practice. @pepyakin is better equipped to comment on future support

[pepyakin]

Yeah, I think that issue is the way to go for tracking.

[rphmeier]

outdated