Bearmint Blog | Learnin' Yer ASBCs...

Howdy to all of you good people once again! We’re halfway through September, and it feels like the end of 2022 is just around the bend! But don’t worry! We here at Bearmint sure ain’t slackin’ off anytime soon and are still very much hard at work gettin’ things ready to go live! Over the past few weeks we’ve discussed various elements related to the world of blockchain, but we’ve yet to truly talk about somethin’ very near and dear to us…

Now you might ask yerself, “Why on Earth would I want to create a blockchain? Can’t I just use smart contracts?” Naturally this particular solution seems logical and straightforward, but you may want to consider some of the significant downsides to usin’ this approach. Today we’ll discuss several reasons why many consider Application-Specific Blockchains (also known as ASBCs) superior to smart contract implementations.

What in Tarnation’s an Application-Specific Blockchain!?

An Application-Specific Blockchain (ASBC) is a blockchain customized in order to drive a single application. Rather than build a decentralized application (dApp) on top of a general purpose blockchain like Ethereum, developers build their own blockchain from scratch. As you can imagine, this means creating all of the underlying architecture (such as nodes, clients and interfaces) and taking the time to ensure they all work together in a seamless and secure system.

However, this is a time-consuming process and one that isn’t particularly easy to pull off without possessing a deeper understanding and knowledge of Web3 technology. That said, ASBCs feature a number of key benefits that make them far more effective than building dApps through the use of smart contracts.

Where Them Smart Contracts Fall Short…

In order to understand smart contracts, you need to give some thought to their origins. In 2014, Virtual-Machine blockchains such as Ethereum provided solutions in terms of the growing demand for programmability. At the time, options for building dApps were highly limited - most developers would either build on top of the very complex Bitcoin scripting language or fork the Bitcoin codebase, which was similarly difficult to work with.

This is where Ethereum provided new opportunities to developers by offering state-machines that incorporate a virtual-machine that can interpret Turing-Complete programs known as smart contracts. While these smart contracts work well for one-off events like Initial Coin Offerings (ICOs), they tend to lack the necessary functionality to build intricate decentralized platforms.

A lack of flexibility - The vast majority of smart contracts use specific programming languages that the underlying virtual-machine is able to interpret. However, typically immature programming languages tend to run into major constraints due to the limited nature of the virtual-machine in question. As an example, Ethereum’s own virtual-machine (known as EVM) doesn’t allow developers to implement the automatic execution of code. In addition, developers must make use of an account-based system that limits their options in terms of available cryptographic operations.
Constrained performance - Given that the same virtual machine runs all smart contracts, they compete for resources, and, as a direct consequence, this negatively affects performance. Even if you split the state-machine into multiple subsets (for example, via sharding), the virtual machine would still handle the smart contracts, meaning the overall problem isn’t really addressed. This inevitability means that your entire application won’t run as required and very likely run into issues when attempting to carry out more complex operations.
A lack of sovereignty - Smart contracts that share the same underlying environment experience major limitations in terms of sovereignty. dApps function as ecosystems with a number of different actors involved in their development and governance. If a dApp is built on top of something like EVM, governance becomes a major issue as the governance of the underlying blockchain (in this case, Ethereum) supersedes any decisions made on the dApp. In other words, if you encounter a bug in the dApp, there’s very little you can do (if anything at all) to address the issue in question.

The Answer? Application-Specific Blockchains, Partners!

With the shortcomings of smart contracts in mind, ASBCs offer a number of key advantages to developers as they don’t suffer from any of the issues encountered using smart contracts on general-purpose blockchains like Ethereum.

Flexibility

