Theme: Light

The Modular Stack Is a No-Brainer

‘Modular’ is all the rage in blockchains today. Add the word ‘modular’ to your pitch deck and you’ll probably raise a few extra $$ than you would otherwise. (jokes)

Ironically, for an industry that’s at the frontier of innovation, modularizing the stack is a development paradigm that’s been around for decades.

For the uninitiated, a modular blockchain is one that outsources at least one of the four core functions of a blockchain - consensus, data availability (DA), settlement, and execution.

Modular software, on the other hand, provides a toolkit for ‘building blockchains that separate the core functions among different pieces of software.’

A modular blockchain != modular software

As of writing, there are no modular blockchains in production. And yet, building a modular stack is a complete no-brainer. What do I mean by that?

Development in the monolithic paradigm

A developer building a traditional Web2 application can choose the different components of their tech stack, such as front-end + back-end frameworks, database, OS, and other dev tools for testing, auditing, etc.

This development model offers freedom and choice to the developer, to pick the tools that are suitable for them to build their product.

Blockchain development for decentralized apps is nowhere near offering this degree of freedom to application developers. But we’re getting there.

Developers are still forced to deploy their contracts on a monolithic chain that intrinsically restricts them to a narrow design space for experimentation. If you choose to deploy your application on the EVM, you can only write code in Solidity or Vyper. The EVM itself imposes a series of limitations on the developer. For example, the EVM has a depth of 1024 items, where each item is a 256-bit word. This inherent limitation means that exceeding the stack depth can cause errors and result in the smart contract failing to execute correctly.

Similar constraints extend beyond the EVM and to other execution environments as well, such as the SolanaVM (SVM), Cosmos SDK, etc.

Deploying your application on a monolithic L1 is akin to being forced to write a web app using Ruby on Rails, Linux, MongoDB and nothing else, even if these software components are not the best fit for your application requirements.

Development in the modular paradigm

On the other hand, modularity enables one to pick the VM of their choice and plug into a suitable DA layer.

For example, say you’re a developer that wants to deploy a game on some blockchain. You probably don’t want it to live on the EVM due to its sequential execution model. You know that the SolanaVM (SVM) is great for parallelization, but you’re wary of the downtime Solana consistently has. By opting for a modular stack, you can leverage the SVM for parallelization, while at the same time using a DA layer with a battle-tested consensus algorithm like Tendermint.

Or maybe you’re a Solidity developer who wants to write a DEX application. But you don’t want to opt for the EVM since it makes no sense for your application to compete for block space with other Ethereum L1 or L2 apps. In a modular paradigm, you can still deploy your DEX as a rollup on an EVM-compatible environment, while slotting in completely new DA and settlement layers.

In this manner, you can pick and choose what works for you best, instead of being restricted to a particular execution or consensus constraints.

Note that I’ve said nothing about the advantages of a modular stack aside from the benefits it brings to developers. Relative to a monolithic one, a modular blockchain offers improvements in scalability (bigger blocks without increasing the cost to run a full node), decentralization (light nodes that operate with the same security guarantees as a full node), efficient resource pricing (dedicated block space for each rollup), etc.

To me, the rise of modular blockchains feels like this industry reaching a point of maturity in terms of blockchain application development.


back home