Author Topic: Blockchain size projections  (Read 2777 times)

0 Members and 1 Guest are viewing this topic.

Offline vikram

Re: Blockchain size projections
« Reply #15 on: February 05, 2015, 12:51:21 am »
Sounds doable (maybe one day..); but note that the full state is still not bounded (nor has it been partitioned) so delegate resource requirements will still keep growing. Whether the growth will be fast enough to be a serious problem--I don't know.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Re: Blockchain size projections
« Reply #16 on: February 05, 2015, 01:36:31 am »
Sounds doable (maybe one day..); but note that the full state is still not bounded (nor has it been partitioned) so delegate resource requirements will still keep growing. Whether the growth will be fast enough to be a serious problem--I don't know.

Sure the database state still grows. But that is to be expected when our community is growing! Every new account registration and asset registration is going to grow the database. But I think reasonable bounds will exist: there is only a limited number of accounts people will want (and there is only a finite number of people on this planet), and if not that means our account registration fee is too low; there is probably some reasonable bound on the number of unique balances each account will have; there are reasonable bounds to the number of orders in any given order book (individuals will split their orders to a fine price granularity only up to a limit, and typically only for orders at prices within a few percentage difference from the current price); asset registrations are hopefully bounded to a sensible number by the fees needed to register them. So I don't think of the database as growing indefinitely with time but rather growing proportionally to user adoption (and there is a point where adoption has to saturate).

And obviously the database shouldn't store anything that grows with time rather than adoption (such as various histories of price feeds, trades, etc. or previously defined delegate slates that are no longer used), at least not for more than some limited window of time. Those things could be useful or even necessary to store in a cache database (and perhaps that cache database should be in the Merkle Patricia tree so that even light wallets can access it), but since it is a cache focused on a limited moving window of time, it would still be bounded in size as the old, unnecessary data is progressively garbage collected.

And certainly expiring balances would help with this. That is another reason I prefer the expiration fee that seems to no longer be of interest. It clears out all those balances that are probably never going to be used (due to lost private keys) but would indefinitely take up space in the database.
« Last Edit: February 05, 2015, 01:39:35 am by arhag »