In this article we will discuss the recent developments in the blockchain space to use modular frameworks to develop and launch blockchain networks, and how this new approach affects the enterprise customers wanting to build permissioned consortia, application-specific chains, or sidechains.
The blockchain industry needs enterprise players to expand on the use cases, while the enterprises need blockchain to solve age-old problems around multi-party work flows and digital asset lifecycle management. So it’s no surprise that the first wave of the blockchain technologies implemented for enterprise usage, in permissioned settings, focused on the core tenets including more efficient consensus algorithms than the proof-of-work kind, controllable participant onboarding, configurable permissioning, and application developer friendliness.
As a result, the industry has seen the emergence of a group of blockchain implementations that make permissioned networks possible, including Quorum, Hyperledger Fabric, R3 Corda and Hyperledger Besu. Each offered a complete set of components that are highly integrated to work together.
While all the above implementations support a highly flexible configuration for runtime parameters, including cryptography algorithms for hashing and digital signatures, consensus algorithms, block capacity, block period, and so on, they are all opinionated about many aspects of the components in the stack.
For instance, all implementations except for Hyperledger Fabric include a fixed runtime engine for executing application-specific transaction processing logic, or smart contracts. Both Quorum and Hyperledger Besu use an Ethereum Virtual Machine (EVM) implementation, while R3 Corda has a deterministic JVM. These smart contract engines dictate the programming languages that a blockchain developer must use for their smart contracts: Solidity for Quorum/Besu and Java for Corda.
On the public blockchain front, most of the ecosystems have focused on perfecting the technology behind their public mainnet, giving less emphasis to supporting the development and deployment of different types of variants. Thus most of the implementations are monolithic and do not have pluggability.
For instance, when the Quorum team at JPMorgan Chase tried to enhance go-ethereum to support enterprise requirements, they had to fork the code, which makes adopting future go-ethereum versions a difficult task, especially when there were extensive code refactorings.
Many blockchain ecosystems have since realized that a single Layer 1 mainnet is not sufficient for scalability. The need to have a Layer 2 became clear. Thus, the need to allow many instances of the protocol to be deployed also came into focus.
The Cosmos and PolkaDot communities were the first to design frameworks that allow customizable blockchain instances to be developed and deployed, with the Cosmos SDK and Substrate respectively.
Other communities are following up with their own frameworks. Polygon, the most popular Layer 2 scaling solution for Ethereum, launched their own technology called Polygon Edge. This can be used to launch a standalone permissioned network, a Layer 2 sidechain under the Ethereum mainnet, or a “Layer 3” sidechain under the Polygon mainnet.
Modularity and pluggability are major themes with these new frameworks. Most of the components that make up the full blockchain stack are pluggable:
On the enterprise side, Hyperledger Fabric is built from the ground up with modularity and pluggability in mind. Most of the components listed above are also pluggable in Fabric.
What are application-specific blockchains and why are they needed?
This term refers to the blockchain networks that are dedicated to a single use case or a small set of highly related use cases. In contrast to a general-purpose blockchain, like most of the Layer 1 public networks, an application-specific blockchain serves a much smaller set of use cases.
Because of the focused set of requirements to fulfill, an application-specific blockchain (or App Chain) has a number of advantages compared to a shared decentralized computing platform like a general-purpose blockchain.
An App Chain can have a virtual machine based runtime to process transactions, or a pre-built runtime entirely bypassing the general purpose smart contract engines that can introduce overhead with abstractions.
All the frameworks mentioned above allow developers to customize the transaction processing runtime entirely. An industry standard platform might choose the former to allow different applications to be deployed in order to accommodate a wide range of use cases, while a gaming company might choose to use a pre-built runtime with fixed logic for its better performance to accommodate high transaction volumes.
An App Chain is given access to the entire set of resources available on the blockchain, without having to share with other applications, similar to a single-tenant centralized application. This way, different applications don’t have to compete for the compute cycles of the shared transaction runtime, making transaction throughput and latency more predictable.
An App Chain can choose the right type of modules most suitable for the use case. Efficient consensus algorithms such as the BFT variants, for example, can be used for higher throughput or in networks with low trust. Low-latency algorithms such as the CFT variants (Raft, for example), might be the right choice in a network with more trust among the participants.
Different types of validator selection schemes can be used, such as proof-of-authority (voting based) and proof-of-stake (staking based), based on the specific onboarding process with the application’s use case.
Runtime aspects like the choices of cryptography, block interval, or block capacity can be tuned to the needs of the application.
Many permissioned blockchain networks implemented by industry consortia are by definition application-specific chains. They tend to focus on specific use cases such as commodity trade, commercial product track and trace, supply chain workflows, and many others.
On the other hand, a number of public blockchains have been built with these modular frameworks. With the Cosmos SDK, the most notable implementation is the BNB Beacon Chain (formerly the Binance Chain), which is the governance layer for the BNB Smart Chain (formerly the Binance Smart Chain). Centrifuge and Tinlake, the famous DeFi platform and marketplace for real-world assets as NFTs, was built with substrate and has recently won the auction to become PolkaDot’s 9th parachain.
It’s worth mentioning that all the frameworks mentioned above have built-in support for cross-chain communications and/or interoperability. This is table stakes in the age of multi-chains and multi-layers.
Through the Inter-Blockchain Communication (IBC) protocol support built-in with the Cosmos SDK, blockchains written in this framework can readily communicate with other blockchains to coordinate cross-chain asset transfers or transaction verifications.
Substrate defines the Cross-Chain Message (XCM) format to allow parachains to talk with each other, parachains to talk with the relay chain, and solo chains (standalone substrate chains that are not attached to a relay chain) to talk with each other or with other non-substrate blockchains.
Besides the low level messaging formats and protocols, there are also higher level constructs available for cross-chain interoperability, including bridges, atomic swaps, rollups and others. Details of these approaches are beyond the scope of this article. However, it’s worth noting that as the App Chains pattern gets adopted more, an interconnected web of blockchains will start to emerge naturally, since, most App Chains will have a need to communicate with other chains in order to allow values to flow back and forth and to allow transactions associated with each other to execute in lock-step. That is the web in Web3.
Can’t wait to give App Chains a try? There are comprehensive documentations for each of the frameworks mentioned above. In particular, for Polygon Edge, commercial platforms like Kaleido makes it a trivial task to stand up an App Chain instance with the flexibility to set up the chain with the desired levels of decentralization.
Your guide to everything from asset tokenization to zero knowledge proofs
Download Now
