Foresight Ventures: Broken Composability

Source: Foresight Ventures

"Composability refers to the ability to recombine components into larger structures, where the output of one component can serve as the input to another. The best example is Lego, where each piece can connect to another."

Great Composability… Right?

Holy composability! Composability has brought us financial Lego (standards like ERC-20 and OpenZepplin), financial Lego (various combinations of DeFi protocols), and media Lego (NFTs).

Composability allows innovative developers to take others' Lego (contract source code), tinker with it, and create a new product, just like building with Lego.

Composability is like compound interest! Users can also unlock infinite possibilities for their assets by interacting with the different new products they create.

The composability of Web3 resembles a microservice architecture that references Lego rather than copying it, making it more powerful but also more dangerous (the board effect is evident and deadly).

Crypto = Composability (open-source data and code + interoperability + liquidity integration) + incentives, but as an essential component of Crypto, the Lego of composability is actually a precarious structure that could collapse at any moment.

Composability === Complexity in Development and Use

One example is that every codebase (without exception) is a mess (mature projects from the Web2 era are already complex just in terms of the number of lines of code).

The more combinations there are, the higher the complexity, which means a greater chance of errors during development or use, leading to more bugs.

For instance, asking you to read this article and like and share it is easy; but if you have to monitor Bitcoin's price while peeling an apple and riding a bike, it becomes very difficult to accomplish all these tasks simultaneously. You may be doing many things at once, being highly efficient, but you are also very prone to making mistakes.

The image above shows the changes in Ethereum's Sharding proposal. The design goals of the EVM include [simplicity and fewer external dependencies. Even very complex ideas often have a "reasonably simple" version. Sometimes, it may not be necessary to have so many combinations and engineering, making things overly complicated.

Composability === Risks of Software Dependencies

Composability often implies that certain projects must combine with others to function, which is the risk of software dependencies.

Imagine you want to create a DEX aggregator; you have to wait for the DEXs to be aggregated to go live on the network. You must combine them to leverage the beautiful composability. But this also means you have to wait for Uniswap to propose a proposal, pass it, and deploy it before you can launch your aggregator (by the way, in many cases, using Uniswap directly is better than using an aggregator).

A more obvious example of dependency caused by composability is that without the EVM, applications cannot go live. The EVM has become an indispensable part of composability, which is why it is so important for many ecosystems.

Sometimes, developers and users rely too much on composability. Composability provides developers with quick access, but perhaps longer wait times; it also brings existing code, but it may lead to a collapsing domino effect.

Composability === The Domino Effect of Open Source Projects

Continuing from the previous discussion on the dependency issues of composability, this long chain of dependencies turns the Lego of composability into a domino effect.

Examples of open-source supply chain poisoning have become increasingly common, such as the actively poisoned (though perhaps with good intentions) Faker.js and node-ipc, as well as Log4j, which inadvertently compromised the security of the entire internet (it seems Java has had issues again recently).

The root causes of these problems are:

1. Developers do not review all the source code; they just copy and paste (Can devs do something?)

2. The incentives in ordinary open-source communities are insufficient to support sustained development. (One contributor has to feed 80,000 users)

To address these two root causes, 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, from these problems, we can see that fully entrusting development to the community is also not advisable (JavaScript community), and we cannot rely too heavily on community contributions, as this may lead to a lack of standard libraries, and community development under incentives often cannot guarantee long-term support. We still need some neutral and effective organizations to decide on the inclusion of certain standards and to guide funding incentives for the development community.

(By the way, Ethers is the most used third-party library in the EVM ecosystem, with a weekly download volume of around 680,000, but this is only about 5% of the "Web2" front-end framework React; according to Electric Capital's data, the number of Web3 developers accounts for about 0.07% of all developers. Web3 development still has a long way to go.)

Returning to Web3, if OpenZepplin encounters some risks, the victims will not only be our software but also our most valuable funds, which is quite frightening.

Composability === More Obvious Disadvantages of DAOs

This year is also the year of DAOs. DAOs have become the default practice for communities.

The composability of DAOs indeed allows organizations to thrive together like grafting.

However, as a decentralized organization, the disadvantages of DAOs include slower and more difficult decision-making, an inability to measure contributions to work, and sometimes the abuse of power.

The highly composable nature of DAOs makes them overly decentralized and complex, amplifying the three aforementioned disadvantages geometrically.

Composability exacerbates the disadvantages of DAOs.

Composability === Inflated Financial Bubbles

The dangers of composability in the traditional sense of financial bubbles are, I believe, self-evident.

Taking NFT derivatives as an example, the financial projects of NFTs are continuously stacking blocks, making the entire NFT industry increasingly complex, leading to more opportunities for arbitrage attacks and other attacks. As these financial products stack upon each other, and these products are recognized by insurance companies (think of auditing agencies), the risks are transferred from the wealthy who can afford BAYC to the general consumer. Ultimately, when the bubble bursts, the ones who suffer the most are ordinary users.

Do you remember what happened in the year the Bitcoin genesis block was born?

Conclusion

Regarding composability, we need to understand both its advantages and its disadvantages. For every disadvantage mentioned in this article, I can counter it with the advantages of composability, but we still need to be aware of these disadvantages, rather than letting composability become a puppet for anyone to dress up.

There is still much room for improvement in composability, even though it has already helped us create an infinite number of magnificent masterpieces (Web1 + Web2 + Web3). We need more, better, and more attention-grabbing fat protocols (I know the theory of fat protocols is somewhat unreasonable…), credible neutrality, and acceptability.

Composability is 99% combination and 1% broken.