chore(docs): github actions, reorg, other nits (#16299)

Some bundled changes here, as discussed with @critesjosh 

- Docs deployment and previews are now done via Netlify. These versions
are cut by release-please so that doesn't change.
- Removed typedoc and the aztec-nr autogenerated docs. This means
reference won't show anymore until we find a better solution using the
upcoming aztec-nr documentation. As for typedoc, it's not very useful
and was wrong. Removing these deps makes the website smaller, faster,
and makes it not depend on any other builds, which allows it to be
deployed by Netlify.
- Moving and merging some pages to make navigation easier (please thank
Claude for de-duplicating TONS of info!)
- Some other little nits

Author: signorecello

.github/workflows/docs-preview.yml

@@ -50,12 +50,6 @@ jobs:
           git config --global user.name AztecBot
           git config --global user.email tech@aztecprotocol.com
 
-      - name: Build dependencies
-        run: |
-          for project in noir barretenberg l1-contracts yarn-project; do
-            CI=1 $project/bootstrap.sh
-          done
-
       - name: Query new version
         id: version
         run: |
@@ -88,7 +82,6 @@ jobs:
           git commit -m "chore(docs): cut new aztec docs version for tag ${{ steps.version.outputs.semver }}"
           git push
 
-
       - name: Cut Barretenberg Docs version
         working-directory: ./barretenberg/docs
         run: |

.github/workflows/release-please.yml

@@ -20,7 +20,7 @@ if semver check $REF_NAME; then
   export COMMIT_TAG=$REF_NAME
 fi
 
-function build_and_deploy {
+function build {
   if [ "${CI:-0}" -eq 1 ] && [ $(arch) == arm64 ]; then
     echo "Not building bb docs for arm64 in CI."
     return
@@ -31,19 +31,6 @@ function build_and_deploy {
     return
   fi
   denoise "yarn install && yarn build"
-
-  if [ "${CI:-0}" -eq 1 ] && [ "$(arch)" == "amd64" ]; then
-    if [ "$REF_NAME" == "next" ]; then
-      echo_header "deploying to production"
-      do_or_dryrun yarn netlify deploy --site barretenberg --prod
-    else
-      echo_header "deploying preview for branch: $REF_NAME"
-      do_or_dryrun yarn netlify deploy --site barretenberg
-    fi
-  else
-    echo "Skipping deployment - only deploy in CI on amd64."
-  fi
-
   cache_upload bb-docs-$hash.tar.gz build
 }
 
@@ -63,7 +50,7 @@ case "$cmd" in
     git clean -fdx
     ;;
   ""|"full"|"fast"|"ci")
-    build_and_deploy
+    build
     ;;
   "hash")
     echo "$hash"

barretenberg/docs/bootstrap.sh

@@ -437,7 +437,6 @@ case "$cmd" in
     release-image/bootstrap.sh push
     test
     release
-    docs/bootstrap.sh release-docs
     ;;
   "ci-release")
     export CI=1

bootstrap.sh

@@ -32,14 +32,6 @@ function build_docs {
   cache_upload docs-$hash.tar.gz build
 }
 
-function release_docs {
-  echo "deploying docs to prod"
-  yarn install
-  yarn build
-
-  yarn netlify deploy --site aztec-docs-dev --prod 2>&1
-}
-
 function test_cmds {
   if [ "${CI:-0}" -eq 1 ] && [ $(arch) == arm64 ]; then
     # Not running docs tests for arm64 in CI.
@@ -69,9 +61,6 @@ case "$cmd" in
   "hash")
     echo "$hash"
     ;;
-  "release-docs")
-    release_docs
-    ;;
   test|test_cmds)
     $cmd
     ;;

docs/bootstrap.sh

