Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: Reducing Lightweight Storage Requirements  (Read 372 times)

0 Members and 1 Guest are viewing this topic.

Offline indolering

  • Newbie
  • *
  • Posts: 15
    • View Profile
Reducing Lightweight Storage Requirements
« on: May 06, 2015, 08:16:41 PM »

Let me preface this by saying that I have only a fairly high-level understanding of blockchain mechanics and I'm pretty sure this is a dumb idea and I'm positive that it's not original.  I'm mainly asking to figure out what I don't understand.

Ten second block times drastically increase the storage requirements for header based lightweight clients (think SPV).  The storage estimate for Namecoin's lightweight, name-only resolvers is ~100 megabytes.  But Namecoin produces a block every 10 minutes, a naïve calculation indicates that BitShares would require 60x more storage, or around 600 megabytes. 

But then I got to thinking: why don't we just produce a meta-block that includes all of the transactions for a given period?  You could produce a meta-block every 10 minutes or every hour.  You could even continue to receive regular blocks every 10 seconds but only store the meta blocks. 

Offline Ander

  • Hero Member
  • *****
  • Posts: 3507
    • View Profile
  • BTS: Ander
Re: Reducing Lightweight Storage Requirements
« Reply #1 on: May 06, 2015, 10:34:30 PM »
I remember Bytemaster posting that every 101 blocks (1 per delegate, thats just over 15 minutes) acted like a snapshot.  Would this be similar to a 'meta-block' that you are talking about?  At ~15 minutes each it would be similar to Namecoin.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline vikram

Re: Reducing Lightweight Storage Requirements
« Reply #2 on: May 06, 2015, 10:36:46 PM »
What is the exact use-case you are considering? Is it not sufficient to receive a signed statement from a quorum of delegates for the particular data that you are interested in?

Offline pc

  • Hero Member
  • *****
  • Posts: 1034
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BTS: cyrano
  • Witness: cyrano
  • Payrate: 100%
Re: Reducing Lightweight Storage Requirements
« Reply #3 on: May 07, 2015, 06:23:49 AM »
There is a fundamental difference between BTC transactions and BTS transactions that removes the need to store the blockchain in a lightweight client. BTS transaction "inputs" are withdrawn from "balance ids" which act like some kind of public ledger. In order to verify a transaction the client must know the state of the public ledger. The client can track the state of the ledger by applying the transactions from incoming new blocks. Afterwards, the blocks can be discarded (they may be retained for a limited time to facilitate switching between forks).

The resulting ledger size is independent from the size of the blockchain and the time span between blocks.
Please vote for my BitShares witness "cyrano" and for my STEEM witness "cyrano.witness"!
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline bytemaster

Re: Reducing Lightweight Storage Requirements
« Reply #4 on: May 07, 2015, 12:38:46 PM »
There is a fundamental difference between BTC transactions and BTS transactions that removes the need to store the blockchain in a lightweight client. BTS transaction "inputs" are withdrawn from "balance ids" which act like some kind of public ledger. In order to verify a transaction the client must know the state of the public ledger. The client can track the state of the ledger by applying the transactions from incoming new blocks. Afterwards, the blocks can be discarded (they may be retained for a limited time to facilitate switching between forks).

The resulting ledger size is independent from the size of the blockchain and the time span between blocks.

To be fair you can do the same kind of accounting / discarding with Bitcoin. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline indolering

  • Newbie
  • *
  • Posts: 15
    • View Profile
Re: Reducing Lightweight Storage Requirements
« Reply #5 on: May 08, 2015, 07:35:05 PM »
What is the exact use-case you are considering?

Lightweight, name-only resolvers for DNS.  I'm not sure if the "name only" part has the same ramifications for BitShares as Namecoin, but since purchasing a domain destroys the currency in both models I'm assuming that it means that a BitShares name resolver will not need to worry about double spends either.

Is it not sufficient to receive a signed statement from a quorum of delegates for the particular data that you are interested in?

I remember Bytemaster posting that every 101 blocks (1 per delegate, thats just over 15 minutes) acted like a snapshot.  Would this be similar to a 'meta-block' that you are talking about?  At ~15 minutes each it would be similar to Namecoin.

Like I said, I posted this because a few things didn't make sense.  When I asked around about the BitShares lightweight client I got the impression that it was a trusted server model ... which I didn't understand given that you could rely on a quorum.

While a lightweight client wouldn't want to have to tally the votes to figure out who a valid delegate is, I would assume that you could bootstrap new delegates by including a proof of some kind in each block.

Sorry for the basic questions.  I did some light googling, but I didn't see much on BitShares specific lightweight clients.  Is there a blog article I'm missing?

Offline bytemaster

Re: Reducing Lightweight Storage Requirements
« Reply #6 on: May 08, 2015, 10:42:56 PM »
What is the exact use-case you are considering?

Lightweight, name-only resolvers for DNS.  I'm not sure if the "name only" part has the same ramifications for BitShares as Namecoin, but since purchasing a domain destroys the currency in both models I'm assuming that it means that a BitShares name resolver will not need to worry about double spends either.

Is it not sufficient to receive a signed statement from a quorum of delegates for the particular data that you are interested in?

I remember Bytemaster posting that every 101 blocks (1 per delegate, thats just over 15 minutes) acted like a snapshot.  Would this be similar to a 'meta-block' that you are talking about?  At ~15 minutes each it would be similar to Namecoin.

Like I said, I posted this because a few things didn't make sense.  When I asked around about the BitShares lightweight client I got the impression that it was a trusted server model ... which I didn't understand given that you could rely on a quorum.

While a lightweight client wouldn't want to have to tally the votes to figure out who a valid delegate is, I would assume that you could bootstrap new delegates by including a proof of some kind in each block.

Sorry for the basic questions.  I did some light googling, but I didn't see much on BitShares specific lightweight clients.  Is there a blog article I'm missing?

You can always use a quorum of delegates....
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

 

Google+