Scalability by splitting the master chain and joining branches back

[Hans0]

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?

[1714911313]

1714911313

[1714911313]

1714911313

[1714911313]

1714911313

[bittrader]

- Transactions appearing in any branch are valid just like now a transaction in the main line. All branches are equal

So to verify that a given transaction is valid, you'd have to have access to all the block chains. But if you have to have all the block chains, doesn't it defeat the purpose of having multiple chains?

[realnowhereman]

I don't think it would be a good idea, but an equivalent of git's "merge" function would be technically possible.

The merge operation would require that there be no conflicts on the two branches.

I think it would make the verification a bit too complicated, but it's certainly not impossible.

[Hans0]

I guess there are still a few questions unanswered but the main idea of increasing parallelism when under load and reducing overhead when the load is gone seems to be good. In addition we probably need a way to prune history.