chore: fix some minor issues in comments

doc/book/crypto-intro/merkle-trees.html

@@ -181,7 +181,7 @@ <h1 id="merkle-trees"><a class="header" href="#merkle-trees">Merkle Trees</a></h
 <p>Merkle trees take advantage of the properties of hash functions discussed above and can perform many functions in this way. There are many different variants of Merkle trees, in this case we first look at simple Merkle trees built on a binary search tree.</p>
 <p>The leaves of the tree store data that has been hashed using a hash function. Subsequently, the resulting hash values of each of two leaf nodes are also hashed again and the resulting hash forms the parent node of these two leaf nodes. The process of producing parent nodes by taking hash values from two child nodes is performed recursively until we have only one hash value, often referred to as a Merkle root or root hash.</p>
 <p>Since for the same input in hash functions always the same output comes out, therefore the hash value of the parent node depends directly on the hash values of the children. So, accordingly, the root depends on all the hash values in the tree and thus all the data (hashed as leaves) in the Merkle tree. Moreover, we know that in practice it should not be possible for two different inputs to produce the same output. In this way, the integrity of the data can be checked: we can thus quickly determine whether data within a tree has changed based only on the root, since we can be sure that the original root could only have come about through the input of that very data.</p>
-<p>But why the tree? One can come up with the idea of simply putting all the data strung together into a hash function and even then the ouput would be unique to the input. The biggest advantage lies in the fact that in this way an efficient verifiability of individual contained data is made possible. No matter how many leaves there are in the tree, all that is needed to prove a single data point is the hash value of the data point itself, plus any sibling nodes on the way to the root. The depth of the tree is always logarithmic to the number of data in the binary Merkle tree, which can be considered efficient. Here is a pictorial illustration.</p>
+<p>But why the tree? One can come up with the idea of simply putting all the data strung together into a hash function and even then the output would be unique to the input. The biggest advantage lies in the fact that in this way an efficient verifiability of individual contained data is made possible. No matter how many leaves there are in the tree, all that is needed to prove a single data point is the hash value of the data point itself, plus any sibling nodes on the way to the root. The depth of the tree is always logarithmic to the number of data in the binary Merkle tree, which can be considered efficient. Here is a pictorial illustration.</p>
 
                     </main>
 

doc/book/insert-update-proofs.html

@@ -208,7 +208,7 @@ <h2 id="proof-of-insert"><a class="header" href="#proof-of-insert">Proof-of-Inse
 <p>Insertion proofs consist of the inserted key, a non-membership proof of the node in the current tree, a membership proof of the new node in the JMT, and the updated merkle root.</p>
 <p>The non-inclusion proof has two variants for different cases:</p>
 <ol>
-<li>A leaf exists where the missing leaf <em>should</em> be, sharing a prefix with the key (recall that the path to the leaf is determined by the key bytes, and paths get compressed for effeciency)</li>
+<li>A leaf exists where the missing leaf <em>should</em> be, sharing a prefix with the key (recall that the path to the leaf is determined by the key bytes, and paths get compressed for efficiency)</li>
 <li>The node key leads to an empty subtree</li>
 </ol>
 <p>After finding the position the new node should be inserted into, it is inserted and a membership proof is created.</p>

doc/book/print.html

@@ -389,7 +389,7 @@ <h2 id="proof-of-insert"><a class="header" href="#proof-of-insert">Proof-of-Inse
 <p>Insertion proofs consist of the inserted key, a non-membership proof of the node in the current tree, a membership proof of the new node in the JMT, and the updated merkle root.</p>
 <p>The non-inclusion proof has two variants for different cases:</p>
 <ol>
-<li>A leaf exists where the missing leaf <em>should</em> be, sharing a prefix with the key (recall that the path to the leaf is determined by the key bytes, and paths get compressed for effeciency)</li>
+<li>A leaf exists where the missing leaf <em>should</em> be, sharing a prefix with the key (recall that the path to the leaf is determined by the key bytes, and paths get compressed for efficiency)</li>
 <li>The node key leads to an empty subtree</li>
 </ol>
 <p>After finding the position the new node should be inserted into, it is inserted and a membership proof is created.</p>
