Specialization, the Dark Side of Modularity
There are two notable trends that dominate the R&D done in web3 infrastructure at the moment. Both trends fall under the banner of modularity.
First, there’s modularity in the reinvented sense. That is, modular blockchain stacks. This sense of “modular” term is native to web3.
Second, there’s modularity in the conventional sense of software engineering. I've seen this trend of modularity be at the forefront of the Interchain Stack roadmap we did in Informal Systems (alongside other core organisations in the interchain). The first strategic theme for the interchain was to “increase modularity.” In some form or another, the modular direction made its way in the roadmap of every element of the stack. Outside of the interchain, a few representative technology providers that take similar approaches would be OP stack, Polygon 2.0, or zkSync.
Whether modularity appears as a top design principle in the first meaning or the second, it’s a symptom of variation. The more variation exists in the needs of developers, the more generality – and hence modularity – is required for the tools these developers use. This doesn’t guarantee or cause some sort of success, but variation does correlate with experimentation and growth. Both are good signs.
If modularity is over-used, however, there’s a potential problem.
Specialization
When an application requires something customised from one of the building blocks it is using – say a custom mempool, or a specific way of building blocks to counter MEV – that can indicate (at least) two things:
- It can indicate that there is some general variation across the needs of application developers, as I wrote earlier. This puts pressure for modularity on the building blocks (e.g. CometBFT or Cosmos SDK) that those developers are using. In turn, this leads to the emergence of some of the narratives centered on "modularity". These are driving the building blocks to become more modular and thus satisfy the needs of application developers.
- It can indicate that this application is doing something different, and, in the context of the apps/infra cycle, it may well be an example of a breakout application. If so, then there’s good reasons to treat this application differently. The right response is not for the infrastructure (i.e., the building block) to become more modular, and for the team to pat itself on the back that they did a good job to “enable” the application developers. That approach might be too slow. Instead, the right response is likely specialization: The providers of infrastructure should contribute actively to moulding to the needs of that application, safely and fast, while ignoring the need for modularity at least temporarily.
Both cases are highly interesting, and are not mutually exclusive. Both should be considered. But it takes different skills reasoning about each. In the first case, we think of the problem through engineering lenses (i.e., as a technology, as APIs that need to evolve, as a technical debt issue). In the second case, we think of the problem through product lenses (i.e., "is this application gaining traction, solving a pressing need in the right way?" or "do we have convincing signs or hypotheses about the potential to be a breakout application?").
Balance
Given time and energy constraints, it’s impossible for a team to follow both the modularity and specialization pattern.
Over-focusing on modularity will slowly erode the impact of the building block, like the adage goes, "if something is for everyone then it's good for no one." It will also hinder the success of the potential breakout application, having industry-wide consequences.
Over-focusing on specialization can result in mercenary work: The building block molds itself to the needs of few various use-cases, with customised elements living in forks and obscure deployments, leading to fragmentation, bad UX, and high barrier to use.
A strategic approach to balance would likely help. To weigh the needs of the many against those of very specific (maybe exotic) applications with very high potential impact. I haven't seen such a strategy in play yet. In fact I haven't seen specialization seriously considered as a solid approach to support growth at all. Some application developers took it into their own hands to specialize the building block to their needs, which is great, and which makes me wonder how much more could be achieved if the infrastructure team itself contributed.
There's a lot of emphasis on "public goods." This seems to be driving the modularity approach, covertly. In any case, the reason why I call specialization the dark side of modularity is because it is the technique complementary to modularization, under-appreciated but necessary, a sort of a blind spot in the industry.
