Add page comparing ink! and CosmWasm #63

bernardoaraujor · 2022-05-20T20:10:06Z

HCastano

Good start!

By the way, do you also mind wrapping lines at 90 characters?

HCastano · 2022-05-21T10:02:08Z

docs/intro/ink-vs-cosmwasm.md

+
+The architecture philosophy is likely the point where CosmWasm and ink! differ the most. CosmWasm follows the actor model design pattern, while ink! follows a synchronous execution model. That means some fundamental differences in how the source code is structured.
+
+After a CosmWasm contract is deployed to the chain, it needs to be instantiated before it is usable. An ink! contract on the other hand is usable right after it’s been deployed.


Under the hood we also have a different deploy and instantiate steps, but the UIs just hide that for you. One benefit of this is that you can deploy a contract once (say, an ERC-20) and instantiate it multiple times with different parameters (token name, decimals, etc.).

Not sure if this need to be in the Architecture section though, could be closer to where we talk about the constructors

HCastano · 2022-05-21T10:03:52Z

docs/intro/ink-vs-cosmwasm.md

+- `execute` which has the actor perform operations to its internal state.
+- `query` which retrieves data from the actor’s internal state.
+
+An ink! contract can have as many entry point functions as the developer desires, and differently from CosmWasm, it doesn’t rely on JSON schemas for defining how the messages are structured. Instead, ink! makes heavy usage of Rust macros. The main ink! macros are:


