Modular Blockchains: Lego Dream or Integration Nightmare?

Modular is a suspiciously pleasant word. It evokes images of Lego bricks, well-organized software libraries, and furniture delivered in boxes with a bag of screws on the side. Modular implies flexibility, modernity, and a certain degree of elegance, as opposed to some giant indestructible mechanism where every gear is welded to the next. That is why the word finds its natural habitat in crypto marketing. A modular blockchain is something that should just click together in one’s mind - execution here, settlement there, data availability below, a bridge, some zero-knowledge encryption, and suddenly the whole system is more efficient than the monolithic alternative.

Anybody who has ever tried to assemble something modular knows that the beauty is often in the lie. Substituting one set of Lego blocks for another can be disappointing if the new blocks are not as strong as the old ones. Now imagine that instead of plastic bricks and screws you have settlement assumptions, rollup frameworks, bridge contracts, data-availability committees, governance tokens, investor timelines, external audits, and five thousand lines of LLM-initialized code that nobody reads because the launch window is near.

Things can be good if done right. This banal truth is the whole point of modular blockchain design. It is not magical, it does not promise to solve problems by itself; it only claims that complexity can be moved around. It is up to the implementers to make sure that the new, distributed complexity is manageable. A well-organized modular system can carve out a certain domain and perform its task far better than a monolithic system would. It can also create an attack surface of terrifying size if not designed with this fact in mind.

The reason why modular blockchains are interesting to people is because the old ways of designing traditional blockchain systems ran into a certain set of problems. A monolithic blockchain is a settlement layer, an execution environment, a consensus mechanism, and a data-availability layer all mushed together into one tightly integrated system. It is the Middle Ages castle design - simple, elegant, with all the defenses concentrated in one place, but extremely costly to build and maintain.

Settlement, execution, consensus, and data-availability are all important, but the competition for the block space between them often leaves little room for applications that want to settle on the chain. Users have to pay for what the developers fail to prioritize, and the developers have to design around the constraints instead of building the application layer they envision. This is why modular blockchain design is an attractive prospect - it promises to decouple these functions and allow specialized layers to perform their task better than a general-purpose blockchain can.

Ethereum’s rollup-centric upgrades are the most prominent example of this approach, where settlement and security are provided by Ethereum mainnet while the execution environment is rolled out separately in the form of various rollups. The recent Dencun upgrade, which introduced blobspace, is another example - it allowed rollups to post their data for cheaper, which in turn makes the applications that use these rollups cheaper for the users.

Celestia is an experimental modular blockchain protocol that also aims to provide a settlement layer separate from the execution environment. It is similar to Ethereum in many ways but attempts to be generalized and thinner - execution rollups can use its data-availability layer without adopting Ethereum’s settlement and consensus mechanisms. Celestia uses data-availability sampling to let light nodes verify that the data was published correctly without downloading the whole chain. The whole ecosystem around it is also modular - rollup frameworks, data publication layers, and other infrastructure tools are built separately but interoperate with the base chain. Demand is there, but it is still early days for Celestia, as it is for many other modular blockchains.

EigenDA is a data-availability layer built on EigenLayer, which allows Ethereum-based rollups to utilize EigenDA’s restaked Ether security instead of securing their own data-availability chains. Avail, the former Polygon project turned standalone data-availability layer, is another competitor that promises chain-agnostic data availability with light-client verification and interoperability. These are all interesting ideas that aim to decouple data availability from settlement and execution, letting rollups be thinner and more specialized.

For developers, the appeal of modular blockchains is obvious. Instead of building everything from scratch, they can use a certain framework or a set of well-known modular components to build their chain. OP Stack, Arbitrum Orbit, ZK Stack, Polygon CDK, Agglayer CDK, Rollkit, and various rollup-as-a-service offerings all allow developers to build an execution environment of their choice while relying on well-established security assumptions. Instead of launching a full-blown settlement layer with validators, a bridge, a consensus mechanism, and a set of smart contracts, a team can launch an optimistic or zk-rollup with a trusted setup, and be done with it in a matter of weeks. Instead of building a data-availability layer, a rollup can rent space on Ethereum or on another chain via EigenDA or Celestia.

For users, the benefits are more elusive. A cheaper rollup-based application is better than nothing, but the true promise of modular blockchains is specialization. Settlement and data-availability layers can be optimized for simplicity and security, execution rollups can utilize the tooling provided by their framework of choice, and application-specific blockchains can provide cheaper transactions and better UX than generic ones. This is all very theoretical, but the more attractive proposition it provides for developers and users is also a threat - a threat to the dominance of monolithic blockchains.

Armor Problem

The trouble starts when modularity leaves architecture for fashion. One is not safer simply because his diagrams have more boxes. Around every boundary between boxes must be assumptions, every message between layers must be checked, every bridge designed with a trust model, every sequencer checked for liveness, every data availability layer scanned for honest sampling or operators, every upgrade path subjected to governance, every external dependency something that might malfunction while the app claims to be safe.

