Terra and CosmWasm — the great, good and ugly
Terra is a decentralised stablecoin which is fast becoming the most popular in its field. Unlike centralised stablecoins, there is no central company which holds $1 USD fiat currency [or less according to what is Tethering :-)] per 1 USD stablecoin. You can read more how Luna is used to stabilise all types of fiat denominated stablecoins, with the most famous being UST. You also have TerraCNY, TerraJPY, TerraGBP, TerraKRW, TerraEUR, and the International Monetary Fund’s TerraSDR. Two of the most prominent projects build on top of Terra are the Anchor Protocol (high return savings) and the Mirror Protocol (mirrors any financial services investment like stock, indexes,…). Terra is fast seeing adoption in several Asian countries as the digital payment solution. Terra is built on top of the Cosmos SDK, more specifically CosmWasm. The project’s focus is on being a global payment system and a decentralised finance accelerator for which Terra stablecoins are integrated with Solana and the Ethereum ecosystem. Via Cosmos’s inter-blockchain communications [IBC] protocol, transfers of tokens between different blockchains are simplified.
CosmWasm uses the actor model for concurrent messaging and Tendermint BFT for consensus. Three types of messages are important inside smart contracts. The init message is to initialise the configuration and values of a smart contract. The handle messages involve all types of messages which change values inside the smart contract or beyond. The query messages allow read-only access to both the raw data and abstracted custom queries. Cosm messages are designed to have protection against denial of service, to avoid concurrency issues, and to eliminate the potential of reentrancy bugs which are soften exploited in Ethereum contracts who call one another. Via modules, reusable functionality can be easily interacted with, e.g. Bank allows for access to native tokens and Staking to simplify staking via delegation, withdrawal and others. These modules allow for easy cross-chain token transfers and staking.
The Great — reusability and security
Given that custom modules are possible, Terra has made Swap, Oracle and Treasury modules for instance. Unlike Solidity and Ethereum two steps, CosmWasm has three steps to deploy and execute a contract. Step one is deploy the code. Step two is instantiate the contract and step three is execute the contract. This differentiation is important from a security perspective. It allows standard ERC20 token contracts to be developed, similar to OpenZeppelin in Ethereum, but unlike Ethereum for these to be instantiated with custom parameters. This avoids introducing new security issues via inheriting, overwriting and incorrectly interacting with third-party code. Via resource limits a lot of Ethereum denial of service attacks are also avoided. In general it is clear that CosmWasm has learnt from several of the security issues found in Ethereum and is trying to address them.
The Good — ease of use and performance
Given that CosmWasm contracts use JSON internally, interacting with them is a lot easier than for instance Solidity’s ABI. Still developing in Rust is harder than learning Solidity but writing a Terra smart contract is so much more strait-forward than a Solana contract with its low-level serialisation.
With a 1000 transaction per seconds [TPS] by around 100 validators, which are punished heavily if they cheat or do not provide service, performance is a lot better than Ethereum [at 20 TPS] but not at the levels of Avalanche [4,500 TPS] and especially Solana [65,000 TPS]. Also the 100 validator number is clearly inferior than the 1000+ Solana validators.
The Ugly — maturity
Documentation and tooling of the Terra project is not really great. Several happy paths in the documentation, e.g. cargo run-script optimize did not work because documentation does not specify you need to do cargo install cargo-run-script. The what is explained with a simple example in the documentation but if compared to the CosmWasm documentation the why and how is often not, leaving the reader wondering why it works in a certain way and how to use Terra beyond a simple example.
Although Terra is supposed to share CosmWasm, the multiple different projects have seen many changes in the versions up to 1.0.0. CosmWasm beginner documentation is using an old version which is not compatible with Terra. A similar problem with TerraLocal and Terrad. Unless an old version (git checkout v0.5.6-oracle) of TerraLocal is used, deployment of code fails with a very unclear message, i.e. error unmarshalling result: unknown field “isOracleTx” in types.ResponseCheckTx. This means that the promise of write once, run on any chain is a future promise and definitely need some more work. The project should urgently fix this type of issues through better governance and automated testing.
Understanding how much you will be charged for a transaction on Terra is not simple. The documentation states a fee of 0.1% of the transaction with a max fee of 1 SDR ($1.42 at the time of writing) [https://www.terra.money/Terra_White_paper.pdf] and normally set to $0.15 or 0.01133 Luna (https://fcd.terra.dev/v1/txs/gas_prices). But the documentation is sketchy at best. This means that $0.15 is the minimum you pay per transaction. Afterwards 0.1% is charged with a $1.42 max for transfers over $1420. So far the theory. However gas fees are not the only part that is charged. In addition a stability fee is charged. While doing tests on TestNet and transferring different amounts of Luna, from 0.001 to 100 Luna, the total fee always came back to 0.01391 Luna or around $0.619. This makes Terra ideal for transferring payments which normally are above $5 but expensive for micro transactions.
Deploying a simple contract was costing 1.609068 Luna ($71.51) in gas fees according to gas used. Strangely when measuring the amount of Luna before and after, 0.419884 Luna ($18.66) was consumed. Both are on the high end compared to other distributed ledgers. When deploying the same contract with $0.15 USD fees specified, $0.419884 where deducted from the USD balance. This seems like a bug. Specifying less than $0.15 USD would give an insufficient fee error.
Unfortunately, I am not able to verify if creating custom tokens is equally as expensive because actions like creating a coin and minting it to validate how much is charged are not straightforward. Sample code is available [https://github.com/terra-money/cosmwasm-plus/tree/main/contracts/cw20-base] but Testnet and LocalTerra do not like any Cosmwasm code that is not exactly compiled with the same version numbers which means substantial rewrites.
Terra.js is supposed to be a very easy way to interact with smart contracts and base modules. Sample code and documentation is available but stupid things like not naming coins the same, e.g. KRT in Terra Vision and uKRW [u for unit but KRW instead of KRT and few documentation on all the other symbols], make even the most basic tasks challenging. Also any error will generate Javascript pages and pages of error logs but gives a rather generic 404 or 400 error which makes debugging really hard.
Conclusion
A very promising distributed ledger solution provided gas fees are not excessive for small transaction use cases as well as software packaging, testing and documentation improves substantially. Creating a user-friendly development environment like Ethereum’s Remix, better deployment tools like Shuffle [I was not able to get the Shuffle alternative for Terra to work] and a catalogue of deployed modules ready for reuse would improve the speed of adoption. At the moment Terra is in the leading but often bleeding edge category.
