Explorar el Código

book: Fix typos

This fixes some typos in the mdbook (#177)
omahs hace 3 años
padre
commit
5f0559e910

+ 9 - 9
doc/src/architecture/blockchain.md

@@ -11,7 +11,7 @@ Blockchain $\mathbb{C_{loc}}$ is a series of epochs: it's a tree of chains,
 $C^1$, $C^2$, $\dots$, $C^n$, the chain ending in a single leader per slot single finalization.
 
 Crypsinous Blockchain is built on top of Zerocash sapling scheme, and Ouroboros Genesis  blockchain.
-Each participant $U_p$ stores it's own local view of the Blockchain $C_{loc}^{U_p}$.
+Each participant $U_p$ stores its own local view of the Blockchain $C_{loc}^{U_p}$.
 $C_{loc}$ is a sequence of blocks $B_i$ (i>0), where each $B \in C_{loc}$
 $$ B = (tx_{lead},st)$$
 $$tx_{lead} = (LEAD, header, txs, stx_{proof})$$
@@ -58,7 +58,7 @@ validation of proposed lead proof as follows:
 * verify block header hash
 * public inputs $\mu_y$, $\mu_{rho}$ are hash of current consensus $\eta$, and current slot
 * public inputs of target 2-term approximations $\sigma_1$, $\sigma_2$ are valid given total network stake and controller parameters
-* the competing coin nullifier isn't published before to protect against double spening, before burning the coin.
+* the competing coin nullifier isn't published before to protect against double spending, before burning the coin.
 * verify block transactions
 
 <!--
@@ -100,7 +100,7 @@ $$sn_{c_i}=PRF_{root_{sk_{c_i}^{COIN}}}^{sn}(\rho_{c_i}), \forall_i \in \{1,2\}$
 
 ## Epoch
 
-An epoch is a vector of blocks. Some of the  blocks might be empty if there is no winnig leader. tokens in stake are constant during the epoch.
+An epoch is a vector of blocks. Some of the  blocks might be empty if there is no winning leader. tokens in stake are constant during the epoch.
 
 ## Leader selection
 
@@ -133,9 +133,9 @@ family of functions.
 
 ### automating f tuning
 
-the stable consensus token supply is maintained by the help of discrete PID controller, that maintain stabilized occurance of single leader per slot.
+the stable consensus token supply is maintained by the help of discrete PID controller, that maintain stabilized occurrence of single leader per slot.
 
-#### control lottery f tunning paramter
+#### control lottery f tunning parameter
 
 $$f[k] = f[k-1] + K_1e[k] + K_2e[k-1] + K_3e[k-2]$$
 
@@ -233,7 +233,7 @@ be used by the protocol.
 | `rho_mu`     | `pallas::Base` | random seed base from blockchain                      |
 | `rho`        | `pallas::Base` | hash of random seed and `rho_mu` to constrain lottery |
 | `sigma1`     | `pallas::Base` | first term in 2-terms target approximation.           |
-| `sigma2`     | `pallas::Base` | second term in 2-terms target approximatino.          |
+| `sigma2`     | `pallas::Base` | second term in 2-terms target approximation.          |
 
 
 ### Linear family functions
@@ -333,7 +333,7 @@ assume there is a solution for the lead statement parameters and constants $S, f
 for the statement $y<T$, $$T=L\phi_{max}\phi(\alpha)=S\phi(\alpha)$$
 $$S=ord(G)\phi_{max}\phi(\alpha)$$
 such that S $in Z$
-$\phi_{max}=\phi(\alpha_{max})$ where $\alpha_{max}$ is the maximum stake value being $2^{64}$, following from the previous proof that the family of function haveing independent aggregation property is the exponential function $f^\alpha$, and $f \in Z | f>1$, the smallest value satisfying f is $f=2$, then $$\phi_{max} = 2^{2^{64}}$$
+$\phi_{max}=\phi(\alpha_{max})$ where $\alpha_{max}$ is the maximum stake value being $2^{64}$, following from the previous proof that the family of function having independent aggregation property is the exponential function $f^\alpha$, and $f \in Z | f>1$, the smallest value satisfying f is $f=2$, then $$\phi_{max} = 2^{2^{64}}$$
 note that since $ord(G)<<\phi_{max}$ thus $S<<1$, contradiction.
 
 
@@ -355,11 +355,11 @@ R is the epoch length in terms of slots.
 
 ### toward better decentralization in ouroboros
 
-the randomization of the leader selection at each slot is hinged on the random $y$, $\mu_y$, $\rho_c$, those three values are dervied from $\eta$, and root of the secret keys, the root of the secret keys for each stakeholder can be sampled, and derived beforehand, but $\eta$ is a response to global random oracle query, so it's security is hinged on $\textit{centralized global random node}$.
+the randomization of the leader selection at each slot is hinged on the random $y$, $\mu_y$, $\rho_c$, those three values are derived from $\eta$, and root of the secret keys, the root of the secret keys for each stakeholder can be sampled, and derived beforehand, but $\eta$ is a response to global random oracle query, so it's security is hinged on $\textit{centralized global random node}$.
 
 #### solution
 
-to break this centeralization, a decentralized emulation of $G_{ro}$ functionality for calculation of: $\eta_i=PRF^{G_{ro}}_{\eta_{i-1}}(\psi)$
+to break this centralization, a decentralized emulation of $G_{ro}$ functionality for calculation of: $\eta_i=PRF^{G_{ro}}_{\eta_{i-1}}(\psi)$
 $$\psi   =  hash(tx^{ep}_{0})$$
 $$\eta_0 =  hash(\mathrm{"let\; there\; be\; dark!"})$$
 note that first transaction in the block, is the proof transaction.

+ 3 - 3
doc/src/architecture/consensus.md

@@ -14,7 +14,7 @@ blockchain achieve consensus.
 | Leader                 | Block producer                                                                            |
 | Unproposed Transaction | Transaction that exists in the memory pool but has not yet been included in a block       |
 | Block proposal         | Block that has not yet been appended onto the canonical blockchain                        |
-| P2P network            | Peer-to-peer network on which nodes communicate with eachother                            |
+| P2P network            | Peer-to-peer network on which nodes communicate with each other                            |
 | Finalization           | State achieved when a block and its contents are appended to the canonical blockchain     |
 | Fork                   | Chain of block proposals that begins with the last block of the canonical blockchain      |
 
@@ -73,7 +73,7 @@ Upon receiving a block, one of the following cases may occur:
 
 ### Visual Examples
 
-| Sympol        | Description                            |
+| Symbol        | Description                            |
 |---------------|----------------------------------------|
 | [C]           | Canonical(finalized) blockchain block  |
 | [C]--...--[C] | Sequence of canonical blocks           |
@@ -129,7 +129,7 @@ to the canonical blockchain.
 Once finalized, all fork chains are removed from the memory pool.
 Practically this means that no finalization can occur while there are
 competing fork chains of the same length. In such a case, finalization
-can only occur when we have a a slot with a single leader.
+can only occur when we have a slot with a single leader.
 
 We continue Case 3 from the previous section to visualize this logic.
 On slot 5, a node observes 2 proposals. One extends the F0 fork,

+ 1 - 1
doc/src/architecture/smart_contracts.md

@@ -209,7 +209,7 @@ And corresponding function calls.
 ```
 
 As we can see the ZK proofs and signatures are separate from the
-actuall `call_data` interpreted by `state_transition()`. They are
+actual `call_data` interpreted by `state_transition()`. They are
 both automatically verified by the VM.
 
 However for verification to work, the ZK proofs also need corresponding

+ 3 - 3
doc/src/architecture/tx_lifetime.md

@@ -32,7 +32,7 @@ chain:
 9. `CP` proposes a block finalization containing $tx$
 10. `CP` writes the state transition update of $tx$ to their chain
 11. `CP` removes $tx$ from their `mempool`
-12. `CP` broadcasts the finalizated proposal
+12. `CP` broadcasts the finalized proposal
 13. `CS` receives the proposal and validates transactions
 14. `CS` writes the state updates to their chain
 15. `CS` removes $tx$ from their `mempool`
@@ -56,7 +56,7 @@ chain:
 in sequence
 11. `CP` writes the state transition update of $tx$ to their chain
 12. `CP` removes $tx$ from their `mempool`
-13. `CP` broadcasts the finalizated proposals sequence
+13. `CP` broadcasts the finalized proposals sequence
 14. `CS` receives the proposals sequence and validates transactions
 15. `CS` writes the state updates to their chain
 16. `CS` removes $tx$ from their `mempool`
@@ -87,7 +87,7 @@ transactions in sequence, against canonical state
 15. `CP` writes the state transition update of $tx$ to their chain
 16. `CP` removes $tx$ from their `mempool`
 17. `CP` drop rest forks and keeps only the finalized one
-18. `CP` broadcasts the finalizated proposals sequence
+18. `CP` broadcasts the finalized proposals sequence
 19. `CS` receives the proposals sequence and validates transactions
 20. `CS` writes the state updates to their chain
 21. `CS` removes $tx$ from their `mempool`

+ 1 - 1
doc/src/tutorial.md

@@ -184,7 +184,7 @@ following command:
 
 ## Receive
 
-To receive anonymous tokens your darkfid account, you must retrieve your
+To receive anonymous tokens on your darkfid account, you must retrieve your
 darkfi address. Send this address to others so they can send you tokens.
 
 ```