Over time I examined both the solutions offered by Jan:
B.i Spawn/Exec output locks associated with types
It is a good solution only when designing from the ground up lock and type to work together.
That said, it lacks adoption and back-ward compatibility with all existing type scripts. Given this, we cannot design a general lock around such assumption.
B.ii Create a meta type to spawn sub-scripts
I would love to work full-time on this meta-protocol, so I spent quite a bit of my time on this and it could solve a lot of inconveniences when working on L1. For example, we could potentially move from:
a. Data is what can be deserialized from cell data
to integrate natively SSRI(-alike) method calls:
b. Data is what SSRI(-alike) method returns as data
sUDT/xUDT are the classic example of a. Issue is that said we cannot express within such protocol cells that have a UDT value, but cannot be themselves UDTs, for example iCKB Receipts/Deposits. With b it would be pretty easy actually. So potentially a big step forward, very expressive and very composable (within the protocol).
That said, as a friend put it bluntly: it’s a stretch of the imagination.
The first issue when designing such protocols is the amount of information contained in these higher level cells is non-trivial. Potentially each sub-type would need to record some metadata: capacity/originatingOutpoint/inclusionBlock… Additionally, since we are indeed aiming for higher level compos-ability it could be possible to drop molecule altogether to move to a more descriptive standard.
All this brings up the cell size and beg the question where do we want to store such cells data:
- We cannot strictly depend on L1 for storing lots/complex of data (CKB future price volatility)
- We cannot strictly depend on witness for availability (until witness life-cycles can be economically well defined)
So the design of such meta-protocol gets pretty complex pretty fast as it should be able to:
- Accept off-chain data without depending strictly on its source
- Be able to independently verify its authenticity (has this data the right signature?)
- Be able to verify its mapping to cells outputs (is this data actually of that tx output?)
Issues with relying strictly on witnesses for long-term data availability:
- No incentive model: no native fees or rent to reward nodes for storing witness history.
- Unbounded growth: post-quantum signatures and richer proofs will steadily increase witness size.
- Resource strain and DoS risk: large or abusive payloads in witnesses can overload nodes and networks.
- Future retention uncertainty: though pruning isn’t used today, nodes may drop old witnesses later to manage state growth.
- Inconsistent access: once pruning exists, only archive nodes will retain full witness history.
- Added operational complexity: guaranteeing availability will require parallel archive networks or paid gateways.
Feedback
@xxuejie @janx @Hanssen @matt_ckb what are your thoughts on all this?
Love & Peace, Phroi %94