.png)
This is Part 2 of a series of posts. Part 1 can be found here.
We often see the term “network effect” in technology discussions. In common usage, the term can be misused to imply a natural tendency for networks to add value to all users as they grow. But this is not always the case.
Firstly, there are many different types of network effects, each with different characteristics and differing strengths. One thing that is often overlooked is that network effects can sometimes be negative and, in fact, sometimes both positive and negative effects can co-exist in the same network. An effect is positive when more people using the network gives everyone access to more value. But a broadband or mobile network may have negative network effects, where more users may lead to more congestion. We see something similar in a social network, where noisy content feeds caused by user growth can make it harder to find quality content. In a marketplace, more sellers result in more competition for other sellers (negative), but more products for buyers (positive), which in turn leads to more buyers which is good for all sellers (positive). This specific example is called an indirect network effect. The NFX venture fund has an amazing collection of essays on network effects here: https://www.nfx.com/essays.
In this post, we’ll show why network effects are so important in Cosmos. The main reason is that Cosmos is not just a network: it’s a network of networks. Each sub-network has its own network effects which will interact with each other. When Ebay started they could focus on one network: buyers and sellers in a marketplace. Likewise for Uber: drivers and commuters. The Cosmos Hub has at least three types of network effects at launch.
NFX defines two-sided platform network effects as follows:
“… 2-Sided Platform nfx … the supply side actually engineers products that are only available on the platform. The supply side has to do work to integrate to the platform. The products created and sold by the suppliers are a function of the platform, not independent of it.”
At first glance, it may seem that Cosmos SDK fits into this classification. Developers build apps as the supply side, with app users as the demand side. And these apps are “not independent of the platform”. So this looks like a typical developer platform such as iOS, Windows, or Xbox. Here we can see that Cosmos is a platform.
But… NFX also define protocol network effects that “arise when a communications or computational standard is declared and all nodes and node creators can plug into the network using that protocol”.
When we look at Cosmos this way our focus is on its ability to become a global standard for inter-blockchain communication, much like TCP/IP powers the internet or VHS became the video standard. So Cosmos is also a protocol.
Another perspective on Cosmos focuses on resource provision. We can look at Cosmos as having two-sided marketplace network effects, with validators providing computational resources on one side and app developers paying for these resources (either directly or by passing the costs onto their end users) on the other side. In fact, we can also see a second two-sided marketplace, with delegators as resource providers providing capital and validators as the demand-side, providing security and a safe return on that capital. So, from this perspective, Cosmos consists of two back-to-back two-sided marketplaces.
For Cosmos to succeed, each of these three classes of network effects (platform, protocol, and marketplace) need to strongly reinforce each other. They will each come into play at different phases in the growth of Cosmos.
As a platform, the focus needs to be on growing the developer community. The Cosmos community will need to build out the best tooling for developers to build, deploy and support applications. It will need to be cost-effective for developers to get their apps into production and in use. The community needs to create the best forums for the community of developers, sharing sample code, supporting each other, updating documentation etc.
But it’s also important that the validators and delegators help to build developer and user confidence in the network, by securing the infrastructure, avoiding network downtime and improving overall resiliency. Cosmos validators will need to work together to ensure that as the first apps take off, the user experience is on par with centralized services like AWS and other centralized networks. The network must also remain cost-competitive so that developers and users are not put off by high fees, while maintaining high enough rewards to support world-class infrastructure providers and to provide competitive risk-adjusted yields for delegators, especially in light of competing investment opportunities in the decentralized finance (DeFi) space. This is why the effectiveness of the marketplace mechanisms are so important.
But the Cosmos vision of multi-token services and the interoperability of chains will become increasingly important over time. This is where protocol network effects become increasingly important. While each effect can be built up over time, all three are mutually self-reinforcing. An early win with a multi-token service, even one with low transaction volumes, could have a meaningful impact on the long-term chances of the Cosmos Inter-Blockchain Communication (IBC) Protocol becoming the de facto standard for token exchange. But if there were weak rewards for validators or a high number of slashing events (causing weak delegator returns), this could start to negatively impact the quality of the network infrastructure thus damaging the long-term potential of IBC and weakening the attractiveness of Cosmos as a developer platform.
What is especially interesting is the relative strength of each network effect. Platform effects are weaker than protocol network effects. This is because developers love nothing more than trying out new tools and platforms, as is evidenced by the huge number of developer libraries and frameworks. Right now this is a strength for Cosmos, as Ethereum developers are more likely to experiment with a new platform. But even though platform effects are weaker, they can still provide an advantage, so it’s important for Cosmos to build an effective community of developers helping each other, contributing to tools, videos, Q&A forums etc. This will serve to strengthen the overall proposition, giving itself more time to build out the stronger protocol effects.
In summary, Cosmos is a network of network effects. If these network effects can reinforce each other, this could make Cosmos more powerful than any protocol, platform or marketplace that has previously existed. But it requires a delicate balance. It will be an exciting experiment!
Stay tuned for more in this Internet of Blockchain series, where we dive into staking economics, value capture, governance and more.
Follow us on Twitter and join our Telegram and mailing list to find out more.
Originally published at blog.chorus.one on April 8, 2019.
Stable Cosmos Hub mainnet without transfers
Clearly specified and decentralized upgrade process
New release for testnet with transfer feature enabled and other parameters such as the block size updated
Stable testnet with new release software
Phase I: a vote on a proposal specifying a plan and the criteria that need to be achieved for transfers to be enabled
Phase II: an expedited vote on the exact git hash for the updated software and block height for when the upgrade will take place
Chorus One is in favor of enabling transfers as quick as possible, as this is an essential feature of any blockchain network and because we want to encourage a wider distribution of Atom holders that isn’t limited to fundraiser participants. We believe the state of the mainnet proves the readiness of the network to enable transfers.
At the same time, we are aware that a new software release that will change parameters like the block size needs to be tested before migrating to mainnet. Additionally, we support a clearly defined process that allows for a decentralized upgrade to happen. Finally, we believe the integrity of the chain and the decision-making needs to be independently verifiable in the future, which is why a formalized governance process should be followed and the state of the old chain (cosmoshub-1) needs to be preserved adequately.
These requirements call for a two-step upgrade process where the first proposal is there to decide on what is planned and the second one is targeting a specific release that should match what was described in the first proposal.
The proposal at hand describes such a two-step process and it also plans to modify the parameters needed for the second proposal to pass. We support the current proposal including the 24-hour expedited governance rule for the second stage.
Some validators have suggested that there should be separate proposals: One on the general governance process and another one on the specific issue. We view the governance process of this proposal as an experiment and limited for this particular proposal. After this, we will have data to see whether this process is sound or a different governance process should be adopted. At that time, it will make sense to have a separate governance vote to decide on a general governance process. But to hold off enabling transfers at this point would be misguided, in our view.
The expedited governance rule states that a proposal may be deemed to have passed if ⅔ +1 of the bonded stake has voted in favor of the proposal for a continuous duration of 24 hours (after a buffer period of 24 hours passed). We think this is a reasonably secure way of ensuring that the plans from the first phase of an upgrade have been met in the second phase of the upgrade and that the proposal is actually supported by a majority of both validators and Atom holders delegating their stake.
We think the data from an abandoned chain should persist in an independently verifiable way in the genesis file of the new chain. The current proposed solution relies on trusting external identities to provide this data, which we believe is not sustainable. Chorus One will store cosmoshub-1 state data and encourages other validators to do the same to have as many entities as possible verifying the data that will be included in the genesis file of a future upgrade.
Chorus One is voting “Yes” on this proposal to enable transfers on the Cosmos Hub. We do view it as a desirable guideline that most proposals should cover only a single issue in the future.
Should the testnet with the new software release be unstable, or other problems emerge, we may vote no for the second proposal. We will follow the development of the testnet closely and will provide updates on our social channels.
If you want to vote yourself because you disagree with the voting choice of your validator(s), you can use the governance tool available on our website which allows you to cast your own vote that will overwrite all your validators’ decisions. Join our Telegram to discuss this issue further and make sure to subscribe to our social channels to be informed about future proposals and our evaluation of them.
An Overview of Cosmos Hub Governance
Transfer Enablement Proposal #1 & #2
Tendermint Recommendation to Decline Proposal #1
Forum Discussion on Proposal #2
Originally published at blog.chorus.one on April 4, 2019.
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.
.png)
