Down the Rabbit Hole (Part 2): A Blockchain May Be Many Things Underneath
When Alice fell, she did not land in chaos. She landed in a world with different rules.
This is a continuation of the previous article, Down the Rabbit Hole (Part 1). If you have not read it yet, you can find it here.
In Part 1, we followed the path from classical distributed systems to peer-to-peer networks, to monolithic blockchains, and finally to the scaling wall. The main theme was coordination. We saw how coordination costs never disappeared but merely transformed once trust was removed from the system.
We build on that foundation in this part: It is about what happens when we stop treating “the blockchain” as a single object and begin to analyze the structure underneath it, following the abstraction further down the rabbit hole.
A blockchain is not a single machine that can be optimized in isolation.
It is a network where thousands of independent nodes execute the same transactions, verify the same state transitions, propagate the same data, and participate in the same consensus process. Scaling such a system by increasing throughput, reducing latency, or improving hardware performance means raising the resource requirements for every validating participant simultaneously. If performance doubles, bandwidth, storage, and computational demands increase across the entire validator set. In a network with tens or hundreds of thousands of validators, that cost scales with the network itself.
When we look more closely, what we call a blockchain is a composition of distinct responsibilities that were brought together in early designs for security reasons. A full node executes transactions, participates in consensus, ensures that transaction data is available to the network, and settles the resulting state. These roles coexist inside the same abstraction, and for a long time we thought they were inseparable.
But in time, it became harder to ignore that these responsibilities do not share the same constraints. Scaling computation is not the same as scaling coordination, and ensuring data is available to the network is not the same as ordering transactions.
In reality, we were attempting to scale multiple fundamentally different problems simultaneously, under the illusion that they were one.
Data Availability: The Invisible Constraint
Layer 2 solutions separated execution from the base layer, as we discussed in Part 1. Transactions no longer needed to be executed by every node, reducing congestion and lowering costs. But this system only focused on the execution part of the architecture.
Even if computation moves off-chain, the system still needs to agree on ordering and ensure that transaction data is available to everyone. Without access to the underlying data, no one can verify anything: a proof is meaningful only if the inputs behind it can be reconstructed.
In a monolithic design, data availability is guaranteed by requiring full nodes to download and store all transaction data. This guarantee makes verification possible. That is, if a validator does not have the data,
it cannot check the state transition,
validate a settlement claim,
challenge incorrect execution.
However, it also ties throughput directly to bandwidth and to storage limits. As blocks grow, more data must be propagated across the network, and every validating participant must keep up. Unlike execution, which can be optimized or aggregated, data must ultimately be published in raw format somewhere so that others can verify it.
The system is therefore constrained not only by computation, but by how much data can be safely propagated and verified across the network.
Modularly Designed Blockchains
At this point, the idea of a single, indivisible blockchain is not the default starting point when designing a new one. What we once treated as one machine starts to separate into its parts: execution, consensus, and data availability no longer move as a single unit. They respond to different pressures, scale under different constraints, and fail for different reasons.
It is almost like the Cheshire Cat. The original blockchain form is still there, but it begins to dissolve. At first execution faded from the base layer, then data availability stood out as its own constraint. What remains is not a broken or torn-apart system but a clear view of what has always been underneath.
Modularly designed blockchains acknowledge that the responsibilities within a blockchain are distinct and do not need to live together to create and preserve network integrity. Execution can live in one place, consensus in another, and data availability in yet another, as long as the layers can verify and enforce each other’s assumptions through proofs, incentives, or challenge mechanisms.
At this point, one might argue that separating these responsibilities introduces fragmentation. If execution, consensus, and data availability no longer share the same environment, do we lose the native coordination that the previous design provided? Does separation simply move the bottleneck elsewhere?
It is a valid concern, but the constraint was already there. Scaling computation, coordination, and data distribution are different problems. Keeping them together was necessary for security and separating them simply acknowledges that they scale differently.
What we call a blockchain is still there, but as a stack of different layers rather than a single machine.
App-Chain Consequence
If execution no longer has to live inside a single shared environment, and if data availability and consensus can be provided as separate layers, as rollup architectures already separate execution from ordering and finality, why should all applications compete for the same block space?
Different applications have different requirements.
A payment system values predictable fees and fast confirmation.
An NFT-oriented network cares about storage patterns and minting throughput.
A DeFi environment depends on low-latency state updates and composability.
A natural idea follows from these differences: can we separate these applications into customized execution environments while keeping interoperability intact?
In this environment, applications benefit from what we call a network effect. Liquidity is accumulated in one place, state is shared across protocols, and composability becomes native. Protocols can interact directly without any additional layers of coordination or trust assumptions. An increase in chain activity on a certain application increases the competition for block space and fee markets intensify. So, the resource, block space, usage in one application directly affects others.
These application-specific needs reflect different assumptions about how data is used, how state grows, and how coordination takes place within the system. The network effect concentrates liquidity and composability in one place, but it also creates constraints. A network optimized for simple transfers does not carry the same structural demands as one optimized for complex financial transactions.
Following from this difference, application specific blockchains focus on the approach that execution can be defined around the needs of a particular use case while relying on shared layers for security or data availability. And it reduces the competition within a single block space as the chain is designed for a specific type of execution rather than every possible one.
However, liquidity no longer concentrates by default: it becomes distributed and fragmented across chains. And coordination takes a different form. It moves to interoperability, liquidity movement, and communication across chains. Each app-chain must define its own coordination playbook. That is, how it connects to others and how these interactions are maintained within its own system design.
What we have now is a network of specialized environments connected through new coordination mechanisms.
How Deep Does the Rabbit Hole Go?
We started with distributed systems and a familiar problem: coordination under constraints. When a single operator exists, coordination can be enforced. When trust disappears, coordination must be embedded into the protocol itself.
Layer 2 solutions reduced the execution burden. Modular architectures separated responsibilities. App-specific chains specialized execution. And each step looked like a scaling solution, but was also a redistribution of constraints. Execution moved. Data availability became visible. Consensus remained.
Nevertheless, we saw that as layers separate and chains specialized, coordination did not vanish. It becomes distributed across interfaces, interoperability mechanisms, and shared security assumptions. The surface changes, but the original constraint remains.
The rabbit hole may not end with modularity or app-specific chains. As layers separate and chains specialize, new coordination surfaces emerge.
We may not have reached the bottom. But we now understand that scaling in adversarial environments is less about speed and more about architecture.
We have a long way to go to find new architectural designs.
A long way to go down through the rabbit hole…
 | A guest post by
|