@@ -63,10 +63,10 @@ In routine nullifier insertions, a non membership check for a value is performed
 As it turns out, we can do better. [This paper](https://eprint.iacr.org/2021/1263.pdf) (page 6) introduces the idea of an indexed merkle tree. A Merkle Tree that allows us to perform efficient non-membership proofs. It achieves this by extending each node to include a specialized data structure. Each node not only stores some value $v \in \mathbb{F}_p$ but also some pointers to the leaf with the next higher value. The data structure is as follows:
 
 $$
-\textsf{leaf} = \{v, i_{\textsf{next}}, v_{\textsf{next}}\}.
+\textsf{leaf} = \{v, i_\textsf{next}, v_\textsf{next}\}.
 $$
 
-Based on the tree's insertion rules, we can assume that there are no leaves in the tree that exist between the range $(v, v_{\textsf{next}})$.
+Based on the tree's insertion rules, we can assume that there are no leaves in the tree that exist between the range $(v, v_\textsf{next})$.
 
 More simply put, the merkle tree pretty much becomes a linked list of increasing size, where once inserted the pointers at a leaf can change, but the nullifier value cannot.
 
@@ -79,45 +79,45 @@ The insertion protocol is described below:
 1. Look for a nullifier's corresponding low_nullifier where:
 
    $$
-   low\_nullifier_{\textsf{next\_value}} > new\_nullifier
+   low\_nullifier_\textsf{next\_value} > new\_nullifier
    $$
 
    > if $new\_nullifier$ is the largest use the leaf:
 
    $$
-   low\_nullifier_{\textsf{next\_value}} == 0
+   low\_nullifier_\textsf{next\_value} == 0
    $$
 
 2. Perform membership check of the low nullifier.
 3. Perform a range check on the low nullifier's value and next_value fields:
 
 $$
-new\_nullifier > low\_nullifier_{\textsf{value}} \: \&\&  \: ( new\_nullifier < low\_nullifier_{\textsf{next\_value}} \: || \:  low\_nullifier_{\textsf{next\_value}} == 0 )
+new\_nullifier > low\_nullifier_\textsf{value}} \: \&\&  \: ( new\_nullifier < low\_nullifier_\textsf{next\_value}} \: || \:  low\_nullifier_\textsf{next\_value}} == 0 )
 $$
 
 4. Update the low nullifier pointers
 
    $$
-   low\_nullifier_{\textsf{next\_index}} = new\_insertion\_index
+   low\_nullifier_\textsf{next\_index}} = new\_insertion\_index
    $$
 
    $$
-   low\_nullifier_{\textsf{next\_value}} = new\_nullifier
+   low\_nullifier_\textsf{next\_value}} = new\_nullifier
    $$
 
 5. Perform insertion of new updated low nullifier (yields new root)
 6. Update pointers on new leaf. Note: low_nullifier is from before update in step 4
 
 $$
-new\_nullifier\_leaf_{\textsf{value}} = new\_nullifier
+new\_nullifier\_leaf_\textsf{value}} = new\_nullifier
 $$
 
 $$
-new\_nullifier\_leaf_{\textsf{next\_value}} = low\_nullifier_{\textsf{next\_value}}
+new\_nullifier\_leaf_\textsf{next\_value}} = low\_nullifier_\textsf{next\_value}}
 $$
 
 $$
-new\_nullifier\_leaf_{\textsf{next\_index}} = low\_nullifier_{\textsf{next\_index}}
+new\_nullifier\_leaf_\textsf{next\_index}} = low\_nullifier_\textsf{next\_index}}
 $$
 
 7. Perform insertion of new leaf (yields new root)
@@ -130,7 +130,7 @@ $$
 - A handful of equality constraints.
 
 **Special cases**
-You'll notice at step 3 the $low\_nullifier_{\textsf{next\_value}}$ can be 0. This is a special case as if a value is the max, it will not point to anything larger (as it does not exist). Instead it points to zero. By doing so we close the loop, so we are always inserting into a ring, if we could insert outside the ring we could cause a split.
+You'll notice at step 3 the $low\_nullifier_\textsf{next\_value}}$ can be 0. This is a special case as if a value is the max, it will not point to anything larger (as it does not exist). Instead it points to zero. By doing so we close the loop, so we are always inserting into a ring, if we could insert outside the ring we could cause a split.
 
 A visual aid for insertion is presented below:
 
@@ -175,12 +175,12 @@ Suppose we want to show that the value `20` doesn't exist in the tree. We just r
 - hash the low nullifier: $low\_nullifier = h(10, 1, 30)$.
 - Prove the low leaf exists in the tree: `n` hashes.
 - Check the new value 'would have' belonged in the range given by the low leaf: `2` range checks.
-  - If ($low\_nullifier_{\textsf{next\_index}} == 0$):
+  - If ($low\_nullifier_\textsf{next\_index}} == 0$):
     - Special case, the low leaf is at the very end, so the new_value must be higher than all values in the tree:
-    - $assert(low\_nullifier_{\textsf{value}} < new\_value_{\textsf{value}})$
+    - $assert(low\_nullifier_\textsf{value}} < new\_value_\textsf{value}})$
   - Else:
-    - $assert(low\_nullifier_{\textsf{value}} < new\_value_{\textsf{value}})$
-    - $assert(low\_nullifier_{\textsf{next\_value}} > new\_value_{\textsf{value}})$
+    - $assert(low\_nullifier_\textsf{value}} < new\_value_\textsf{value}})$
+    - $assert(low\_nullifier_\textsf{next\_value}} > new\_value_\textsf{value}})$
 
 This is already a massive performance improvement, however we can go further, as this tree is not sparse. We can perform batch insertions.
 

docs/docs/aztec/concepts/advanced/storage/indexed_merkle_tree.mdx

@@ -97,15 +97,15 @@ And we can't use the normal flow to create a transaction fee refund note for Ali
 So we define a new type of note with its `compute_partial_commitment` defined as:
 
 $$
