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

Synchronous contract calls: concordium client #108

Closed
3 tasks
abizjak opened this issue Jan 8, 2022 · 0 comments · Fixed by #107
Closed
3 tasks

Synchronous contract calls: concordium client #108

abizjak opened this issue Jan 8, 2022 · 0 comments · Fixed by #107
Assignees
Labels
[Prio] High An urgent problem that blocks the system use until the issue is resolved. [Type] Task An additional feature or improvement.

Comments

@abizjak
Copy link
Contributor

abizjak commented Jan 8, 2022

Task description

In connection with Concordium/concordium-node#236 concordium-client needs to be updated to support V1 contracts.

The high-level requirements are

  • concordium-client must still allow to deploy and inspect existing contract types, as well as working with new contracts
  • add ability to invoke contracts locally on the node (InvokeContract endpoint)

There should be a general change in handling module deployment. Previously concordium-client added the module version and took just a wasm file as input. In order to reduce errors this should be changed. cargo-concordium will be changed to output a versioned output.

To support deployment of raw Wasm modules we could still support a --version option which would add that version to a raw wasm file before deployment.

Sub-tasks

  • Add raw InvokeContract command to invoke the contract for testing
  • Add a high-level contract invoke command that requires less input, or more friendly input, from the user
  • Allow deploying and inspecting V1 modules analogously as V0 are now. The client should figure out itself which version it retrieved. THe main difference between V0 and V1 modules will be in the module schema. V1 modules will have a different schema, and the semantics of entrypoints will be different, which should be reflected in the the pretty output.
@abizjak abizjak added [Prio] High An urgent problem that blocks the system use until the issue is resolved. [Type] Task An additional feature or improvement. labels Jan 8, 2022
@abizjak abizjak linked a pull request Jan 8, 2022 that will close this issue
5 tasks
@abizjak abizjak self-assigned this Jan 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Prio] High An urgent problem that blocks the system use until the issue is resolved. [Type] Task An additional feature or improvement.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant