Have you noticed that the structure of blockchain has completely changed? In the past, blockchain architecture could be described with one term: monolithic structure. But now? Blockchain is moving toward a “modular structure.”
What is a monolithic structure? If you think back carefully, you’ll realize that early blockchains basically had one chain doing everything:
Executing transactions
Storing data
Handling consensus
Completing settlement
This approach is simple, but the problem is also obvious: once any part becomes a bottleneck, the entire system slows down.
Once you understand this, the idea of a “modular structure” becomes easy to grasp—split these functions apart so that each layer does only one thing. That way, even if one layer encounters a bottleneck, the entire system won’t be heavily affected.
And that’s exactly what we’re discussing today: Modular Stack Composition.
A simple definition first
Modular Stack Composition refers to an architectural design approach that splits a blockchain system into multiple functional modules and then combines them based on needs.
There is only one core change: from “one system does everything” to “multiple modules work together.”
Problems with monolithic structures
Because all capabilities are tightly coupled, several issues arise:
Difficult to scale: improving performance requires upgrading the entire system, which is costly and complex
Poor flexibility: different applications have different needs, but the system cannot optimize for them individually
Resource waste: some functions are not needed by all applications, yet must still run together
So the goal of modularity is very clear: make the system more flexible and more efficient.
In a modular architecture, the system is usually split into several core layers
1. Execution Layer
Responsible for processing transactions and computation, focusing on speed and performance.
The execution layer can be understood as the part of the system “closest to the user.” Almost all user operations happen here, such as trading, contract calls, and asset interactions.
This also means it must be fast—otherwise, user experience will suffer.
In modular design, the execution layer often adopts more flexible approaches, such as optimizing computation methods or relaxing certain constraints to improve efficiency.
But it’s important to note: it does not carry final security responsibility. Its focus is “efficient computation,” not “final confirmation.”
2. Settlement Layer
Responsible for final confirmation, focusing on security and immutability.
The settlement layer acts as the system’s “bottom line.” No matter where transactions are executed, the final result must be confirmed here.
Once written into the settlement layer, the result is recognized by the system and cannot be easily changed.
Therefore, this layer usually adopts stricter security mechanisms, such as stronger consensus rules or higher decentralization.
Compared to the execution layer, it can be slower—but it must be reliable. You can think of it as: “better to be slow than wrong.”
3. Data Layer
Responsible for data storage and availability, ensuring that data can be accessed.
The data layer solves a commonly overlooked problem: data must not only exist—it must also be accessible.
In many designs, execution results need to be verified, and verification requires data availability. If data is lost or inaccessible, even the most secure system cannot verify anything.
So the role of the data layer is not just storage, but ensuring that data can be retrieved by any participant when needed.
This is why data availability is becoming increasingly important in modular architectures.
4. Consensus Layer
Responsible for network consistency, ensuring all nodes reach agreement.
The role of the consensus layer is to ensure that the entire network has the same view—for example, whether a transaction is valid or whether a state is correct.
Without consensus, different nodes could produce different results, and the system would not function properly.
In modular design, the consensus layer usually does not directly handle execution or storage details. Instead, it focuses on “achieving agreement,” allowing other layers to focus on their own tasks.
These modules can exist independently or be combined
In real systems, very few projects rely on a single structure. More often, modules are combined based on needs:
Some projects strengthen the execution layer to pursue higher performance
Some rely more on the settlement layer to emphasize security
Others focus on optimizing the data layer to improve data handling
Different combinations correspond to different system characteristics. This flexibility is exactly what gives modular architecture greater scalability than traditional monolithic structures.
The key is not just splitting, but “how to combine”
Different projects can choose different modules based on their needs:
High-performance applications → stronger execution layer
High-security requirements → stronger settlement layer
Data-intensive scenarios → stronger data layer
Different combinations lead to different capabilities.
Core principles of module composition
Choose based on needs: not every module needs to be the strongest—only sufficient for current requirements
Decoupled design: modules should be as independent as possible for easier replacement and upgrades
Scalability first: new modules can be added in the future, giving the system room to grow
Advantages of this architecture
Higher performance: each module can be optimized independently
Lower cost: only necessary resources are used, reducing waste
Greater flexibility: structure can be adjusted based on scenarios
1-minute recap
Modularity means “split tasks”
Composition means “combine as needed”
The goal is to improve efficiency and flexibility
Conclusion
Blockchain is evolving from “one system does everything” to “multiple modules working together.” Modular Stack Composition is at the core of this transformation.
It makes systems no longer rigid, but adaptable based on needs.
In the future, blockchain may not be a single chain—but an entire system that can be freely composed.
