chore: redo typo PR by socialsister (#5931)

Thanks socialsister for
#5892. Our policy is
to redo typo changes to dissuade metric farming. This is an automated
script.

Co-authored-by: AztecBot <tech@aztecprotocol.com>

docs/docs/developers/tutorials/token_portal/minting_on_aztec.md

@@ -24,7 +24,7 @@ The `claim_public` function enables anyone to consume the message on the user's
 **What’s happening here?**
 
 1. We first recompute the L1->L2 message content by calling `get_mint_public_content_hash()`. Note that the method does exactly the same as what the TokenPortal contract does in `depositToAztecPublic()` to create the content hash.
-2. We then attempt to consume the L1->L2 message by passing the `msg_key`, the the content hash, and the "secret". Since we are depositing to Aztec publicly, this secret is public, anyone can know this and is usually 0.
+2. We then attempt to consume the L1->L2 message by passing the `msg_key`, the content hash, and the "secret". Since we are depositing to Aztec publicly, this secret is public, anyone can know this and is usually 0.
    - `context.consume_l1_to_l2_message()` takes in the content_hash and secret to recreate the original message. The L1 to L2 message consists of:
      - Sender - who on L1 sent the message + chain ID of L1. The context variable knows the portal address on L1 and adds that
      - Recipient - i.e. this aztec contract address which is consuming the message + the current version of the aztec rollup.

docs/docs/developers/tutorials/token_portal/withdrawing_to_l1.md

@@ -48,7 +48,7 @@ Paste this in your `TokenPortal.sol`:
 }
 ```
 
-Here we reconstruct the L2 to L1 message and check that this message exists on the outbox. If so, we consume it and transfer the funds to the recipient. As part of the reconstruction, the content hash looks similar to what we did in our bridge contract on aztec where we pass the amount and recipient to the the hash. This way a malicious actor can’t change the recipient parameter to the address and withdraw funds to themselves.
+Here we reconstruct the L2 to L1 message and check that this message exists on the outbox. If so, we consume it and transfer the funds to the recipient. As part of the reconstruction, the content hash looks similar to what we did in our bridge contract on aztec where we pass the amount and recipient to the hash. This way a malicious actor can’t change the recipient parameter to the address and withdraw funds to themselves.
 
 We also use a `_withCaller` parameter to determine the appropriate party that can execute this function on behalf of the recipient. If `withCaller` is false, then anyone can call the method and hence we use address(0), otherwise only msg.sender should be able to execute. This address should match the `callerOnL1` address we passed in aztec when withdrawing from L2.
 

docs/docs/protocol-specs/bytecode/index.md

@@ -144,7 +144,7 @@ If the function is public, the entry will be its ABI. If the function is private
 | `width?` | `number` | The width of the integer in bits. Applies to integers only. |
 | `length?` | `number` | The length of the array or string. Applies to arrays and strings only. |
 | `type?` | [AbiType](#abi-type) | The types of the array elements. Applies to arrays only. |
-| `fields?` | [ABIVariable[]](#abi-variable) | The The fields of the struct. Applies to structs only. |
+| `fields?` | [ABIVariable[]](#abi-variable) | the fields of the struct. Applies to structs only. |
 
 ### Bytecode in the artifact
 

docs/docs/protocol-specs/circuits/private-function.md

@@ -16,7 +16,7 @@ The private inputs of a private function circuit are customizable.
 
 <!-- Mike review:
 - Elaborate on what the `counter`s are for (or link to a section which describes them).
-- It would be nice to explain what's inside a call_stack_item_hash, or to link to a definition of the the private_call_stack_item and public_call_stack_item structs.
+- It would be nice to explain what's inside a call_stack_item_hash, or to link to a definition of the private_call_stack_item and public_call_stack_item structs.
 - It seems the L1->L2 messages tree doesn't exist anymore (according to the `../state/*` section of this paper. Perhaps it's been absorbed into the note hashes tree?). Consider updating the structs accordingly. EDIT: it should still exist.
 - I think there's still some outstanding ugliness originating from the "where to read?" debate:
     - Read requests for notes are being output by private functions, but the `note_hash_tree_root` is also available - so which should be used by an app?

docs/docs/protocol-specs/circuits/private-kernel-initial.mdx

@@ -168,8 +168,8 @@ The circuit undergoes the following validations for data within [`private_inputs
        For each `note_hash` at index `i` in `note_hashes`:
 
        - Find the `request_index` at [`hints`](#hints).`note_hash_range_hints[i]`, which is the index of the `private_call_requests` with the smallest `counter_start` that was emitted after the `note_hash`.
-       - If `request_index` equals `NM`, indicating no request was emitted after the `note_hash`, its counter must be greater the the `counter_end` of the last request.
-       - If `request_index` equals `0`, indicating no request was emitted before the `note_hash`. Its counter must be less the the `counter_start` of the first request.
+       - If `request_index` equals `NM`, indicating no request was emitted after the `note_hash`, its counter must be greater the `counter_end` of the last request.
+       - If `request_index` equals `0`, indicating no request was emitted before the `note_hash`. Its counter must be less the `counter_start` of the first request.
        - Otherwise, the request was emitted after the `note_hash`, and its immediate previous request was emitted before the `note_hash`. Its counter must fall between those two requests.
 
        The code simplifies as:

docs/docs/protocol-specs/data-publication-and-availability/overview.md

@@ -76,7 +76,7 @@ Eventually consensus forms and blocks from the _dynamic_ chain gets included in
 Below image is from [Bridging and Finality: Ethereum](https://jumpcrypto.com/writing/bridging-and-finality-ethereum/).
 ![](https://jumpcrypto-com.ghost.io/content/images/2023/03/ZK-Bridging-4--1-.png)
 
-In rollup land, the _available_ chain will often live outside the host where it is built upon before blocks make their way onto the host DA and later get _finalized_ by the the validating light node that lives on the host as a smart contract.
+In rollup land, the _available_ chain will often live outside the host where it is built upon before blocks make their way onto the host DA and later get _finalized_ by the validating light node that lives on the host as a smart contract.
 
 > Depending on the rollup mechanism, rollup full nodes will be able to finalize their own view of the chain as soon as data is available on the host.
 

docs/docs/protocol-specs/rollup-circuits/tree-parity.md

@@ -95,7 +95,7 @@ class BaseParityInputs {
     msgs: List~Fr[2]~
 }
 ```
-The logic of the the circuits is quite simple - build both a SHA256 and a snark-friendly tree from the same inputs.
+The logic of the circuits is quite simple - build both a SHA256 and a snark-friendly tree from the same inputs.
 For optimization purposes, it can be useful to have the layers take more than 2 inputs to increase the task of every layer.
 If each just take 2 inputs, the overhead of recursing through the layers might be higher than the actual work done.
 Recall that all the inputs are already chosen by the L1, so we don't need to worry about which to chose.