docs: add a draft of kuai proposal

[Keith-CY]

Add a draft of kuai proposal to elaborate on the motivation, design and schedule.

Preview: https://github.com/ckb-js/topics/blob/add-draft-of-kuai-proposal/README.md

[janx]

This is cool!

The abstractions data/code/token seems to sit on different levels:

• data is the top abstraction, abstracting away storage-related details;
• code is a special type of data, which can be executed;
• token is a special type of code;

If so I'd suggest stating the different abstraction levels explicitly in the documentation. I also think "data" and "code" are pretty bad names ... I believe better choices exist, e.g. Store / Contract / Token would read clearer to me.

I have a question about the "MultiCoin Token" - why the prefix "MultiCoin"? Is "MultiCoin Token" a model of one token, or it is a model of an aggregation of tokens? Is a "MultiCoin Token" held by a user or issuer?

[yanguoyu]

Is the ABI means interface about DApp? Because the contract will only verify transaction, there is no interface like ABI.
If so it means the DApp ABI will output valided transaction for contract. Then how could we ensure that, or how could we link DApp interface with contract?

[Keith-CY]

I also think "data" and "code" are pretty bad names ... I believe better choices exist, e.g. Store / Contract / Token would read clearer to me.

Renaming Code to Contract is a good suggestion cuz contract is more generally used in blockchain context. Data and Store are equivalent for me so Store is also fine if good for understanding.

---

If so I'd suggest stating the different abstraction levels explicitly in the documentation.

Relation between Store, Contract, and Token will be elaborated on below and a conclusion will be updated in the draft later.

I would take JavaScript Built-in Objects Map, Reflect and Date as analogues to clarify their relationship in abstractions.

Store is similar to Map in JavaScript, which is an iterable collection of key-value pairs and has basic methods such as get, has, set, clear, forEach, keys, values, entries. Its only usage is to store structured data.

Contract extends Store to have the ability to alter/retrieve its internal data under specific rules(ABI) rather than simple get/set methods. For interoperability, Contract exposes a uniform approach to update its state, named run(methodSignature, argumentList) which is similar to Reflect.apply(fn, thisArg, argumentList) so the trigger could be broadcasted via message in the model tree, we will talk about it later.

Token is specialized from Contract, and can be thought of as Date in JavaScript, which has its own specific attributes and methods now, setHours. Token would have methods like mint, burn, transfer, etc. Data and Token are used so widely that they have their own seats in Built-in Objects. More advanced models will be added along with the evolving ecosystem.

With a set of standardized interfaces, we can build a model tree of a DApp, as briefly mentioned in the draft.

flowchart BT

cell_a_0_model --> dapp_a_sub_model
cell_a_1_model --> dapp_a_sub_model
cell_a_n_model --> dapp_a_sub_model
dapp_a_sub_model --> dapp_a_model

cell_b_0_model --> dapp_b_model
cell_b_1_model --> dapp_b_model
cell_b_n_model --> dapp_b_model
dapp_b_model --> dapp_a_model

Loading

This idea is from actor model so the structure of an application is similar.

Actor model is a programming paradigm for concurrent computation, states will not be stored in a single point, but distributed to various actors so computation could be performed in many actors.

Actor model follows several fundamental rules

• All computation is performed within an actor
• Actors can communicate only through messages
• In response to a message, an actor can:
  • Change its state or behavior
  • Send messages to other actors
  • Create a finite number of child actors

From the perspective of the model tree and CKB's cell model, states/cells will not be stored in a single Store model, but distributed to a bulk of Store models and can be updated in parallel via messages. If a model handles a message, it would

• Update model's state
• Proxy the message to another model
• Create a new model to fetch more state/cells and handle the message

States/cells are arranged isolatedly into different pieces and can only be changed by messages, the updates are sequenced and data conflicts are avoided naturally.

