Starknet v0.13.2 pre-release notes

🆙 Versions Upgrade
1

Sepolia Testnet – August 5
Mainnet – August 26

Conceptual Changes

This version focuses on performance improvements. In addition, we make some necessary adjustments in order to prepare for the transition to a Starknet p2p network between nodes that will happen in a later version. We proceed to describe the version highlights.

Sequencer parallelization

We’re reintroducing optimistic parallelization to the new rust-based Starknet sequencer. The gist of optimistic parallelization is to execute transactions in parallel as long as we don’t find a dependency between them. You can read more about optimistic parallelization here. The improvement factor obviously depends on the nature of the common txs on the network.

Starknet applicative recursion

What do we mean by “applicative recursion”

SHARP works in the resolution of proof trains, each train consists of a tree whose leaves are jobs, each corresponding to a Cairo program that needs proving (in the case of Starknet, this is the Starknet OS). The final proof that reaches L1 is a recursive proof for all the leaves in the tree. Unlike verification of the proof on L1 which is shared among all the jobs in the train, there is a fixed cost per job for e.g. recording the associated fact, or publishing data which is done separately for each job. So far, each Starknet block was sent as a separate job. This limited our ability to squash state diffs over several blocks, and prevented us from having a short fixed-time block interval (since in the current architecture, each block publishes one blob, so short enough block times will lead to severe blob under-utilization). Even more importantly, this meant a high fixed cost per block (fact recording on-chain and state-update on the Core contract).

To overcome the above issues, we want to have only one fact recorded on-chain, attesting to many Starknet blocks. We refer to this feature as “Starknet applicative recursion”. The idea is, to generate the recursive proof on the Starknet side, and only send one final job for SHARP. For each block, we’ll ask SHARP for a proof of that block, but without the recording on-chain part. Given the proofs, we’ll construct a final recursive job that attests to all the blocks, and squashes all the state diffs between them.

What actually changes

The L1 verifier contract will change. Instead of verifying the execution of the bootloader program, it will verify a new program, called the “applicative bootloader”. The applicative bootloader relies on the existence of a “base program” and an aggregator program.

To register a new “applicative fact” on-chain, the verifier contract must see a proof for the successful execution of the applicative bootloader with some base program P, and an aggregator program for P. The way the applicative bootloader works, is to verify (potentially several) proofs of the base program execution, and then use the outputs of the base program as input to the aggregator program. In the case of Starknet, the base program is the Starknet OS, and the aggregator program is a new cairo program that squashes the state diffs of several blocks. This way, we can take individual proofs of OS executions for some block range, and end up with a single program whose valid execution attests to the validity of all blocks within that range, and whose output is the squashed state diff. On Ethereum, the Starknet core contract will verify that an “applicative fact” was registered on chain, with the expected aggregator program, and that the base program hash (outputted by the aggregator) is that of the Starknet OS.

We summarize the technical changes induced by the above here:

  • The Starknet Core contract now knows of both the aggregator program hash and the OS program hash.
  • The LogStateUpdate event for the Starknet core contract will be emitted once for every sequence of blocks, rather than for every block.
  • The data published on L1 is now the output of the aggregator. While the format of the state diffs, the OsOutputHeader changes. We’re adding four new fields to the header: prev_block_number, prev_block_hash, os_program_hash, full_output. This means that if you’re decoding Starknet onchain data from blobs, then you’ll need to start decoding statediffs after the first 10 felts rather than after the first 6.

The new Cairo programs, namely the aggregator and applicative bootloader, will be published as part of the new cairo-lang release.

New block hash definition

To prepare for the future transition to p2p communication (as opposed to relying on the centralized sequencer block publications), we’re making sure that the block hash structure is robust in the sense that it allows nodes to verify all the data given by peers without being susceptible to DOS.

This change will affect full nodes, and will not be seen externally (past block hashes naturally remain unchanged). You can find a reference implementation to the new block hash calculation in the starknet-api crate.

