RFC: Extensible UDT

Time:2021-9-18

Extensible UDT (extensible UDT, uniformly called XUDT in this paper) is an extension based on simple UDT, which can be used to define the behavior that more UDTs may need. Sudt provides a basic core for issuing UDT on nervos CKB, while XUDT can be based on sudt to meet more potential needs, such as supervision.

data structure

xUDT Cell

XUDT cells are backward compatible with sudt, and all existing rules defined in the sudt specification still apply to XUDT cells. On the basis of sudt, XUDT extends the following cells:

data:
    <amount: uint128> <xudt data>
type:
    code_hash: extensible_udt type script
    args: <owner lock script hash> <xudt args>
lock:
    <user_defined>

The added XUDT args and XUDT data parts provide all the new functions required by XUDT. We will describe the architecture of these details below.

xUDT Args

The architecture of XUDT args is as follows:

  • 4-byte XUDT tag
  • Variable length XDATA

Depending on the content of flags, different extended data may be attached:

  • If all flags are 0, we don’t need any extended data. It should be noted that the backward compatible view mode is that a blank sudt cell also has a hidden flags field with all 0.
  • If flags is 0x1, the extended data will contain a molecule serialized in scriptvec structure( https://github.com/nervosnetw…
table Script {
    code_hash:      Byte32,
    hash_type:      byte,
    args:           Bytes,
}

vector ScriptVec <Script>;

Each entry contained in the scriptvec structure is interpreted as a CKB script hash of an extension script with additional behavior. When an XUDT script is executed, it will run each extension script included here. XUDT will consider the validation successful only when all extension scripts pass the validation.

An extended script can be loaded in any of the following ways:

  • Some extension logic may already have predefined hashes. For example, we can use 0x0000… 0001 to represent regulatory extensions. The actual code of these scripts has been embedded in XUDT’s own scripts.
  • Owner lock can be used: if an input cell in the current transaction uses a lock script with the same script hash as the current extension script, we can consider that the extension script has been verified.
  • If an extension script does not match any of the above criteria, XUDT will use the code contained in the extension script_ Hash and hash_ Type to call CKB_ dlopen2( https://github.com/nervosnetw… To load a dynamically linked script from the cell DEPs of the current transaction. If the script can be successfully located, XUDT will look for an export function with the following signature:
int validate(int is_owner_mode, size_t extension_index, const uint8_t* args, size_t args_length);

is_ owner_ Mode indicates whether the current XUDT is unlocked through the owner mode (as described in sudt), extension_ Index refers to the index of the current extension in the scriptvec structure. Args and args_ Length is set to script args contained in the script structure of the current extended script.

If the function returns 0, the validation of the current extension script is considered successful.

  • If flags is 0x2, the extended data will contain the blake160 hash of the scriptvec structure explained in the previous section. The actual scriptvec structure data will be included in the witness in the current transaction. We will explain this part below.

xUDT Data

XUDT data is a module serialized with xudtdata structure:

vector Bytes <byte>;
vector BytesVec <Bytes>;

table XUDTData {
  lock: Bytes;
  data: BytesVec;
}

The data field contained in xudtdata must be the same length as the scriptvec structure contained in XUDT args. Some extensions may need to store user specific data in each XUDT cell. XUDT data provides a place for such data.

The lock field contained in xudtdata will not be used by XUDT script. It is reserved for the lock script specific data of the current cell.

The extension script first needs to find the index located in XUDT args, and then find the data of the current extension script at the same index of the data field of xudtdata structure.

operation

XUDT adopts the same governance operation as sudt: owner lock controls all governance behaviors, such as token casting.

However, the normal invocation operation of XUDT is different from that of sudt. Depending on the flags used, there may be two usage modes:

Original extension script

When flags is set to 0x1, the original extended data will be directly included in XUDT args.

Inputs:
    <vec> xUDT_Cell
        Data:
            <amount: uint128> <xudt data>
        Type:
            code_hash: extensible_udt type script
            args: <owner lock script hash> <xudt args>
        Lock:
            <user defined>
    <...>
Outputs:
    <vec> xUDT_Cell
        Data:
            <amount: uint128> <xudt data>
        Type:
            code_hash: extensible_udt type script
            args: <owner lock script hash> <xudt args>
        Lock:
            <user defined>
    <...>
Witnesses:
    WitnessArgs structure:
      Lock: <user defined>
      Input Type: <BytesVec structure>

The witness of the same index as the first input XUDT cell is located by the XUDT script. It is first parsed into the witnessargs structure, so the input of witnessargs_ The type field is treated as a bytesvec structure. This structure must also be the same length as the XUDT args and XUDT data sections. The extension script may also need data for a specific transaction for validation. Here, witness provides a place for this data requirement.

Note that each extension script is executed only once in the transaction. The extension script is responsible for checking all XUDT cells of the current type to ensure that each cell data and witness of the current extension script can be verified according to the rules of the extension script.

P2SH Style Extension Script

When flags is set to 0x2, XUDT args only contains blake160 hash of extended data. Users will be asked to directly provide extended data in witness:

Inputs:
    <vec> xUDT_Cell
        Data:
            <amount: uint128> <xudt data>
        Type:
            code_hash: extensible_udt type script
            args: <owner lock script hash> <xudt args>
        Lock:
            <user defined>
    <...>
Outputs:
    <vec> xUDT_Cell
        Data:
            <amount: uint128> <xudt data>
        Type:
            code_hash: extensible_udt type script
            args: <owner lock script hash> <xudt args>
        Lock:
            <user defined>
    <...>
Witnesses:
    WitnessArgs structure:
      Lock: <user defined>
      Input Type: <Raw Extension Data> <BytesVec structure>

The only difference here is the input in the corresponding witnessargs structure_ The type field contains the original extension data in the scriptvec data structure. The XUDT script must first verify whether the hash of the original extension data provided here is the same as the blake160 hash contained in XUDT args. After that, it will use the same logic as in the previous workflow.

RFC: Extensible UDT

Recommended Today

Supervisor

Supervisor [note] Supervisor – H view supervisor command help Supervisorctl – H view supervisorctl command help Supervisorctl help view the action command of supervisorctl Supervisorctl help any action to view the use of this action 1. Introduction Supervisor is a process control system. Generally speaking, it can monitor your process. If the process exits abnormally, […]