Composability refers to the ability to reassemble components into larger structures, and for the output of one component to be the input to another. The best example of this is Lego where each piece can be connected to another.

Composability is Great…?

The great composability! Composability brings us Money Lego (standards like ERC-20 and OpenZepplin), Financial Lego (combinations of DeFi protocols), and Media Lego (NFT).

Composability is innovation! Developers can take someone else’s Lego (contract source code), tinker with it, and create a new product, just like building Lego blocks.

Composability is compound interest! Users can unlock the infinite possibilities of assets by interacting with each other in a large pool of products.

The composability of Web3 resembles a microservice architecture that is not a copy of Lego, but a reference to it, more powerful but also more dangerous (the plank effect is more obvious and deadly).

Crypto = Composability (open source data and code + interoperability + liquidity aggregation) + Incentives, but as a key component of Crypto, an important variable that can be infinitely multiplied, the Lego of composability is actually a wobbly Jenga game.

Composability === Complexity of Development and UX

One example is that every code base (without any exception) is shit (look at some notable projects in Web2, where the number of lines of code alone is already complex).

More composabilities mean more complexity, which means more potential for error and more bugs in development or usage.

For example, if you’re asked to read this article then like and retweet it, you can easily do that, but if you’re asked to keep track on the price of bitcoin, cut apple peels, and ride a bike at the same time, you’ll have a hard time doing all of those things simultaneously. You do get a lot of things done at once, and you’re very efficient, but you’re very error-prone.

The diagram above shows the changes to the Ethereum Sharding design. The design goals of EVM include simplicity and fewer external dependencies. Even very complex ideas often have “reasonably simple” versions. Sometimes it may not be necessary to combine and over-engineer things too much, to make things too complex.

Composability === More Risky Software Dependencies

Composability often means that some projects must be depending on other projects in order to run, and this is the risk of software dependency.

Imagine you want to build a DEX aggregator, then you have to wait for the aggregated DEX to be launched on the network, and you have to combine and connect them to make the best of the composability. But this also means that you have to wait for Uniswap to make a proposal, pass the proposal, and deploy the new contract before you can bring your aggregator alive (BTW, in many cases it is better to use Uniswap directly than an aggregator).

A more obvious example of composability causing too much dependency is that without EVM, the network would not be able to get the application launched. EVM has become an integral part of composability, which is why it is so important to many ecosystems.

Sometimes, developers and users rely too heavily on composability. Composability gives developers faster access to existing projects, but perhaps longer wait times; it also gives them existing code, but the possible collapsing dominoes.

Composability === Domino of Open Source

Following on from the composability causing dependencies problem in the previous section, this long list of dependencies actually turns composable Lego into Dominoes.

Examples of open source supply chain poisoning are common these days, such as Faker.js and node-ipc, which poisoned by intention (though with the best of intentions in their mind), and Log4j, which accidentally compromised the security of the entire Internet (there seems to be another recent security issue with Java).

The root cause of these problems is still :

1. Developers never look at all the source code, they just copy and paste (Can devs do something?)

2. The incentives of the general open source community are not enough to support sustained development. (One contributor has to provide support for 80,000 users)

To address these two issues, we need third-party auditing services, decentralized development communities, reasonably incentivized DAOs, more Gitcoin donations, and more funding allocated to infrastructure.

At the same time, it is clear from the questions that it is not desirable to leave too much development to the community (the JavaScript community). It is not possible to rely too heavily on community contributions, that there may leading to a lack of standard libraries. The usual incentives for community development may not guarantee long-term support. We still need some neutral and effective organization to decide on the inclusion of standards, and to guide the financial incentives for the development community.

(By the way, Ethers is the most used third-party library in the EVM ecosystem, with around 680k weekly downloads, but only about 5% of the “Web2” front-end framework reactjs. According to Electric Capital, the number of Web3 developers is about 0.07% of all developers. Web3 development still has a long way to go.)

Going back to Web3, if something were to happen to OpenZepplin, it wouldn’t just be our software that would be hacked, it would be our most valuable assets, and that’s scary.

Composability === DAO with Disadvantages More Disadvantageous

This is the year of DAO, again. DAO has become the default practice of setting up the community.

The composability of DAO does allow organizations to flourish together like grafting.

But as a decentralized organization, DAO has the disadvantage of slower and harder decisions than firms, the inability to measure the contribution of work, and sometimes the abuse of power.

DAOs full of composability make DAOs too decentralized and complex, and the above three drawbacks are exponentially magnified.

Composability makes DAO’s disadvantages more disadvantageous.

Composability === Financial Bubble on Steroids

I believe it goes without saying that the dangers of composability in the traditional sense of a financial bubble.

Take NFT derivatives for example, NFT financial projects are building the blocks, making the whole NFT industry more and more complex, and increasing the opportunities for attacks such as arbitrage attacks happen. And these financial products are building on top of each other. These products are approved by insurance companies (like auditors). The risk is transferred from the rich who can afford BAYC to the mass of consumers. In the end, when the bubble bursts, it is the average user who suffers the most.

Remember what happened the year the Bitcoin Genesis block was mined?

Conclusion

For composability, we need to know its advantages as well as its disadvantages. For each of the disadvantages I mentioned in my article, I can counter them with the advantages of composability, but we still need to know the disadvantages, rather than letting composability become a slogan.

Composability still has a lot of room for improvement, even though it has helped us create infinitely larger and more beautiful masterpieces (Web1 + Web2 + Web3). We need more and better and more attention to fat protocols (I know the fat protocol theory is a bit broken…) , trusted neutrality, and acceptability.

Combinability is composing by 99% and decomposing by 1%.