|
| 1 | +--- |
| 2 | +title: ink! vs. CosmWasm |
| 3 | +slug: /ink-vs-cosmwasm |
| 4 | +--- |
| 5 | + |
| 6 | +This is a short comparison between [ink!](https://github.com/paritytech/ink/) |
| 7 | +and [CosmWasm](https://github.com/CosmWasm/cosmwasm) meant to onboard |
| 8 | +developers coming from the Cosmos ecosystem. |
| 9 | + |
| 10 | +# Architecture |
| 11 | + |
| 12 | +CosmWasm is modular, meaning that any blockchain using the Cosmos SDK can add smart |
| 13 | +contract support to their chain. That is similar to the [Substrate](https://substrate.io/) |
| 14 | +approach, where chains have the option to add `pallet-contracts` to their runtime. |
| 15 | + |
| 16 | +Aside from that, the architecture philosophy is likely the point where CosmWasm and ink! |
| 17 | +differ the most. CosmWasm follows the actor model design pattern, while ink! follows a |
| 18 | +synchronous execution model. That means some fundamental differences in how the source |
| 19 | +code is structured. |
| 20 | + |
| 21 | +The main entry point functions of CosmWasm contracts are: |
| 22 | +- `instantiate` which bootstraps the initial contract state (assuming it's already been |
| 23 | + deployed). |
| 24 | +- `execute` which has the actor perform operations to its internal state. |
| 25 | +- `query` which retrieves data from the actor’s internal state. |
| 26 | + |
| 27 | +An ink! contract can have as many public dispatchables as the developer desires, and |
| 28 | +differently from CosmWasm, it doesn’t rely on JSON schemas for defining how the messages |
| 29 | +are structured. |
| 30 | + |
| 31 | +Instead, ink! makes heavy usage of Rust macros. The main ink! macros are: |
| 32 | +- `#[ink(constructor)]` which is called when the contract is deployed, and is responsible |
| 33 | + for bootstrapping the initial contract state into the storage. It is analogous to the |
| 34 | + CosmWasm `instantiate` function. |
| 35 | +- `#[ink(storage)]` which annotates a struct that represents the contract's internal |
| 36 | + state. |
| 37 | +- `#[ink(message)]` which marks a function as a publicl dispatchable, meaning that it is |
| 38 | + exposed in the contract interface to the outside world. This macro can make a function |
| 39 | + behave analogously to CosmWasm’s `execute` and `query` functions. This depends on how it |
| 40 | + affects the internal contract state and what the return types. |
| 41 | +- `#[ink(event)]` and `#[ink(topic)]` which annotates a struct and its members as the |
| 42 | + events and topics that the contract might emit. |
| 43 | + |
| 44 | +There are other ink! macros, for which details can be found at [Macros & Attributes](/macros-attributes). |
| 45 | + |
| 46 | +# Unit Testing |
| 47 | + |
| 48 | +Unit testing in CosmWasm is quite similar to ink!. Both use the conventional Rust |
| 49 | +`#[cfg(test)]` macro and set up a mock on-chain environment. |
| 50 | + |
| 51 | +While CosmWasm unit tests have different modules for each of the three main entry-point |
| 52 | +functions, ink! allows for a more generalised approach, where the `#[ink(test)]` macro is |
| 53 | +used for each unit test. |
| 54 | + |
| 55 | +You can read more about ink! unit tests [here](https://ink.substrate.io/basics/contract-testing#unit-tests). |
| 56 | + |
| 57 | +# Compiler |
| 58 | + |
| 59 | +CosmWasm uses [cargo-wasm](https://docs.rs/crate/cargo-wasm/latest) as its main |
| 60 | +compiler, while ink! uses [cargo-contract](https://github.com/paritytech/cargo-contract). |
| 61 | +`cargo-contract` is developed by Parity specifically for building, testing, and deploying |
| 62 | +ink! contracts. |
| 63 | + |
| 64 | +# Local Development Network |
| 65 | + |
| 66 | +In terms of local development networks, the [cosmos/gaia](https://github.com/cosmos/gaia) |
| 67 | +repository acts as the basic template for a generic Cosmos node. With the addition of the |
| 68 | +`x/wasm` module and some clean-up, this template repository becomes |
| 69 | +[wasmd](https://github.com/CosmWasm/wasmd), the entry point for CosmWasm development. |
| 70 | + |
| 71 | +In terms of Substrate, `substrate-node-template` is a basic generic template of a node. |
| 72 | +Similar to `x/wasm`, [`pallet-contracts`[(https://github.com/paritytech/substrate/tree/master/frame/contracts) |
| 73 | +is the module that adds WebAssembly smart contract functionality to the chain. Parity |
| 74 | +provides the [substrate-contracts-node](https://github.com/paritytech/substrate-contracts-node), |
| 75 | +which is analogous to `wasmd` - a basic template node for smart contract development. |
| 76 | + |
| 77 | +# Testnets |
| 78 | + |
| 79 | +For CosmWasm development and on-chain testing, `wasmd` can be operated as a local setup |
| 80 | +(single or multiple nodes), or connected to the `cliffnet` public test network. |
| 81 | + |
| 82 | +ink! contracts can be deployed on a few different options: |
| 83 | +- Locally, on a single or multiple node setup of [`substrate-contracts-node`](https://github.com/paritytech/substrate-contracts-node). |
| 84 | +- [Contracts on Rococo Parachain](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frococo-contracts-rpc.polkadot.io#/explorer), |
| 85 | + which is connected to the [Rococo relay chain test network](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frococo-rpc.polkadot.io#/explorer). |
| 86 | +- [Astar Network’s Shibuya testnet](https://docs.astar.network/maintain/collator/shibuya-network/). |
| 87 | + |
| 88 | +# Development Workflow |
| 89 | + |
| 90 | +## Dependencies |
| 91 | + |
| 92 | +The first step in CosmWasm development is to |
| 93 | +[install dependencies](https://docs.cosmwasm.com/docs/1.0/getting-started/installation), |
| 94 | +namely Go, Rust and `wasmd`. |
| 95 | + |
| 96 | +For ink! you can also find [a setup guide](/getting-started/setup) which will help you |
| 97 | +with dependencies, namely Rust, `cargo-contract` and `substrate-contracts-node`. |
| 98 | + |
| 99 | +## Environment Setup |
| 100 | + |
| 101 | +The next step in the CosmWasm development workflow is |
| 102 | +[setting up the environment](https://docs.cosmwasm.com/docs/1.0/getting-started/setting-env). |
| 103 | +That consists mainly of configuring `wasmd` such that it has prefunded accounts that are able |
| 104 | +to interact with the network. |
| 105 | + |
| 106 | +When `substrate-contracts-node` is started with the `--dev` flag, it already contains well |
| 107 | +known pre-funded accounts (`alice`, `bob`, etc.) which are ready to be used for development. |
| 108 | + |
| 109 | +## Compile and Test |
| 110 | + |
| 111 | +CosmWasm provides example contracts at the |
| 112 | +[cw-contracts](https://github.com/InterWasm/cw-contracts) repository. After the |
| 113 | +repository is cloned, from the contract directory it can be compiled via: |
| 114 | +``` |
| 115 | +$ cargo wasm |
| 116 | +``` |
| 117 | + |
| 118 | +and tested via: |
| 119 | +``` |
| 120 | +$ cargo unit-test |
| 121 | +``` |
| 122 | + |
| 123 | +Similarly, ink! provides an |
| 124 | +[`examples`](https://github.com/paritytech/ink/tree/master/examples) directory of its |
| 125 | +main repository. |
| 126 | + |
| 127 | +A contract can be compiled from its directory via: |
| 128 | +``` |
| 129 | +$ cargo +nightly contract build |
| 130 | +``` |
| 131 | + |
| 132 | +and tested via: |
| 133 | +``` |
| 134 | +$ cargo test |
| 135 | +``` |
| 136 | + |
| 137 | +## Deploy and Interact |
| 138 | + |
| 139 | +CosmWasm contracts are deployed and instantiated with help of the `wasmd` executable. The |
| 140 | +list of step is provided [here](https://docs.cosmwasm.com/docs/1.0/getting-started/interact-with-contract). |
| 141 | + |
| 142 | +It is possible to deploy and interact with ink! contracts using either a CLI |
| 143 | +(`cargo-contract`), or a web UI ([`contracts-ui`](https://paritytech.github.io/contracts-ui/)). |
| 144 | + |
| 145 | +- [Instructions for `cargo-contract`](https://github.com/paritytech/cargo-contract/blob/master/docs/extrinsics.md) |
| 146 | +- [Instructions for `contracts-ui`](/getting-started/deploy-your-contract) |
0 commit comments