Open Keith-CY opened 1 year ago
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?
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
?
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
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
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
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
Store of Token A
Store of Token B
.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.
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.
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?
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?
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.
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
Store of Token A
(covers all addresses holding this token)Store of Partial Token A belongs to user and swap_pool
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
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?
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.
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.
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.
Do users need to sign transaction via MetaMask?
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
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.
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)
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?
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
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.
@zhengjianhui @pygman @Daryl-L This proposal is a good starting point for the kuai project, please have a review
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