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.
