concordium / concordium-smart-contract-tools

Tools for building, deploying, and interacting with smart contracts

Concordium Smart Contract Tools

This repository contains tools to support smart contracts on and off-chain.

• cargo-concordium which is a small tool for developing smart contracts. It uses the API exposed in wasm-chain-integration to execute smart contracts directly and can initialize and update smart contracts, in a desired state. See the --help option of the tool for details on how to invoke it. It can also be used to build contracts embedded with schemas (see section about contract schemas).
• vscode-smart-contracts A VS Code extension providing snippets and the functionality of cargo-concordium as commands inside the editor.

Contributing

This repository's CI automatically checks formatting and common problems in rust. Changes to any of the packages must be such that

• cargo clippy --all produces no warnings
• rust fmt makes no changes.

Everything in this repository should build with stable rust at the moment (at least version 1.44 and up), however the fmt tool must be from a nightly release since some of the configuration options are not stable. One way to run the fmt tool is

 cargo +nightly-2022-06-09 fmt

(the exact version used by the CI can be found in .github/workflows/ci.yaml file). You will need to have a recent enough nightly version installed, which can be done via

rustup toolchain install nightly-2022-06-09

or similar, using the rustup tool. See the documentation of the tool for more details.

In order to contribute you should make a merge request and not push directly to master.

concordium-smart-contract-tools's Issues

Remove the use of ptree dependency

Description

The ptree dependency has not been updated for some time, and in particular it depends on nom version 5, which uses Rust features that will be deprecated

> warning: trailing semicolon in macro used in expression position
>    --> /home/abizjak/.cargo/registry/src/github.com-1ecc6299db9ec823/nom-5.1.2/src/combinator/macros.rs:509:35
>     |
> 509 |     map!(__impl $i, call!($f), $g);
>     |                                   ^
>     |
>    ::: /home/abizjak/.cargo/registry/src/github.com-1ecc6299db9ec823/nom-5.1.2/src/number/complete.rs:595:3
>     |
> 595 |   map!(i, le_u128, |x| x as i128)
>     |   ------------------------------- in this macro invocation
>     |
>     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
>     = note: macro invocations at the end of a block are treated as expressions
>     = note: to ignore the value produced by the macro, add a semicolon after the invocation of `map`
>     = note: `#[allow(semicolon_in_expressions_from_macros)]` on by default
>     = note: this warning originates in the macro `map` (in Nightly builds, run with -Z macro-backtrace for more info)

We use this for pretty printing the contract state as a key-value store. However that is not really useful for users since it is too complex.

We should either replace the use of ptree, or remove this state printing feature.

Provide command for smart contract templates in VS Code extension

The extension should provide a command for using cargo concordium init, which sets up a template project from a list of options.

Ideally, it would prompt the user for which template to use, but a simpler approach might be to just provide the default.

When running this command, it should ensure cargo-generate is installed, otherwise prompt the user whether to install it.

Update cargo-concordium for P6

Task description

Update cargo-concordium for protocol 6, so that module validation, etc. follows P6 semantics.

Automatically (re)compile module for integration tests

Task description

The testing library uses compiled smart contract modules for testing. This means that users must use cargo concordium build to build the module before the tests can run.
It also means that you must recompile your smart contract every time you make changes, otherwise, the tests will run against the "old code".
This task is about removing the need for manual compilation, which will also remove the risk of testing the incorrect, old, code.

Adding deployment/initialization features via scripts

Task description

Adding deplyment/initialization template scripts with some boilerplate code which can be created using cargo-generate command. It would reduce the number of tools a smart contract developer has to interact with (no concordium-client or our hosted frontend needed anymore) to get their protocol deployed on chain.

A new deploy/migrate template folder will be added to Concordium smart contract default template. This folder includes scripts and boilerplate code written in Rust which can be executed to deploy/initialize the smart contracts.

There are two distinguished flows supported to deploy the smart contracts with this template project.

• Automated flow: A given key file and URL to a node allows to run scripts locally and deploy the contracts by signing the transaction with the given key and sending it to the node. The local flow is recommended when developing the protocol actively since it is fully automated and speeds up the testing process on testnet.

