Proposal of kuai project

[Keith-CY]

• Superficial problems
  • Separate runtimes
    • Verification on chain
    • Data construct(computation) off chain
  • Fragmented devtools
• Underlying problems
  • An dapp includes an on-chain contract state verification logic and an off-chain data management workflow
    • Functional Programming in on-chain verification
    • Functional Programming in off-chain data management
    • OOP on manipulating off-chain data when interact with dapp
  • Lack of unified development paradigm
    • Uniformity on engineering
      • project structure
      • workflow
    • Composability on logics
      • interoperable models among dapps
  • Lack of devtools
    • Local network
    • Compile/Debug/Test
    • Deploy
• How other ecologies are solving these problems
  • Engineering
    • hardhat
  • UTXO development paradigm
    • run
• Target
  • Unified paradigm for development

    • Data storage

      • Basic Models/data structures
        • Data: for plain data storage
        • Code: extended from Data, for running scripts
        • MultiCoin Token: extended from Code, for token management

    • Data manipulation

      • Data
        • Sync: load data from chain
        • Get/Set/Delete: update data
        • New/Destroy/Duplicate: create/destroy data model
      • Code
        • Deploy:
        • Extend:
        • Upgrade:
        • Run: call a method
        • Link:
      • Token
        • Define
          • Name
          • Symbol
          • Token URI
          • Total Supply
        • Mint/Burn
        • Send
        • Stake/Redeem
        • Lock/Unlock
        • Combine
        • Get Balance

    • Reactive Lazy Evaluation

      • const model = new Data(init_value) | action_1 | action_2 | … | action_3 =>

      Struct {
      value
      actions: Action[]
      }

      • model will be finalized on consumption
      • With lazy evaluation
        • the state of model can be traversed
        • actions can be revoked easily
        • inspector(or other dependencies) could be injected for debug
  • Fine grind devtools
    • Clear project structure
    • Compile
      • debug
      • release
    • Debug
      • break
      • console
      • inspector
    • Test
      • run specific cases
    • Deployment
    • Configuration management
      • multiple network
      • hd wallet
    • Base contracts/scripts
• Resources
  • 6 developers
  • 6 months
• Roadmap
  • M1 ~ M2
    • build system similar to https://nx.dev/, only for project structure, basic tasks, and plugins
    • design storage paradigm
    • design action paradigm
    • design workflow with base contracts/scripts
  • M3 ~ M4
    • implements sdk following the designed paradigm and workflow with base contract/scripts
    • design generally used tasks and plugins
      • cycle reporter
      • script sizer
      • test-coverage
      • document
      • debugger remover
      • typechain: https://github.com/dethcrypto/TypeChain/
      • storage layout: https://www.npmjs.com/package/hardhat-storage-layout, when to use on-chain/off-chain data
    • design local network debug/test/deploy tools
  • M5
    • implement tasks/plugins
    • implement local network
    • implement debug/test/deploy tools
  • M6
    • Use the project to deliver a simple .bit dapp

[felicityin]

1 Background

Ethereum itself is a server, because it can not only change state, but also store state. Developers only need to implement client. In contrast to CKB, it can only store state. Moreover, the storage on CKB is expensive, so the data should be stored in off-chain as much as possible.
In summary, developers need to implement an additional server on top of CKB to change and store state. While CKB uses the UTXO programming model, which is difficult to understand. In addition, developers need to know a lot of details about CKB in the process of implementing the server, such as Cell model. It caused a lot of inconvenience to developers.
To make it easier to develop on CKB, Kuai will provide a javascript-based development framework to help developers create high-quality services more efficiently.

2 What is Kuai

Kuai is not a server, but a development framework.

Kuai will provide developers with a more friendly API for off-chain development. It helps developers change and store state in off-chain more conveniently, while only one proof of many state changes is stored in on-chain.

3 Component

Kuai includes kuai-runner, kuai-convention, kuai-runtime, and kuai-testing.

3.1 kuai-runner

At present, it is cumbersome to set up a CKB development environment locally, and developers need to know a lot of details, such as the configuration files of indexer and CKB.

kuai-runner will provide a one-click launch method to help developers to set up a development environment easily, such as:

• Creates project templates with by CLI. And the project should include both on-chain and off-chain parts.
• kuai.config.js - The configuration of a node, account and other information. It will provide the devnet related configuration by default.
• kuai node start|stop|restart - Start and stop the local devnet node.
• kuai contract build|test|deploy - 1) Compile the contract. 2) Test the contract, and output the test results. 3) Deploy the contract to the node according to the configuration, and output the DeploymentConfig.

3.2 kuai-convention(maybe kuai-protocol)

As a framework, Kuai should provide clear boundaries and development standards, and provide a list of best practice tips for developers to follow.

