Skip to content

Commit c014299

Browse files
authored
Small typos in documentation (#97)
* Small typo * Small typo * Diagram is below the text * Change period to comma
1 parent ce6a44a commit c014299

File tree

3 files changed

+4
-4
lines changed

3 files changed

+4
-4
lines changed

src/content/docs/en/learn/zero-knowledge/kzg-commitment-scheme.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@ whatsnext: { "Additional Resources": "/learn/zero-knowledge/additional-zk-learni
1010

1111
One of the most widely used polynomial commitment schemes is the KZG commitment scheme. The scheme was originally [published](https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf) in 2010 by Kate, Zaverucha, and Goldberg.
1212

13-
KZG is used Ethereum’s [Proto-Danksharding](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq), and is also used in Scroll's proof system.
13+
KZG is used in Ethereum’s [Proto-Danksharding](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq), and is also used in Scroll's proof system.
1414

1515
This article will give an overview of the KZG commitment scheme.
1616

src/content/docs/en/technology/chain/rollup.mdx

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -43,7 +43,7 @@ The rollup process can be broken down into three phases: transaction execution,
4343

4444
### Phase 3. Proof Generation and Finalization
4545

46-
7. Once the coordinator polls a new chunk or batch fromm the database:
46+
7. Once the coordinator polls a new chunk or batch from the database:
4747
- Upon a new chunk, the coordinator will query the execution traces of all blocks in this chunk from the L2 sequencer and then send a chunk proving task to a randomly selected zkEVM prover.
4848
- Upon a new batch, the coordinator will collect the chunk proofs of all chunks in this batch from the database and dispatch a batch proving task to a randomly selected aggregator prover.
4949
8. Upon the coordinator receives a chunk or batch proofs from a prover, it will write the proof to the database.

src/content/docs/en/technology/sequencer/zktrie.mdx

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -20,7 +20,7 @@ You can also explore our [zktrie repo](https://github.com/scroll-tech/zktrie).
2020

2121
## Tree Structure
2222

23-
zkTrie is a sparse binary Merkle Patricia Trie, depicted in the above figure.
23+
zkTrie is a sparse binary Merkle Patricia Trie, depicted in the below figure.
2424
Before diving into the Sparse Binary Merkle Patricia Trie, let's briefly touch on Merkle Trees and Patricia Tries.
2525
* **Merkle Tree**: A Merkle Tree is a tree where each leaf node represents a hash of a data block, and each non-leaf node represents the hash of its child nodes.
2626
* **Patricia Trie**: A Patricia Trie is a type of radix tree or compressed trie used to store key-value pairs efficiently. It encodes the nodes with same prefix of the key to share the common path, where the path is determined by the value of the node key.
@@ -40,7 +40,7 @@ Given a key-value pair, we first compute a *secure key* for the corresponding le
4040

4141
We encode the path of a new leaf node by traversing the secure key from Least Significant Bit (LSB) to the Most Significant Bit (MSB). At each step, if the bit is 0, we will traverse to the left child; otherwise, traverse to the right child.
4242

43-
We limit the maximum depth of zkTrie to 248, meaning that the tree will only traverse the lower 248 bits of the key. Because the secure key space is a finite field used by Poseidon hash that doesn't occupy the full range of $2^{256}$. the bit representation of the key can be ambiguous in the finite field and thus results in a soundness issue in the zk circuit. After we truncate the key to lower 248 bits, the key space can fully occupy the range of $2^{248}$ and won't have the ambiguity in the bit representation.
43+
We limit the maximum depth of zkTrie to 248, meaning that the tree will only traverse the lower 248 bits of the key. Because the secure key space is a finite field used by Poseidon hash that doesn't occupy the full range of $2^{256}$, the bit representation of the key can be ambiguous in the finite field and thus results in a soundness issue in the zk circuit. After we truncate the key to lower 248 bits, the key space can fully occupy the range of $2^{248}$ and won't have the ambiguity in the bit representation.
4444

4545
We apply an optimization to reduce the tree depth by contracting a subtree that has only one leaf node to a single leaf node. For example, in the Figure 1, the tree has three nodes in total, with keys `0100`, `0010`, and `1010`. Because there is only one node that has key with suffix `00`, the leaf node for key `0100` only traverses the suffix `00` and doesn't fully expand its key which would have resulted in depth of 4.
4646

0 commit comments

Comments
 (0)