Data availability

Introduction

In the current stage of the Alpha, Starknet operates in a ZK-Rollup mode. This means that upon the acceptance of a state update onchain, the state diff between the previous and new state is sent as calldata to Ethereum.

This data allows anyone that observes Ethereum to reconstruct the current state of Starknet.

To update the Starknet state on L1, it suffices to send a valid proof — without information on the transactions or particular changes that this update caused.

Consequently, more information must be provided in order to allow other parties to locally track Starknet’s state.

Data availability: post v0.11.0

v0.11.0 format

The state diffs contain information on every contract whose storage was updated and additional information on contract deployments.

For each affected contract, we have:

  • The contract address

  • A single word that encodes:

    • class information flag (0 = Storage updates only / 1 = contract was deployed or replaced in this state update). When this flag is on, we will have an additional word before the storage updates section, which contains the new class hash

    • nonce

    • num_of_storage_updates

See below for the expected format:

\[\underbrace{0\cdots0}_{\text{127 bits}}| \underbrace{\text{class information flag}}_{\text{1 bit}}| \underbrace{\text{new nonce}}_{\text{64 bits}}|{ \underbrace{\text{# of storage updates}}_{\text{64 bits}}}_{\text{LSB}}\]

For each storage update:

  • key - the address inside the contract’s storage where the value is updated

  • value - the new value

Next, we have information about newly declared classes:

  • The # of (Cairo 1.0) classes that were declared in the block

  • For each class we have:

v0.11.0 example

Below we show an example of on chain data that was extracted from L1, and proceed to decode it according to the above format.

[
  1,
  2019172390095051323869047481075102003731246132997057518965927979101413600827,
  18446744073709551617,
  100,
  200,
  1,
  1351148242645005540004162531550805076995747746087542030095186557536641755046,
  558404273560404778508455254030458021013656352466216690688595011803280448032
]

  • The first element, 1, is the number of contracts whose state was updated

  • The second element, 2019172390095051323869047481075102003731246132997057518965927979101413600827, is the address of the first (and only) contract whose state changed

  • The third element, 18446744073709551617, which is \(2^{64}+1\), encodes the following:

    • The class information flag is 0, that is, the contract was not just deployed or replaced, so we shouldn’t treat the next word as the class hash

    • The new nonce is 1

    • One storage cell was updated

  • The next two elements, 100 and 200 encode the storage update (the value of key 100 was set to 200)

  • Next we have the new declare section: 1 means that we had a single

declare v2 in this state update, and the next two elements encode

the class hash and compiled class hash of the declared class

Data availability: pre v0.11.0

Pre v0.11.0 format

The state diffs contain information on every contract whose storage was updated and additional information on contract deployments. Those differences are sent as uint256[] array as part of the calldata, and are encoded as follows:

  • Number of cells that encode contract deployments

  • For each deployed contract, we have:

xref:Smart_Contracts/contract-address.adoc

  • contract_address - the address of the deployed contract

  • contract_hash - the hash of the class

    • Number of contracts whose storage is updated

    • For each such contract, we have:

  • contract_address - the address of the contract

  • num_of_storage_updates - number of storage updates

  • `nonce, num of storage updates ` - a uint256 value that encodes both the number of storage updates for that contract and the updated nonce:

    \[\underbrace{0\cdots0}_{\text{128 bits}} | \underbrace{\text{new nonce}}_{\text{64 bits}} | {\underbrace{\text{# of storage updates}}_{\text{64 bits}}}_{\text{LSB}}\]

  • For each storage update:

    • key - the address inside the contract’s storage where the value is updated

    • value - the new value

Pre v0.11.0 example

Below we show an example of on chain data which was extracted from L1, and proceed to decode it according to the above format.

[
  2,
  2472939307328371039455977650994226407024607754063562993856224077254594995194,
  1336043477925910602175429627555369551262229712266217887481529642650907574765,
  5,
  2019172390095051323869047481075102003731246132997057518965927979101413600827,
  18446744073709551617,
  5,
  102,
  2111158214429736260101797453815341265658516118421387314850625535905115418634,
  2,
  619473939880410191267127038055308002651079521370507951329266275707625062498,
  1471584055184889701471507129567376607666785522455476394130774434754411633091,
  619473939880410191267127038055308002651079521370507951329266275707625062499,
  541081937647750334353499719661793404023294520617957763260656728924567461866,
  2472939307328371039455977650994226407024607754063562993856224077254594995194,
  1,
  955723665991825982403667749532843665052270105995360175183368988948217233556,
  2439272289032330041885427773916021390926903450917097317807468082958581062272,
  3429319713503054399243751728532349500489096444181867640228809233993992987070,
  1,
  5,
  1110,
  3476138891838001128614704553731964710634238587541803499001822322602421164873,
  6,
  59664015286291125586727181187045849528930298741728639958614076589374875456,
  600,
  221246409693049874911156614478125967098431447433028390043893900771521609973,
  400,
  558404273560404778508455254030458021013656352466216690688595011803280448030,
  100,
  558404273560404778508455254030458021013656352466216690688595011803280448031,
  200,
  558404273560404778508455254030458021013656352466216690688595011803280448032,
  300,
  1351148242645005540004162531550805076995747746087542030095186557536641755046,
  500
]

  • The first element, 2, is the number of cells that encode contracts deployment.

  • The next two elements describe a single contract deployment with the following parameters:

    • contract_address:

      2472939307328371039455977650994226407024607754063562993856224077254594995194

    • contract_hash:

      1336043477925910602175429627555369551262229712266217887481529642650907574765

  • The next element, 5 (index 3 in the array), is the number of contracts whose storage was updated. We will take only the first contract as an example.

    • contract_address:

      2019172390095051323869047481075102003731246132997057518965927979101413600827

    • Following the above contract address, we have 18446744073709551617 (index 8 in the array), which is \(2^{64}+1\), thus:

      • The new contract nonce is 1

      • One storage key is updated

      • The value at key 5 was changed to 102

The next 4 contract storage updates are interpreted in the same manner.

Extract from Ethereum

The data described above is sent across several Ethereum transactions, each holding a part of this array as calldata. Each new Starknet block has its associated state diff transactions.

You can find the code for extracting this data from Ethereum in Pathfinder’s repo. Pathfinder is the first Starknet full node implementation. You may also take a look at the Python script which extracts the same information.