Pages:
Author

Topic: Bitcoin addon: Distributed block chain storage - page 2. (Read 3335 times)

sr. member
Activity: 280
Merit: 257
bluemeanie
Hi. I am brain center of DIANNA Project Smiley Actually my project had stuck on future scalability problem. DIANNA needs easily accessible Bitcoin block chain indexed by block hash and transaction hash.

This is very big problem for local computers - its a [giga|tera|peta]bytes of data being constantly read.

I know Bitcoin community also have worries about Bitcoin database size and its load in future.

I think we may solve this problem together once and forever.

What do I need is to design and implement distributed, redunant, DHT-like (HASH=[block/transaction body]) storage for Bitcoin. Each network participant will store some piece of block chain and respond for inbound queries.

As benefit for most network participants - there will be no need to store 100% of data locally and read 100% of data locally. Each will serve his own piece of chain. And as network will grow, storage size/read capacity will also grow.

I think it is okay to put blocks bodies to DHT-like storage a leave only block headers locally as trusted chain skeleton.

I have no expirence with C and DHT. Could someone participate with this? I can sponsor this task. And if community need this feature, other sponsors welcome.


It's probably possible to store blocks in a DHT with some kind of reasonable response time.  These structures are designed to store data of this capacity.

For many applications though, you need to keep a copy of the block in local storage so you can validate the chain, thus there is a good probability that the block is available at a given node.  From here you need to determine 1) how to locate the block efficiently 2) which node is appropriate to poll- for instance balancing the load on all nodes that have a given block is optimal.  

It's certainly possible to optimize the basic DHT algorithm, which is designed for general use.  You might also need to implement a broadcast function for the transactions.
legendary
Activity: 2618
Merit: 1006
Isn't bloom filtering already enough for your project? If you need to trust third parties anyways, you could just do a spv client that accesses the chain with bloom filters if it needs specific transactions. This already is implemented in bitcoin-qt
sr. member
Activity: 462
Merit: 250
Clown prophet
Yes, I think it will need to adapt some existing DHT solution with custom modifications for redunancy and storage filter (it should store only some part of chain listed in local headers plus some small percent of arbitrary orphaned blocks/transactions)
newbie
Activity: 46
Merit: 0
Why not adapt existing solutions for this? Plenty of distributed key-value storage software is freely available. Is there some special requirement in your case that is not satisfied?
sr. member
Activity: 462
Merit: 250
Clown prophet
No. This should be custom DHT implementation in untrusted network.

Each client should store some number of blocks from his local headers - not arbitrary data.
hero member
Activity: 826
Merit: 1001
Sounds like a nice job for http://hadoop.apache.org/ ?
sr. member
Activity: 462
Merit: 250
Clown prophet
Hi. I am brain center of DIANNA Project Smiley Actually my project had stuck on future scalability problem. DIANNA needs easily accessible Bitcoin block chain indexed by block hash and transaction hash.

This is very big problem for local computers - its a [giga|tera|peta]bytes of data being constantly read.

I know Bitcoin community also have worries about Bitcoin database size and its load in future.

I think we may solve this problem together once and forever.

What do I need is to design and implement distributed, redunant, DHT-like (HASH=[block/transaction body]) storage for Bitcoin. Each network participant will store some piece of block chain and respond for inbound queries.

As benefit for most network participants - there will be no need to store 100% of data locally and read 100% of data locally. Each will serve his own piece of chain. And as network will grow, storage size/read capacity will also grow.

I think it is okay to put blocks bodies to DHT-like storage a leave only block headers locally as trusted chain skeleton.

I have no expirence with C and DHT. Could someone participate with this? I can sponsor this task. And if community need this feature, other sponsors welcome.
Pages:
Jump to: