Since launching zkApps in Mina’s Berkeley release this June, all of us at o1Labs have been excitedly watching the progress builders have made on the platform. We've seen a flood of incredible projects and heard from droves of talented developers. We've been challenged to make the platform even better and more flexible to help these applications achieve their fullest potential.
At o1Labs, we thrive on hard problems. From building the first zk-rollup before the concept even existed, through building the first prover marketplace – the Snarketplace – as part of Mina, to launching the first universal, composable zk application platform, we pride ourselves on identifying the real needs of the future and building the right solution the right way. Even as other ecosystems struggle in their infancy, we believe the next hard problem is clear: decentralized, trustless applications require decentralized, trustless state.
How web3 has managed its state so far
Web3’s limitations in state management are painfully evident. Today, only small amounts of data can be stored on-chain—and at exorbitant costs. Applications with a small amount of state, or those willing to pay a premium for state storage, can build on their native platforms and use the limited and expensive state capabilities that these platforms provide. This harsh ceiling on applications has stifled the development of big-data applications like social networks, distributed databases, and AI applications that require large models and datasets.
Developers have had to compromise to overcome these constraints - settling for limiting their applications or paying high prices. Many have resorted to layer-2 chains tailored to specific applications, re-creating the infrastructure of existing platforms to make a home for their state and execution environments. The promise of decentralization for these systems lingers, but the pattern that we see again and again is for these chains to be born and, unfortunately, remain centralized, losing even more of the properties that applications set out to achieve.
We’ve seen this firsthand in the Mina ecosystem, where even the incredible work on the Protokit app-chain platform hit against the same set of compromises. As a modular framework, Protokit currently allows developers to choose between based-sequencing – using the L1 for censorship resistance and data availability, at the expense of speed and UX – or a centralized mode with a private mempool, at the expense of censorship resistance. We all want a solution that doesn’t ask developers to make any compromises. We’re eager to continue working with the Protokit team on achieving full decentralization, and we’re excited by the prospect of a close integration with our solution, so that we can address this risk fully for the Mina community
Another approach that once held great promise is to upload snapshots of the state to storage systems like IPFS. In practice, we've seen these systems poorly matched to the needs of applications: integrating with them is complex, the wasted expense of storing old snapshots is high, the process of sending these snapshots is cumbersome, and an update to a single byte requires a full download and re-upload. The lack of random-access reads and writes places a high burden on applications, and their resulting redesigns often sacrifice user experience and functionality just to get something working.
Data availability solutions have also played a role, and still show potential. The ability to submit data, propose updates, and use the chain to rebuild and recover the state is a general-purpose step in the right direction. This comes with a high cost: recovering the state involves re-applying updates, filtering through unwanted noise from other applications, and bringing a high complexity cost for users and developers. Thus, for this use case, it does not make sense.
For us, the need is clear. These tradeoffs of cost, censorship, and performance are not acceptable. We must do better.
How state should be managed–Our belief in a better future for state management
We believe Web3 applications shouldn’t have to compromise on decentralization, cost, or performance. In Web2, applications can easily request the space and resources they need for their state, update it cheaply as often as necessary, and have all the tools to make their backups and recovery trivial. It’s time to bring this standard to Web3.
The rapid advancements in zero knowledge proof cryptography have unlocked the tools needed to solve this challenge. Drawing from our experience building Mina, we knew that the most important property was to forget history – to be lightweight, efficient, and accessible from everywhere, only the most recent data is relevant. Developers should always be able to choose to record history, but keeping history forever just to operate your app is not reasonable, not scalable, and not sustainable for decentralization. Developers should have the flexibility to focus on only the data that matters most.
Bringing the same principles that built Mina to its zkApps to applications across Web3, we can empower developers to build truly decentralized and trustless solutions without compromise.
Ready for more?
To learn more about how we're solving this challenge, check out our [Project Untitled] overview for an introduction to the vision behind our approach. And we’ll continue to share more technical updates along the way. For developers eager to discuss this project, share feedback, and stay updated, join our Telegram group to be part of the conversation.