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: docs/zkEVM/architecture/zkprover/mem-align-sm.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -90,7 +90,7 @@ $$
90
90
in the address $\mathtt{0x22}$ of the byte-addressed Ethereum memory. We are using the same $\mathtt{m}_0$ and $\mathtt{m}_1$ (and since we are writing into the same address as before) and they will transition into:
Copy file name to clipboardExpand all lines: docs/zkEVM/architecture/zkprover/memory-sm.md
+8Lines changed: 8 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,6 +14,8 @@ Now, let's see the layout in memory of the following two words $\texttt{0xc417..
14
14
15
15
The below table displays this layout. Let's call this Table 1.
16
16
17
+
<center>
18
+
17
19
| $\mathbf{ADDRESS}$ | $\mathbf{BYTE}$ |
18
20
| :----------------: | :---------------: |
19
21
| $\mathtt{0}$ | $\mathtt{0xc4}$ |
@@ -27,6 +29,8 @@ The below table displays this layout. Let's call this Table 1.
27
29
| $\mathtt{62}$ | $\mathtt{0xb7}$ |
28
30
| $\mathtt{63}$ | $\mathtt{0x23}$ |
29
31
32
+
</center>
33
+
30
34
Observe that each word has 32 bytes and the words are stored in Big-Endian form. So, the most significant bytes are set in the lower addresses. The EVM provides three opcodes to interact with the memory area. **There is an opcode to read, and an opcode to write 32-byte words providing an offset**:
31
35
32
36
- $\texttt{MLOAD}$: It receives an offset and returns the 32 bytes in memory starting at that offset
@@ -36,6 +40,8 @@ Considering our previous memory contents, if we perform an $\texttt{MLOAD}$ with
36
40
37
41
On the other hand, if we do an $\texttt{MSTORE}$ with an offset of $\texttt{1}$ with the word $\texttt{0x74f0...ce92}$, we would modify the content of the memory as shown in the below table (or Table 2).
38
42
43
+
<center>
44
+
39
45
| $\mathbf{ADDRESS}$ | $\mathbf{BYTE}$ |
40
46
| :----------------: | :----------------------: |
41
47
| $\mathtt{0}$ | $\mathtt{0xc4}$ |
@@ -49,6 +55,8 @@ On the other hand, if we do an $\texttt{MSTORE}$ with an offset of $\texttt{1}$
49
55
| $\mathtt{62}$ | $\mathtt{0xb7}$ |
50
56
| $\mathtt{63}$ | $\mathtt{0x23}$ |
51
57
58
+
</center>
59
+
52
60
When the offset is not a multiple of 32 (or 0x20), as in the previous example, we have to use bytes from two different words when doing $\texttt{MLOAD}$ or $\texttt{MSTORE}$.
53
61
54
62
Finally, the EVM provides a write memory operation that just writes a byte:
Copy file name to clipboardExpand all lines: docs/zkEVM/architecture/zkprover/paddingkk-bit-sm.md
+33-37Lines changed: 33 additions & 37 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -170,43 +170,39 @@ Now, the last part of the Padding-KK-Bit SM is to keep track of the last subdivi
170
170
Consider the 256 bits, $\mathtt{0b|10110011\dots1010|\dots|11\dots11|01\dots10101101|}$, where "$|$" separates every set of 32 bits. The table below displays how the $256 + 1$ rows of a $1993$-block are stored in the registers $\{\mathtt{sOut_i}|\ 0 \leq i \leq 7 \}$.
Observe how factors $\{\mathtt{FSOut_i} |\ 0 \leq i \leq 7\}$, in the above table, are used to construct the $32$-bit registers $\{\mathtt{sOut_i}|\ 0 \leq \mathtt{i} \leq 7 \}$. Note that the last row contains the complete set of the $256$ bits. These columns fulfil the following relations,
0 commit comments