Why existing “modular blockchains” (mostly) miss the point
And the correct way of modularizing blockchains
The modular blockchain narrative
For most of their existence, blockchains were monolithic protocols that implement some trusted functionality in a single protocol, with cryptoeconomically-incentivized consensus obeying a set of protocol rules that directly implement the functionality needed by the user. We can further divide these monolithic blockchains into “application” blockchains like Bitcoin and “platform” blockchains like Ethereum. The former are designed for a specific use case, while the latter — including the vast majority of newer blockchain projects — provide a “world computer” for running arbitrary on-chain logic.
But increasingly, people are realizing that having one blockchain “do it all” leads to very poor flexibility and efficiency. On the flexibility side, people have an annoying habit of finding exciting new blockchain applications, like payment channels and zk-rollups, that existing blockchains just don’t support very well. Fixing monolithic blockchains to accommodate these new use cases involves cumbersome, ecosystem-wide upgrade efforts like Bitcoin’s SegWit or Ethereum’s innumerable hard forks adding everything from new precompiles to sweeping cryptoeconomic reforms like EIP-1559.
On the efficiency side, there’s the famous “blockchain trilemma”: it’s very difficult for a single blockchain to achieve all three of decentralization (many participants), security (must compromise the majority of participants to corrupt the network), and scalability (high transaction throughput). Monolithic blockchains strong at two arms of the trilemma tend to be bad at the third: Ethereum and Bitcoin sacrifice scalability, high-throughput chains like EOS sacrifice decentralization, and unconventional ledgers like IOTA sacrifice security.
Modular blockchains seek to improve flexibility and efficiency by breaking apart the functionality of a platform blockchain into multiple parts which then interoperate. Polynya gives a great rundown, but in short, modular blockchains break blockchain functionality down into three components:
- Execution: the user-interfacing part, executing app code. Often an EVM-compatible interface
- Consensus/security: agreeing that some globally consistent, canonical history of events happened.
- Data availability: storing what events happened. This is different from consensus, since we can separate, say, deciding on a history of transaction hashes with storing the actual content of those transactions.
The idea is that blockchains or protocols can specialize in one area and use other chains to implement other functions. For example, an app might use a fast, low-security EVM-based sidechain to implement execution, a ZK-rollup to back consensus on Ethereum, and a “dumb” sharded chain like Celestia for data availability. Flexibility is improved because these layers can evolve or even be replaced independently of other layers, while efficiency is supercharged since none of the pieces need to solve the “blockchain trilemma” — execution protocols only need scalability, while security protocols only need decentralization and security.
A better way to modularize
Yet the most important property of blockchains is neither flexibility nor efficiency, but endogenous trust — trust based on self-incentivized protocol rules, rather than preexisting trust in blockchain participants. As we have argued elsewhere, endogenous trust is the killer feature of blockchains, not decentralization, transparency, or other widely-touted features. Unlike pre-blockchain decentralized protocols like BitTorrent or PGP, blockchains come with cryptoeconomics that reward correct behavior and punish destructive behavior. When we use Bitcoin, for instance, we only need to that most miners are rational, rather than honest. This promises a fundamental revolution in trust, enabling a wide variety of autonomous or “trustless” applications like DeFi.
Unfortunately, monolithic blockchains do not implement endogenous trust well, even though they invented the concept! This is partly due to ideological reasons — not all blockchain communities take “code is law” seriously — but most importantly, it’s due to tight coupling between application and blockchain. Thus, when new applications evolve, the blockchain is forced to evolve with them, undergoing governance events such as protocol upgrades and hard forks. These consensus-breaking changes not only cause a great deal of disruption and drama in the ecosystem but destroy endogenous trust.
In fact, endogenous trust is also at the root of the flexibility and efficiency problems that plague monolithic blockchains. Neither flexibility nor scalability is hard if we don’t care about endogenous trust — we could just run every Web3 app on its own little private blockchain! The hard part is really building a system that has flexibility and efficiency, but also endogenous trust. Fixing monolithic blockchains’ problem with endogenous trust is thus crucial to any new blockchain model.
At first glance, “modular blockchains” look like the solution. After all, aren’t they all about decoupling? We can build an app on a combination of a secure, immutable consensus layer with top-notch endogenous trust with some less security-critical data availability and execution layers that focus on flexibility and scalability. Can this get us the best of both worlds?
Unfortunately, no. Modular blockchains cannot fix endogenous trust. First, application-protocol friction strikes back on the execution layer. When application requirements change, there would be similar pressures for “governance” on the execution layer to add features, rectify bugs, etc. But this harms endogenous trust even though the supposed “security” layer is untouched! This is because even though the security and data availability layers ensure a consistent history of transactions, these transactions are meaningless without the execution layer interpreting them. Protocol governance on execution layers thus pulls the rug under application-level endogenous trust just as much as governance in layer-1 protocols does.
A deeper problem is that the consensus layer’s endogenous trust is hard to transfer. Even if we have an immutable consensus layer with strong endogenous trust, it’s difficult for that to translate into endogenous trust in the execution and data availability layers — and thus the application. Without any execution or data availability, a “dumb” consensus layer like Celestia may be able to keep track of a consistent transaction history, but cannot check the correct behavior of the execution layer. Every client of the execution layer ends up needing to replicate much of the functionality of a monolithic blockchain full node to accept correct transactions and reject invalid ones. Not only does this force the execution layer to do double duty to provide consensus security, it precludes a wide variety of applications ranging from trustless thin clients to cross-chain contracts.
This is because the security of the execution layer generally requires the consensus layer to do at least some execution to run exit games, accept fraud proofs, check zero-knowledge validity proofs, etc. Indeed, Vitalik Buterin has an excellent blogpost that argues that any consensus layer must have a certain set of features, including flexible scripting, to achieve “escape velocity” and give its endogenous trust to upper-layer protocols. Yet a consensus layer with these features is hardly a consensus layer at all — it’s a monolithic blockchain! The whole modular blockchain design then reduces down to “merely” an L2 on a monolithic L1 rather than a revolutionary rearchitecting of blockchains. This, of course, does not fix any problems with monolithic blockchains’ endogenous trust.
Thus, we see that the modular blockchain model does not have a solution to the biggest problem facing monolithic blockchains — poor endogenous trust. How can we tackle it then?
The answer is a new modularized architecture, but not a “modular blockchain”. Instead of decoupling execution, consensus, and data availability into different quasi-blockchains, we decouple applications from the blockchain. This needs an extremely simple, robust, and governance-free blockchain focused on endogenous trust, with a bare minimum of execution, consensus, and data availability — “escape velocity” —to transfer its trust to higher-level protocols.
And that blockchain is Themelio —a blockchain designed solely as a root of trust for a trustless new Internet. In an upcoming post, we’ll discuss the specific design choices that make Themelio the perfect layer-1 blockchain for this new paradigm of modularization.
