The idea of releasing a new currency as a mechanism for funding protocol development is perhaps one of the most interesting economic innovations to come out of the cryptocurrency space. In the past twenty years, we have seen a growing centralization in the protocols that underlie the internet, with the rise of proprietary chat systems and social networks like Facebook, and a large part of the reason for this trend has been the need for monetization; if Facebook was cryptographically secure and decentralized, the developers would have no way to make money by data mining their users’ activities and taking a 30% cut of their internal currency, and so decentralized alternatives to Facebook have largely fizzled due to lack of institutional support and funding. With decentralized protocols, however, we have discovered a new mechanism for monetizing them: create internal assets, and sell them to pay for the development of the protocol.
In general, so far we know of two classes of “internal assets” that can be sold in this way; first, there is the idea of creating an internal token system, a crypto-fuel with a floating price that has some value in the network, and second, one can introduce name registrations; for example, a decentralized Twitter might fund itself by building in its own decentralized username registration mechanism similar to Namecoin and selling off the 1-4 letter names. This new monetization model is powerful, and in the first of the two above-described implementations already has a number of proven successes, but it is also incredibly non-intrusive – it requires no licensing schemes, proprietary software, crippleware or privacy infringement, and in fact no one actually has to explicitly “pay” for anything at all (if you buy tokens you are just swapping into a different asset, which can easily hold its value against other assets). However, in this model there is one concern that many people have raised, and that is the question of forks. In short, if one releases a new decentralized protocol that is based on a token system, why won’t someone else release a fork with either their own token system, or a token system that is somehow tied to an asset with an existing userbase, and if one releases a decentralized Twitter with a built-in name registration system why won’t someone release a fork that points to their own name registration system, or even the original Namecoin?
In traditional business, there are two solutions to the problem. One is to give up the idea of making everything open-source, and keep at least the latest version of the client proprietary. The other is to release the protocol for free, and then sell services. Of course, both approaches have their own very well-understood flaws. In the context of a decentralized blockchain application, most of the benefits of decentralization are lost when the code becomes proprietary – with a proprietary mining algorithm, for example, there is no way to prove that it does not have a backdoor for its developers, and is therefore equivalent to the developers simply running a centralized server and asking the community to trust them. The second approach, selling services, is also flawed; first, the revenue is in most cases vastly insufficient, and second, it incentivizes the organization to produce only a minimal decentralized protocol in order to then sell centralized services on top, rather than building up an entire decentralized ecosystem.
Many decentralized projects are pursuing neither of these strategies; for example, Ethereum itself is 100% open source, and have been since even before the day that it publicly launched. Many protocol organizations, including our own, are interested in transforming themselves into “decentralized autonomous organizations”, which necessarily implies a very high degree of transparency. Given this, what is a decentralized protocol’s “moat” against forks? What stops another group from taking all of our code and research ready-made and creating their own version of the blockchain, perhaps with one or two superior features (or simply having a large endowment and dumping it all into superior marketing), and taking us over? The question is a difficult one, but it has a number of interesting answers, both in terms of Ethereum specifically and decentralized protocols as a whole.
On Flimsy Moats and Dictators
In order to answer the question, it is important to first understand that, in the space of tech companies and especially social networking startups, a large number of them are literally backed by almost nothing but social consensus. Theoretically, it is entirely possible for all of the employees at Snapchat, Tinder, Twitter or any other such startup to all suddenly agree to quit and start their own business, completely rebuild all of the software from scratch within months, and then immediately proceed to build a superior product. The only reason why such companies have any valuation at all is a set of two coordination problems: the problem of getting all employees to quit at the same time, and the problem of getting all of the customers to simultaneously move over onto the new network. In the context of a service like Dropbox, the latter issue does not exist; because Dropbox is just as useful to each individual if one other person is using it or a million, there is no reason why people can’t move over a few at a time. In the context of a social network, which is useless unless everyone else is already on it, the problem is fundamental.
In the abstract, this may seem like a flimsy justification for why tech companies are valuable; when thinking about something that represents billions of dollars of value, one naturally expects that value to be backed up by something tangible like physical resources or government force, not just some ethereal instantiation of the fact that it’s hard for large groups of people to suddenly move from one social configuration to another. In reality, however, even physical resources and government force are backed by nothing but a social coordination problem – if 70% of the victims of a dictatorship were to simultaneously rise up against their dictator, the government would get toppled pretty quickly, and yet most dictators even running rather brutally oppressive regimes are quite comfortable sitting in their lofty thrones knowing that such a thing will almost certainly not happen.
Given this background in theory, what exactly are the social coordination problems backing up a decentralized blockchain? What exactly is the “moat” that is backing up the value of the “official” Ethereum blockchain or Mastercoin state transition system, and ether as a mechanism of storing value and paying for transaction fees, as opposed to alternate clones like “aethereum“? Specifically, what are the necessary factors that make the original version of a given decentralized protocol superior, when all of its underlying features can easily be cloned, and even improved upon as soon as a group discovers even one flaw in the original (in the case of Bitcoin, for example, one can trivially improve the Bitcoin protocol by removing the requirement for multisig spending transactions to have an extraneous zero in the spending script code, an anti-feature which was introduced accidentally)? As it turns out, there is quite a lot.
Teams
First of all, every project has a core development team. In fact, this aspect is actually stronger in the case of a decentralized token system than a traditional tech company. While in a traditional tech company, there might be only a very small number of people with shares in the company and who are thus incentivized to stick with it and see it succeed, in the case of a decentralized token system there are dozens or even hundreds of people holding tokens associated with the project; in fact, many people actually choose to be paid predominantly in tokens. In the case of Ethereum, for example, the size of the list of people who will be receiving ether as compensation for work done currently stands at sixty-eight, and will increase even further as time goes on. And all of these tokens are, of course, untradeable until the protocol actually launches, so all of the token holders are strongly incentivized to do their best to ensure that the system does as well as possible. Thus, the team, the set of people who know the most about how the protocol works from the experience of having actually developed it, is a decentralized project’s core asset that competitive spinoffs cannot so easily “fork” and replicate, and it is the team that will be responsible for much of the rest of the project’s “moat”.
Network Effects of Exposure
The simplest reason why people will use the original blockchain and not a fork is simple: it’s the default. People hear about Bitcoin first, so they go to bitcoin.org and download the Bitcoin client, and use Bitcoin to buy and sell goods and services, notBitcoin Scrypt. For the same reason, people use the official version of most open-source projects and not any of the thousands of forks, buy music, books and movies instead of trying to download them via torrents, and use popular Bitcoin wallets instead of less popular ones. Any fork of a given protocol necessarily comes after the original, and is therefore much less likely to gain media attention.
Moral Pressure
Another important reason why the original version of a protocol is more likely to gain media attention than a fork is plain old public morality: people believe that the developers of a project deserve to get compensated, and so a fork which is developed with the primary purpose of depriving the developers of compensation is likely to be viewed negatively, or at least less favorably, by many people. This moral effect can be a very powerful one, and contributes heavily to the original protocol’s greater exposure; the best empirical evidence for this is likely the success of services like Netflix over filesharing-based alternatives.
At the same time, however, if the original developers of a protocol start taking development in an undesirable direction (eg. introducing backdoors, introducing excessively intrusive monetization vehicles, or even just being too plain slow), then the moral effect can rapidly turn on its head and even support the first credible effort to try to wrest away a project from its creators; following the prior example, the pertinent example here is the media success of the Pirate Bay and Popcorn Time. Thus, moral pressure can work both for and against a decentralized protocol, and it is the protocol developers’ responsibility to ensure that the community opinion of their project remains positive, and serves as an important check-and-balance to make sure that the core team behind a project continues to move the project forward at a solid pace and in an agreeable direction.
Network Effects of Currency Unit Liquidity
One argument that is often raised against forks of Bitcoin is the idea of liquidity, or specifically market depth: smaller currencies are inherently weaker than larger currencies because there are fewer people buying and selling them, and so you will move the price much more if you try to sell a large amount. However, this argument is only important up to a certain point; once a currency reaches a sufficient size, it has enough market depth to cover all ordinary usage, and so additional depth provides little value. Hence, this network effect provides a moderately strong edge against forks with a new token system, which will have very low market depth to start off, although at the cost of a slight disadvantage against forks that tie in existing large currencies via two-way-pegging mechanisms.
Ecosystemic Network Effects
An important feature of decentralized protocols, and social protocols in general, is that they also build ecosystems. On a social network, for example, there is a one-dimensional network effect: a social network is more useful if more people use it. With a currency, that effect becomes two-dimensional: a currency attracts more users if there are more merchants, and more merchants if there are more users. Once development effort, security and liquidity come into play, this increases to three to six dimensions. All of these interdependencies make it hard for a new version of a social network to bore its way into mainstream acceptance, as initially it starts off with nothing.
In the case of Ethereum, the tightly integrated nature of the currency system actually makes the network effect in some respects highly multi-dimensional. The relevant property of the Ethereum architecture is the first-class-citizen property of contracts: contracts can interact with, send and receive messages from and hold accounts with other contracts much like external accounts can. This allows you to cleverly pull together long chains of contracts and applications, using contracts of different types at each step of the interaction process. For example, I might hold some shares of a decentralized autonomous organization (contract A), where the shares are held on a decentralized market (contract B) in a multisignature account (contract C) for added security. The co-signer of said multisig account is paranoid about quantum computing, so he uses custom cryptography (contract D) based on verifying Lamport signatures for authentication. The organization would then store some of its funds in a USD-pegged asset using a financial derivatives market (contract F) using a combination of centralized and decentralized data feeds (contracts G, H, I), and internally uses a name registration system (contract J) to store all of the functions that it calls. A single transaction may end up calling all of these contracts multiple times.
Liquid markets for on-blockchain assets, liquid markets for message publication, and a robust ecosystem of DAOs, decentralized exchanges, financial markets and data feeds all support each other and make the Ethereum blockchain stronger. The Ethereum blockchain is not just a blockchain; it’s really one large decentralized computer where all of the components are tightly linked together, and each component provides additional tools for other components to play with.
Bugs and Attacks
This is a small point, but an important one. There is always a risk that either the protocol or the client implementation will be flawed in some way. As hard as the Bitcoin developers have tried, the bitcoind source code has had problems crop up over the years, and twice in Bitcoin’s history (specifically, the integer overflow exploit in 2010 and the fork in 2013) such problems have even led to a consensus failure that required manual resolution. In theory, developers of every protocol try as hard as they can to ensure that bugs never happen in the first place. In practice, of course, there is always a chance that something will slip by, the price will start crashing ten or twenty percent within an hour, and it will be up to the developers, the miners and the large businesses to quickly push out and coordinate a fix. Sometimes, such errors may not even be the protocol’s fault; a massive megacorporate or government-sponsored 51% attack or a globally coordinated distributed denial of service on the entire network are also possibilities, and might need special measures to be dealt with. Thus, as decentralized as peer to peer protocols aspire to be, ultimately they do benefit considerably from some degree of institutional support in times of crisis – support that the original developers who understand the protocol and software best are the best-equipped to provide.
Protocol upgrades
Ethereum 1.0 is far from perfect, and between our discussions on the development roadmap and the Hard Problems of Cryptocurrency we have been very open about admitting this. There are plenty of ways that blockchain technology could be improved, ranging from research on price-stabilized currencies to better fee structures, alternative consensus models and, as a holy grail, multi-blockchain architectures or SCIP. However, the intricacies of actually coming up with the math and then implementing these mechanisms, are in many cases even figuring out whether or not they are even possible, are sufficiently complex that we have decided there is a large list of features we are simply not going to do for Ethereum 1.0. To that end, we have established the long-term roadmap that we will release Ethereum 1.0 in Q4 2014 at the latest, and at the same time we have already started to set up efforts to research the kinds of improvements that we can theoretically add, specifically in terms of scalability, with a plan to crystallize them into Ethereum 2.0 at some point around 2016. Ethereum 2.0 will use “ether 2.0″ as its currency, where the main initial mechanism for obtaining a unit of ether 2.0 is simply to provably destroy a unit of ether 1.0.
Thus, the currency inside of a protocol is backed not just by the utility and network effects of the current implementation of that protocol, but also the promise of better future versions of the protocol to come. Of course, cryptocurrency protocols are hard to change, and in practice Bitcoin has proven very difficult to change in the short term, but more large-scale re-architectures are actually somewhat easier to implement than small changes when one looks at the ratio of effort to effect. We have already seen the Master Protocol make several upgrades, and we will likely see Ethereum 2.0, 3.0 and perhaps even further over the next few years and decades.
What’s the Point?
Finally, the most important argument of all is, what’s the point of a fork? In the case of Bitcoin, there are many reasons to fork the code – you might want to add support for more transaction types, change the currency supply, replace the currency with a centralized alternative backed by the US dollar, or change the type of cryptography used. If a protocol is correctly generalized, however, there simply is no way to improve that can’t be replicated inside the protocol itself. For example, if you are using Ripple then you can use Ripple equally easily to store XRP, cryptocurrencies, fiat currencies, local community currencies or Little Bobby’s Magic Token Points. Hence, concerns about optimal monetary policy, politicization or depoliticization of money or many of the other debates surrounding Bitcoin have no bearing on the success of the Ripple protocol itself. In the case of Ethereum, the protocol has a generic programming language, making the system even more malleable: if someone comes up with a blockchain-based system that is better than Ethereum in some fashion (with the exception of secure near-instant block times), then someone else can fork it right back inside of Ethereum itself by simply implementing it as a contract. This fork would immediately benefit from Ethereum’s ecosystemic network effects, allowing users to benefit from both the superior feature and the ability to interface seamlessly and directly with an existing ecosystem of liquid markets, data feeds and DAOs. Using this power of the contract mechanism, Ethereum will be able to contain side-chains of Bitcoin, Litecoin and Dogecoin (yes, even Scrypt-based coins can be turned into side-chains via computational stacktraces and an economically incentivized challenge-response protocol), name registrations, post-quantum cryptography and an unlimited number of other features.
Thus, on the whole decentralized protocols lie in an interesting place in the modern economy. On the one hand, much like Bitcoin itself, they are in a very clear way “backed by nothing”. On the other hand, they actually have quite a powerful backing underneath, and one that is difficult to unseat; in practice, we have seen very few examples of any open source software fork unseating the original, both in the cryptocurrency space and outside of it. Nothing has unseated Bitcoin, nothing has unseated Litecoin and nothing has unseated Dogecoin. The only forks that do gain serious community acceptance are the ones that add a large body of new features, and these forks always succeed in carving out a niche of their own. Fortunately, we still have many decades to go in seeing exactly how the decentralized protocol ecosystem is going to play out.
