How to construct a transaction?

[Lester-xie]

CKB adopts UTXO model. A transaction destroys some outputs created in previous transactions and creates some new outputs.We call the transaction output a cell in CKB. Thus the name cell and transaction output are interchangeable.

Here I quote a sentence from CKB Transaction Structure.

A complete transaction must contain at least these fields, as shown in the diagram below.

It contains a lot of information, and the most crucial part is the inputs and outputs. It specifies the participants of the transaction, the sender and the receiver.

To construct a transaction, we need to use the sender's address, find the input (unspent output) that meets certain conditions in the blockchain node, and calculate the outputs containing the recipient's address information.

Essentially, both input and output are arrays of cells that have the same structure. A cell has the following fields:

• capacity- Size limit of the cell. A cell's size is the total size of all fields contained in it.
• data- State data stored in this cell. It could be empty, however, the total bytes used by a cell (including data), must always be less than or equal to its capacity.
• type- State verification script.
• lock- Script that represents the ownership of the cell. Owners of cells can transfer cells to others.

But for different transaction types, these fields also have different rules.

Below I will introduce how to construct cells in inputs and outputs under different transaction types.

Transaction

General Transaction

Suppose I have an account A with 800 CKB in it, and now I want to transfer 500 CKB to account B using Neuron.

Let's construct the inputs. First, the wallet will find all the unspent transaction outputs under A from the block nodes and find the single or multiple outputs that can complete the transaction. In short, the sum of the inputs is greater than the outputs.

The lock script used by ordinary transactions is SECP256K1/blake160. Type script is optional.

So the inputs should look like this:

Inputs:
    General Cell
        CAPACITY: (500, 800] CKB
        LOCK: SECP256K1/blake160 Script
        TYPE: <optional>
        DATA: <optional>

or

Inputs:
    General Cell
        CAPACITY: 350 CKB
        LOCK: SECP256K1/blake160 Script
        TYPE: <optional>
        DATA: <optional>
    General Cell
        CAPACITY: 450 CKB
        LOCK: SECP256K1/blake160 Script
        TYPE: <optional>
        DATA: <optional>

Now let's look at the outputs. As you can see from the above inputs, we entered 800CKB, but the B account will only receive 500CKB, and the rest needs to be returned to A, so the outputs should be like this:

Outputs:
    General Cell
        CAPACITY: 299.99 CKB(0.01CKB is paid as the transaction fee)
        LOCK: SECP256K1/blake160 Script
        TYPE: <optional>
        DATA: <optional>
    General Cell
        CAPACITY: 500 CKB
        LOCK: SECP256K1/blake160 Script
        TYPE: <optional>
        DATA: <optional>

In this way, we have completed the inputs and outputs of a general transaction

Anyone-Can-Pay Transaction

There is such a problem that we cannot ignore. One can only transfer to another user at most minuscule 61 CKBytes when using the default lock(SECP256K1/blake160).

The anyone-can-pay lock script can be unlocked not only by validating a signature but also by accepting any payment amount. For a detailed introduction, please refer to this RFC

Now I assume that A has 100 CKB, B has 200 CKB, and now A wants to transfer 50 CKB to B, then the inputs and outputs of this transaction should be like this:

Inputs:
    Normal Cell:
        Capacity: 100 CKB
        Lock:
            code_hash: secp256k1_blake2b lock
            args: <public key hash A>
        TYPE: <optional>
        DATA: <optional>
    Anyone-can-pay Cell:
        Capacity: 200 CKB
        Lock:
            code_hash: anyone-can-pay lock
            args: <public key hash B> <CKByte minimum: 2>
        TYPE: <optional>
        DATA: <optional>
Outputs:
    Normal Cell:
        Capacity: 49.99 CKB(0.01CKB is paid as the transaction fee)
        Lock:
            code_hash: secp256k1_blake2b lock
            args: <public key hash A>
        TYPE: <optional>
        DATA: <optional>
    Anyone-can-pay Cell:
        Capacity: 250 CKB
        Lock:
            code_hash: anyone-can-pay lock
            args: <public key hash B> <CKByte minimum: 2>
        TYPE: <optional>
        DATA: <optional>

In this transaction, B will receive a transfer of 50 CKB. The anyone-can-pay lock is used to overcome the 61 CKB requirement of plain transfer.

