Welcome
While CKBytes are a well known and important concept to every CKB holder (hopefully!), there is a powerful nuance to the existing cell data structure that hides in plain sight.
It was first noticed in 2018 or 19 by a prolific researcher/early contributor to the ecosystem and has since been discussed at various times in the community (shout out to @phroi who has entertained this conversation).
It goes like this:
1 CKB is needed to store 1 byte of data in the cell, however the capacity field (amount of CKB) itself can have up to 8 digits after the decimal (or 100,000,000).
If we operate in the binary space, this converts to 26 bits of information (a value up to 67,108,863) that can be stored before rolling over to the next CKByte (because one more bit will roughly double the max value to 134,217,727)
This 26 bit field can effectively function as another cell field available to developers (in addition to the data, type and lock script fields)
Digging In
I can already tell that some readers would think this is completely unreasonable and hacky, placing an inordinate burden on developers, but I implore you to consider the power of expanding the capability currently available on mainnet today.
Importantly, this field is independent of type, lock and data fields, allowing it to specify considerations about the cell without impacting functionality.
A simple example would be storing an offset value relating to cell data, which could be used across applications to understand what the cell data consists of.
I am certain there are many more ideas to be found.
There is a interesting nuance that a user must hold additional CKB to store this information. For example storing 62.00000001 will require owning less CKB than storing 62.12345678
Words to close
In my personal judgement, the experiences of Bitcoin vs Ethereum have shown that hacky options can have merit. Artistically, constraints lead to beauty, creativity is channeled into a finite and universal domain, often leading to mind-bending surprises in what is possible (just look at BitVM!)
Conversely, when creativity is applied to modifying constraints, it seems to lead to shared discontent with the status quo and an environment in which change is the subject of action.
Ethereum has shown us that consensus changes seem to lead to more consensus changes, which in turn lead to more consensus changes… and so on… and slowly the idea gets normalized and the consensus changes become ever more ambitious, with less being enshrined or untouchable.
There may be an additional lesson here that creativity within a paradigm is positive sum (we are working on solutions we can share) versus creativity to modify a paradigm is zero sum (my idea vs your idea).
Negotiation between the architectural view and application developer view will be constant and ongoing, looking forward to discussing more.
Before they start knocking down my door, this is where we discussed it: