Distant future question: Dealing with a multi-TB blockchain

[SteveHere]

As noted in the whitepaper:

Kindelia
Avg. Block Time 1 second
Avg. Block Size 1,280 bytes
State Growth Limit 256 bytes

1280 bytes/block * 1 block/second * 86400 seconds/day * 365.25 days/year = 37.619 GB of block size growth / year

256 bytes/block * 1 block/second * 86400 seconds/day * 365.25 days/year = 7.5239 GB of state growth / year

In the event that Kindelia is adopted en masse, what is the consensus with regards to the eventual TBs of block & state size that will be accrued, or is it assumed (like in the Bitcoin whitepaper) that Moore's Law (or its equivalent in the storage) will render this a non-concern?

[VictorTaelin]

Kindelia's blockchain is precisely small enough for us to assume that it won't be a problem. With ~40 GB per year, it will take 25 years for it to reach 1 TB, which is already affordable today. Do you mean that as "40 GB is too much"? Usually I get the opposite reception, that 40 GB is too little. Increasing to 80 GB or 160 GB would be better IMO, but that would get us above the ~1500 bytes UDP packet sweetspot.

[SteveHere]

It's not that "40 GB is too much", it's that in the case of new nodes wanting to download the entire blockchain, the amount of time needed to download the blockchain (& therefore the state) would grow linearly in proportion to the total blockchain size.

In such a scenario, is there a way to create the Kindelia version of a light client / light node?

[steinerkelvin]

afaik light node capability is incompatible with our cheap state storage operation. we would need the equivalent of a very cheap Merkle tree mutation operation but for Kindelia's VM state.