Version notes

The following version notes cover the ongoing version changes to Starknet. To get the latest version updates delivered to you, please subscribe to our mailing list here.

Starknet Environments

Within Starknet’s deployment pipeline there are separate and distinct networks that operate independently of each other for testing before deployment.

The current version on each environment are listed within the table below:

Environment

Starknet version

Cairo version

Mainnet

0.11.2

1.1.0

Goerli Testnet 1

0.11.2

1.1.0

Goerli Testnet 2

0.11.2

1.1.0

Starknet v0.11.2 (May 31, 23)

Starknet v0.11.2 is live on Mainnet.

Technical release notes

Upgrade Cairo 1.0 version to v1.0.0-rc0 (Cairo 1.0 activated on Starknet!)

Starknet v0.11.1 (May 23, 23)

Starknet v0.11.1 is live on Mainnet.

Technical release notes

Upgrade Cairo 1.0 version to v1.0.0-rc0 (Currently disabled on Mainnet until version 0.11.2).

  • Charged transaction fee is now based on an average Ethereum gas price instead of a single sample (estimation API is unaffected).

  • API changes:

    • Remove the state root in get_state_update for pending blocks to allow faster responses in future versions.

  • Testing framework:

    • Allow declaring (and interacting with) Cairo 1.0 contracts.

      • Currently, the Cairo 1.0 ABI is not supported yet, so a Cairo 0 ABI should be supplied to declare() manually.

    • Split deploy() to two phases declare and deploy: deprecated_declare() (for Cairo 0 contract) or declare() (for Cairo 1.0 contracts) and deploy() (for both).

  • Add current block hash to the Starknet Core contract (currently not verified by the Starknet OS):

    • Breaking change: The LogStateUpdate event’s data is changed to include blockHash.

Starknet v0.11.0 (Mar 29, 23)

Starknet v0.11.0 is live on Mainnet.

invoke and declare transactions of version 0 are no longer supported on this version.

Technical release notes

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.

Historically, contract classes have been defined in terms of Cairo assembly, or Casm for short (the class definition also included more information needed for execution, e.g., hint data). The novelty of Cairo 1.0 is the introduction of Sierra (Safe Intermediate Representation), an intermediate layer between Cairo 1.0 and Casm.

The introduction of Cairo 1.0 and Sierra has several effects on the system. Below we list the effects on each component; of particular note are:

  • A new version of the declare transaction, which allows sending the new class structure

  • The state commitment will now include contract classes

  • Changes to the on-chain data format

  • New system call - replace_class

Starknet v0.10.3 (Dec 12, 22)

The deploy transaction is no longer supported on this version.

Technical release notes

Starknet

  • Performance - Separate the state commitment computation from the execution of the transactions

  • Add starknet-class-hash command to compute the class hash of a compiled Starknet contract

Cairo:

  • Autoformatter: Automatically break lines inside expressions

Starknet v0.10.2 (Nov 29, 22)

  • This version introduces sequencer parallelization! This is the first step in our roadmap of performance upgrades. Details about the specific mechanism of parallelization and the roadmap in general are described in this medium post.

  • A new endpoint, estimate_fee_bulk, is added to the feeder gateway. This will allow estimating the fee of several transactions at once, where each transaction is executed relative to the resulting state from applying the previous one.

Technical release notes

  • Sequencing performance improvements

  • Builtin ratio changes, which affects builtin costs

  • Add estimate_fee_bulk API that computes the fee of multiple transactions that will be executed consecutively

As part of this version, we will also increase the finality of transactions in the pending block, by fixing the timestamp at the time of the block creation. This will solve the issue of transactions moving from pending to rejected on account of too old timestamp

Starknet v0.10.1 (Oct 25, 22)

Technical release notes

Starknet:

  • Add DeployAccount transaction (which will replace the Deploy transaction for deploying account contracts). To use it, you should first add enough funds to your account address to pay the transaction fee, and then you can invoke DeployAccount

  • Split the starknet deploy_account CLI command into starknet new_account and starknet deploy_account

  • Account contracts that are expected to be deployed this way should implement the`validate_deploy()` entry point, which should check the signature of the DeployAccount transaction

  • Improve L1 fee computation: the fee is computed according to the diff of the storage state

  • API: Remove entry_point_type field from transaction information

Cairo:

  • Add uint256_mul_div_mod to uint256.cairo

Starknet v0.10.0 (Sept 05, 22)

This version introduces the next step in Starknet’s account abstraction design, specifically the validate/execute separation. See here for more information.

