CosmWasm for CTOs
Why CosmWasm is the best platform to launch your next blockchain project.
Now that we have released CosmWasm v1.0 and a number of blockchains will add support for this in the next few months, it is a great time to get onboard. Whether you have been considering launching your project on Ethereum or one of the EVM-based scalability solutions, or were considering launching a sovereign blockchain, most likely, you will find CosmWasm a cheaper, easier, and more secure solution.
Comparison Overview
CosmWasm can compete both with leading Smart Contract Engines as well as Native Blockchain SDKs.
“Level of Customization” and “Native Chain Features” are not available in CosmWasm by default, but can be enabled if you embed it into a custom Cosmos SDK chain. There are chains connecting CosmWasm to GPUs and others replacing the dPOS implementation with smart contracts. CosmWasm development is quick, once you have skilled Rust developers that understand the API. However, the learning curve, especially if they need to learn Rust, can be high.
These claims are not mere hyperbole. I have built multiple blockchain SDKs before and integrated all my learnings from these and other ones I have studied into the design of CosmWasm. I was the original architect of the Cosmos SDK and wrote the first IBC whitepaper in 2017. In 2018, I left to create Weave (“The other Cosmos SDK”) which was technically correct but lacked developer adoption. In fact, it pioneered Protobuf APIs and had a rich JS client (which was the basis of CosmJS). And much of the post-Stargate design of the Cosmos SDK was heavily informed by studying my earlier work.
I have also used Solidity and seen the importance of good developer tooling. However, I also have seen how baking design decisions into the fundamental infrastructure of the platform makes them brittle and hard to adapt in the future, and ensured we allow chains to customize and extend CosmWasm, while maintaining compatibility and avoiding forks.
Better than the EVM
To give it credit, Ethereum and the EVM is a runaway success story. From the idea of a “World Computer”, a small team created the first blockchain that could challenge Bitcoin, and launched the first smart contract platform. It now has a market cap in the $100s of billions and huge developer adoption. In fact, most smart contract chains to date with significant developer adoption are forks of Ethereum and run the EVM. Why would anyone not choose it?
Security. Solidity and EVM have been riddled with attack vectors built into the design. Even when following best practices, and getting reputable audits, we see hack after hack, especially in the DeFi world. Much of this is based on a powerful architecture that is very difficult to secure. Even using reentrancy guards on their contracts, CREAM finance was recently exploited for millions based on a reentrancy attack. And the Parity MultiSig Hack which lost $1.5 Billion in ETH at today’s value was written by the top Ethereum developers. The exploit involved library contracts and proxies… powerful but dangerous constructs not needed in CosmWasm. CosmWasm prevents reentrancy by design, and provides a first-class experience to migrate contracts rather than some “library contract” pattern. In fact, CosmWasm prevents most classes of attacks present in Solidity
Testing. Even if a projects triple checks all the doors and there is no known “attack vector”, many fall victim to basic errors in the business logic. Mistakes in if conditions or loop guards can leak millions. Recently Compound gave away $90 million by mistake, due to using < rather than <= in an if statement. This is a hard issue to audit, but easy to cover with unit tests… if it was easy to unit test Solidity. CosmWasm made testing at many levels (unit, integration and full-stack) a first class citizen from day one and make it easy to provide solid coverage to critical business logic.
Performance / Cost. Gas prices on Ethereum have skyrocketed, which have already driven many projects to BSC, Polygon, or Fantom. This is due to the high popularity of the chain along with a limit of around 30 tx per second and market pricing for space. CosmWasm can easily handle several hundred tx per second, and is deployed on multiple, connected chains, splitting the load and keeping costs low… much like the Ethereum 2.0 vision.
Composition. The key to Ethereum’s success in DeFi is based on the ability to compose multiple projects, or “build DeFi Legos”. It is easy to connect contracts, but we see such composition is very dangerous — even when the other contract is legitimate, composition multiplies the attack surface for exploits and is extremely difficult to test. CosmWasm provides all the power of contract composition as in Ethereum, but with architectural support to allow you build complex composition safely. You can look at Anchor Protocol as an quite complex process built on an early release of CosmWasm. The design is even more powerful now as Mars Protocol and others will show.
Lock-In. Once you deploy your project on one chain, it is very hard to switch. Especially when you integrate with other projects. There is no method to compose across multiple chains, nor migrate a project to another blockchain. However, building upon the Cosmos SDK and IBC, CosmWasm provides such power.
If your project becomes too large and you want to move to your own sovereign zone, you can easily launch a new CosmWasm zone based on wasmd, with Inter Blockchain Communication baked in. You can then iterate on new multi-chain protocols as CosmWasm contracts and allow users to opt-in to your new chain, while still maintaining a first class connection to protocols on the original chain.
This is a huge area and will be the subject of an entire article in Part V.
I do recognize that Ethereum has a huge developer lock-in, and many projects have failed trying to replace Ethereum as a general purpose smart contracting platform. This is why CosmWasm focused on providing multiple, specialized smart contracting platforms. And with the new world of IBC and Bridges, you don’t have to run on Ethereum to be composable with it… just check out Sommelier for an example.
Better than Cosmos SDK Modules
Solidity is actually a quite easy target to challenge, and when building CosmWasm, we compared ourselves with the Cosmos SDK, one of the top blockchain construction kits. It allows you to write native code in Go and quickly wire up modules from many sources to produce powerful, application-specific blockchains. Cosmos SDK comes with amazing power built in. A world class POS system as on the Cosmos Hub, on-chain governance, and IBC. You just need to write some modules in Go with your custom logic and wire them in.
However, if you want to extend the Cosmos SDK, CosmWasm provides you with most of the power of native modules, similar performance and simpler, stabler interfaces. It also removes the need to run your own blockchain just to launch a DEX. There are some cases when you really need a native Cosmos SDK module. If you are working on a new consensus mechanism (to replace the standard dPOS), overhauling the fee handling mechanism, or integrating a GPU compute engine, please use native Go modules, which provide unlimited flexibility and native power. However, for the majority of blockchain projects, you are better off coding your idea in CosmWasm (even if you do launch it in a soverign zone).
No Chain Needed. There is a lot of overhead in launching and maintaining a standalone chain. While the Cosmos SDK simplifies much of the technical effort, a developer still needs to attract and sufficiently incentivize a strong community of validators to run the network, which can be a daunting endeavor for early projects. With CosmWasm you can simply deploy to an existing blockchain of your choice, and you can migrate onto your own chain (or a different chain) when needed.
Ease of Migrations. A lot of work has been done in Stargate to make upgrading a Cosmos SDK module easier, but it is still hard. CosmWasm has a permissioned, per-contract migrate function built in. This allows you to migrate contract by contract to a new codebase and run a migration function to do any required data transformations during this process. No chain-wide coordination required.
Stable APIs. While the Cosmos SDK keeps adding features, they also keep breaking APIs. As any project following Cosmos for a while knows, there is a lot of lost developer time with each upgrade. CosmWasm now has committed to v1.0 stability and your code will run unmodified on Cosmos SDK 0.42, 0.44, 0.45 and beyond. Future versions of CosmWasm will provide opt-in features (eg. BLS signature verification) but be completely backwards compatible.
Better Storage APIs. One of my personal pain points in the Cosmos SDK is the lack of wrappers around a raw byte -> byte key-value store. And a source of pride of the Weave framework was the ORM-like helpers. CosmWasm goes even further with cw-storage-plus, an opt-in wrapper around raw storage. It allows you easily map something like (Addr, u32) -> Vote with one line of code, getting type-safe access to the database. It also provides automatic secondary indexes and lazy snapshotting if desired.
Easy composition. While there are many modules built in the Cosmos SDK and it is not hard to import a number of them to add multiple features to your chain, it is not so easy to integrate them with each other. Allowing two different modules to talk to each other requires some intricate wiring of capabilities, and modifications to any module that calls another. This works fine if one project is building 3 or 4 modules as one product. But not so easy when multiple projects want to integrate their modules together… not to mention the trust issue of running foreign code un-sandboxed. On the other hand, CosmWasm makes it easy for multiple projects to upload contracts and wire them together with many safety guarantees built in.
Other Contenders
There are some other contenders for general purpose platforms to build your system, but not that many. The only smart contracting platform beyond the EVM and CosmWasm to get much traction in DeFi is Solana. To be honest, no one can come close to Solana with throughput. But the API is super low-level and difficult. Best to optimize large classes of simpler contracts.
The majority of Blockchains have forked Bitcoin or Ethereum. And those that haven’t have custom-built a single blockchain. Besides the Cosmos SDK, I only know of one other “blockchain development kit” that will let you quickly combine modules into your own blockchain, Parity’s Substrate. You can argue the relative merits with the Cosmos SDK and it does have a better upgrade story. But most of the arguments above still hold (para-chains are expensive), and I have yet to see any serious project use the ink! programming language.
Deep Dive into Details
Coming up is a six-part series going into detail of various aspects of the CosmWasm platform, so you can see the architecture behind such bold claims above.
- Part I, The Architecture: Focus on security and testing
- Part II, Advanced Usage: Migrations, submessages and more
- Part III, Better than Native Modules: Composability, upgrades and more
- Part IV, Native Integrations: connecting contracts with custom SDK modules
- Part V, Performance: Benchmarks and comparisons
- Part VI, IBC: How to build multi-chain native contracts
- Part VII, Real World Examples: How some chains are already benefiting
Please follow me or CosmWasm on Medium to get all the new articles. I will be linking them here once they are released.