With Bearmint, an interface known as the ABCI typically connects the state-machine to the underlying consensus engine. Bearmint makes use of TypeScript, a highly popular and accessible programming language that significantly reduces the difficulty associated with blockchain development and makes the entire development process far more flexible.
Developers can experiment with and implement a range of different consensus mechanisms, transactions and cryptographic algorithms. Even once they have chosen certain parameters, they can modify them so that they perfectly match their unique requirements.
Further to this, developers may explore a number of different trade-offs, such as number of validators versus transaction throughput or safety versus availability in asynchrony.
Unlike smart contracts, developers may implement the automatic execution of code. In Bearmint, it’s possible to automatically trigger logic at the beginning and end of each new block. Developers can also choose which cryptographic library to employ within their application and escape the constraints imposed by general-purpose blockchains such as Ethereum.

Each of the above examples outlines just some of the ways that Bearmint makes blockchain development more flexible and dynamic for developers. While configurability is sacrificed to a degree, this trade-off increases ease-of-use and allows developers to avoid having to consider aspects that really possess little to no utility. By only providing sane conventions, much of the difficulties of needing to fine tune your application practically disappear, allowing you to deploy your work more rapidly.

Performance

If a dApp wants to maximize its overall performance, it must make use of an application-specific blockchain. Again, smart contracts make use of the same virtual-machine, putting significant strain on system resources. The advantages of an ASBC in terms of performance include the following aspects:

With Bearmint, developers can make use of consensus mechanisms that offer significant advantages over Proof-of-Work (PoW) including Proof-of-Stake (PoS), Delegated Proof-of-Stake (DPoS), Nominated Proof-of-Stake (NPoS) and so forth. The result is far less resource consumption and higher levels of throughput.
Since an ASBC only operates a single application, there’s no competition for scarce resources. This greatly enhances performance and prevents any computational errors from arising during the application’s lifecycle.
Even in the event a virtual-machine blockchain allowed for application-based sharding in addition to a resource-efficient consensus mechanism, the virtual-machine would still limit performance. The state-machine is what causes the primary throughput bottleneck, and if a virtual-machine is required to interpret transactions, the computational complexity of processing them increases dramatically.

Security

While quantifying security is a difficult task since it varies significantly from one platform to the next, ASBCs provide several benefits when the integrity of an application is concerned:

While TypeScript isn’t perfect by any means, it’s still significantly more secure than JavaScript and smart contract programming languages such as Solidity which typically lack the requisite level of maturity.
Developers may implement their own custom cryptography and rely on well-curated cryptographic libraries instead of the limited cryptographic functions offered by underlying virtual-machines.
Moreover, developers don’t need to concern themselves with any potential bugs or exploits that the underlying virtual-machine may contain, so this alone significantly bolsters security.
The code underpinning Bearmint is rigorously tested so as to minimize or completely eliminate any bugs or issues that may arise. However, if you do discover a bug or vulnerability, we ask that you notify us immediately so we may address it as soon as possible.

Sovereignty

ASBCs allow developers to maintain sovereignty and exist independently of any other groups that could adversely affect their activities in one or more ways:

dApps exist as ecosystems with many different stakeholders including users, developers, third-party services and so on. When developers choose to build on virtual-machine blockchains where many other dApps also exist, the community that operates in and around their dApp differs from the underlying blockchain’s community, with the latter superseding the process of governance.
With this in mind, if a bug is identified or a new feature is required, a dApp’s stakeholders can do little to upgrade the code. In the event the underlying community’s blockchain refuses to take action, you can bet nothing will happen.
ASBCs solve this issue by operating a single application, allowing all participants to retain full control over the development of the blockchain as a whole. This means that any identified issues won’t pose any major problems and receive the treatment they require in order to dutifully address them. Freedom is paramount for developers, and here at Bearmint, we know that developers deserve to create what they like, whenever they like, without limitations!

Do You Need Any More Convincin’?

Well partners, it’s entirely apparent that ASBCs truly provide the answers yer lookin’ fer! If you want to maximize performance, retain sovereignty, increase security and experience maximum flexibility and ease-of-use, then Bearmint’s the most logical and practical solution fer you to pursue! Should you have any further questions regardin’ ASBCs, please don’t hesitate to get in touch with us so we can assist you accordin’ly!