If the token contract is made now on what will be the main chain, but long term it is desired for the application to run within a shard, will the tokens ever be able to be sent there?

The map of addresses to balances could hold an address within the shards address space and give them an allowance. But for the contract within the shard to withdraw the tokens it would have to interact with the contract on the main chain, will that be possible?

Is the solution to add functionality to the token contract before it is created on the main chain now which allows it to be destroyed, then at some point in the future copying it and all its state to a shard and destroying it on the main chain so they can actually be used?

  • This is an interesting question. I'm very interested in the answer. – Thomas Jay Rush Feb 14 '18 at 2:08
  • This sounds more like a description of what happens with side-chain processing such as a Raiden or Plasma; is this what you're referring to? My understanding of the sharding implementations being considered is that there is no special "main chain" (except to distinguish it from, say, Ropsten) -- the main chain is the current chain, but the processing of transactions is divvied to multiple validator groups (i.e., they're all operating on different subsets of the same chain). – lungj Feb 14 '18 at 6:38
  • I believe in the first version there is a main chain which hosts the validator manager contract, with possibly only a single shard initially to make it a little easier. – ayeayeron Feb 14 '18 at 20:46

I expect that you'll still be able to send tokens via smart contracts and Ether to any address on any shard with cross shard transactions:

The usual way that cross-shard transactions are conducted is simple:

  1. An operation on shard A creates a receipt on shard A (note: receipts are calculated as part of the state calculation process, so think of receipts as being kind of part of the state)
  2. The receipt on shard A gets confirmed
  3. An operation on shard B incorporates a proof that the receipt on shard A was confirmed, and performs some execution based on this.

However, there is a risk: what if, after this happens, shard A has a large reorg (ie. many blocks get reverted) but shard B does not, and in the new main chain of shard A the original receipt no longer exists? Then, you have a “dangling effect” in shard B without a cause, which is very dangerous and could lead to things like money being created out of nowhere.

We could simply have the reorg on shard A trigger a reorg on shard B, but that would be dangerous as it would be a DoS vulnerability: a small number of attackers reorging shard A could conceivably reorg every shard, if there is much cross-shard communication going on. The “dependency cone” of A will likely grow quickly. To prevent this, we can only go for the dumb solution: wait for the receipt on shard A to finalize, so that reorgs are simply not possible.

But separating state execution gives us another way out: if shard A does a reorg, then we don’t reorg any transactions on shard B, but rather we simply let the executors recalculate the state roots. Any operations on shard B that actually do depend on activity on shard A would have their consequences reorg’ed, but any operation on shard B that is not part of the dependency cone of the receipt would be left alone. Furthermore, it should be possible to calculate ahead of time that some operation on shard B is not part of the dependency cone of something in shard A simply by looking at the access lists of transactions (the access lists would be extended so that transactions can also access historical receipts on other shards), and so users would have private knowledge that their operation on shard B is safe and sound without waiting for confirmation from the global state root. With this kind of approach, we could allow cross-shard transactions to happen very quickly, possibly even allowing transactions to reference receipts from the most recent collation in some other shard.

Additionally see:

Note that addresses in shards are prefixed by a shard ID.

Your Answer

