RFC: Regulation Compliance Lock

Regulation Compliance Lock

Regulation Compliance Lock (RC Lock) is a new lock script that is designed to be used together with Regulation Compliance Extension. Apart from being a regular lock, it provides one unique feature: certain administrators of the xUDT can revoke tokens held by certain malicious users. In otherwise, a cell guarded by this lock can be unlocked by either of the following parties:

  • Owner of the cell
  • Administrators of the RC lock, typically regulators for a particular xUDT token

One might find this lock against common beliefs in Nervos CKB: the owner of a lock has absolute control on his/her cells. One unique power of CKB, is to provide options, it’s perfectly good to use a lock that only one themselves can unlock, we will be continuing supporting this solution to the end of time. Having RC lock will not change this fact.

However, it might also make sense to provide option for the other side of spectrum: certain tokens are regulated by authorities, which will need the ability to revoke issued tokens, once owners stop confronting to regulations. While this option certainly sacrifices some security, it trades us a solution to be more connected with the real world for mass adoption.

When using together, RC Lock and RCE provide functionalities that are on par with ERC-1404.

Identity

RC lock introduces a new concept to CKB lock scripts: an identity is a 21 byte long data structure containing the following components:

<1 byte flag> <20 byte identity content>

Depending on the value of the flag, the identity content has different interpretations:

  • 0x0: identity content represents the blake160 hash of a secp256k1 public key. The lock script will perform secp256k1 signature verification, just as the SECP256K1/blake160 lock.
  • 0x1: identity content represents the blake160 hash of a lock script. The lock script will check if current transaction contains an input cell with matching lock script. Otherwise it would return with an error.

Later, more checks might be added to the identity data structure. For example, when exec becomes ready, we might add yet another identity type, which loads a new script for the actual identity validation.

Regulation Compliance Lock Script

An RC lock script has the following structure:

Code hash: RCE script code hash
Hash type: RCE script hash type
Args: <21 byte identity> <32 byte RC cell type id>

RC cell type ID contains the type script hash used by a special cell with the same format as RCE Cell, but with the following differences:

  • The cell used here contains identities, not lock script hashes.
  • If the cell contains a RCRule structure, the RCRule structure must be in whitelist mode.
  • If the cell contains a RCCellVec structure, there must at least be one RCRule structure using whitelists in the RCCellVec.

For ease of reference, we call this cell RC AdminList Cell.

When an administrator tries to unlock the cell using RC lock, the administrator must provide SMT proofs for the identity used for validation. See the following part for more details.

Regulation Compliance Lock Witness

When unlocking an RC lock, the corresponding witness must be a proper WitnessArgs data structure in molecule format, in the lock field of the WitnessArgs, an RcLockWitnessLock data structure as follows, must be present:

import xudt_rce;

array Identity [byte; 21];

table RcIdentity {
    identity: Identity,
    proofs: SmtProofEntryVec,
}
option RcIdentityOpt (RcIdentity);

// the data structure used in lock field of witness
table RcLockWitnessLock {
    signature: BytesOpt,
    rc_identity: RcIdentityOpt,
}

When rc_identity is present, we will validate if the provided identity in rc_identity is present in RC AdminList Cell associated with current lock script via SMT validation rules. In this case, the identity included in rc_identity will be used in further validation.

When rc_identity is missing, the identity included in lock script args will then be used in further validation.

Once the identity to be used is confirmed, we will look for the flag in the designated identity for succeeding operations:

  • In case the identity flag is 0x0, a signature must be present in RcLockWitnessLock, we will used the signature for secp256k1 recoverable signature verification. The recovered public key hash using blake160 algorithm, must match the current identity content.
  • In case the identity flag is 0x1, we will check against current transaction, and there must be an input cell, whose lock script matches the identity content when hashed via blake160.

Examples

Unlock via owner’s public key hash

CellDeps:
    <vec> RC Lock Script Cell
Inputs:
    <vec> Cell
        Data: <...>
        Type: <...>
        Lock:
            code_hash: RC Lock
            args: <flag: 0x0> <pubkey hash 1> <RC AdminList Cell type ID>
    <...>
Outputs:
    <vec> Any cell
Witnesses:
    WitnessArgs structure:
      Lock:
        signature: <valid secp256k1 signature for pubkey hash 1>
        rc_identity: <MISSING>
      <...>

Unlock via owner’s lock script hash

CellDeps:
    <vec> RC Lock Script Cell
Inputs:
    <vec> Cell
        Data: <...>
        Type: <...>
        Lock:
            code_hash: RC Lock
            args: <flag: 0x1> <lock hash: 0x1234> <RC AdminList Cell type ID>
    <vec> Cell
        Data: <...>
        Type: <...>
        Lock: blake160 for this lock script must be 0x1234
    <...>
Outputs:
    <vec> Any cell
Witnesses:
    WitnessArgs structure:
      Lock:
        signature: <MISSING>
        rc_identity: <MISSING>
      <...>

Unlock via administrator’s public key hash

CellDeps:
    <vec> RC Lock Script Cell
    <vec> RC AdminList Cell 1
Inputs:
    <vec> Cell
        Data: <...>
        Type: <...>
        Lock:
            code_hash: RC Lock
            args: <flag: 0x0> <pubkey hash 1> <RC AdminList Cell 1's type ID>
    <...>
Outputs:
    <vec> Any cell
Witnesses:
    WitnessArgs structure:
      Lock:
        signature: <valid secp256k1 signature for pubkey hash 2>
        rc_identity:
           identity: <flag: 0x0> <pubkey hash 2>
           proofs: <SMT proofs for the above identity in RC AdminList Cell 1>
      <...>

Unlock via administrator’s lock script hash

CellDeps:
    <vec> RC Lock Script Cell
    <vec> RC AdminList Cell 1
Inputs:
    <vec> Cell
        Data: <...>
        Type: <...>
        Lock:
            code_hash: RC Lock
            args: <flag: 0x0> <pubkey hash 1> <RC AdminList Cell 1's type ID>
    <vec> Cell
        Data: <...>
        Type: <...>
        Lock: blake160 for this lock script must be 0x1234
    <...>
Outputs:
    <vec> Any cell
Witnesses:
    WitnessArgs structure:
      Lock:
        signature: <MISSING>
        rc_identity:
           identity: <flag: 0x1> <lock hash: 0x1234>
           proofs: <SMT proofs for the above identity in RC AdminList Cell 1>
      <...>
3 Likes

Here I have a dumb question : how to understand the field “flag” ?
Have seen it on the RCE post lol.

The flags indicates an unlock method, either by one of the following:

  • unlock by owner lock
  • pubkey hash
    It has no relationship with RCE.
1 Like

Got it, thanks for your helpful answer!