The blockchain ecosystem is complex and ever-evolving, and has recently made incredible strides towards scalability. Modular blockchains bring a number of key benefits, including reduced developer complexity, enhanced scalability and performance, better adaptability, and financial efficiency.
The blockchain ecosystem is complex and ever-evolving, and has recently made incredible strides towards scalability. To keep up this progress, it’s important to clear up the myths about modular blockchains that pop up from time to time.
Modular blockchains bring a number of key benefits to the entire ecosystem, including reduced developer complexity, enhanced scalability and performance, better adaptability, and financial efficiency. They’re specifically designed so components can work together seamlessly, forming a well-integrated system.
Let’s dive in.
One misconception is that modular blockchains may increase complexity for app developers due to multiple components working together.
In fact, in a modular system, a smart contract developer building on a general-purpose L2 has the exact same experience as a smart contract developer building on a monolithic chain. Once the smart contract is deployed on an EVM L2 chain, users only have to send their transactions to the blockchain as they would’ve done if the contract was deployed on a monolithic chain. Any increase in complexity is handled by the rollup/chain developer, not the app developer - and it gives the app developer several advantages in return including flexibility, cost reduction, and more.
What if the project is deployed as an app-specific rollup instead of on top of a general-purpose one?
In a modular ecosystem, underlying complexities further down the stack can be reduced for rollup developers by offering pre-configured chain templates. As an example, if you want to deploy an app rollup today, you can go to a Rollup-as-a-service (RaaS) provider (see Caldera, Altlayer, Opside, Snapchain) and spin it up in one click.
The RaaS provider takes up the complexity and offers it as a service just like hosting a VM on DigitalOcean or deploying a webapp on Heroku. A power user can still take up the entire orchestration which provides more configurability but takes a huge effort to setup and maintain.
Let’s look at a comparison between a project deciding to deploy its own exclusive chain in a Monolithic vs. Modular setting:
CEX and fiat on/off ramps will be easily accessible for app developers on modular blockchains as well. Every major rollup ecosystem on a Layer 1 blockchain (such as Avail) is going to have at least 1 specialized liquidity-focused rollup, that will have:
This liquidity focused rollup (or the Liquidity Hub) will be seamlessly accessible from other rollups via an inexpensive and fast inter-rollup messaging mechanism. Rollup ecosystems built on a shared DA layer will focus on seamless interoperability amongst the rollups themselves as they do not need to cross trust zones.
Good early examples of this model are seen with Osmosis in the Cosmos ecosystem or AssetHub in the Polkadot ecosystem - strictly speaking, these are not rollups, but you can see the general ecosystem design pattern that others are converging on.
There’s a misconception that by separating the functionality of a monolithic blockchain into modular layers will reduce performance, or at least not improve it.
We are now living in a post-zk world, where previously prevalent assumptions about scalability and security no longer hold. Today, execution verification does not require ALL the nodes in the network to re-execute all transactions. Instead, trustless zero-knowledge (ZK) provers can provide validity proofs, which are orders of magnitude cheaper to verify. And validity provers are incredibly parallelizable.
With Data Availability Sampling or in short, DAS (implemented on Avail, Celestia), you don’t need to download all the transaction data to verify data availability (DA). DAS light clients can randomly sample a small fraction of the entire data and very quickly get high probabilistic DA guarantees.
This is an order of magnitude faster and cheaper than downloading ALL the data by EVERY node in the network.
The combination of DAS and recursive validity proofs makes modular blockchains extremely powerful. Any rollup developer can build a completely new chain, even with a centralized sequencer, and users can still be assured of the safety of their funds, assuming the rollup protocol has options built in for escape hatches and based sequencing.
Some additional benefits you get with this are:
Modularity has nothing to do with execution speeds. The Solana VM on a rollup will have the same performance as on a monolithic blockchain. The real benefit of modularity is in optimizing the verification workflow. And it does not even need to have zk/validity proofs. Optimistic or pessimistic rollups also exhibit the same characteristics.
Modular blockchains are more than the sum of their parts.
When working with modular blockchains, there might be a concern about increased cost, but in reality, it’s just the opposite. Monolithic chains have hidden costs and in a multi-chain world, users pay the costs on all the chains.
Let’s look at some data about the actual costs of operating various blockchain networks. The data below is sourced from https://www.stakingrewards.com/
Focus on the right-most column in the table above. As is evident, the costs of bootstrapping and maintaining a blockchain are really high!
Note that inflation rewards to stakers running the network are ultimately paid out from the token holder’s pocket. Token holders subsidize the cost of running the network in the absence of real transaction fees.
Whenever someone wants any flexibility from the protocol rules of a monolithic chain and wants to introduce a new execution environment or a new precompile, the proponents of monolithic blockchains expect them to build a new blockchain by bootstrapping a validator network and token from scratch!
This is limiting the permissionless innovation that is at the core of this industry.
When a rollup is deployed on the same DA layer, it is part of the SAME ledger as an asset on the base layer. In fact, the so-called ‘L2 ledger’ is just a subset of the data entries in the L1 ledger. As Jon explains in this article, there are millions of rollups within each DA layer. In simple terms, a rollup is just ANY subset of the base DA layer.
“There are essentially infinite undiscovered rollups hidden in Ethereum’s data. You can make a rollup to trustlessly read and compute over that data however you want, then you could provably communicate it back. - Jon Charbonneau”
Yes, there are entities specifically focused on maintaining their own L2 ledgers, but all of these ledgers are ultimately just the subsets of the base layer ledgers. This is why L2s inherit the security guarantees from the DA layer that they are deployed on.
On a shared DA layer, token holders of the base layer bootstrap and maintain security. The rollup ecosystem on top does not need to individually manage this. They inherit the security of the base layer.
An idea shared by some that modularizing blockchains leads to lesser liquidity on each ledger is flawed and assumes that modular blockchains aren’t vertically integrated. This argument puts a premium on synchronous composability when most stuff is possible via asynchronous composability. Even the best traditional fintech systems prioritize asynchronous composability. This is what allows Cosmos chains to access the liquidity hub in Osmosis (via IBC) and Ethereum L2 rollups to access liquidity on Ethereum (via trust-minimized bridging).
As modular systems mature, asynchronous messaging via recursive proof aggregation is going to be extremely cheap since client-side validity proof verification is possible via a combination of execution verifiers and efficient DA verification via light clients.
If multiple arbitrage transactions on different rollups are a concern, they are not limited to just modular blockchains. Duplicative computations across asset ledgers can happen even with multiple DeFi protocols on the same layer. If the ETH-USDC price is $1800 on Binance, $1600 on Aave, and $1700 on Compound, this requires two separate arbitrage transactions to resolve.
Multiple arbitrage transactions are not an exclusive function or consequence of modular blockchains.
There’s a misconception that app rollups do not give developers any new avenues for experimentation or monetization. The belief is that existing constructs on monolithic chains give enough tools to perform experimentation or create revenue.
Modular rollups empower developers to work in a variety of execution environments, not only fostering diversity but also presenting cost-saving advantages. Compared to monolithic chains, with their high overheads, app-specific rollups are often more economical and streamlined, removing complexities like managing infrastructures and indexers.
It’s quite clear that applications can capture MEV (in-rollup and cross-chain) if they deploy the app as an app-specific rollup. There’s a misconception that the same can be achieved with monolithic blockchains by adding a few logical changes to the smart contract deployed on a global ‘monolithic’ state machine.
Adding a few logical changes to the smart contract deployed on a global ‘monolithic’ state machine may achieve similar results. But the idea of adhering to a global state model and single VM for execution doesn’t make much sense when there is so much potential for arbitrary execution environments with app rollups. As explained above, some apps might be better suited to a completely different execution environment than the standard EVM or SVM. This is possible with Modular Blockchains, and we think a lot more experimentation with execution environments, ledger authentication, access, custom state models, etc. is required to keep pushing the industry forward.
Taking an analogy from traditional tech stacks, there isn’t any single programming language or one standard way of developing web/mobile apps. Why should blockchains be any different? The diversity of choice and fostering of experimentation which unlocks new monetization opportunities in any industry can be achieved with modular rollups!
In addition to the revenue opportunities, the “costs” of deploying and maintaining an app on a monolithic chain can be much higher than simply deploying an app-specific rollup. Most app developers on a monolithic chain need to manage a ton of infra, indexers, transaction relay providers, RPC full node providers, etc.
Modular structures are able to abstract away this complexity by allowing specialized chains with the right construction (application-specific, custom state transition function, custom state - see Stackr Labs) to bypass these infra management requirements - which is often cheaper than trying to bootstrap everything on a monolithic chain yourself.
Ignoring all these benefits, do we really want to limit developers to the status quo?
The misconception is that monolithic chains have adequate constructs to solve for cross-app congestion, without needing to break into app-specific rollups.
In practice, pricing every resource using the same global fee market puts constraints on the throughput of the entire system. While localized fee markets, as seen in Solana and Aptos, effectively alleviate application-level congestion, they fall short in addressing cross-app congestion.
That is precisely what the developers of modular systems are trying to solve. By deploying an app as an app-specific rollup, projects can get exclusive execution environments and application-specific fee markets.
What happens when there is a spike in prices and congestion at the base layer (either directly or trickled down via some other L2)?
The app-specific rollup can keep operating as normal and stay unaffected if it simply delays posting a batch of transactions on the base layer during such spikes. Users of this app rollup will still be able to get soft finality, even though the ‘hard’ finality might be delayed.
Rollups on a scalable data availability-focused base layer like Avail mitigate this to a large extent by being able to scale DA block sizes with rollup demand.
In a rollup ecosystem that enables asynchronous message passing via recursive proof aggregation, each app can have its own throughput and transaction pricing. They can run at their own pace without having to worry about the other chain it needs to interact with. The async message passing enables verifiable inclusion without synchronicity assumptions and hence allows users far greater flexibility in terms of avoiding shared state access compared to monolithic chains.
The async paradigm enabled by proof aggregation enables you to put transactions in individual chains at different points in time in order to avoid individual chain congestion without sacrificing atomicity or composability between the applications. This provides a richer set of tools to express intents which are extremely limited in synchronous composability between apps on a monolithic chain.
One misconception is that modularity means no vertical integration. It is also thought that the flexibility offered by modular chains are overrated and nothing new needs to be built.
The truth is, modular systems can combine to form vertically integrated stacks, the complexity of which can be abstracted away from the app developers.
The premise of permissionless innovation is to allow app developers to experiment and come up with new ideas while still absorbing high security from the stack on which their apps are deployed. This permissionless-ness can be constrained if the app is deployed on an L1 where the upgrade costs are high.
Modular systems lower the cost of experimenting with new execution environments, new state models, and new access mechanisms. They provide access to lower fees and lower latency. Access to spot DEXs, stablecoins, and fiat on-ramps can be easily implemented via 1 or more liquidity-focused rollups or a liquidity hub as mentioned earlier.
Without experimentation, it is impossible to predict the use cases that can be fostered by a properly implemented modular stack. When the Internet came along, Bill Gates’s best guess of a use case was watching recordings of baseball games. This just goes to show how tough it is to predict the direction a technology will go in without allowing anyone to permission-lessly innovate on it.
There is a misconception that rollups cannot be hard forked. They are tied to the enshrined bridge on the base layer and hard fork would mean the base layer itself has to fork off.
This misconception arises from how rollups are implemented today on Ethereum that combine a bridge to the base layer for L1 assets along with the state verification mechanism. We should not confuse the bridge and the verification mechanics.
The rollup itself can certainly be hard forked, very similar to how L1 forks happen. The bridge itself is a separate construct. Jon Charbonneau explains it pretty well in this post why rollups are not equal to bridges. A rollup is not defined by the bridge and hence the hard fork ability of the bridge on some other chain should not be equated with the hard fork ability of the rollup itself.
A sovereign rollup on Avail can be viewed as similar to any normal blockchain. There are full nodes of the rollup that sync with the rollup node. What happens differently here is that rollup transaction data is also sent to Avail and DA light clients on Avail can then randomly sample the data and verify data availability. These light clients are also embedded in the rollup node to facilitate this process. The major difference in this construction versus Ethereum-style or enshrined settlement layer type rollups is that the rollup nodes and light clients verify the canonical chain without relying on a smart contract based enshrined verification mechanism.
And if people are still unconvinced by the theoretical discussions around it, they can refer to our OpEVM prototype which is a sovereign optimistic chain built on Avail with decentralized sequencer set and permissionless watchtower. It can easily hard fork without changing anything on Avail. It is also good to keep in mind that Avail does not support any smart contract so the rollup does not have an enshrined bridge which gives it sovereignty.
At present, blockchains are a niche industry. We require more users, greater adoption, and expanded use cases than are possible today.
To get there, we’ll need to lower the cost of experimentation and let users and developers make an educated choice of monolithic or modular ecosystems. We hope that in this article, you’ve learned more about the scalable potential for modular systems, and will be better equipped to make that choice yourself when you need to. And with the right tools, we’re sure you will create innovations beyond our imagination.
Let thousands of rollups bloom!
The blockchain ecosystem is complex and ever-evolving, and has recently made incredible strides towards scalability. Modular blockchains bring a number of key benefits, including reduced developer complexity, enhanced scalability and performance, better adaptability, and financial efficiency.
The blockchain ecosystem is complex and ever-evolving, and has recently made incredible strides towards scalability. To keep up this progress, it’s important to clear up the myths about modular blockchains that pop up from time to time.
Modular blockchains bring a number of key benefits to the entire ecosystem, including reduced developer complexity, enhanced scalability and performance, better adaptability, and financial efficiency. They’re specifically designed so components can work together seamlessly, forming a well-integrated system.
Let’s dive in.
One misconception is that modular blockchains may increase complexity for app developers due to multiple components working together.
In fact, in a modular system, a smart contract developer building on a general-purpose L2 has the exact same experience as a smart contract developer building on a monolithic chain. Once the smart contract is deployed on an EVM L2 chain, users only have to send their transactions to the blockchain as they would’ve done if the contract was deployed on a monolithic chain. Any increase in complexity is handled by the rollup/chain developer, not the app developer - and it gives the app developer several advantages in return including flexibility, cost reduction, and more.
What if the project is deployed as an app-specific rollup instead of on top of a general-purpose one?
In a modular ecosystem, underlying complexities further down the stack can be reduced for rollup developers by offering pre-configured chain templates. As an example, if you want to deploy an app rollup today, you can go to a Rollup-as-a-service (RaaS) provider (see Caldera, Altlayer, Opside, Snapchain) and spin it up in one click.
The RaaS provider takes up the complexity and offers it as a service just like hosting a VM on DigitalOcean or deploying a webapp on Heroku. A power user can still take up the entire orchestration which provides more configurability but takes a huge effort to setup and maintain.
Let’s look at a comparison between a project deciding to deploy its own exclusive chain in a Monolithic vs. Modular setting:
CEX and fiat on/off ramps will be easily accessible for app developers on modular blockchains as well. Every major rollup ecosystem on a Layer 1 blockchain (such as Avail) is going to have at least 1 specialized liquidity-focused rollup, that will have:
This liquidity focused rollup (or the Liquidity Hub) will be seamlessly accessible from other rollups via an inexpensive and fast inter-rollup messaging mechanism. Rollup ecosystems built on a shared DA layer will focus on seamless interoperability amongst the rollups themselves as they do not need to cross trust zones.
Good early examples of this model are seen with Osmosis in the Cosmos ecosystem or AssetHub in the Polkadot ecosystem - strictly speaking, these are not rollups, but you can see the general ecosystem design pattern that others are converging on.
There’s a misconception that by separating the functionality of a monolithic blockchain into modular layers will reduce performance, or at least not improve it.
We are now living in a post-zk world, where previously prevalent assumptions about scalability and security no longer hold. Today, execution verification does not require ALL the nodes in the network to re-execute all transactions. Instead, trustless zero-knowledge (ZK) provers can provide validity proofs, which are orders of magnitude cheaper to verify. And validity provers are incredibly parallelizable.
With Data Availability Sampling or in short, DAS (implemented on Avail, Celestia), you don’t need to download all the transaction data to verify data availability (DA). DAS light clients can randomly sample a small fraction of the entire data and very quickly get high probabilistic DA guarantees.
This is an order of magnitude faster and cheaper than downloading ALL the data by EVERY node in the network.
The combination of DAS and recursive validity proofs makes modular blockchains extremely powerful. Any rollup developer can build a completely new chain, even with a centralized sequencer, and users can still be assured of the safety of their funds, assuming the rollup protocol has options built in for escape hatches and based sequencing.
Some additional benefits you get with this are:
Modularity has nothing to do with execution speeds. The Solana VM on a rollup will have the same performance as on a monolithic blockchain. The real benefit of modularity is in optimizing the verification workflow. And it does not even need to have zk/validity proofs. Optimistic or pessimistic rollups also exhibit the same characteristics.
Modular blockchains are more than the sum of their parts.
When working with modular blockchains, there might be a concern about increased cost, but in reality, it’s just the opposite. Monolithic chains have hidden costs and in a multi-chain world, users pay the costs on all the chains.
Let’s look at some data about the actual costs of operating various blockchain networks. The data below is sourced from https://www.stakingrewards.com/
Focus on the right-most column in the table above. As is evident, the costs of bootstrapping and maintaining a blockchain are really high!
Note that inflation rewards to stakers running the network are ultimately paid out from the token holder’s pocket. Token holders subsidize the cost of running the network in the absence of real transaction fees.
Whenever someone wants any flexibility from the protocol rules of a monolithic chain and wants to introduce a new execution environment or a new precompile, the proponents of monolithic blockchains expect them to build a new blockchain by bootstrapping a validator network and token from scratch!
This is limiting the permissionless innovation that is at the core of this industry.
When a rollup is deployed on the same DA layer, it is part of the SAME ledger as an asset on the base layer. In fact, the so-called ‘L2 ledger’ is just a subset of the data entries in the L1 ledger. As Jon explains in this article, there are millions of rollups within each DA layer. In simple terms, a rollup is just ANY subset of the base DA layer.
“There are essentially infinite undiscovered rollups hidden in Ethereum’s data. You can make a rollup to trustlessly read and compute over that data however you want, then you could provably communicate it back. - Jon Charbonneau”
Yes, there are entities specifically focused on maintaining their own L2 ledgers, but all of these ledgers are ultimately just the subsets of the base layer ledgers. This is why L2s inherit the security guarantees from the DA layer that they are deployed on.
On a shared DA layer, token holders of the base layer bootstrap and maintain security. The rollup ecosystem on top does not need to individually manage this. They inherit the security of the base layer.
An idea shared by some that modularizing blockchains leads to lesser liquidity on each ledger is flawed and assumes that modular blockchains aren’t vertically integrated. This argument puts a premium on synchronous composability when most stuff is possible via asynchronous composability. Even the best traditional fintech systems prioritize asynchronous composability. This is what allows Cosmos chains to access the liquidity hub in Osmosis (via IBC) and Ethereum L2 rollups to access liquidity on Ethereum (via trust-minimized bridging).
As modular systems mature, asynchronous messaging via recursive proof aggregation is going to be extremely cheap since client-side validity proof verification is possible via a combination of execution verifiers and efficient DA verification via light clients.
If multiple arbitrage transactions on different rollups are a concern, they are not limited to just modular blockchains. Duplicative computations across asset ledgers can happen even with multiple DeFi protocols on the same layer. If the ETH-USDC price is $1800 on Binance, $1600 on Aave, and $1700 on Compound, this requires two separate arbitrage transactions to resolve.
Multiple arbitrage transactions are not an exclusive function or consequence of modular blockchains.
There’s a misconception that app rollups do not give developers any new avenues for experimentation or monetization. The belief is that existing constructs on monolithic chains give enough tools to perform experimentation or create revenue.
Modular rollups empower developers to work in a variety of execution environments, not only fostering diversity but also presenting cost-saving advantages. Compared to monolithic chains, with their high overheads, app-specific rollups are often more economical and streamlined, removing complexities like managing infrastructures and indexers.
It’s quite clear that applications can capture MEV (in-rollup and cross-chain) if they deploy the app as an app-specific rollup. There’s a misconception that the same can be achieved with monolithic blockchains by adding a few logical changes to the smart contract deployed on a global ‘monolithic’ state machine.
Adding a few logical changes to the smart contract deployed on a global ‘monolithic’ state machine may achieve similar results. But the idea of adhering to a global state model and single VM for execution doesn’t make much sense when there is so much potential for arbitrary execution environments with app rollups. As explained above, some apps might be better suited to a completely different execution environment than the standard EVM or SVM. This is possible with Modular Blockchains, and we think a lot more experimentation with execution environments, ledger authentication, access, custom state models, etc. is required to keep pushing the industry forward.
Taking an analogy from traditional tech stacks, there isn’t any single programming language or one standard way of developing web/mobile apps. Why should blockchains be any different? The diversity of choice and fostering of experimentation which unlocks new monetization opportunities in any industry can be achieved with modular rollups!
In addition to the revenue opportunities, the “costs” of deploying and maintaining an app on a monolithic chain can be much higher than simply deploying an app-specific rollup. Most app developers on a monolithic chain need to manage a ton of infra, indexers, transaction relay providers, RPC full node providers, etc.
Modular structures are able to abstract away this complexity by allowing specialized chains with the right construction (application-specific, custom state transition function, custom state - see Stackr Labs) to bypass these infra management requirements - which is often cheaper than trying to bootstrap everything on a monolithic chain yourself.
Ignoring all these benefits, do we really want to limit developers to the status quo?
The misconception is that monolithic chains have adequate constructs to solve for cross-app congestion, without needing to break into app-specific rollups.
In practice, pricing every resource using the same global fee market puts constraints on the throughput of the entire system. While localized fee markets, as seen in Solana and Aptos, effectively alleviate application-level congestion, they fall short in addressing cross-app congestion.
That is precisely what the developers of modular systems are trying to solve. By deploying an app as an app-specific rollup, projects can get exclusive execution environments and application-specific fee markets.
What happens when there is a spike in prices and congestion at the base layer (either directly or trickled down via some other L2)?
The app-specific rollup can keep operating as normal and stay unaffected if it simply delays posting a batch of transactions on the base layer during such spikes. Users of this app rollup will still be able to get soft finality, even though the ‘hard’ finality might be delayed.
Rollups on a scalable data availability-focused base layer like Avail mitigate this to a large extent by being able to scale DA block sizes with rollup demand.
In a rollup ecosystem that enables asynchronous message passing via recursive proof aggregation, each app can have its own throughput and transaction pricing. They can run at their own pace without having to worry about the other chain it needs to interact with. The async message passing enables verifiable inclusion without synchronicity assumptions and hence allows users far greater flexibility in terms of avoiding shared state access compared to monolithic chains.
The async paradigm enabled by proof aggregation enables you to put transactions in individual chains at different points in time in order to avoid individual chain congestion without sacrificing atomicity or composability between the applications. This provides a richer set of tools to express intents which are extremely limited in synchronous composability between apps on a monolithic chain.
One misconception is that modularity means no vertical integration. It is also thought that the flexibility offered by modular chains are overrated and nothing new needs to be built.
The truth is, modular systems can combine to form vertically integrated stacks, the complexity of which can be abstracted away from the app developers.
The premise of permissionless innovation is to allow app developers to experiment and come up with new ideas while still absorbing high security from the stack on which their apps are deployed. This permissionless-ness can be constrained if the app is deployed on an L1 where the upgrade costs are high.
Modular systems lower the cost of experimenting with new execution environments, new state models, and new access mechanisms. They provide access to lower fees and lower latency. Access to spot DEXs, stablecoins, and fiat on-ramps can be easily implemented via 1 or more liquidity-focused rollups or a liquidity hub as mentioned earlier.
Without experimentation, it is impossible to predict the use cases that can be fostered by a properly implemented modular stack. When the Internet came along, Bill Gates’s best guess of a use case was watching recordings of baseball games. This just goes to show how tough it is to predict the direction a technology will go in without allowing anyone to permission-lessly innovate on it.
There is a misconception that rollups cannot be hard forked. They are tied to the enshrined bridge on the base layer and hard fork would mean the base layer itself has to fork off.
This misconception arises from how rollups are implemented today on Ethereum that combine a bridge to the base layer for L1 assets along with the state verification mechanism. We should not confuse the bridge and the verification mechanics.
The rollup itself can certainly be hard forked, very similar to how L1 forks happen. The bridge itself is a separate construct. Jon Charbonneau explains it pretty well in this post why rollups are not equal to bridges. A rollup is not defined by the bridge and hence the hard fork ability of the bridge on some other chain should not be equated with the hard fork ability of the rollup itself.
A sovereign rollup on Avail can be viewed as similar to any normal blockchain. There are full nodes of the rollup that sync with the rollup node. What happens differently here is that rollup transaction data is also sent to Avail and DA light clients on Avail can then randomly sample the data and verify data availability. These light clients are also embedded in the rollup node to facilitate this process. The major difference in this construction versus Ethereum-style or enshrined settlement layer type rollups is that the rollup nodes and light clients verify the canonical chain without relying on a smart contract based enshrined verification mechanism.
And if people are still unconvinced by the theoretical discussions around it, they can refer to our OpEVM prototype which is a sovereign optimistic chain built on Avail with decentralized sequencer set and permissionless watchtower. It can easily hard fork without changing anything on Avail. It is also good to keep in mind that Avail does not support any smart contract so the rollup does not have an enshrined bridge which gives it sovereignty.
At present, blockchains are a niche industry. We require more users, greater adoption, and expanded use cases than are possible today.
To get there, we’ll need to lower the cost of experimentation and let users and developers make an educated choice of monolithic or modular ecosystems. We hope that in this article, you’ve learned more about the scalable potential for modular systems, and will be better equipped to make that choice yourself when you need to. And with the right tools, we’re sure you will create innovations beyond our imagination.
Let thousands of rollups bloom!