-\text{amount}*G_{amount} + \text{address}*G_{address} + \text{randomness}*G_{randomness} + \text{slot}*G_{slot}
+\text{amount} \cdot G_\text{amount} + \text{address} \cdot G_\text{address} + \text{randomness} \cdot G_\text{randomness} + \text{slot} \cdot G_\text{slot}
 $$
 
 Suppose Alice is willing to pay up to a set amount in stablecoins for her transaction. (Note, this amount gets passed into public so that when `transaction_fee` is known the FPC can verify that it isn't losing money. Wallets are expected to choose common values here, e.g. powers of 10).
 
 Then we can subtract the set amount from Alice's balance of private stablecoins, and create a point in private like:
 
 $$
-P_a' := \text{alice address}*G_{address} + \text{rand}_a*G_{randomness} + \text{Alice note slot}*G_{slot}
+P_a' := \text{alice address} \cdot G_\text{address} + \text{rand}_a \cdot G_\text{randomness} + \text{Alice note slot} \cdot G_\text{slot}
 $$
 
 We also need to create a point for the owner of the FPC (whom we call Bob) to receive the transaction fee, which will also need randomness.
@@ -117,7 +117,7 @@ We need to use different randomness for Bob's note here to avoid potential priva
 :::
 
 $$
-P_b' := \text{bob address}*G_{address} + \text{rand}_b*G_{randomness} + \text{Bob note slot}*G_{slot}
+P_b' := \text{bob address} \cdot G_\text{address} + \text{rand}_b \cdot G_\text{randomness} + \text{Bob note slot} \cdot G_\text{slot}
 $$
 
 Here, the $P'$s "partially encode" the notes that we are _going to create_ for Alice and Bob. So we can use points as "Partial Notes".
@@ -127,11 +127,11 @@ We pass these points and the funded amount to public, and at the end of public e
 Then, we arrive at the point that corresponds to the complete note by
 
 $$
-P_a := P_a'+P_{refund} = (\text{funded amount} - \text{transaction fee})*G_{amount} + \text{alice address}*G_{address} +\text{rand}_a*G_{randomness} + \text{Alice note slot}*G_{slot}
+P_a := P_a'+P_\text{refund} = (\text{funded amount} - \text{transaction fee}) \cdot G_\text{amount} + \text{alice address} \cdot G_\text{address} + \text{rand}_a \cdot G_\text{randomness} + \text{Alice note slot} \cdot G_\text{slot}
 $$
 
 $$
-P_b := P_b'+P_{fee} = (\text{transaction fee})*G_{amount} + \text{bob address}*G_{address} +\text{rand}_b*G_{randomness} + \text{Bob note slot}*G_{slot}
+P_b := P_b'+P_\text{fee} = (\text{transaction fee}) \cdot G_\text{amount} + \text{bob address} \cdot G_\text{address} + \text{rand}_b \cdot G_\text{randomness} + \text{Bob note slot} \cdot G_\text{slot}
 $$
 
 Then we just emit `P_a.x` and `P_b.x` as a note hashes, and we're done!

docs/docs/aztec/concepts/advanced/storage/partial_notes.md

@@ -104,5 +104,5 @@ Oracles are pieces of data that are injected into a smart contract function from
 
 To learn how to develop on top of the PXE, refer to these guides:
 
-- [Run more than one PXE on your local machine](../../../developers/guides/local_env/run_more_than_one_pxe_sandbox.md)
+- [Run more than one PXE on your local machine](../../../developers/guides/local_env/sandbox.md#running-multiple-pxes-in-the-sandbox)
 - [Use in-built oracles including oracles for arbitrary data](../../../developers/guides/smart_contracts/writing_contracts/how_to_use_capsules.md)

docs/docs/aztec/concepts/pxe/index.md

@@ -24,7 +24,7 @@ Oracles introduce **non-determinism** into a circuit, and thus are `unconstraine
 
 ## Inbuilt oracles
 
-- [`debug_log`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/oracle/debug_log.nr) - Provides a couple of debug functions that can be used to log information to the console. Read more about debugging [here](../../../developers/reference/debugging/index.md).
+- [`debug_log`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/oracle/debug_log.nr) - Provides a couple of debug functions that can be used to log information to the console. Read more about debugging [here](../../../developers/guides/local_env/how_to_debug.md).
 - [`auth_witness`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/authwit/src/auth_witness.nr) - Provides a way to fetch the authentication witness for a given address. This is useful when building account contracts to support approve-like functionality.
 - [`get_l1_to_l2_message`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/oracle/get_l1_to_l2_message.nr) - Useful for application that receive messages from L1 to be consumed on L2, such as token bridges or other cross-chain applications.
 - [`notes`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/oracle/notes.nr) - Provides a lot of functions related to notes, such as fetches notes from storage etc, used behind the scenes for value notes and other pre-build note implementations.