Currently there is one block chain that contains all transactions. This will become a scalability problem at transaction rates that VISA has (2000tps). To spread the load we could allow a block to split into N child blocks instead of exactly one. That would create multiple chains spreading the load. Multiple chains could be joined if transaction load declines by having a single child block for multiple predecessors. Wo would get a directed acyclic graph (DAG) instead of a linked-list.

We could program clients with the following rules:

- Transactions appearing in any branch are valid just like now a transaction in the main line. All branches are equal
- Miners can split and join chains as they see fit under the following rules:
 * A block has a maximum size of 1MB. If more, then a split must occur
 * The least amount of split nodes must be used to fit the 1MB rule
 * Two chains can only be joined if the 1MB rule is not violated
 * A chain must have at least 1000 blocks before it splits or joins (just like transactions are currently required to "harden")
- We would need to find a way to let every client apply his unit-of-work to as many chains as he likes in order to keep the system scalable and fast

This would balance the load across as many chains as necessary and still keep a single address space - no hub chains or exchange rates between chains required. We only make changes on the "storage layer" of the blocks. Their meaning is unchanged.

Is this feasible?