How to interact between a smart contract written in Solidity from a smart contract written in ink!?

Question

In the repository of the cargo-contract CLI tool, which currently "helps you develop smart contracts in Parity's ink!, which is a Rust eDSL allowing you to write smart contracts for blockchains built on the Substrate framework", there is an opportunity here to extend it to support Solang so developers could use it to write smart contracts in either ink! (which compiles to WASM) or Solidity (which compiles to WASM using Solang compiler), which they could then deploy to chains that implement the Substrate Contracts module. However, they'd need to use a different compiler like solc to compile down to EVM-compatible bytecode if they wanted to deploy it to chains that implement the EVM, so I think the CLI should give them a choice of whether they want to compile the Solidity code to WASM or EVM-compatible bytecode.

If cargo-contract had this feature of also supporting smart contracts written in Solidity then I was thinking it could be valuable for decentralization and adoption of blockchain and Web3 and multi-chain deployment, since developers could more seamlessly build the smart contracts of a DApp that uses a combination of both ink! and Solidity at the same time.

They'd be able to write smart contracts in Solidity that I think would be able to interact with Moonbeam-specific precompiles (EVM bytecodes used to run cryptographic computations within acceptable gas limits) through Solidity interfaces using the Ethereum API, which are ultimately used to interact with the underlying Substrate interface, as shown here.

But the smart contracts written in Solidity (or other languages like Vyper) that use solc to compile down to EVM-compatible bytecode could only be deployed to chains that have a full EVM implementation, such as Ethereum and Moonbeam.

Whilst the smart contracts written in ink! are compiled into the web binary standard WebAssembly with file extension .wasm that may be deployed to chains that have a Substrate Contracts module implementation.

But if in the future chains like Ethereum 2.0 and Moonbeam, and chains implementing the Substrate Contracts module, all supported a gas-efficient eWASM (Ethereum WebAssembly) standard, then most precompiles could become redundant.

Then CLI tools like cargo-contract could compile smart contracts written in ink! and Solidity into eWASM, and they could be deployed to any chain that supported eWASM.

Question: But how would it be possible to build smart contracts written in ink! that call public functions in smart contracts written in Solidity and vice versa? Could the smart contracts written in ink! use Rust FFI to interface with the smart contracts written in Solidity? Or would it make more sense in any case to (or be necessary to) just first transpile Solidity to ink! using a transpiler like sol2ink, and then compile to WASM (or eWASM in future).

Update: It seems like the Solang team have already thought about this possibility here.

References:

• https://use.ink/ink-vs-solidity/
• https://www.parity.io/blog/wasm-smart-contract-development/

Answer 1

But how would it be possible to build smart contracts written in ink! that call public functions in smart contracts written in Solidity and vice versa?

We need to distinguish between Solidity contracts compiled to Wasm running on the contracts pallet (i.e. they execute within the same runtime) vs. Solidity contracts compiled into EVM bytecode running on pallet EVM.

For the first case, technically it does not matter in what language a contract was written. In practice there are 2 small nuances.

• The concepts of the Result type and the language error don't exist in Solidity. Instead, the contract will always return the concrete value instead of a Result<T, LanguageError> returned by ink! contracts.
• Solidity and ink! have different (incompatible) ways of calculating their function selectors.

You can refer to this solang integration test as an example how to call into a Solidity contract from ink!. Calling ink! contracts from Solidity does work fine too.

The latter case requires cross contract calls between 2 different execution engines. Which is much more sophisticated and requires something like this to work.