RFP 4 - A Scalable, Faster CosmWasm STM Product

Scalability
1

Researchers: Miguel Matos & team at INESC-ID

Summary

CosmWasm (CW) is a smart contract module with a number of strengths, such as its multi-chain contracts and high levels of security. However, a limitation of CosmWasm is its scalability and speed. Thus, we are researching and developing a mechanism for making CW much more scalable in a faster manner. This will support Composable’s CosmWasm Virtual Machine (VM).

This initiative will contribute the following:

  • A software transactional memory (STM) product to make CosmWasm (CW) much more scalable in a faster manner

Completing this initiative will enable us to handle a higher volume of CW transactions, given the enhanced speed and scalability with which they are managed in our ecosystem. This means we can grow larger and support more users.

Background & Problem Statement

Background

Core background concepts/definitions are as follows:

CosmWasm:

Composable selected CosmWasm as the developer framework for smart contract deployment on the CVM as it offers cross-chain support, is tightly compatible with Cosmos chains, and has superior security design.

CosmWasm is an abbreviation derived from the combination of the name Cosmos and the abbreviation for WebAssembly, Wasm. It implements the WASM smart contract engine for the Cosmos SDK and runs on the IBC. This allows projects using CosmWasm to communicate cross-chain between all of the chains linked on the IBC protocol. It enables dApps to function as smart contracts on Cosmos chains, without the need to develop a new chain.

CosmWasm has a significant feature that enables multi-chain contracts, where a single contract can be used across multiple chains in one dApp. With the use of the Cosmos SDK, any chain can easily incorporate the CosmWasm module with minimal system overhead. Our development of pallet-CosmWasm has made it possible for any parachain to integrate and implement the CosmWasm framework on their chain. This integration provides a composition of multiple chains and migration functionality across different chains with pre-contract permission. CosmWasm is designed to connect various blockchains, allowing users to benefit from the utility of multiple chains without the need to choose one over the other. The framework also includes built-in, permissioned, pre-contract migration functionality.

In terms of security, CosmWasm is designed to avoid the attack vectors found in Ethereum and Solidity, such as Reentrancy, Arithmetic Underflows/Overflows, and Default Visibilities. Its security is further reinforced by its well-developed tooling and testing mechanisms prioritized early in its conception.

Due to these benefits, many DeFi projects have adopted CosmWasm as their smart contract framework, including notable examples like Neutron, Secret Network, OKX, Crypto.org, and Osmosis.

Composable’s CosmWasm Virtual Machine:

Composable is the first team building a CW VM outside the Cosmos ecosystem that developers can use to build with all the benefits of CW and the Cosmos Network.

Composable opted for using CosmWasm for a VM, as it will allow developers to run smart contracts directly on the Picasso parachain. This provides novel opportunities, such as enabling existing Cosmos projects and CW developers to run smart contracts in the Polkadot & Kusama (DotSama) ecosystems simultaneously. Accessible, interoperable smart contract creation is crucial for developing ecosystems, especially nascent ecosystems, that will play a significant role in the future of DeFi.

Specifically, our team is creating a portable library version of CW that can be hosted on different implementations to reduce the effort required to port CW to other ecosystems. Composable CosmWasm VM (ccw-vm) has two host implementations which allow developers to easily integrate CosmWasm into their ecosystems. This ensures that ccw-vm is highly portable and has consistent execution semantics regardless of its host. As a result, developers can integrate ccw-vm as a pallet, within a frontend app, or inside a CLI tool.

Problem Statement

Confio’s current implementation of CW is written half in Rust and half in Golang, which means it is not compatible with Substrate and has never been used outside Cosmos. Also, Confio’s CW VM excludes library components but consists of a single implementation targeting the Cosmos SDK. Hence, Composable has created its own CW VM.

Moreover, DotSama does not have options for supporting CW smart contracts - so there is also no STM product designed to increase the scalability of CW on DotSama. Therefore, the present initiative improves the speed and scalability of Composable’s CW VM initiative.

Thus, the research question/objective here is as follows:

  • How can we improve the speed and scalability of CosmWasm and the CosmWasm VM?

Plan & Deliverables

Expected outputs/deliverables are as follows:

  • A software transactional memory (STM) product to make CosmWasm (CW) much more scalable in a faster manner

The plan for achieving this output is outlined below:

Experiment:

We will complete a research experiment with the following steps in order to develop the aforementioned STM product:

  • Create a system of grouping dependent/independent transactions using a scheduler
  • Test this system to determine and optimize its efficiency
  • Deploy this system to improve Composable’s CosmWasm VM

This product will work by using the following components:

  1. STM logic for parallelization of transactions; This would commit transactions in a block with light synchronization (pre-processing) for later scheduling by the scheduler.

  2. Scheduler for ordering the mempool for transaction processing; This should be separated from the consensus protocol, but something that reliably distributes transactions.

  3. Transactions are executed when they are spawned on specific chains; This is considered optimistic execution.

  4. Validation of transactions occurs when the full thread has been completed.

  5. Commitment is the final step after validation where “awaiting” transactions (overlapping threads with dependency) and re-execution in the case of errors.

  6. Note: The same transaction is never executed concurrently by more than one thread.

  7. These committed blocks are considered proposed blocks that are submitted to validators for broadcasting; The leader proposes a block hash of this block during consensus.

The CosmWasm VM must be up and properly running to integrate the STM product. We also need to test out different iterations of the STM product to determine how to best group and schedule transactions in order to enhance speed/scalability.

References

How to Participate

If you’re a researcher who believes that you would be a good fit to contribute to any of the Composable RFPs, please reach out to Composable’s Lead Research Associate, Sydney Sweck, at sydney@composable.finance. In the email, be sure to include:

  • The RFP number(s) you’d like to contribute to
  • Your relevant background experience
  • How you think you could contribute to the research