doc: Minor typo fixes

Signed-off-by: omahs <73983677+omahs@users.noreply.github.com>

doc/src/arch/arch.md

@@ -262,5 +262,5 @@ to properly price them for verification fees.
 
 ### Documentation
 
-* Create beginner level tutorial to introduce contract developement and tools.
+* Create beginner level tutorial to introduce contract development and tools.
 * Create a list of outstanding work before mainnet.

doc/src/arch/consensus.md

@@ -83,7 +83,7 @@ sum of its block's squared target distances, and the second being the sum of
 their squared hash distances. Squared distances are used to disproportionately
 favors smaller targets, with the idea being that it will be harder to trigger
 a longer reorg between forks. When we compare forks, we first check the first
-sum, and if its tied, we use the second as the tie breaker, since we know it
+sum, and if it's tied, we use the second as the tie breaker, since we know it
 will be statistically unique for each sequence.
 
 The ranking of a fork is always increasing as new blocks are appended.
@@ -163,7 +163,7 @@ Extending the canonical blockchain with a new block proposal:
 ## Finalization
 
 Based on the rank properties, each node will diverge to the highest ranking
-fork, and new fork wil emerge extending that at its tips.
+fork, and new fork will emerge extending that at its tips.
 A security threshold is set, which refers to the height where the probability
 to produce a fork, able to reorg the current best ranking fork reaches zero,
 similar to the # of block confirmation used by other PoW based protocols.
@@ -315,7 +315,7 @@ which means it's sufficient to compare $𝐚$ and $𝐛$ directly.
 
 ## Proposed Rank
 
-With a PoW mining system, we are guaranteed to always have that the block hash
+With a PoW mining system, we are guaranteed to always have the block hash
 $h(b) ≤ T(b)$. Since the block hashes $( h(b₁), …, h(bₘ) )$ for a sequence
 $( b₁, …, bₘ )$ have the property that $∑ h(bᵢ) ≤ ∑ T(bᵢ)$, as well as being
 sufficiently random, we can use them to define our work function.

doc/src/arch/dao.md

@@ -5,7 +5,7 @@
 There is a scheme called commit-and-reveal, where given an object $x$
 (or set of objects), you generate a random blind $b$, and construct the
 commitment $C = \textrm{hash}(x, b)$. By publishing $C$, you are
-commmitted to the value $x$.
+committed to the value $x$.
 
 Secondly, we may wish to publish long lived objects on the blockchain,
 which are essentially commitments to several parameters that represent
@@ -184,7 +184,7 @@ the vote is proposed.
 
 ## Forking the Global State (with SMT)
 
-Instead of revealing the nullifier, we instead snapshot the the nullifier
+Instead of revealing the nullifier, we instead snapshot the nullifier
 tree alongside $C$.
 
 The downsides are:
@@ -238,7 +238,7 @@ The proposal is as follows and involves a merkle tree $𝐂$, and a SMT $𝐍$.
 
 For the sake of clarity, we will not detail the storing of the trees themselves.
 For $𝐂$, the tree is stored in `db_info`, while $𝐍$ has a full on-disk
-representation. Instead the info in this section concerns the auxilliary data
+representation. Instead the info in this section concerns the auxiliary data
 required for using the trees with snapshotted states.
 
 ## DB Merkle Roots

doc/src/arch/overview.md

@@ -7,7 +7,7 @@ outline a few key terms that help explain DarkFi.
 **Blockchain:** The DarkFi blockchain is based off Proof of Work RandomX
 algorithm, paired with Delayed finality. Consensus participating nodes,
 called miners, produce and propose new blocks to the network, extending
-some fork chain, which once it reaches a finality security thresshold,
+some fork chain, which once it reaches a finality security threshold,
 can be appended to canonical by all nodes in the network.
 
 **Wallet:** A wallet is a portal to the DarkFi network. It provides
@@ -23,7 +23,7 @@ and P2P task manager [tau](../misc/tau.md).
 
 **ZK smart contracts:** Anonymous applications on DarkFi run on proofs
 that enforce an order of operations. We call these zero-knowledge smart
-contracts. Anonymous transactions on DarkFi is possible due to the
+contracts. Anonymous transactions on DarkFi are possible due to the
 interplay of two contracts, mint and burn (see the [sapling payment
 scheme](../zkas/examples/sapling.md)). Using the same method, we can
 define advanced applications.

doc/src/zero2darkfi/darkmap.md

@@ -6,13 +6,13 @@ Suppose you want to build a name registry.
 
 You want this to be:
 * resistant to any coercion
-* leaving no trace who owns a name
+* leaving no trace of who owns a name
 
 Because the users intend to use it for critical things that they like privacy for.
 Say naming their wallet address e.g. anon42's wallet address -> 0x696969696969.
 
 Getting a wrong wallet address means, you pay a bad person instead of anon42.
-Revealing who owns the name reveals information who might own the wallet.
+Revealing who owns the name reveals information on who might own the wallet.
 Both are unacceptable to your users.
 
 Upon examination we see backdoor in many solutions.
@@ -25,7 +25,7 @@ Upon examination we see backdoor in many solutions.
 An immutable name registry deployed on Darkfi.
 
 * names can be immutable, not even the name registry owner can change the name
-* there is no trace who owns the name
+* there is no trace of who owns the name
 
 ### API: Get
 
@@ -81,7 +81,7 @@ cd ../ && git clone https://github.com/darkrenaissance/darkmap
 ## Tool 1: `ZKAS`, `ZKVM`
 
 We want a way for someone to control an account and account to control one name registry. 
-You could use public key crytography.
+You could use public key cryptography.
 But in here, we will use ZK to accomplish the same thing for our learning.
 
 In Darkfi, circuits are programmed in `ZKAS` (ZK Assembly) and later run in `ZKVM` for generating proofs.
@@ -100,13 +100,13 @@ Let's see how to run the set_v1.zk by reading `<darkfi>/bin/zkrunner/README.md`.
 
 ### Outcome
 
-Good job! Now you have you learned how to prove and run using a ZKAS circuit.
+Good job! Now you have learned how to prove and run using a ZKAS circuit.
 
 ## Tool 2: WASM contract
 
 In Darkfi, a contract is deployed as a wasm module. 
 Rust has one of the best wasm support along with C and C++, so Darkmap is implemented in Rust.
-In theory, any language that compiles to wasm can be used make a contract.
+In theory, any language that compiles to wasm can be used to make a contract.
 
 Let's learn about the contract by reading `<darkmap>/src/entrypoints.rs`.
 
@@ -117,17 +117,17 @@ FIXME: perhaps more detailed explanation
 ## Deploying 
 
 Currently, the infrastructure for deploying non-native contracts is being worked on. 
-So Darkmap was tested by modifiying the darkfi validator to deploy it as native contract.
+So Darkmap was tested by modifying the darkfi validator to deploy it as native contract.
 
 If you like to try it out, take a look at the [pull request draft](https://codeberg.org/darkrenaissance/darkfi/pulls/170/files#diff-1592d061816d5a4da17e089758e15df75ae1ab963b2288e6d84b8f29b06f7d4f).
 
 In particular:
 * `src/consensus/validator.rs`
-* `sdk/src/crpyto/*`
+* `sdk/src/crypto/*`
 
 ## Testing and client implementation
 
-For now, the best place to learn is learn from the darkmap pull request draft or `src/contract/money`.
+For now, the best place to learn is to learn from the darkmap pull request draft or `src/contract/money`.
 
 ## Notes