6

I tried deployed two ink-compatible solidity smart contract using solang as the compiler. When trying to play around cross contract calls, I've stumbled upon the below failure:

Prerequisite:

  1. compile one solidity smart contract using solang: get abi bundle Flip.contract
  2. compile another solidity smart contract Inc that takes another smart contract as constructor input https://github.com/hyperledger-labs/solang/blob/main/integration/substrate/issue666.sol

Route1, using polkadot.js/app:

  1. upload smart contract Flip.contract using the contacts tab.
  2. upload Inc.contract and take the Flip account_address as constructor input. ... salt value is auto generated by polkadot.js app
  3. call the superFlip method on Inc contract to see if it can call external contract Results: ContractTrapped

Route2, using subxt to construct transaction ourself:

  1. deploy Flip.contract, call api.tx().contracts.instantiate_with_code(... same params as route1)
  2. deploy Inc.contract, call api.tx().contracts.instantiate_with_code(... same params as route1) ... both steps have the same input data/gas_limit value as route1, we input salt value using account.nonce value
  3. call the superFlip method on Inc contract to see if it can call external contract Results: ExtrinsicSuccess

Need some help for this, and specifically what should be salt in this scenario. Thx.

Example is produced with this node: https://github.com/paritytech/substrate-contracts-node

Improve this question
6
  • A hunch: docs.astar.network/tutorial/… will have some hints at to what might be up?
    – Nuke
    Commented Mar 18, 2022 at 2:59
  • What are you following as a guide to try this out?
    – Nuke
    Commented Mar 18, 2022 at 3:00
  • Thanks for your reply, but the solidity code is compiled with solang, results in a pallet-contract compatible abi bundle, it's the webassembly contract pallet tht powered ink as well. You can check the hypoerledger solang link above and see the usage of the cli, after that you can follow general ink tutorial to deploy compiled $Some.contract on the substrate-contracts-node to test that out. If for frontend, polkadot.js app has specific contract tab, and there's also a contract-ui to try out. paritytech.github.io/contracts-ui The astar guide is using pallet-ethereum.
    – extraymond
    Commented Mar 19, 2022 at 7:08
  • why is the post titled and tagged with frontier? that's a bit misleading, since frontier is an evm compatibility layer, but your execution environment is wasm
    – Bernardo Rodrigues
    Commented Mar 19, 2022 at 22:25
  • it might also be useful to post which node-template you are using to deploy this contract, with specific references to versions
    – Bernardo Rodrigues
    Commented Mar 19, 2022 at 22:28

2 Answers 2

Reset to default
8

The substrate backend of solang didn't get much love lately for various reasons. As a consequence of this it is out of date and doesn't work flawlessy with newer substrate versions. The current hypothesis is that your current error is connected to salt handling: Solang doesn't calculate he callee's address correctly.

It was discussed in this post: Calling the function of an other contract in Solidity

Also, check out this issue: https://github.com/hyperledger-labs/solang/issues/666

This situation will get better soon when we eventually get more people on the substrate backend.

Improve this answer
2
  • Appreciate your feedback! Hopefully it's really related to my salt findings being the culprit. Would you mind giving any suggestion on where should I look at albeit it being in substrate or solang? Thx
    – extraymond
    Commented Apr 5, 2022 at 15:36
  • I've added a test repo, and seems the error can only be seen if deploying the contracts via polkadot.js.app, tests against the runtime confirms that either method to configure the salt allows the contracts to call each other. github.com/extraymond/substrate-contracts-node/blob/…
    – extraymond
    Commented Apr 7, 2022 at 8:12
3

From solang docs, it seems they target substrate 2.0, which is a relatively outdated release.

It might be worth it to open an issue on the solang repository asking about compatibility with substrate 3.0.

Improve this answer
3
  • The integration test suite they used are running substrate v3, and the above test case passed without any problem.
    – extraymond
    Commented Mar 20, 2022 at 4:50
  • can you share a link where the substrate version is defined on the solang repository?
    – Bernardo Rodrigues
    Commented Mar 20, 2022 at 22:27
  • 1
    Here's the link in their test suite: github.com/hyperledger-labs/solang/blob/…
    – extraymond
    Commented Mar 21, 2022 at 4:20

Not the answer you're looking for? Browse other questions tagged or ask your own question.