Application-specific blockchains, commonly known as appchains, are starting to see significant traction as developers seek to escape the constraints of existing smart contract platforms.
The allure is clear: with appchains, you get to control every detail of interacting with your dApp, notably the gas mechanics, consensus mechanism, choice of smart contract virtual machine, etc.
Plus, new blockchain architectures are generally more scalable and enable some really cool things that were never possible with legacy systems.
The most common architectures include the Cosmos SDK, Substrate (the “engine” behind Polkadot), and Ethereum-based Rollups. Each approach has its benefits and drawbacks, but one constant remains: they’re not for the faint of heart.
For now, developing custom chains remains a complex and costly task, so make sure that the benefits of having your own block space outweigh the costs required to set it up.
Thankfully, as teams continue developing new infrastructure solutions, implementing custom blockchain should become ever simpler. Let’s dive into some of the leading solutions in the market to create an application-specific blockchain implementation!
Cosmos SDK: Low-Level and Powerful but Complex
The Cosmos SDK is a module-based kit that offers developers an interface to build blockchains using the Tendermint consensus (or Proof-of-Authority if desired).
By mixing and matching custom-built and existing modules, developers can fine-tune the user experience and implement full-on dApps as native blockchain features. The most notable examples are smart contract chains such as Evmos or Canto, appchain exchanges like Osmosis and Injective, and over 30 more chains.
The pre-built modules in Cosmos SDK are very low-level, including very basic features like authentication (wallet management), token transfers, governance, fee settings, fraud prevention, or halting systems.
There’s virtually no limit to what you can build with the modules, but oftentimes everything will need to be done from scratch. There are some community-built modules, like Evmos’s EVM module that supports deploying the popular Ethereum-like smart contract environment.
The Cosmos SDK requires developing in Go, which means that your team will need to have a strong foundation in the language to use the SDK effectively.
Consensus and Security with Independent Cosmos Chains
Cosmos chains use an independent security model where each chain is its own sovereign island of PoS consensus. This is a double-edged sword: you have complete freedom to create your own tokenomics, but if you’re just starting out, there’s nobody bigger to rely on for your chain’s security.
A notable example of the dangers related to independent security is the Terra crash. Because of the specific mechanics of the chain and the UST token, the network and staking token (LUNA) became virtually worthless. This forced the entire blockchain to be halted, which included a vibrant ecosystem of DeFi and NFT projects who benefited from UST activity but were otherwise unrelated to the “stablecoin.”
In general, there is no “bootstrapping” in Cosmos: you need to rally support from the ecosystem’s validators, which are often large companies that will likely engage only with very well-funded projects who can guarantee a minimum value and liquidity to the staking token.
The Independent-Minded Community and Ecosystem in Cosmos
The Cosmos community is somewhat unique. While Cosmos chains often have some degree of cross-collaboration, developers are usually on their own in terms of creating and maintaining their appchains. Each use case typically has its own chain, and it's rare to find infrastructure projects within the Cosmos ecosystem.
However, interoperability is possible through the Inter-Blockchain Communication protocol or IBC. While IBC is a generalized interface for communicating any kind of data, the largest use case, for now, is bridging tokens between Cosmos chains and “The Hub” (home of the ATOM token).
Substrate: Maximum Flexibility and Power, but Steep Learning Curve
Substrate, the Rust-based framework used to build blockchains on the Polkadot and Kusama networks, is also a type of modular SDK. It offers a great balance of flexibility, customizability, and plug & play support.
Substrate modules are called “pallets.” Integrated (FRAME) pallets include a good number of extra features that can save up on development time. Besides basic blockchain architecture pallets, you also have your on-chain randomness pallets, multiple consensus implementations (including Aura and Polkadot’s BABE and Grandpa algorithms), atomic swaps, vesting, multi-sig, governance and smart contract pallets supporting WebAssembly and the EVM.
Substrate also includes a lot of unique native capabilities, such as off-chain workers (essentially, customizable oracles), the XCM messaging protocol, and a comprehensive set of governance, election, and blockchain update management pallets. Because of the richness of features, developing in Substrate takes a while to get used to. Once you do, though, the possibilities are endless.
Substrate’s Parachains and Other Choices of Consensus Model
Substrate has no limitations on the consensus system you can implement. Unlike with Cosmos, you can use both independent and shared security models powered by the Polkadot Relay Chain (or even Ethereum).
To implement an independent chain, you can freely use the consensus mechanism used in Polkadot by taking the BABE and GRANDPA modules. These are two synergistic consensus engines, with BABE responsible for block production, while GRANDPA is a checkpointing system used to finalize blocks. You will need to search for full-on validators, just like with Cosmos.
To implement a shared security blockchain, you can rely on Kusama or Polkadot and join either (or both) of the networks as a parachain or parathread.
Parachains are obtained through a lease mechanic: you must bond some KSM or DOT to secure a lease lasting from a few months to a few years. Usually, projects will source the bond from the community in exchange for the project’s tokens via crowdloans, which can be a useful marketing tactic.
Parachains do have a set of Collators who build the blocks of your chain — basically equivalent to rollup sequencers. Some recruitment is required, but setting up collators is generally easier, and there are quite a few community-run collators you could reach out to. If you don’t care about decentralizing collators too much, it’s also possible to run at least some of these in-house, as they don’t participate in consensus, only in the liveness of the chain.
Source: Polkadot (https://polkadot.com/)
Parathreads are instead a “pay-as-you-go” model where you connect to the Relay Chain by regularly paying some amount in DOT or KSM. So far, though, parathreads have been primarily used for “testnets” and as a “waiting room” for becoming a parachain.
The United and Collaborative Polkadot Community
The Polkadot ecosystem is much more unified than Cosmos, and there is a lot of value derived from interacting with other parachains. For example, the OAK Network parachain is designed to execute event-based transactions for other parachains, which can be incredibly useful to respond to changes without requiring constant “poke” transactions to trigger functions.
Interoperability is achieved by connecting to the Relay Chain as a parachain, though a “horizontal” model is also in the works. Thanks to the XCM messaging protocol, developers are actively creating cross-chain smart contract interactions, such as the aforementioned OAK Network.
Setting up a parachain does usually require some community support, but this is also positive: you have a clear set of first community members and users, and they’re quite easy to reach.
Custom-Built Rollups: Easy Ethereum Integration, but Almost no Customizability
Layer 2 (L2) rollups are an emerging solution for scaling Ethereum, but the space is still immature, with no production-ready solutions for building custom appchains.
Right now, rollups are basically just fresh EVM space that you or others get to fill with dApps.
Developers can fork existing L2s like Optimism to create their own rollups, but as it’s not an SDK, you really shouldn’t be changing anything (for your own good).
So, UX improvements like paying for gas with any token require complex smart contract setups (similarly to Ethereum), and you can forget about making custom native dApps.
In theory, rollups can be expanded to become full application-specific chains, with projects like Celestia working towards making this a reality. But it’ll take a bit longer to see this work in practice.
The Different Ways of Using Ethereum’s Consensus
Rollups borrow the security from Ethereum — their basic principle is that the Ethereum EVM is able to verify state transitions from the rollup, so the only way to compromise a rollup is to compromise Ethereum mainnet itself.
The biggest difference lies in how the state transitions are verified. Optimistic rollups operate on a “valid by default” principle and allow a complex fraud-proof mechanism in case anyone tries to submit an invalid state. Because of the need for a challenge period, optimistic rollup blocks are only technically finalized after 7 days.
zkRollups instead post compressed (or pruned) zero-knowledge proofs of the transactions to the Ethereum blockchain, meaning that all transactions are fully finalized after just a few minutes.
Both types have a block builder called sequencer, which accepts user transactions and “sequences” the rollup’s blocks. Currently, sequencers are mostly centralized and require a beefy infrastructure set up by the team.
Easy Onboarding of the Ethereum Community, But Limited Interaction
Interoperability is a weak point for rollups, especially optimistic rollups. Because of their finality delay (the withdrawal window of a few days), any kind of native interoperability use case will also suffer this restriction. This doesn’t apply to zkRollups, but they are only just entering production.
There are also no dedicated communication protocols for rollups, leaving bridge providers like Wormhole and Axelar as the only option for interoperability, which don’t have the same security guarantees as native protocols.
The community and business perspective is probably the most compelling aspect of building a rollup “appchain.” Sharing security with ETH and creating a native bridge for it means that the large Ethereum community will have easy access to your chain. Still, the competition between different layer-two platforms is fierce, and crafting a unique selling proposition is not easy.
So, which one should you use for blockchain implementation?
As always with this kind of thing, the answer will depend on your background and needs.
Cosmos is a good pick for established projects who don’t mind the “rugged individualist” vibe of the Cosmos ecosystem. The Cosmos SDK has been successfully adopted by many such projects, including the original Binance Chain, dYdX, Osmosis and others.
From a development and set up perspective, Cosmos is the most resource-intensive by far, and there are few development shortcuts available. But if you have a capable Golang team and a large warchest, Cosmos is a great choice for building a “sovereign but connected” chain thanks to its IBC model.
Right now, Rollups are hardly even an option for building application-specific chains, since all you’re doing is creating more EVM block space. If you’re a large team who’s interested in creating your own DeFi/NFT playground (say, you’re Coinbase), rollups are great.
If you’re developing an app, you’re still going to be building it fully in Solidity, and at that point there’s no advantage to building it on your own rollup — best use an already established one.
Substrate is likely the best option for small-to-midsize teams, especially if they’re already familiar with Rust. There are many tools out-of-the-box, and creating your own custom chain is relatively simple. Security is taken care of through the parachain mechanism, and on Kusama in particular, they can be acquired with minimal effort. If you have very cool and innovative ideas, Substrate is probably the best tool for it.
A word of advice though: though Substrate is without question the most complete and flexible framework out there, it is also a Herculean effort that has yet to reach full maturity. Because of this, developing features “outside the beaten path” on Substrate can be somewhat difficult, and there are still some setup costs involved with block explorers, collators, and governance. Thankfully, this state of affairs won’t last for much longer…
Comments