# Netted balance maps for cross-shard transfers * An explainer for dummies (hopefully easier to follow than the original post, which took me a week to understand: https://ethresear.ch/t/an-even-simpler-meta-execution-environment-for-eth/6704) * update 2020-1-23: an edited version of this was posted as a reply on the thread. ## Intro * we have three shards: A B C * When an EE is deployed, it is exists on all shards. Same code, but a different balance and different stateroot on each shard. * for each EE, each shard maintains a balance map like this: `A: [1, 0, 0]`. * we can visualize the global map as a matrix, but note that it is not maintained in whole anywhere. Rather, each shard maintains one row. ``` A B C A [1, 0, 0] B [0, 0, 0] C [0, 0, 0] ``` * this is the map(s) for an EE with a starting balance = 1 ETH on shard A. ## same-EE cross-shard transfers * same-EE cross-shard transfers are done by updating the map on the sending shard `shard[s1]`; the map on the receiving shard `shard[s2]` is not updated. * in code: `shard[s1].balances[s1][ee] -= xfer_amount` and `shard[s1].balances[s2][ee] += xfer_amount` * in a block on shard A there's a txn that transfers the 1 ETH to shard B (in the same EE). Only the map stored on shard A is updated (Row A), shard B is not aware. ``` A B C A [0, 1, 0] B [0, 0, 0] C [0, 0, 0] ``` * in a block on shard B there's a txn that transfers 1 ETH from B to C (in the same EE). only Row B is updated: ``` A B C A [0, 1, 0] B [0, -1, 1] C [0, 0, 0] ``` * note that the protocol doesn't require any checks for same-EE cross-shard transfers; it is up to the EE to implement checks and ensure that its balance across shards is netted correctly. For example, if a shard's row is all zeros, like Row B was prior to the transfer, then I guess the EE should verify a proof that shard B has a balance in some other row (in this example, shard B had balance 1 in Row A). * But it is no risk to the protocol if an EE doesn't do this correctly, because the protocol requires proofs when transferring from one EE to another. (protocol prevents EE's from issuing new ETH, but doesn't save EE's from accidentally burning or losing their ETH). ## cross-EE same-shard transfers * For cross-EE transfers, the protocol requires proof of an EE's balance across shards ("real balance"). > To perform any transfers of ETH between EEs in a block, the shard must contain a Merkle proof from the most recent state of every shard, showing `shard[i].balances[s][x]` for every shard i to prove the total balance of the EE. ... we check that `real_balance(s, ee_1) >= xfer_amount`. * Take the map from the previous section: ``` A B C A [0, 1, 0] B [0, -1, 1] C [0, 0, 0] ``` * to calculate the "real balance" on a shard, you add up the column. The real balance on shard C is 1, A and B have 0. * to send a transfer to another EE on shard C, you include merkle proofs for the balance map on all shards. This proves sufficient total balance, and sufficient "real balance" on C. ``` AliceEE -before Txn- BobEE A B C A B C A [0, 1, 0] A [0, 0, 0] B [0, -1, 1] B [0, 0, 0] C [0, 0, 0] C [0, 0, 0] ``` * Let's send the 1 ETH we have in AliceEE on shard C, to BobEE on shard C. To perform the transfer, update two maps (AliceEE and BobEE) for the shard we're on. * in code: we check that `real_balance(s, ee_1) >= xfer_amount`, then set `shard[s].balances[s][ee_1] -= xfer_amount` and `shard[s].balances[s][ee_2] += xfer_amount` ``` AliceEE -after Txn- BobEE A B C A B C A [0, 1, 0] A [0, 0, 0] B [0, -1, 1] B [0, 0, 0] C [0, 0, -1] C [0, 0, 1] ``` * This cross-EE same-shard Txn protocol works without coordination across slots (queues, receipts, etc.) because it is isolated from any AliceEE activity that might be happening on other shards in the same slot. Since the "real balance" is on shard C, the only way to do a cross-EE txn is to do it on shard C. The cross-EE txn could fail if a same-EE/cross-shard txn that sends the balance from C back to A, gets included in the block first. But any same-EE/cross-shard AliceEE txns included in shards A and B can be ignored; the worst that could happen is additional netting (-1, +1) entries getting added to the balance map, which won't affect the existing "real balance" on C. [edit]: I don't like this explanation of "without coordination across slots". It is coordinated across slots because the same-EE/cross-shard xfer happens by committing the balance map in a cross-link, and the cross-EE/same-shard also commits the balance maps (for sending EE and receiving EE) to a cross-link.