Abstract
General principles and background of Cambrian
Last updated
General principles and background of Cambrian
Last updated
Modular versus integrated is perhaps the most debated topic in the field of distributed system design today. This approach can be compared to the implementation of monolithic and microservice architecture in system design. In microservice architecture the code is divided into separate modules, each function has a separate service. Each software component is designed for a specific function and developers can use separate technology stacks for each service and separate microservices to support separate operations. Also, each service can be deployed, scaled and updated independently, enabling continuous integration and continuous delivery (CI/CD), which is also applicable to the modular architecture that Cambrian's approach enables.
It can be debated as to whether in the long term the modular approach or the integrated one emerge dominant, what’s clear is that in the foreseeable future they coexist. As curious builders, we often wonder whether there are learnings Solana can take from Ethereum and vice-versa.
Few deny the fact that both Ethereum and Solana house capable, independent-thinking devs and researchers. Thus, beyond tribalism, it makes sense to question why they work on the areas they do. Ethereum, after all, started as the world’s super computer.
However, even a super computer can’t power a single popular web service, let alone a decentralized network. Memory accesses and bandwidth bottlenecks make sharded designs more efficient for large-scale applications. This became crystal clear with the recent congestion on Solana.
Even then, the current upper limit of 12m CUs only allows 4 popular apps to exist simultaneously before hitting the 48m block limit. There are diminishing returns to what can be achieved w more hardware. Increasing the number of cores doesn’t linearly increase parallelizability.
New compute networks like, AI projects , onchain games may prefer Solana’s practicality-first approach but might want to use new design patterns like the coprocessors. We believe modularity is the key to composability. Cambrian gives applications the flexibility they deserve. It strengthens $SOL's position as an Internet money and allows us to combine vertical scaling with horizontal computing and data segmentation.
A range of new sectors including zero-knowledge cryptography, dePIN, artificial intelligence and machine learning have been gaining momentum over the past year. However, all these technologies require professional players (relayers / validators / proovers) who solve tasks specialized for these projects. And we are facing one of the key limitations for the growth of the ecosystem – bootstrapping new middleware networks.
Launching new networks is one of the key and difficult tasks in the development of any on-chain project. Why? Every network is facing the “cold start problem”: gaining users makes the product more useful and sustainable both for validators and other users. But on day 0, there are no paying users on the network and, accordingly, there is no utility for validators. And if there are no reliable validators, then users do not have trust in such a network. This chicken-egg problem usually has been solved by incentivizing early network participants.
The basic idea is: Early on during the bootstrapping phase when network effects haven’t kicked in, provide users with financial utility via token rewards to make up for the lack of native utility. - Chris Dixon (a16z)
Cons of low-trust middleware which creates barriers for innovations: - Middleware: high cost of capital - dApps: low trust model - SOL: low-trusted dApps lower trust in Solana ecosystem, security standards are not unanimous
Pros of sharing trust with SOL: - Middleware: zero-margin cost of capital, no bottleneck - dApps: higher core trust from SOL holders and stakers - SOL: value alignment from new innovations contributing back value to SOL ecosystem and holders
It may seem that the problem is solved. However, early-stage networks’ token is extremely volatile by nature and has weak distribution which makes such networks easy targets for attacks. Another problem that projects are facing during the early distribution period is the death spiral; when a drop in the price of a token reduces the interest of users & validators, making the network less secure and, as a result, even less interesting for participants.
An option is launching a curated model (progressive decentralization playbook), though it also has its own drawbacks: often such decisions lead to the fact that the network remains locked in the hands of the team, never achieving the required level of decentralization.
