Exploring an essential data structure in CKB— the transaction
There’s a reason we choose cell type script hash to support upgradable script. If the adversary wants to create a cell with a specific type script, the transaction must be verified by the type script code.
Type ID is this kind of type script. As the name suggests, it ensures the uniqueness of the type script.
This feature involves several type scripts, so I will use different terms to differentiate them:
- The Type ID code cell is the cell which stores the code to verify that a type id is unique.
- The Type ID code cell has a type script as well. We don’t care about the actual content for now, so let’s assume the type script hash is TI.
- A Type ID is a type script in which
hash_typeis “Type”, and
From Type Script Part I, we know that type script groups inputs and outputs first. In other words, if the type script is a type ID, the inputs and outputs in the group all have the same type ID.
The Type ID code verifies that, in any type id group, there is at most one input and at most one output. A transaction is allowed to have multiple type id groups depending on the numbers of inputs and outputs, the type id groups are categorized into three different types:
- Type ID Creation Group has only one output.
- Type ID Deletion Group has only one input.
- Type ID Transfer Group has one input and one output.
The transaction in the diagram above has all three kinds of type id groups.
- G1 is a Type ID Transfer Group which transfers the type id from cell1 to cell4.
- G2 is a Type ID Deletion Group which deletes the type id along with cell2.
- G3 is a Type ID Creation Group which creates a new type id for cell3.
In the Type ID Creation Group, the only argument in
args is the hash of this transaction first
CellInput structure and the output index of the cell in the group. For example, in the group g3, id3 is a hash on
tx.inputs and 0 (cell3’s index in
There are two ways to create a new cell with a specific type id.
- Create a transaction where the hash of
tx.inputsand any index equal to a specific value. Since a cell can only be used as an input once in the chain,
tx.inputsmust be different in each transaction; this problem is equivalent to finding a hash collision, the probability of which is negligible.
- Destroy the old cell in the same transaction.
We assume that method 2 is the only way to create a cell equal to an existing type id. And this way requires the authorization of the original owner.
The Type ID code can be implemented only via CKB VM code, but we choose to implement it in the CKB node as a special system script, because if we want to be able to upgrade Type ID code later, it has to use itself as the type script via type script hash, which is a recursive dependency.
The Type ID code cell uses a special type script hash, which is just the ascii codes in hex of the text