• Frontend flow: A local backend server and a local frontend are spun up. The front end pulls periodically for new transaction requests that the backend creates based on the deployment scripts. This new transaction is not signed yet but in the correct format to be forwarded by the front end to the Concordium browser wallet where the transaction is signed and sent to the node that the Concordium browser wallet is connected to. The frontend flow is recommended to get a protocol live on mainnet using hardware wallets.

Sub-tasks

Automated flow:
e.g.

cargo run -- --node http://node.testnet.concordium.com:20000 --account ./3PXwJYYPf6fyVb4GJquxSZU8puxrHfzc4XogdMVot8MUQK53tW.export --modules ./default.wasm.v1 --modules ./default2.wasm.v1

Provide command for testing a smart contract in VS Code extension

The extension should provide commands for triggering cargo concordium test.

We should also provide a setting for additional arguments.

When running this command, it should ensure the wasm32-unknown-unknown target is installed, otherwise prompt the user whether to install it.

Smart contract integration testing library

Create a library that will allow smart contract developers to write automated integration tests similar to the one shown at the bottom of this description (API is still WIP and will very likely change):

Implementation progress

Primary functionality

• Create accounts
• Deploy modules
• Initialize contracts
• Update contracts
  • Without account transfers, contract invokes, or upgrades
  • With account transfers
    • With rollback of account balances
  • With contract invokes
    • Without rollbacks
    • With rollbacks
  • With upgrades
  • With queries
• Invoke contracts (view functions)

Remaining tasks

• Allow a Contract sender for contract_update/contract_invoke (currently only supports Account)
• Use changeset to handle contract upgrades (changing modules)
• Change the return type of contract_update_aux so it cannot return interrupts
• Structure code for better readability
  • Create module for handling contract entrypoint invocation (including the changeset, checkpoints and rollbacks)
  • Split into lib.rs, impl.rs, types.rs
  • Move integration tests to /tests
  • Move unit tests to appropriate files
• Use Parameter and ReturnValue types from base (perhaps adding helper functions)
• Add staked and locked balances to accounts.
• Add iterator over (ContractAddress, [ChainEvent]) for successful contract updates
• Verify energy usage (compare deployment, init, update and invoke with chain)
  • Deployment
  • Init
  • Update
  • Invoke
