This situation is currently confusing a lot of our users because the warning is not immediately obvious from being simply put inside a more or less long list of some events that quickly pop up after calling a message on a contract that just got evicted.

The UI should instead filter out an eviction event and signal an alert to the confused user as to why the contract execution was not successful and should help them out with what might have caused the problem and provide them with some initial help to cope with such a situation.

This topic is clearly underdeveloped in Parity products right now. However, as I see it, we have to do an excellent job in order to convince people that storage rent is a good way forward into securing economic strengths for our blockchain systems. If we do not do a good job at teaching people about the pitfalls they will not accept this solution.

Hi guys,

I searched all over with no luck. Hope someone could shine some light on below issue.

I tried to deploy contract https://github.com/ww8912188/ink-contracts/tree/main/voting on https://paritytech.github.io/canvas-ui/#/upload.

It works smoothly for the upload process but deploy, it raise below error:

Can someone take a look at this issue? This contract works last week to my memory.
I also tried to install canvas-ui on locally with the newest release version v0.44.1. But it seems the UI looks totally different
from the one of https://paritytech.github.io/canvas-ui/#/upload, so I cannot debug my code.

Regards,
Nan

Update will be in 2.3.1 release on Monday (for non-beta use)

Hi folks, so I'm a bit stuck on the smart ink tutorial - I get an error trying to upload my flipper contract as described in

https://substrate.dev/substrate-contracts-workshop/#/0/deploying-your-contract

I get:

Transaction Failed: Error: 1002: Verification Error: Execution: Could not convert parameter tx between node and runtime: No such variant in enum MultiAddress: RuntimeApi, Execution: Could not convert parameter tx between node and runtime: No such variant in enum MultiAddress

which interestingly is the same error that I got when my local frontend was 2.0.0 and my backend was 2.0.1 as described here:

substrate-developer-hub/substrate-front-end-template#158

More details on the issue in:

substrate-developer-hub/substrate-contracts-workshop#100

is there some way to upgrade https://paritytech.github.io/canvas-ui to work with 2.0.1 backends, or maybe I can run https://paritytech.github.io/canvas-ui locally and upgrade myself?

The UI currently allows users to input the maximum amount of gas they want to spend on an operation and UI even nicely displays the fraction of block time this amount will maximumly require. However, the ideal solution was to precompute all messages or constructor calls as RPC calls and then right away display the costs that are going to be required concretely to the user.

The big advantage is that the user sees right away how costly a call is going to be and does not do some guesstimations themselves. Also this will simplify interaction with the UI since we then can simply leave away the entire max. gas cost field at all - we simply take the value from the precomputing step before.

Copy/Pasted from polkadot-js#4010:

We recently updated cargo-contract in a way that it now outputs a <contract-name>.contract as well (besides the usual <contract-name>.wasm and metadata.json).

This .contract file bundles the Wasm and metadata together by encoding the Wasm into the source.wasm field of the metadata.json ‒ so the .contract is really just a JSON. You can see an example of the ink! 3.0 flipper.contract here.

It would be great if polkadot-js could accept this new .contract file format, thus making it easier for users to deploy contracts. Maybe we can even deprecate uploading a separate Wasm/metadata entirely at some point.

I'm not sure how the two codebases relate nowadays, but these changes need to be introduced in the canvas-ui as well.

The situation was the following:

I was deploying and executing an instance of the demo'ed ERC-20 contract on-chain on the Canvas test network.
I tried to execute the ERC-20 transfer method as RPC call which resolves return values for me because I wanted to know if the call resulted in some error with the given arguments.
Unfortunately the UI crashed telling it could not properly decode the Result type.
Maybe this is connected to the fact that the UI cannot really handle enum types, yet but I still wanted to clarify this issue.

After executing several contract reads on the Execute page, there should be an easy way to remove them all at once.

