Development

Github metrics:

Why Cosmos SDK?

TruStory started out with the goal of building a decentralized app that had the look and feel of a normal app that people are used to. They didn’t want their users to wait for confirmations every time they performed an action, or have to deal with pending transactions. The app also called for a lot of fine-grained transactions based on events fired at specific times. So immediately, building on Ethereum mainnet was out of the picture. They needed something that was more responsive and robust. So they figured an Ethereum-based sidechain might work.

They built an early prototype on Loom SDK, but the framework wasn’t mature enough for their needs at that time. They did, however, take a liking to Tendermint, the BFT-consensus middleware that powers Loom. It allows for fast finality (~5 seconds), which is critical to the user experience of a social app with frequent interaction.

Next, They decided to try out Cosmos SDK since it’s from the same team that built Tendermint. They loved what they saw:

A statically typed, compiled programming language (Go)

A well architected blockchain framework

Modular architecture

Highly configurable

Built-in governance

Another thing that sold their on Cosmos is the ability to build a community of stakeholders around a network. They think networks of the future can be more egalitarian, giving users and stakeholders more control and ownership over the platform. Companies like Airbnb are asking the SEC to make changes to the rules to allow hosts to own a stake in the company. There’s a good chance that social networks of the future will be run more like co-ops than traditional companies.

Users and stakeholders alike will be able to participate as little or as much as they want, as consumers of the service, as network operators (validators), or both. In addition, token holders will be able to delegate their tokens to validators, and passively participate in the network.

Building on Cosmos SDK gives their the technical capability to implement user ownership and governance natively. Users and validators can vote on upgrades and new features, and help uphold the values and guidelines of the network and user community. Users are incentivized to be good citizens and moderate the network. They have already seen successful blockchain governance in action on the Cosmos Hub, the first mainnet launch of a network built on the SDK. Nearly every proposal so far has seen over 60% voting participation.

Building a network that is self-sustaining and self-governing can fix a lot of the issues with current social networks. It is no secret that Facebook has issues with content moderation and privacy.

Staking is DeFi

The incentive structure of TruStory is based around curating content by staking on it. Staking on content can be thought of as the evolution of the Facebook Like button. Likes are great for signaling association, but they don’t provide any sort of reward to the user for investing their time in curating content. Similar to how validators stake ATOM to provide skin-in-the-game and secure the Cosmos Hub, in TruStory, users stake on user-generated content. In the process, users earn interest in the form of TRU, TruStory’s native token.

An incentive structure wouldn’t be complete without disincentives. TruStory content is moderated by users who have earned enough TRU. Users can be slashed for bad behavior, where they are jailed for a period of time. Jailed users lose some of their TRU as punishment.

TruStory also plans on implementing staking at the infrastructure level. Namely, power users can run nodes of the TruStory blockchain, called validators. Validators are responsible for securing the TruStory blockchain by signing transactions and proposing blocks in a proof-of-stake network. Similar to TruStory users, validators stake TRU and are slashed for bad behavior such as downtime and double-signing blocks.

TruStory Architecture Overview

The first version of TruStory was a Schelling Point game based around validating and verifying content, but recently pivoted to a platform for more constructive debate around claims. Cosmos SDK was instrumental in this pivot. They were able to fork their blockchain, while migrating all data over to the new chain.

Every Cosmos chain is bootstrapped with a Genesis File that defines the initial state of the blockchain. To fork the blockchain, a new genesis file can be created with a command-line tool that exports the current app state. Migrations can be run on this genesis file, upgrading it with whatever is needed to bootstrap a new chain. This process is similar to database migrations common in iterative development, and brings a more agile development methodology to blockchain development.

Here’s a high-level view of the basic TruStory architecture.

TruChain Zone contains the validator set that runs TruStory blockchain nodes (TruChain). TruChain is the part that is built with Cosmos SDK and implemented in Go.

TruAPI, also written in Go, is a GraphQL light client that is responsible for querying and broadcasting transactions to the chain. It also communicates with a Postgres database for client-specific data that doesn’t need to live on-chain. This includes data such as chat logs and user profiles that aren’t associated with the value of TRU. GraphQL enables the web and mobile clients to perform queries that seamlessly merge data from both the chain and database.

The native mobile and web clients are written in React Native and React Native for Web respectively. This allows a high level of code sharing between native mobile (iOS and Android) and web. They talk to the chain via TruAPI.

A few microservices also power TruStory, such as a push notification service that works by observing events from Tendermint. Push notifications can be very powerful when combined with governance, as users can be notified directly of new proposals and get reminders to vote.

A TruChain node is built around a few core custom modules:

claim

staking

slashing

bank

The claim module is mostly a data store for claims. It contains all claim content and high level metadata about each claim. Here’s an example of a claim about man-made climate change on TruStory.

The staking module provides all functionality around staking on arguments. A nice feature of Cosmos SDK is block-level events that run before and after each block is processed. After each block, they check for expiring stakes and distribute rewards.

The slashing module implements punishments for bad behavior in the app and rewards users for moderating bad content. For example, if an argument is downvoted by a certain number of users, the argument creator and upvoters get some of their stake slashed. This helps maintain an incentive structure that keeps the community in check.

The bank module keeps track of token supply and all transactions by users. It mainly powers the wallet functionality of the app.

Each TruChain node also provides a CLI and REST interface that will be used by validators for staking at the network level.

Check out Cosmos Module Generator for a tool that generates much of the boilerplate required for custom modules.

Should You Build on Cosmos?

As a fan of decentralized technologies, I’m very excited about Ethereum 2.0. However, it’s still in development and won’t be ready for at least another year. Cosmos Hub, however, launched in March 2019, and has multiple projects already running testnets. After the implementation of IBC (Inter-Blockchain Communication protocol), Cosmos chains like TruChain will be able to talk to the Cosmos Hub, and eventually transfer assets between Bitcoin and Ethereum via peg zones.

Most decentralized apps do not need the security of thousands of proof-of-work Ethereum nodes. A proof-of-stake sidechain or a custom blockchain secured by a hundred, or even a few dozen nodes would suffice. As a bonus, you can create a governance structure that fits the needs of your app, with a more structured way to handle forks, upgrades, and decisions pertaining to the future of the network. Cosmos SDK is one of the best options to build this future with.

However, building a validator community and running a sovereign chain may not fit the needs of every project. Some may want to buy into an existing validator set and the security it provides. Parity’s Polkadot, for example, is built around a shared security model where each chain connects to a relay chain and inherits its security. While Cosmos currently relies on each chain providing its own security, there are plans to offer shared security in the future.

Another advantage of custom Cosmos chains is not having the requirement of paying gas fees in a platform token (like ETH on Ethereum). These gas fees are often going to parties that have nothing to do with your app or project. Cosmos allows gas to be paid in the native token of your app, and gives validators control over the fees they would like to charge.

P.A.N.I.C. (Python Alerter for Nodes In Cosmos) by Simply VC is a powerful and lightweight open source monitoring and alerting solution for Cosmos nodes. It is compatible with any chain built using the Cosmos SDK. The tool was built with user friendliness in mind, without excluding cool and useful features like phone calls for major alerts and Telegram commands for increased control over your alerter.

The alerter’s focus on a modular design means that it is beginner friendly but also developer friendly. It allows the user to decide which components of the alerter to set up while making it easy for developers to add new features. P.A.N.I.C. also offers two levels of configurability, user and internal, allowing more experienced users to fine-tune the alerter to their preference.