There is a tangible feeling that the gloves are coming off in crypto. When crypto was growing fast and valuations hit peak bubble, it was easy to argue that crypto was such a big transformation that all the early movers could be winners. As crypto winter befell us, the focus turned to survival and on buidling. Crypto took a hit, but the smart money stayed in and the crypto ecosystem is in much better shape to disrupt the global economy. But now some people’s minds are turning to the impending battle of the chains.
In this article, the first of a series of posts, we’d like to argue the opposite point of view. We believe that it’s much too early for crypto infighting. When markets mature, competition will get intense. But we are nowhere near a mature market. Right now, it’s in everyone’s interest to focus on growing crypto into a rich, diverse ecosystem of projects that can thrive together.
Throughout the blog post series, we will work to reclaim the “Internet of Blockchains” (IoB) vision from the many projects that have claimed it as their own. When we speak about IoB, we mean a vision of the decentralized web that is made of tens of thousands, maybe even millions, of interconnected blockchains. This vision may include a range of general-purpose smart contracts platforms, each with their own features that create differentiated value propositions. There may be competing inter-chain protocols that allow value to flow across the IoB, potentially through decentralized hubs that can securely route these flows. Data will be dispersed across a range of private and public repositories. Much of the business logic will sit in application-specific chains.
We want this reclaimed Internet of Blockchains vision to serve as a catalyst for a renewed focus on positive-sum thinking within the wider crypto community. Maybe we can even call it Interoperability Maximalism 😁.
When Chorus One selects a network to support, interoperability is a key requirement. You could say it’s our central investment thesis. The two projects we run validators on today (Cosmos Hub and Loom Network) both reflect this interoperability bias. Both the Cosmos Hub and Loom’s PlasmaChain are two very important pieces in the IoB vision. They are both, in their own ways, interoperability hubs. Loom is a Layer 2 network built on Ethereum, so ETH and ERC20 tokens can be used by apps running on the chain. Loom has also announced interoperability with Cosmos Hub, Tron, and EOS (and we’re guessing there might be more network integrations to come). Cosmos has announced plans to bridge their hub to Bitcoin and Ethereum. They also provide an SDK for developers to build their own application-specific blockchains or “zones” (as they are known in Cosmos terminology). Cosmos are also working on their Inter-Blockchain Communication (IBC) Protocol, which could become the global standard for inter-blockchain value exchange, allowing digital assets to be moved across chains.
So instead of thinking what <insert your favorite blockchain> should be doing to out-compete the rest of the community, why don’t we try to reframe these strategy discussions and try to figure out where each blockchain fits into the Internet of Blockchains? What special value does each chain add? Does it differentiate by providing unique value? Can it identify a niche to fill and then look to build network effects within that niche?
For general-purpose smart contracts platforms, this might mean some form of specialization i.e. identifying key use cases to focus on and adding features that uniquely enable those use cases. What attracted us to Loom, was their decision to focus on features for the gaming industry, by building the essential elements required by the game studios who are lined up to capitalize on the great disruption that crypto brings to their industry. Once a niche is identified, each project can then try to figure out where the network effects are. In gaming, marketplaces for trading in-game assets are the best places to build sustainable competitive advantage.
Other networks we are speaking with are a looking to drive down the cost per transaction on smart contract networks to give them a unique advantage in verticals that require massive transaction volume e.g. micropayments. Others are focusing on developer productivity, through great tooling and new paradigms for code reuse.
Another approach is to build specific protocols. The Cosmos IBC protocol takes a siloed network and makes it more useful by making it interoperable with other networks. When protocols become global standards (think HTTP, TCP/IP) they become irreplaceable. Protocols have very powerful network effects. So Cosmos Hub with IBC has identified its niche. But more importantly, the Cosmos community have a clear strategy on how to succeed in this niche i.e. to make IBC the global standard. In later posts we’ll show how Cosmos SDK, Ethermint, pegged zones etc. all come together to maximize IBC’s chances of success.
So stay tuned. This interplay of differentiation and strategy is at the heart of how we think about interoperability. Over the series of posts, we’ll dig deeper into a range of topics that will hopefully start a wider conversation about how we deliver on the Internet of Blockchains vision.
Follow us on Twitter and join our Telegram and mailing list to find out more.
The Cosmos Hub has launched and one of its core features is the ability for Atom holders to collectively govern the blockchain. Atom holders can submit proposals and signal their approval or disapproval to proposals submitted to the network by signing a special type of transaction. The following article will cover the governance procedure on the Cosmos Hub and introduce our governance tool that allows any Atom holder to participate in the on-chain governance mechanism.
In the current Cosmos Hub governance implementation anyone can submit a text proposal to the system. A minimum deposit is required for a proposal to enter the voting period during which Atom holders will be able to vote on whether the proposal is accepted or not. The numbers used in the following are based on the parameters implemented on the Cosmos Hub at the time of writing (25th March 2019).
For a proposal to be considered for voting, a minimum deposit of 512 Atoms needs to be deposited within 2 weeks from when the proposal was submitted. Any Atom holder can contribute to this deposit to support proposals, meaning that the party submitting the proposal doesn’t necessarily need to provide the deposit itself. The deposit is required as spam protection, Atom holders that contributed Atoms to a proposal will be able to collect their deposit when the proposal was accepted or when it did not reach the minimum threshold after 2 weeks.
When the minimum deposit for a particular proposal is reached the 2 week (336h) long voting period begins. During this period, Atom holders are able to cast their vote on that proposal. There are 4 voting options (“Yes”, “No”, “No with Veto”, “Abstain”).
Important details in the governance implementation of Cosmos are:
If a proposal is accepted depends on the result of the coin voting by Atom holders. The following requirements need to be satisfied for a proposal to be considered accepted:
If one of these requirements is not met at the end of the voting period, e.g. because the quorum was not met, the proposal is denied. As a result, the deposit associated with the denied proposal will not be refunded and instead be awarded to the community pool.
An accepted proposal will need to be implemented as part of the software that is run by the networks’ validators. A future blog post will cover different types of proposals and how exactly validators coordinate to implement a proposal that passed the procedure described above.
For an exemplary governance vote, check out the first governance proposal from validator team B-Harvest about adjusting the block time rate used to calculate network inflation to mirror actual conditions in the network (Note: Chorus One is supporting this proposal because it aligns staking rewards paid out by the live network with what was described in the Cosmos whitepaper).
At Chorus One, we aim to enable token holders to exert influence on network governance. For this reason, we created a tool that allows Atom holders to effortlessly cast their own governance vote from their Ledger device. You can find the tool on our Cosmos page:
https://chorus.one/networks/cosmos
Another part of our effort in terms of network governance is informing and discussing governance procedures and proposals with our community of delegators and the wider Cosmos ecosystem, join our Telegram and follow our social media channels to stay informed about our stance in matters of blockchain governance!
We believe the governance implementation of Cosmos with delegators inheriting validator votes, but delegators being able to overwrite validator choices and make their own decision is a great solution to the low governance turnouts that can be observed in other blockchain networks. We think this approach does good in striking a balance between a representative democracy (“proxy voting”) for less interested holders, while still allowing for direct influence for token holders that want to directly engage in network governance.
Cosmos Hub governance is still in its early days and we aim to provide our input into how the system could be improved, as we believe a well-functioning governance mechanism will increase the likelihood of success of the Cosmos Network, feel free to chat with us about your ideas!
Chorus One Governance Tool:
https://chorus.one/networks/cosmos
Cosmos SDK Governance Documentation: https://cosmos.network/docs/spec/governance/
Cosmos Network Governance Forum: https://forum.cosmos.network/c/governance
Governance Proposals Statistics:
https://bharvest.io/wallet_en
https://hubble.figment.network/chains/cosmoshub-1/governance
Gaiacli Instructions:
List of query commands (in gaiacli):
gaiacli query gov -h
Participation (through gaiacli):
https://cosmos.network/docs/gaia/delegator-guide-cli.html#participating-in-governance
Originally published at blog.chorus.one on March 25, 2019.
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.
.png)
