Introduction
Cosmos is a network of many independent blockchains, called zones. The zones are powered by Tendermint Core, which provides a high-performance, consistent, secure PBFT-like consensus engine, where strict fork-accountability guarantees hold over the behaviour of malicious actors. Tendermint Core’s BFT consensus algorithm is well suited for scaling public proof-of-stake blockchains.
The first zone on Cosmos is called the Cosmos Hub. The Cosmos Hub is a multi-asset proof-of-stake cryptocurrency with a simple governance mechanism which enables the network to adapt and upgrade. In addition, the Cosmos Hub can be extended by connecting other zones.
The hub and zones of the Cosmos network communicate with each other via an inter-blockchain communication (IBC) protocol, a kind of virtual UDP or TCP for blockchains. Tokens can be transferred from one zone to another securely and quickly without the need for exchange liquidity between zones. Instead, all inter-zone token transfers go through the Cosmos Hub, which keeps track of the total amount of tokens held by each zone. The hub isolates each zone from the failure of other zones. Because anyone can connect a new zone to the Cosmos Hub, zones allow for future-compatibility with new blockchain innovations.
Technology
VALIDATORS
In classical Byzantine fault-tolerant (BFT) algorithms, each node has the same weight. In Tendermint, nodes have a non-negative amount of voting power, and nodes that have positive voting power are called validators. Validators participate in the consensus protocol by broadcasting cryptographic signatures, or votes, to agree upon the next block.
Validators’ voting powers are determined at genesis, or are changed deterministically by the blockchain, depending on the application. For example, in a proof-of-stake application such as the Cosmos Hub, the voting power may be determined by the amount of staking tokens bonded as collateral.
NOTE: Fractions like ⅔ and ⅓ refer to fractions of the total voting power, never the total number of validators, unless all the validators have equal weight. >⅔ means “more than ⅔”, ≥⅓ means “at least ⅓”.
CONSENSUS
Tendermint is a partially synchronous BFT consensus protocol derived from the DLS consensus algorithm. Tendermint is notable for its simplicity, performance, and fork-accountability. The protocol requires a fixed known set of validators, where each validator is identified by their public key. Validators attempt to come to consensus on one block at a time, where a block is a list of transactions. Voting for consensus on a block proceeds in rounds. Each round has a round-leader, or proposer, who proposes a block. The validators then vote, in stages, on whether to accept the proposed block or move on to the next round. The proposer for a round is chosen deterministically from the ordered list of validators, in proportion to their voting power.
The full details of the protocol are described here.
Tendermint’s security derives from its use of optimal Byzantine fault-tolerance via super-majority (>⅔) voting and a locking mechanism. Together, they ensure that:
- ≥⅓ voting power must be Byzantine to cause a violation of safety, where more than two values are committed.
- if any set of validators ever succeeds in violating safety, or even attempts to do so, they can be identified by the protocol. This includes both voting for conflicting blocks and broadcasting unjustified votes.
Despite its strong guarantees, Tendermint provides exceptional performance. In benchmarks of 64 nodes distributed across 7 datacenters on 5 continents, on commodity cloud instances, Tendermint consensus can process thousands of transactions per second, with commit latencies on the order of one to two seconds. Notably, performance of well over a thousand transactions per second is maintained even in harsh adversarial conditions, with validators crashing or broadcasting maliciously crafted votes. See the figure below for details.
LIGHT CLIENTS
A major benefit of Tendermint’s consensus algorithm is simplified light client security, making it an ideal candidate for mobile and internet-of-things use cases. While a Bitcoin light client must sync chains of block headers and find the one with the most proof of work, Tendermint light clients need only to keep up with changes to the validator set, and then verify the >⅔ PreCommits in the latest block to determine the latest state.
Succinct light client proofs also enable inter-blockchain communication.
PREVENTING ATTACKS
Tendermint has protective measures for preventing certain notable attacks, like long-range-nothing-at-stake double spends and censorship.
ABCI
The Tendermint consensus algorithm is implemented in a program called Tendermint Core. Tendermint Core is an application-agnostic “consensus engine” that can turn any deterministic blackbox application into a distributedly replicated blockchain. Tendermint Core connects to blockchain applications via the Application Blockchain Interface (ABCI). ABCI is an interface that defines the boundary between the replication engine (the blockchain), and the state machine (the application). By using a socket protocol, we enable a consensus engine running in one process to manage an application state running in another. Thus, the ABCI allows for blockchain applications to be programmed in any language, not just the programming language that the consensus engine is written in. Additionally, the ABCI makes it possible to easily swap out the consensus layer of any existing blockchain stack.
We draw an analogy with the well-known cryptocurrency Bitcoin. Bitcoin is a cryptocurrency blockchain where each node maintains a fully audited Unspent Transaction Output (UTXO) database. If one wanted to create a Bitcoin-like system on top of ABCI, Tendermint Core would be responsible for
- Sharing blocks and transactions between nodes
- Establishing a canonical/immutable order of transactions (the blockchain)
Meanwhile, the ABCI application would be responsible for
- Maintaining the UTXO database
- Validating cryptographic signatures of transactions
- Preventing transactions from spending non-existent funds
- Allowing clients to query the UTXO database
Tendermint is able to decompose the blockchain design by offering a very simple API between the application process and consensus process.
Cosmos SDK and other application layer frameworks
Tendermint Core reduces the development time of a blockchain from years to weeks, but building a secure ABCI-app from scratch remains a difficult task. This is why the Cosmos SDK exists.
The Cosmos SDK is a generalized framework that simplifies the process of building secure blockchain applications on top of Tendermint Core. It is based on two major principles:
- Modularity: The goal of the Cosmos SDK is to create an ecosystem of modules that allows developers to easily spin up application-specific blockchains without having to code each bit of functionality of their application from scratch. Anyone can create a module for the Cosmos SDK, and using ready built modules in your blockchain is as simple as importing them into your application. For example, the Tendermint team is building a set of basic modules that are needed for the Cosmos Hub. These modules can be used by any developer as they build their own application. Additionally, developers can create new modules to customize their application. As the Cosmos network develops, the ecosystem of SDK modules will expand, making it increasingly easier to develop complex blockchain applications.
- Capabilities-based security: Capabilities constrain the security boundaries between modules, enabling developers to better reason about the composability of modules and limit the scope of malicious or unexpected interactions. For a deeper look at capabilities click here.
The Cosmos SDK also comes with a set of useful developer tools for building command line interfaces (CLI), REST servers and a variety of other commonly used utility libraries.
One final remark: the Cosmos SDK, like all Cosmos tools, is designed to be modular. Today, it allows developers to build on top of Tendermint Core. However, it can be used with any other consensus engines that implements the ABCI. As time goes by, we expect multiple SDKs to emerge, built with different architecture models and compatible with multiple consensus engines — all within a single ecosystem: the Cosmos Network.
ETHERMINT
The great thing about the Cosmos SDK is that its modularity allows developers to port virtually any existing blockchain codebase already in Golang on top of it. For example, Ethermint is a project that ports the Ethereum Virtual Machine into an SDK module. Ethermint works exactly like Ethereum but also benefits from all the properties of Tendermint Core. All the existing Ethereum tools (Truffle, Metamask, etc.) are compatible with Ethermint and you can port your smart contracts over without additional work.
Connecting Blockchains Together — IBC
Now that developers have a way to quickly build customized blockchains, let us see how to connect these blockchains together. The connection between blockchains is achieved through a protocol called Inter-Blockchain Communication protocol (IBC). IBC leverages the instant finality property of Tendermint consensus (although it can work with any “fast-finality” blockchain engine) to allow heterogeneous chains to transfer value (i.e. tokens) or data to each other.
WHAT ARE HETEROGENEOUS CHAINS?
Essentially it comes down to two things:
- Different layers: Heterogeneous chains have different layers, meaning they can differ in how they implement the networking, consensus and application parts. To be compatible with IBC, a blockchain needs only follow a few requirements, the main one being that the consensus layer must have fast finality. Proof-of-Work chains (like Bitcoin and Ethereum) do not fall in this category, as they have probabilistic finality.
- Sovereignty: Every blockchain is maintained by a set of validators whose job is to agree on the next block to commit to the blockchain. In Proof-of-Work blockchains these validators are called miners. A sovereign blockchain is a blockchain with its own validator set. In many instances it is important for blockchains to be sovereign, as validators are ultimately responsible for modifying the state. In Ethereum, applications are all run by a common set of validators. Because of this, each application only has limited sovereignty.
IBC allows heterogeneous blockchains to transfer tokens and data to each other, meaning that blockchains with different applications and validator sets are interoperable. For example, it allows public and private blockchains to transfer tokens to each other. Currently, no other blockchain framework enables this level of interoperability.
HOW IBC WORKS
The principle behind IBC is fairly simple. Let us take an example where an account on chain A wants to send 10 tokens (let us call them Atoms) to chain B.
Tracking
Continuously, chain B receives the headers of chain A, and vice versa. This allows each chain to track the validator set of the other. In essence, each chain runs a light-client of the other.
Bonding
When the IBC transfer is initiated, the Atoms are locked up (bonded) on chain A.
Proof Relay
Then, a proof that the 10 Atoms are bonded is relayed from chain A to chain B.
Validation
The proof is verified on chain B against chain A’s header and, if it is valid, then 10 Atom-vouchers are created on chain B.
Note that the Atoms that have been created on chain B are not real Atoms, as Atoms only exist on chain A. They are a representation on B of Atoms from chain A, along with a proof that these Atoms are frozen on chain A.
A similar mechanism is used to unlock Atoms when they come back to their origin chain. For a more comprehensive description of the IBC protocol, you can look at this specification.
Designing the “Internet of Blockchains”
IBC is a protocol that allows two heterogeneous blockchains to transfer tokens to each other. From there, how do we create a network of blockchains?
One idea is to connect each blockchain in the network with every other via direct IBC connections. The main problem with this approach is that the number of connections in the network grows quadratically with the number of blockchains. If there are 100 blockchains in the network and each needs to maintain an IBC connection with every other, that is 4950 connections. This quickly gets out of hand.
To solve this, Cosmos proposes a modular architecture with two classes of blockchain: Hubs and Zones. Zones are regular heterogenous blockchains and Hubs are blockchains specifically designed to connect Zones together. When a Zone creates an IBC connection with a Hub, it can automatically access (i.e. send to and receive from) every other Zone that is connected to it. As a result, each Zone only needs to establish a limited number of connections with a restricted set of Hubs. Hubs also prevent double spending among Zones. This means that when a Zone receives a token from a Hub, it only needs to trust the origin Zone of this token and the Hub.
The first Hub to launch in the Cosmos Network will be the Cosmos Hub. The Cosmos Hub is a public Proof-of-Stake blockchain whose native staking token is called the Atom, and where transactions fees will be payable in multiple tokens.
Bridging non-Tendermint chains
So far, the architecture of Cosmos we have presented shows how Tendermint-based chains can interoperate. But Cosmos is not limited to Tendermint chains. In fact, any kind of blockchain can be connected to Cosmos.
We have two cases to distinguish: fast-finality chains and probabilistic-finality chains.
FAST-FINALITY CHAINS
Blockchains that use any fast-finality consensus algorithms can connect with Cosmos by adapting IBC. For example, if Ethereum were to switch to Casper FFG (Friendly Finality Gadget), a direct connection could be established between it and the Cosmos Ecosystem by adapting IBC to work with Casper.
PROBABILISTIC-FINALITY CHAINS
For blockchains that do not have fast-finality, like Proof-of-Work chains, things get a bit trickier. For these chains we use a special kind of proxy-chain called a Peg-Zone.
A Peg-Zone is a blockchain that tracks the state of another blockchain. The Peg-Zone itself has fast-finality and is therefore compatible with IBC. Its role is to establish finality for the blockchain it bridges. Let us look at the following example.
Example: Ethereum Peg-Zone
We want to bridge the Proof-of-Work Ethereum blockchain to make it possible to send tokens back and forth between Ethereum and Cosmos. Because Proof-of-Work Ethereum does not have fast-finality, we need to create a Peg-Zone to act as a bridge between the two.
First, the Peg-Zone needs to decide on a finality threshold for the origin chain. For example, it can consider that a given block of the origin’s chain is final when 100 blocks have been added after it.
Second, a contract is deployed on the main Ethereum blockchain. When users want to send tokens from Ethereum to Cosmos, they start by sending tokens to this contract. Then the contract freezes the assets and after 100 blocks, a representation of these assets is released on the Peg-Zone. A similar mechanism is used to send assets back to the Ethereum chain.
Interestingly enough, the Peg-Zone also allows users to send any token that lives on Cosmos to the Ethereum chain (the Cosmos tokens would be represented as ERC20 on the Ethereum chain). The Tendermint team is currently working on a Peg-Zone implementation for the Ethereum chain called Peggy.
Peg-Zones will need to be customized for the particular chain they bridge. Building an Ethereum Peg-Zone is relatively simple because Ethereum is account-based and has smart-contracts. However, building a Bitcoin Peg-Zone is a bit more challenging. If you want to learn more about Peg-Zones you can take a look at this spec.
Solving Scalability
Now that we can easily create and connect blockchains there is one final issue to tackle: Scalability. Cosmos leverages two types of scalability:
- Vertical scalability: This encompasses the methods for scaling the blockchain itself. By moving away from Proof-of-Work and optimizing its components, Tendermint Core can reach thousands of transactions per-second. The bottleneck factor is the application itself. For example, an application like a Virtual Machine (e.g. the Ethereum Virtual Machine) will impose a much lower limit on the transaction throughput than an application where transaction types and state transition functions are directly embedded in it (e.g. a standard Cosmos SDK application). This is one of the reasons why application-specific blockchains make sense (read about more reasons here).
- Horizontal scalability: Even if the consensus engine and the application are highly optimized, at some point the transaction throughput of a single chain inevitably hits a wall it cannot surpass. That is the limit of vertical scaling. To go beyond it, the solution is to move to multi-chain architectures. The idea is to have multiple parallel chains running the same application and operated by a common validator set, making blockchains theoretically infinitely scalable. Details about horizontal scalability are fairly complex and out-of-scope for this intro.
Cosmos will offer very good vertical scalability at launch, which will be a major improvement over current blockchain solutions in and of itself. Later, after the completion of the IBC module, horizontal scalability solutions will be implemented.
Team
Cosmos Network team consists of members of The Interchain Foundation (ICF) and the Tendermint Inc team.
The Interchain Foundation (ICF) is a Swiss non-profit foundation that was formed to support the development of Cosmos and the ecosystem that will contribute to the Cosmos Network. The ICF is accepting applications for grants.
All in Bits Inc (dba Tendermint Inc) is a software development company contracted by the ICF to develop the Cosmos Network.
Tendermint team
Tendermint team consists of world class software developers, researchers and network operators.
Jae Kwon — CEO & Founder.
Jae is the President at Interchain Foundation and the CEO of Tendermint, which he founded to save the world from needlessly wasting electricity to secure distributed ledgers. Along the way he realized that using quorums and cryptography instead of energy and hashing affords many advantages such as speed and scalability.
Education: Cornell University. BS. Field Of Study — Computer Science (2001–2005). Activities and Societies: Robocup — AI robots playing soccer
Ethan Buchman — Cofounder.
Ethan sees consensus algorithms as a 21st century means for promoting social cohesion. He is driven to empower humans with new ways to coordinate and reach agreement at scale.
Education: University of Guelph. Bachelor of Science. Field Of Study — Biophysics (2010–2013).
Peng Zhong — Chief Design Officer.
Peng aims to dramatically increase blockchain adoption through better usability design. He hopes to turn cutting-edge technology into mundane things that everyone can use.
Education: Humboldt State University (2006–2007). MATH 110. Calculus II. MATH 210. Calculus III.
Anton Kaliaev — Software Engineer.
Anton is a software engineer with more than 6 years of experience. He has worked in web, video processing, and telecom industries and has extensive knowledge, which he hopes will help him make Tendermint better.
Education: Ulyanovsk State Technical University. Specialist. Field Of Study — Computer Science. Grade 4.87 (2005–2010). Developed translator of Java source code into C# and vice versa.
Jim Yang — Strategy.
Jim Yang co-founded Identyx, where he served as CEO until its acquisition by Red Hat. Identyx developed an open source enterprise identity management software. Previously was the founder and CEO of ChatX, mobile messaging studio.
Education: The University of Texas at Austin. BS. Field Of Study — Computer Science.
Christine Chiang — Community Architect.
Christine is the content creator and communications lead for the Cosmos project, the Internet of Blockchains.
Education: University of California, San Diego. BS. Field Of Study — Management Science (2007–2011). Activities and Societies: Dir. Communications — Undergraduate Investment Society, Sixth College Technology Committee, Clinton Global Initiative University, Moneythink.
Hugh Rooney — Advisor.
Hugh has extensive experience in the application of leading-edge technologies to a wide range of business problems in both the public and private sectors. He was also one of the founders of Infobright, a “Big Data Analytics” company.
Education: Ivey Business School at Western University. Master of Business Administration — MBA (1981–1983). Western University. Bachelor’s degree. Field Of Study — Computer Science and Philosophy.
Greg Szabo — VP of SRE.
Greg is an IT enthusiast with more than 10 years of experience in building enterprise infrastructures. His primary goal is to create a world, where computers are used transparently and people are focusing on their goals instead of their tools.
Rigel Rozanski — Software Engineer.
Rigel is inspired by blockchain as a means of reducing entropy as the interactions of technology grow to manifold complexities. His interests lie in the crossroads between blockchain and the geospatial realm.
Education: Budapesti Mûszaki és Gazdaságtudományi Egyetem. Master’s degree. Field Of Study — Computer Systems Networking and Telecommunications (2002–2009).
Gautier Marin — Developer Relations Engineer.
Education: Telecom ParisTech (2014–2017). École Polytechnique. Master of Research. Field Of Study — Innovation Management (2016–2017).
Experience: Software Engineer at Ledgys (2016–2017).
Fabian Weber — Software Engineer.
Education: Humboldt University of Berlin (2008–2015).
Experience: Zalando SE as Frontend Developer (2015–2017). Development of internal tools in the buying process for the wholesale product.
Shelley Chang — Operations Manager.
Shelley is a tech enthusiast participating in hackathons, and has presented at Tech Crunch Disrupt. Her operations experience spans across SASS, AI and cryptocurrency. At Tendermint, she is the copilot to the CEO, and a generalist assisting in various functions of the company.
Jessy Irwin — Head of Security.
Jessy is Head of Security at Tendermint, where she excels at translating complex cybersecurity problems into relatable terms, and is responsible for developing, maintaining and delivering comprehensive security strategy that supports and enables the needs of her organization and its people.
Education: Virginia Polytechnic Institute and State University.
Federico Kunze — Software Developer.
Federico Kunze is an alumni from Blockchain at Berkeley (B@B) where in 2017 he joined an external consulting team working to build a decentralized license marketplace for Qualcomm and created content for the Executive Education program for Fortune 500 companies. He’s now also advising the Chilean ministry of economy in public sector blockchain use cases and co-founded the Chilean Blockchain Industry Association (a.k.a CryptoChile).
Christopher Goes — Software Developer.
Christopher Goes hopes that distributed ledgers will shift the economics of network effects in favor of aligned incentives and positive-sum games. He hopes to help Cosmos make this happen by developing robust software infrastructure layers and reducing barriers to entry. Christopher previously cofounded Stash.ai and led CUAUV.
Zaki Manian — Director of Tendermint Labs.
Jin Kwon hopes to bring value to the blockchain space through his interdisciplinary background in engineering, sales, marketing and finance.
Education: University of Pennsylvania. BA. Field Of Study — History and Sociology of Science (2000–2005).
Jin Kwon — Chief of Staff & Partnerships.
Jin Kwon hopes to bring value to the blockchain space through his interdisciplinary background in engineering, sales, marketing and finance.
Education: The University of Chicago Booth School of Business. Master of Business Administration (MBA). Field Of Study — Finance, Accounting, Managerial and Organizational Behavior (2013–2015). University of California, Berkeley. Master of Science (MS). Field Of Study — Computer Science (2008–2010).
Karoly Szabo — Senior Software Engineer.
Karoly Szabo started working in 2007 initially as freelance, then full time. He moved from Backend to Frontend and DevOps. He loves to learn new things and has been studying Machine Learning since the last 5 years.
Education: Università degli Studi di Padova. Field Of Study — Computer Engineering. Master degree (2011–2014). University of Aberdeen. Bachelor’s degree. Field Of Study — Computer Science (2012–2013). Technische Universität München. Field Of Study — Computer and Information Systems Security/Information Assurance (2012–2012).
Sunny Aggarwal — Research Scientist.
Zarko Milosevic — Research Scientist.
Billy Rennekamp — Developer Relations Engineer.
Jordan Bibla — User Experience Designer.
Arianne Flemming — VP of Finance.
Juwoon Yun — Software Developer.
Anna Harbaum — General Manager (GmBH).
Ismail Khoffi — Software Engineer.
Michelle Leech — PR & Corporate Comms.
Jack Zampolin — Product Manager.
Aleksandr Bezobchuk — Senior Software Engineer.
Khayeni Sanders — Visual Design Lead.
Alessio Treglia — Software Developer.
Mircea Colonescu — Senior DevOps Engineer.
Cheryl Sew Hoy — Chief Marketing Officer.
Melanie Robb — VP of People & Talent.
And others.
Partnerships
Full list of 80+ projects in Cosmos ecosystem.
Projects worth mention:
- Binance
- OmiseGo
- FOAM
- Oracle International Corporation
- IRIS
- DATA Chain
- Loom Network
- ThetaToken
Use case
DISTRIBUTED EXCHANGE
In the same way that Bitcoin is more secure by being a distributed, mass-replicated ledger, we can make exchanges less vulnerable to external and internal hacks by running it on the blockchain. We call this a distributed exchange.
What the cryptocurrency community calls a decentralized exchange today are based on something called “atomic cross-chain” (AXC) transactions. With an AXC transaction, two users on two different chains can make two transfer transactions that are committed together on both ledgers, or none at all (i.e. atomically). For example, two users can trade bitcoins for ether (or any two tokens on two different ledgers) using AXC transactions, even though Bitcoin and Ethereum are not connected to each other. The benefit of running an exchange on AXC transactions is that neither users need to trust each other or the trade-matching service. The downside is that both parties need to be online for the trade to occur.
Another type of decentralized exchange is a mass-replicated distributed exchange that runs on its own blockchain. Users on this kind of exchange can submit a limit order and turn their computer off, and the trade can execute without the user being online. The blockchain matches and completes the trade on behalf of the trader.
A centralized exchange can create a deep orderbook of limit orders and thereby attract more traders. Liquidity begets more liquidity in the exchange world, and so there is a strong network effect (or at least a winner-take-most effect) in the exchange business. Given such strong network effects, it is unlikely for AXC-based decentralized exchanges to win volume over the centralized exchanges. For a decentralized exchange to compete with a centralized exchange, it would need to support deep orderbooks with limit orders. Only a distributed exchange on a blockchain can provide that.
Tendermint provides additional benefits of faster transaction commits. By prioritizing fast finality without sacrificing consistency, zones in Cosmos can finalize transactions fast — for both exchange order transactions as well as IBC token transfers to and from other zones.
Given the state of cryptocurrency exchanges today, a great application for Cosmos is the distributed exchange (aka the Cosmos DEX). The transaction throughput capacity as well as commit latency can be comparable to those of centralized exchanges. Traders can submit limit orders that can be executed without both parties having to be online. And with Tendermint, the Cosmos hub, and IBC, traders can move funds in and out of the exchange to and from other zones with speed.
BRIDGING TO OTHER CRYPTOCURRENCIES
A privileged zone can act as the source of a bridged token of another cryptocurrency. A bridge is similar to the relationship between a Cosmos hub and zone; both must keep up with the latest blocks of the other in order to verify proofs that tokens have moved from one to the other. A “bridge-zone” on the Cosmos network keeps up with the Hub as well as the other cryptocurrency. The indirection through the bridge-zone allows the logic of the Hub to remain simple and agnostic to other blockchain consensus strategies such as Bitcoin’s proof-of-work mining.
Sending Tokens to the Cosmos Hub
Each bridge-zone validator would run a Tendermint-powered blockchain with a special ABCI bridge-app, but also a full-node of the “origin” blockchain.
When new blocks are mined on the origin, the bridge-zone validators will come to agreement on committed blocks by signing and sharing their respective local view of the origin’s blockchain tip. When a bridge-zone receives payment on the origin (and sufficient confirmations were agreed to have been seen in the case of a PoW chain such as Ethereum or Bitcoin), a corresponding account is created on the bridge-zone with that balance.
In the case of Ethereum, the bridge-zone can share the same validator-set as the Cosmos Hub. On the Ethereum side (the origin), a bridge-contract would allow ether holders to send ether to the bridge-zone by sending it to the bridge-contract on Ethereum. Once ether is received by the bridge-contract, the ether cannot be withdrawn unless an appropriate IBC packet is received by the bridge-contract from the bridge-zone. The bridge-contract tracks the validator-set of the bridge-zone, which may be identical to the Cosmos Hub’s validator-set.
In the case of Bitcoin, the concept is similar except that instead of a single bridge-contract, each UTXO would be controlled by a threshold multisignature P2SH pubscript. Due to the limitations of the P2SH system, the signers cannot be identical to the Cosmos Hub validator-set.
Withdrawing Tokens from Cosmos Hub
Ether on the bridge-zone (“bridged-ether”) can be transferred to and from the Hub, and later be destroyed with a transaction that sends it to a particular withdrawal address on Ethereum. An IBC packet proving that the transaction occurred on the bridge-zone can be posted to the Ethereum bridge-contract to allow the ether to be withdrawn.
In the case of Bitcoin, the restricted scripting system makes it difficult to mirror the IBC coin-transfer mechanism. Each UTXO has its own independent pubscript, so every UTXO must be migrated to a new UTXO when there is a change in the set of Bitcoin escrow signers. One solution is to compress and decompress the UTXO-set as necessary to keep the total number of UTXOs down.
Total Accountability of Bridge Zones
The risk of such a bridgeging contract is a rogue validator set. ≥⅓ Byzantine voting power could cause a fork, withdrawing ether from the bridge-contract on Ethereum while keeping the bridged-ether on the bridge-zone. Worse, >⅔ Byzantine voting power can steal ether outright from those who sent it to the bridge-contract by deviating from the original bridgeging logic of the bridge-zone.
It is possible to address these issues by designing the bridge to be totally accountable. For example, all IBC packets, from the hub and the origin, might require acknowledgement by the bridge-zone in such a way that all state transitions of the bridge-zone can be efficiently challenged and verified by either the hub or the origin’s bridge-contract. The Hub and the origin should allow the bridge-zone validators to post collateral, and token transfers out of the bridge-contract should be delayed (and collateral unbonding period sufficiently long) to allow for any challenges to be made by independent auditors. We leave the design of the specification and implementation of this system open as a future Cosmos improvement proposal, to be passed by the Cosmos Hub’s governance system.
ETHEREUM SCALING
Solving the scaling problem is an open issue for Ethereum. Currently, Ethereum nodes process every single transaction and also store all the states. Since Tendermint can commit blocks much faster than Ethereum’s proof-of-work, EVM zones powered by Tendermint consensus and operating on bridged-ether can provide higher performance to Ethereum blockchains. Additionally, though the Cosmos Hub and IBC packet mechanics does not allow for arbitrary contract logic execution per se, it can be used to coordinate token movements between Ethereum contracts running on different zones, providing a foundation for token-centric Ethereum scaling via sharding.
MULTI-APPLICATION INTEGRATION
Cosmos zones run arbitrary application logic, which is defined at the beginning of the zone’s life and can potentially be updated over time by governance. Such flexibility allows Cosmos zones to act as bridges to other cryptocurrencies such as Ethereum or Bitcoin, and it also permits derivatives of those blockchains, utilizing the same codebase but with a different validator set and initial distribution. This allows many existing cryptocurrency frameworks, such as those of Ethereum, Zerocash, Bitcoin, CryptoNote and so on, to be used with Tendermint Core, which is a higher performance consensus engine, on a common network, opening tremendous opportunity for interoperability across platforms. Furthermore, as a multi-asset blockchain, a single transaction may contain multiple inputs and outputs, where each input can be any token type, enabling Cosmos to serve directly as a platform for decentralized exchange, though orders are assumed to be matched via other platforms. Alternatively, a zone can serve as a distributed fault-tolerant exchange (with orderbooks), which can be a strict improvement over existing centralized cryptocurrency exchanges which tend to get hacked over time.
Zones can also serve as blockchain-backed versions of enterprise and government systems, where pieces of a particular service that are traditionally run by an organization or group of organizations are instead run as a ABCI application on a certain zone, which allows it to inherit the security and interoperability of the public Cosmos network without sacrificing control over the underlying service. Thus, Cosmos may offer the best of both worlds for organizations looking to utilize blockchain technology but who are wary of relinquishing control completely to a distributed third party.
NETWORK PARTITION MITIGATION
Some claim that a major problem with consistency-favouring consensus algorithms like Tendermint is that any network partition which causes there to be no single partition with >⅔ voting power (e.g. ≥⅓ going offline) will halt consensus altogether. The Cosmos architecture can help mitigate this problem by using a global hub with regional autonomous zones, where voting power for each zone are distributed based on a common geographic region. For instance, a common paradigm may be for individual cities, or regions, to operate their own zones while sharing a common hub (e.g. the Cosmos Hub), enabling municipal activity to persist in the event that the hub halts due to a temporary network partition. Note that this allows real geological, political, and network-topological features to be considered in designing robust federated fault-tolerant systems.
FEDERATED NAME RESOLUTION SYSTEM
NameCoin was one of the first blockchains to attempt to solve the name-resolution problem by adapting the Bitcoin blockchain. Unfortunately there have been several issues with this approach.
With Namecoin, we can verify that, for example, @satoshi was registered with a particular public key at some point in the past, but we wouldn’t know whether the public key had since been updated recently unless we download all the blocks since the last update of that name. This is due to the limitation of Bitcoin’s UTXO transaction Merkle-ization model, where only the transactions (but not mutable application state) are Merkle-ized into the block-hash. This lets us prove existence, but not the non-existence of later updates to a name. Thus, we can’t know for certain the most recent value of a name without trusting a full node, or incurring significant costs in bandwidth by downloading the whole blockchain.
Even if a Merkle-ized search tree were implemented in NameCoin, its dependency on proof-of-work makes light client verification problematic. Light clients must download a complete copy of the headers for all blocks in the entire blockchain (or at least all the headers since the last update to a name). This means that the bandwidth requirements scale linearly with the amount of time. In addition, name-changes on a proof-of-work blockchain requires waiting for additional proof-of-work confirmation blocks, which can take up to an hour on Bitcoin.
With Tendermint, all we need is the most recent block-hash signed by a quorum of validators (by voting power), and a Merkle proof to the current value associated with the name. This makes it possible to have a succinct, quick, and secure light-client verification of name values.
In Cosmos, we can take this concept and extend it further. Each name-registration zone in Cosmos can have an associated top-level-domain (TLD) name such as “.com” or “.org”, and each name-registration zone can have its own governance and registration rules.
Social metrics
See also Cosmos forum and Matrix/Riot Chat.
There are also Community-managed Channels. These channels are managed entirely by members of the Cosmos community and do not represent official Cosmos or ICF announcements.
Markets and volume
TBA
TA
TBA
Competitors
Aion, Ark, ICON, Wanchain, Cardano, Fusion, Lamden, Komodo, Blocknet, Polkadot, Oneledger, Block Collider — all of this projects are competitors of Cosmos Network which have been trying to solve the problem with interoperability for quite some time.
On the current market, there are 4 methods of achieving interoperability which can be seen on the table below.
Aion, Ark, ICON, Wanchain, Cardano, Fusion, Lamden, Komodo, Blocknet belong to Notary schemes type, Polkadot to Relaychains/Parachains, Oneledger to Cross-chain hash locking and Block Collider to Multi-chain weaving.
It is hard to say which of these projects will be more successful, since it highly depends on adoption, network effect and delivery of a working product.
Cosmos has Binance in its ecosystem which will help them with adoption, network effect, since right now Binance is one of the best hype generators on the market.
Token Mechanics
THE ATOM TOKEN
While the Cosmos Hub is a multi-asset distributed ledger, there is a special native token called the atom. Atoms are the only staking token of the Cosmos Hub. Atoms are a license for the holder to vote, validate, or delegate to other validators. Like Ethereum’s ether, atoms can also be used to pay for transaction fees to mitigate spam. Additional inflationary atoms and block transaction fees are rewarded to validators and delegators who delegate to validators.
The BurnAtomTx transaction can be used to recover any proportionate amount of tokens from the reserve pool.
LIMITATIONS ON THE NUMBER OF VALIDATORS
Unlike Bitcoin or other proof-of-work blockchains, a Tendermint blockchain gets slower with more validators due to the increased communication complexity. Fortunately, we can support enough validators to make for a robust globally distributed blockchain with very fast transaction confirmation times, and, as bandwidth, storage, and parallel compute capacity increases, we will be able to support more validators in the future.
On genesis day, the maximum number of validators will be set to 100, and this number will increase at a rate of 13% for 10 years, and settle at 300 validators.
Year 0: 100
Year 1: 113
Year 2: 127
Year 3: 144
Year 4: 163
Year 5: 184
Year 6: 208
Year 7: 235
Year 8: 265
Year 9: 300
Year 10: 300
BECOMING A VALIDATOR AFTER GENESIS DAY
Atom holders who are not already can become validators by signing and submitting a BondTx transaction. The amount of atoms provided as collateral must be nonzero. Anyone can become a validator at any time, except when the size of the current validator set is greater than the maximum number of validators allowed. In that case, the transaction is only valid if the amount of atoms is greater than the amount of effective atoms held by the smallest validator, where effective atoms include delegated atoms. When a new validator replaces an existing validator in such a way, the existing validator becomes inactive and all the atoms and delegated atoms enter the unbonding state.
PENALTIES FOR VALIDATORS
There must be some penalty imposed on the validators for any intentional or unintentional deviation from the sanctioned protocol. Some evidence is immediately admissible, such as a double-sign at the same height and round, or a violation of “prevote-the-lock” (a rule of the Tendermint consensus protocol). Such evidence will result in the validator losing its good standing and its bonded atoms as well its proportionate share of tokens in the reserve pool — collectively called its “stake” — will get slashed.
Sometimes, validators will not be available, either due to regional network disruptions, power failure, or other reasons. If, at any point in the past ValidatorTimeoutWindow blocks, a validator’s commit vote is not included in the blockchain more than ValidatorTimeoutMaxAbsent times, that validator will become inactive, and lose ValidatorTimeoutPenalty (DEFAULT 1%) of its stake.
Some “malicious” behavior does not produce obviously discernable evidence on the blockchain. In these cases, the validators can coordinate out of band to force the timeout of these malicious validators, if there is a supermajority consensus.
In situations where the Cosmos Hub halts due to a ≥⅓ coalition of voting power going offline, or in situations where a ≥⅓ coalition of voting power censor evidence of malicious behavior from entering the blockchain, the hub must recover with a hard-fork reorg-proposal. (Link to “Forks and Censorship Attacks”).
TRANSACTION FEES
Cosmos Hub validators can accept any token type or combination of types as fees for processing a transaction. Each validator can subjectively set whatever exchange rate it wants, and choose whatever transactions it wants, as long as the BlockGasLimit is not exceeded. The collected fees, minus any taxes specified below, are redistributed to the bonded stakeholders in proportion to their bonded atoms, every ValidatorPayoutPeriod (DEFAULT 1 hour).
Of the collected transaction fees, ReserveTax (DEFAULT 2%) will go toward the reserve pool to increase the reserve pool and increase the security and value of the Cosmos network. These funds can also be distributed in accordance with the decisions made by the governance system.
Atom holders who delegate their voting power to other validators pay a commission to the delegated validator. The commission can be set by each validator.
INCENTIVIZING HACKERS
The security of the Cosmos Hub is a function of the security of the underlying validators and the choice of delegation by delegators. In order to encourage the discovery and early reporting of found vulnerabilities, the Cosmos Hub encourages hackers to publish successful exploits via a ReportHackTx transaction that says, “This validator got hacked. Please send bounty to this address”. Upon such an exploit, the validator and delegators will become inactive, HackPunishmentRatio (default 5%) of everyone’s atoms will get slashed, and HackRewardRatio (default 5%) of everyone’s atoms will get rewarded to the hacker’s bounty address. The validator must recover the remaining atoms by using their backup key.
In order to prevent this feature from being abused to transfer unvested atoms, the portion of vested vs unvested atoms of validators and delegators before and after the ReportHackTx will remain the same, and the hacker bounty will include some unvested atoms, if any.
GOVERNANCE SPECIFICATION
The Cosmos Hub is operated by a distributed organization that requires a well-defined governance mechanism in order to coordinate various changes to the blockchain, such as the variable parameters of the system, as well as software upgrades and constitutional amendments.
All validators are responsible for voting on all proposals. Failing to vote on a proposal in a timely manner will result in the validator being deactivated automatically for a period of time called the AbsenteeismPenaltyPeriod (DEFAULT 1 week).
Delegators automatically inherit the vote of the delegated validator. This vote may be overridden manually. Unbonded atoms get no vote.
Each proposal requires a deposit of MinimumProposalDeposit tokens, which may be a combination of one or more tokens including atoms. For each proposal, the voters may vote to take the deposit. If more than half of the voters choose to take the deposit (e.g. because the proposal was spam), the deposit goes to the reserve pool, except any atoms which are burned.
For each proposal, voters may vote with the following options:
- Yea
- YeaWithForce
- Nay
- NayWithForce
- Abstain
A strict majority of Yea or YeaWithForce votes (or Nay or NayWithForce votes) is required for the proposal to be decided as passed (or decided as failed), but 1/3+ can veto the majority decision by voting “with force”. When a strict majority is vetoed, everyone gets punished by losing VetoPenaltyFeeBlocks (DEFAULT 1 day’s worth of blocks) worth of fees (except taxes which will not be affected), and the party that vetoed the majority decision will be additionally punished by losing VetoPenaltyAtoms (DEFAULT 0.1%) of its atoms.
PARAMETER CHANGE PROPOSAL
Any of the parameters defined here can be changed with the passing of a ParameterChangeProposal.
BOUNTY PROPOSAL
Atoms can be inflated and reserve pool funds spent with the passing of a BountyProposal.
TEXT PROPOSAL
All other proposals, such as a proposal to upgrade the protocol, will be coordinated via the generic TextProposal.
Atoms have three use cases: as a spam-prevention mechanism, as staking tokens, and as a voting mechanism in governance.
As a spam prevention mechanism, Atoms are used to pay fees. The fee may be proportional to the amount of computation required by the transaction, similar to Ethereum’s concept of “gas”. Fee distribution is done in-protocol and a protocol specification is described here.
As staking tokens, Atoms can be “bonded” in order to earn block rewards. The economic security of the Cosmos Hub is a function of the amount of Atoms staked. The more Atoms that are collateralized, the more “skin” there is at stake and the higher the cost of attacking the network. Thus, the more Atoms there are bonded, the greater the economic security of the network.
Atom holders may govern the Cosmos Hub by voting on proposals with their staked Atoms.
Token Metrics
Fundraiser
The initial distribution of atom tokens and validators on Genesis will go to the donors of the Cosmos Fundraiser (75%), lead donors (5%), Cosmos Network Foundation (10%), and ALL IN BITS, Inc (10%). From genesis onward, 1/3 of the total amount of atoms will be rewarded to bonded validators and delegators every year. See the Cosmos Plan for additional details.
168,475,963 ATOM were sold during fundraiser, total supply at launch will be 230,000,000 ATOMs.
ICO price was $0,1 with 25% a discount of 25% for strategic funders implies an atom price of $0.075. A discount of 15% for Pre-Fundraisers implies an atom price of $0.085.
Testnets
The Cosmos network had a number of testnets and some of those had very interesting events which I would like to outline, especially since mainnet is so close and those events are recent.
- Aforementioned 73% voting power validator (see image below)
- Cartel created by validators rose from 28% to 53% voting power, it happened during GoS, and it is true that it happened naturally since requirements to be validators differed from real case, but still shows that network isn’t really secure from such type of attacks.
- When Bitfish cartel was found and couldn’t be dealt with onchain (since their voting power was already too big), decision was made to propose a community fork with genesis file excluding cartel validators. Sooo doing so they pretty much created cartel #2 which had off-line agreement to exclude some of validators from participating in GoS. Well, fighting fire with fire, I guess. (Bitfish answer to accusations)
- Last GoS 6 had Bitfish onboard as well, they controlled 54 out of 162, and to be honest that lets us speculate that some of the nodes were also controlled in batches. Btw 37 out of 162 nodes had 0 voting power.
Auto-redelegation tooling superiority
“So long, and thanks for all the fish” — Bitfish version, GoS 6
Summary
Team: Good team with tech background
Idea: one of the many projects tackling scalability/interoperability problem
Whitepaper: lacks some of the crucial info (e.g. token metrics, info about sentinel nodes, etc.)
Roadmap: shows no deadlines, concerns only mainnet
Cosmos Network is a very ambitious project, it aims to become an internet of blockchains and it is soon to enter mainnet phase, crucial part, since competition is fierce and early start means much in crypto, though Cosmos doesn’t look like a project that hurries to launch mainnet, as it repeatedly and patiently launches testnets, while fixing bugs, errors.
Cosmos has created a big ecosystem with a vast diversity of projects, some of which have already achieved great results in their respective fields. It will be very interesting to see what kind of role they will take up during mainnet, how fast they will integrate with Cosmos.
Testnets showed us that Cosmos network doesn’t have defensive mechanism against sybil attack against the registration of validators, hope that the team will pay close attention to that during mainnet.
There is not enough transparency in use of proceeds and some of the crucial token metrics such as slashing%, which can highly affect delegators and hence affect investors decision to join the network as stakers.