Currently the UI only supports primitives as well as compound types (tuples and structs).
However, it is missing support for enum types that are any variant of a given fixed list of compound of enum type.
Ideally the UI supports both input and output of those types.

• Implement UI to allow inputting enum types into contracts.
• Implement UI to properly display return values of enum types.

Currently Canvas UI does not properly give attribution to things that it copied from Polkadot JS Apps or was inspired from.

If Canvas UI authors copy'n'pasted a file from Polkadot JS Apps the license header will be the original:

// Copyright 2017-2021 @polkadot/apps-* authors & contributors
// SPDX-License-Identifier: Apache-2.0

If Canvas UI authors modified a file that has been copied from Polkadot JS Apps it will in the future have a license header like this instead:

// Copyright 2017-2021 @polkadot/apps-* authors & contributors
// and @canvas-ui/app-* authors & contributors
// SPDX-License-Identifier: Apache-2.0

Inspired by: https://ink-playground.com/

Unfortunately they are not upgrading it anymore.
Having a stable and up-to-date ink! playground would allow the community to have a zero-setup workspace for writing and teaching ink! smart contracts.
This is very much needed in the future where we are refocusing on community building and teaching ink!.
Also it would be a fantastic base for a lightweight ink! tutorial.

Unlike the original ink! playground we should, however, make sure that contracts compile quickly or simply as fast as possible to be comparable in compilation speed to native compilation. For this we are going to be in need of proper pre-caching of the environment in which the ink! contracts are going to be build. This has been proposed for the original ink! playground but was never implemented unfortunately.

As additional features the ink! playground should not only have proper syntax highlighting but also proper built-in IDE-like features provided by the well established rust-analyzer. This could be implemented as a follow up.

Further future additions could be an improved setup where we allow for editing multiple projects at once and improve organization in between them for a real in-browser development experience. It might make sense to have both, ink! playground as well as the fully integrated IDE experience ink! studio as different products since they serve different purposes.

Canvas commit: 0516adfe4b17549b837080b6d49dd2472af5706f
Substrate commit: a200cdb93c6af5763b9c7bf313fa708764ac88ca

Substrate and Canvas Node are moving from contracts.putCode -> contracts.instantiate to instantiateWithCode (single step). The UI must support both types of instantiation.

Following situation:

I was about to upload the Wasm blob for my smart contract and did the following steps.

1. Clicked on Deploy
2. Insert some name for my contract.
3. Uploaded Wasm
4. Name was overwritten by the Wasm blob's name which is definitely not what I intended it to be. It should leave whatever I have put in there in the first place.

Instead to fix this bug I always first had to upload the Wasm and metadata and do the naming in the end in this order.

Contracts, code bundles persist despite no longer being on chain

The Canvas UI should have a feature to query the code hashes that have been deployed on-chain to simplify reuse.
It shall be possible to query them by their name as well as by the account ID that uploaded them to the chain.

This UI shall display general information about the code hash as well as its dependencies and dependency count to quickly determine which ones should and should not be reused. Also they should allow inspection into their underlying Wasm sources easily and if provided the associated metadata and therefore contract interface.

It should be very simple for users to instantiate a contract from a selected code hash.

Contracts/code bundles currently stored in browser storage should be stored in a IPFS-based file system or database store - possibly Orbit-DB

• Requires addition of user credentials
• New design spec(s)?

set value to hello, it returns u0014hello;

set value to hello, world!, it returns 4hello, world!

contract source

// Copyright 2018-2021 Parity Technologies (UK) Ltd.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//     http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

#![cfg_attr(not(feature = "std"), no_std)]

use ink_lang as ink;

#[ink::contract]
pub mod flipper {

    use ink_prelude::string::String;
    
    #[ink(storage)]
    pub struct Flipper {
        value: String,
    }

    impl Flipper {
        /// Creates a new flipper smart contract initialized with the given value.
        #[ink(constructor)]
        pub fn new(init_value: String) -> Self {
            Self { value: init_value }
        }

