Cairo 2.10.0 was just released. This version involves a Sierra upgrade to v1.7.0, which means contracts written with v2.10.0 are only deployable on Starknet ≥ 0.13.4 . The Testnet upgrade is planned to happen by the end of February, and the Mainnet upgrade will follow one month later (you can find more details here). As usual, you can continue using older compiler versions for your contracts and deploy them on Starknet.
Cairo v2.10.0 introduces a new notion of a Cairo executable, used for proving standalone Cairo programs (not Starknet contracts) via the Stwo prover. Proving becomes straightforward via Scarb, which encapsulates all the proving interface with the new Scarb execute and Scarb prove commands.
From the point of view of contract developers, this release is relatively small as it’s mostly intended for updates that are bound to the Starknet upgrade (see more info on gas redeposits and the new system call below). Many corelib updates, such as the extension of the iterator trait and option trait, are not included in this release. These changes will be part of Cairo v2.11.0, which will be a high-level version (no changes to the Sierra → CASM compiler), and will be released soon.
We proceed to discuss a few of the noticeable updates of Cairo v2.10.0 (for an exhaustive list of changes, see the release notes):
- Client-side proving via Scarb
- Sierra 1.7.0 and gas redeposits
- New
get_class_hash_atsystem call - No more Rust compilation for
snforge_std - Scarb lint
Breaking changes
Packages using Cairo ≥ 2.10.0 require Starknet Foundry version ≥ 0.38.0, which will be released soon (the latest Starknet Foundry version is 0.37.0 at the moment).
The reason that existing foundry versions aren’t working with Cairo ≥ 2.10.0 is twofold:
- The new Sierra version requires an update to the USC (Universal Sierra Compiler), which is used by Starknet Foundry.
- Gas redeposits: since gas is not monotonically decreasing now, setting it to
u64::maxcan lead to overflows in some of the tests. This will be handled by selecting the initial gas for tests in a more careful way.
The Starknet Foundry team is working on a release that will handle the above issues.
Client-side proving via Scarb
As the development of the new Stwo prover progresses, we wanted to ensure that developers can seamlessly integrate proving into their Cairo development environment. To this end, we defined a new compilation target: Cairo executable. To mark your package as an executable, add [[target.executable]] to your Scarb.toml file. You can then choose your executable entry point by annotating it with the new #[executable] attribute. In addition, the following commands were added to Scarb:
scarb executescarb provescarb verify
You can fine a comprehensive tutorial on how to define, run, and then generate a proof for the execution of a Cairo program via Stwo in the following readme.
Sierra 1.7.0 and gas redeposits
As of Starknet v0.13.4, some contracts will track Sierra gas rather than raw VM resources. This relies on an inherent gas-counting mechanism that’s embedded in the contract code. While gas accounting has existed in Sierra since its inception, it is only now put in production in the sense that this mechanism will affect the transaction fee.
Earlier versions of Sierra’s gas accounting were extremely worst-case in the sense that gas was charged for the worst possible execution path. For example, passing through an extremely unbalanced if/else statement would charge the maximal cost between the branches. In Sierra v1.7.0, we introduce gas redeposits. Continuing the if/else example, the cheaper branch will include a redeposit statement that compensates for the difference between the branch’s costs. Note that the maximal cost is still charged before going through the branching instruction, but if the code was compiled with the latest compiler, we will be reimbursed when choosing the cheaper branch.
For the moment, contracts with Sierra < 1.7.0 will continue to use the old pricing mechanism. In the future, we may use Sierra gas for older contracts too, hence, developers are advised to recompile their contracts with Cairo version ≥ 2.10.0 to avoid future fee increases due to the lack of redeposits.
New system call: get_class_hash_at
We introduce a system call that allows getting the class hash at a given address. If no contract is deployed at the given address then zero will be returned.
Examining the class hash of a given contract is important for various security considerations, for example:
- A contract wants to have a whitelist of allowed callbacks from a list of known implementations
- Checking if a contract is deployed before interacting with it
The example below shows how we can get the class hash of the caller in Cairo 2.10.0:
use starknet::get_caller_address;
use starknet::syscalls::get_class_hash_at_syscall;
fn foo() {
let caller = get_caller_address();
let class = get_class_hash_at_syscall(caller).unwrap_syscall();
}
No more Rust compilation for snforge_std
Since the transition of Starknet Foundry to using Cairo procedural macros (you will hear more about those in Cairo 2.11.0), building Rust was part of the process of Foundry tests compilation. This lead to various errors related to mismatch between Rust versions and slower build time the first time you’re running tests.
With Scarb 2.10.0 you now have the option to specify trusted macros. If a specific procedural macro is marked as trusted, then its binary will be downloaded directly from the Scarbs.xyz, forgoing the need to build its Rust code prior to building the Cairo project. To mark snforge as trusted, add the following to your Scarb.toml file:
[tool.scarb]
allow-prebuilt-plugins = ["snforge_std"]
The above will work with Starknet Foundry ≥ 0.37.0. New projects initialized with Scarb new will have this setting by default.
Scarb lint
The Cairo linter is now integrated in Scarb! You can find the list of currently supported lints in the cairo-lint repository.
To run the linter simply run Scarb lint, or Scarb lint --fix in case you want it to change the problematic code (when possible).
The linter is in active development, you can expect new lints to be added in the near future.