@@ -950,7 +950,7 @@ <h1 id="merkle-trees"><a class="header" href="#merkle-trees">Merkle Trees</a></h
 <p>Merkle trees take advantage of the properties of hash functions discussed above and can perform many functions in this way. There are many different variants of Merkle trees, in this case we first look at simple Merkle trees built on a binary search tree.</p>
 <p>The leaves of the tree store data that has been hashed using a hash function. Subsequently, the resulting hash values of each of two leaf nodes are also hashed again and the resulting hash forms the parent node of these two leaf nodes. The process of producing parent nodes by taking hash values from two child nodes is performed recursively until we have only one hash value, often referred to as a Merkle root or root hash.</p>
 <p>Since for the same input in hash functions always the same output comes out, therefore the hash value of the parent node depends directly on the hash values of the children. So, accordingly, the root depends on all the hash values in the tree and thus all the data (hashed as leaves) in the Merkle tree. Moreover, we know that in practice it should not be possible for two different inputs to produce the same output. In this way, the integrity of the data can be checked: we can thus quickly determine whether data within a tree has changed based only on the root, since we can be sure that the original root could only have come about through the input of that very data.</p>
-<p>But why the tree? One can come up with the idea of simply putting all the data strung together into a hash function and even then the ouput would be unique to the input. The biggest advantage lies in the fact that in this way an efficient verifiability of individual contained data is made possible. No matter how many leaves there are in the tree, all that is needed to prove a single data point is the hash value of the data point itself, plus any sibling nodes on the way to the root. The depth of the tree is always logarithmic to the number of data in the binary Merkle tree, which can be considered efficient. Here is a pictorial illustration.</p>
+<p>But why the tree? One can come up with the idea of simply putting all the data strung together into a hash function and even then the output would be unique to the input. The biggest advantage lies in the fact that in this way an efficient verifiability of individual contained data is made possible. No matter how many leaves there are in the tree, all that is needed to prove a single data point is the hash value of the data point itself, plus any sibling nodes on the way to the root. The depth of the tree is always logarithmic to the number of data in the binary Merkle tree, which can be considered efficient. Here is a pictorial illustration.</p>
 <div style="break-before: page; page-break-before: always;"></div><link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/katex@0.16.4/dist/katex.min.css">
 <h1 id="cryptographic-commitments"><a class="header" href="#cryptographic-commitments">Cryptographic commitments</a></h1>
 <p>maybe for the crypto intro</p>

doc/src/crypto-intro/merkle-trees.md

@@ -8,4 +8,4 @@ The leaves of the tree store data that has been hashed using a hash function. Su
 
 Since for the same input in hash functions always the same output comes out, therefore the hash value of the parent node depends directly on the hash values of the children. So, accordingly, the root depends on all the hash values in the tree and thus all the data (hashed as leaves) in the Merkle tree. Moreover, we know that in practice it should not be possible for two different inputs to produce the same output. In this way, the integrity of the data can be checked: we can thus quickly determine whether data within a tree has changed based only on the root, since we can be sure that the original root could only have come about through the input of that very data.
 
-But why the tree? One can come up with the idea of simply putting all the data strung together into a hash function and even then the ouput would be unique to the input. The biggest advantage lies in the fact that in this way an efficient verifiability of individual contained data is made possible. No matter how many leaves there are in the tree, all that is needed to prove a single data point is the hash value of the data point itself, plus any sibling nodes on the way to the root. The depth of the tree is always logarithmic to the number of data in the binary Merkle tree, which can be considered efficient. Here is a pictorial illustration.
+But why the tree? One can come up with the idea of simply putting all the data strung together into a hash function and even then the output would be unique to the input. The biggest advantage lies in the fact that in this way an efficient verifiability of individual contained data is made possible. No matter how many leaves there are in the tree, all that is needed to prove a single data point is the hash value of the data point itself, plus any sibling nodes on the way to the root. The depth of the tree is always logarithmic to the number of data in the binary Merkle tree, which can be considered efficient. Here is a pictorial illustration.

doc/src/insert-update-proofs.md

@@ -46,7 +46,7 @@ Insertion proofs consist of the inserted key, a non-membership proof of the node
 
 The non-inclusion proof has two variants for different cases:
 
-1. A leaf exists where the missing leaf *should* be, sharing a prefix with the key (recall that the path to the leaf is determined by the key bytes, and paths get compressed for effeciency)
+1. A leaf exists where the missing leaf *should* be, sharing a prefix with the key (recall that the path to the leaf is determined by the key bytes, and paths get compressed for efficiency)
 2. The node key leads to an empty subtree
 
 After finding the position the new node should be inserted into, it is inserted and a membership proof is created.