Crypto hackers have long since discovered that the best place to poke at a system is rarely its core, but its appendages: the bridge, the oracle, the validator set, the upgrade key, the off-chain signer, the little helper contract no one thought would matter. Look at Ronin’s disastrous validator key compromise, Wormhole’s wrapping fraud, or Nomad’s bridge withdrawal exploit – and the countless billions in value stolen in these incidents. The cost of each was minimized by design, but the damage was done at the point of lowest security: the weakest link in the chain.

This is where medieval armor comes in. Chainmail and plates and leather and padding and various other forms of defense were once joined together in a patchwork to allow maximum freedom of movement while still providing reasonable safety. Each layer could be replaced, upgraded, repaired – but the joins between the different types of armor were always weak points, exploited by determined enemies. It was not the weakest single link that finished mounted knights, but their belts. Their armpits, their visors, their groins, their knees, their elbows – all these places were not designed to repel a spear, but they became certain entry points of attack.

Later developments in armor design sought to reduce these weak points by making the whole garment more integrated: a cuirass, a closed helmet, more strategic plates and joint reinforcement. There was nothing wrong with the old way, but the enemy was not stupid, and he stopped aiming at the knight’s belt. A modular system is only as strong as its weakest dependency, and the more such dependencies there are, the more likely one of them will fail.

This is the standard that modular blockchains must be measured against. A modular design is beneficial when each layer is built to the threat of the system as a whole, but dangerous when its individual elements become the lowest common denominator of security. When someone is poking at your sequencer, you don’t want to be reminded that your data layer or settlement chain is a multi-sig contract or a third-party node operator.

This does not mean that monolithic chains are by default superior to modular ones. A single integrated blockchain has its own risks, attack vectors, bottlenecks, and points of failure – witness the ever-growing security challenges of Solana, Ethereum, Bitcoin, and other large ecosystems. But a monolith presents a simpler surface to attack and defend, with lower overall risk than the alternative. Similarly, a modular stack may allow for greater scalability, flexibility, and experimentation, but it comes at the cost of increased complexity and the burden of additional trust assumptions.

User Experience Problem

The weakness of the modular approach tends to manifest in the user experience. If execution layer is working fine but data layer is unavailable, or sequencer is paused but settlement chain is live, or bridging is temporarily disabled due to an incident, how is the user supposed to know? He is not familiar with the distinction between settlement and execution anyway, and certainly not with the subtle differences between various data availability designs and their implications for liveness. To him, the blockchain is down, period.

Rollup outages are the most prominent example of this problem. Base, one of the most popular Ethereum layer 2s, had its chain paused for 33 minutes due to a sequencer failover issue. Fortunately for its users, their funds were not actually inaccessible at any point during the incident, but it remains a sobering lesson. The entire Ethereum ecosystem is built on the security of settlement on Ethereum, but that does not mean that rollup-specific outages never occur.

Another example can be found in the recent Linea sequencer outage following the Velocore exploit. In the aftermath of the attack, Linea’s team initiated a pause that prevented withdrawal of user funds. While this was undoubtedly the lesser of two evils given the circumstances, it highlights the potential UX risk of a modular design. The pause meant that users of Linea’s Ethereum-compatible chain were unable to access their assets, even though they were secured by Ethereum. It also served as a painful reminder that many rollups still have centralized or semi-centralized operational control over their chains.

At the moment, the rollup space is characterized by an explosion of different data availability options. Various modular blockchains offer their users a choice between rollup-as-a-service providers, Celestia DA, EigenDA, Avail, Ethereum blobspace, and other options. Some chains, including Base, Arbitrum Nova, Linea, Scroll, and others, are built on top of existing Ethereum settlement chains and utilize their data availability solutions. Meanwhile, Optimism is set to launch its own Superchain, which would unite multiple OP chains in a shared settlement layer.

The choice between these options is rarely obvious, and rarely made without considering technical specifics. In practice, many users simply want their transactions to be cheap and fast. They do not want to worry about the differences between blobs and calldata, or layer 2 chains and their settlement on the layer 1. When it comes to crypto UX, ‘modular’ often means ‘inexpensive’, and the audience for that is broad.

On the other hand, every chain built on top of another one introduces additional risk. Ethereum bridges have been a frequent source of attacks this year, and it is only logical to assume that rollup-specific issues will follow suit. The more layers there are between a user’s funds and settlement, the more things can go wrong at once. While the threat model for rollup outages is arguably not as high as bridges, the same cannot be said for UX design. The same user who would not notice the difference between Ethereum, Arbitrum Nova, Linea, or Base will also not notice when one of these chains is ‘paused for security reasons’.

It is not just the individual user who has to deal with the complexities of modular design. Smart contract security is already challenging enough, but auditing a modular stack is like climbing a mountain. One has to review not just the target contract but all of the additional code, assumptions, dependencies, and tools that constitute the system. Any one of these elements could fail in an unexpected way, and the interaction between them is rarely intuitive. An attacker only needs to find one vulnerability in one smart contract or one weakness in one bridge in the system for his attack to succeed.

