Bitcoin Forum
December 02, 2016, 06:12:43 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Scalability by splitting the master chain and joining branches back  (Read 654 times)
Hans0
Member
**
Offline Offline

Activity: 91


View Profile
June 05, 2011, 06:18:41 PM
 #1

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?
1480702363
Hero Member
*
Offline Offline

Posts: 1480702363

View Profile Personal Message (Offline)

Ignore
1480702363
Reply with quote  #2

1480702363
Report to moderator
1480702363
Hero Member
*
Offline Offline

Posts: 1480702363

View Profile Personal Message (Offline)

Ignore
1480702363
Reply with quote  #2

1480702363
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480702363
Hero Member
*
Offline Offline

Posts: 1480702363

View Profile Personal Message (Offline)

Ignore
1480702363
Reply with quote  #2

1480702363
Report to moderator
bittrader
Jr. Member
*
Offline Offline

Activity: 42



View Profile
June 05, 2011, 06:31:56 PM
 #2

- 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
Hero Member
*****
Offline Offline

Activity: 504



View Profile
June 05, 2011, 07:03:09 PM
 #3

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.

1AAZ4xBHbiCr96nsZJ8jtPkSzsg1CqhwDa
Hans0
Member
**
Offline Offline

Activity: 91


View Profile
June 05, 2011, 07:39:52 PM
 #4

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.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!