The majority of Decentralized Applications available today are built with smart contracts deployed on top of existing blockchains (Ethereum, Avalanche, Solana, etc.). Smart contracts built on the same blockchains would then be part of a shared environment. In this article I want to touch up on why this can be better improved upon.

Building complex decentralized applications using smart contracts deployed on top of existing blockchains isn’t perfect, and could even be considered as sub-optimal. Here’s why:

• Lack of Flexibility

  dApps are often developed with a specific blockchain in mind, and thus a specific programming language and virtual machine. The dApp would then be limited to the capabilities of the underlying blockchain itself. For example, dApps built on the Ethereum Virtual Machine (EVM) would inherit whatever limitations the EVM has.

• Lack of Sovereignty

  dApps that run on a shared environment face limited sovereignty. For example, if the devs or community wanted to do a fork or upgrade the smart contract, they would have to coordinate with and depend upon the underlying blockchain’s governance.

• Sub-Optimal Performance

  All dApps 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 issues in gas and network usability

Application-specific blockchains addresses these shortcomings.

Application-Specific Chains are customized blockchains made for one specific decentralized application.

In this article, I’ll be talking about modular app-specific blockchains in particular

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 Celestia. A more in-depth dicussion on Celestia and modular architecture can be found in this article:

https://mirror.xyz/knarb.eth/krxlssV17vl6WnYACRZoBCgzyvIB8m3ogWyWsPaYdEQ

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 from the ground up. This requires a lot of resources.

For modular app-specific blockchains, you’d only need to build the execution layer which you can plug into Celestia for the consensus and data availability layers.

This saves time, resources and costs while providing the benefits that Celestia itself offers.

On top of the improved scalability and resource efficiency, modular app-specific blockchains also address the shortcomings of building on a shared environment and have a multitude of other pros

With modular app-specific blockchains that live natively on a data availability layer, such is the case by using Celestia, devs can 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 previously mentioned, flexibility.

Since dApps on modular app-specific blockchains are not reliant on a shared environment’s governance, devs and the community would 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 devs or the community wanted to fork or upgrade their dApp, modular app-specific chains allows you to do this without having to wait for any underlying blockchain’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 solving the sovereignty problem.

Modular app-specific chains 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.

Cross-chain communication is the exchanging, reading and writing of data between different chains. Another word for it would be multi-chain interoperability. It’s how different chains like Ethereum, Solana and Avalanche are able communicate and interact with each other.

A benefit of modular app-specific chains is trust-minimized cross-chain communication between “clusters”

Clusters are groups of chains that perform trust-minimized communication

Every chain can perform cross-chain communication, whether it’s Ethereum to Solana, Ethereum to Polygon, Solana to Avalanche, etc. This is done by using trust assumptions, where you assume and trust that the chain and bridge you are communicating with is honest, reliable and will not steal your funds. This entire process is what’s called trust-based communication and poses some security risks 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, your funds will flow from the Ethereum chain to a bridge, then into the Polygon chain. See how, in this entire process, you are trusting the Polygon-Ethereum bridge to keep your funds safe and to not steal your funds. This process is trust-based as the bridge is a committee-based bridge which uses trust assumptions that require 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 (Ethereum) assumes that the transaction is valid, but can also use fraud proofs to indirectly validate the transactions of the rollup (Arbitrum), then you wouldn’t need any trust assumptions for your funds to be safe.

A while back I mentioned Clusters

So Ethereum and rollups like Arbitrum, Optimism and zkSync would be one cluster as they communicate with trust-minimized communication. Meanwhile, Ethereum and Polygon are 2 separate clusters as they communicate with each other using trust-based communication (trust assumptions). For a more in-depth explanation on clusters, you can refer to this article:

https://blog.celestia.org/clusters/

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 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 each other with trust-minimized communication, they are in one cluster. That cluster then uses trust-based cross-chain communication when communicating with other chains like Polygon

How can cross-chain communication be trust-minimized in order to reduce security risks?

Any rollup or blockchain that shares a common data availability layer can make trust-minimized bridges with each other, either by fraud proofs, 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 plug their execution layer onto Celestia, and voilà, enjoy trust-minimized cross-chain communication.

Here’s what the landscape of cross-chain communication in the future could look like with Celestia:

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.

By building on existing monolithic blockchains, the flexibility, sovereignty, performance and security of a dApp is far from optimal. Blockchains that communicate using trust-based assumptions relying on honest majority assumptions are flawed and face major security risks.

Modular app-specific chains that rely on trust-minimized cross-chain communication solves this by not only improving upon security, but by also significantly reducing the risk of funds being stolen.

Thanks for reading. And a thank you to Alex Beckett and Nick White for helping with proofreading! If you want to get notified about future posts or give any input/feedback, subscribe and follow me on Twitter. Or don’t. It’s up to you.

subscribe://

This article was first published on 8 February 2022 in Substack. Minor edits were made for formatting.

