Why application-specific blockchains make sense
Cosmos enables developers to easily build and deploy scalable and interoperable application-specific blockchains. But what are application-specific blockchains exactly, and why should you consider building your decentralised application as an application-specific blockchain?
What are application-specific blockchains?
Today, most decentralised applications are developed on top of an existing blockchain like Ethereum. That is because for a long time, it was the easiest and most practical way to develop decentralised applications.
Tendermint and Cosmos propose another way to build decentralised applications. Instead of having the application part of the blockchain be a Virtual-machine and decentralised applications built on top of it, Cosmos facilitates the development of decentralised application as the application of the blockchain itself. This is what we call an application-specific blockchain.
The main reason why application-specific blockchains did not really blow up until now is because it was very hard to build a blockchain. Most people who wanted to had to fork the codebase of an existing blockchain like Bitcoin. But not anymore. With Tendermint and the Cosmos-SDK, building a blockchain is now as easy as coding a few modules. I encourage you to read this page, which goes deeper on these concepts, before continuing this blog post.
Now that we know what application-specific blockchains are, let us understand why, in many cases, it makes more sense to develop a decentralised application as an application-specific blockchain rather than on top of a Virtual-machine blockchain.
Performance
As explained in the aforementioned article, a blockchain can be divided in three layers: networking, consensus and application. The Tendermint consensus engine, which implements the networking and consensus layers, can handle thousands of transactions per second. The real bottleneck is the application.
Developing your decentralised application as a blockchain means you only have to define the transaction types and state transition functions that your application needs. This will greatly increase the application’s performance.
Security
The attack-surface of a Virtual-machine blockchain is large. Most of it comes from the complexity of the Virtual-machine itself. The security analysis is simpler in application-specific blockchains because you only have to consider how the different parts of your application interact with each other. You don’t have to worry about the interactions between the application and the Virtual-machine mechanics. The complexity of the Virtual-machine mechanics is usually the cause of bugs like call stack limit (DAOBug), DelegateCall (Parity Bug #1), contract suicide (Parity Bug #2), etc.
The Cosmos-SDK offers another approach to security, notably based on the notion of object capabilities. Note that no framework can completely protect developers from introducing breaches in their application. In the end, it is the responsibility of application developers to make sure nothing bad happens. Note though that application-specific blockchains might offer more recoverability options in case something bad does happen (see next section).
Sovereignty
When developing an application-specific blockchain, you can decide to deploy it as a public (Proof-Of-Stake) or private (Proof-Of-Authority) chain. In both cases, validators only validate transactions specific to the application. This means that governance is compartmented to your application, and does not overlap with other applications. If there is a problem with your application, governance can fix it without impeding on any other application in the ecosystem.
On the other hand, if a problem arises in a decentralised application built on top of a Virtual-machine, nothing can be done to fix it if the governance of the underlying chains does not consent to it. For example, if a decentralised application built on Ethereum is hacked and funds are stolen, it won’t be possible to repair the damages if the Ethereum community does not want it. This happened recently with the Parity multisig hack.
Flexibility
Developers building on top of Virtual-machine blockchains are limited by the development environment of the underlying blockchain. For Ethereum developers, this means they have to choose between the limited number of programming languages that are available like Solidity or Serpent. Furthermore, they are limited by the constraints imposed by the Virtual-machine itself. For example, most Virtual-machine blockchains do not allow automatic state transitions. Every state transition has to be triggered by an end-user sending a transaction. While this constraint makes sense if you are building on a Virtual-machine blockchain, it still creates limitations for developers that can be bothersome.
Application-specific blockchains provide more flexibility. First, developers can choose the programming language they prefer. In Cosmos, this is true if they build their blockchain as an ABCI-application on top of Tendermint. However, building an application from scratch can be difficult. This is why the Cosmos-SDK exists. For now, it is only available in Golang. But in the future, we expect SDKs in other language to emerge. Other frameworks also exist, such as LotionJS, which allows developers to build their Tendermint blockchain application in Javascript.
Another example of the flexibility application-specific blockchains provide to developers is the ability to trigger automatic state-transitions. The ABCI has two messages called BeginBlock and EndBlock. BeginBlock() and EndBlock() functions are automatically executed at the beginning and end of each block. Developers must be careful not to include logic that is too computationally expensive or would expose the application to never-ending loop but, if done properly, this can be a very useful ability.
Virtual-machine blockchains also have strong use cases
We have presented some advantages that application-specific blockchains can provide. But this does not mean that no decentralised application should be built on top of a Virtual-machine blockchain. Each framework has its strength and weaknesses, and developers have to go for the one that is best suited for their specific use case. Next are a few cases where building on top of a Virtual-machine blockchain make sense:
- Small, low usage application or prototypes. Virtual-machines are super practical and user-friendly. They allow developers to deploy decentralised applications in minutes, which is very convenient when the application is not too complex or meant as a proof of concept.
- If you do not want to deploy a validator set for your application. Virtual-machine blockchains run the consensus for you, the application-developer, so that you don’t have to worry about deploying a network. Note that in the future Cosmos will support shared-validator set, allowing developers to deploy applications without needing to support validators.
- If your end-users need to add custom logic to the application for their own usage.
Conclusion
Application-specific blockchains have been under the radar until now, due to the difficulty of building them. But with Cosmos, it is now possible to easily develop interoperable and scalable application-specific blockchains. You can start building your decentralized application on the Cosmos-SDK today.
Social Channels
If you have general questions, ask them on:
- Telegram: t.me/CosmosProject
- Reddit: reddit.com/r/CosmosNetwork
If you’re thinking about becoming a validator, visit:
- Discord: forum.cosmos.network
If you’re thinking about building an application-specific blockchain and have technical usage questions, ask them on Riot:
- Riot: riot.cosmos.network
If you just want to be entertained or to absorb knowledge, your best resources are:
- YouTube: youtu.be/CosmosNetwork
- Twitter: twitter.com/cosmos