• Add remaining tests from the scheduler
  • All new host functions
  • Checkpointing
  • Counter
  • Cross messaging (between v0 and v1, won't do as v0 not supported)
  • Error codes
  • Fallback
  • Iterator
  • Queries
  • Recorder
  • Relaxed restrictions
  • Self balance
  • Transfers
  • Upgrading
  • Valid invalid modules (Won't do, as it relates to our module validation)
• Move a lot of things:
  • Scheduler tests to concordium base
    • Concordium/concordium-base#332
    • Concordium/concordium-node#762
  • Move ExchangeRates from concordium std to contracts-common
    • Concordium/concordium-rust-smart-contracts#239
    • Concordium/concordium-contracts-common#78
  • Move ContractTraceElement from Rust SDK to base
    • Concordium/concordium-base#341
    • Concordium/concordium-rust-sdk#79
  • Move AccountBalance from concordium-std to contracts-common
    • Concordium/concordium-rust-smart-contracts#227
    • Concordium/concordium-contracts-common#72
• Unification of types and some renaming
  • Concordium/concordium-contracts-common#73
  • Concordium/concordium-base#333
  • Concordium/concordium-rust-sdk#75
  • Concordium/concordium-rust-smart-contracts#230
  • Concordium/concordium-contracts-common#75
  • Concordium/concordium-base#334
  • Concordium/concordium-base#334
• Use manual stack to process recursive contract calls

Future tasks (will be separate tasks)

• Documentation in developer docs
• Get logs on failed contract invocations
• Set up configurable logging

Example integration test (API is still WIP)

fn test_sunny_days() {
    const INVOKER_ADDR: AccountAddress = AccountAddress([0; 32]);
    const ICECREAM_VENDOR: AccountAddress = AccountAddress([1; 32]);

    // Create a new chain.
    // Uses exchange rate to calculate fees.
    let mut chain = Chain::new(Timestamp::from_timestamp_millis(0), // slot time
                               ExchangeRate::new_unchecked(2400, 1)); // microCCD / energy

    // Create accounts with optional policies.
    let initial_balance = Amount::from_ccd(10000);
    chain.create_account(INVOKER_ADDR, initial_balance, None);
    chain.create_account(ICECREAM_VENDOR, initial_balance, None);

    // Deploy the module. The sender account pays for the energy.
    let res_mod = chain
        .module_deploy(ICECREAM_VENDOR, PathBuf::from("a.wasm.v1"))
        .expect("Deployment of valid module should succeed");
    let mod_ref = res_mod.module_reference;
    let cost_deploy_module = res_mod.transaction_fee;

    // Initialize the weather contract.
    let res_weather = chain
        .contract_init(
            ICECREAM_VENDOR,
            mod_ref,
            ContractName::new_unchecked("init_weather"),
            ContractParameter::from_typed(&Weather::Sunny),
            Amount::zero(), // Must be <= invoker.balance + energy cost
            Energy::from(10000u64),
        )
        .expect("Initializing weather contract should succeed");
    let addr_weather = res_weather.contract_address;
    let cost_init_weather = res_weather.transaction_fee;

    // Initialize the icecream contract.
    let res_icecream = chain
        .contract_init(
            ICECREAM_VENDOR,
            mod_ref,
            ContractName::new_unchecked("init_icecream"),
            ContractParameter::from_typed(&addr_weather),
            Amount::zero(),
            Energy::from(10000),
        )
        .expect("Initializing icecream contract should succeed");
    let addr_icecream = res_icecream.contract_address;
    let cost_init_icecream = res_icecream.transaction_fee;

    // Buy the icecream via a contract update.
    let res = chain
        .contract_update(
            INVOKER_ADDR,
            addr_icecream,
            EntrypointName::new_unchecked("buy_icecream"),
            ContractParameter::from_typed(&ICECREAM_VENDOR),
            ICECREAM_PRICE,
            Energy::from(10000u64),
        )
        .expect("Buying icecream update should succeed");
    let cost_update_icecream = res.transaction_fee;
    let energy_update_icecream = res.energy;

    // Assert various results.
    assert_eq!(res.transfers, [(ICECREAM_VENDOR, ICECREAM_PRICE)]);
    assert_eq!(chain.account_balance(ICECREAM_VENDOR), 
        Some(initial_balance 
          - cost_deploy_module 
          - cost_init_weather 
          - cost_init_icecream));
    assert_eq!(chain.account_balance(ICECREAM_VENDOR), 
               Some(initial_balance - cost_update_icecream));
    assert!(energy_update_icecream <= 3000); // Check energy usage/regressions
    assert_eq!(res.host_events, [ChainEvent::Interrupted {
        address: addr_icecream,
        events:  Vec::new(),
    },
    /// ...remaining events omitted
    ]);
}

Revise contract init/update costs in the testing library

Task description

We are changing the contract init/update cost in P6 to not count the custom section. We should reflect that in the testing library.

VSCode ext: Build task does not use `--schema-embed`

Bug Description

The configurable build task does not use --schema-embed, but the default build task does.
I would expect that it matches exactly by default, and then you can configure it to your liking.

Steps to Reproduce

1. Run Tasks: Configure Task
2. Choose .: Build smart contract
3. You are directed to the file .vscode/tasks.json

Expected Result
The args for concordium build should include --schema-embed.

Actual Result
--schema-embed is missing:

		{
			"type": "concordium",
			"command": "build",
			"cwd": ".",
			"args": [
				"--out",
				"concordium-out/module.wasm.v1",
				"--schema-json-out",
				"concordium-out",
				"--schema-base64-out",
				"concordium-out/module-schema.bs64"
			],
			"problemMatcher": [],
			"label": ".: Build smart contract"
		},

Versions

• Software Version: 0.1.0-0
• OS: macOS Ventura (Apple M2)

Add guide about integration testing on developer.concordium.com

• Create a guide about integration testing on developer.concordium.com.
• Update piggy bank test tutorial to use integration testing
• Go through remaining documentation and refer/link to integration testing when relevant

Remove notice from documentation related to Rust 1.70 problems

Task description

The new cargo-concordium release (to go together with node P6 release) will no longer have problems with Rust 1.70.

We should remove the notices to this effect from the documentation.

VSCode ext: Show error message when setting invalid custom cargo-concordium binary

Description

In the VSCode extension, it is possible to set a custom binary path to cargo concordium.
Issues with the binary, fx that it is missing or isn't executable, isn't displayed to the user.

Steps to Reproduce

1. Set the custom cargo path to a non-existing file or to a non-executable cargo concordium
2. Run the contract build command

Expected Result
A popup stating that the binary is missing or not executable.

Actual Result
Nothing.

Note
A popup with a useful error message is displayed when using the cargo concordium version command.
We should match that behavior for the other commands.

Versions

• Software Version: 0.1.0-0
• OS: macOS Ventura (Apple M2)

VSCode ext: `ccdrec` snippet uses `mut` host without `mutable` attribute

Bug Description

In the VSCode extension, the ccdrec snippet uses mut host without mutable attribute, which causes a compiler error.

Steps to Reproduce

1. Use the snippet ccdrec and enter values of existing data types and contracts in the placeholders.
2. Return a value from the function.
3. Compile

Expected Result
Compiles successfully.

Actual Result
A compiler error because the snippet uses &mut impl HasHost... instead of &impl HasHost when the mutable attribute isn't specified.

error[E0308]: mismatched types
   --> src/lib.rs:105:1
    |
105 | / #[receive(
106 | |     contract = "vstest",
107 | |     name = "foo",
108 | |     parameter = "()",
109 | |     return_value = "()",
110 | |     error = "()"
111 | | )]
    | |__^ types differ in mutability
112 |   fn vstest_foo<S: HasStateApi>(
    |      ---------- arguments to this function are incorrect
    |
    = note: expected mutable reference `&mut _`
                       found reference `&ExternHost<_>`
note: function defined here
   --> src/lib.rs:112:4
    |
112 | fn vstest_foo<S: HasStateApi>(
    |    ^^^^^^^^^^
113 |     ctx: &impl HasReceiveContext,
114 |     host: &mut impl HasHost<State, StateApiType = S>
    |     ------------------------------------------------
    = note: this error originates in the attribute macro `receive` (in Nightly builds, run with -Z macro-backtrace for more info)

Versions

• Software Version: 0.1.0-0
• OS: macOS Ventura (Apple M2 chip)

SC integration testing: figure out approach + write feature proposal

This pre-feature proposal task is about figuring out the correct approach to multi-contract testing in cargo concordium.

Also includes the feature proposal now.

Event schemas

Task description

Add schema support for events

Automate the build for vscode extension

Provide command for building a smart contract in VS Code extension

The extension should provide commands for running cargo concordium build

• Variant, which builds with: No schema.
• Variant, which builds with: With Schema (Base64 version of schema should be printed).
• Variant, which builds with: With embedded schema (Base64 version of schema should be printed).
• We should also provide a setting for additional arguments.
• When running this command, it should ensure the wasm32-unknown-unknown target is installed, otherwise prompt the user whether to install it.

Provide the cargo-concordium binary in VS Code extension

Provide the platform-specific binary for cargo-concordium and describe how to create a platform specific extension.

Provide code snippets for common smart contract patterns (VS Code extension)

The extension should include useful snippets.

Depending on the user experience and expressiveness of these snippets, details will have to be decided as these are developed.

Ex. Defining init and receive functions for smart contracts involve some amount of boilerplate, and the extension should include snippets to reduce some of the work related to this.

Snippets to implement:

• #[init(..)]
• #[receive(..)]

front-end-tool: Displaying the inputParameters schema to the user

Task description

Currently, the front-end requires the user to input the inputParameter without displaying its format. We can parse the schema of the initParameter from the module (if it has an embedded schema) or from the uploaded schema and display it to the user. This will be possible soon:
Concordium/concordium-contracts-common#96

• Get embedded schema from module.
• Get the inputParameter template from the schema and display it to the user.

Dry run a smart contract in the currently available state via cargo-concordium.

This is just to record that this is something we would ideally want to have. Specifying this for a good user experience will take some though.

It is a combination of the build/test tool and concordium client, where it would retrieve the contract from the chain, and its state, and run the specified call locally.

Cargo-concordium output flags

Description

When a user looks up the command for --out/--schema-out in cargo concordium build --help it says:

-o, --out Writes the resulting module to file at specified location.
-s, --schema-out Builds the contract schema and writes it to file at specified location.

Users often think that they just have to give a path as follows and the file will be created for them:

cargo concordium build --out ./
cargo concordium build --schema-out ./

but this results in an error as follows

Error: Could not build smart contract.
Caused by:
    Is a directory (os error 21)

Users have to give the path + file name for this to work e.g.

cargo concordium build --out ./my_wasm_file.wasm.v1
cargo concordium build --schema-out  ./schema.bin

Suggestion changes:

• Option 1: Create a default file name in case the user has no file name specified.
• Option 2: Check if the user forgot to specify a file name and give an error message stating how the format to these flags is expected.

VSCode extension icon is not visible in dark mode

Add some commands to convert the schema into base64

Task description

This command will make it easier to have a nice flow at presentations/workshops to explain where the magic rawSchemaBase64 string comes from that is used in the front-end code.

cargo concordium schema-base64 --schema ./schema.bin --out ./my/path/
cargo concordium schema-base64 --module ./foo.wasm.v1 --out ./my/path/

cargo concordium build --schema-base64-out ./my/path/

The long-term plan is to support/promote json-schema instead which could give a better developer experience since they are human-readable and can be used for debugging purposes.

Setup VS Code extension project

Create initial project, document how to start development and how to publish.

Cargo-concordium: Add support to print a schema template

Task description

Add support to output a schema template.

Display traits are now implemented for the schemas.

Concordium/concordium-contracts-common#99

SubTasks

• Add --schema_template_out flag to the cargo concordium build command. It either outputs the JSON template of the schema to a file (if a valid path+file is provided with the flag) or outputs it to the console (if a dash is used aka - with the flag)
• Add cargo concordium schema-template command (a schema has to be provided either as part of a smart contract module or with the schema flag. Exactly one of the two flags (--schema or --module) has to be used with this command.) that also outputs the template to a file or console.

cargo concordium test does not build tests with dev-dependencies

cargo concordium test fails if t here are dev-dependencies needed by the tests.

cargo test succeeds.

front-end: Make contract name a drop-down based on module

Description

Currently the front-end asks the user to input the contract name. We can parse the list of all possible contracts from the module, and offer them in a drop-down. If we have the schema we can also partially recover this information from the schema, if we assume all init functions are in the schema, which technically they don't have to be.

Get chain parameters for testing library via node connection

Task description

We want to expand the testing library with various ways of using data from an actual chain via a node.

The first step on that journey is to allow users to get certain chain parameters from the chain, including the exchange rates and block time.

The Concordium Rust SDK already supports communicating with a node, so we will add it as a dependency to the testing library.
The calls to a node take time and are async in the Rust SDK, but for testing, we want to hide the asynchronicity from the user by blocking the thread until the task is finished.

The reason for doing so is that it really isn't possible to run any parts of an individual test in parallel.
Hiding the async functions also provide a simpler and cleaner interface for the users.

Sub-tasks

• Add a constructor function to Chain which connects to a running node.
• Add a method for setting the Chains exchange rate parameters and the block time to match those of the connected node.

VSCode smart contract extension

Integration testing in Cargo Concordium

Cargo Concordium has support for simulation smart contracts off-chain, but it is quite limited in capacity.
It only supports simulating one method at a time, and the execution will stop at the first interrupt (which occurs when a transfer to an account occurs, the contract invokes another contract, or when the contract wants to upgrade).

The purpose of this epic is to improve the testing and simulation capabilities of Cargo Concordium so that it is possible to test not only one contract to completion but also multiple contracts interacting together.

Make sure the costs are correct for re-entrant calls

Task description

We have changed/fixed the semantics of re-entrant calls in the node in P6.

We should make sure that the costs in the testing library are correct. In particular

• add the re-entrant tests from the node to the tests of the library
• make sure that the library reports correct cost
• make sure the library then also reports correct "state has changed" back to the contract.

VSCode ext: Custom tasks prefixed with `.:` instead of `ccd:` or `concordium:`

Bug Description

The configurable tasks are prefixed with .: instead of ccd: or concordium:.
In comparison, the regular rust tasks are prefixed with rust:.
I assume that this can lead to confusion, if you also have tasks for smart contracts on other chains. For example for the build task, which has the full name .: Build smart contract

Steps to Reproduce

1. Run Tasks: Configure Task
2. See the names of the different tasks available

Expected Result
rust: cargo clean
...
concordium: Build smart contract
concordium: Test smart contract

Actual Result
rust: cargo clean
...
.: Build smart contract
.: Test smart contract

Versions

• Software Version: 0.1.0-0
• OS: macOS Ventura (Apple M2)

front-end-tool: Check for duplicate module

Description

It would be useful if the front-end checked if the module the user is trying to deploy is already deployed on the relevant network instead of letting the transaction through, and it failing.

Support new host functions and operations in cargo-concordium.

• Support for the upgrade host function
• Support for new query operations.
• Support for revised resource restrictions.

Write feature proposal for Expand SC Testing Library

Write the feature proposal for our plans to expand the smart contract testing library.

VSCode ext: Small issues in readme

Found two small issues in the readme of the VSCode extension.

1. all prefixed with ccd (for smart contract) should be all prefixed with ccd (for Concordium).
2. The extension relies on [rustup](https://rustup.rs/) and cargo being installed and available in PATH. It links to rustup but not cargo. I think it should link to both.

Investigative work for VSCode smart contract extension

Investigate what would be included in a smart contract extension for VSCode and write first draft for a feature proposal.

It is not available for Mac with Silicon chips.

**Bug Description** The 'Concordium Smart Contracts' extension is not available in Visual Studio Code for Mac Silicon.

May worth look into this for potential fixes: https://code.visualstudio.com/api/working-with-extensions/publishing-extension#platformspecific-extensions

Versions
Apple MacBook Air M1
OS: Ventura 13.2.1

cargo-concordium templates

Task description
cargo-concordium should have an init command to spin up a fresh Concordium smart contract project easily.
cargo-concordium should have an init cis2-nft command to spin up a fresh Concordium smart contract token project easily.

Sub-tasks

• Add cargo-concordium init command
• Add cargo-concordium init --template cis2-nft command

front-end-tool: Simulate deploy/init transaction before executing it

Task description
This is blocked until the node supports this feature and the web-sdk has the required functions exposed.

#87 (comment)
Concordium/concordium-node-sdk-js#215

Extract `ContractTraceElements` for failed calls in the testing lib

Task description

This task relates to the testing library.

When contracts invoke certain host functions, for example calling another contract or transferring CCD, ContractTraceElements are created. This is true both in the testing library and the node.
There are different kinds of trace elements. As an example, consider a contract call that transfers CCD to an account and then returns. It would produce the following trace elements:

• Interrupted the contract
• Transferred the CCD
• Resumed the contract after a successful interrupt
• Updated the contract with success

The trace elements record the high-level interactions in a contract call and are useful for testing and also debugging.
However, the debugging aspect could be improved because trace elements of inner calls that eventually fail are omitted.
This was originally by design in the node, but in the testing library, we can change this behavior to allow the user to get all trace elements and use them for testing and debugging.

An example of trace elements being "lost" is the following:

• Interrupted contract A to call contract B.
  • Interrupted contract B` <- omitted
  • Transferred CCD <- omitted
  • Resumed <- omitted
  • Then fail. (so there is no Update) <- omitted
• Resumed the contract after a failed interrupt.

In this example, all the trace elements of contract B are omitted, because the call eventually fails.
This task is about collecting and exposing the previously omitted trace elements in a nice way to the developer.

Tasks

• Collect all the trace elements instead of discarding them
• Find out how to expose it to the user (while still allowing the user to get the list as it is currently)
  • It should be easy to see where the omitted events fit into the original list.
• Include trace elements in ContractInvokeFailure, for when the outer-most entrypoint fails.
• Write a few test cases that showcases the usefulness and tests the functionality.

VSCode Extension doesn't show an error if 'it doesn't know' what contract to build

To reproduce:

1. Initialize the contract from the template.
2. Create a folder when the VSCode asks to select one.
3. Select the folder you have just created.
4. Don't open the lib.rs file, try the build command.

Result:
First time, there is an error shown that folder where the contract exists doesn't exist.
Second time, it just doesn't show any errors.

Expected
Error that would explain the user to select contract to build.

Version
1.0.1

VSCode ext: Custom test task does not run tests, only `cargo build`

Bug Description

The configurable test task does not run the tests, but it does seem to run cargo build without any arguments.

Steps to Reproduce

1. Run Tasks: Configure Task
2. Choose .: Test smart contract
3. The file .vscode/tasks.json is created.
   With content:

        ...
    {
    		"type": "concordium",
    		"command": "test",
    		"cwd": ".",
    		"args": [],
    		"problemMatcher": [],
    		"label": ".: Test smart contract"
    	}
         ...
   

4. Run the task with Tasks: Run Task
5. Then choose .: Test smart contract

Expected Result
In step 3 I would assume that it should match the exact behavior and args of the default concordium test command.
In step 5, I would expect the tests to run.

Actual Result
In step 3: it doesn't match the args etc that I would expect.
In step 5: It only compiles, and no tests are run:

*  Executing task: /Users/kasper/.vscode/extensions/concordium.concordium-smart-contracts-1.0.0/executables/cargo-concordium concordium build 

   Compiling vstest v0.1.0 (/Users/kasper/Developer/Concordium/vstest/vstest)
    Finished release [optimized] target(s) in 0.11s
    Finished smart contract module 21.515 kB
 *  Terminal will be reused by tasks, press any key to close it. 

Versions

• Software Version: 0.1.0-0
• OS: macOS Ventura (Apple M2)

Support for new operations (get keys, check signatures) in smart contract testing library

Task description

The smart contract testing library should support the new operations for getting account keys, and checking account signatures.

• Support handling new operations.
• Add support for setting up accounts with keys in a way that is ergonomic to test entrypoints which require account signatures.

Add label for component and priority.

cargo-concordium should check whether paths/directories it needs exist before doing work

Currently if --schema-json is supplied and points to a non-existing directory the error only occurs at the very end, after the contract has been compiled (twice if compiling with schemas).

It would be more user friendly to check the relevant property at the beginning, before we start compilation and other expensive work.

We should check if any other flags like this have similar error conditions.

`cargo concordium init` does not work if non-empty `concordium-contracts-common` folder exists

Bug Description

cargo concordium init does not work if non-empty concordium-contracts-common folder exists.

Steps to Reproduce

1. Create a non-empty folder named concordium-contracts-common: mkdir concordium-contracts-common; touch concordium-contracts-common/a.txt
2. Run cargo concordium init

Expected Result
The wizard starts correctly:

❯ cargo concordium init
? 🤷   Which template should be expanded? ›
❯ cis2-nft
  default

Actual Result
The wizard cannot run:

❯ cargo concordium init
Error: Please check if the Git user / repository exists.

Caused by:
    'concordium-contracts-common' exists and is not an empty directory; class=Invalid (3); code=Exists (-4)
Error: Could not create a new Concordium smart contract project.

Caused by:
    Could not use the template to initialize the project.

Versions

• Software Version: cargo concordium 2.5.0
• OS: macOS

Investigate how to generate off-chain smart contract clients

Investigate options and design decisions related to generating off-chain smart contract clients.

Building a front end that smart contract developers can use to deploy/initialize their smart contracts

Task description

To simplify the deployment process, we want to provide a front end that developers can use. That way new smart contract developers (e.g. at a hackathon) get easily started without downloading/setting up concordium-client .

Get schema for specific entrypoints

Task description

Add a new command to get schema types outputted in a JSON file.

E.g.
cargo concordium schema-expand --module foo.wasm.v1 --out schema-types.json
cargo concordium schema-expand --schema schema.bin --out schema-types.json

The input can be either a smart contract module or a schema. The output should only include the schema types. The purpose is that a dApp should be able to provide the schema types to the browser wallet (e.g. just the schemas to call the balanceOf function) without specifying and linking it to a specific smart contract name. E.g. the dApp might want to interact with the balanceOf function on some CIS2 token contract (without knowing the exact name of the CIS2 token contract).