kuai-convention is a convention document for the implementation reference of kuai-runtime and the usage guide of kuai-runtime, such as:

• project structure
• off-chain service - Conventions on how to write business logic in off-chain. Which data types will be supported by Kuai, etc.
• sequencer - Define how to sort user requests.
• storage - A series of schemes on how to persist data, such as serialization schemes, etc.
• [TBD] Interoperability between kuai apps.

3.3 kuai-runtime

kuai-runtime implements the interface defined by kuai-convention, shielding implementation details for developers and provides easy-to-use APIs.

kuai-runtime provides friendly libraries/modules for building, sending, and managing transactions.

Developers can build services quickly by kuai-runtime.

The composition of kuai-runtime is as follows.

• Merkle X Storage - Generate proof which stored in on-chain. And persist data in off-chain.
• Sequencer - Combine multiple requests into one to avoid concurrency issue.
• Transaction Builder Factory (OnChainStateUpdator) - Build transactions that update on-chain state.
• CkbNodeClient - Interact with chains, such as query transaction status, etc.
• Client-side SDK - Common wallet integration, e.g MetaMask(sign via EIP712 if possible), TronLink, CardanoWallet…
• Scheduler - Scheduling various sub-services, such as Sequencer and Merkle X Storage.

3.4 kuai-testing

Testing is an important part of the software development process. And Kuai should provide modules that integrate with common testing frameworks on the market to help developers perform integration testing of the entire business process (dapp → service → CKB → assertion).

kuai-testing will provide a friendly integration testing environment, such as:

• Simulate a user to send a transaction.
• May provide a test package that provides methods such as deploy(), clearState().

3.5 kuai-website

As an open source project, Kuai needs to provide good documentation and examples to attract and guide developers.

kuai-website provides friendly development documentation, such as:

• Tutorial
• Developer Documentation
• API Documentation

4 Roadmap

• M1 - Complete kuai-runner. Design kuai-convention.
• M2 - Complete kuai-convention design. Implement kuai runner.
• M3 - Implement kuai-runtime.
• M4 - Implement kuai-runtime.
• M5 - Design and implement kuai testing. Start a demo for domain service via kuai runtime
• M6 - Adjust kuai implementation for completing the domain service.

[yanguoyu]

Code
Run: call a method

Is it means to use a deployed contract? Like for cheque contract, send a cheque, claim, or withdraw?

Data storage
Data manipulation

Is it means to get cell data from chain? And we can use data to deploy contracts, call contracts, or get information.

@Keith-CY

[yanguoyu]

kuai-convention

I thought of two ways for kuai-convention to provide for users. We shouldn't limit user development contracts in one way.

• Create some templates that let the user choose. For example, a storage template is a better way to persist data, or a basic simple template just shows syscall what can we do in the contract.
  • Strong point: It is easy to use, only need to download template files.
  • Weak point: For every developed paradigm we need to provide a template.
• Deploy some plugins with contract language for the template, so that users can choose plugins when creating a project.
  • Strong point: It's easy to expand, and may combine many developed paradigms.
  • Weak point: We need to consider how to use plugins in a project and combine some plugins.

I prefer the second method, we can accumulate many useful plugins to improve development efficiency.

[felicityin]

I thought of two ways for kuai-convention to provide for users. We shouldn't limit user development contracts in one way.

You are right, but kuai-convention focuses on off-chain services, rather than on-chain contracts.

[Keith-CY]

Code
Run: call a method

Is it means to use a deployed contract? Like for cheque contract, send a cheque, claim, or withdraw?

Yes, Run is used to call a method of the script/contract (Code model). We can use the simple command as the most underlying method to change the state of the Data model from which Code model extends. And derive a contract object with user-friendly APIs from Code model with ABI (TypeChain)

Data storage
Data manipulation

Is it means to get cell data from chain? And we can use data to deploy contracts, call contracts, or get information.

@Keith-CY

Data storage and Data manipulation are mentioned in the Unified paradigm for development section, the main idea is to make base APIs uniform so all dapps following the paradigm could interact with each other smoothly.

Say DApp_A has Model A on the chain and it's derived from Code Model/Data Model, then the Model A's data are transparent to all and can be parsed and shown in every other DApp. Besides, if Model A's ABI is public, DApp_B could overlap its own business logic over DApp_A, just like extends ERC 20 Token

Once the rule is omnipresent, all DApps are connected to each other.

Back to question 2

Is it means to get cell data from chain? And we can use data to deploy contracts, call contracts, or get information.

Yes, data storage includes reading/writing data in a prescribed way, and data manipulation means updating data in a well-known way.

[Keith-CY]

The proposal has been drafted by #5