What prevents the validators from voting on increasing fees tomorrow? Well, nothing theoretically. If higher fees work in their best interest, they are free to increase them to the detriment of the apps running on top.
What does this mean for blockchain design?
Making protocol decisions that work against the interest of apps is likely to cause an adoption problem. If the fees you charge for infrastructure are too high — apps will find a cheaper alternative. If you create barriers of entry, like forcing apps to buy stake upfront and be locked-in to a specific project — apps will find an alternative that doesn’t have this lock-in. If the governance model you propose places a different group in control — apps will find an alternative where they’re not stripped of power.
This understanding is one of the core principles upon which Orbs is designed. The Orbs blockchain places apps in control and works together with these apps to make sure the protocol evolves according to their best interest, all while still enjoying the benefits of a completely decentralized environment.
Governance on Orbs is performed using a permissionless federation where any app can join and take part in making protocol decisions. The model is built to strip power both from miners who have a hash power advantage over apps and from financial power groups who have more control over stake than apps. Infrastructure fees on Orbs are designed to be the lowest possible, pegged to the actual infrastructure cost. In addition to the use of a subscription model and monthly billing for transactions, this avoids the issue of fluctuating gas costs.
How do blockchain infrastructure projects avoid forks?
Some infrastructure projects create barriers to make forks difficult. A good example is Hashgraph where patents and intellectual property protections prevent users from forking the protocol. How will this strategy fair with apps? As long as apps will be able to find a parallel solution that provides roughly the same abilities, they are likely to prefer the solution without lock-in.
Take a look at the Windows vs. Linux battle for servers and cloud computing. Initially, Microsoft Windows had a performance advantage due to the large corporate funding its development. Ultimately, it was only a matter of time until Linux caught up. The Linux permissive license, freedom of use, open source code base and lack of lock-in ultimately crowned it as the undisputed king of cloud computing.
Another popular method of reducing the incentive to fork revolves around security. This is premise of many PoW networks like Bitcoin. The security of the network is directly related to the amount of hash power. Forking the project will not maintain the hash power of the original network, making the more popular fork significantly more secure.
This method works well for use cases where Proof of Work is a good fit — store of value for example like Bitcoin. It seems that practically none of the next generation projects aimed for large scale consumer apps is based on PoW. It’s evident that there are other means of securing these networks that are easier to scale. EOS and Stellar, for example, are only running with a couple of dozen of nodes and presumably are secure enough without PoW. Forking these systems will not have a great impact on their degree of security.
A different tactic for avoiding infrastructure forks by apps is creating lock-in with methods like placing the infrastructure token in the hands of end users. This is the case with Ethereum for example. For an end user to use an app over Ethereum, they must keep an Ether balance and pay the infrastructure fee directly. If an app wants to migrate away from Ethereum, it will have difficulty to do so because its user base now has a stake in Ether.
Creating infrastructure lock-in for apps is a very dangerous approach. The best interest of a consumer app is maintaining its freedom of choice regarding infrastructure. If a better infrastructure solution pops up, the apps that will migrate to it will gain a competitive advantage over those who can’t. In addition, apps are likely to want their user base to adopt their own application token and not the infrastructure’s.
Another incentive for avoiding forks is a thriving ecosystem. This is mostly relevant if you’re aiming for professional traders, investors and the secondary market. Take Ethereum’s ERC20 standard, for example. It’s well integrated in exchanges and wallets. Switching an app token to run over a solution that is less integrated in this space will have an impact on liquidity and professional trade.
This also appears to make little difference with apps today. Kin has chosen to launch digital services on Stellar although Stellar has a significantly smaller integration ecosystem for secondary tokens. How did Kin avoid the impact on liquidity and professional trade? 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. Professional traders aren’t the typcial end users of mass market consumer apps and their needs can be addressed by using Ethereum in parallel.
So what’s the best way to avoid forks?
Forking the infrastructure is always going to have a price. Owning the responsibility for maintaining a working blockchain infrastructure environment takes a toll. It requires focus and effort as this isn’t a small task. Security and scalability are issues that entire dedicated projects are focused on. Keeping up with the latest infrastructure technology advancements of this crazy space is even difficult for teams that were formed for this sole purpose. Apps will always have a hard time doing this in parallel to focusing on development of their app itself.
Take a look at centralized infrastructure solutions — platforms 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 for example, cloud providers have become so efficient that delegating the infrastructure task to them makes more business sense. Practically every modern centralized app today, Kik Messenger included, is running on third-party cloud infrastructure.