I'm adding "module linking" support to Scout. Some of this was previously discussed at ewasm/design#17.
To be clear, here I strictly mean runtime linking, where a libraries' are created as separate instances and their exports are imported in the calling instance (in our case an EE). Because they have separate memories, we must consider some options to pass data around. Two potential solutions are described here: ewasm/design#181 and ewasm/design#198.
In order to describe available modules I'm thinking about the following simplistic fields extending the YAML file:
libraries:
- name: "keccak"
file: "keccak.wasm"
- name: "bignum"
file: "bignum.wasm"
Every execution script listed in the YAML will have these preloaded and made available to them.
Complete example:
beacon_state:
libraries:
- name: "keccak"
- file: "keccak.wasm"
execution_scripts:
- phase2_helloworld.wasm
shard_pre_state:
exec_env_states:
- "0000000000000000000000000000000000000000000000000000000000000000"
shard_blocks:
- env: 0
data: ""
- env: 0
data: ""
shard_post_state:
exec_env_states:
- "0000000000000000000000000000000000000000000000000000000000000000"
I'm adding "module linking" support to Scout. Some of this was previously discussed at ewasm/design#17.
To be clear, here I strictly mean runtime linking, where a libraries' are created as separate instances and their exports are imported in the calling instance (in our case an EE). Because they have separate memories, we must consider some options to pass data around. Two potential solutions are described here: ewasm/design#181 and ewasm/design#198.
In order to describe available modules I'm thinking about the following simplistic fields extending the YAML file:
Every execution script listed in the YAML will have these preloaded and made available to them.
Complete example: