Deploying the piggy bank smart contract

This is the third part of a tutorial on smart contract development. So far you have written and tested a piggy bank smart contract in the Rust programming language.

This part focuses on how you can deploy your developed piggy bank smart contract to the Concordium testnet and interact with it.

Warning

The reader is assumed to have basic knowledge of what a blockchain and smart contract is, and some experience with Rust.

Preparation

Before you start, make sure you completed the previous parts of the tutorial and have a running testnet node that has caught up to the head of the blockchain and an account with some CCD setup.

Building a Wasm module

You have already built a Wasm module from your piggy bank smart contract in a previous part of this tutorial.

Repeat this step since you might have done some changes to the smart contract code in part 2 of this tutorial. Go to the folder where you saved your piggy bank smart contract and use cargo concordium build to create a Wasm module.

$cargo concordium build --out piggy_bank_part2.wasm.v1

Note

This command outputs the module piggy_bank_part2.wasm.v1 to the project’s root folder.

Note

When you use the above command without the --out flag, you can find the module in the folder ./target/concordium/wasm32-unknown-unknown/release/. Use the Wasm module file suffixed with v1 when deploying to the chain. The piggy_bank_part2.wasm file (without the v1 suffix) is not the v0 module, but rather the raw Wasm module produced by cargo. The v1 suffixed module has been stripped for debugging information, which makes it significantly smaller.

The piggy_bank_part2.wasm.v1 file can be deployed to the Concordium chain. Transfer the piggy_bank_part2.wasm.v1 file to the place where you are running your concordium-client tool. Navigate to the folder as well.

Deploying a module

You are now set up to deploy the piggy bank module to the testnet chain. Give the module the name piggy_bank_part2_module so it can be referenced in this tutorial.

Note

Remember to adjust the following commands when you are running your concordium-client tool locally and want to connect to your node on the server. You can look up the different options on how to connect the concordium-client tool to your testnet node here.

Note

Names are only stored locally in the concordium client configuration. They are not visible to others on the chain. This is the case for all contracts, modules, and account names/aliases.

$./concordium-client module deploy piggy_bank_part2.wasm.v1 --sender <account-name> --name piggy_bank_part2_module --grpc-port 20001

If everything works correctly the output has a green line with your module reference.

Module successfully deployed with reference: <module-reference>.
Module reference <module-reference> was successfully named 'piggy_bank_part2_module'.

You can find additional information about deploying a module in this guide.

Note

Deploying the piggy bank module will fail with an error message if a module with the exact same hash (the <module-reference>) has already been deployed. If you compile the same contract on different systems or versions of rustc, then their hashes will often differ. You can continue this tutorial by using the module reference printed in the error message instead of the name `piggy_bank_part2_module`.

Error: Module deployment failed:
Module <module-reference> already exists.

Initializing a module

You can initialize your smart contract now to create a smart contract instance. Give the instance the name piggy_bank_part2_instance so it can be referenced in this tutorial.

$./concordium-client contract init piggy_bank_part2_module --sender <account-name> --contract PiggyBank --name piggy_bank_part2_instance --energy 1500 --grpc-port 20001

Note

1500 is enough energy to initialize the piggy bank smart contract but you might need more energy for larger smart contracts. The --energy parameter sets the maximum allowed energy to be used. You only pay for the actual energy used.

If everything works correctly the output has a green line with your smart contract instance index.

Contract successfully initialized with address: {"index":<smart-contract-instance-index>,"subindex":0}
Contract address {"index":<smart-contract-instance-index>,"subindex":0} was successfully named 'piggy_bank_part2_instance'.

You can find additional information about initializing a smart contract instance in this guide.

Updating the piggy bank smart contract

Deposit 1 CCD into the piggy bank to test if you can update the smart contract instance.

$./concordium-client contract update piggy_bank_part2_instance --entrypoint insert --energy 1000 --sender <account-name> --amount 1 --grpc-port 20001

If everything works correctly the output has a green line as follows:

Successfully updated contract instance {"index":<smart-contract-instance-index>,"subindex":0} ('piggy_bank_part2_instance') using the function 'insert'.

You can find additional information about updating a smart contract instance in this guide.

Viewing the piggy bank state

You can display the raw return value of your piggy bank smart contract with the following command.

$./concordium-client contract invoke piggy_bank_part2_instance --entrypoint view --energy 1000 --grpc-port 20001

If everything works correctly the output has a green line as follows:

Invocation resulted in success:
- Energy used: 510 NRG
- Return value (raw):
[0,64,66,15,0,0,0,0,0]
.

You can find additional information about invoking in this guide.

Smashing the piggy bank smart contract

Smash the piggy bank contract to test that you can invoke this entry point. After smashing the piggy bank you cannot enter any additional CCD into the piggy bank anymore.

$./concordium-client contract update piggy_bank_part2_instance --entrypoint smash --sender <account-name> --energy 2000 --grpc-port 20001

If everything works correctly the output has a green line as follows:

Successfully updated contract instance {"index":<smart-contract-instance-index>,"subindex":0} ('piggy_bank_part2_instance') using the function 'smash'.

You can find additional information about updating a smart contract instance in this guide.

Concordium-std crate errors

Ensure that you don’t send any CCD to the smart contract instance. You can find explanations about the behavior of the Smash entry point in this guide. The Smash entry point is non-payable and will print the below error message if you send CCD with the --amount flag. The opposite is not true and you can omit the --amount flag when interacting with a payable function without raising an error because in that case 0 CCD is sent to the payable entry point.

Error: Updating contract instance failed:
'smash' in 'PiggyBank' at {"index":<smart-contract-instance-index>,"subindex":0} failed with code -2147483636.

Note

You can find the meaning of common error codes in this list. This error was thrown by the concordium-std crate. The error codes start from i32::MIN and go upwards. -2147483636 corresponds to NotPayableError. In contrast, error types of the smart contract start from -1 and go downwards.

Smart contract errors

Ensure that the --sender flag uses the <account-name> that initialized the piggy bank smart contract instance (the owner of this smart contract instance). You can find explanations about the behavior of the Smash entry point in this guide. If you invoke the Smash entry point with a different account than the owner, it will print the below error message.

Error: Updating contract instance failed:
'smash' in 'PiggyBank' at {"index":<smart-contract-instance-index>,"subindex":0} failed with code -1.

Note

You can find the meaning of the piggy bank error codes in this section. This error was thrown by the smart contract. The error codes start from -1 and go downwards. -1 is the first error code and corresponds to NotOwner. In contrast, errors from the concordium-std crate start from i32::MIN and go upwards.

Congratulations. You have completed the whole piggy bank tutorial.