Upper size limit of CKB

RFC-15 state that 1 CKB is precisely 1 byte of information stored by a cell. Also, the supply aims to ~30B tokens.

Do I correctly understand that currently, the blockchain theoretical bound is ~30GB of data and practical (~30% of stake) is around ~10GB? Hence, if the average size of the cell is around 1KB, then the blockchain practically bounded to 10M cells only? Am I missing something? Or it’s a purposeful design decision?

I am also curious, does this a hard social consensus? Or if there is a plan to govern the number of bytes the one can get for 1 CKB?

You can check this one first:

For right now the basic size of a Cell is 61 CKByte, so we can contain many users right now. And for a UDT(User Defined Token) cell, it would be 100+ CKByte, but you can use this cell to store a large number of one UDT.

And we believe that the most important thing about layer1 as a global consensus is that it is decentralized and secure, which means it will be slow and expensive. For smaller transactions and partial consensus can be implemented with infinitely expandable layer2.

Am not saying that this bound is bad :slight_smile: On the contrary, I think its brilliant idea. This gives ability to run the blockchain in mobile and robots. I just want to have precise mental model of capacity.

Imho its not entirely correct to perceive CKB as the storage for balances only. Libs and code is the best use case and this will rise the average cell size significantly.

In general the answer is yes.

The upper bound of state size for now is ~10GB. Given the numbers of initial supply and primary/secondary issuance, the theoretical upper bound of state size will reach 100GB (including NervosDAO) after ~30 years. The ratio between CKB (actually it’s CKByte) and an actual byte on disk is fixed, 1:1.

Full node on mobile and robots is one reason for the bound and parameters. As storage technology advances 100GB will eventually be a piece of cake for mobile even IoT devices. A bounded state size is also good for value capturing as stated in RFC0015.

I agree :-).