Development

Github metrics:

A WASM-based Smart Contract Module for the Cosmos SDK

The Cosmos SDK is written in Golang based on certain design considerations to allow for the customization of modules, however, expanding across many programming languages is crucial to growing developer adoption. Ultimately supporting the greater goal of enabling an Internet of Blockchains — or The Interchain — to support a plethora of implementations and capabilities connected by the Inter-Blockchain Communication Protocol (IBC).

June 2019 marked the first-ever Cosmos HackAtom Berlin and the beginnings of CosmWasm. The hackathon’s goal? Expanding tooling for developers interested in building on the Cosmos Network. CosmWasm, a project enabling WebAssembly (WASM) virtual machines (VMs) in the Cosmos SDK, was one of a number of projects to eventually receive a grant from the Interchain Foundation with regards to developer tooling.

The first implementation of a WASM virtual machine running on top of a Cosmos SDK application has been designed by Ethan Frey from Confio (he’s also the lead engineer at Regen Network). The team is excited to announce that it is now available for the Cosmos community! If you are a Rust developer, you can easily write smart contracts that can be uploaded to any Cosmos SDK based chain that includes the CosmWasm module. You can find more information on the technology at the links below:

Adding WebAssembly to the Cosmos SDK allows software written in many languages to run securely on a blockchain. WASM serves as an intermediate language that compiles the developer’s language of choice into a portable virtual machine. This means that you can have a simple, secure and fast virtual machine set up to sandbox or partition your application’s actions for better testing, security, performance and speed.

The entrance of a new programming language to the Cosmos Network has several benefits for the overall developer ecosystem. First, this product allows developers to write modules in Rust that integrate seamlessly with the Cosmos SDK, so they can take advantage of the mainnet-proven Cosmos-SDK modules and BPoS Tendermint consensus algorithm while developing a largely Rust-based custom application logic. Second, the ability to upload code in transactions, rather than restarting the chain, allows for a much quicker deployment of new features; the Cosmos Hub upgrade procedure is necessary only when making changes in the core logic. This enables application-specific zones to freeze the staking logic and iterate quickly on their core value proposition through custom smart contracts. Especially if they limit contract deployment to governance, this can provide an easy way for the chain to ship code quickly. If they launch a chain with the default permissionless uploading of smart contracts, you can build an Ethereum alternative on Tendermint.

An important consideration for performance when building smart contracts is the data packet size. Web Assembly code is naturally larger than Ethereum bytecode as it offers more generality. Rust has no garbage collector and the standard library can be excluded from builds, which means that a minified simple escrow contract requires around 50kB (16kB compressed). Golang or Haskell are alternatives, but would likely produce contracts of several hundred kB. This consideration, along with the popularity of Rust in the blockchain ecosystem, led the Tendermint team to use this as a first implementation language for Web Assembly contracts in the Cosmos SDK.

While the ecosystem is still nascent, the smart contract environment within CosmWasm is Turing complete. This means that you have the capability to perform any logic that could be implemented in Ethereum and execute it within the Cosmos SDK without modifying the underlying blockchain. The CosmWasm module includes a mature build and test environment and comes with an integrated development environment (IDE) thanks to Rust’s native programming features. For a more detailed guide on “Getting started with CosmWasm” visit the product’s documentation website.

If you are a Rust developer using CosmWasm with the Cosmos SDK means you:

…only need a minimal knowledge of Golang.

… can start building on the Cosmos SDK and integrate easily into the existing Cosmos Network.

…can extend your existing chain or application to the Cosmos chain with minimal overhead.

If you are a Go developer using the Cosmos SDK with CosmWasm, the benefits include:

Only a minimal knowledge of Rust is required thanks to the well-designed CosmWasm tool kit.

Adding Rust programming logic to the Cosmos SDK allows for live upgrades or custom contracts enhancing the customization and execution of your application.

You gain access to Rust’s type safety and testing and the encoding and crypto signatures relatively common in Rust — which are ideal for developing highly secure blockchain applications which could be used in DeFi.

