How to visit CKB cells in Axon

[KaoImin]

Challenges Outlined

The question is how to reuse IBC’s message and relay process to implement cell visitor. Let's first figure out what we need to do:

1. Obtain cell information
   • The cells should be stored in the node to be used directly for signature verification; otherwise (if we use RPC), the throughput will be impaired.
2. Get cells from CKB
3. Store cells on Axon

The key is: how to get cells from CKB. Cosmos IBC protocol specifies a set of inter-chain communication schema that makes smooth message exchange possible. To reuse IBC Relayer, we need a component to play the role of the opponent chain. This component does not have to be a chain, as long as it can do verifications on Axon as a Cell Emitter that keeps sending cells to Relayer, meanwhile requesting Relayer to resend cells to Axon.

Here is my design draft:

This graph illustrates the process of how an IBC-based cell visitor works, where IBC Relayer takes care of the entire message relay. This design contains three major components:

1. Cell Emitter
2. IBC Relayer
3. Image Cell System Contract (called ICSC)

The complete workflow can be summarized as follows:

1. Application registers the required cell format with Cell Emitter; the chain URL with the IBC Relayer
2. Cell Emitter requests IBC Relayer to relay cell
3. IBC Relayer packages the cell provided by Cell Emitter into a transaction and send it to Axon ICSC
4. Application contract call ICSC to get the cell mirror

Design Explained

Cell Emitter

Being the core of the system, Cell Emitter is responsible for sending the cells from CKB to IBC Relayer and further, to Axon’s chain. Cell Emitter can be based on either ckb-indexer or ckb-node.

There are two critical states of Cell Emitter:

1. The latest state in ICSC, i.e. the latest block number. Because of its read-only nature, the image cell cannot reuse the state of CKB IBC light client on Axon to generate its latest block number, but rather updates it by itself. Correspondingly, in ICSC, the latest updated block number must be maintained.
2. During the process of cell synchronization, old cells might be updated along, meaning that in this block updating process ICSC is write-only. Therefore, ICSC needs to maintain a Write Only/Read Write state.

The overall workflow of Cell Emitter is demonstrated in the following flowchart:

IBC Relayer

IBC Relayer needs to relay the requests from Cell Emitter to Axon and listen to Axon as well.

The interfaces of requests IBC relays:

1. Get ICSC block number
2. Set ICSC Read Only/Read Write
3. Relay the cell and header in a block

The events IBC Relayer listens to are:

1. ICSC current block number events that occur after the request for ICSC block number

IBC Relayer is stateless, therefore. For reuse, the following modifications are needed:

1. To allow Axon and Cell Emitter to establish a one-way connection
2. To create a new IBC Application type for Cell Emitter to send cells

ICSC

As mentioned above, two ICSC states are necessary for Cell Emitter to properly function: block number and Read Only/Read Write. Therefore, ICSC is a stateful contract which stores all the cells and block header relayed from CKB.

The ICSC contract interface for updating is:

