Implementing UTXOs as a User Defined Token Using the Cell Model
by Jan Xie
Defining a Token Using Cells
If we want to create a UDT (User Defined Token) called SatoshiCoin, its state transfer has to conform to the following constraints:
1. The user must prove that he or she is the owner of the input token;
2. The amount of input tokens must be greater than or equal to the amount of output tokens in every transaction.
The first constraint can be expressed by a lock script, which is similar to scriptPubKey in Bitcoin. (If you are interested in this, you can view the sample code here.) The second constraint is hard-coded into the underlying architecture of Bitcoin, but in CKB is implemented by a Cell’s type script.
The amount of SatoshiCoin “held” in a Cell is a kind of state. It’s structure is defined by the type as a string of 8 bytes saved in the data of a SatoshiCoin Cell, and the ‘amount’ is a serialized integer stored in those 8 bytes:
{
“amount”: “Bytes[8]”// serialized integer
}The type script can contain all of the logic that governs a user’s newly-defined type. We want SatoshiCoin to verify transactions like Bitcoin does, so the type script will need to be executed on all of the Cells that are used as input to a transaction (remember the CKB changes state by destroying Cells and making new ones). The type script can be made to contain logic that guarantees that the newly-created Cells that replace input Cells are not minting new SatoshiCoin.
The sample type script code attached looks at all SatoshiCoin cells when verifying the transaction. (https://github.com/nervosnetwork/ckb-ruby-scripts/blob/a75b5df8fdf833b7316bbd9213f73436401c86a5/udt/unlock.rb)
We have created a simple UTXO-like token, just by defining the lock and type scripts. (There is the caveat here that a Cell that has the minimum capacity needed for a SatoshiCoin cannot be used to make two new Cells that also have the same capacity of state.)
Lock and type scripts can not only read the state saved in their own Cell, but also reference and read the state saved in other Cells. Hence CKB presents a stateful programming model. It is worth mentioning that a stateful programming model rather than Turing-completeness is what makes Ethereum so powerful.
We can save the type script in an independent Cell and reference it in the type of every SatoshiCoin Cell. The benefit is that the same type script only needs to occupy a single space in storage. The Cell that stores the definition of a digital asset is called an ADC (Asset Definition Cell). Another feature of the SatoshiCoin implementation is that the detailed record of assets and their owners is split up and saved in multiple independent Cells, which can be provided by developers to users. These cells are owned by users themselves, or can even be rented to users. Only when the ownership of consensus space is clearly defined, can users really own the assets saved in their cells (any cell’s data can be an asset). Since users are allowed to own consensus space on the CKB, they can also own the digital asset saved in it (an example from real estate: only when you own the land can you really own the house built on it).
As an abstract state validation model, the Cell model offers an internally unstructured storage space (data) and supports any state validation rule (type) and ownership validation rule (lock). We can simulate how the UTXO model works in the Cell model (as seen in SatoshiCoin), or build the Account model in it.
The validation of transaction inputs require execution of the lock script, ensuring the users’ ownership of the inputs and their right to destroy the corresponding Cells. The validation of transaction outputs requires execution of the type script, ensuring the new state generated by users conforms to the constraints of the type script and the new Cells are created correctly.
The programming model of CKB differs greatly from that of Ethereum, because it adopts a unique state model and separates calculation and verification. Hence, further exploration is needed to seek out best practices for the programming model of CKB.
Reference：
