Doing one thing is much easier than many things.
Blockchains haven’t gotten broad adoption in the wider world yet. Perhaps it’s because selling platforms are difficult, persuading other developers to build on top of your platform along with all the tooling that must tag along. But there is one class of blockchains that have been doing better at getting traction. These we will call application specific blockchains, protocols developed with one use case in mind. Whether it start with storage (Sia) or currency (Bitcoin) to assets (Stellar) or content publishing (Steemit), what these blockchains have in common is that they were initially built for one purpose only.
Here we will extol the virtues of applications specific blockchains. Focusing on broad categories such as product marketing, engineering and product. But first let’s define an application specific blockchain.
Application Specific Blockchains
Blockchains can be bifurcated into two categories: generalised smart contract platforms and application specific protocols. Ethereum pioneered the former, with a Turing complete scripting language, anything can be built to the limit of imagination of the developer, however this is not without its own set of unique problems. Bitcoin in contrast has a very specific use case, a pure transfer of value. Application specific blockchain have a narrow set of utility, they were designed with one purpose in mind such as:
- Private Compute (Oasis Lab, Ankr)
- AI Compute (Hadron)
- Data Storage (Filecoin + IPFS, Sia, Storj, Maidsafe)
- Data Caching (CacheCash, BloXroute)
- P2P Messaging (Orchid)
- Domain Names (Blockstack, Handshake)
- Assets (Stellar, Ripple, Tari, VGO)
- Financial (Stablecoins [sometimes build on on top of other protocols], Derivatives [Risk Labs, dYdX, etc.], Non-Turing Complete contracts [Kadena’s PACT, BAT scripts])
- Content Publishing (Steemit)
- Proof of Existence (Tieron, Factom)
- Interoperability (Polkadot, Cosmos)
The above blockchains do not have much functionality outside their intended designs, but that’s the goal. It is easy to market a product that does only one or two things, it is faster to develop a product that only does one thing, the blockchain can be product driven, etc.
Product Marketing
A smart contract platform by design is meant to be used as a foundation by many other applications. When designing these systems it is necessary to consider needs of the developers and the end users, to make the features generalisable enough to be suited for a diverse set of applications. Although very versatile, it is often difficult to sell a multi tool that can do everything semi decently. But not one particular role exceptionally well.
With application specific blockchains, they are designed to fix a specific problem. Issues with media platforms censoring your content:use Steemit; afraid of cloud providers spying on your data: use Oasis; concerned about assets depreciating in value: use a stablecoin. All these applications have one sole objective, to fix one problem and do it well. The narrative is simple, use product x to fix problem y.
Selling a multitool is difficult, users often times want a solution that solves a clear organisational or individual problem. There is no need to have a tool that fixes one problem, but then has all these other features that lie dormant. Application blockchains fit this gap neatly. With this focused tool, the narrative is much simpler.
Engineering
An unexpected effect that comes from a focused product is shorter development cycles. Smart contract platforms tend to follow waterfall development, where they are not useful unless they are fully-featured(e.g. can’t have a smart contract language with only half the op_codes implemented). But with application specific protocols, development is more lean. Every week, new features can be pushed out to the network and the protocol is usable from an early start.
By building a protocol to complete a very specific task, there are very clear test cases that can be written that encompass what the protocol should and should not do. The scripting language / OP_CODE set is defined in a way that only provides core utility to the underlying protocol. There is no need for op_codes that are out of band. This reduces the attack surface on the scripting side of things. In general the code base is also smaller, reducing the attack surface.
Want to register a domain on ENS, but there’s a hot ICO going on and the network is congested by an event entirely unrelated to what you’re doing right now? Why should you pay more to register for a domain when you’re the only one doing it? If there were other people registering domains, then yes, it’s okay to pay more; but if others are doing entirely disjoint actions, this is madness. When a protocol only has one function the cost on operating in the network is proportional to how much others want to use it. No longer will one get upset from a user on the other side of a globe participating in the network. Only fight with those who want to do the same action, such as registering a domain on Handshake; if you don’t want to pay more now, simpy wait until later.
Product
Ideally a blockchain should be useful out of the box, with a simple integration or a client installation, one should be able to interact with the network. Unlike general purpose Blockchains, application specific blockchains are built with a product mindset. Given a storage network, storage providers download the client software on their computers and storage users interface with the protocol through an API interface or by running a full node. The UX is clear and straightforward, increasing the adoption rate.
Faster development cycles means faster iteration. Once the product is in users’ hands, protocol developers can understand how the system operates in the wild. What was expected of user development and what was unexpected? What features do users want, what features do they not care about? What crypto economic mechanisms worked, which ones failed. With this model, developers can engineer their protocol to exactly their users wants. Whereas in a generalised blockchain, these iteration cycles take much longer, increasing the time to get to product market fit and giving competitors more time to catch up and get market share.
Governance has been a contested topic these days. Who should be able to vote, how are ballots introduced in the system, what is time frame for changes, how to prevent forking? In blockchains that do many different things, there are many competing interests that are pulling the protocol in different directions. One team wants scalability first, another UX, and a third privacy — where are the developers suppose to spend their time? And what if a dissenting group tries to block a change, does a fork occur? In application specific blockchains, all users are united in a common goal, whether it be in compute or data marketplaces to CDNs or Proof of Existence blockchains. All users generally want the same thing, a more efficient protocol, and are more likely to update their software when new versions come out.
Historically in the startup world, companies don’t go to market with a platform that anyone can build on. The resources to encourage developers to jump on is too great. Instead startups start with a killer app, and if they want to create a platform out of it. Have an amazing messenger app, then why not build a commerce and payment platform into it. The same applies to a blockchain, start with an application specific one, and then try to generalise it.
Future Trends of This Category
Will we see more application specific blockchains in the future? It’s difficult to say, but given their advantages compared to generalised blockchains please be the case. But also blockchains as a whole are trending to become more specific. With the rise of side chains and interoperability such as Tendermint and Substrate, it is foreseeable to have application specific side chains that do not suffer from multi tenancy issues other random applications.
But then again is a sidechain it’s own blockchain or is it a slave to its master?
Further Reading
Misnomer of Application Specific Blockchains
TBH what really is a blockchain, these are just distributed systems with cryptographic primitives and tokens for settlement. Some of these aren’t even blockchains in reality, they don’t have the linked list data structure common in Bitcoin or Ethereum. Application protocols would be a more fitting title but that term is less widespread. And when it comes to financial settlement, it could make sense to use another ledger for security.
Are these just dApps that decided to build their own settlement layer?
