Support infrastructural scripts on devnet #235

Keith-CY · 2023-04-12T16:19:50Z

The following are the most prevailing scripts that not provided on devnet by default

Anyone can pay: https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0026-anyone-can-pay/0026-anyone-can-pay.md
Simple UDT: https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0025-simple-udt/0025-simple-udt.md
CoTA: unrevealed
Omnilock: https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0042-omnilock/0042-omnilock.md

But they are widely used in dapps, and are usually inevitable in dapp development. It would be quite helpful if they are out-of-the-box in kuai

Daryl-L · 2023-04-23T04:35:38Z

What I designed is as follow.

First, I will provider a method named depolyInfraScripts in CkbDockerNetwork for cli to call, cli will call this method immediately while the node starting. Then I will create a folder which stores the scripts should be deployed.

In file

kuai/packages/core/src/builtin-tasks/node.ts

Line 27 in 11d213d

const ckbDockerNetwork = new CkbDockerNetwork()

const ckbDockerNetwork = new CkbDockerNetwork()
await ckbDockerNetwork.start({
  port: port.toString(),
  detached,
  genesisAccountArgs: genesisArgs,
})
await ckbDockerNetwork.depolyInfraScripts()

Create a folder to store scripts in package docker-node.

- docker-node
- - scripts
- - - sudt
- - - omnilock
- - - acp

In file

kuai/packages/docker-node/src/ckb-docker-network.ts

Line 9 in 11d213d

export class CkbDockerNetwork {

deploy() {
  // load scripts bin from scripts file
  // deploy them by prepared account
  // output the cell info of deployed scripts to command line and file

What I inspires me is Force Bridge. https://github.com/Magickbase/force-bridge/blob/feature-nervos-to-ethereum/offchain-modules/packages/x/src/ckb/tx-helper/deploy.ts
Please correct me if I was wrong.

Keith-CY · 2023-04-23T05:32:02Z

What I designed is as follow.

First, I will provider a method named depolyInfraScripts in CkbDockerNetwork for cli to call, cli will call this method immediately while the node starting. Then I will create a folder which stores the scripts should be deployed.

In file

kuai/packages/core/src/builtin-tasks/node.ts

Line 27 in 11d213d

const ckbDockerNetwork = new CkbDockerNetwork()
const ckbDockerNetwork = new CkbDockerNetwork()
await ckbDockerNetwork.start({
  port: port.toString(),
  detached,
  genesisAccountArgs: genesisArgs,
})
await ckbDockerNetwork.depolyInfraScripts()
Create a folder to store scripts in package docker-node.
- docker-node
- - scripts
- - - sudt
- - - omnilock
- - - acp
In file

kuai/packages/docker-node/src/ckb-docker-network.ts

Line 9 in 11d213d

export class CkbDockerNetwork {
deploy() {
  // load scripts bin from scripts file
  // deploy them by prepared account
  // output the cell info of deployed scripts to command line and file
What I inspires me is Force Bridge. Magickbase/force-bridge@feature-nervos-to-ethereum/offchain-modules/packages/x/src/ckb/tx-helper/deploy.ts Please correct me if I was wrong.

An entry to extend the script list on devnet should be provided for users to add custom scripts.

Since we're going to support the deployment of multiple contracts(#230) and binaries(#231), how about specifying a directory full of contract binaries and a metadata file as an index of the contracts to deploy, e.g.

{
  "sudt": {
    "path": "built-in/sudt"
  },
  "custom": {
    "path": "./custom"
  }
}

And the deployed tx info will be appended into the metadata file for reference in dapp.

Daryl-L · 2023-04-23T06:40:25Z

What I designed is as follow.
First, I will provider a method named depolyInfraScripts in CkbDockerNetwork for cli to call, cli will call this method immediately while the node starting. Then I will create a folder which stores the scripts should be deployed.
In file

kuai/packages/core/src/builtin-tasks/node.ts

Line 27 in 11d213d

const ckbDockerNetwork = new CkbDockerNetwork()
const ckbDockerNetwork = new CkbDockerNetwork()
await ckbDockerNetwork.start({
  port: port.toString(),
  detached,
  genesisAccountArgs: genesisArgs,
})
await ckbDockerNetwork.depolyInfraScripts()
Create a folder to store scripts in package docker-node.
- docker-node
- - scripts
- - - sudt
- - - omnilock
- - - acp
In file

kuai/packages/docker-node/src/ckb-docker-network.ts

Line 9 in 11d213d

export class CkbDockerNetwork {
deploy() {
  // load scripts bin from scripts file
  // deploy them by prepared account
  // output the cell info of deployed scripts to command line and file
What I inspires me is Force Bridge. Magickbase/force-bridge@feature-nervos-to-ethereum/offchain-modules/packages/x/src/ckb/tx-helper/deploy.ts Please correct me if I was wrong.
An entry to extend the script list on devnet should be provided for users to add custom scripts.

Since we're going to support the deployment of multiple contracts(#230) and binaries(#231), how about specifying a directory full of contract binaries and a metadata file as an index of the contracts to deploy, e.g.
{
  "sudt": {
    "path": "built-in/sudt"
  },
  "custom": {
    "path": "./custom"
  }
}
And the deployed tx info will be appended into the metadata file for reference in dapp.

That's a good idea. I will change the file as follow.

{
  "sudt": {
    "path": "built-in/sudt",
    // will be added to file after the deployment
    "cellDep": {
        "depType": "${code}",
        "outPoint": {
          "txHash": "${txHash}",
          "index": "0x0",
        },
      },
      "script": {
        "codeHash": "${codeHash}",
        "hashType": "data"
      }
}

yanguoyu · 2023-04-23T07:24:16Z

Should we need to consider how to deploy a contract that depType is depGroup, it may need to deploy twice, once to deploy the contract with code, and once to deploy reference of the code contract cell and other dep cells.

Keith-CY · 2023-04-23T07:27:32Z

Should we need to consider how to deploy a contract that depType is depGroup, it may need to deploy twice, once to deploy the contract with code, and once to deploy reference of the code contract cell and other dep cells.

Please cover this in the contract deployment by kuai-cli @PainterPuppets

Daryl-L · 2023-04-23T15:28:52Z

Should we need to consider how to deploy a contract that depType is depGroup, it may need to deploy twice, once to deploy the contract with code, and once to deploy reference of the code contract cell and other dep cells.

{
"builtIn": [
  {
    "name": "sudt",
    "path": ["built-in/sudt"],
    // will be added to file after the deployment
    "cellDep": {
      "depType": "code",
      "outPoint": {
        "txHash": "${txHash}",
        "index": "0x0"
      }
    },
    "script": {
      "codeHash": "${codeHash}",
      "hashType": "data"
    }
  }
],
"custom": [
 {
    "name":  "custom",
    "path": ["custom1"],
    // will be added to file after the deployment
    "cellDep": {
      "txHash": {
        "txHash": "${txHash}",
        "index": "0x0"
      },
      "depType": "depGroup",
      "cellDeps": [
        {
          "txHash": {
            "txHash": "${txHash}",
            "index": "0x0"
          }, 
          "depType": "code"
        }
      ]
    }
  }
]

Set deps while the dep type is dep group.

Daryl-L · 2023-04-28T06:26:15Z

Another point, should we place the binary files into the repo? I think there are three ways to provide the built-in contracts

place the binary files into the repo directly.
use submodule from https://github.com/nervosnetwork/ckb-production-scripts, build the contracts when install kuai
developers clone the https://github.com/nervosnetwork/ckb-production-scripts and build the contracts themselves, place the path into config file which will be provided to the kuai-cli command

@Keith-CY @yanguoyu @zhangyouxin @PainterPuppets I prefer the first way.

Keith-CY · 2023-04-28T06:33:23Z

Another point, should we place the binary files into the repo? I think there are three ways to provide the built-in contracts

place the binary files into the repo directly.

use submodule from nervosnetwork/ckb-production-scripts, build the contracts when install kuai

developers clone the nervosnetwork/ckb-production-scripts and build the contracts themselves, place the path into config file which will be provided to the kuai-cli command

@Keith-CY @yanguoyu @zhangyouxin @PainterPuppets I prefer the first way.

Building on users' PC is unacceptable because it requires the setup of develop environment.

Another option is to build binaries by CI and publish them in an independent repo, as a git submodule of kuai

Ref:
git submodule: https://git-scm.com/book/en/v2/Git-Tools-Submodules

homura · 2023-04-28T07:20:04Z

Is this ticket already is in development? Maybe we can reuse the e2e node of Nexus's ckb-js/nexus#239

Keith-CY · 2023-04-28T07:38:16Z

Is this ticket already is in development? Maybe we can reuse the e2e node of Nexus's ckb-js/nexus#239

We're still designing it. This topic has been discussed in discord channel and can be continued there because it covers not only these two projects. We can even propose a project for e2e test in various projects.

homura · 2023-05-04T08:06:17Z

There is a simple CKB wrapper is implemented in Nexus, with some use cases like claiming devnet token from genesis UTxO

Daryl-L · 2023-05-05T04:22:36Z

There is a simple CKB wrapper is implemented in Nexus, with some use cases like claiming devnet token from genesis UTxO

So with this wrapper, we can run the dev node without docker, right?

homura · 2023-05-05T05:01:56Z

So with this wrapper, we can run the dev node without docker, right?

You're right, the wrapper will

download CKB if it is not downloaded
run the CKB via an unused port

Daryl-L · 2023-05-05T06:27:44Z

So with this wrapper, we can run the dev node without docker, right?

You're right, the wrapper will

download CKB if it is not downloaded

run the CKB via an unused port

I'll have a try in kuai

Daryl-L · 2023-05-08T07:42:32Z

I copied the code from nexus, and made some necessary modification, to instead of using docker node. And then I will create a repo to publish the binary files of built-in scripts for kuai to download. The binary files will be placed in OS cache directory as nexus did. Is that ok?

@Keith-CY @homura @yanguoyu @PainterPuppets @zhengjianhui

The PR will be updated tomorrow after fully test.

yanguoyu · 2023-05-08T08:20:39Z

So we will not use docker to start ckb dev chain? But if we start testnet or mainnet we can still use docker?

Keith-CY · 2023-05-08T09:12:43Z

So we will not use docker to start ckb dev chain? But if we start testnet or mainnet we can still use docker?

Any feedback from lumos users that complain about launching ckb node? @homura @zhangyouxin @PainterPuppets @IronLu233

homura · 2023-05-08T09:22:14Z

Any feedback from lumos users that complain about launching ckb node?

Lumos will only launch a CKB node when run its E2E testing, so the users of Lumos do not need to install a Docker or CKB node

Keith-CY · 2023-05-08T09:29:26Z

Any feedback from lumos users that complain about launching ckb node?

Lumos will only launch a CKB node when run its E2E testing, so the users of Lumos do not need to install a Docker or CKB node

So we can assume that users of lumos can host their own node successfully.

But after consideration, I think it is necessary to use docker for the production environment because we may recommend users to deploy projects built by kuai via docker.

Keith-CY · 2023-05-10T05:57:04Z

PR: #257

Keith-CY added the documentation Improvements or additions to documentation label Apr 12, 2023

Keith-CY assigned Daryl-L Apr 19, 2023

Daryl-L mentioned this issue May 5, 2023

feat(dev-scripts): add deployment for dev scripts #257

Merged

Keith-CY closed this as completed Jun 7, 2023

Keith-CY mentioned this issue Jun 21, 2023

Support caching and loading deployment information of contracts #334

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support infrastructural scripts on devnet #235

Support infrastructural scripts on devnet #235

Keith-CY commented Apr 12, 2023 •

edited

Loading

Daryl-L commented Apr 23, 2023

Keith-CY commented Apr 23, 2023

Daryl-L commented Apr 23, 2023

yanguoyu commented Apr 23, 2023

Keith-CY commented Apr 23, 2023

Daryl-L commented Apr 23, 2023 •

edited

Loading

Daryl-L commented Apr 28, 2023

Keith-CY commented Apr 28, 2023 •

edited

Loading

homura commented Apr 28, 2023

Keith-CY commented Apr 28, 2023

homura commented May 4, 2023

Daryl-L commented May 5, 2023

homura commented May 5, 2023

Daryl-L commented May 5, 2023

Daryl-L commented May 8, 2023

yanguoyu commented May 8, 2023

Keith-CY commented May 8, 2023

homura commented May 8, 2023

Keith-CY commented May 8, 2023

Keith-CY commented May 10, 2023

Support infrastructural scripts on devnet #235

Support infrastructural scripts on devnet #235

Comments

Keith-CY commented Apr 12, 2023 • edited Loading

Daryl-L commented Apr 23, 2023

Keith-CY commented Apr 23, 2023

Daryl-L commented Apr 23, 2023

yanguoyu commented Apr 23, 2023

Keith-CY commented Apr 23, 2023

Daryl-L commented Apr 23, 2023 • edited Loading

Daryl-L commented Apr 28, 2023

Keith-CY commented Apr 28, 2023 • edited Loading

homura commented Apr 28, 2023

Keith-CY commented Apr 28, 2023

homura commented May 4, 2023

Daryl-L commented May 5, 2023

homura commented May 5, 2023

Daryl-L commented May 5, 2023

Daryl-L commented May 8, 2023

yanguoyu commented May 8, 2023

Keith-CY commented May 8, 2023

homura commented May 8, 2023

Keith-CY commented May 8, 2023

Keith-CY commented May 10, 2023

Keith-CY commented Apr 12, 2023 •

edited

Loading

Daryl-L commented Apr 23, 2023 •

edited

Loading

Keith-CY commented Apr 28, 2023 •

edited

Loading