StarkNet v0.11.0 tracking

[Mirko-von-Leipzig]

Tracking issue for StarkNet v0.11.0 support. Changes are documented here but we should still expect changes and more information over the coming days / weeks.

I'll start with a broad list of what is likely required and we can expand and refine it as more information becomes available. Once something is actionable, it would be nice to split it into a separate issue which is also tracked here.

Cairo 1.0 and Sierra

Cairo 1.0 classes may now be deployed using Declare V2 transactions. We will have to store its Sierra IR representation (to hand out to users via JSON-RPC) but will also need to compile it to Cairo assembly. The latter is required to execute calls and estimate fee's in the VM.

• Embed Sierra compiler #823
• Use Sierra compiler #824
• Parse sierra classes #903
• Sierra class hash calculation #904
• Represent sierra classes in storage #905
• Store CASM for sierra classes #906

Declare V2

This new transaction type will permeate everywhere - RPC, gateway, sync, storage

State commitment

The state commitment definition is changing from v0.11.0 onwards. It now includes a class hash commitment tree. Since this change takes effect from literally v0.11.0 onwards, we will need to parse the semver version of a block to calculate the state commitment hash.

A question I have - are historical classes included in this tree or is it new classes only? I imagine only Cairo v1 classes to be backwards compatible? Indeed, only Cairo v1 classes are used.

• parse block semver #825
• calculate and store class commitment trees #826
• calculate new state commitment #827
• Update state commitment calculation #895

JSON-RPC changes

Changes are already available for preview in the PRs since the last release. We will need to investigate how we can make v0.2 compatible with the upcoming v0.3 release.

On a positive note, at least we can remove v0.1.

• investigate json-rpc changes #828
• Support storage proofs in v0.11.0 #830
• Support new starknet_getEvents event filter semantics for keys #834
• v0.3 starknet_call #855
• v0.3 starknet_chainId #856
• v0.3 starknet_getBlockWithTxHashes #857
• v0.3 starknet_getBlockWithTxs #858
• v0.3 starknet_getClass #859
• v0.3 starknet_getClassAt #860
• v0.3 starknet_getClassHashAt #861
• v0.3 starknet_estimateFee #862
• v0.3 starknet_getNonce #863
• v0.3 starknet_pendingTransactions #864
• v0.3 starknet_getStateUpdate #865
• v0.3 starknet_getStorageAt #866
• v0.3 starknet_getTransactionByHash #867
• v0.3 starknet_getTransactionByBlockIdAndIndex #868
• v0.3 starknet_getTransactionReceipt #869
• v0.3 starknet_syncing #870
• v0.3 starknet_getBlockTransactionCount #871
• v0.3 starknet_blockHashAndNumber #872
• v0.3 starknet_blockNumber #873
• v0.3 starknet_addInvokeTransaction #874
• v0.3 starknet_addDeclareTransaction #875
• v0.3 starknet_addDeployTransaction #876
• v0.3 starknet_addDeployAccountTransaction #877
• RPC Felt representation  #879
• add missing v0.3 transaction types #885
• v0.3 starknet_simulateTransaction #887
• v0.3 RPC examples, fix v0.2.1 examples #901

Gateway API

• Gateway API changes v0.11.0 #839
• Support gateway Declare V2 for add_transaction #854
• handle new state updates #899
• gateway get_compiled_class_by_class_hash #912

Poseidon hash

Poseidon hash will be used in some places, but it is not yet clear where exactly.

• Implement Poseidon hash #829

Breaking Release

Since this is a breaking release, it would be a good time to remove the deprecated items:

• Deprecated items #791
• Remove RPC API v0.1 #900

Misc

• Support pending state updates without new_root property #919

Release preparations

• Update documentation #902

[kkovaacs]

A question I have - are historical classes included in this tree or is it new classes only? I imagine only Cairo v1 classes to be backwards compatible?

This was mentioned during the meeting -- only Cairo v1 classes are added to the classes tree.