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)
