ZK/SEC Research notes from zkSecurity
All posts
tools · zk

Stone CLI: Making Cairo programming more accessible

Introduction

We are pleased to announce that after working for months with the StarkWare team, we are finally launching the Stone CLI, a tool for easily proving and verifying Cairo programs! Huge thanks to the StarkWare team for their work and guidance as well as the Lambdaclass and Herodotus teams for building the infrastructure that makes this possible.

Motivation

Currently, the Cairo ecosystem is fragmented in that there are multiple tools for compiling, running, proving, and verifying Cairo programs. Beginners are often confused about which tool to use for a given task and end up spending too much time figuring out the optimal toolchain for their needs. The Stone CLI aims to bring a large part of the process into one simple tool. Below is an overview of the components that the CLI brings together:

Stone CLI Components

Features

Proving

Cairo programs need to be compiled to Cairo Assembly (CASM) before they can be run by the VM and proven. Cairo 0 programs are different from Cairo 1 programs in that they are compiled directly to CASM, while Cairo 1 programs need to be compiled first to an intermediate representation called Sierra and then compiled to CASM. Most of the time, Cairo 1 programs will be used. (Please see the Cairo book for more details on programming in Cairo 1.)

After the program is compiled to CASM, it needs to be run by the Cairo VM to generate the memory and trace outputs. These outputs are then parsed to make the public and private inputs for creating a proof.

The generated public and private inputs will be used as input for the Stone prover, which will create a Cairo proof.

A Cairo proof is essentially a proof that a certain program was run with certain inputs and produced certain outputs. For example, a Fibonacci sequence program that computes the nth Fibonacci number may take 10 as input and produce 55 as output. As long as the verification process is correct, one can be assured that the 10th Fibonacci number is 55 without having to run the program themselves.

Verifying

The CLI supports verifying on 3 different verifiers: Stone verifier in C++, Starknet verifier in Cairo, and Ethereum verifier in Solidity.

Using the Stone verifier is straightforward using the CLI and it is mainly used locally for testing purposes. The more interesting verifiers are the ones deployed on Starknet and Ethereum since both on-chain verifiers allow the output of the program to be registered as "facts" that smart contracts can rely on as verified data.

Serializing proofs

In order to use those verifiers, however, one needs to interact with the contracts deployed on-chain, and the CLI does not support such infrastructure. Instead, it serializes the proof into a format that is compatible with the on-chain verifier. Note that in this process the proof is often split into multiple files since the entire proof usually does not fit inside the calldata limits of a single transaction.

Proving with the bootloader

For the Ethereum verifier, there is an additional specific requirement: the proof needs to be generated using a specific Cairo program named the "bootloader". The bootloader program allows one to efficiently run multiple Cairo programs by creating a proof size smaller than (see more details in the STARK book). Since only the bootloader program is supported by the Ethereum verifier, the CLI provides an easy way to generate bootloader proofs via the prove-bootloader command.

What's next?

Since the Starknet ecosystem is constantly evolving, we will continue to update the CLI to support new features and infrastructure. If you want to contribute to the repo or request additional features, please let us know on GitHub!

Keep reading
More to explore

Improving the Security of the Jolt zkVM

We recently explored a16z’s Jolt zkVM to bolster its security, discovering significant bugs in the process. Our findings revealed vulnerabilities that could allow malicious provers to forge proofs, highlighting the crucial role of manual reviews in catching these issues. Jolt, with its unique approach using the Lasso lookup technique, aims to improve prover efficiency and system scalability. With these bugs now fixed, this work underscores the importance of thorough audits in ensuring the reliability of advanced zkVM technology. Stay tuned as we continue to delve into zkVM security insights.

Suneal Gong, Imam Al-Fath · November 19, 2024

Archetype x zkSecurity (Whiteboard Session) - Proof is in the Pudding: Arithmetization

Join us for a deep dive into the fascinating world of arithmetization as David from our team breaks down the process of converting logical statements into algebraic forms to create arithmetic circuits, essential for constructing ZK proofs. This unedited recording from our "Proof is in the Pudding" series offers a unique opportunity to grasp these foundational concepts, perfect for anyone keen on unlocking the mechanics behind zero-knowledge proofs. Curious? Check out the session on Archetype's channel!

ZK/SEC · October 03, 2024

The zero-knowledge attack of the year might just have happened, or how Nova got broken

Last week, a surprising paper revealed a major vulnerability in Microsoft's Nova, a leading zero-knowledge proof (ZKP) system, that showcased a false computation with a valid proof. This discovery is especially intriguing given the complexity and robustness typically associated with ZKP systems. We had just launched our company to tackle bugs in ZKP frameworks, and while we anticipated issues, complete breakdowns of systems themselves are rare. Nova's issue revolved around cycles of elliptic curves, showing how small implementation oversights in complex cryptographic systems can lead to significant errors. This post dives into the intricate mechanics of Nova and the discovery process, offering a fascinating glimpse into why rigorous specifications are crucial in cryptography.

David Wong · July 02, 2023