Small typos in documentation (#97)

* Small typo

* Small typo

* Diagram is below the text

* Change period to comma

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

@@ -10,7 +10,7 @@ whatsnext: { "Additional Resources": "/learn/zero-knowledge/additional-zk-learni
 
 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.
 
-KZG is used Ethereum’s [Proto-Danksharding](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq), and is also used in Scroll's proof system.
+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.
 
 This article will give an overview of the KZG commitment scheme.
 

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

@@ -43,7 +43,7 @@ The rollup process can be broken down into three phases: transaction execution,
 
 ### Phase 3. Proof Generation and Finalization
 
-7. Once the coordinator polls a new chunk or batch fromm the database:
+7. Once the coordinator polls a new chunk or batch from the database:
    - 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.
    - 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.
 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

@@ -20,7 +20,7 @@ You can also explore our [zktrie repo](https://github.com/scroll-tech/zktrie).
 
 ## Tree Structure
 
-zkTrie is a sparse binary Merkle Patricia Trie, depicted in the above figure.
+zkTrie is a sparse binary Merkle Patricia Trie, depicted in the below figure.
 Before diving into the Sparse Binary Merkle Patricia Trie, let's briefly touch on Merkle Trees and Patricia Tries.
 * **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.
 * **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
 
 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.
 
-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.
+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.
 
 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.