Scout host functions getShardId(), getShardStateRoot(shardId, offset).

[poemm]

The motivation for this proposal is to allow dapp developers to experiment with cross-shard communication through the beacon chain.

Analogous to how POSIX threads has pthread_self() to identify the thread id, and how OpenCL has get_global_id() and get_local_id() to identify the work item id, Scout EEs may wish to identify which shard they are executing in. I hereby propose a new scout host function getShardId() -> uint32 which returns 0 if called from the beacon chain, 1 if called from the first shard, 2 if called from the second shard, ..., n if called from the nth shard.

Moreover, analogous to how POSIX threads can read from shared pointers to local data, and how OpenCL threads can read from __global or __local pointers to __private data, EEs executing on a shard may wish to read from the beacon chain to local memory. I hereby propose a second new scout host function getShardStateRoot(shardId, offset) -> uint32 which takes as arguments a shard id as described above, and takes a memory offset similar to other scout functions. The host function has a side-effect of writing that shardId's 32-byte state root (see below) at the current time step to the EE's local memory at the offset. If either of the arguments are out-of-range, then it writes nothing. This host function returns 0 unless an argument was out-of-range, then it returns 1.

Now the unspecified part -- we must define what a shard is, define what an EE is relative to shards, define what code is relative to EEs, and define what a shard writes to the beacon chain at each time step. A first attempt follows, but it is incomplete. At each time step, each shard updates its state root to the beacon chain, where the state root of a shard is the 32-byte merkle root of all EEs in that shard. For merkleization, each EE is a leaf which contains the following.

• 32-byte EE address (this needs specification) which corresponds to the Merkle path to this leaf,
• 32-byte Eth balance (same as Eth1 balance),
• 32-byte hash of the code that the EE executes when it is called (this needs specification), and
• the 32-byte state root of the EE (accessed with scout functions loadPreStateRoot() and savePostStateRoot()).
  Merkleization obeys SSZ rules, though it may be wise to allow the user to easily replace the merkleization rule to allow prototyping without depending on SSZ.

Finally, I hereby propose changes to the Scout yaml format to initialize each EE, and to specify shardIds for each execution. This needs discussion.

Concrete use-cases are not yet available.

[poemm]

Prototyped here https://github.com/poemm/scout_wabt.cpp/tree/getShard_host_funcs .

Retrospective: The interface is reasonable. The unspecified part explained above remains unspecified.