Got contracts.StorageDepositLimitExhausted when instantiating contract. rc-7 was OK.

[czyczk]

Questions

• Is this a bug concerning building of ink! smart contracts?
  No. Testing and compilation are OK.

Version
Rust Nightly: cargo 1.60.0-nightly (95bb3c92b 2022-01-18)
cargo-contract: cargo-contract 0.17.0-unknown-x86_64-linux-gnu
substrate-contract-node: substrate-contracts-node 0.5.0-0ec18d9-x86_64-linux-gnu
ink!: 3.0.0-rc8

Describe the bug
I have a custom struct ComplexStruct which contains another custom struct and they have the Encode etc. properly annotated. In the #[ink(storage)] section I store the struct in a HashMap identified by its ID (string). The String and collection types are of the ink_prelude and ink_storage versions.

The code in the storage section is something like this:

pub struct Blbc {
        pub res_map: HashMap<String, Vec<u8>>,
        pub res_metadata_map: HashMap<String, ComplexStruct>,
}

The default() constructor just instantiates them with Default::default().

Testing and compilation are OK. The same code got instantiated using the default() constructor without problem with v3.0.0-rc7, but not so with v3.0.0-rc8.

The module error I got during the instantiation was (not original, enriched with the error metadata):

"explainedModuleError": {
    "index": "0x08",
    "error": "0x18",
    "type": "contracts.StorageDepositLimitExhausted",
    "details": "More storage was created than allowed by the storage deposit limit."
}

Further description
Actually it's very easy get it reproduced with a minimal example. Write an Inner struct and an Outer struct which contains an Inner.
Store them in hash maps like

pub struct Blbc {
        pub inner_map: HashMap<String, Inner>,
        pub outer_map: HashMap<String, Outer>,
}

and implement a default() constructor. Same error when instantiating.

Expected behavior
Instantiation should succeed just as before.

Attachment
rc-7 wasm: https://1drv.ms/u/s!Aj_rPvkyS8y8gvFVvamGbf8MqsFyxQ?e=QLaqte
rc-7 metadata.json: https://1drv.ms/u/s!Aj_rPvkyS8y8gvFSEuJh7Cf74cI8Eg?e=hGXnCM
rc-8 wasm: https://1drv.ms/u/s!Aj_rPvkyS8y8gvFUY3MRjJR8WjJcRQ?e=ArsySK
rc-8 metadata.json: https://1drv.ms/u/s!Aj_rPvkyS8y8gvFTNx-spU29_T6hIA?e=H2Tgi2

[VargSupercolony]

@czyczk I have a similar issue on my end with substrate-contracts-node. I suspect it might be a Redspot problem in fact. As polkadot.js expects the storageDepositLimit to be passed to instantiateWithCode, Redspot just passes in null instead. I just checked and the substrate-contracts-node indeed needs 6 params to be provided to the call.

[HCastano]

@czyczk do you mind uploading a Gist to GitHub with your contract (Rust + TOML)?

[czyczk]

I see. The problem lies in the new field storageDepositLimit of type BlueprintOptions in Polkadot JS API (which, tracing the source, comes from Substrate (this PR)).

In previous versions (ink rc7 + node 0.3.0 + JS API 6.12.x) I'm not sure whether the field exists, but it never bothered to be specified and the instantiation worked.

I just tried to pass a -1 (try to specify the max limit just like what I did for gas limit) but was rejected because the internal type for the deposit limit is u128.

In the instantiation page of the Substrate Contracts Explorer (the new version of Canvas UI), I see no storage deposit limit. I don't know what version the GitHub hosted pages is based on, but clearly it works.

So the question now is, how can I achieve the same effect, i.e. not specifying the storage deposit limit manually, and still make the instantiation pass?

[cmichi]

@czyczk @VargSupercolony We've figured it out now. It was due to a mispricing of deposits in the latest substrate-contracts-node release.

We've fixed it now and done a new release. You can find the binary releases here or install via:

cargo install contracts-node --git https://github.com/paritytech/substrate-contracts-node.git --tag v0.6.0 --force --locked