I haven’t escaped Cairo hell yet when the Cairo 1.0 rolled out, promising ZK-STARK-provable computation with simpler syntax and better security through an intermediate representation they call Sierra.

Now after a few traumatic attempts at understanding the old version of Cairo (excuse me I’m quite normie), my fear was that the addition of this new steps will make it more complex, but luckily I was proven wrong.

Cairo is specifically designed for creating validity proofs, and for this reason it compiles to a special machine code they call CASM which translates to a set of polynomial constraints and runs on a VM that was optimized for proofs (aka. Cairo is not an EVM Compatible language).

Cairo VM is different in a few ways from EVM, like for instance, field element is the only data type in Cairo while we have a variety of 256-bit words for EVM languages like Solidity which we still have to emulate into field elements if we’re going to run proofs, so why not just go with it directly. Anyway… what makes proving multiple times faster in Cairo VM is their read-only memory model. Linear type systems like this also guarantees safety when it comes to making sure that memory cannot be deleted or rewritten.

This probably one of the bigger downsides of using a proof-optimized system, I think. Because Cairo is made to run on a different VM, we can’t just create dApps with it that are interoperable with protocols in the EVM, which is a big bummer but luckily we now have Kakarot, a enshrined zkEVM implemented in Cairo that can serve as an abstraction layer for programs written in Cairo, practically enabling EVM calls and Solidity bytecode to be interpreted in StarkNet. It is still not live in production as of time of writing, to note. But I’m looking forward to try the RPC and will post about it.

So with the original Cairo, the compilation goes like this:

Cairo --→ CASM

Where Cairo compiles locally into CASM (Cairo Assembly) which is a machine code that translates to polynomial constraints. So every program written in Cairo generates a proof of correct CASM execution and that is then sent to the StarkNet sequencer.

This process has some nuances though. For example, if the user submits an invalid transaction in CASM directly to the sequencer and it reverted, then there will be no proof generated that the user has indeed submitted a failed transaction so that the network can collect fees from it. And if StarkNet can’t collect fees for doing certain computations then it can be an opening to DoS attacks in the network.

So now we have to introduce a safe form of CASM that will be provable at all times, and that is where this intermediate representation, Sierra comes in. In Cairo 1.0, the program first has to locally compile into Sierra which then compiles into safe CASM when submitted to the sequencers for verifying. This means can no longer send CASM directly to StarkNet, limiting the attack surface and making the network more secure.

The compilation process in Cairo 1.0 looks like this:

Cairo 1.0 --→ Sierra --→ Safe CASM

Some other notable features of Sierra include:

-Gas counting upon compilation to Sierra. Sierra makes sure that each function counts its gas correctly and returns if it has reached the limit.

-Intermediate representation enables type information from Sierra to work with native types, opening the possibility that StarkNet sequencers may eventually run on native hardware

When I first encountered Cairo, you will still have to create types for different integers and addresses using field entities or felt. And then I had to understand when and how to use variable declaration patterns like tempvar, local… Tbh it’s a little overwhelming for noobs like me, but it gets more understandable now because some of these low-level decisions are now abstracted away in the language.

There are many examples where I can point out that it’s looking more like Rust and is easier to the eyes, and here are some:

• func is now just fn, and its return variables no longer have variable names but just their types.

• @storage_var is no more, now you have to put them in a storage struct, write the contract traits, and then write its implementation.

• the decorator syntax is now more Rust-like. So is creating enums and matching patterns

• the use of an interface contract they call traits, which has a separate section for its implementation

• enabling type generic parameters through the use of <>

• easy upgradeability by just replacing class hash!

There are many more that I probably missed, so better check out their docs.

As y’all know, I come from a Solidity background and still currently exploring Rust. So if you’re interested, let’s be scruffy, learn from mistakes together, and take this path with me! I’ll be hacking away a few sample programs in Cairo 1.0 and hopefully get to share some with you, too.