Simple User Defined Token Transaction

Developers can also issue their custom tokens on Nervos CKB, this RFC describes the Simple User Defined Tokens(SUDT) in detail.

If the SUDT transaction uses the default lock, then a transfer transaction requires not only UDTs but CKByte to keep the UDTs in a cell. This situation is not what we want. Fortunately, using the anyone-can-pay lock can also solve this problem.

Suppose A has 100CKB and 200UDT, B has 300CKB and 400UDT, and A wants to transfer 150UDT to B. Let's see what such a transaction should look like:

Inputs:
    Deposit Normal Cell:
        Capacity: 100 CKB
        Lock:
            code_hash: secp256k1_blake2b lock
            args: <public key hash A>
        Type:
            code_hash: simple udt lock
            args: <owner lock C>
        Data:
            Amount: 200 UDT
    Anyone-can-pay Cell:
        Capacity: 300 CKB
        Lock:
            code_hash: anyone-can-pay lock
            args: <public key hash B> <CKByte minimum: 8> <UDT minimum: 2>
        Type:
            code_hash: simple udt lock
            args: <owner lock C>
        Data:
            Amount: 400 UDT
Outputs:
    Deposit Change Cell:
        Capacity: 99.99 CKB(0.01CKB is paid as the transaction fee)
        Lock:
            code_hash: secp256k1_blake2b lock
            args: <public key hash A>
        Type:
            code_hash: simple udt lock
            args: <owner lock C>
        Data:
            Amount: 50 UDT
    Anyone-can-pay Cell:
        Capacity: 300 CKB
        Lock:
            code_hash: anyone-can-pay lock
            args: <public key hash B> <CKByte minimum: 8> <UDT minimum: 2>
        Type:
            code_hash: simple udt lock
            args: <owner lock C>
        Data:
            Amount: 350 UDT

Here CKByte minimum is set to 8, which means in each transaction, one must at least transfers 10^8 shannons, or 1 CKBytes into the anyone-can-pay cell. Note that even though the UDT minimum is set to 2, one should at least transfer 100 UDT base units to the anyone-can-pay cell, satisfying the CKByte minimal transfer minimum alone satisfies the validation rules allowing CKB to accept the transaction.

[Keith-CY]

The lock script used by ordinary transactions is SECP256K1/blake160. Type script is optional.

We will filter out cells having type script or data in ordinary transactions, because a cell with type script or data is usually not an ordinary cell, consuming it will lead to other functions being broken, e.g. another script refers to this cell with data as a dependency.

Now I assume that A has 100 CKB, B has 200 CKB, and now A wants to transfer 50 CKB to B, then the inputs and outputs of this transaction should be like this:

This ACP example is inappropriate, A has 100 CKB and will send 50CKB out, then its balance is 50CKB, less than 61CKB.

If the SUDT transaction uses the default lock, then a transfer transaction requires not only UDTs but CKByte to keep the UDTs in a cell. This situation is not what we want. Fortunately, using the anyone-can-pay lock can also solve this problem.

Here B uses an Anyone-can-pay cell because this transaction is signed by A, if B uses a secp256k1/blake2b cell, to unlock B's input requires B to sign this transaction. When B uses an Anyone-can-pay cell, B doesn't need sign it because the Anyone-can-pay cell can be unlocked by A when its amount is not reduced.

[Lester-xie]

We will filter out cells having type script or data in ordinary transactions, because a cell with type script or data is usually not an ordinary cell, consuming it will lead to other functions being broken, e.g. another script refers to this cell with data as a dependency.

Oh, I see, so an ordinary cell usually does not contain type or data.

This ACP example is inappropriate, A has 100 CKB and will send 50CKB out, then its balance is 50CKB, less than 61CKB.

Yes, I think I overlooked this. Maybe A should have a hypothesis larger than 111CKB, such as 200CKB.

Here B uses an Anyone-can-pay cell because this transaction is signed by A, if B uses a secp256k1/blake2b cell, to unlock B's input requires B to sign this transaction. When B uses an Anyone-can-pay cell, B doesn't need sign it because the Anyone-can-pay cell can be unlocked by A when its amount is not reduced.

Thanks for the addition. It deepened my understanding.