.png)
This post is the first of a series that will introduce major Proof-of-Stake smart contract platforms. We will regularly add profiles to the “Proof-of-Stake Contenders” series covering the founding history, the team and basic components of the projects, including how their protocol is incorporating staking. The first contender will be the project that we at Chorus One have until now spent most of our time on: the Cosmos Network.
The main vision behind the Cosmos Network is that of an interoperable, scalable “internet of blockchains”. The project’s goal is to enable developers to easily spin up blockchains on a per-application basis, with components that can be switched out to fit the desired use case. To achieve this, the Cosmos Network is utilizing a modular design and a Hub and Spoke model, facilitated by a multitude of technologies and developer tools that enable communication between blockchains and pluggable features such as staking, slashing, governance, etc.
Before the Cosmos Network whitepaper was released in 2016, co-founders Jae Kwon and Ethan Buchman had already been actively working together on Tendermint, a BFT (Byzantine fault-tolerant) algorithm devised to achieve consensus in an adversarial distributed setting, which serves as the basis for the Cosmos Network. Jae Kwon is the author behind the 2014 Tendermint paper, which was one of the first papers that described a possible alternative to Proof-of-Work in public blockchains drawing on distributed system research. Ethan Buchman’s thesis from 2016 on Tendermint remains one of the best technical introductions to blockchains to this day. The two are the leading forces behind the company Tendermint, which is developing the Cosmos Network on behalf of the Interchain Foundation.
The Cosmos Network fundraiser took place on the 7th of April 2017 and was one of the most popular at the time. In the Cosmos fundraiser, participants contributed over $16m in around 30 minutes to receive 168,475,963 Atoms at network launch (at a rate of ~$0.10 per Atom). The rest of the Atom allocation (25%) are distributed to the Interchain Foundation (10%), All in Bits (aka Tendermint) (10%) and seed investors (5%) at launch. The fundraiser raised a record amount at the time, on par with the Ethereum fundraiser but completed in a much shorter time.
The project has been in development since and managed to gather an active community, especially around the staking and validation ecosystem, with over 250 entities registering for the final incentivized testnet (300,000 Atoms are going to be distributed) taking place in November 2018 before the mainnet launch that is scheduled to happen at the end of this year. The testnet dubbed Game of Stakes will test the security and performance of validator infrastructure by simulating and encouraging adversarial behavior between participating parties.
The Cosmos Network is made up of many components, many of which are modular to allow for high degrees of freedom for developers that want to use the Cosmos Network to host their decentralized application. There are two main technical components to the Cosmos Network, the consensus engine (Tendermint Core) and the application interface (ABCI). The Cosmos SDK is a toolkit written in Golang that developers can use to write applications using their own modules or the ones provided by the Cosmos team.
The heart of the Cosmos Network is the Cosmos Hub, which is going to be the first blockchain in the Cosmos Network. Zones connect to the Hub and are able to send transactions to each other through the Hub. Zones will host applications built on the SDK. An example could be a decentralized exchange (DEX) that runs on its own zone. The IBC protocol developed by the Tendermint team provides a standardized way for blockchains to communicate.
In the future there could also be other Hubs with their own Zones that connect to the Cosmos Hub. Zones can have their own set of rules, modules, and even validator sets. There are many concepts for zones in various stages of development, some of the most interesting ones include Ethermint and Ethereum or Bitcoin Peg Zones.
Ethermint is a fully Web3-compatible implementation of the EVM running on the Cosmos Network; it allows Ethereum applications to be ported over to Cosmos to benefit from higher throughput and instant finality. Peg Zones describe bridge blockchains that implement a way to transfer tokens from foreign blockchains into the Cosmos Network via a two-way peg. The Cosmos team has also come up with interesting ideas on how one could onboard the Ethereum community to the Cosmos Network, e.g. by issuing a token (Photon) that essentially mirrors balances of ether holders through a so-called hard spoon (you can learn more about this concept here).
The Cosmos Hub is a Proof-of-Stake blockchain that is secured by the native cryptocurrency of the Cosmos Network: Atoms. Atoms are bonded to (staked with) validators either by validators themselves or by other stakeholders (delegators). Delegators are able to delegate their stake with whichever validator(s) they wish to. If you want to learn more about validation and delegation in Proof-of-Stake, check out this blog post first.
To be able to achieve high performance, the Cosmos Network validator set is limited to 100 validators at launch. There are many cryptoeconomic mechanisms (incentives and penalties) in place to ensure that the protocol runs at it is supposed to, some of these include slashings and lockup periods. Slashing refers to destruction of locked up stake when undesired behavior is detected (through cryptographic evidence). These attributable actions include signing two different blocks at the same height (also called double-signing or equivocation) and being unavailable (offline) for an extended period of time. The lockup of three weeks (in Cosmos: bonding period) is required to prevent long range attacks.
The important thing to note is that in Cosmos, token holders delegating their stake to validators are held responsible for their validators’ actions. This means that they receive rewards in relation to the performance of their validator(s), but also face risks of slashings due to validator misbehavior. This is done to ensure that delegators do their due diligence and choose to delegate to trusted, non-malicious validators with a secure infrastructure setup.
For taking part in securing the blockchain ledger, the Cosmos Network compensates stakers (validators and delegators) with block rewards in the form of inflated Atom tokens and transactions fees paid by users of the network in whitelisted tokens of the Cosmos Network (in the beginning only Atoms, but overtime this may include whatever tokens validators are willing to accept). Returns from staking in Cosmos are based on a variety of factors. Some of these are related to the state of usage of the network and some to the performance of a validator.
The network will likely have negligible transactions fees due to its performance, especially in the bootstrapping phase. This means that rewards for staking will mostly depend on inflated Atoms. The annual inflation rate is targeted to be 7%, which will be reached if more than 66% of the total Atom supply have been staked for an extent period of time. If there are less than 66% of Atoms at stake, the inflation rate will gradually adjust and rise up to a ceiling of 20%.
The image below shows the range of possible annual yields in Atoms when delegating at an assumed 15% commission rate. The chart is cut off at a 20% of total Atom supply staking because at very low staking levels effective yields from staking reach extremely high rates of above 100%. Because of the dynamically adjusting inflation rate effective yields will gradually move towards the upper bound when below 66% of the supply are staking and towards the lower bound when above 66% of the supply are staking respectively.
This analysis shows that incentives in the Cosmos Network are designed to heavily encourage staking, as the Atom is mainly designed to be a staking token on which the security of the Cosmos Network depends.
Finally, Cosmos also features an on-chain governance mechanism that is going to ensure that protocol upgrades happen in a formalized manner. Atom holders will vote on governance proposals with a 1-token-1-vote system. Governance proposals can be submitted by anyone, proposals with a minimum amount of deposits behind them enter a voting period. Delegators will inherit the votes of their validators, but are also able to vote on governance proposals themselves by overriding their validators decision. If a proposal fails, the deposited tokens are lost. To learn more about the Cosmos governance process, check out the documentation here.
Due to its proximity to the Ethereum ecosystem, focus on decentralized applications, and due to Tendermint being one of the most advanced BFT algorithms in production, many projects are already building or consider to host their applications on the Cosmos Network once it goes live. A collection of candidates that have expressed an interest or are experimenting with the Cosmos SDK and Tendermint, including projects like OmiseGO, BigchainDB, FOAM and many others is available in this thread on the official Cosmos forum.
Cosmos is a visionary project with a sound design that pioneered many concepts which were adopted by other cryptocurrencies. Our team at Chorus One is extremely excited about the upcoming Game of Stakes testnet competition and to finally be able to demonstrate the robustness of our validator infrastructure in an adversarial setting. To stay up-to-date with our operations and the nearing launch of the Cosmos Network, visit our website or join the mailing list and other social channels linked below.
About Cosmos
Cosmos Network Website
Cosmos Blog
Cosmos Twitter
Whitepaper
Cosmos For Developers
Introduction
Cosmos Academy
Documentation
Github Cosmos SDK
Github Tendermint
More on Staking and Delegating
Chorus One Proof-of-Stake Blog Posts
Cosmos Delegator FAQ
[Technical] Introduction to the Proof-of-Stake Security Model
[Technical] PoS FAQ Ethereum
About Chorus One
Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Medium: https://medium.com/chorus-one
Slack: https://chorus.one/slack
Telegram: https://chorus.one/telegram
Originally published at blog.chorus.one on October 26, 2018. Featured image by Richard Lee taken from Unsplash.
Proof-of-Stake (PoS) is still a foreign concept to many, even within the blockchain space. Yet we see most next generation protocols adopting PoS approaches and a large ecosystem will form around the alternative to Proof-of-Work (PoW). Similar to how PoW gave rise to a multi-billion dollar industry centered around mining (ASIC producers, mining farms and pools, etc.) there is an opportunity for new types of network maintainers emerging.
To reason about how this market may evolve, we need to take a step back to understand Proof-of-Stake, its main actors, their incentives, as well as differences in PoS implementations. This post is the first of an ongoing series that will try to do just that by providing an analysis of the PoS ecosystem and how we at Chorus One have been thinking about this space while building out own staking operations over the past few months.
The first part of this series will provide a basic introduction to PoS and the concepts of validation and delegation. As some readers might know, I have already written about the different types of staking. The “Proof-of-Stake Ecosystem” series will focus on pure PoS implementations, meaning those in which the consensus process is directly influenced by the stake. But what does that mean in practice?
If we look at PoS from a high level the concept is quite clear; the term refers to a system where value at stake is the main determinant of which blocks are added to the blockchain. Participants in a Proof-of-Stake network essentially vote with their money on blocks of transactions that they deem valid, get rewarded if the majority of the network agrees and risk losing their stake (deposited tokens) if they try to cheat, e.g. by voting on two different blocks of transactions at the same time.
In PoS money is power; instead of requiring participants securing the network to spend electricity (PoW), PoS requires participants to acquire and utilize the network tokens themselves as security deposits to align them with the networks’ interests.
Staking in a PoS blockchain refers to depositing tokens in a smart contract to register the intent to take part in maintaining the blockchain ledger. Once these tokens (the stake) are registered in the network, the staking party is required to run node infrastructure that will participate in the consensus process by receiving, signing and sending messages (about blocks of transactions) to other peers in the network. The combination of stake and node infrastructure is commonly called a validator. The amount of stake registered in this way determines the influence in the consensus process and the rewards a validator receives for the work it performed. The graphic below illustrates this process that is often referred to as validation.
If the story ended here, to participate in Proof-of-Stake one would need to a) own the staking tokens and b) be able to run the infrastructure required to take part in validating the blockchain.
But then what would happen with token holders that want to stake their tokens to receive rewards but cannot, or do not want to operate the required validation infrastructure themselves? It turns out that the developers of most PoS protocols have thought about this case and figured out ways to enable token holders to stake their tokens with a validator that they do not run themselves, without requiring them to actually send the tokens to the validator, using a process that is commonly called delegation.
Delegating your tokens means letting them count towards the stake of a validator in return for a share of the reward received. In practice, a delegator deposits tokens in a smart contract specifying the validator whose influence in the network he wants to increase. As a result, the rewards earned in the validation process increase, but instead of only the validator receiving compensation, the rewards are automatically split between the validator and the delegator depending on how the delegation smart contract specifies it, usually by applying a simple commission rate as pictured below.
It’s important to note that this process is a) non-custodial, i.e. a validator can never access token holders staked cryptoassets, b) capable of being reproduced on any smart contract platform, and c) expandable in many ways, the example above only illustrating the idea behind the concept of delegation.
Point b) and c) become especially apparent when one looks at how PoS and delegation mechanisms are currently designed in protocols such as Tezos, Cosmos, Ethereum (developed by third parties, e.g. Rocket Pool), Cardano, etc. There are massive differences in how delegation is implemented in these protocols, especially with regards to payout distribution and the treatment of parties that delegated their tokens to malicious validators, I will touch on some of these differences in the final part of this series.
The next post of this series will be about incentives and disincentives in the Proof-of-Stake ecosystem. It will try to lay out which factors drive the decision to delegate tokens instead of operating validator nodes yourself, or even starting your own delegation operation. To be the first to hear about new posts, sign up for our email list, follow the Chorus One Twitter account, or join our other social channels.
About Chorus One
Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Slack: https://chorus.one/slack
Telegram: https://chorus.one/telegram
Originally published at blog.chorus.one on October 19, 2018.
It has been 6 years since the idea of Proof-of-Stake (PoS) was first proposed by the Peercoin project. An eternity in blockchain time. Yet large projects like Ethereum and Cosmos are taking years to launch their own PoS-based chains, with timelines delaying over and over.
People understandably wonder: why is it so hard for these experts to implement PoS when there already seem to be PoS networks running, like those based on Delegated Proof-of-Stake (DPoS)? Adding to the confusion is that staking is a loosely defined term that comes in many, rapidly multiplying, forms.
In the following post, I will try to clear up some of the confusion around staking by creating a framework for classification and discussing how delegation works in “pure” PoS implementations.
To start off, it is important to note that staking can refer to many things and the only commonality between those is that tokens are used for some purpose without actually spending them. The main difference in how staking works among projects lies in the influence that staked tokens have on the consensus process. Put differently: How do staked tokens influence who gets to propose blocks and how those blocks are verified?
In many projects staking doesn’t influence the consensus process at all and staking is merely used for other network functions. This can mean that staked tokens serve purposes such as minting secondary fee tokens (e.g. GNO/OWL and SPANK/BOOTY) or that the stake is used to guarantee the correctness of outcomes (challenge protocols) or quality of entries to a curated list (TCRs). An example of such a form of staking is FOAM’s Proof-of-Location protocol. Masternode projects like Dash also fall into this category, as they utilize Proof-of-Work (PoW) for ordering and verifying transactions on their blockchains and staking (obtaining a masternode) for relaying special transactions and network governance. An important consideration here is that parties staking their tokens in these protocols are rewarded with tokens (either native as in the DASH case or secondary as in the OWL/BOOTY case).
There are also many decentralized networks where tokens determine governance decisions (e.g. MKR, 0x). The difference in those is that tokens aren’t locked up and participants don’t stand to earn income simply by participating in governance.
This also brings us to DPoS. In networks using DPoS token holders vote for block producers and the amount of stake that each candidate gets decides on who gets to participate in the consensus and governance process. One could argue that DPoS gives token holders the ability to participate in a governance decision: Who are the parties that are going to propose and verify blocks and govern our decentralized network? Staked tokens in a DPoS implementation only indirectly influence the consensus process. Block producers that are voted into the (limited) validator set all have the same rights and power and traditional, well-understood BFT algorithms can be used to come to consensus between them.
This is exactly where the difference of DPoS and “pure” PoS systems lies. In PoS networks, the stake directly influences the consensus outcome. The stake a validator controls is the deciding factor of how much power he holds in the network. Who gets to propose a block is decided based on stake and blocks are only verified once a certain threshold (usually two thirds) of staked tokens signed off on them.
Finally, hybrid decentralized network are the ones that use a combination of PoW and PoS to come to consensus about the state of their blockchain. This usually means that PoW is used to order transactions and propose blocks and PoS is added as a second layer of protection that is used to finalized blocks. The addition of PoS decreases the probability of a 51% attack and thus can be used to lower PoW mining rewards. Projects belonging to this basket include Decred (DCR) and Ethereum’s deprecated Casper FFG effort.
With this basic framework in mind, it should become easier to understand that a pure PoS implementation results in an order of magnitude higher complexity compared to DPoS. As an example, hard problems such as how (fair) leader election works with uneven and constantly changing power distributions now need to be solved.
Adding to the confusion is the concept of delegation that is incorporated in the DPoS (Delegated Proof-of-Stake) term. Many PoS protocols also allow the delegation of stake leading less well-versed observers to believe that these belong to the DPoS group.
Stake delegation will come to exist in some form in any successful PoS system that has smart contract support, since such a feature can be implemented with the help of smart contracts. The term merely describes the ability to participate in consensus and receive rewards for it without running the necessary node infrastructure or owning enough tokens to be able to do so.
The difference between PoS projects with regards to delegation mainly lies in the core developers choice to natively incorporate such a feature. Other important factors in this context are the existence of slashing and how the size of the validator set is limited.
Of the four major PoS implementations in the comparison above, only Ethereum relies on third party delegation smart contracts (e.g. by Rocket Pool). All others are implementing a native stake delegation protocol.
PoS implementations need to limit validator sets to some degree to ensure performant consensus rounds. Cosmos and Cardano opt for a fixed number of participants (both of them currently set this number to around 100, with planned upscaling in the future), while others such as Tezos and Ethereum require a minimal deposit to participate (in Tezos currently 10,000 XTZ (aimed to be decreased in the future) and in Ethereum expected to be 32 ETH).
Another factor that will influence how token holders will participate in PoS staking lies in whether or how the protocol incorporates slashing, the possibility of stake destruction for not following protocol rules. Of the ones listed, only Cardano won’t feature a slashing mechanism. In Cosmos and Tezos the difference lies in whether both delegators and validators or only validators get slashed. In Tezos only validators (referred to as bakers) post a security bond which is subject to slashing, while delegators aren’t at risk in this regard. Delegators in Tezos only need to make sure that their baker keeps his security bond above the required threshold and that he distributes payouts correctly. In Ethereum slashing will be part of the protocol and most likely affect both validators and delegators. Though smart contracts will allow different approaches to risk sharing. For instance, a Ethereum staking pool could offer a high-risk/high-return option and a low-risk/low-return option and preferentially slash users in the first bucket if something goes wrong. In Cosmos, slashing will apply proportionally to both validators and delegators.
All of the stated differences are based on choices project teams are making when facing tradeoffs inherent to PoS and blockchain design and all of these choices will result in different staking ecosystems. We at Chorus One do expect that pure PoS networks will innovate more rapidly and ultimately lead to much more robust and decentralized networks. For this reason, we are focusing most of our effort in this area. We hope to contribute to the evolution of PoS by supporting future stakers with our infrastructure (e.g. in the form of validator nodes) and by helping them to navigate this highly complex field.
If you are interested in learning more about the staking ecosystem please also take a look at the Staking Economy newsletter I edit and subscribe to it to receive the most recent update every two weeks via email.
Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Slack: https://chorus.one/slack
Telegram: https://chorus.one/telegram
Originally published at blog.chorus.one on October 3, 2018. Featured image by Rosie Kerr taken from Unsplash.
.png)
