nav test

docs/doc/whitepaper.md

@@ -137,7 +137,7 @@ An Ergo box is made of registers (and nothing but registers). Such a box can hav
 
 One-time immutable objects (as in Bitcoin's UTXO model) have some advantages over Ethereum's long-lived mutable accounts. Firstly, it gives easier and safer protection from replay or reordering attacks. Secondly, it is easier to process transactions in parallel because they don't modify the state of the objects they access. Also, a transaction either modifies the system state exactly as intended, or does not change it at all (with no possible side-effects resulting from "out-of-gas" exceptions, reentrancy issues, and so on). Finally, it seems easier to build fully stateless clients using one-time coins[@chepurnoy2018edrax] (although research in this area is still in the initial stage).
 
-One major criticism of one-time coins is that this model does not seem suitable for non-trivial decentralized applications. However, Ergo has overcome the problems and shown this assertion to be false by demonstrating many non-trivial prototype applications built on top of it (see Section~\ref{sec:contractual}).
+One major criticism of one-time coins is that this model does not seem suitable for non-trivial decentralized applications. However, Ergo has overcome the problems and shown this assertion to be false by demonstrating many non-trivial prototype applications built on top of it (see [Contractual Money](#contractual-money)).
 
 The Ergo protocol fixes the ledger snapshot representation in the form of boxes not destroyed by previous transactions. In detail, a miner should maintain a Merkle-tree-like authenticated data structure built on top of the UTXO set and must include a short digest (just 33 bytes) of this structure in each block header. This digest must be calculated *after* applying the block. This authenticated data structure is built on top of an AVL+ tree[@reyzin2017improving], which, like a regular hash tree, allows generating proofs of existence or non-existence of particular elements in the tree. Thus, users maintaining the full tree are capable of generating proofs that their boxes are unspent, and a small 33-byte digest is sufficient for verifying these proofs. However, unlike regular hash trees, an AVL+ tree also allows generation of proofs of tree modifications that allow verifiers to compute the new tree digest. Ergo miners are required to generate proofs of block modifications, and a hash of this proof is included into the block header along with the digest of the resulting state. Hence, light nodes that only maintain a small digest of the current state are able to verify a full block—they can check that all spent boxes were removed from the state, all created boxes were added to it, and no more changes were made.
 
@@ -150,7 +150,7 @@ Finally, proofs for multiple transactions in a single block are compressed toget
 ![Left: proof size per modification for 2000 transactions as a function of starting tree size $n$. Right: proof size per modification for a tree with $n = 1,000,000$ keys as a function of batch size $B$.](img/batching/proofSizeFromTreeSize.png)
 ![Batching: Proof size comparison](img/batching/proofSizeFromBatchSize2.png)
 
-Thus, Ergo state provides an efficient and secure way to prove existence or non-existence of certain elements in it, as well as proofs of tree modifications. These tree operations are supported by the Ergo smart contract language, thereby providing the ability to implement sophisticated contracts like those discussed in Section~\ref{sec:contractual}.
+Thus, Ergo state provides an efficient and secure way to prove existence or non-existence of certain elements in it, as well as proofs of tree modifications. These tree operations are supported by the Ergo smart contract language, thereby providing the ability to implement sophisticated contracts like those discussed in [Contractual Money](#contractual-money).
 
 ## Resiliency and Survivability
 

mkdocs.yml

@@ -146,7 +146,9 @@ nav:
       - Storage Rent: dev/protocol/storage-rent.md
       - Autolykos: dev/protocol/autolykos-protocol.md
 
-    - Research & Whitepapers: documents.md
+    - Research & Whitepapers: 
+      - documents.md
+      - Whitepaper I: doc/whitepaper.md
     - Roadmap:
       - roadmap.md
       - Scaling: