Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add deploy contract command #242

Merged
merged 5 commits into from
May 16, 2023
Merged

feat: add deploy contract command #242

merged 5 commits into from
May 16, 2023

Conversation

PainterPuppets
Copy link
Contributor

@PainterPuppets PainterPuppets commented Apr 19, 2023

  • add deploy contract command

image

deploy contract workflow:

    1. kuai contract new --name [contract-name]
image
    1. kuai contract build --release
image
    1. kuai contract deploy --name [contract-name] --from [0x.....] --signer ckb-cli
image

Tips: How to deploy contract to other network

  • kuai contract deploy --name [contract-name] --from [0x.....] --network [networkname]
  • or set network to .env file

Tips: add more network config

Kuai currently has three default settings for networks, testnet / mainnet / devnet, and users can also add custom network

  • edit kuai.config.js of project and add network tor networks field
networks: {
    [networkname: string]: {
        rpcUrl: string
        prefix: string
        scripts?: Record<string, ScriptConfig>
    }
}

packages/core/package.json Outdated Show resolved Hide resolved
packages/core/src/builtin-tasks/contract.ts Outdated Show resolved Hide resolved
packages/core/src/builtin-tasks/contract.ts Outdated Show resolved Hide resolved
packages/core/src/builtin-tasks/contract.ts Outdated Show resolved Hide resolved
packages/core/src/builtin-tasks/contract.ts Outdated Show resolved Hide resolved
packages/core/src/builtin-tasks/contract.ts Outdated Show resolved Hide resolved
packages/core/src/builtin-tasks/contract.ts Outdated Show resolved Hide resolved
packages/core/src/builtin-tasks/contract.ts Outdated Show resolved Hide resolved
packages/core/src/builtin-tasks/contract.ts Outdated Show resolved Hide resolved
packages/core/src/builtin-tasks/contract.ts Outdated Show resolved Hide resolved
packages/core/src/type/runtime.ts Outdated Show resolved Hide resolved
packages/core/src/type/runtime.ts Outdated Show resolved Hide resolved
paramTypes.string,
true,
)
.setAction(async ({ name, chain, fee, env, migrate, ...args }: DeployArgs, { config, run }) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about extracting the code of deployment so that we can use it to deploy the infra scripts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Keith-CY
Copy link
Member

How is it going

@PainterPuppets
Copy link
Contributor Author

PainterPuppets commented May 4, 2023

The contract module of kuai needs a way to manage and organize, and some parts of the current contract management by capsule do not meet the needs

For example:
- capsule has its own directory structures, which can cause some confusion when using kuai
- deploy contracts by capsule can only be signed by ckb-cli, which can be a strange process
- It is not possible to deploy multiple contracts in a single transaction

So kuai needs to deploy contract code through lumos in order to meet the flexible deploy methods, which will make capsule's ability to organize contracts invalid, so kuai itself needs a way to organize contracts

For this reason, the following three structures are defined, where the ContractManager is used to manage contract information and some configuration. The Contract is the entity for individual contract information, and KuaiContractMigration is generated after each deployment to track the deployment

export interface ContractManager {
	contracts: KuaiContract[]

	newContract: (name: string, template?: 'rust' | 'c' | 'c-sharedlib')
	build: (name: string) => void
	createDeployTx: (name: string, deployer: Address) => Promise<Transaction>
	createUpgradeTx: (name: string, deployer: Address) => Promise<Transaction>
	commitTx: (name: string, witnesses: string[]) => Promise<Hash>
}

interface KuaiContract {
	name: string
	templateType: string
	srcPath: string
	binPath: string
	deployType: 'data' | 'typeId'
	migrations: KuaiContractMigration[]
}

interface KuaiContractMigration {
	chain: string
	txHash: Hash
	index: number
	dataHash: Hash
	typeId: Hash
}

Specific implementation details:
When call newContract, use capsule to generate the code by template
When call build, use capsule to build the contract file (perhaps in the future can support direct build)

deploy process:
kuai-cli calls createDeployTx of the ContractManager to generate the tx, which is then signed by a user-selected signature method (e.g. ckb-cli / metamask / other...)
kuai-cli calls the ContractManager's commitTx to commit the tx to the chain

@Keith-CY
Copy link
Member

Keith-CY commented May 4, 2023

The contract module of kuai needs a way to manage and organize, and some parts of the current contract management by capsule do not meet the needs

For example: - capsule has its own directory structures, which can cause some confusion when using kuai - deploy contracts by capsule can only be signed by ckb-cli, which can be a strange process - It is not possible to deploy multiple contracts in a single transaction

So kuai needs to deploy contract code through lumos in order to meet the flexible deploy methods, which will make capsule's ability to organize contracts invalid, so kuai itself needs a way to organize contracts

For this reason, the following three structures are defined, where the ContractManager is used to manage contract information and some configuration. The Contract is the entity for individual contract information, and KuaiContractMigration is generated after each deployment to track the deployment

export interface ContractManager {
	contracts: KuaiContract[]

	newContract: (name: string, template?: 'rust' | 'c' | 'c-sharedlib')
	build: (name: string) => void
	createDeployTx: (name: string, deployer: Address) => Promise<Transaction>
	createUpgradeTx: (name: string, deployer: Address) => Promise<Transaction>
	commitTx: (name: string, witnesses: string[]) => Promise<Hash>
}

interface KuaiContract {
	name: string
	templateType: string
	srcPath: string
	binPath: string
	deployType: 'data' | 'typeId'
	migrations: KuaiContractMigration[]
}

interface KuaiContractMigration {
	chain: string
	txHash: Hash
	index: number
	dataHash: Hash
	typeId: Hash
}

Specific implementation details: When call newContract, use capsule to generate the code by template When call build, use capsule to build the contract file (perhaps in the future can support direct build)

deploy process: kuai-cli calls createDeployTx of the ContractManager to generate the tx, which is then signed by a user-selected signature method (e.g. ckb-cli / metamask / other...) kuai-cli calls the ContractManager's commitTx to commit the tx to the chain

How about accepting a deployer config instead of deployer in createDeployTx and updateDeployer so it's easy to extend to deploy/update contracts with multisig

Ref: #233

@yanguoyu
Copy link
Contributor

yanguoyu commented May 5, 2023

kuai-cli calls createDeployTx of the ContractManager to generate the tx, which is then signed by a user-selected signature method (e.g. ckb-cli / metamask / other...)

I think we can support signed by kuai, then developers will not need to know more tools.

@Keith-CY
Copy link
Member

Keith-CY commented May 5, 2023

kuai-cli calls createDeployTx of the ContractManager to generate the tx, which is then signed by a user-selected signature method (e.g. ckb-cli / metamask / other...)

I think we can support signed by kuai, then developers will not need to know more tools.

Upvote, only kuai-cli should be exposed to reduce confusion.

@PainterPuppets
Copy link
Contributor Author

kuai-cli calls createDeployTx of the ContractManager to generate the tx, which is then signed by a user-selected signature method (e.g. ckb-cli / metamask / other...)

I think we can support signed by kuai, then developers will not need to know more tools.

Does support for signature by "kuai" mean wrapping "ckb-cli" or using the keystore directly?

@Keith-CY
Copy link
Member

Keith-CY commented May 5, 2023

kuai-cli calls createDeployTx of the ContractManager to generate the tx, which is then signed by a user-selected signature method (e.g. ckb-cli / metamask / other...)

I think we can support signed by kuai, then developers will not need to know more tools.

Does support for signature by "kuai" mean wrapping "ckb-cli" or using the keystore directly?

It's about the detail of implementation, but ckb-cli requires private key on the disk, which is not recommended.

@Keith-CY
Copy link
Member

Keith-CY commented May 8, 2023

How is it going @PainterPuppets

@PainterPuppets
Copy link
Contributor Author

Have implemented the ContractManager part, is doing the deployment of the signature part, because the keystore built into the kuai spend more time, so are packing ckb-cli signature part, is expected to be completed and submit tomorrow

@Keith-CY

@Keith-CY
Copy link
Member

Keith-CY commented May 8, 2023

Have implemented the ContractManager part, is doing the deployment of the signature part, because the keystore built into the kuai spend more time, so are packing ckb-cli signature part, is expected to be completed and submit tomorrow

@Keith-CY

Looking forward to it

@Keith-CY
Copy link
Member

Keith-CY commented May 9, 2023

How is it going

@PainterPuppets PainterPuppets force-pushed the add_deploy_command branch 2 times, most recently from 4b0219b to 1d45bd4 Compare May 9, 2023 21:44
@Keith-CY
Copy link
Member

Please update the usage in the PR message and I'll request some reviews from outside teams that may use kuai to deploy contracts.

@PainterPuppets
Copy link
Contributor Author

Please update the usage in the PR message and I'll request some reviews from outside teams that may use kuai to deploy contracts.

Updated, only the ckb-cli signature method is supported for now, but the extension point is left, I don't know what the outside teams is using for the signature, I can go add it

@Keith-CY
Copy link
Member

Keith-CY commented May 10, 2023

Please update the usage in the PR message and I'll request some reviews from outside teams that may use kuai to deploy contracts.

Updated, only the ckb-cli signature method is supported for now, but the extension point is left, I don't know what the outside teams is using for the signature, I can go add it

Should kuai's user keep their private key on the disk to sign the transaction with ckb-cli?


If so, signing a transaction with lumos should be considered, and the private key should be decrypted from a keystore file instead of reading a private key file

@Keith-CY
Copy link
Member

Please update the usage in the PR message and I'll request some reviews from outside teams that may use kuai to deploy contracts.

Updated, only the ckb-cli signature method is supported for now, but the extension point is left, I don't know what the outside teams is using for the signature, I can go add it

Should kuai's user keep their private key on the disk to sign the transaction with ckb-cli?

If so, signing a transaction with lumos should be considered, and the private key should be decrypted from a keystore file instead of reading a private key file

But it could be treated as a low-priority one, signing a transaction with secp256k1_blake160_multisig_all is more desired

@PainterPuppets
Copy link
Contributor Author

Please update the usage in the PR message and I'll request some reviews from outside teams that may use kuai to deploy contracts.

Updated, only the ckb-cli signature method is supported for now, but the extension point is left, I don't know what the outside teams is using for the signature, I can go add it

Should kuai's user keep their private key on the disk to sign the transaction with ckb-cli?

No, if sign with ckb-cli, need to import account in ckb-cli, but this part is the logic of ckb-cli, after that it should be possible to extend more signature methods, like metamask / Ledger / other...

@Keith-CY
Copy link
Member

Please update the usage in the PR message and I'll request some reviews from outside teams that may use kuai to deploy contracts.

Updated, only the ckb-cli signature method is supported for now, but the extension point is left, I don't know what the outside teams is using for the signature, I can go add it

Should kuai's user keep their private key on the disk to sign the transaction with ckb-cli?

No, if sign with ckb-cli, need to import account in ckb-cli, but this part is the logic of ckb-cli, after that it should be possible to extend more signature methods, like metamask / Ledger / other...

I see, so kuai doesn't care about where the private key in ckb-cli is from, it's reasonable

@PainterPuppets
Copy link
Contributor Author

If so, signing a transaction with lumos should be considered, and the private key should be decrypted from a keystore file instead of reading a private key file

I thought ahead about the multisg implementation, the specific logic part does not conflict with multisig, at the cli level it will probably look like this

kuai contract deploy --name [contract-name] --address [multisig_1] --address [multisig_2] --address [multisig_3] --network [networkname]

packages/core/package.json Outdated Show resolved Hide resolved
packages/core/src/ckbcli.ts Outdated Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tx information in block 0 is stable, can we use const variables to define this information?

packages/core/src/builtin-tasks/contract.ts Outdated Show resolved Hide resolved
packages/core/src/builtin-tasks/contract.ts Outdated Show resolved Hide resolved
packages/core/src/builtin-tasks/contract.ts Show resolved Hide resolved
packages/core/src/builtin-tasks/contract.ts Outdated Show resolved Hide resolved
packages/core/src/builtin-tasks/contract.ts Outdated Show resolved Hide resolved
packages/core/src/constants.ts Outdated Show resolved Hide resolved
packages/core/src/errors-list.ts Outdated Show resolved Hide resolved
packages/core/src/contract.ts Outdated Show resolved Hide resolved
import { RPC, config, utils } from '@ckb-lumos/lumos'

// Special cells in genesis transactions: (transaction-index, output-index)
const SpecialCellLocation: {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better to add a reference of this locations

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not quite sure where this reference can be found, these magic location is what I see in the source code of ckb-cli

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please refer to the code of ckb-cil, and I'll open an issue in ckb-cli repo for detailed info

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My bad, I didn't notice the comment above, which clearly implies the definition of [number, number] is [transaction-index, output-index]

Among them, SIGNHASH_GROUP, MULTISIG_GROUP, DAO can be found at https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0024-ckb-genesis-script-list/0024-ckb-genesis-script-list.md
SIGHASH, MULTISIG are not used normally. I'm not sure if these two will be used in our project.

Besides, we can use labeled tuple for readability

Ref: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-0.html#labeled-tuple-elements

...generateGenesisScriptConfig(...SpecialCellLocation['SIGHASH_GROUP']),
CODE_HASH: generateGenesisScriptConfig(...SpecialCellLocation['SIGHASH']).CODE_HASH,
DEP_TYPE: 'depGroup',
SHORT_ID: 0,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does SHORT_ID mean here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SHORT_ID is required for lumos to parse short address

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SHORT_ID is required for lumos to parse short address

I think it can be removed if it's not mandatory in lumos because short address is deprecated, and we should guide users not to use it.

@codecov-commenter
Copy link

codecov-commenter commented May 15, 2023

Codecov Report

❗ No coverage uploaded for pull request base (develop@01ec626). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             develop     #242   +/-   ##
==========================================
  Coverage           ?   68.59%           
==========================================
  Files              ?       84           
  Lines              ?     2305           
  Branches           ?      515           
==========================================
  Hits               ?     1581           
  Misses             ?      657           
  Partials           ?       67           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

feat: kuai contract support multisig deploy
@Keith-CY
Copy link
Member

I see feat: kuai contract support multisig deploy has been merged, and an example of 0/1 multisig tx was demonstrated in that PR.

My question is how to share the partially signed transaction via kuai, e.g. the contract should be deployed by 2/3 multisig, how should the 2 users to deploy the contract.

And the example could be appended in this PR because the PR of feat: kuai contract support multisig deploy will be inconspicuous when it's one commit of this PR

@Keith-CY
Copy link
Member

I see feat: kuai contract support multisig deploy has been merged, and an example of 0/1 multisig tx was demonstrated in that PR.

My question is how to share the partially signed transaction via kuai, e.g. the contract should be deployed by 2/3 multisig, how should the 2 users to deploy the contract.

And the example could be appended in this PR because the PR of feat: kuai contract support multisig deploy will be inconspicuous when it's one commit of this PR

This feature is required by other features(deploy contract on devnet, complete workflow of building a dapp) so let's merge it first, other details could be added later

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

5 participants