API Changes

FGW request/response

  1. Block hash definition will change as discussed above, this will affect all endpoints returning the block hash (the response structure remains the same)
  2. Fix bug where state diff hash used for signatures is affected by 0 length state diff.
  3. Receipts will get a new total_gas_consumed property, that will only appear in new transactions after 0.13.2. This is an object that includes l1_gas and l1_data_gas. These are the numbers used for the eventual fee computation, and for the receipt hash during the block hash calculation.
  4. Three new builtins can appear under the builtin_instance_counter property of execution_resources under transaction receipts (which are accessible through the get_block endpoint). The new builtins are add_mod, mul_mod, and range_check96.

The source of truth for the feeder gateway response is FGW response objects.

Stopping support for tracing on the feeder gateway on 0.13.2

The following tracing related methods will not be available post 0.13.2:

  • get_block_traces
  • get_transaction_trace

To clarify, these methods will continue to be supported for blocks pre 0.13.2.

JSON RPC

No change in 0.13.2

v0.8.0 will be released alongside Starknet v0.13.3, at which point all support for versions < 0.7.0 will stop.

Cairo

A new compiler version will be released for 0.13.2, Cairo 2.7.0. This includes a Sierra upgrade to v1.6.0, i.e. contracts compiled with the new compiled will only be accepted on Starknet v0.13.2 onwards.

The Starknet-related features that will be added in this Cairo version include:

  • SHA256 syscall - syscall for computing sha256 on an arbitrary length input
    • High level code for using sha256
    • Syscall cost - the dominant part of the syscall is ~1.1k bitwise builtin applications which today costs ~180 L1 gas (the 2k steps are negligible in comparison). The syscall is applied once for ~14 u32.
  • Circuit builtin - the new compiler version will introduce a way to define ad-hoc algebraic circuits in Cairo. Circuits use the new mulmod and addmod builtins under the hood.

Execution Changes

Blockifier

  1. Parallelization infrastructure: we’ll add separate modules to the blockifier that will be responsible for running a block with optimistic parallelization. The sequential flow remains mostly be untouched by parallelization. The entry point to the blockifier’s concurrency handling is concurrency.rs. You can find a short description of the new design in the community forum post.

  2. VM upgrade: we’ll bump the vm version v1.0.0 (atm we’re on v1.0.0-rc3). This version uses the new lambdaworks felt. The felt change will propagate to the blockifier, compiler and nodes.

  3. Errors prettifying: currently, error strings are not very informative and have a lot of redundant data with no information that comes from the back and forth between the blockifier and the VM. Execution errors are becoming more structured, which will be the basis for better error handling in the next rpc version, resulting in nice error displays by wallets.

Old error template example:

"Transaction execution has failed: Error in the called contract \
                 ({account_address_felt}):
Error at pc=0:797:
Got an exception while executing a hint.
Cairo traceback (most recent call last):
Unknown location (pc=0:{account_pc_location})

Error in the called contract ({address_felt}):
Error at pc=0:8010:
Got an exception while executing a hint.
Cairo traceback (most recent call last):
Unknown location (pc=0:{pc_location})

Error in the called contract ({address_felt}):
Error at pc=0:{expected_pc}:
Got an exception while executing a hint.
Cairo traceback (most recent call last):
Unknown location (pc=0:{pc_location})

Error in the called contract ({address_felt}):
Execution failed. Failure reason: {expected_error}.

New error template example:

Transaction execution has failed:
0: Error in the called contract (contract address: {account_address_felt}, selector: \
                 {execute_selector_felt}):
Error at pc=0:797:
Cairo traceback (most recent call last):
Unknown location (pc=0:{account_pc_location})

1: Error in the called contract (contract address: {address_felt}, selector: \
                 {invoke_call_chain_selector_felt}):
Error at pc=0:8010:

Limits changes

  • The maximal number of steps in a single INVOKE transaction increases to 10m.

  • The maximal calldata length increases to 5k felts