I've noticed that one of main concerns about long-term viability of Bitcoin is scalability: when all transactions are broadcast to all nodes it is simply ...way too much.
Wiki article on the topic (
https://en.bitcoin.it/wiki/Scalability) essentially says that in future we will have faster computers, but many would say that it is not an acceptable solution because in this case Bitcoin won't be truly P2P anymore because only large, expensive nodes will be able to handle the load. And so there are talks about 'collusion problem'.
Another voiced concern is that
http://blog.ezyang.com/2011/06/bitcoin-is-not-decentralized/ there is no straightforward update mechanism for the case when something goes awry...
As I'm generally curious about distributed/p2p protocols/algorithms I've tried to think of a possible solution for this problem(s), and I've got an idea which at least on surface looks viable. Here is it (or, rather, a thought process):
While block chain structure is a 'difficult' object from scalability perspective, it is best we have now (unless somebody will find a method to prevent double spending with DHTs, for example), so let's consider more scalable bitcoin-like systems which still use block chains.
There are two possibilities: 1) somehow make blocks smaller; 2) apply divide&conquer strategy.
First option was discussed in the wiki article on scalability and it looks like possible improvements are limited.
So let's consider possible divide & conquer opportunities.
If we could somehow split block chain among nodes... that probably won't solve anything because we still need blocks to verify transactions. (Although, maybe, some blocks are very rarely used? Then there is a possible improvement, but probably a relatively small one.)
The only other possibility is to have many chains each of which incorporates a disjoin set of transactions. Then size of each individual chain will be smaller than of a large chain and this solves the problem: if nodes are overloaded then we just need to spawn more chains.
There is a problem, though: interoperability. Multiple independent chains are much less useful than one chain.
Can we achieve interoperability while still having many chains?
One solution is to allow transactions between addresses belonging to different chains. Let's say we have address foo123 belonging to chain foo and bar456 belonging to chain bar. When money is sent from foo123 to bar456 it is recorded in both foo123 and bar456 block chains. Chain foo can verify transaction on its own. Chain bar can use a simplified verification mechanism on chain foo to make sure that transaction is valid (foo123 has money).
This means that nodes of each chain need to be able to run simple verification on transactions of each other chain. This is better than nothing as it reduces amount of information required by each not, but still doesn't scale very well.
It looks like "each to each" part causes problem. What if chains would not exchange directly but instead would use a 'hub' chain?
This is my idea. More detailed description:
Let's say we have arbitrary number of 'numbered' chains (chain1, chain2 ... chainN, collectively known as chainZ) and one 'hub' chain. Each individual block chain has a distinct address space (e.g. an addresses are prefixed by chain name, e.g. chain1-XXX) and can do transactions just like Bitcoin chain does it now.
Chains cannot exchange between each other, but they can exchange with hub. So transactions chain1-XXX -> hub-YYY and hub-YYY->chain1-XXX are allowed.
Of course both hub and chainZ need to be able to verify these interop transactions.
For chainZ it is simple: each node of chainZ needs to keep track of a hub's block chain. Then it can verify transactions coming from hub addresses directly. Presumable size of chainZ + hub << size of all chainZ.
For hub it is more complex. Ideally each hub's node needs to keep track of ALL chainZ, at least in 'simple verification' form. But if it is not feasible it can track only some chainZ (or none of them, only hub).
In this case if miner tracks chain1 and chain2 but not chain3 he can include only transactions from chain1 and chain2 addresses but not from chain3 in blocks he mines. So there is an incentive to track as many chains as possible.
I'm not quite sure this 'optional verification' is sound, let's for simplicity assume that each hub node tracks all chainZ at least in scope of simplified verification.
Obviously, hub's nodes are much more strained than chainZ nodes. Then they can justify higher transaction fees.
And thus users have incentive to keep their money in one of chainZ but not in hub to keep fees low. This also means that they need to trade within a single chain.
This shouldn't be a problem because client software can easily work with multiple chains. For example, if customer has money in chain3 merchant can allocate a new address in chain3 and handle transaction. Then he will create address in a different chain for a different customer. He only needs to move money between chains only if he needs collect a large sum in a single address.
As for 'chain strength', miners can include hashes of blocks in other chains in their blocks: chainZ will include hub's block's hashes and hub will include hashes of all blocks. This cross-signing will make it about as strong as one single chain.
And, finally, this solves a problem with protocol updates: each chain can run a somewhat different protocol! If, say, chain5 has some undesirable properties people will move their money off chain5 via hub, so eventually it will be fully abandoned. Then, maybe, some super-secure chain15 will appear and people will move their money to this new chain. Upgrading hub is more problematic, but not impossible. (It would mean a short-term disruption of interoperability.)
Oh, and chains can be added dynamically through consensus of hub's miners. (Likewise, hub can be upgraded through consensus of chainZ.)
Thoughts?
