Apps running on top of blockchain infrastructure will always act according to their own best interest. I don’t think this realization surprises anyone.
What might surprise you is that apps are the ones really in power in the blockchain infrastructure game. We just recently wrote a blog post about it — Who Controls Your Blockchain? — well, now more than ever it’s clear that apps do.
Please Note: This is a Guest Post by Uriel Peled, Co-Founder of Orbs.
The Stellar Fork by Kin
Kin by Kik Interactive is one of the first large-scale apps to move to blockchain. Kin’s eventual goal is to be the most-used cryptocurrency by consumers. To pull this off, Kin is launching its digital services ecosystem on the Stellar blockchain instead of Ethereum because of the latter’s scaling issues.
The news this week that Kin will actually use a Stellar fork adds a twist to this story. Why would Kin do that? After all, forking is difficult and keeping blockchain infrastructure in production is a massive undertaking.
It’s all a question of control.
The first reason is that Kin needs to scale quickly and Stellar fees are paid per wallet. If you plan to on-board as many users as possible, a fee model that grows directly with the number of users and is highly susceptible to churn and fraud. The Stellar fork would allow Kin to change the fee model and avoid paying infrastructure fees to Stellar main net nodes.
This should be a textbook example for the blockchain world. If an app is unhappy with a blockchain infrastructure is providing, it will simply abandon it, move to another, or just fork it . The app is in control, taking its end-users wherever it goes.
Who controls how high or how low fees are on Stellar main net: the Stellar validator nodes, free to choose whether fees rise or fall.
Making protocol decisions that work against the interest of apps is likely to cause an adoption problem. If you create barriers of entry and the governance model you propose to place a different group in control — apps will find an alternative where they’re not stripped of power.
How do Blockchain Infrastructure Projects Avoid Forks?
There are four main strategies blockchain infrastructures use to dis-incentivize forks:
- Legal: Hashgraph uses patents and intellectual property protection to prevent users from forking. But if apps can find another reasonably similar blockchain solution, those app developers might avoid one so restrictive.
- Security: Proof-of-Work networks like Bitcoin correlate security with hash power, so a fork would not maintain the hash power of the original network, and thus neither the security. But projects like EOS and Stellar are moving away from PoW and using fewer nodes.
- Lock-in: Networks like Ethereum require users to maintain a balance of Ether to pay infrastructure fees. With so many users invested in Ether, it might be hard for apps to migrate to alternative blockchains. But ultimately, migration to a better infrastructure will draw apps anyway because of the competitive advantage it provides. Also, apps will want users to adopt the app’s own token.
- Thriving ecosystem: Having an established standard like the ERC20 token makes it difficult to choose to move to something else that is less integrated across trading markets. But Kin circumvented this by running Ethereum and Stellar side by side. It is possible to allow different target audiences of the token (professionals vs. consumers in this case) to rely on different blockchain implementations according to their needs, and switch between implementations seamlessly with technologies like atomic swap.
So What’s the Best Way to Avoid Forks?
It’s actually very straight forward — just don’t give apps any incentive to fork. Forking the infrastructure is always going to have a price. Owning the responsibility for maintaining a working blockchain infrastructure environment takes a toll. Security and scalability are issues that entire dedicated projects are focused on. Keeping up with the latest infrastructure technology advancements in a world as dynamic as blockchain development is difficult even for teams focused on that very task. Apps will always have a hard time doing this themselves.
Take a look at centralized infrastructures like AWS, Microsoft Azure and Google Cloud. Why don’t centralized apps “fork” them and maintain their own infrastructure data centers? Well, they used to initially, but now it’s actually cheaper not to. An app will always prefer to focus on its core business as long as it doesn’t gain anything significant by doing something else. In the case of AWS, cloud providers have become so efficient that delegating the infrastructure task to them makes more business sense. Practically every modern centralized app today, Kik included, is running on third-party cloud infrastructure.
This is exactly the approach we’re taking in Orbs. There is no benefit for apps in forking Orbs. Apps are already in control, isolated from one another with virtual chains. There are other critical incentives not to fork. A specialized ecosystem of contributors maintaining the latest version of the protocol and keeping up with the latest infrastructure requirements — issues like privacy and aggressive sharding that next generation solutions are only starting to address; i.e., a network that improves its security as more apps join it.
