DankiBlockchain for Enterprise
People tend to overestimate how easy it is to create a blockchain. Just because you were able to deploy a network doesn’t make you an expert on blockchain. As a matter of fact, even an intern can do it in minutes. Here, try it. You know what else is easy to deploy? A webpage. Creating a blockchain is easy, and you can do it at zero cost and effort for as long as you don’t care about the design and spec of your network. Understanding the engineering constraints to design a secure and functiona...
DankiZK Proofs Part II: ZK Maths
Standing before Danki today are ghosts of the audit reports I haven’t read and dat job hunt I’ve been meaning to do for weeks now… but in the name of mighty procrastination, let’s write something totally fun but completely unrelated to everything I needed to do: ZK maths frens. If you have no idea what this is all about and why danki is so happy as my hooves type dis post, then check out Part I. But if you’re too lazy to click… ZKP or Zero Knowledge Proofs is a cryptographic mechanism that al...
DankiDemystifying the Quantum Threat
In da past two weeks, I have encountered at least 3 people who talk about quantum menace as if it will be the end of all existing blockchains today. So here are some facts: -Majority of the hashing functions used to generate private keys for blockchain addresses are using Elliptic Curve Cryptography which is NOT quantum safe. It means digital signatures may be forged to make transactions on behalf of an account. This is probably where they’re coming from. -Hashing algorithms like Keccak256 ar...
Crypto things
DankiBlockchain for Enterprise
People tend to overestimate how easy it is to create a blockchain. Just because you were able to deploy a network doesn’t make you an expert on blockchain. As a matter of fact, even an intern can do it in minutes. Here, try it. You know what else is easy to deploy? A webpage. Creating a blockchain is easy, and you can do it at zero cost and effort for as long as you don’t care about the design and spec of your network. Understanding the engineering constraints to design a secure and functiona...
DankiZK Proofs Part II: ZK Maths
Standing before Danki today are ghosts of the audit reports I haven’t read and dat job hunt I’ve been meaning to do for weeks now… but in the name of mighty procrastination, let’s write something totally fun but completely unrelated to everything I needed to do: ZK maths frens. If you have no idea what this is all about and why danki is so happy as my hooves type dis post, then check out Part I. But if you’re too lazy to click… ZKP or Zero Knowledge Proofs is a cryptographic mechanism that al...
DankiDemystifying the Quantum Threat
In da past two weeks, I have encountered at least 3 people who talk about quantum menace as if it will be the end of all existing blockchains today. So here are some facts: -Majority of the hashing functions used to generate private keys for blockchain addresses are using Elliptic Curve Cryptography which is NOT quantum safe. It means digital signatures may be forged to make transactions on behalf of an account. This is probably where they’re coming from. -Hashing algorithms like Keccak256 ar...
Crypto things
Subscribe to Danki
Subscribe to Danki
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
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.
No activity yet