I haven’t escaped Cairo hell yet when the Cairo 1.0 rolled out, promising ZK-STARK-provable computation with simpler syntax and better security through an intermediate representation they call Sierra.

Now after a few traumatic attempts at understanding the old version of Cairo (excuse me I’m quite normie), my fear was that the addition of this new steps will make it more complex, but luckily I was proven wrong.

Cairo is specifically designed for creating validity proofs, and for this reason it compiles to a special machine code they call CASM which translates to a set of polynomial constraints and runs on a VM that was optimized for proofs (aka. Cairo is not an EVM Compatible language).

Cairo VM is different in a few ways from EVM, like for instance, field element is the only data type in Cairo while we have a variety of 256-bit words for EVM languages like Solidity which we still have to emulate into field elements if we’re going to run proofs, so why not just go with it directly. Anyway… what makes proving multiple times faster in Cairo VM is their read-only memory model. Linear type systems like this also guarantees safety when it comes to making sure that memory cannot be deleted or rewritten.

This probably one of the bigger downsides of using a proof-optimized system, I think. Because Cairo is made to run on a different VM, we can’t just create dApps with it that are interoperable with protocols in the EVM, which is a big bummer but luckily we now have Kakarot, a enshrined zkEVM implemented in Cairo that can serve as an abstraction layer for programs written in Cairo, practically enabling EVM calls and Solidity bytecode to be interpreted in StarkNet. It is still not live in production as of time of writing, to note. But I’m looking forward to try the RPC and will post about it.

So with the original Cairo, the compilation goes like this:

Cairo --→ CASM

Where Cairo compiles locally into CASM (Cairo Assembly) which is a machine code that translates to polynomial constraints. So every program written in Cairo generates a proof of correct CASM execution and that is then sent to the StarkNet sequencer.

This process has some nuances though. For example, if the user submits an invalid transaction in CASM directly to the sequencer and it reverted, then there will be no proof generated that the user has indeed submitted a failed transaction so that the network can collect fees from it. And if StarkNet can’t collect fees for doing certain computations then it can be an opening to DoS attacks in the network.

So now we have to introduce a safe form of CASM that will be provable at all times, and that is where this intermediate representation, Sierra comes in. In Cairo 1.0, the program first has to locally compile into Sierra which then compiles into safe CASM when submitted to the sequencers for verifying. This means can no longer send CASM directly to StarkNet, limiting the attack surface and making the network more secure.

The compilation process in Cairo 1.0 looks like this:

Cairo 1.0 --→ Sierra --→ Safe CASM

Some other notable features of Sierra include:

-Gas counting upon compilation to Sierra. Sierra makes sure that each function counts its gas correctly and returns if it has reached the limit.

-Intermediate representation enables type information from Sierra to work with native types, opening the possibility that StarkNet sequencers may eventually run on native hardware

When I first encountered Cairo, you will still have to create types for different integers and addresses using field entities or felt. And then I had to understand when and how to use variable declaration patterns like tempvar, local… Tbh it’s a little overwhelming for noobs like me, but it gets more understandable now because some of these low-level decisions are now abstracted away in the language.

There are many examples where I can point out that it’s looking more like Rust and is easier to the eyes, and here are some:

• func is now just fn, and its return variables no longer have variable names but just their types.

• @storage_var is no more, now you have to put them in a storage struct, write the contract traits, and then write its implementation.

• the decorator syntax is now more Rust-like. So is creating enums and matching patterns

• the use of an interface contract they call traits, which has a separate section for its implementation

• enabling type generic parameters through the use of <>

• easy upgradeability by just replacing class hash!

There are many more that I probably missed, so better check out their docs.

As y’all know, I come from a Solidity background and still currently exploring Rust. So if you’re interested, let’s be scruffy, learn from mistakes together, and take this path with me! I’ll be hacking away a few sample programs in Cairo 1.0 and hopefully get to share some with you, too.