On-Chain Data

In the current stage of the alpha, StarkNet operates in a zk-rollup mode. This means that upon the acceptance of a state update on chain, the state diff between the previous and new state is sent as calldata to Ethereum. To emphasize the motivation for this, consider the following scenario. Suppose that we deploy the simple balance contract from the StarkNet tutorial. In order to increase the balance, one first reads the current balance. Suppose that in state A my balance was x, and known to everyone. A prover can include a transaction that calls increase_balance, resulting in my new balance being x+amount. This proof will now transition the state of StarkNet from A to new state B. Note that so far, x+amount is not necessarily available to anyone but the prover including the transaction. Unless this information is revealed, the user’s balance is effectively frozen, as no one knows the balance at state B and consequently can not call increase_balance.

The state diffs contain information on every contact whose storage was updated, and additional information on contract deployments. Those differences are sent as unit256[] calldata, that is  encoded as follows:

len(deployments_info), ... , num_of_updates, contract_address, num_of_storage_updates, address, value

Where each deployment data in the above takes the following form:

contact_address, contract_hash, len(call_data), call_data

Consider the following example:

[5, 2472939307328371039455977650994226407024607754063562993856224077254594995194, 1336043477925910602175429627555369551262229712266217887481529642650907574765, 2, 955723665991825982403667749532843665052270105995360175183368988948217233556, 2439272289032330041885427773916021390926903450917097317807468082958581062272, 5, 2019172390095051323869047481075102003731246132997057518965927979101413600827, 1, 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, 5, is len(deployments_info), the number of elements that comprise the new contract deployments data
  • Those next five elements describe a single contract deployment with the following parameters:
    • Contract address: 2472939307328371039455977650994226407024607754063562993856224077254594995194
    • Contract hash: 1336043477925910602175429627555369551262229712266217887481529642650907574765
    • Two constructor arguments (indicated by the cell at index 3):
      • 955723665991825982403667749532843665052270105995360175183368988948217233556
      • 2439272289032330041885427773916021390926903450917097317807468082958581062272
  • The next element, 5 (index 6 in the array), is num_of_updates. This is the number of contracts whose storage was updated. We will take only the first contract as an example.
    • Contract address: 2019172390095051323869047481075102003731246132997057518965927979101413600827
      • One update (indicated by the cell at index 8):
        • The value at key 5 was changed to 102.

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

In the future we will publish a script that retrieves the above data by querying the corresponding events on Ethereum.