CKB is different from other blockchains, since keeping sUDTs in a cell, would also has CKB storage requirements. This has been a quest to us for a while, several different solutions have all been proposed. Each of them has its merits and drawbacks. Yet there is still use cases that cannot be fulfilled quitely here.
Lately there has also been a development in Sparse Merkle Tree on CKB. We’ve seen its use case in a few areas, and how it can help ensure constant space requirements on variable length data in CKB. And this brings an idea: what if we bring SMT to sUDT to solve the storage requirement?
We can design a compact sUDT cell like following:
Lock: <compact sUDT lock>
Type: sUDT type script
Data: <16 byte sUDT amount> <32 byte SMT root>
At a glance, this looks exactly like a typical sUDT cell, except from the 32 byte SMT root. The SMT root, actually keeps track of a balance sheet for different users holding the tokens. For example, a compact sUDT cell with 100 sUDTs, might keep a balance sheet like following:
| Owner | Amount |
|---|---|
| Alice | 21 |
| Bob | 33 |
| Charlie | 56 |
One potential use case here, is exchanges: an exchange might generate one or more compact sUDT cells per sUDT type, those compact sUDT cells, can perfectly handle withdraws: when a user withdraws from a centralized exchange, the exchange only needs to modify the compact sUDT cells with updated records. For example, if Alice withdraws 50 sUDTs, the exchange uses a compact sUDT cell exactly like the above, the cell only needs to be updated so Alice has 71 sUDTs, 50 new sUDTs will also be transferred to this cell.
If, for example, Bob wants to withdraw from the compact sUDT cell, Bob can generates a transaction by proving his identity, compact sUDT lock can thus validates Bob’s identity, checks SMT balance, and either accepts or rejects Bob’s withdraw attempt.
This way, we have a proper sUDT cell which can hold numerous balances, but constant storage requirement. In a way, we can think of this as an extension of Approve Cell, instead of holding the balances for one user, you are holding the balances of many users at once.
Cell Contention
Of course there might be a contention for cells, one might tries to deposit, while another tries to withdraw. And chances are they all try to consume the same compact sUDT cell, which will result in contention. But another way of thinking this problem, is that a compact sUDT cell is a perfect use case, for an open transaction design. No matter if you are depositing or withdrawing, the full transaction is never required, people can just provide the parts they care and need, then a miner-style agency, can then piece the full transaction together for CKB to then process.
xUDT
You might have noticed that I intentionally leave out one question: who is gonna validate the SMT proof logic? Assuming I now deposit 10 sUDTs to a compact sUDT cell, what’s preventing me from granting me 100000 sUDTs in the balance sheet? Turns out for an sUDT, there might not be a good place for such logic, but for xUDT, the validation logic can be perfectly kept in an extension to the standard spec. So compact sUDT cell might not be a real thing, but compact xUDT cell is.
Next
This is all just some rough idea, I really don’t know if such a thing makes sense, or what to do next, or if there is a real need for a compact xUDT cell. Any type of comments are welcome.