App-Specific Chains – Modular Times Ahead?
Diving into modular app-specific blockchains, what they are, how they work and what benefits they have over building applications on existing blockchains
The majority of Decentralized Applications available today are built using smart contracts on top of existing blockchains such as Ethereum, Avalanche, Solana, etc. Smart contracts built on the same blockchains would then be a part of a shared environment. Now this process is alright, but it has a few drawbacks that can certainly be better improved upon. Let’s dive in…
Shortcomings
Building complex decentralized applications using smart contracts developed on top of existing blockchains isn’t perfect, and could even be considered as sub-optimal. Here’s why:
Lack of Flexibility
Smart contracts are often developed with a specific blockchain in mind. By building smart contracts with a specific blockchain, and thus a specific programming language and virtual machine, in mind, the smart contract would then be limited to the capabilities of the underlying blockchain itself. For example, if a smart contract is built on the Ethereum Virtual Machine (EVM), the smart contract itself would inherit whatever limitations the EVM has.
Lack of Sovereignty
Smart contracts that run on a shared environment face limited sovereignty. For example, if the developers or community wanted to do a fork or wanted to upgrade their smart contract, they would have to coordinate with and depend upon the underlying blockchain’s governance.
Sub-Optimal Performance
All smart contracts in the same blockchain are run by the same Virtual Machine. These smart contracts would then have to compete and “fight” with each other for an allocation of resources from the VM, which would then constrain the VM itself, limiting its performance, eventually leading to high gas fees and network usability issues.
Application-specific blockchains address these shortcomings.
Application-Specific Blockchains
What are they?
App-specific Blockchains are customized blockchains made for one specific decentralized application.
In this article, I’ll be talking about modular app-specific blockchains in particular
Modular app-specific blockchains are customized MODULAR blockchains made for one specific decentralized application. They are built using modular architecture where the consensus and Data Availability functions are separated from the Execution function. An example of modular app-specific chains would be app-specific chains built on something like Celestia. A more in-depth explanation on modular architecture can be found here.
Why modular app-specific chains?
Traditional app-specific chains requires you to build every part of your own customized blockchain, that would mean building every single component including consensus, execution and data availability all from the ground up. This would obviously require a lot of resources.
For modular app-specific blockchains, you’d only need to build its execution layer which you can then plug into something like Celestia for its consensus and data availability layer. This saves time, resources and bootstrapping costs while also providing the modular app-specific blockchain with the benefits that Celestia itself offers.
Addressing Shortcomings
On top of the improved scalability and resource efficiency components of modular architecture, modular app-specific blockchains also address the shortcomings of building on a shared environment that were previously mentioned and have a multitude of other benefits over building dApps on existing blockchains.
With modular app-specific blockchains that live natively on a data availability layer, such is the case if Celestia is used, devs can then build custom virtual machines with any network in mind. Cosmos SDK, Substrate, Weave, anything they want, it's their choice. This immediately solves the first problem mentioned before, which was flexibility.
Since dApps on modular app-specific blockchains are not reliant on a shared environment’s governance, the devs and community of the dApp would then have significantly greater authority and sovereignty. They would not have to wait for an approval from an underlying blockchain’s governance if they wanted to make a decision. For example, if the devs or community wanted to fork or upgrade their dApp, instead of having to wait and be dependent on an underlying blockchain’s governance, modular app-specific chains allows you to do this without having to wait for any underlying environment’s governance. An example of this would be how dApps on Celestia would not need consent from Celestia itself if they wanted to do a fork. Therefore the sovereignty problem is solved.
Modular app-specific chains also allows a dApp to maximize its performance without having to worry about the constraints of its underlying environment. dApps on a modular app-specific chain would never have to compete for an allocation of resources on they’re blockchain, unlike on a shared environment.
Trust-minimized Cross-Chain Communication
Another benefit of modular app-specific chains that I wanted to emphasize on is something called trust-minimized cross-chain communication between “clusters”.
Cross-chain communication is the exchanging, reading and writing of data between different chains. It’s basically multi-chain interoperability. It’s how different chains such as Ethereum, Solana and Avalanche communicate and interact with each other.
Okay so, every chain can perform cross-chain communication, whether it be Ethereum to Solana, Ethereum to Polygon, Solana to Avalanche, etc. This is done by using something called trust-based assumptions, where you assume and trust that the chain you are communicating with is honest, reliable and will not steal your funds. This entire process is what’s called trust-based communication and actually poses some risks and is not entirely secure as you are dependent on the honesty and reliability of the chain you are communicating with. Here’s a simple illustration to help you get a better understanding of this concept.
Let’s use a case study of bridging between Ethereum and Polygon. When you bridge from Ethereum to Polygon, the flow of your funds will be from the Ethereum chain to a bridge, then into the Polygon chain. See how, in this entire process, you are trusting the polygon-eth bridge you’re using to keep your funds safe and to not steal your funds. This process is trust-based as the polygon-eth bridge is a committee-based bridge that uses trust assumptions that requires an honest majority assumption to sign off on communication. This poses a big security problem because you are exposing your funds to the bridge, and in a worst case scenario, your funds get stolen.
Now, there is another type of communication called trust-minimized communication. This is a type of communication that requires weaker trust assumptions, meaning that it uses an honest minority assumption instead. This would mean that in the case of a dishonest majority in a committee-based bridge, the bridge can still continue to facilitate valid communication. There will then be significantly less security risk or risk that your funds will be stolen.
Now let’s use a case study of bridging between Ethereum and a rollup like Arbitrum. Say you want to bridge your funds from Ethereum mainnet into Arbitrum. Since the main chain, in this case Ethereum, assumes that the transaction is valid, but can also use fraud proofs to indirectly validate the transactions of the rollup, in this case Arbitrum, then you wouldn’t need any trust assumptions for your funds to be safe.
A few paragraphs ago I mentioned something called a “cluster”.
Well, a cluster is a set of chains that communicate with each other with trust-minimized communication. So, referring to the 2 case studies I mentioned before, Ethereum and rollups like Arbitrum, Optimism and zkSync would be one cluster as they communicate with trust-minimized communication. Meanwhile, the other case study of Ethereum and Polygon are 2 separate clusters and cannot be clusters themselves as they communicate with each other using trust-based communication. For a more in-depth explanation on clusters, you can refer to this article.
Now this obviously poses a problem because communication between different chains, like Ethereum to Polygon, Ethereum to Solana, Ethereum to Cosmos, Cosmos to Polygon, etc. uses trust-based communication, which, like I mentioned before, is quite risky and has weaker security guarantees as it requires more trust assumptions.
So, this is what the current landscape of Cross-Chain Communication looks like:
You see how since Ethereum and its rollups communicate with trust-minimized communication, it is one cluster. That cluster, when communicating with other chains like Polygon, then uses trust-based cross-chain communication, which is less secure.
Now the question is how can Cross-Chain Communication be trust-minimized between chains like Ethereum to Polygon, Ethereum to Cosmos or Ethereum to Solana in order to improve security and reduce risk?
Well, any rollup or blockchain that shares a common data availability layer can make trust-minimized bridges with each other, either by fraud/validity proofs or by directly validating the transactions, and a data availability layer is something that Celestia specializes in.
Celestia is a pluggable consensus and data availability layer, meaning that rollups or blockchains that want trust-minimized cross-chain communication can simply plug their execution layer onto Celestia, and voilà, there you have it, trust-minimized cross-chain communication.
Here’s what the landscape of Cross-Chain Communication in the future could look like with Celestia:
So Celestia has the potential to become the core foundation for shared security and trust-minimized interoperability and communication between thousands, if not millions of rollups and blockchains in the future.
Ending Note
To put it into a very simple and watered-down analogy, imagine Lewis Hamilton racing in the Abu Dhabi grand prix with a 98’ Corolla. Could he do it? Yea he could. Could he finish the track? Yea probably. But it wouldn’t be optimal at all would it? A 98’ Corolla might be alright for casual drives around town, but for the specific purpose of finishing the Abu Dhabi grand prix, you’d very much rather use an F1 racing car wouldn’t you?
Well then, building dApps on existing traditional blockchains in this analogy is like using the 98’ Corolla. It can definitely get the job done, but it lacks the performance, safety and a multitude of other benefits when compared to using an F1 racing car, which in this analogy refers to building on a modular app-specific blockchain.
To put it simply, the flexibility, sovereignty, performance and security of a dApp by building on existing traditional blockchains is sub-optimal. Blockchains that communicate with each other using trust-based communication that rely on an honest majority assumption are flawed and face major security risks.
Modular app-specific chains which rely on trust-minimized cross-chain communication solves this by not only greatly improving upon security, it also eliminates any risk associated with funds potentially being stolen.