You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: components/Starknet/modules/architecture-and-concepts/pages/network-architecture/starknet-state.adoc
+46-46Lines changed: 46 additions & 46 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,33 +1,56 @@
1
1
[id="starknet_state"]
2
-
= Starknet state
2
+
= State
3
3
:stem: latexmath
4
4
5
+
== Overview
6
+
7
+
Starknet's state xref:state_structure[is composed of contract classes and instances] and xref:state_transition[tracks any changes to them]. Its xref:state_commitment[commitment] uses a cryptographic structure optimized for zero-knowledge proofs, enabling efficient proof generation of state updates and forming the backbone of Starknet's scalability and security.
8
+
9
+
== State structure
5
10
Starknet's state consists of:
6
11
7
-
[horizontal,labelwidth="25",role="stripes-odd"]
8
-
xref:architecture-and-concepts:smart-contracts/contract-classes.adoc[Contract classes]:: a mapping
9
-
between the class hash and the class definition
10
-
xref:architecture-and-concepts:smart-contracts/contract-classes.adoc[Contract instances]:: a mapping between addresses (251-bit field elements) and the contract's state
12
+
* A mapping between the hashes of contract classes and their definitions
13
+
* A mapping between the addresses of contract instances and their xref:contract_instance_state[states]
14
+
15
+
=== Contract instance state
16
+
17
+
A contract instance state consists of:
18
+
19
+
* A class hash, which defines the functionality of the contract
20
+
* A key-value mapping (where the key and values are field elements), which comprises the contract's storage
21
+
* A nonce, which tracks the number of transactions sent from this contract
11
22
12
-
A contract instance's state consists of:
23
+
=== Special addresses
24
+
25
+
Starknet uses special contract addresses to provide distinct capabilities beyond regular contract deployment.
26
+
27
+
Two such addresses are `0x0` and `0x1`. These addresses are reserved for specific purposes and are
28
+
characterized by their unique behavior in comparison to traditional contract addresses.
13
29
14
-
[horizontal,labelwidth="25",role="stripes-odd"]
15
-
xref:smart-contracts/class-hash.adoc[Class hash]:: defines the functionality of the contract
16
-
xref:smart-contracts/contract-storage.adoc[Contract storage]:: a key-value mapping where the key/values are field elements
17
-
xref:accounts/approach.adoc#replay_protection[Contract nonce]:: the number of transactions sent from this contract
30
+
==== Address `0x0`
31
+
32
+
Address `0x0` functions as the default `caller_address` for external calls, including interactions with the L1 handler or deprecated Deploy transactions. Unlike regular contracts, address `0x0` does not possess a storage structure and does not accommodate storage mapping.
33
+
34
+
==== Address `0x1`
35
+
36
+
Address `0x1` is another special contract address within Starknet's architecture. It functions as a storage space for mapping block numbers to their corresponding block hashes. The storage structure at this address is organized as follows:
37
+
38
+
[horizontal,labelwidth="20"]
39
+
Keys:: Block numbers between stem:[\text{first_v0_12_0_block}] and stem:[\text{current_block - 10}].
40
+
Values:: Corresponding block hashes for the specified blocks.
41
+
Default Values:: For all other block numbers, the values are set to `0`.
18
42
19
-
[#transitioning_to_a_new_state]
20
-
== Transitioning to a new state
43
+
The storage organization of address `0x1` supports the efficient retrieval of block hashes based on block numbers within a defined range and is also used by the xref:architecture-and-concepts:smart-contracts/system-calls-cairo1.adoc#get_block_hash[`get_block_hash`] system call.
21
44
45
+
== State transition
22
46
A transaction stem:[$tx$] transitions the system from state stem:[$S$] to state stem:[$S'$] if:
23
47
24
-
* stem:[$tx$] is an xref:network-architecture/transactions.adoc#invoke_transaction[Invoke] transaction, and the storage of stem:[$S'$] is the result of executing the target contract code with respect to the previous state stem:[$S$]. The arguments,
48
+
* stem:[$tx$] is an `INVOKE` transaction, and the storage of stem:[$S'$] is the result of executing the target contract code with respect to the previous state stem:[$S$]. The arguments,
25
49
contract instance's address, and the specific function entry point are part of the transaction.
26
-
* stem:[$tx$] is a xref:network-architecture/transactions.adoc#deploy_account_transaction[Deploy account] transaction, and stem:[$S'$] contains the new contract instance's state at the contract instance's address. Additionally, the storage of stem:[$S$] is updated
50
+
* stem:[$tx$] is a `DEPLOY_ACCOUNT` transaction, and stem:[$S'$] contains the new contract instance's state at the contract instance's address. Additionally, the storage of stem:[$S$] is updated
27
51
according to the execution of the contract instance's constructor.
28
-
* stem:[$tx$] is a xref:network-architecture/transactions.adoc#declare-transaction[Declare] transaction, and stem:[$S'$] contains the class hash and definition in the contract class's mapping
52
+
* stem:[$tx$] is a `DECALRE` transaction, and stem:[$S'$] contains the class hash and definition in the contract class's mapping
29
53
30
-
[id="state_commitment"]
31
54
== State commitment
32
55
33
56
The state commitment is a digest that represents the state.
@@ -54,7 +77,7 @@ function.
54
77
[id="contracts_trie"]
55
78
=== The contract trie
56
79
57
-
As with Ethereum, this trie is a two-level structure, whose leaves correspond to distinct contracts. The address of each contract determines the path from the trie’s root to its corresponding leaf, whose content encodes the contract’s state.
80
+
As with Ethereum, this trie is a two-level structure, whose leaves correspond to distinct contracts. The address of each contract determines the path from the trie's root to its corresponding leaf, whose content encodes the contract's state.
58
81
59
82
The information stored in the leaf is as follows:
60
83
@@ -126,16 +149,16 @@ In the future, when Sierra-to-Casm compilation becomes part of the Starknet OS,
126
149
====
127
150
128
151
[#merkle_patricia_trie]
129
-
== Merkle-Patricia trie
152
+
=== Merkle-Patricia trie
130
153
131
154
The state commitment scheme uses a binary Merkle-Patricia trie with the Pedersen hash function.
132
155
133
156
[#about_nodes]
134
-
=== About nodes
157
+
==== About nodes
135
158
136
159
Each node in the trie is represented by a triplet stem:[$(length, path, value)$], where:
137
160
138
-
[horizontal,labelwidth=10,role="stripes-odd"]
161
+
[horizontal,labelwidth=10]
139
162
stem:[$length$]:: is the length of the path, measured in nodes.
140
163
141
164
stem:[$path$]:: is the path from the current node to its unique non-empty subtrie.
@@ -156,7 +179,7 @@ Length is specified, and cannot be deduced from stem:[$path$], because the numbe
156
179
For a node where stem:[$length>0$], stem:[$path$] leads to the highest node whose left and right children are not empty.
157
180
====
158
181
159
-
=== Trie construction
182
+
==== Trie construction
160
183
161
184
The following rules specify how the trie is constructed from a given set of leaves:
All arithmetic operations in the above description of stem:[$H$] are done in the STARK field, as described in xref:cryptography.adoc#stark-field[The STARK field].
176
199
====
177
200
178
-
=== Mathematical definition of the nodes in the trie
201
+
==== Mathematical definition of the nodes in the trie
179
202
180
203
The triplet representing the parent of the nodes stem:[$left=(\ell_L, p_L, v_L)$], stem:[$right=(\ell_R, p_R, v_R)$] is defined as follows:
181
204
@@ -190,8 +213,7 @@ parent=
190
213
\end{cases}
191
214
++++
192
215
193
-
[#example_trie]
194
-
=== Example trie
216
+
==== Example trie
195
217
196
218
The diagram xref:#3-level_trie[] illustrates the construction of a three-level-high Merkle-Patricia trie from the leaves whose values are stem:[$(0,0,1,0,0,1,0,0)$]:
197
219
@@ -204,25 +226,3 @@ Where stem:[$r=h_{Ped}(H(2,2,1),H((2,1,1))$]. Notice that the example does not s
204
226
Suppose that you want to prove, with respect to the state commitment just computed, that the value of the leaf whose path is given by stem:[$101$] is stem:[$1$]. In a standard Merkle trie, the proof would consist of data from three nodes, which are siblings along the path to the root.
205
227
206
228
In a Merkle-Patricia trie, because the trie is sparse, you only need to send the two children of the root, which are stem:[$(2,2,1)$] and stem:[$(2,1,1)$]. These two children are enough to reproduce the state commitment stem:[$r$], and because you know that the height of the trie is three, and that it is fixed, you know that the path stem:[$01$] of length stem:[$2$] specified by the right-hand child, stem:[$(2,1,1)$], leads to the desired leaf.
207
-
208
-
== Special addresses
209
-
210
-
Starknet uses special contract addresses to provide distinct capabilities beyond regular contract deployment.
211
-
212
-
Two such addresses are `0x0` and `0x1`. These addresses are reserved for specific purposes and are
213
-
characterized by their unique behavior in comparison to traditional contract addresses.
214
-
215
-
=== Address `0x0`
216
-
217
-
Address `0x0` functions as the default `caller_address` for external calls, including interactions with the L1 handler or deprecated Deploy transactions. Unlike regular contracts, address `0x0` does not possess a storage structure and does not accommodate storage mapping.
218
-
219
-
=== Address `0x1`
220
-
221
-
Address `0x1` is another special contract address within Starknet's architecture. It functions as a storage space for mapping block numbers to their corresponding block hashes. The storage structure at this address is organized as follows:
222
-
223
-
[horizontal,labelwidth="20",role="stripes-odd"]
224
-
Keys:: Block numbers between stem:[\text{first_v0_12_0_block}] and stem:[\text{current_block - 10}].
225
-
Values:: Corresponding block hashes for the specified blocks.
226
-
Default Values:: For all other block numbers, the values are set to `0`.
227
-
228
-
The storage organization of address `0x1` supports the efficient retrieval of block hashes based on block numbers within a defined range and is also used by the xref:architecture-and-concepts:smart-contracts/system-calls-cairo1.adoc#get_block_hash[`get_block_hash`] system call.
0 commit comments