tl;dr
- Vendor lock-in: difficulty moving away from StarkWare’s ecosystem
- System centralization: the Sequencer and the Prover are operated by StarkWare
- Steep learning curve: Cairo is hard to learn and the documentation has gaps
- Upgradable smart contracts: StarkWare can make changes at any time
Introduction
The moment I learned of the existence of a zk-rollup that used STARK instead of SNARK to generate validity proofs on Ethereum I got very excited. I thought that the holy grail of smart contract scalability was already here. While writing another article reviewing StarkNet’s architecture I started to discover some of the shortcomings of StarkWare’s ecosystem, some of them shared with other rollups. Below you’ll find some of the challenges that could put StarkNet’s success in jeopardy based on my perceived level of importance.
1) Vendor Lock-In
Only a small subset of the technologies developed by StarkWare are open source. This includes the Solidity smart contracts and the Cairo programs developed by StarkWare that are deployed to Ethereum, StarkNet and StarkEx.
The Cairo compiler license is more restrictive and although is open source and free to use, it doesn’t allow for external parties to make modifications beyond “fixing errors”. This decreases the level of involvement of the community in further developing the tooling or experimenting in different directions.
The critical piece of StarkWare’s infrastructure, the Prover service (SHARP) is closed source. This makes it impossible for the community to verify the correctness of the software that generates the proof and therefore its reliability. This also forces any company that might be thinking of deploying their app to a dedicated L3 to enter in a business agreement with StarkWare that could potentially be severed, leaving the dapp, its users and potentially billions of dollars locked in a limbo.
Imagine a company who invests a significant amount of resources developing their backend as Cairo programs to deploy on a dedicated L3 and agrees to a certain fee and conditions to use StarkWare’s Prover service. StarkWare will have all the leverage to renegotiate the fees and terms as it could be too costly for the customer to simply move their backend (smart contracts) to another system that is not Cairo compatible.
2) System Centralization
The Sequencer and the Prover are both centralized services operated by StarkWare. Having single points of failure makes the system vulnerable as the whole network could go offline if any of those systems stop working due to internal errors (ex. faulty upgrades) or external attacks (ex. DDoS).
With StarkWare in control of the Sequencer, users of the network are exposed to the risk of the company selecting which users and which transactions to serve. This could be a vector of attack for any dapp with significant liquidity. StarkWare will also have a privileged position to front run their customer’s transactions for profit in a process known as Maximal Extractable Value (MEV). To be fair, other rollups like Optimism and Arbitrum suffer from the same centralization problem.
StarkWare has stated its willingness to decentralize the system but it’s not clear when that would happen. For a company that wants to deploy their dapp today waiting for the network to be decentralized might not be an option.
3) Steep Learning Curve
Solidity has become so ingrained in web3 that most blockchains go to great lengths to make their system EVM compatible in an attempt to lower the barrier of entry for developers. StarkWare’s ecosystem is so unique that they had to develop their own programming language (Cairo) that allows for the creation of validity proofs of its execution.
Learning Cairo is not easy. As someone with many years of experience as a software developer and exposed to many different programming languages, Cairo has posed a significant challenge that I can only compare to learning Rust as they are both low level languages. In the case of Rust you can at least count on the availability of excellent documentation and a thriving community. Cairo’s documentation is not of the same caliber and the community is still small.
When writing a previous article analyzing StarkNet’s architecture I found the documentation lacking and it was only after getting help from the community on their Discord server that I was able to fill the gaps. For a team considering StarkWare as their platform of choice, they will need to account for the difficulty of hiring developers proficient in the Cairo language and the StarkWare platform.
4) Upgradable Smart Contracts
The smart contracts on Ethereum that are part of the StarkWare platform are not immutable. StarkWare can upgrade those smart contracts at any time, changing the rules of operation of the network without notifying its users and potentially introducing critical bugs that could put funds of projects deployed on StarkNet or StarkEx at risk.
This is likely something transitory of the alpha stage but knowing how long Solana has been in “beta”, well, who knows when that’s going to change.
Conclusion
My initial excitement for StarkNet has waned after learning of the associated risks. StarkWare has stated its plans to work on more permissive licenses, decentralize the network and make their smart contracts on Ethereum immutable. The problem is knowing if they are really going to follow through with those promises and guessing how long is going to take as there is no clear roadmap for those changes. For projects who are ready to launch today, StarkWare’s platform might not be the best place.
As an example, just this week dYdX announced that they will create their own blockchain using Cosmos SDK instead of continue using StarkEx, as they have done until now, to deploy the new version of their protocol. The company claimed that the decision was made in part due to concerns about StarkEx’s performance and decentralization.
Deep down I’m also concerned that StarkWare will never fully open source their codebase as they are a private company that have received extensive investment. Making a profitable business model out of open source software is almost impossible and StarkWare is more likely to follow an AWS-like business model that would require control over their platform.
I believe that web3 can only succeed if the underlying platform is created as a public good, much like web2’s success was thanks to the Internet being a neutral and open platform. Sadly, right now, StarkWare’s platform is neither.
Acknowledgments
- Cover photo by Hermes Rivera on Unsplash