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

[client library] decouple extrinsics related ability as library #1140

Closed
extraymond opened this issue Jun 2, 2023 · 2 comments · Fixed by #1181
Closed

[client library] decouple extrinsics related ability as library #1140

extraymond opened this issue Jun 2, 2023 · 2 comments · Fixed by #1181

Comments

@extraymond
Copy link

extraymond commented Jun 2, 2023

Info

background:
This is a proposal similar to #659, this time targeted extrinsics.

Since now we have both contract-transcode and contract-metadata as isolated libraries, any smart contract that is compatible with the metadata version can:

  • use it to load the contract bundle
  • use the transcoder to encode, decode the payload and event output.

Currently for live testing contracts against pallet-contract, most likely one will end up setup subxt and use the contract-metadata, contract-transcode to test it's logic and input and output.
Operation around uploading/deploying/calling/reading is regularly involved when testing against live environment. If we can extract those extrinsics ops out, it might make writing testing framework or other alternative clients more easily.

proposal:
Expose most of crates/cargo-contract/src/cmd/extrinsics as library, so it can be reused or embedded in other projects.

hyperledger/solang#990 is an in progress PR of creating tests against solang compiled solidity contracts using subxt, as you can see here, most of the setup code is achieving very similar goals like cargo-contract does in the cmd module.

The end result of this proposal will definitely let solang stay close to the testing environment cargo-contract currently have to iron up rough edges, and perhaps open up other limitation not needed by ink contracts but important to other smart contract runtime running on top of pallet-contracts.
For example contract-metadata currently don't support I256, U256 type which solang supports, which the contract-transcode will refuse to encode input for solang if those types are summoned.

effected use cases:
the developer experience of the following use cases will most likely be improved due to less hand-rolled setup code.

  • testing contract logic and state changes against a running chain
  • testing against chain built-ins or extensions that through contract output
  • incorporated into clients to have preliminary ability to upload/call/read contract, e.g solang CLI.

C.C @xermicus

@xermicus
Copy link
Contributor

xermicus commented Jun 5, 2023

I support this, this is a worthwhile proposal not only for Solang but anyone wanting to "just" deploy or call contracts in rust.

@ascjones
Copy link
Collaborator

ascjones commented Jun 5, 2023

Indeed I have wanted to extract the extrinsics in a similar manner to the contract-build library, it would be good to have a similar separation here.

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

Successfully merging a pull request may close this issue.

3 participants