        /// Creates a new flipper smart contract initialized to `false`.
        #[ink(constructor)]
        pub fn default() -> Self {
            Self::new(String::from("hello, world!"))
        }

        /// Flips the current value of the Flipper's bool.
        #[ink(message)]
        pub fn set(&mut self, v:String) {
            self.value = v;
        }

        /// Returns the current value of the Flipper's bool.
        #[ink(message)]
        pub fn get(&self) -> String {
            self.value.clone()
        }
    }

    #[cfg(test)]
    mod tests {
        use super::*;

        #[test]
        fn default_works() {
            let flipper = Flipper::default();
            assert_eq!(flipper.get(), String::from("hello, world!"));
        }

        #[test]
        fn it_works() {
            let mut flipper = Flipper::new(String::from("Good day"));
            assert_eq!(flipper.get(), String::from("Good day"));
            flipper.set(String::from("Good morning"));
            assert_eq!(flipper.get(), String::from("Good morning"));
        }
    }
}

@seanyoung What can be the reason behind the error :

contracts.putCode
createType(AccountId):: Maximum call stack size exceeded

I was able to upload a WASM and ABI file to canvas UI. After clicking on Sign and Submit, I get the above stated error.

In the case of the screenshot below i32::MAX is 2147483647, however I can only enter digits up to 21474836 into the field.

An issue which is recurring in our public channels is that people try to upload a Wasm file instead of the .contract bundle. The UI displays an ABI error in this case:

Typically users don't get what the actual is from this error message. I suggest to display an error explaining that only a .contract bundle can be uploaded ‒ not the Wasm.

There is this mismatch:

I've created this issue after reading through https://brson.github.io/2020/12/03/substrate-and-ink-part-3, where the author is irritated by this.

This might be a bit of a bigger task all in all.

The UI currently does not make any use of the contract's storage metadata section.
This section describes in detail how the storage of the contract looks like.
The information includes concrete keys, offsets, structural patterns and even types of the entities encoded.

Ideally the Canvas UI provides this very detailed information to the user under a new tab "storage" where a user can inspect the entire storage of a selected smart contract decoded and destructured.
This should not simply show the raw bytes but also decode the information right away and show it nicely with its respective type definition.

I am not sure what is the best technique and method to display this as cleanly and as organized as possible since the storage of a contract can quickly become very complex. This is a research topics where probably @erler , @kwingram25 and me has to sit together and think about some really good visualization. Please schedule a meeting as soon as work on this starts, @kwingram25 .

When I tried to access https://paritytech.github.io/canvas-ui, it's telling me that it's been blocked by PhishFort. Is anyone experiencing the same issue?

I think the docs disappeared with the migration to the .contract file:

Before:

Currently:

The url was wss://canvas-rpc.parity.io which no longer connects, in browser I get 502 Bad Gateway.

Steps to reproduce:

• Deploy
  incrementer.zip
• Execute the get function or the inc function (rpc or transaction)
• Results: no event visible

Expected results:

• Both the transaction and the rpc call should show that the event incrementer.Foo was emitted and the value

When deploying this contract via the UI, the UI just displays this:

Uncaught error. Something went wrong with the query and rendering of this component. createType(Result):: Cannot construct unknown type Result

The console shows:

react.01.5ff66cee.js:2 Error: createType(Result):: Cannot construct unknown type Result
    at u (polkadot.01.dc51e7e6.js:1)
    at io (main.01be78c1.js:2)
    at main.01be78c1.js:2
    at Object.useMemo (react.01.5ff66cee.js:2)
    at t.useMemo (react.01.5ff66cee.js:2)
    at e (main.01be78c1.js:2)
    at Gi (react.01.5ff66cee.js:2)
    at xl (react.01.5ff66cee.js:2)
    at ps (react.01.5ff66cee.js:2)
    at ds (react.01.5ff66cee.js:2)

