Since releasing Cairo a few weeks ago we’ve seen a lot of excitement but also some confusion as to how it fits in with the usual tech stack used by blockchain developers. So let’s clarify.
What Cairo is, & isn’t
Cairo is a language for writing provable programs: running a Cairo program produces a trace that can then be sent to a trustless prover, which generates a STARK proof for the validity of the statement or computation represented by the Cairo program. The proof can then be verified using a verifier (which may or may not be on-chain).
Cairo isn’t a blockchain language. It cannot be used for writing smart contracts (although it may become that, down the road).
If it isn’t a blockchain language, how can it help you?
Cairo & the Blockchain Tech Stack
Today, most blockchain dApps are basically a Solidity contract implementing some sort of logic, perhaps some frontend for good user experience, and maybe a backend. These dApps, when successful, inevitably face the scalability problem.
More and more we see dApps that solve their scalability problems by turning to proof-based L2 scalability solutions (like DeversiFi with StarkEx). An off-chain component takes over some of the more complex parts of the business logic and communicates with the on-chain smart contracts, without giving up on security, because all changes to the state of the system are certified with proofs. Scale improves because verifying a proof on-chain is exponentially cheaper than executing the business logic fully on-chain.
Before Cairo, creating a proof system that covers a specific business logic was hard (it’s like constructing a chip for that business logic by placing NAND gates on a silicon wafer). With Cairo, the barriers for using proofs to achieve scalability are much lower. You write your complex logic in Cairo, get it proved off-chain (we’ll explain how in a minute), and once that proof is validated on-chain, your smart contract application can use the result trustlessly – as if it executed that complex logic onchain, because that’s what the proof asserts.
So how does it work? With SHARP
Three things are expensive on Ethereum: computation, transmission and storage. Cairo solves all three of them. To understand how it does that, we need to introduce a new concept – The Shared Prover (or SHARP).
The SHARP is the connecting link between your Cairo code and your Solidity smart contract. It has three main components – a prover (off-chain), a verifier smart contract (on-chain) and a fact registry contract (on-chain).
The prover takes your Cairo program’s execution trace, proves that it’s valid, and sends this proof to the verifier. After verifying the proof, the on-chain verifier takes an important extra step: it writes a fact attesting to the validity of the proof in the Fact Registry. This fact is like a trustless stamp of approval, certifying that the Cairo program was computed correctly. Now all that is left for the dApp’s smart contract is to check that this fact exists, in order to rely on the computation that was executed off-chain.
Let’s look at a toy example – a blockchain-based Sudoku game, where the person who presents a correct solution gets a prize.
Today, you need to implement the entire business logic of verifying whether a solution to the puzzle is correct in Solidity – that’s an expensive computation to perform on-chain. Instead, you can write this logic in Cairo, and execute it off-chain. The Cairo program will check the solution and will then trigger the SHARP to generate a proof, verify it on-chain and write a fact – a stamp of approval that this solution was the right one. The Sudoku’s smart contract checks that this fact exists, and pays the prize to the winner. We saved both the expensive computation of solution verification and the transmission of the Soduko’s solution on-chain
The role of the dApp’s smart contract changes – from the component in charge of executing expensive business logic, it becomes the component in charge of dealing with the inexpensive consequences of that business logic (in our example, sending the prize to the winner or updating some state), while relying on the fact that the business logic was executed correctly.
We’ve discussed computation and transmission in this post – we will talk about how Cairo can solve storage on Ethereum in a future post.
We hope this gives you a better picture of how Cairo fits into the tech stack you’re working with. If you have any more questions – join the Cairo Dev discord server, we’ll be happy to answer them there.