Kyle Samani, partner at Multicoin Capital, details 7 reasons why modular blockchains are overrated.
Written by Kyle Samani, Partner at Multicoin Capital
Compiled by: Luffy, Foresight News
Over the past two years, the blockchain scalability debate has centered on the central topic of “modularity vs. integration.”
Note that discussions in crypto often conflate "monolithic" and "integrated" systems. The technical debate about integrated vs. modular systems has a long history spanning 40 years. This conversation in crypto should be framed through the same lens as history; this is far from a new debate.
When considering modularity vs. integration, the most important design decision a blockchain can make is how much of the complexity of the stack it exposes to application developers. The customers of a blockchain are application developers, so the ultimate design decision should consider their perspective.
Today, modularity is largely hailed as the primary way blockchains scale. In this post, I will challenge this assumption from first principles, expose the cultural myths and hidden costs of modular systems, and share the conclusions I’ve drawn from thinking about this debate over the past six years.
Modular systems increase development complexity
By far the biggest hidden cost of modular systems is the added complexity of the development process.
Modular systems greatly increase the complexity that application developers must manage, both in the context of their own applications (technical complexity) and in the context of interactions with other applications (social complexity).
In the context of cryptocurrencies, modular blockchains theoretically allow for greater specialization, but at the cost of creating new complexity. This complexity (both technical and social in nature) is being passed on to application developers, ultimately making it more difficult to build applications.
Consider, for example, OP Stack. As of now, it seems to be the most popular modular framework. OP Stack forces developers to choose between adopting Law of Chains (which comes with a lot of social complexity), or forking and managing separately. Both options create huge downstream complexity for builders. If you choose to fork, do you get technical support from other ecosystem participants (CEXs, fiat on-ramps, etc.) who must bear the cost to comply with the new technical standards? If you choose to follow Law of Chains, what rules and constraints will be imposed on you today and tomorrow?
Source: OSI Model
Modern operating systems (OS) are large, complex systems that contain hundreds of subsystems. Modern operating systems handle layers 2-6 in the diagram above. This is a classic example of integrating modular components to manage the complexity of the stack exposed to application developers. Application developers don't want to deal with anything below layer 7, which is exactly why operating systems exist: the OS manages the complexity of the layers below so that application developers can focus on layer 7. Therefore, modularity should not be a goal in itself, but a means to an end.
Every major software system in the world today—cloud backends, operating systems, database engines, game engines, etc.—is highly integrated and composed of many modular subsystems. Software systems tend to be highly integrated to maximize performance and reduce development complexity. The same is true for blockchain.
By the way, Ethereum is reducing the complexity that emerged in the 2011-2014 Bitcoin fork era. Modularity proponents often emphasize the Open Systems Interconnection (OSI) model, arguing that data availability (DA) and execution should be separated; however, this argument is widely misunderstood. A correct understanding of the issue at hand leads to the opposite conclusion: OSI is an argument for integrated systems rather than modular systems.
Modular chains cannot execute code faster
A common definition of a "modular chain" is a separation of data availability (DA) and execution, by design: one set of nodes is responsible for DA, while another set (or sets) of nodes is responsible for execution. The sets of nodes do not have to have any overlap, but they can.
In practice, separating DA and execution does not inherently improve the performance of either; rather, some hardware somewhere in the world must perform DA, and some hardware somewhere must implement execution. Separating these functions does not improve the performance of either. While separation can reduce computational costs, it can only be reduced by centralizing execution.
It bears repeating: regardless of modular or integrated architecture, some hardware somewhere has to do the work, and separating DA and execution onto separate hardware does not inherently speed up or increase total system capacity.
Some argue that modularity allows multiple EVMs to run in parallel in a Rollup fashion, enabling execution to scale horizontally. While this is theoretically correct, this view actually highlights the limitations of the EVM as a single-threaded processor, rather than the fundamental premise of separating DA and execution in the context of scaling the overall throughput of the system.
Modularity alone does not increase throughput.
Modularity increases transaction costs for users
By definition, each L1 and L2 is an independent asset ledger with its own state. These separate state fragments can communicate, albeit with longer transaction latency and more complexity for developers and users (via cross-chain bridges such as LayerZero and Wormhole).
The more asset ledgers there are, the more fragmented the global state of all accounts is. This is terrible for both chains and users across multiple chains. State fragmentation can have a range of consequences:
Reduced liquidity, resulting in higher trading slippage;
More total gas consumption (cross-chain transactions require at least two transactions on at least two asset ledgers);
Increased duplication of calculations across asset ledgers (thus reducing the overall throughput of the system): When the price of ETH-USDC changes on Binance or Coinbase, arbitrage opportunities arise on every ETH-USDC pool across all asset ledgers (you can easily imagine a world where every time the price of ETH-USDC changes on Binance or Coinbase, there are 10+ trades across various asset ledgers. Keeping prices consistent across fragmentation is an extremely inefficient use of block space).
It’s important to recognize that creating more asset ledgers significantly increases costs in all of these dimensions, especially those related to DeFi.
The main input to DeFi is on-chain state (i.e. who owns which assets). When teams launch application chains/Rollups, they naturally create state fragmentation, which is very bad for DeFi, both for developers managing application complexity (bridges, wallets, delays, cross-chain MEV, etc.) and users (slippage, settlement delays).
The most ideal condition for DeFi is that assets are issued on a single asset ledger and traded within a single state machine. The more asset ledgers there are, the more complexity application developers must manage and the higher the cost users must bear.
Application Rollups do not create new monetization opportunities for developers
Application chain/Rollup proponents believe that incentives will lead application developers to develop Rollups instead of building on L1 or L2 so that the application can capture MEV value themselves. However, this idea is flawed because running an application Rollup is not the only way to capture MEV back into application layer tokens, and in most cases it is not the best way. Application layer tokens simply encode logic in smart contracts on the general chain to capture MEV back into their own tokens. Let's consider a few examples:
Liquidations: If Compound or Aave DAO wanted to capture a portion of the MEV flowing to the liquidator bot, they could simply update their respective contracts to make a portion of the fees currently going to the liquidator payable to their own DAO, without the need for a new chain/rollup.
Oracles: Oracle tokens can capture MEV by providing back running services. In addition to price updates, oracles can also bundle any arbitrary on-chain transactions that are guaranteed to run immediately after the price update. Therefore, oracles can capture MEV by providing back running services to searchers, block builders, etc.
NFT Minting: NFT minting is rife with scalping bots. This can be easily mitigated by simply coding a redistribution of declining profits. For example, if someone tries to resell their NFT within two weeks of minting, 100% of the proceeds go back to the issuer or DAO. This percentage may change over time.
There is no universal answer to capturing MEV into application layer tokens. However, with a little thought, application developers can easily capture MEV back into their own tokens on a general-purpose chain. Launching a whole new chain is simply unnecessary, creates additional technical and social complexity for developers, and creates more wallet and liquidity headaches for users.
Application Rollup cannot solve cross-application congestion problems
Many people believe that application chains/rollups ensure that applications are not affected by gas spikes caused by other on-chain activities (such as popular NFT minting). This view is partially correct, but mostly wrong.
This is a historical issue that is rooted in the single-threaded nature of the EVM, not because DA and execution are not separated. All L2s pay fees to L1, and L1 fees can increase at any time. During the memecoin craze earlier this year, transaction fees on Arbitrum and Optimism briefly exceeded $10. More recently, Optimism fees also spiked after the launch of Worldcoin.
The only solution to the fee spike is to 1) maximize L1 DA, and 2) make the fee market as granular as possible:
If L1 is resource constrained, usage spikes in individual L2s will be passed on to L1, which will impose higher costs on all other L2s. Therefore, AppChains/Rollups are not immune to Gas spikes.
Multiple EVM L2s coexisting is just a crude way to try to localize fee markets. It's better than putting the fee market in a single EVM L1, but it doesn't solve the core problem. Once you realize that the solution is to localize fee markets, the logical end point is a fee market per state (rather than a fee market per L2).
Other chains have already come to this conclusion. Solana and Aptos natively localized fee markets. This required a lot of engineering work over many years for their respective execution environments. Most modularity proponents severely underestimate the importance and difficulty of engineering local fee markets.
Localized fee market, source: https://blog.labeleven.dev/why-solana
Developers are not unlocking true performance gains by launching multiple chains. As applications drive transaction volume, costs for all L2 chains will be impacted.
Flexibility is overrated
Proponents of modular chains argue that modular architectures are more flexible. This statement is obviously true, but does it really matter?
For six years, I have been trying to find application developers for whom general purpose L1s provide meaningful flexibility. But until now, no one has been able to clearly articulate why flexibility is important and how it directly helps scale, except for three very specific use cases. The three specific use cases where I have found flexibility to be important are:
Applications that take advantage of "hot" states. Hot states are states that are necessary to coordinate some set of operations in real time, but are only submitted to the chain temporarily and do not exist forever. A few examples of hot states:
Limit orders in DEXs like dYdX and Sei (many limit orders were eventually canceled).
Real-time coordination and identification of order flow in dFlow (dFlow is a protocol that facilitates a decentralized order flow market between market makers and wallets).
Oracles like Pyth, which is a low latency oracle. Pyth runs as a standalone SVM chain. Pyth generates so much data that the core Pyth team decided it would be best to send high frequency price updates to a standalone chain and then use Wormhole to bridge prices to other chains as needed.
Chains that modify consensus. The best examples are Osmosis (where all transactions are encrypted before being sent to validators), and Thorchain (where transactions within a block are prioritized based on fees paid).
The infrastructure for Threshold Signature Schemes (TSS) needs to be leveraged in some way. Some examples of this are Sommelier, Thorchain, Osmosis, Wormhole, and Web3Auth.
With the exception of Pyth and Wormhole, all of the examples listed above were built using the Cosmos SDK and run as standalone chains. This speaks volumes about the applicability and scalability of the Cosmos SDK for all three use cases: hot states, consensus modification, and threshold signature scheme (TSS) systems.
However, most of the projects in the three use cases above are not applications, they are infrastructure.
Pyth and dFlow are not applications, they are infrastructure. Sommelier, Wormhole, Sei, and Web3Auth are not applications, they are infrastructure. Among them, there is only one specific type of user-facing application: DEX (dYdX, Osmosis, Thorchain).
For six years now, I’ve been asking Cosmos and Polkadot backers about the use cases enabled by the flexibility they offer. I think there’s enough data to make some inferences:
First, infrastructure examples should not exist as Rollups because they either produce too much low-value data (e.g. hot state, where the whole point of hot state is that data is not committed back to L1) or because they perform some function that is intentionally related to state updates on the asset ledger (e.g. all TSS use cases).
Secondly, the only type of application I have seen that would benefit from changing the core system design is a DEX. Because DEXs are flooded with MEV, and general-purpose chains cannot match the latency of CEXs. Consensus is the foundation of trade execution quality and MEV, so changes based on consensus naturally bring a lot of innovation opportunities to DEXs. However, as mentioned earlier in this article, the main input to a spot DEX is the asset being traded. DEXs compete for assets, and thus compete for asset issuers. Under this framework, independent DEX chains are unlikely to succeed because the primary concern of asset issuers when issuing assets is not DEX-related MEV, but general smart contract functionality and incorporating that functionality into developers' respective applications.
However, derivatives DEXs do not need to compete for asset issuers, they rely primarily on collateral such as USDC and oracle feeds, and essentially have to lock up user assets to collateralize derivative positions. Therefore, in terms of independent DEX chains, they are most likely to be suitable for derivatives-focused DEXs such as dYdX and Sei.
Let’s think about the common integrated L1 applications that exist today, including: Games, DeSoc systems (such as Farcaster and Lens), DePIN protocols (such as Helium, Hivemapper, Render Network, DIMO, and Daylight), Sound, NFT exchanges, etc. None of these particularly benefit from the flexibility that comes with modifying consensus, and their respective asset ledgers have a set of fairly simple, obvious, and common requirements: low fees, low latency, access to spot DEXs, access to stablecoins, and access to legal channels such as CEXs.
I believe we now have enough data to say to some degree that the vast majority of user-facing applications have the same general requirements as listed in the previous paragraph. While some applications can optimize other variables at the margin through custom functionality in the stack, the tradeoffs these customizations bring are generally not worth it (more bridges, fewer wallets supported, fewer indexers/queriers supported, fewer fiat channels, etc.).
Rolling out new asset ledgers is one way to achieve flexibility, but it rarely adds value and almost always introduces technical and social complexity with little ultimate benefit to application developers.
Scaling DA does not require re-collateralization
You’ll also hear modular proponents talk about rehypothecation in the context of scaling. This is the most speculative argument made by modular chain proponents, but it’s worth discussing.
It roughly states that due to re-pledge (e.g., through systems such as EigenLayer), the entire crypto ecosystem can re-pledge ETH infinitely, empowering an infinite number of DA layers (e.g., EigenDA) and execution layers. Therefore, while ensuring the value appreciation of ETH, scalability is solved from all aspects.
Despite the huge uncertainty between the current state and the theoretical future, we take for granted that all stratification assumptions work as advertised.
Ethereum’s DA is currently around 83 KB/s. With the introduction of EIP-4844 later this year, that speed could roughly double to around 166 KB/s. EigenDA could add an additional 10 MB/s, but would require a different set of security assumptions (not all ETH would be re-collateralized into EigenDA).
In comparison, Solana currently offers a DA of about 125 MB/s (32,000 shreds per block, 1,280 bytes per shred, 2.5 blocks per second). Solana is much more efficient than Ethereum and EigenDA. In addition, Solana’s DA scales over time according to Nelson’s Law.
There are ways to scale DA through rehypothecation and modularity, but these mechanisms are simply not necessary today and would introduce significant technical and social complexity.
Built for application developers
After years of thinking about this, I have come to the conclusion that modularity should not be a goal in itself.
Blockchain must serve its customers, i.e. application developers, and therefore, blockchain should abstract infrastructure-level complexity so that developers can focus on building world-class applications.
Modularity is great. But the key to building winning technology is figuring out which parts of the stack to integrate and which to leave to others. For now, integrating DA and chain of execution inherently provides a simpler end-user and developer experience, and will ultimately provide a better foundation for best-in-class applications.
