How to integrate CKB into Exchanges

English CKB Development & Technical Discussion
1

Note: This is a translation post of 交易所整合 CKB 简明方案

Introduction

Nervos CKB is a UTXO model based PoW blockchain that supports smart contracts. Its virtual machine uses the RISC-V instruction set. The basic asset of Nervos CKB is called CKB, or CKBytes, its main purpose is to pay state space occupancy fees (through inflation) and transaction fees to miners.

The default signature algorithm of CKB is secp256k1, and the default hash algorithm is blake2b, in the same way as Bitcoin and Ethereum. Exchanges can generate a dedicated address for each user, and users can transfer assets to the address.

Blockchain explorer: https://explorer.nervos.org/

Testnet Faucet: https://faucet.nervos.org/

Desktop Wallet: GitHub - nervosnetwork/neuron: Neuron: Nervos CKB Wallet

Mobile Wallet: imToken, Bitpie, ABCWallet, Cobo, Hoo, etc

SDK: ckb-sdk-js , ckb-sdk-java , ckb-sdk-go

Integration process

1.Running Node

The Nervos foundation does not provide centralized public APIs. For security reasons, Wallets and Exchanges operators should run blockchain nodes (CKB node) and cache middleware on their own (CKB indexer). Cache middleware provides convenient interfaces to query information such as balances and historical transactions.

Here you can find the two in one docker image maintained by the CKB Dev team, which can be run with one click. It consists of 2 groups of APIs: CKB RPC and CKB indexer RPC, which can be accessed respectively at http://localhost:8117/rpc and http://localhost:8117/indexer

2.Generate address

Private key generation

The CKB default signature algorithm uses secp256k1, and the public-private key generation algorithm is the same as Bitcoin and Ethereum.

Relationship between public key and address

User assets on CKB are managed by a lock script, each lock script corresponds to a signature algorithm and a public key hash. The address is human readable code of a lock script: lock script ⇔ address

    lock_script: {
    code_hash: // 32 bytes signature algorithm contract address or code hash(fixed value)
    hash_type: // type / data and code_ Hash pairing setting ( fixed value )
    args: // user's public key hash
    }

CKB nodes only recognize lock scripts, and the application layer needs to convert the address value. For Exchange deposit addresses, both code_hash and hash_type are fixed values and only need to be modified to update the args value (address).

Address generation

    Generate private key => generate public key =>
    take the first 20 bytes of blake2b hash as args
    => Patchwork lock script => Convert into address

Public key to address API: java sdk, js sdk（ utils.pubkeyToAddress )

Address validity verification

CKB transfer supports a variety of address formats, and the SDK already handles them properly. The front end could use utils.parseAddress to check the validity of the address, and the back-end SDK will automatically convert them into lock script values for processing.

3.Query

Balance query: get_cell_capacity (from ckb-indexer-rpc)

Tip header： get_tip (from ckb-indexer-rpc)

Number of irreversible block confirmations: 24

Query block according to block height : get_block_by_number (from ckb-rpc)

Query block according to block_hash: get_block (from ckb-rpc)

Valid transaction determination: all transactions entered in blocks are valid transactions (different from Ethereum)

Transaction history query: get_transactions (from ckb-indexer-rpc)

4.Transfer

Note: due to the underlying logic of CKB, the minimum amount of transfer and change is 61 CKB by default.

For transfer implementation please refer to:

For principles of transfer please refer to How to sign the transaction.

For setting principles of transaction fees please refer to Transaction Fee .

5. Live cell management

Note: live cell management is very important for business reliability, please ensure it is handled properly

As a UTXO public blockchain, each external transfer needs to refer to a certain number of live cells as input. However, if transactions are sent continuously, there will be repeated spend of live cells or insufficient available live cells. For example, after obtaining a user’s available cells through CKB indexer and sending transactions continuously, when the last transaction is still off-chain, CKB indexer may return the previously referenced input cell as a live cell.

This requires developers to distinguish cells that are inputs to pending transactions (but not yet included in blocks), two solutions are given here:

  • Developers could manage an off-chain transaction pool, mark its referenced input as invalid, and exclude these cells from new transactions. Update the transaction pool after transactions are successfully on-chain or rejected by the blockchain;
  • Serial processing transactions; Each time a transaction is sent, wait for the transaction to be included in a block, and collect transfer requests in the waiting process. Construct a multi-output transaction after the last transaction is on-chain, and send collected transfer requests together.

6. Public server

Note: Considering security and reliability, it would be better that applications/wallets/exchanges use nodes maintained by themselves in a production environment. The public servers collected below are maintained by the community just for public welfare. They are for testing only and make no guarantees of availability.

Testnet:

https://testnet.ckb.dev/rpc => ckb node rpc

https://testnet.ckb.dev/indexer => ckb-indexer rpc

Mainnet:

https://mainnet.ckb.dev/rpc => ckb node rpc

https://mainnet.ckb.dev/indexer => ckb-indexer rp

1 Like