The majority of Decentralized Applications available today are built with smart contracts deployed on top of existing blockchains (Ethereum, Avalanche, Solana, etc.). Smart contracts built on the same blockchains would then be part of a shared environment. In this article I want to touch up on why this can be better improved upon.

Building complex decentralized applications using smart contracts deployed on top of existing blockchains isn’t perfect, and could even be considered as sub-optimal. Here’s why:

• Lack of Flexibility

  dApps are often developed with a specific blockchain in mind, and thus a specific programming language and virtual machine. The dApp would then be limited to the capabilities of the underlying blockchain itself. For example, dApps built on the Ethereum Virtual Machine (EVM) would inherit whatever limitations the EVM has.

• Lack of Sovereignty

  dApps that run on a shared environment face limited sovereignty. For example, if the devs or community wanted to do a fork or upgrade the smart contract, they would have to coordinate with and depend upon the underlying blockchain’s governance.

• Sub-Optimal Performance

  All dApps 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 issues in gas and network usability

Application-specific blockchains addresses these shortcomings.

Application-Specific Chains are customized blockchains made for one specific decentralized application.

In this article, I’ll be talking about modular app-specific blockchains in particular

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 Celestia. A more in-depth dicussion on Celestia and modular architecture can be found in this article:

https://mirror.xyz/knarb.eth/krxlssV17vl6WnYACRZoBCgzyvIB8m3ogWyWsPaYdEQ

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 from the ground up. This requires a lot of resources.

For modular app-specific blockchains, you’d only need to build the execution layer which you can plug into Celestia for the consensus and data availability layers.

This saves time, resources and costs while providing the benefits that Celestia itself offers.

On top of the improved scalability and resource efficiency, modular app-specific blockchains also address the shortcomings of building on a shared environment and have a multitude of other pros

With modular app-specific blockchains that live natively on a data availability layer, such is the case by using Celestia, devs can 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 previously mentioned, flexibility.

Since dApps on modular app-specific blockchains are not reliant on a shared environment’s governance, devs and the community would 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 devs or the community wanted to fork or upgrade their dApp, modular app-specific chains allows you to do this without having to wait for any underlying blockchain’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 solving the sovereignty problem.

Modular app-specific chains 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.

Cross-chain communication is the exchanging, reading and writing of data between different chains. Another word for it would be multi-chain interoperability. It’s how different chains like Ethereum, Solana and Avalanche are able communicate and interact with each other.

A benefit of modular app-specific chains is trust-minimized cross-chain communication between “clusters”

Clusters are groups of chains that perform trust-minimized communication

Every chain can perform cross-chain communication, whether it’s Ethereum to Solana, Ethereum to Polygon, Solana to Avalanche, etc. This is done by using trust assumptions, where you assume and trust that the chain and bridge you are communicating with is honest, reliable and will not steal your funds. This entire process is what’s called trust-based communication and poses some security risks 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, your funds will flow from the Ethereum chain to a bridge, then into the Polygon chain. See how, in this entire process, you are trusting the Polygon-Ethereum bridge to keep your funds safe and to not steal your funds. This process is trust-based as the bridge is a committee-based bridge which uses trust assumptions that require 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 (Ethereum) assumes that the transaction is valid, but can also use fraud proofs to indirectly validate the transactions of the rollup (Arbitrum), then you wouldn’t need any trust assumptions for your funds to be safe.

A while back I mentioned Clusters

So Ethereum and rollups like Arbitrum, Optimism and zkSync would be one cluster as they communicate with trust-minimized communication. Meanwhile, Ethereum and Polygon are 2 separate clusters as they communicate with each other using trust-based communication (trust assumptions). For a more in-depth explanation on clusters, you can refer to this article:

https://blog.celestia.org/clusters/

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 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 each other with trust-minimized communication, they are in one cluster. That cluster then uses trust-based cross-chain communication when communicating with other chains like Polygon

How can cross-chain communication be trust-minimized in order to reduce security risks?

Any rollup or blockchain that shares a common data availability layer can make trust-minimized bridges with each other, either by fraud proofs, 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 plug their execution layer onto Celestia, and voilà, enjoy trust-minimized cross-chain communication.

Here’s what the landscape of cross-chain communication in the future could look like with Celestia:

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.

By building on existing monolithic blockchains, the flexibility, sovereignty, performance and security of a dApp is far from optimal. Blockchains that communicate using trust-based assumptions relying on honest majority assumptions are flawed and face major security risks.

Modular app-specific chains that rely on trust-minimized cross-chain communication solves this by not only improving upon security, but by also significantly reducing the risk of funds being stolen.

Thanks for reading. And a thank you to Alex Beckett and Nick White for helping with proofreading! If you want to get notified about future posts or give any input/feedback, subscribe and follow me on Twitter. Or don’t. It’s up to you.

subscribe://

This article was first published on 8 February 2022 in Substack. Minor edits were made for formatting.