Correct.
drcode1:
Also, why is it not preferable to just use Merkle proofs for cross-shard transfers directly, with single balances for the EE maintained on each shard? (instead of merkle proofs for inter-EE transfers)
This requires either a bitfield mechanism (which essentially veers into another enshrined UTXO model with complexity on its growth), or a queue/nonce model to prevent replays. These discussions are found here:
One of the requirements of phase 2 is the ability to move ETH quickly from one shard into another shard. Though cross-shard transactions in general are possible through application of the usual receipt mechanism , with the protocol itself needing only to provide access to each shard’s state roots to each other shard, cross-shard ETH requires a little more enshrined in-protocol activity. The reason for this is that we need to keep track of how much ETH there is in each shard, and we need an enshri…
In general, the way that tokens are handled on a sharded blockchain is through accounts and receipts that exist inside of execution environments. That is, a token is something that exists inside of an EE, in the form of account balances on different shards that have units of that token. On shard A, Alice might have 50 ExampleCoin (EXC) and Ashley 70 EXC, on shard B, Bob might have 40 EXC, etc, and these are all represented as leaves in the EE’s state tree.
[Untitled%20Diagram]
Alice transferri…