This is the second part of a 3-piece blog series on the key ideas behind the Cosmos Network.
The previous part covered the basic ideas behind early Tendermint, an approach to building a cryptocurrency without Proof of Work mining. Early Tendermint merged together a consensus algorithm based on Practical Byzantine Fault Tolerance (PBFT) with the concept of security bonds, in order to enable construction a permissionless cryptocurrency with low operating costs. These ideas were in place by the end of 2014, and early technical work on Tendermint had begun.
The logical next step would have been to conduct an ICO, and attempt to launch a currency based on the Tendermint design. Ethereum trod that path in 2014, so a precedent for that path existed. This was a fork in the road the Tendermint team did not take! It’s journey over the next two years was much richer, and the vision evolved alongside major developments in the blockchain industry. This article tells that story, and will familiarize the reader with the concept of separating out consensus and application logic, leading to application-specific blockchains.
Reading this article will immerse you into the novel possibilities of application-specific chains. The view at the end of the road is spectacular; join us on the journey!
2015 was a unique year — this was the depth of the bear market in cryptocurrency; bringing deep skepticism about the value proposition of cryptocurrency. A few, hitherto fringe, ideas came into prominence. Two of them — decentralized applications and Bitcoin sidechains — will be critical to the Cosmos vision. But we’ll postpone the ripple effects of Bitcoin sidechains to the next article in the series.
The first is the wave of decentralized applications (DApps). Inventors had been adding new applications to Bitcoin — futures contracts, gambling contracts and proof of existence applications for a while already. The Ethereum whitepaper and vision burst onto the scene, popularized the concept of a DApp, and the implementation of Ethereum as a platform for hosting DApps. A DApp can be imagined as open data and code, that lives on a decentralized network (a blockchain or a BitTorrent like network) beyond a corporation’s ownership and delivers some utility to its users. A practical example is the Ethereum Name Service (ENS), which is a decentralized registry of human meaningful names (like meher.eth) that can be owned by Ethereum accounts. A hyperbolic example, which we simply do not have the capacity to implement today, is decentralized Uber — an application with the functionality of Uber, but with all of its data, processing logic and user accounts operating on a blockchain network.
Adherents of the decentralized applications vision were making a radical leap — they were casting away new monetary instruments, like the currency bitcoin, as the centerpiece for leveraging blockchain technology and put applications — exchanges, domain names, social media, prediction markets etc. — as the theater of operation for blockchains. The launch of Ethereum in July 2015 was a seminal event, since Ethereum actually delivered the ability to build decentralized applications like ENS, albeit with a lot of constraints. The constraints were that all of the application data needed to be public, each interaction with the application required the user to bear significant transaction costs in ether and the quantity of data and processing power at an application’s disposal was reminiscent of the 1970s, rather than modern computing. Nonetheless, it was a powerful proof of concept.
Ethereum is built as a general purpose blockchain. In principle, one can write any software application to run on Ethereum. This is the key point of differentiation between the Ethereum vision for DApps, and the Cosmos vision for DApps. Sometime in 2015, the Tendermint team questioned whether a single blockchain ought to host all of the DApps, or whether each DApp ought to be hosted on its own dedicated blockchain. Is the future one of a single dominant DApp hosting platform (Ethereum), or one of a myriad blockchains, each tailored to a specific application? The Tendermint team bet on the latter vision.
This bet altered the demands from Tendermint. Early Tendermint had been developed with the goal of building cryptocurrencies. Now, the need was a deliver a general platform that allowed others to build their own blockchain hosting specifically their own application aka an application-specific blockchain. The focus shifted from the pure accounting of cryptocurrencies to hosting general application logic and data.
Node software for various blockchain networks can be divided into three functional components, each playing a different role. These components are: Networking, Consensus and Application Logic — and they can be thought of as independent modules that work together to make a blockchain node:
Until this point, Bitcoin mixed the subcomponents of these modules into an interwoven codebase. Two projects, Tezos and Tendermint, initiated the effort to separate these components neatly, so that they could be built and upgraded in parallel. Their motivations for such separation are radically different, but that’s a topic for a different day. Over time, other projects have also adopted the design pattern of separating these modules, so much so that it isn’t a particularly unique idea anymore!
Tendermint combined consensus and networking into Tendermint Core. The Application module would run concurrently, on the node, entirely separate from Tendermint Core. A protocol, called ABCI, was developed to facilitate communication between Tendermint Core and the Application module. The following diagram illustrates this new Tendermint architecture.
This concept, and its utility, is better understood via analogies. Let’s consider two analogies — your personal computer and DNA. Ponder this question: What makes a computer “your computer”? All computers share thousands of hardware and software components — cores, buses, BIOS, operating systems etc. What makes your computer yours is the data you input into the computer, and the software you configure on it. Tendermint Core is analogous to the systems that are common to all of the computers — it concerns itself with lower-level tasks like networking and consensus that all blockchains need to perform. If the reader, as an entrepreneur, launches their blockchain for a decentralized exchange and I, launch a different blockchain for a decentralized Twitter application; both our chains can be powered by Tendermint Core. Tendermint Core is akin to an operating system for blockchains.
Let’s zoom in to a blockchain running decentralized Twitter. This specific blockchain requires tailor-made logic and needs to store user data. This logic might, for instance, implement the restriction of tweet length to 140 characters; with each tweet being a transaction on the blockchain. The application data would store a giant list of all historical tweets in a query-able format. It’s the combination of application data and application logic that gives a decentralized Twitter blockchain its “Twitteriness”. Similar to how your data and the software you install make your computer uniquely yours. The new Tendermint design allowed the separation of the Twitter specific items, implemented as an application, from the other, more mundane parts of the blockchain (Tendermint Core).
This design also has inspiration from biology. If one considers the difference between one of your cells and one of mine; the majority of the machinery — amino acids, lipids, organelles etc. — are all common between the two. What differentiates our cells are the differences in our DNA. The Application logic and data, in the diagram, is analogous to DNA while Tendermint core is akin to all of those pieces that are somewhat immaterial to our specific identity.
The value proposition of this design is that future entrepreneurs, launching application-specific blockchains will need to focus only on their application logic. This is powerful in itself, but the Tendermint team went a step further with Cosmos SDK — a framework for writing blockchain applications.
While each application-specific chain has its unique data and logic, many decentralized applications tend to require similar pieces of logic, or base components. For instance, consider tokens and token transfers. Many applications — decentralized exchanges, stablecoins etc. — will require the issuance, transfer, accounting logic and delegations of token rights on the blockchain. To make the creation all of these token operations a cinch, the Cosmos SDK contains a “bank” module with prebuilt logic for token functionality. In a similar vein, the SDK contains modules for governance operations, staking operations etc. Future modules will add functionality like auctions, exchange operations, reputation operations, registry operations etc. The result will be a rich toolset of components to combine in building blockchain applications.
These SDK modules allow for the simplification of developer experience when developing blockchain applications. The aim of the SDK is to be the Ruby on Rails of blockchain applications. If this approach pans out; imagine dozens of application-specific chains hosting disparate functionality, and their own individual tokens.
This incipient world of application-specific chains, each containing their own staking token and validator community, is a powerful alternative to the Ethereum vision of DApps written as smart contracts and hosted on the Ethereum chain. While it remains to be seen how this new model shall fare, the contours of its advantages and disadvantages are already visible.
The first advantage of the application-specific model is community sovereignty — each chain is able to make design decisions tailored for the specific application at hand, independent of the choices made by other applications in their own chains. This serves to avoid contention between different application communities. We’ve seen this kind of contention emerged in the Ethereum ecosystem when the DAO was hacked, and Ethereum holders were forced to make radical decisions to repair the accounts of DAO investors. It emerged again in the Parity multisignature episode. Future upgrades to the Ethereum platform have the potential for affecting different applications differentially. This can become a bone of contention, when different application communities seek fundamentally different upgrades to the Ethereum protocol.
The second feature of the model are the better scaling and performance characteristics of each application-specific chain. Each chain need not specialize in general purpose computation, and can restrict operations to a very small set of transactions. Application logic can be implemented “closer to the metal” making it operationally cheaper. Applications also get their own dedicated capacity, and need not share that capacity with other, high transaction volume, applications. This is an important feature, since ICOs on the Ethereum platform have crowded out capacity for other applications.
However, this model creates some specific downsides. The primary downside is weaker security. Imagine thousands of chains, each carrying their own staking tokens and applications. It is likely that the majority of these tokens will have low market capitalizations (<$100 million), and therefore be vulnerable to alterations of their history. There are a few potential solutions — replicated security and sortition based security — to securing hundreds of application chains. We shall cover these methods in the blog later; but these methods will invariably encroach upon the community sovereignty of application-specific chains.
Some proponents of the Cosmos Internet of Blockchains vision believe that small market capitalization chains (aka small chains), secured by Tendermint, will be secure enough for practical purposes. Their argument is that really egregious attacks on small chains require the attacker to buy up 66% of the voting power in a relatively illiquid staking token. Such large purchases ought to drive up the market capitalization to higher levels, and reduce the incentive to attack the chain once a majority of the tokens are bought by the attacker. Another defense, available to small chain communities, is to (hard) fork out the attacker and disregard their blockchain, similar to what Ethereum did to the DAO attacker. It remains to be seen whether these arguments will survive contact with reality in the next decade.
The second downside is the potential to create application silos, where data and tokens on one application chain are unable to be synergistically used with logic on a different chain. Just as Uber drivers find it really hard to migrate to Lyft, and carry their own reputation; the blockchain sector risks the creations of similar economic incentives for the percolation of silos. Thankfully, the Tendermint team has worked out beautiful concepts, which are the subject of our next article, to route around some of these impending issues.
In this article, we’ve covered the story of how Tendermint responded to the prominence of decentralized applications, by presenting and implementing the toolsets for entrepreneurs to build application-specific chains. These application-specific chains, are potentially, better base layer infrastructure for the realization of decentralized exchange, stablecoin, prediction market, decentralized social media and other incipient technologies.
This vision naturally raises the specter of data and value silos that prevent applications from inter-operating with each other seamlessly. This will be subject of the next article in our series, which covers the development of IBC — a protocol for blockchains to send authenticated value carrying messages to each other — and of the Cosmos Hub. The next article will be last in the series and completes our exposition of the key ideas behind the Cosmos Network.
If you want to discuss Cosmos further, stop by our Chorus One Telegram and say hi. And, of course, we’re happy to answer any questions about delegating to Chorus One.
We are delighted to announce the publication of our Loom Network Investment Thesis:
So why, you might ask yourself, would Chorus One, a leading infrastructure provider for decentralized networks, write an investment thesis about a decentralized network? Isn’t that best left to research analysts? Shouldn’t infrastructure providers stick to running validator nodes?
And running a validator node is easy, right? Someone else writes the code, so you download the software, install it, configure it and you are done. Right?
Well, no. Not really. Not at all, actually.
When Chorus One commits to running a piece of decentralized infrastructure we have every intention of being highly involved with that network for years to come.
We don’t just read all the documentation available. In fact, sometimes there is very little documentation and what is there can often be out of date. So we dive into the code. We understand every detail of the consensus mechanisms, the software configuration options, the potential attack vectors and the application interfaces. We need to know how to run these nodes 24/7/365, so we have to instrument everything, i.e. we need to get visibility of everything that is happening in the network, with real-time data feeds. We need to ensure we can integrate logging, monitoring, alerting, analytics, and fully automate all aspects of the delivery pipeline.
We also commit to being highly engaged community members. We will be actively involved in every governance decision. We will monitor every pull request to see what changes are being made to the codebase to determine if they will impact the security and robustness of our infrastructure or the network at large. We propose changes to the protocols. We contribute code. We build open-source tools for other validators to use. Most importantly, we are always there for our delegators to provide them with advice, to answer their questions and to act as their technical / governance representatives in community discussions.
Most of all we evangelize. We validate on a network because we believe in its vision. The competition between networks is going to be intense. Only the networks that can clearly articulate the value they provide will survive. We are a communications partner for the networks we run. We produce blogs and video podcast updates to educate and inform users, developers, investors and other ecosystem participants.
In short, we make a major long-term investment in a network when we decide to run a validator node. And therefore, we treat the decision like an investment decision. We need to know the size of the opportunity, to map out the ecosystem, to understand the use cases, to assess the competitive threats and the regulatory landscape. We need to assess the overall strategy, the go-to-market, and the cryptoeconomics. Then we need to consolidate all of this information into an overarching thesis so that we can make a go/no-go decision.
Today we are announcing the release of our Loom Investment Thesis, a 26-page document that captures the results of our research to date. We are releasing this document to the community so that everyone can have a chance to learn about this great project.
Last Friday (February 15th) we launched our Loom validator. LOOM token holders can now delegate their tokens to us. The maximum yield on Loom tokens is currently set at 15% (after commissions) in Year 1, so it’s a great opportunity to earn returns on your crypto investment. To find out how to delegate your tokens check out our step by step tutorial here:
blog.chorus.one
Over the coming days and weeks we will be adding more content and insights on Loom. Follow us on Twitter and join our Telegram and mailing list to find our more.
Originally published at blog.chorus.one on February 18, 2019.
Staking is emerging as a way of ensuring Sybil-resistance in permission-less, public blockchain networks. Delegation protocols allow anyone holding a Proof-of-Stake (PoS) cryptoasset to participate in securing these networks and being rewarded for it. An industry surrounding the staking ecosystem is forming. Low barriers to entry mean that any party dealing with staking tokens may become involved directly or indirectly.
After learning about validation and delegation, as well as the incentives in play when considering to participate in staking, this third part of the “Proof-of-Stake Ecosystem” series will cover which players can be expected in a PoS network.
The first group of stakeholders in PoS network that comes to mind are investors, which are usually split into a retail and institutional market. But not only investors will be holding staking tokens; a significant portion is usually held by foundations funding the development of a decentralized network. Other holders include entities dealing with cryptoassets as part of their business activities or as a result of their funding. Similarly, projects hosting their applications or assets on a PoS network might consider to improve the security of it by participating in staking.
Another important stakeholder group are third party services that facilitate the purchase, trading, storage and access to cryptoassets. These will need to consider if and how they will enable their customers to participate in this emerging space. Centralized exchanges, cryptoasset custodians and wallets belong to this group.
An essential emerging part of the PoS puzzle are third party infrastructure providers that enable participation in staking for all of these token holders. This group is also referred to as staking pools, staking providers, or delegation/staking services.
Finally, block explorers, rating websites and potentially delegation marketplaces will assist token holders in choosing fitting staking providers by aggregating information and curating available delegation services, which can be done in a variety of ways. The following graphic depicts an overview of potential participants in the PoS ecosystem:
As highlighted in the second part of this series, the decision to participate in staking comes down to a cost and risk versus rewards analysis that should be carried out by each potential participant. While some may choose not to participate in staking at all, those who will are essentially faced with the decision to either run staking infrastructure themselves, delegate to (a set of) staking provider(s), or potentially a combination of the two.
In the following, I will cover each stakeholder group shortly discussing their connection to staking including some examples.
This is the most diverse group that consists of individuals owning the staking token, ranging from developers and enthusiasts to a grandma that got gifted some cryptoassets by her grandson for Christmas. Retail investors may become part of the staking ecosystem in a variety of ways depending on how they store their cryptoassets. Some technology enthusiast will run staking nodes themselves to improve decentralization of their favorite project. Others might participate in staking through the exchange they decided to leave their cryptoassets on. Some will delegate to their favorite staking providers based on their own research, other will rely on information provided by staking service curation sites or marketplaces (current examples include sites like MyTezosBaker and marketplaces like Rocketpool or Vest).
The staking space for institutional investors differs from that of retail investors, as these entities are mostly bound by regulations or other limitations guiding how they may store and utilize their cryptoassets. Institutional investors include VC firms that invested in an early stage PoS project, hedge funds that may own a staking cryptoasset, and potentially a wide range of other traditional investment companies such as family offices or even banks. These entities may simply hire their own team to run staking infrastructure. Another option would be to partner with a professional staking provider, or to participate in staking through their custodian (see below). Finally, institutional investors can also make use of delegation protocols and outsource validation work by delegating to staking services. We are already starting to see early examples of institutional investors running their own validator infrastructure (e.g. Polychain), hybrid fund/staking provider structures (e.g. Mythos Capital and Mythos Services), as well as partnerships between funds and staking providers (e.g. Bison Trails and Notation Capital).
This is a group that is seemingly largely disregarded, but that might make up a significant portion of the staking market. Many companies and projects involved in the blockchain space will or do currently hold cryptoassets that could be staked. At this point these were mostly received in ICOs or through grants, with a few crypto payment processing companies serving as examples of businesses that are holding cryptoassets.
In line with the previous group that may hold stakeable tokens received in the fundraising process or through business activities, many projects and companies involved in the blockchain ecosystem may have an interest in securing the PoS network on which their application or assets are built. By staking the network’s native cryptoasset, such projects can help to improve how difficult it is to attack the network on which they are relying. An example of a blockchain startup that voiced their interest in staking is Gnosis.
This is one of the most important and controversial participants in a PoS network, as foundations are usually controlling a large share of the staking token. Participating in staking would potentially increase a foundation’s control over the network even further. On the other hand, foundation support for staking might be necessary to secure the network (especially in the early days). Furthermore, staking may provide a way to continuously fund development of a decentralized network. Delegation also enables additional ways to support parties advancing it (e.g. by delegating to validators that contribute to the project). The Tezos Foundation’s approach is an early case study in how foundations might participate in the staking ecosystem by seeding the ecosystem and lowering their influence overtime.
Cryptocurrency wallets have a variety of choices on how they may incorporate staking opportunities in their products. Some potential directions include running their own validator infrastructure or partnering with a staking provider to offer staking to customers. Another direction would be to simply incorporating the delegation protocol and to let users decide how they want to participate in staking themselves. Here, Balance is leading the way with early experimental drafts of how staking might be integrated in their wallet.
Centralized exchanges are another interesting case, as they are essentially controlling their customers funds and may potentially participate in staking on behalf of their users. Another option could be to create some separate type of staking account in their system or integrating a delegation option in the exchange interface itself. An early examples of an exchange participating in staking is gate.io.
Some cryptoasset owners are required to store their assets with a third party and others do not want to be in control of their private keys themselves, which is why a large market of cryptoasset custody services has emerged (BitGo, Coinbase Custody, PolySign, etc.). As an example, US hedge funds with over $150 million in assets under management need to store their assets with a certified custodian. This circumstance puts custodians in a potentially powerful position in the staking economy. Custodians might run their own validator infrastructure or enable customers to delegate tokens to a set of curated partner staking providers etc. Because custodians are a strongly regulated business, it is currently unclear if and how these entities will be able to participate in staking.
Finally, one of the most important emerging parties in the staking context are professional staking providers. These are entities that are focusing on creating secure and reliable staking infrastructure for delegators and other partners. These teams can work together with all of the parties as described above. Chorus One is an example belonging to this group that aims to provide a high quality staking service in multiple Proof-of-Stake networks. Some notable other staking providers that are helping to advance and educate people around the validator and staking ecosystem include Certus One, Cryptium Labs, Figment Networks, Lunamint, and Staking Facilities.
The following post of the “Proof-of-Stake Ecosystem” series will go into some more detail regarding factors that could threaten the security of a PoS network. The series will conclude with a discussion of potential mitigation strategies.
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 November 21, 2018.
As cryptonetworks mature and move from development to usage, cryptoassets will be utilized in many ways. For example, Proof-of-Stake networks enable token holders to participate in securing the network and receive rewards by staking their tokens. To make the most of an investment in a cryptoasset, simply holding it will likely be a suboptimal strategy. Many networks reward participation by inflating tokens and handing them out to protocol following participants resulting in a dilution of non-participating token hodlers. The following post will go into the economic considerations that go into the decision of participating in a Proof-of-Stake network.
This is the second post of the “Proof-of-Stake Ecosystem” introductory series. The first post provided a basic introduction to PoS and the concepts of validating and delegating, you can find it here in case you missed it. Upcoming posts of this series will go into more detail regarding the parties involved in a Proof-of-Stake network, their positions and potentially centralizing factors.
Until now being a long-term cryptoasset investor was a rather straightforward experience: you obtain the desired cryptoasset, store it (or leave it on an exchange) and wait. The popularized “hodl” meme is the epitome of this approach that contrasts short-term trading strategies employed by many speculative crypto investors.
With the advent of protocols that allow for utilization of crytoassets, e.g. staking in Proof-of-Stake networks or lending out tokens, the optimal strategy for long-term investors probably won’t be to simply hodl.
In the following analysis, I will focus on the incentives of participating in a Proof-of-Stake network versus alternatives, especially contrasting validation and delegation. An owner of a Proof-of-Stake cryptoasset can essentially choose from the following options:
1.) Hodl, i.e. keep tokens liquid
2.) Stake
3.) Utilize tokens in another way
From an economic perspective, a rational investor should choose the option with the highest risk-adjusted return. In practice this means that a token holder should figure out what kinds of risks are involved (ideally quantify them), what the expected returns (after subtracting costs and considering other limitations) of the various options are, and finally compare the various alternatives to each other to make the optimal decision based on her risk profile.
To do this kind of analysis, it is important to consider important factors that validating and delegating in a Proof-of-Stake network introduce. These are:
Liquidity risk is prevalent in most Proof-of-Stake protocols; there is often a lockup period associated with staking to be able to penalize potential offenders and to prevent long range attacks. Without this period a malicious party could attack the network and withdraw their stake immediately leaving no chance for the protocol to punish the offense. Because a Proof-of-Stake network is permission-less, anyone fulfilling requirements (i.e. staking enough tokens) can join the validator set. That also means that there needs to be a way to disincentivize not following the protocol. Staked tokens in a PoS network are often subject to being slashed (destroyed) should a malicious action be detected by other network participants. A common slashable offense is the signing of two blocks at the same height, also referred to as double-signing or equivocation.
Additionally, returns in a Proof-of-Stake network depend on the performance of a validator. Failing to propose or verify blocks of transactions means missing out on rewards and can even result in liveness slashings, due to being offline for some extended period of time. Continuously signing and sending messages on behalf of staked tokens as part of the consensus process requires technical and operational excellence. Sound system architecture facilitating a high degree of security is a requirement to be able to guarantee continuous operation of validator infrastructure and to avoid slashings. A validator is an attractive target for parties that want to attack a Proof-of-Stake network. Compromising a validator node could potentially allow double-spend attacks on the network at no cost to the attacker, as only the validator (and his delegators) are subject to slashings should the attack fail. There are countless attack vectors such as DDoS attacks, compromise of validation keys by rogue employees or extortion by outsiders that should be considered when designing the technical architecture and key management system of a validator.
These factors show that building and maintaining a well-performing and secure validator requires technical expertise, time and a complex infrastructure including surrounding tools. When contemplating whether to start a validator operation these requirements should be considered and the associated costs calculated. At Chorus One, by the time of launch, we will have had three people spend a significant portion of their time for roughly a year working on our Cosmos infrastructure. A rational token holder will choose to delegate to a (set of) professional delegation service(s) when the cost incurred of building and operating validator infrastructure exceeds the cost of commission paid when outsourcing validation work.
For many parties whose core business is outside of this scope of secure infrastructure and key management operations, it likely makes sense to delegate tokens to (a set of) professional validators both from a cost and risk minimization perspective.
When considering to run validator infrastructure, there is also the option of accepting delegations, i.e. turning a validator into a delegation service. Doing this will incur further costs associated with operating a validator as a business. These include costs for marketing, customer support, business development, legal, etc. This will likely require a dedicated team and the success of such an operation will largely depend on the quality of the service provided.
The following table shows the most important dimensions and the associated characteristics from the possibility space of a cryptoasset investor introduced above.
As most of the listed options (currently) exclude each other, there are opportunity costs associated with e.g. choosing to delegate instead of loaning out staking tokens. As such, it is possible that staking yields and borrowing rates will converge (as Jake Brukhman from CoinFund notes in this blog post). Furthermore, in some PoS protocols, additional considerations such as varying treatment of reward payouts can also influence decisions.
Finally, there are many not purely financial motives that might be considered when choosing how to participate in staking. These include wanting to support particular parties (especially important in light of protocol governance), improving decentralization of the network, regulatory implications, conflicts of interest, user experience, benefits of staking with a validator on multiple networks and other value-added services that a third party delegation service may provide.
I hope this post gave you a basic understanding of how to think about incentives in a Proof-of-Stake network and the possibilities and risks that token holders in such an environment face. In the next post of the “Proof-of-Stake Ecosystem” series, I will go into what parties can be expected in a PoS network.
Chorus One is a provider of staking services and validation infrastructure with a focus on providing the highest degree of security and quality possible. Our goal is to help token holders earn interest on their cryptoassets. Visit our website and contact us to find out how we could support you in upcoming Proof-of-Stake networks.
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 November 7, 2018.
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.
