Home

Child chain that can have subchains

Will basically have implementations of the following contracts:

• File system
• Truebit task contract
• Interactive proofs
• Judge contract (no transaction types needed, called from verification game)
• Plasma child chain manager (same as the current contract, but there can be several subchains)

Some of the public methods do not have to be their own transaction types, but at least the following are needed:

• Add IPFS file (if the file data is added, the blocks would have to include all data from child chains)
• Add code file, can be a part of the block. This will be the task associated with subchain. Part of the subchain creation?
• Owner of subchain submits a block (perhaps only this is needed, and no file stuff?)
• Transaction to a subchain
• Starting and challenging exits
• Exits are processed automatically if they are not challenged successfully
• Perhaps the owner of subchain posts the solution also
• Challenging the new state. Starts verification game
• Transactions needed for verification game

Exiting from subchains

If a parent of a child chain becomes corrupted, the exit procedure cannot be applied for the child chain. That is why the summed balances are stored for the case of exit.

To calculate balances, the task will need all child chain balances as input. The task just has to check that these balances match with subchain balance hashes in the chain.

Map/reduce or smart contracts that run on a tree of chains

Assume that we have a chain that can have subchains as described above, and in addition has support for smart contracts. Let's also assume that all chains in the tree are this type of chain.

Perhaps it is a good invariant that all the smart contracts in the parent chain are also deployed to the child chains.

We can use the method from https://medium.com/@chriseth/token-contracts-on-plasma-or-a-tale-about-local-and-global-invariants-e37fadba150 to limit damages from corrupted child chains.

There are three kinds of messages that the smart contract can receive:

• Normal message from user transaction
• Message from the parent chain
• Message from the child chain

The smart contract can also send messages to the parent chain or child chains. Then it can also wait for messages, this will block the smart contract execution.

More conservative approach

How to detect if a child chain has sent invalid data? The authority of the parent chain must confirm them. This authority does not necessarily have resources to check them all, though. Perhaps there should be some kind of staking system? Probably won't work because of data availability. The messaging just has to be slow so that corruption will be detected. (Still has the problem that authority of the parent chain is responsible for checking all child chains.) If a child chain was corrupted, it can be restarted from a confirmed checkpoint.