After the successful prototype, the Interchain Foundation provided a grant to Confio to implement a robust version that would work in an adversarial environment. This article introduces developers to the output of that grant work, and lays out possible future directions.

How to use CosmWasm:

CosmWasm is written as a module that can plug into the Cosmos SDK. This means that anyone currently building a blockchain using the Cosmos SDK can quickly and easily add CosmWasm smart contracting support to their chain, without adjusting existing logic. We also provide a sample binary of CosmWasm integrated into the gaiad binary, called wasmd, so you can launch a new smart-contract enabled blockchain out of the box, using documented and tested tooling and the same security model as the Cosmos Hub.

You will need a running blockchain to host your contracts and use them from an app. The team will explain how to set up a local “dev net” in the tutorial. And plan to soon release a hosted testnet, to which all developers can simply upload their contracts, in order to easily run a demo and to share their contract with others.

Once you have a CosmWasm-enabled blockchain, you can deploy a custom contract. This is similar in principle to Ethereum, but there are a number of differences in the details.

Comparison with Solidity Contracts

First of all, the deploy-execute process consists of 3 steps rather than 2. While Ethereum was built around the concept of many unique contracts, each possibly custom-made for any bilateral agreement, the reality seems to show that writing a bug-free contract is harder than originally thought, and a majority are copies of standard templates like OpenZepellin. With that in mind, and conscious of the overhead of uploading and validating wasm code, we define the following 3 phases of a contract:

Upload Code — Upload some optimized wasm code, no state nor contract address (example Standard ERC20 contract)

Instantiate Contract — Instantiate a code reference with some initial state, creates new address (example set token name, max issuance, etc for my ERC20 token)

Execute Contract — This may support many different calls, but they are all unprivileged usage of a previously instantiated contract, depends on the contract design (example: Send ERC20 token, grant approval to other contract)

Just like Ethereum, contract instantiation and execution is metered and requires gas. Furthermore, both instantiation and execution allow the signer to send some tokens to the contract along with the message. Two key differences are that sending tokens directly to a contract, eg. via SendMsg, while possible, does not trigger any contract code. This is a clear design decision to reduce possible attack vectors. It doesn’t make anything impossible, but requires all execution of the contract to be explicitly requested.

Contract Security

Code correctness is paramount in blockchain smart-contracts. As the source code is public and there is no “admin” to fix things, there must be no bugs in the execution paths that can be exploited to produced undesired (or undefined) behavior. Many teams look to use Turing incomplete languages to perform deeper analysis and remove many classes of bugs. The team chooses to use a Turing complete language, like Solidity, but with security as a primary goal. This includes limiting possible attack surface, but also very strong in-built unit test capabilities to easily shake out bugs before deployment.

While CosmWasm development has a steeper learning curve than Solidity (it definitely takes more work to get your first sample contract running), it is designed to be more productive for devs with a couple weeks of experience who wish to produce production-ready code. And they hope to have an architecture and tooling to avoid the need for a whole industry of “CosmWasm smart contract auditors”, as it should be easy to just “do the right thing”.

One major class of attacks in Ethereum (and probably the most infamous due to the DAO hack) is reentrancy. CosmWasm was architected to eliminate the possibility of this class of attacks.

Much like Ethereum, the team takes resource usage seriously. As such, they provide hard limits on memory usage, and gas-based limits on CPU and Storage.

For those who take security very seriously, you can read a longer list of how CosmWasm stacks up against all known Ethereum attack vectors.

For reading Getting Started with CosmWasm click here.

Future Work:

CosmWasm, both the VM as well as the platform, is at a usable alpha-state now and the team is working on refining the last issues to make it production-ready, with your feedback. Smaller fixes needed to make it ready for mainnet are being tracked in this project. In addition to that, they want to build tooling around it, and iterate on new features, ideally focused on the needs of real users. Some of the main points on the current roadmap are: