Today, someone asked me why I was building on Starknet. That's a question I've probably been asked a thousand times and answered the exact same way a thousand times. But today, inexplicably, I didn't answer that question. Instead, I asked: What if the right question were, 'Why are you building on Cairo,' not 'Why are you building on Starknet?'
Indeed, I tend to think that projects choose a language and a tech stack before choosing a particular chain. Of course, there's an intimate link between these two, and the first deployment will happen on a particular chain. However, if you're deploying on Polygon, chances are that deployment on other EVM chains will follow. Stickiness resides in the tech stack; switching costs are much lower in the choice of a particular blockchain.
And that's where things get trickier: Why choose a new language tied to an early ecosystem with limited network effects, over an established one with ever-growing ecosystems built around it?
The answer is not quite simple, and there's a multitude of reasons that will fall out of this post, but I'll try to highlight the essence of it. But first of all, we need to take a step back and think about what we're trying to build here, in crypto. It is easy to forget about the why with the endless numbers of ponzis and forks, but I think that summarizing the why can look like this: we're convinced that society and human organizations will benefit from more transparency and verifiability, so we're developing technologies that will enable the transfer of value and information in a trustless and verifiable way. And while our common belief in the greater good led us to build blockchains, we must acknowledge that blockchains are just a means to an end.
Sylve's best tweet: (https://twitter.com/sylvechv/status/1658465170421870592?s=46&t=JenRgmO2gjpNvJTF06-Big)
And more than that, we now know that even a small fraction of the transfer of value cannot be handled (yet?) fully onchain (cf: the last bull markets). So what's our path forward? We'll certainly have much more block space in the near future, and L2s offer a great trade-off between security and scalability in that regard. But remember, blockchain is a means, and developments in the zk space provided us with a shiny new way of getting closer to our goal, which is validity proofs. Since blockchains and validity proofs offer very distinct properties, it makes them highly complementary. When you need a hard, shared, live state, with censorship resistance, you use the former; when you just need verifiability, you can use the latter. This design presents a credible path toward enabling the entire world to transfer value and information in a verifiable way.
Let's consider a simple example: you want to establish a new business in journalism to address the issues related to fake information, which are expected to escalate further with the integration of AI. To achieve this, you can utilize zk-proofs to establish a chain of truth for audio/video captures. Subsequently, posting these proofs on a blockchain will create a publicly shared state, enabling anyone to verify the authenticity of the materials. In essence, you've established a public ledger containing authenticated content captured by journalists—essentially, a verifiable repository preserved indefinitely, akin to a time capsule.
But what is the link between what we just went through, and Cairo? Cairo is the smart contract language of Starknet, yet before that, it's a language optimized for validity proofs. It serves as a virtual CPU and a singular Algebraic Intermediate Representation (AIR), capable of describing any computation using the same “generic” AIR. The new paradigm introduced by Cairo is significant; it allows for the development of a single application that harnesses a public shared state on Starknet and conducts verifiable off-chain computation using one single language.
What I'm essentially emphasizing is that the new world of the verifiable web is comprised of both blockchains and validity proofs. Cairo is the fuel that enables both airplanes (blockchains) and rockets (validity proofs) to take off and propel you into this realm. Referring back to our previous example, it means you can code in Cairo the logic generating the proof from the attested microphone and the on-chain logic verifying the proofs and the data. It is then possible to subscribe to a proving service to handle the proof generation from the microphone and to have all the on and off-chain interactions under the same code base, ensuring higher security and auditability. Overall, the advantages of an application leveraging both blockchains and validity proofs, using a single language, with various interactions between these elements within the same codebase, are immense in terms of developer experience, auditability, and explainability.
Of course, grasping this concept remains challenging currently, as network effects heavily favor the EVM, and there's still limited exploration of proofs beyond blockchains. However, significant strides are being made toward that goal, notably by projects like Giza, utilizing Cairo to verify AI inferences, Herodotus for on-chain historical data verification, Dojo delving into off-chain verifiable games, and our efforts at Pragma, constructing verifiable financial data backends. Many developments are still required to fully comprehend the comprehensive potential of proofs beyond and interconnected with blockchains.
If I'm being honest, that's definitely not the answer I initially provided to the question, but it prompted me to contemplate this further. I might be mistaken, and Cairo might not be the language that will facilitate bridging part of the gap between where we currently stand with blockchains and a completely verifiable world. Another language might serve as the conduit to reach that destination. However, I firmly believe that something akin to Cairo is necessary, and even if it isn't Cairo itself, we'd still ultimately win.
Thanks a lot Sylve, Edouard, Kaushik and Matthias for the ideas and feedbacks.