One more interesting point is that model tree could be server-agnostic. As mentioned in the draft, if DApp_A relies on DApp_B, e.g. Swap DApp relies on Token DApp, model tree of DApp_B will be a part of DApp_A's model tree, illustrated in the diagram above, and DApp_A have to rebuild the model tree of DApp_B to interact with it. In actor model, DApp_B's model tree could be rebuilt locally or remotely because the interactions are transferred by messages, thus DApp_A could request the server of DApp_B to output Store by a specific action.

Take a concrete example, there's a Swap DApp to swap Token A and Token B. Now user wants to swap X token a with Y token b from Swap DApp

1. Swap DApp requests Token A DApp to take an action transfer X from swap_pool to user and return a Store of Token A
2. Swap DApp requests Token B DApp to take an action transfer Y from user to swap_pool and return a Store of Token B.
3. Swap DApp combines Store of Token A and Store of Token B to generate a transaction for user to confirm the swap.

---

I have a question about the "MultiCoin Token" - why the prefix "MultiCoin"? Is "MultiCoin Token" a model of one token, or it is a model of an aggregation of tokens? Is a "MultiCoin Token" held by a user or issuer?

MultiCoin here is just for emphasis that Token model is of MultiCoin, namely an aggregation of tokens, and they can be combined together with the method combine(token). It's an abstract object existing in state management and transition so not held by someone.

If there's a special DApp Pool of Token A and B in the example above, it would be built on the top of Token model which covers Token A and Token B, then sending two requests to the same DApp should work.

[Keith-CY]

Is the ABI means interface about DApp? Because the contract will only verify transaction, there is no interface like ABI.

ABI is about the interface of DApp based on the Contract model. Contract model mentioned in the draft is not about verifying a state transition, but adopting a transition on the previous state and generating the next stage of state, namely the state transition function mentioned in the draft.

Ideally, a Contract model accepts a message to take an action and respond with the new state, but for development experience, ABI is introduced to encode a method call into a message between two contract models.

---

If so it means the DApp ABI will output valided transaction for contract.

Contract doesn't output a transaction, it outputs a transition of state modeled by Store which can be used in constructing a valid transaction.

---

Then how could we ensure that, or how could we link DApp interface with contract?

It's too detailed so I haven't considered it.

[felicityin]

Swap DApp requests Token A DApp to take an action transfer X from swap_pool to user and return a Store of Token A

Does a Store/Data store only one user's data?

[felicityin]

Note that a Data model could be a group of cells matching the same pattern and working as an entity so it could be regarded as a virutal DApp.

Will all data be stored in the blockchain? Who will pay for the capacity?

[Keith-CY]

Swap DApp requests Token A DApp to take an action transfer X from swap_pool to user and return a Store of Token A

Does a Store/Data store only one user's data?

Store groups cells by a specific pattern defined by DApp and DApp should implement their aggregation service by business logic(could be thought of as schema & sql).

One user could be a pattern for Profile DApp, One Token could be a pattern for Token DApp, and One user's one token could be a pattern for Portfolio Tracker DApp

Of course, some classic patterns, or say aggregation services/schema&sql will be provided by Kuai at the beginning.

Ref: https://github.com/ckb-js/topics/pull/5/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R99

In the "Swap DApp requests Token A DApp to take an action transfer X from swap_pool to user and return a Store of Token A" case, there're two patterns

1. the one adopted by Token A DApp, viz. Store of Token A(covers all addresses holding this token)
2. the one returned to Swap DApp, Store of Partial Token A belongs to user and swap_pool

[Keith-CY]

Note that a Data model could be a group of cells matching the same pattern and working as an entity so it could be regarded as a virutal DApp.

Will all data be stored in the blockchain? Who will pay for the capacity?

Data are stored on the chain and the spender of capacity should be decided by DApps.

But the Store/Data model is about off-chain model, load bytes from the chain turn them into structured data. It can be thought of as ORM

[homura]

Hi, I would like to learn, the Cell of CKB and JIG have a big difference is that Cell is able to verify rule on-chain, JIG's Code actually just store the code in op_return when used as metadata, BSV does not verify JIG, so I would like to ask, the design of the Code, will be a kind of DSL (something like Marlowe) that can run on CKB?