The industry response to this challenge is obvious – more rigor, better tools, improved design. Better bridges with light client verification. Zero knowledge proofs and threshold signatures. Rate limiting and circuit breakers. Decentralized sequencers and settlement chains. Formal verification and monitoring and user-facing UX to explain everything to the confused end-users. The tension at the heart of the modular space drives innovation on all levels, from the lowest technical layers all the way to the top.

Tradeoffs, Not Salvation

Software is all about the tradeoffs. Some are obvious, some are buried under documentation and legalese. Some come with every major innovation in the space, such as the compromises that make up Ethereum’s EVM. Modular blockchains are no different, promising flexibility and experimentation without removing the burden of additional complexity. Modular chains trade the relative technical simplicity of a single-chain system for opportunities at optimization. They trade easy security guarantees for expanded attack surface area. They trade the congestion of a single settlement layer for the organizational overhead of multiple layers of security. They trade developer freedom for decentralization, and raw potential for increased responsibility.

For some teams, that makes them an obvious choice. There are application-specific chains that would benefit from not sharing a settlement layer with everyone else, for performance or economic reasons. There are games and stateful apps and specialized DeFi protocols, enterprise chains and testing environments, all of which can utilize the flexibility of a modular approach. There are entire ecosystems that need to be built from nothing, and a rollup with cheaper data and faster processing is a good way to start.

For other teams, the tradeoff is not nearly as attractive. If the project does not need its own chain, there is no point in launching one. If the team is not confident about building a bridge, it should refrain from doing so. If the organization cannot educate its own users about the dangers of a modular design, it certainly cannot expect to protect its customers. If decentralization is always going to be ‘in the future’, the project is not ready to launch. The security of a modular chain is only as good as its weakest point, and if the weakest point is ‘the promise of future upgrades’, it is time to revisit the design.

The lesson from the middle ages applies here as well – modular armor was not inherently inferior to any other kind. Badly designed modular armor, however, was often easy to spot, as it frequently left vital areas of the body exposed. Same goes for modular blockchains – the promise of ‘unified security properties’ is hollow if every layer of the system is minimally sufficient, insecure, or unproven.

The best modular blockchains acknowledge this reality and minimize these risks as much as possible. They recognize that a truly secure design hides complexity behind a good interface, just like good armor is difficult to spot at a distance. They narrow assumptions and trust boundaries, limit the attack surface, and utilize existing security infrastructure where possible. Sequencing is decentralized, settlement chains are battle-tested, bridges are light client verified, smart contracts are formally audited. Each additional layer is only added if it serves a purpose.

The worst modular blockchains, on the other hand, sound better than they are. They hide their insecurity behind vague assurances, ‘multi-layered’ marketing speak, and the promise of ‘flexibility’. They add more and more complexity without reducing overall risk, prioritizing speed and scale over security. A chain built on top of another chain is not inherently worse than a standalone one, but it is always more dangerous if the team behind it cannot explain exactly why. If the project’s weakest link is its promise to deliver on decentralization ‘someday’, the entire system is in peril.

Worth or Not?

Modular blockchains offer developers incredible opportunities. If utilized correctly, their advantages are difficult to deny – greater flexibility and experimentation, lower costs and easier auditing. There are no doubts that the tension between monolithic and modular approaches will continue to define the space for years to come, as both sides seek to maximize the strengths and minimize the weaknesses of their respective architectures. But whether these opportunities will actually materialize depends on the commitment and technical competence of the individual teams.

Modularity certainly has its appeal. The ability to construct an entire ecosystem from off-the-shelf components is undeniably enticing. It can accelerate development, reduce barriers to entry, and offer a wide variety of experimental options. Ethereum’s optimistic rollups have already demonstrated the viability of the approach, and the wider ecosystem is now witnessing an explosion of innovation.

Celestia and EigenDA, along with Avail and Ethereum blobspace, are all set to bring greater data availability flexibility to the rollup chains that utilize them. OP Stack, Arbitrum Orbit, Polygon’s CDK and Agglayer, Linea’s fork of Optimism, and many others are all working towards lower technical barriers for individual developers and teams, allowing them to launch their own Ethereum-compatible chains. The entire space is entering an exciting phase of development, as the technical feasibility of a multi-chain future becomes increasingly apparent.

However, the same momentum is fueling optimism elsewhere. For some projects, the appeal of a monolithic approach is difficult to ignore. Integrated chains possess inherent advantages, offering greater simplicity and security while being more conducive to long-term sustainability. Users of such platforms are less likely to be confused or frustrated by the technical details of modular design. A single reliable and performant environment is often preferable to an ecosystem with lower costs and faster processing but higher overall risk. Even among Ethereum developers, the option of staying on the ‘mainnet’ is frequently viewed as the most viable path.

The same principles apply to the broader industry trends. Solutions that seek to automate TRON network operations for business are seeing growing demand among teams that do not wish to customize their Energy management, handle Smart Mode and Host Mode themselves, or spend time on scripting and API management. Netts Workspace provides an intuitive interface that unifies Energy rental, Smart Mode and Host Mode, TRON transactions and Energy management, monitoring tools, AML screening, and financial operations, letting companies reduce costs while minimizing risks associated with manual operations.