Technical release notes

Starknet:

  • Contract (breaking changes):

    • @external and @view functions should be imported directly by the main compiled file. Otherwise, they will not be usable as external functions

    • Forbid using the same storage variable name in two modules

  • New transaction version (version 1) for invoke and declare transactions:

    • Transactions of version 0 are deprecated and will not be supported in Starknet from the next version (v0.11.0). Please update your systems to use the new version

In order to use transactions of version 1 you will need to upgrade your account contracts

  • Add nonce field to the transactions. Nonce validation is now part of the Starknet protocol and is enforced to be executed sequentially

  • Invoke:

    • Split execute to two functions:` validate` (only validates the transaction) and execute (only executes the transaction)

    • Remove the selector (which is now always execute) field, following the above change.

  • Declare:

    • declare transaction should now be sent from an account (and is validated using validate_declare in the account contract)

      • Support fee for sending L1 messages. At this point, it’s not mandatory and messages with no fee will still be handled. Starting from the next version it will become mandatory.

Cairo:

Syntax changes in Cairo (to make it more similar to rust and C++):

  • You can use the cairo-migrate script to convert old code to the new syntax. Use the -i flag to apply the changes to the files

  • End statements with ;

New lines are still part of the language at this point, and you cannot put more than one instruction per line. This will change in Cairo1.0.

  • Use { … } for code blocks (instead of : and end)

  • Add () around the condition of if statements

  • Remove the member keyword in structs

  • Change comment to use // instead of #

  • Use …​, ap` instead of `...; ap in low level Cairo code

  • Support return types that are not tuples. For example, func foo() → felt (instead of func foo() → (r: felt)) As a result, it’s now mandatory to specify return types. func foo() → (res) should be replaced by func foo() → (res: felt). The cairo-migrate tool does that automatically.

  • Return statement accepts expressions, rather than only tuples. For example, you can write let x = (5,); return x;

  • A few standard library functions were changed to return felt. The cairo-migrate script also fixes calls to those functions

  • Support using functions as expressions

  • This only applies to functions with → felt signature`, whose ap change is known at compile-time (e.g., recursive functions cannot be used this way)

  • Fix a bug in the secp signature verification code that allowed a malicious prover to ignore the value of v (this does not let the prover fake a signature, but allows it to claim that a valid signature is invalid).

  • Add Cairo code for the recursive STARK verifier

Technical changes: * Move from python3.7 to python3.9

Starknet v0.9.1 (July 20, 22)

Technical release notes

Starknet:

API changes:

  • Add get_block_traces API - returns all the transaction traces of a given block

  • Add a list of declared contracts in get_state_update

  • Add a 0x prefix for class hash in the API

  • Add starknet_version field for blocks (only applies to new blocks)

Starknet CLI:

  • Change the default block number to pending

  • Using a wallet is the default, --no_wallet must be specified explicitly to override this

  • Deploying contracts:

    • Add deploy_contract function to the account contract created by starknet deploy_account

    • Use this function to deploy contract (unless using --no_wallet). In particular, deploy should be used after declaring the contract (it expects the contract class hash)

  • Support --dry_run to get the transaction information without signing or sending it

  • Support deploy_from_zero in the deploy syscall to deploy a contract to an address that does not depend on the deployer

Cairo: * Support and in if statements (if x == y and z == w).

At the moment other boolean combinations are not supported

Starknet v0.9.0 (June 06, 22)

This version introduces the contract class/instance paradigm into Starknet. See here for more information.

Technical release notes

Starknet:

  • Enforce fees - max_fee must not be set to zero, and selector must be execute

  • Split the concepts of contract class and contract instance.

  • Add declare transaction type

  • New API and CLI commands:

  • declare - Declares a contract class

  • get_class_by_hash - Returns the contract class given its hash

  • get_class_hash_at - Returns the class hash for a given contract instance address

  • Rename delegate_call to library_call, and change the contract address argument to class hash.

  • Add a deploy system call.

  • Rename ContractDefinition to ContractClass

  • Reduce the compiled contract file’s size by removing unnecessary identifiers (this optimization can be disabled using --dont_filter_identifiers)

Cairo:

  • Initial support for the EC-op builtin (scalar multiplication over the STARK curve). Not supported in Starknet yet.

  • Add additional helper methods to blake2s.cairo, including big-endian support

Technical changes: * Change function’s return type from a struct to a named tuple. In particular, foo.Return.SIZE is no longer supported.