contract ICSC {
    function queryBlockNumber() public returns (uint256);
    function setState(bool allowRead) public;
    function updateImage(CKBType.Header header, CKBType.OutPoint[] removeCells, CKBType.CellWithOutPointp[, insertCells) public;
}

To save the storage space of EVM MPT, this contract is set as system contract and is independently stored from EVM MPT. At the end of each execution, the MPT root of the cell will be stored in the storage root of the corresponding Account in this contract.

The ICSC contract interface for query is:

contract ICSC {
    function getHeaderByHash(CKBType.BlockHash, blockHash) public returns (CKBTypes.BlockHeader);
    function getCellByOutPoint(CKBType.OutPoint, outPoint) public returns (CKBTypes.CellWithData);
}

We can see from the code snippets that these two interfaces are different. The interface called by IBC Relayer needs to call multiple write methods, while the one called by the application-side contract is all about calling read methods. Therefore, ICSC contracts has two categories:

• System contract part that provides write methods for IBC Relayer. Each system contract has a fixed address and each chain started with Axon shares the same address. Relayer does not need to configure for each chain individually.
• Precompile contract part that provides two precompile contracts for the application-side to call: get header and get cell.

Here comes a permission question for the system contract part, that is, whether the system contract needs to have a whitelist to add restriction on who can call the contracts. The answer depends on whether Axon can trust the cell information forwarded by Relayer.

• If so, a whitelist is needed. However, it brings up a challenge that a single Relayer can launch an attack by deliberately delaying the message. Also, there will be a third state on ICSC, i.e., the whitelist.
• If not, ICSC is thus permissionless and it requires the contract-caller to proof that the newly arrived message has been already added on CKB. This design can be further developed by taking CKB IBC light client into consideration.

More research needs to be done for the final decision. Intuitively speaking, the first design that includes the whitelist seems easier in terms of development.

[CipherWang]

Several questions:

1. How's the sync mechanism for a new node to verify the history Axon transactions with CKB cell accessing? Let's say a historical transaction at 2022.10.10 that accesses a CKB cell at the same time. A new Axon node joined on 2022.12.10, which verifies this transaction, but the related CKB cells had been consumed.

2. There should be a rule for the ICSC update policy, like the block number in ICSC cannot exceeds that recorded in Relayers.

3. Is there a "overwrite" mode to modify a previous block in ICSC? In case the relayer or emitter updates incorrect data. Or the ICSC doesn't verify the data at all, the relayer updates it arbitrarily.

[KaoImin]

How's the sync mechanism for a new node to verify the history Axon transactions with CKB cell accessing? Let's say a historical transaction at 2022.10.10 that accesses a CKB cell at the same time. A new Axon node joined on 2022.12.10, which verifies this transaction, but the related CKB cells had been consumed.

The concern about inconsistent state due to cell consumed is superfluous. Because the state in ICSC is trigger by the transactions sent by cell emitter. For example, the cell created in x block number of CKB and be consumed and updated in x + 100 block number of CKB. The Axon transaction which include the cell created message packed in y block number of Axon and the cell consumed message packed in y + 50 block number of Axon. When an Axon sync node sync the y block, it will create the cell in ICSC. After this, ICSC will return the current cell when required by other contract until the y + 50 block has executed. Within the range (y, y + 50), all the other contracts will get the cell state created in block y, rather the latest state in CKB.

[KaoImin]

There should be a rule for the ICSC update policy, like the block number in ICSC cannot exceeds that recorded in Relayers.

The update of ICSC is called by cell emitter, the check rule is the block number should be consecutive.

[KaoImin]

Is there a "overwrite" mode to modify a previous block in ICSC? In case the relayer or emitter updates incorrect data. Or the ICSC doesn't verify the data at all, the relayer updates it arbitrarily.

Currently we have not designed such a mechanism.

[gpBlockchain]

is need to think about cut blocks?

[KaoImin]

What does the cut block mean here.

[KaoImin]

Because of the chain id of Ethereum Legacy transaction is included in v, In order to maintain compatibility with this transaction type, we have designed the following parsing rules.

Ethereum Transaction

Due to the len(r) + len(s) + len(v) = 65 in Ethereum transaction. Thus we consider all the transactions with len(r) + len(s) + len(v) != 65 as interoperation transaction.

Interoperation Transaction

There are two kinds of interoperation transaction:

• Verify a mock transaction by CKB-VM
• Run a RISC-V script in CKB-VM directly

Here a set of rules is needed to reinterpret r, s, v. In this case, v represents the chain id and is calculated as v = chainid * 2 + 35. r and s have a corresponding relationship.

Firstly, r[0] means the type of verify method.

r[0] == 0

r[0] == 0 means verify the signature by run a RISC-V script in CKB-VM directly.

• r[1..] is rlp encoded by the following object R:

#[derive(RlpEncodable, RlpDecodable, Clone, Debug)]
pub struct CellDepWithPubKey {
    pub cell_dep: CellDep,
    pub pub_key:  Bytes,
}

• s is the signature bytes.

r[0] == 1

r[0] == 1 means verify the signature by mock a transaction and verify in CKB-VM.

• r[1..] is rlp encoded by the following object R:

#[derive(RlpEncodable, RlpDecodable, Clone, Debug)]
pub struct R {
    pub out_points:  Vec<OutPoint>,
    pub cell_deps:   Vec<CellDep>,
    pub header_deps: Vec<H256>,
}

#[derive(RlpEncodable, RlpDecodable, Clone, Debug)]
pub struct OutPoint {
    pub tx_hash: H256,
    pub index:   u32,
}

#[derive(RlpEncodable, RlpDecodable, Clone, Debug)]
pub struct CellDep {
    pub tx_hash:  H256,
    pub index:    u32,
    pub dep_type: u8,
}

• s is rlp encoded by the following object S:

#[derive(RlpEncodable, RlpDecodable, Clone, Debug)]
pub struct S {
    pub witnesses: Vec<Witness>,
}

#[derive(RlpEncodable, RlpDecodable, Clone, Debug)]
pub struct Witness {
    pub input_type: Option<Bytes>,
    pub output_type: Option<Bytes>,
    pub lock:       Option<Bytes>,
}