I think the reason is that the specific contract has this ink! message:

        /// Returns an error.
        #[ink(message)]
        pub fn return_err(&self) -> Result<()> {
            Err(Error::MyError)
        }

I have to expand "Constructor Details" to see the "Instantiate" button.

The constructor details should either be

• expanded by default, if they are that important, or
• the button should already show up if they are collapsed.

You can reproduce by uploading flipper and executing a series of get → flip → get → flip. This will result in this:

Several repeatedly used components should be tested with Jest as part of CI. Obvious candidates:

• Main pages (Upload, Deploy, Execute)
• InputABI
• CodeCard / ContractCard
• ...

TBD - currently TS linting errors

I'm unable to upload flipper with the current canvas-node master. This is the error I get:

contracts.instantiateWithCode
1002: Verification Error: Runtime error:
Execution failed: ApiError(FailedToConvertParameter { function: "validate_transaction", parameter: "tx", error: Error { cause: None, desc: "Could not decode `MultiAddress`, variant doesn\'t exist" } }): RuntimeApi, Execution failed: ApiError, FailedToConvertParameter { function: \"validate_transaction\", parameter: \"tx\", error: Error { cause: None, desc: \"Could not decode `MultiAddress`, variant doesn\\\'t exist\" } }

With the current Canvas UI it is very hard to keep track of how you have operated on all your stored smart contract instances in the past. For this is would be very nice to have a log of commands (e.g. sent messages with their parameters and their returned values or if they failed and why.)

There should be a log per smart contract but also it should be possible to merge logs of different selected smart contracts.
The logs should be displayed in chronological order.

Maybe some interface similar to a console but with proper encoding and decoding support would be what users would probably be most familiar? @erler what is your stance on this from a design perspective?

The Canvas UI can show the documentation of ink! messages, constructors, events etc.
However, this documentation is currently completely unformatted although being preformatted (through means of Rust docs) by Rust's markdown flavor.
It would be a nice feature to show the documentation of those entities with proper markdown formatting.

Also it should be possible to collapse documentation of the items, which will be useful for especially big contracts.
Collapsing the docs will only show the first line of the documentation (or none).

It seems that the UI sometimes does not properly display the displayName of function parameters and function return types and instead displays their technical names which is often not preferred. The distinction between the name of the type in question and its displayName when used as parameter or return type becomes immediately clear when we are talking about type aliases.

Whereas the type's name always resolved aliases and always refers to the real underlying type the displayName does not and instead refers to the actual name that is used on the exact function argument or return type.

Example

type Balance = u64;

#[ink(message)]
pub fn transfer(&mut self, to: AccountId, amount: Balance) { ... }

In this example the amountfunction argument has a displayName of Balance whereas it has a type name of u64.
Ideally the UI could display both if they are different so that a user knows the type's name on the use site as well as its underlying real name or identifier.

Screenshot

The screenshot shows how Balance is shown for total_supply but not for new. Instead the new constructor shows u128 instad of Balance.

A Solidity transaction which fails due to a failing assert or an explicit call to revert("foo"); does not show as failed. The return buffer will be decoded and will return garbage.

Given this function:

contract incrementer {
	function fail() public pure returns (uint32) {
		revert("fail");
	}
}

Steps to reproduce:

• Deploy this contract
  incrementer.zip
• Execute the "fail" message
• Shows the return value 12810656 (garbage)

Expected results:

• Since contract ends with seal_return(1, .. ) the ui should show the transaction as reverted
• The error string "fail" should display

Motivation

The UI should output a warning when trying to upload a contract that was written in an incompatible ink! ⇿ contract pallet version.

This is an issue which will become only more prevalent in the future. It is already a recurring source of confusion for users and we regularly get questions about which versions are compatible.

My hunch is that the output should be a warning, not an error, since a user could write a contract in a newer version of ink! which would still be compatible to old versions of the contract pallet. There are arguments to be made for an error message though, not entirely sure what the best option is.

Implementation

• The .contract file already contains the ink! version under source.language.
• AFAIK the contract pallet does not currently not expose its version. (cc @athei)

I guess in an ideal world we would take semver into account when checking for compatibility.

Currently defining on-chain smart contract tests is hard and best done by programming some custom solution yourself for your own smart contract. It is currently not possible to define on-chain smart contract tests in ink! or any other Substrate based language that I am aware of. The possibility of defining off-chain unit tests in ink! unfortunately is not applicable to on-chain testing.

I began to wonder if it actually makes sense to provide capabilities for defining on-chain smart contract tests in ink! or any other language itself. Instead what probably makes more sense is to program a tool with which a user can easily describe the flow of an on-chain test by imperative or declarative means using a UI that was primarily designed for the task.

I imagine this to be part of the Canvas UI where you can define on-chain tests for your uploaded and managed smart contracts. It should also be possible to serialize those tests to some common format such as JSON. The test definition should happen in some DSL that was specifically designed to facilitate on-chain testing for Substate based smart contracts. The DSL is fed with the contract's very own metadata so that the Canvas UI can easily display actions to call certain contract messages or instantiate using specific constructors with proper arguments. Also it must be possible to interact with the chain directly, e.g. set/get balances. When calling a contract it is also important with regards to testing from which account calling happens. The big advantage of on-chain testing is that it should be possible to test a multitude of smart contracts and their interactions with each other. This is what is not possible with off-chain testing today. Also chain interaction must somehow provide a way to call chain specific extensions - maybe this might be better suited for a future add-on task.

This issue tracks progress of this feature.
@erler We also need a proper design for this.
@statictype Volunteered to spearhead this task initially.

Steps to reproduce:

• Deploy
  incrementer.zip
• Execute the inc message (as a transaction)
• No output

Expected results:
The inc message returns the current value of the incrementer, but this is not visible

I am new to the Ink, I just followed the steps provided in the readme.
Step 1 : Setup Substrate Prerequisites
https://substrate.dev/substrate-contracts-workshop
Step 2: Building the ERC20 Contract
cargo +nightly contract build
Step 3: Running a Canvas Node
canvas --dev --tmp --ws-external
Step 3: Open Canvas UI and connect to local
Here I transferred unit from Alice to Dave see the screen shot below :

Then, if I look at the Polkadot UI or Substrate-front-end-template UI
the balances are not reflecting in the accounts tab!

Anything wrong here or did I missed any steps?

Possible webpack-related bug

Currently the UI can handle all primitive types such as Rust's i32, u64, bool, arrays, tuples and compound types.
However, for Solang we need support for Ethereum's U256 and I256 types.

What is the preferred concrete types to implement for this? https://github.com/seanyoung
@seanyoung

The UI still says "Upload Wasm blob" in a couple of places, even though only .contract bundle files are supported. We should update those labels.

Contracts can emit events which are especially useful to inspect for other third party tools.
The Canvas UI should display those events next to the other events upon interaction with smart contracts.
This currently does not happen from my personal observations but we really want to have those.

All information about how to decode such an event is stored inside the metadata.
Event event topics are now properly included in the encoding.

The Canvas UI should also feature a log for every contract and its events.
There should be one log per contract.
It should be possible to merge different logs.
Event logs should be displayed in chronological order of their appearance.

• Implement events emitted by smart contracts displaying next to other events.
• Implement event log UI as described above.

Currently the UI allows sending funds via execution of messages. However, via metadata it can already determine for every message if it allows receiving funds at all. The UI should ideally reflect this information by greying out the field to insert the transferred amount of funding for non-payable messages with a hover message why it is greyed out for users to notice.

Also besides the nice "mutates storage" icon we also might want to have yet another icon displaying if a message is payable.
Note that constructors are always payable.

Support the new contracts pallet which adds a "salt" argument to instantiate. paritytech/substrate#7482. This could default to the account nonce.

canvas-node has already updated to the version supporting this.