When you refer to "entry point functions" do you mean public dispatchables (e.g #[ink(message)])?

HCastano · 2022-05-21T10:04:20Z

docs/intro/ink-vs-cosmwasm.md

+An ink! contract can have as many entry point functions as the developer desires, and differently from CosmWasm, it doesn’t rely on JSON schemas for defining how the messages are structured. Instead, ink! makes heavy usage of Rust macros. The main ink! macros are:
+- `#[ink(storage)]` which annotates a struct with the main variables that represent a contract internal state.
+- `#[ink(event)]` and `#[ink(topic)]` which annotates a struct and its members as the events and topics that the contract might emit.
+- `#[ink(constructor)]` which is called when the contract is deployed, and is responsible for bootstrapping the initial contract state into the storage. It is analogous to the CosmWasm instantiate function, with the difference that it is called as soon as the contract is deployed onto the chain, not on separate instantiation calls.


Suggested change

- `#[ink(constructor)]` which is called when the contract is deployed, and is responsible for bootstrapping the initial contract state into the storage. It is analogous to the CosmWasm instantiate function, with the difference that it is called as soon as the contract is deployed onto the chain, not on separate instantiation calls.

- `#[ink(constructor)]` which is called when the contract is deployed, and is responsible for bootstrapping the initial contract state into the storage. It is analogous to the CosmWasm `instantiate` function, with the difference that it is called as soon as the contract is deployed onto the chain, not on separate instantiation calls.

HCastano · 2022-05-21T10:15:55Z

docs/intro/ink-vs-cosmwasm.md

+- `query` which retrieves data from the actor’s internal state.
+
+An ink! contract can have as many entry point functions as the developer desires, and differently from CosmWasm, it doesn’t rely on JSON schemas for defining how the messages are structured. Instead, ink! makes heavy usage of Rust macros. The main ink! macros are:
+- `#[ink(storage)]` which annotates a struct with the main variables that represent a contract internal state.


Suggested change

- `#[ink(storage)]` which annotates a struct with the main variables that represent a contract internal state.

- `#[ink(storage)]` which annotates a struct which represents contract's internal state.

HCastano · 2022-05-21T10:17:37Z

docs/intro/ink-vs-cosmwasm.md

+An ink! contract can have as many entry point functions as the developer desires, and differently from CosmWasm, it doesn’t rely on JSON schemas for defining how the messages are structured. Instead, ink! makes heavy usage of Rust macros. The main ink! macros are:
+- `#[ink(storage)]` which annotates a struct with the main variables that represent a contract internal state.
+- `#[ink(event)]` and `#[ink(topic)]` which annotates a struct and its members as the events and topics that the contract might emit.
+- `#[ink(constructor)]` which is called when the contract is deployed, and is responsible for bootstrapping the initial contract state into the storage. It is analogous to the CosmWasm instantiate function, with the difference that it is called as soon as the contract is deployed onto the chain, not on separate instantiation calls.


Suggested change

- `#[ink(constructor)]` which is called when the contract is deployed, and is responsible for bootstrapping the initial contract state into the storage. It is analogous to the CosmWasm instantiate function, with the difference that it is called as soon as the contract is deployed onto the chain, not on separate instantiation calls.

- `#[ink(constructor)]` which is called when the contract is deployed, and is responsible for bootstrapping the initial contract state into the storage. It is analogous to the CosmWasm instantiate function.

HCastano · 2022-05-21T10:21:00Z

docs/intro/ink-vs-cosmwasm.md

+The architecture philosophy is likely the point where CosmWasm and ink! differ the most. CosmWasm follows the actor model design pattern, while ink! follows a synchronous execution model. That means some fundamental differences in how the source code is structured.
+
+After a CosmWasm contract is deployed to the chain, it needs to be instantiated before it is usable. An ink! contract on the other hand is usable right after it’s been deployed.
+


I'd add a section here like

# Development

HCastano · 2022-05-21T10:21:18Z

docs/intro/ink-vs-cosmwasm.md

+
+For CosmWasm development and on-chain testing, `wasmd` can be operated as a local setup (single or multiple nodes), or connected to the `cliffnet` public test network.
+
+Ink! contracts can be deployed on a few different options:


Suggested change

Ink! contracts can be deployed on a few different options:

ink! contracts can be deployed on a few different options:

HCastano · 2022-05-21T10:21:45Z

docs/intro/ink-vs-cosmwasm.md

+
+There are other ink! macros, for which details can be found at [Macros & Attributes](/macros-attributes).
+
+# Node Template


Suggested change

# Node Template

# Local Development Network

HCastano · 2022-05-21T10:23:05Z

docs/intro/ink-vs-cosmwasm.md

+
+# Node Template
+
+CosmWasm is modular, meaning that any blockchain using the Cosmos SDK can add smart contract support to their chain. That is similar to the Substrate approach, where chains have the option to add pallet-contracts to their runtime.


I'd move this to the Architecture section

HCastano · 2022-05-21T10:25:59Z

docs/intro/ink-vs-cosmwasm.md

+
+In terms of Substrate, `substrate-node-template` is a basic generic template of a node. Similar to `x/wasm`, `pallet-contracts` is the module that adds WebAssembly smart contract functionality to the chain. Parity provides [substrate-contracts-node](https://github.com/paritytech/substrate-contracts-node), which is analogous to `wasmd`: a basic template node for smart contract development.
+
+# Testnets


I'd move this after Unit Testing

HCastano

Thanks!

bootstrap ink-vs-cosmwasm

8df1f37

bernardoaraujor requested review from cmichi and HCastano May 20, 2022 20:10

HCastano reviewed May 21, 2022

View reviewed changes

bernardoaraujor and others added 5 commits May 23, 2022 09:48

update

9be89c2

development workflow

041013a

Wrap lines and remove trailing spaces

a28cf38

Add more links and fix wording

bc6d0f5

Move some sections around

e4c6473

HCastano changed the title ~~ink-vs-cosmwasm~~ Add page comparing ink! and CosmWasm May 24, 2022

HCastano approved these changes May 24, 2022

View reviewed changes

Update broken link

c3d0e10

HCastano merged commit 873ef8e into master May 24, 2022

HCastano deleted the bar-cosmwasm branch May 24, 2022 16:38

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add page comparing ink! and CosmWasm #63

Add page comparing ink! and CosmWasm #63

bernardoaraujor commented May 20, 2022 •

edited

Loading

HCastano left a comment

HCastano May 21, 2022

HCastano May 21, 2022

HCastano May 21, 2022

HCastano May 21, 2022

HCastano May 21, 2022

HCastano May 21, 2022

HCastano May 21, 2022

HCastano May 21, 2022

HCastano May 21, 2022

HCastano May 21, 2022

HCastano left a comment


		The architecture philosophy is likely the point where CosmWasm and ink! differ the most. CosmWasm follows the actor model design pattern, while ink! follows a synchronous execution model. That means some fundamental differences in how the source code is structured.

		After a CosmWasm contract is deployed to the chain, it needs to be instantiated before it is usable. An ink! contract on the other hand is usable right after it’s been deployed.

	- `#[ink(constructor)]` which is called when the contract is deployed, and is responsible for bootstrapping the initial contract state into the storage. It is analogous to the CosmWasm instantiate function, with the difference that it is called as soon as the contract is deployed onto the chain, not on separate instantiation calls.
	- `#[ink(constructor)]` which is called when the contract is deployed, and is responsible for bootstrapping the initial contract state into the storage. It is analogous to the CosmWasm `instantiate` function, with the difference that it is called as soon as the contract is deployed onto the chain, not on separate instantiation calls.

	- `#[ink(storage)]` which annotates a struct with the main variables that represent a contract internal state.
	- `#[ink(storage)]` which annotates a struct which represents contract's internal state.


		For CosmWasm development and on-chain testing, `wasmd` can be operated as a local setup (single or multiple nodes), or connected to the `cliffnet` public test network.

		Ink! contracts can be deployed on a few different options:


		There are other ink! macros, for which details can be found at [Macros & Attributes](/macros-attributes).

		# Node Template


		# Node Template

		CosmWasm is modular, meaning that any blockchain using the Cosmos SDK can add smart contract support to their chain. That is similar to the Substrate approach, where chains have the option to add pallet-contracts to their runtime.


		In terms of Substrate, `substrate-node-template` is a basic generic template of a node. Similar to `x/wasm`, `pallet-contracts` is the module that adds WebAssembly smart contract functionality to the chain. Parity provides [substrate-contracts-node](https://github.com/paritytech/substrate-contracts-node), which is analogous to `wasmd`: a basic template node for smart contract development.

		# Testnets

Add page comparing ink! and CosmWasm #63

Add page comparing ink! and CosmWasm #63

Conversation

bernardoaraujor commented May 20, 2022 • edited Loading

HCastano left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

HCastano left a comment

Choose a reason for hiding this comment

bernardoaraujor commented May 20, 2022 •

edited

Loading