[Keith-CY]

Hi, I would like to learn, the Cell of CKB and JIG have a big difference is that Cell is able to verify rule on-chain, JIG's Code actually just store the code in op_return when used as metadata, BSV does not verify JIG, so I would like to ask, the design of the Code, will be a kind of DSL (something like Marlowe) that can run on CKB?

I didn't think about it too much and haven't clearly learned Marlowe so we can have a discussion about it.

For now, there would be some DSL, as the pattern I mentioned in the usage of Store to fetch a group of cells, and would be some built-in abstract classes/modules requiring developers to implement the standard interfaces.

[Keith-CY]

Hi, I would like to learn, the Cell of CKB and JIG have a big difference is that Cell is able to verify rule on-chain, JIG's Code actually just store the code in op_return when used as metadata, BSV does not verify JIG, so I would like to ask, the design of the Code, will be a kind of DSL (something like Marlowe) that can run on CKB?

I think I've got the point after reading the part of Executing a marlowe contract

In Marlowe some instructions like Pay, When, Let are defined to write a contract and will be interpreted during transaction validation. It's worth a discussion.

[Keith-CY]

The draft of the proposal has been updated by docs: update draft of kuai proposal

1. rename models to `Store`, `Contract` and `Token`
2. complement details added in https://github.com/ckb-js/topics/pull/5
3. add some promising features

and please review it again.

[felicityin]

Do users need to sign transaction via MetaMask?

[homura]

Do users need to sign transaction via MetaMask?

I understand that it depends on whether Kuai will integrate Omnilock, which we can probably discuss in the detailed design phase

[Keith-CY]

Do users need to sign transaction via MetaMask?

If users here means users of a dapp based on kuai, it should be decided by developers of the dapp and the workflow of the dapp;

If users means developers using kuai to build a dapp, and sign a transaction is used to deploy the contract, the process of signing (usually) will be done by a script(ci) instead of MetaMask.

[homura]

Capacity management

Unlike most UTxO systems, the economic model of CKB has a concept of "state rent", where the data written on-chain need 1 byte/CKB, which makes capacity management difficult.
For example, as a liquidity provider, a pool may generate LP token, and the dApp user may need to transfer the ownership of the original two tokens (probably at least two cells, or possibly more) to the pool.
In these sessions, the dApp user may need to transfer the ownership of the original two tokens (maybe at least two cells, or maybe more) to the pool, and then get an LP token (maybe one cell)

Message is also the state

AFAIK, message is also a kind of state, right? Maybe Kuai provides the channel for these messages, but these messages may need to exist in a different actor (Cell), which means dApp user might need to write data to the Cell, and wouldn't this action of sending a message cause a UTxO concurrency problem?

[YunwenL]

Minor typos in the draft of Kuai:
three obvious obstables -> obstacles
But a real-word DApp. -> real-world
on-chain off-chain for testing -> on-chain, off-chain for testing
function of state verification off-chain is a rehearsal or replay of function of state verification off-chain. -> … a rehearsal or replay of function of state verification on-chain
let's define the function of state verification and expect it be be 0. -> delete the extra be

[Keith-CY]

Minor typos in the draft of Kuai:
three obvious obstables -> obstacles
But a real-word DApp. -> real-world
on-chain off-chain for testing -> on-chain, off-chain for testing
function of state verification off-chain is a rehearsal or replay of function of state verification off-chain. -> … a rehearsal or replay of function of state verification on-chain
let's define the function of state verification and expect it be be 0. -> delete the extra be

Most of them will be fixed by github suggestions above, except

re-implement function of state verification on-chain off-chain for testing;

which intentionally means

re-write the logic(implemented with rust) runs in ckb-vm on the chain with another programming language, such as JavaScript, and run them in a js vm off the chain for testing state transition functions.

So I prefer to turn it into

re-implement function of state verification on-chain off the chain for testing;

It may be still clumsy, and feel free to revise it.

[Keith-CY]

@zhengjianhui @pygman @Daryl-L This proposal is a good starting point for the kuai project, please have a review