fix: Add redirects from old docs site urls to new site urls (#2429)

Some of the url paths for the old site don't resolve in the new site.
This makes sure that those paths are redirected to existing pages.

# Checklist:
Remove the checklist to signal you've completed it. Enable auto-merge if
the PR is ready to merge.
- [ ] If the pull request requires a cryptography review (e.g.
cryptographic algorithm implementations) I have added the 'crypto' tag.
- [x] I have reviewed my diff in github, line by line and removed
unexpected formatting changes, testing logs, or commented-out code.
- [x] Every change is related to the PR description.
- [ ] I have
[linked](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)
this pull request to relevant issues (if any exist).

docs/docs/about_aztec/roadmap/features_initial_ldt.md

@@ -85,7 +85,3 @@ A bundle of packages which emulate the actions of all eventual Aztec network par
 - World state DB
   - Reconstructs the Aztec Network's various trees.
   - Allows tree state to be queried.
-
-## Participate
-
-Keep up with the latest discussion and join the conversation in the [Aztec forum](https://discourse.aztec.network).

docs/docs/concepts/advanced/contract_creation.md

@@ -325,6 +325,6 @@ As an extension of this example, the deployer might wish bake-into the private c
 
 Adds initial public state variables to the public data tree.
 
-## Participate
+## Further reading
 
-Keep up with the latest discussion and join the conversation in the [Aztec forum](https://discourse.aztec.network).
+To see how to deploy a contract in practice, check out the [dapp development tutorial](../../dev_docs/dapps/tutorials/main.md).

docs/docs/concepts/advanced/data_structures/indexed_merkle_tree.md

@@ -3,7 +3,7 @@ title: Indexed Merkle Tree
 ---
 
 import Image from "@theme/IdealImage";
-import Disclaimer from "../../../misc/common/_disclaimer.mdx";
+import Disclaimer from "../../../misc/common/\_disclaimer.mdx";
 
 <Disclaimer />
 
@@ -51,39 +51,46 @@ _For the remainder of this article I will refer to the node that provides the no
 
 The insertion protocol is described below:
 
-1. Look for a nullifier's corresponding low_nullifier where: 
-$$  
-low\_nullifier_{\textsf{next\_value}} > v
-$$
-> if $new\_nullifier$ is the largest use the leaf:
-$$
-low\_nullifier_{\textsf{next\_value}} == 0
-$$
+1. Look for a nullifier's corresponding low_nullifier where:
+
+   $$
+   low\_nullifier_{\textsf{next\_value}} > v
+   $$
+
+   > if $new\_nullifier$ is the largest use the leaf:
+
+   $$
+   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:   
+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 )
 $$
 
-4. Update the low nullifier pointers  
-$$
-low\_nullifier_{\textsf{next\_index}} = new\_insertion\_index
-$$
-$$
-low\_nullifier_{\textsf{next\_value}} = new\_nullifier
-$$
+4. Update the low nullifier pointers
+
+   $$
+   low\_nullifier_{\textsf{next\_index}} = new\_insertion\_index
+   $$
 
-5. Perform insertion of new updated low nullifier (yields new root)  
+   $$
+   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{next\_value}} = low\_nullifier_{\textsf{next\_value}}
 $$
+
 $$
 new\_nullifier\_leaf_{\textsf{next\_index}} = low\_nullifier_{\textsf{next\_index}}
 $$
@@ -112,7 +119,7 @@ A visual aid for insertion is presented below:
 
 3. Add a new value $v=10$
 
-<Image img={require("/img/indexed-merkle-tree/index-merkle-tree-3.png")} />  
+<Image img={require("/img/indexed-merkle-tree/index-merkle-tree-3.png")} />
 
 4. Add a new value $v=20$
 
@@ -157,6 +164,7 @@ First we will go over batch insertions in an append only merkle tree.
 In the following example we insert a subtree of size 4 into our tree at step 4. above. Our subtree is greyed out as it is "pending".
 
 **Legend**:
+
 - Green: New Inserted Value
 - Orange: Low Nullifier
 
@@ -358,7 +366,3 @@ Despite offering large performance improvements within the circuits, these come
 #### Closing Notes
 
 We have been working with these new trees in order to reduce the proving time for our rollups in Aztec, however we think EVERY protocol leveraging nullifier trees should know about these trees as their performance benefit is considerable.
-
-## Participate
-
-Keep up with the latest discussion and join the conversation in the [Aztec forum](https://discourse.aztec.network).

docs/docs/concepts/advanced/data_structures/trees.md

@@ -139,7 +139,3 @@ The contract tree contains information about every function of every contract de
 ## Trees of valid Kernel/Rollup circuit VKs
 
 Eventually, we'll have trees of VKs for various permutations of kernel/rollup circuits. Such permutations might be the number of public inputs, or the logic contained within the circuits.
-
-## Participate
-
-Keep up with the latest discussion and join the conversation in the [Aztec forum](https://discourse.aztec.network).

docs/docs/concepts/advanced/public_vm.md

@@ -322,7 +322,3 @@ In addition, we can perform checks on each opcode to validate conditions on sele
 No doubt many, but first one on my mind is:
 
 Q: Do we want to support JUMP/JUMPI instructions for public ACIR functions? Would be _very_ nice to have but creates discontinuity between public/private functions.
-
-## Participate
-
-Keep up with the latest discussion and join the conversation in the [Aztec forum](https://discourse.aztec.network).

docs/docs/concepts/foundation/communication/cross_chain_calls.md

@@ -4,11 +4,12 @@ title: L1 <--> L2 communication
 
 import Image from "@theme/IdealImage";
 
-import Disclaimer from "../../../misc/common/_disclaimer.mdx";
+import Disclaimer from "../../../misc/common/\_disclaimer.mdx";
 
 <Disclaimer />
 
 In the following section, we will look at cross-chain communication, mixing L1 and L2 for composability and profits.
+
 # Objective
 
 The goal is to set up a minimal-complexity mechanism, that will allow a base-layer (L1) and the Aztec Network (L2) to communicate arbitrary messages such that:
@@ -126,11 +127,11 @@ struct L2ToL1Msg {
 	bytes32: content,
 }
 ```
+
 :::info
-The `bytes32` elements for `content` and `secretHash` hold values that must fit in a field element (~ 254 bits). 
+The `bytes32` elements for `content` and `secretHash` hold values that must fit in a field element (~ 254 bits).
 :::
 
-
 :::info
 The nullifier computation should include the index of the message in the message tree to ensure that it is possible to send duplicate messages (e.g., 2 x deposit of 500 dai to the same account).
 
@@ -143,19 +144,19 @@ The following diagram shows the overall architecture, combining the earlier sect
 
 <Image img={require("/img/com-abs-7.png")} />
 
-
-
 ## Linking L1 and L2 contracts
-As mentioned earlier, there will be a link between L1 and L2 contracts (with the L1 part of the link being the portal contract), this link is created at "birth" when the contract leaf is inserted. However, the specific requirements of the link is not yet fully decided. And we will outline a few options below. 
 
-The reasoning behind having a link, comes from the difficulty of L2 access control (see "A note on L2 access control"). By having a link that only allows 1 contract (specified at deployment) to send messages to the L2 contract makes this issue "go away" from the application developers point of view as the message could only come from the specified contract. The complexity is moved to the protocol layer, that must now ensure that messages to the L2 contract are only sent from the specified L1 contract. 
+As mentioned earlier, there will be a link between L1 and L2 contracts (with the L1 part of the link being the portal contract), this link is created at "birth" when the contract leaf is inserted. However, the specific requirements of the link is not yet fully decided. And we will outline a few options below.
+
+The reasoning behind having a link, comes from the difficulty of L2 access control (see "A note on L2 access control"). By having a link that only allows 1 contract (specified at deployment) to send messages to the L2 contract makes this issue "go away" from the application developers point of view as the message could only come from the specified contract. The complexity is moved to the protocol layer, that must now ensure that messages to the L2 contract are only sent from the specified L1 contract.
 
 :::info
 The design space for linking L1 and L2 contracts is still open, and we are looking into making access control more efficient to use in the models.
 :::
 
 ### One L2 contract linking to one L1
-One option is to have a 1:1 link between L1 and L2 contracts. This would mean that the L2 contract would only be able to receive messages from the specified L1 contract but also that the L1 should only be able to send messages to the specified L2 contract. This model is very restrictive, but makes access control easy to handle (but with no freedom). 
+
+One option is to have a 1:1 link between L1 and L2 contracts. This would mean that the L2 contract would only be able to receive messages from the specified L1 contract but also that the L1 should only be able to send messages to the specified L2 contract. This model is very restrictive, but makes access control easy to handle (but with no freedom).
 
 It is possible to model many-to-many relationships through implementing "relays" and listing those. However, L2 contracts that want to use the relay would have to either use dynamic access control to ensure that messages are coming from the relayer and that they where indeed relayed from the correct L1 contract. Essentially back in a similar case to no links.
 
@@ -165,21 +166,16 @@ To enforce the restriction, the circuit must ensure that neither of the contract
 
 From the L2 contract receiving messages, this model is very similar to the 1:1, only one L1 contract could be the sender of messages so no extra work needed there. On the L1 side of things, as many L2 could be sending messages to the L1 contract, we need to be able to verify that the message is coming from the correct L2 contract. However, this can be done using easy access control in the form of storage variables on the L1 contract, moving the design-space back to something that closely resembles multi-contract systems on L1.
 
-When the L1 contract can itself handle where messages are coming from (it could before as well but useless as only 1 address could send), we don't need to worry about it being in only a single pair. The circuits can therefore simply insert the contract leafs without requiring it to ensure that neither have been used before. 
+When the L1 contract can itself handle where messages are coming from (it could before as well but useless as only 1 address could send), we don't need to worry about it being in only a single pair. The circuits can therefore simply insert the contract leafs without requiring it to ensure that neither have been used before.
 
 With many L2's reading from the same L1, we can also more easily setup generic bridges (with many assets) living in a single L1 contract but minting multiple L2 assets, as the L1 contract can handle the access control and the L2's simply point to it as the portal. This reduces complexity of the L2 contracts as all access control is handled by the L1 contract.
 
-
-
 ## Open Questions
-- Can we handle L2 access control without public function calls? 
-  - Essentially, can we have "private shared state" that is updated very sparingly but where we accept the race-conditions as they are desired in specific instances. 
+
+- Can we handle L2 access control without public function calls?
+  - Essentially, can we have "private shared state" that is updated very sparingly but where we accept the race-conditions as they are desired in specific instances.
 - What is the best way to handle "linking", with efficient access control, could use this directly.
-- What is the best way to handle messages in a multi-rollup system? E.g., rollup upgrade is rejected by some part of users that use the old rollup. 
+- What is the best way to handle messages in a multi-rollup system? E.g., rollup upgrade is rejected by some part of users that use the old rollup.
   - What happens to pending messages (sent on old system then upgrade)?
   - Should both versions push messages into same message boxes?
-  - How should users or developers signal what versions their contracts respects as the "current" version? 
-
-## Participate
-
-Keep up with the latest discussion and join the conversation in the [Aztec forum](https://discourse.aztec.network).
+  - How should users or developers signal what versions their contracts respects as the "current" version?

docs/docs/concepts/foundation/communication/public_private_calls.md

@@ -71,15 +71,13 @@ Theoretically the builder has all the state trees after the public function has
 
 From the above, we should have a decent idea about what private and public functions can do inside the L2, and how they might interact.
 
-
-
 ## A note on L2 access control
 
 Many applications rely on some form of access control to function well. USDC have a blacklist, where only parties not on the list should be able to transfer. And other systems such as Aave have limits such that only the pool contract is able to mint debt tokens and transfers held funds.
 
 Access control like this cannot easily be enforced in the private domain, as reading is also nullifying(to ensure data is up to date). However, as it is possible to read historic public state, one can combine private and public functions to get the desired effect.
 
-Say the public state holds a `mapping(address user => bool blacklisted)` and a value with the block number of the last update `last_updated`. The private functions can then use this public blacklist IF it also performs a public function call that reverts if the block number of the historic state is older than the `last_updated`. This means that updating the blacklist would make pending transactions fail, but allow a public blacklist to be used. Similar would work for the Aave example, where it is just a public value with the allowed caller contracts. Example of how this would be written is seen below. Note that because the `onlyFresh` is done in public, the user might not know when he is generating his proof whether it will be valid or not. 
+Say the public state holds a `mapping(address user => bool blacklisted)` and a value with the block number of the last update `last_updated`. The private functions can then use this public blacklist IF it also performs a public function call that reverts if the block number of the historic state is older than the `last_updated`. This means that updating the blacklist would make pending transactions fail, but allow a public blacklist to be used. Similar would work for the Aave example, where it is just a public value with the allowed caller contracts. Example of how this would be written is seen below. Note that because the `onlyFresh` is done in public, the user might not know when he is generating his proof whether it will be valid or not.
 
 ```solidity
 function transfer(
@@ -100,8 +98,3 @@ function onlyFresh(pub uint256 blockNumber) public {
 :::info
 This is not a perfect solution, as any functions using access control might end up doing a lot of public calls it could put a significant burden on sequencers and greatly increase the cost of the transaction for the user. We are investigating ways to improve.
 :::
-
-
-## Participate
-
-Keep up with the latest discussion and join the conversation in the [Aztec forum](https://discourse.aztec.network).

docs/docs/concepts/foundation/contracts.md

@@ -34,3 +34,7 @@ The only information leaked about the transaction is:
 2. The set of public calls generated
 
 The addresses of all private calls are hidden from observers.
+
+## Further reading
+
+Read more about writing Aztec contracts [here](../../dev_docs/contracts/main.md).

docs/docs/concepts/foundation/state_model.md

@@ -37,3 +37,7 @@ This is achieved with two main features:
 - Custom nullifiers
 - Emission of custom note data to L1
 - Decrypting and storing encrypted note data
+
+## Further reading
+
+Read more about how to leverage the Aztec state model in Aztec contracts [here](../../dev_docs/contracts/syntax/state_variables.md).

docs/docs/concepts/foundation/transactions.md

@@ -9,3 +9,5 @@ import Disclaimer from '../../misc/common/\_disclaimer.mdx';
 See [here](https://miro.com/app/board/uXjVMQbDwNk=/?share_link_id=47681418582) for a gigantic diagram (readonly) showing the flow from user to L2, to L1, back to user.
 
 > Note: the protocol and its implementation are rapidly evolving, so some info in this diagram will be out of date.
+
+See the page on [contract communication](./communication/main.md) for more context on transactions execute.

docs/docs/intro.md

@@ -65,3 +65,7 @@ Aztec is a hybrid private/public rollup.
 Aztec is a network.
 
 Still confused? Explore these docs!
+
+## Participate
+
+We are building the Aztec network in public. Keep up with the latest discussion and join the conversation in the [Aztec forum](https://discourse.aztec.network) and check out our code on [Github](https://github.com/AztecProtocol).

docs/docs/misc/glossary.md

@@ -1,23 +1,24 @@
 ---
 title: Glossary
 ---
+
 ### Smart Contracts
 
-Programs that run on the Aztec network are called smart contracts, similar to [programs](https://ethereum.org/en/developers/docs/smart-contracts/) that run on Ethereum. 
+Programs that run on the Aztec network are called smart contracts, similar to [programs](https://ethereum.org/en/developers/docs/smart-contracts/) that run on Ethereum.
 
 However, these will be written in the [Noir](https://noir-lang.org/index.html) programming language, and may optionally include [private state and private functions](https://docs.aztec.network/aztec/how-it-works/private-smart-contracts).
 
 ### Barretenberg
 
 Aztec's cryptography back-end. Refer to the graphic at the top of [this page](https://medium.com/aztec-protocol/explaining-the-network-in-aztec-network-166862b3ef7d) to see how it fits in the Aztec architecture.
 
-Barretenberg's source code can be found [here](https://github.com/AztecProtocol/barretenberg). 
+Barretenberg's source code can be found [here](https://github.com/AztecProtocol/barretenberg).
 
 ### Sequencer
 
 Aztec will be launched with a fully permissionless sequencer network that anyone can participate in.
 
-How this works is being discussed actively in the [Discourse forum](https://discourse.aztec.network/t/request-for-proposals-decentralized-sequencer-selection/350/). Once this discussion process is completed, we will update the glossary and documentation with specifications and instructions for how to run. 
+How this works is being discussed actively in the [Discourse forum](https://discourse.aztec.network/t/request-for-proposals-decentralized-sequencer-selection/350/). Once this discussion process is completed, we will update the glossary and documentation with specifications and instructions for how to run.
 
 Sequencers are generally responsible for:
 
@@ -34,6 +35,7 @@ Sequencers are generally responsible for:
 Previously in [Aztec Connect](https://medium.com/aztec-protocol/sunsetting-aztec-connect-a786edce5cae) there was a single sequencer, and you can find the Typescript reference implementation called Falafel [here](https://github.com/AztecProtocol/aztec-connect/tree/master/falafel).
 
 ### Provers
+
 Aztec will be launched with a fully permissionless proving network that anyone can participate in.
 
-How this works will be discussed via a future RFP process on Discourse, similarly to the Sequencer RFP. 
+How this works will be discussed via a future RFP process on Discourse, similarly to the Sequencer RFP.