Live on Testnet, soon on Mainnet!
TL;DR
- Starknet alpha v0.11.0 is out and live on Testnet
- You can now deploy and interact with Cairo 1.0 contracts on Starknet Testnet!
- Computation on Starknet is 5x cheaper!
- For the first time, the Mainnet upgrade to Starknet alpha v0.11.0 will be put to a governance vote
- This marks the beginning of the transition period before Regenesis
- Deploying Cairo 1.0 contracts on Mainnet will be enabled only after a few weeks of running on Testnet, once we ensure the new system runs smoothly.
Introduction
We are excited to announce that the much-awaited Starknet alpha v0.11.0 is live on Testnet! Why is this a big step for Starknet? In Starknet v0.11.0, you can declare, deploy and run Cairo 1.0 smart contracts. We also introduce a new system call that allows a smooth transitioning of existing contracts to a Cairo 1.0 implementation.
Cairo 1.0 improves Starknet in two different aspects. First, it improves the development experience by offering a richer programming language, which introduces (among other things) types/generics/traits/error handling to Cairo. Second, Cairo 1.0 plays a key role in Starknet’s decentralization journey: Cairo 1.0 contracts sent in Starknet alpha v0.11.0 compile to Sierra. Sierra guarantees that every contract execution is provable, which is a crucial property in a decentralized Starknet.
Another important improvement that is coming in this version is a 5x cost reduction for computation. This will make Starknet even more friendly to computationally intensive applications. More details below.
Getting Ready for Regenesis
Starknet alpha v0.11.0 marks the beginning of the Transition period, which will allow preparation ahead of Starknet’s Regenesis. Starknet’s Regenesis plan was published a few months ago, and it focuses on transitioning from a system based on Cairo 0 to a system based on Cairo 1.0.
During the Transition period, existing Cairo 0 contracts (if they’re upgradable) have the opportunity to maintain their address and storage, and seamlessly transition their implementation to Cairo 1.0 (see next section).
As a Starknet user, this means that you only need to upgrade your wallet once the new Cairo 1.0 implementation of your account is released (you’ll be able to do it any time up to the Regenesis itself). No downtime is expected, all the dapps in the system will continue to operate as usual.
After the Regenesis, Starknet will stop supporting the remaining Cairo 0 contracts throughout the system. This will be well communicated in advance, and developers will be given sufficient time to migrate their contracts. The transition period is expected to last a few months, and dapp developers can already start migrating their implementation to Cairo 1.0. At the end of the Transition period, the Regenesis will happen.
Smooth Migration to Cairo 1.0
With the transition to Cairo 1.0, existing Cairo 0 contracts are deprecated and will no longer be supported upon Regenesis. To allow upgradable Cairo 0 contracts to continue operating, even after the Regenesis, and keep the state constructed up until that time, we added a new system call — `replace_class`. Upgradable contracts have no issue with upgrading to a Cairo 1.0 implementation, but the underlying proxy (the contract that holds the actual state) will still be stuck with the Cairo 0 implementation. The `replace_class` syscall solves this problem by allowing the proxy contract to replace its underlying class, i.e. keep the same address and storage, but replace the implementation.
Computation is Now 5x Cheaper!
Today, Starknet transaction fees have two major components: Computation and on-chain data. The computational element of the Starknet transaction fee is determined by the marginal cost of verifying its proof on L1 (see the docs for more details).
Originally, our 200m Cairo steps in a proof that requires 5m gas for verification led to a naive estimation of 0.05 gas per Cairo step. Since then, we have moved to recursive proofs which allow for a significant reduction in L1 verification cost (only the root of a recursion tree reaches L1). It is now time to update our original estimates accordingly — the price of each Cairo-step on L2 will be reduced by 5x, and will now cost 0.01 gas.
This cost reduction is significant for computationally intensive applications, e.g. account contracts with non-native signatures. Simple transactions will see a minor cost reduction (~ 5%). In future versionss, we will handle the second component: on-chain data costs. Once alternatives to on-chain data are introduced to Starknet (aka Volition), the cost reduction will be felt all across the board.
Starknet Governance First Vote
The first phase of Starknet Governance has launched (more details here). Community members are now able to participate in shaping Starknet through an additional channel, namely voting on protocol changes.
Starknet Governance first phases will focus on Starknet protocol upgrades. Every Starknet version upgrade will first be deployed on Testnet; voters will have a 6-day period to examine and test the upgraded version as it runs on Goerli. During this time, a Snapshot proposal will be opened, and the community can vote on whether to approve the new version for Mainnet deployment.
If the proposal gains a majority of ‘YES’ votes during the 6-day voting period, the proposal passes and Starknet Mainnet will be upgraded accordingly.
Starknet alpha v0.11.0 is the first Starknet version which is up for a vote. The Starknet alpha v0.11.0 vote will be open for six days starting from the Testnet deployment.
Relevant links:
- Snapshot space
- Delegation discovery page
- Starknet alpha v0.11.0 discussion thread on the Community forum
Cairo 1.0 and Sierra
Sierra (Safe Intermediate Representation) is an intermediate representation that compiles to Cairo assembly (CASM). Pre Starknet alpha v0.11.0, a developer would compile Cairo 0 into CASM and send the result to the Starknet sequencer. With Cairo 1.0, developers compile their code to Sierra, and send this intermediate representation to the sequencer. The sequencer will then compile it to CASM. Sierra is guaranteed to compile to “safe CASM”, i.e. a subset of CASM that cannot fail, making each and every execution provable. This guarantees that the sequencer will be able to charge fees even for reverted transactions, protecting from DOS. For more information, see the docs.
Starknet alpha 0.11.0 will use the Cairo 1.0-alpha.6 version. This version is close to feature parity with Cairo 0, with all Starknet system calls already present.
Note that the Starknet sequencer uses a fixed compiler version, which means language improvements may not be immediately available in Starknet, and will be available only after a Starknet version update. Specifically, while improvements that affect the Cairo 1.0 → Sierra compilation may take effect immediately, changes to the Sierra → CASM compiler (see the docs for more details) will need to wait for a Starknet upgrade.
What Else is New?
New Transaction Type — Declare v2
We’re adding a new transaction type for declaring Cairo 1.0 classes. This new `declare` transaction version is similar to the existing `declare`, with two important distinctions:
- The class object being sent now represents Sierra rather than CASM, i.e. the class’s semantics is defined by the Sierra representation.
- The user is also signing the compiled class hash. This is a crucial step until Sierra→CASM compilation will be proven as part of the Starknet OS.
For more details, see the docs.
From the developer’s point of view, the experience remains the same. After writing your Cairo 1.0 code, you can use the CLI to declare the class.
Note that initially, `declare v2` transactions will not be accepted on Starknet Mainnet. After a period of experimenting on Testnet, the new transaction type will be enabled on Mainnet, and Cairo 1.0 classes will become available.
Poseidon is Here
Poseidon is a family of hash functions designed for having very efficient algebraic circuits. As such, they may be very useful in ZK proving systems such as STARKs and SNARKs. As of Starknet alpha v0.11.0, developers will be able to use Poseidon. Additionally, some of the hash computations that are part of the Starknet protocol will transition to Poseidon (specifically, the class hash, compiled class hash, and parts of the state commitment will use Poseidon, see the docs for more details). In the future, more internal components will transition to using the Poseidon hash function.
The exact version and parameters that are used in Starknet can be found here.
Miscellaneous changes
Like previous Starknet versions, an upgrade also has implications for our APIs and other low-level components. Below we list those and address the specific changes that were made:
- v0 invoke/declare transactions are no longer supported
- L1→L2 messages now require fees. That is, messages sent with zero fee will not be processed by the Starknet sequencer
- The on-chain data format is changed
- API changes (not all changes are listed here, please refer to the docs for an exhaustive list) :
- added a new `get_compiled_class_by_class_hash` endpoint
- `get_class_by_hash` returns both Cairo 0 / Cairo 1.0 classes (depending on the requested hash)
- `get_state_update` has a new section for replaced classes, and declarations are split between Cairo 0 and Cairo 1 classes.
- `estimate_fee` and `simulate_tx` can now skip validation
- A new Starknet JSON-RPC version
What’s coming next?
Now that all the Cairo 1.0-related infrastructure has been put into place, you can expect:
- Further language improvements to Cairo 1.0
- Performance improvements: as promised, we keep moving forward towards significantly increasing the TPS. The next step in the roadmap is transitioning to the Rust sequenencer, which is developed in the open under the Apache 2.0 license. The new sequencer will make use of the rust CairoVM and the Papyrus full node, forming the Performance Trio.
- Offchain DA! In this version, we handled the computational component of the transaction’s cost. In upcoming versions, we will handle the on-chain data costs, which are today the dominant cost for average transactions.
