chore: redo typo PR by gasaicrypto

docs/docs/aztec/concepts/storage/notes.md

@@ -36,7 +36,7 @@ In some cases, if you know the recipient off-chain, you might choose to share th
 
 If you create a note for yourself, you don’t need to broadcast it to the network or share anything. You will only need to keep the note somewhere, such as in your PXE, so you can prove ownership and spend it in future transactions.
 
-## Abstracting notes from from apps & users
+## Abstracting notes from apps & users
 
 When using the Aztec protocol, users may not be aware of the specific notes that they own. Their experience should be similar to Ethereum, and should instead see the amount of their assets inside their account.
 

docs/docs/aztec/smart_contracts/contract_structure.md

@@ -3,7 +3,7 @@ title: Contract Structure
 tags: [contracts]
 ---
 
-A contract is a collection of persistent state varibles and [functions](./functions/index.md) which may manipulate these variables. Functions and state variables within a contract's scope are said to belong to that contract. A contract can only access and modify its own state. If a contract wishes to access or modify another contract's state, it must make a call to an external function of the other contract. For anything to happen on the Aztec network, an external function of a contract needs to be called.
+A contract is a collection of persistent state variables and [functions](./functions/index.md) which may manipulate these variables. Functions and state variables within a contract's scope are said to belong to that contract. A contract can only access and modify its own state. If a contract wishes to access or modify another contract's state, it must make a call to an external function of the other contract. For anything to happen on the Aztec network, an external function of a contract needs to be called.
 
 ## Contract
 

docs/docs/protocol-specs/addresses-and-keys/example-usage/tag-sequence-derivation.md

@@ -21,7 +21,7 @@ Having derived a Shared Secret, Bob can now share it with Alice as follows:
 $\Taghs$ | $\esk_{hs} \cdot \Tpkm$ | Handshake message identification tag | Note: the tagging public key $\Tpkm$ exists as an optimization, seeking to make brute-force message identification as fast as possible. In many cases, handshakes can be performed offchain via traditional web2 means, but in the case of on-chain handshakes, we have no preferred alternative over simply brute-force attempting to reconcile every 'Handshake message identification tag'. Note: this optimization reduces the recipient's work by 1 cpu-friendly hash per message (at the cost of 255-bits to broadcast a compressed encoding of $\Taghs$). We'll need to decide whether this is the right speed/communication trade-off. | 
 $\payload$ | [$\Taghs$, $\Epk_{hs}$] | Payload | This can be broadcast via L1.<br />Curve points can be compressed in the payload. |
 
-Alice can identify she is the indended the handshake recipient as follows:
+Alice can identify she is the intended the handshake recipient as follows:
 
 <!-- prettier-ignore -->
 | Thing | Derivation | Name | Comments |

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

@@ -521,7 +521,7 @@ TransientAccumulatedData --* PublicInputs: transient_accumulated_data
 
 %% You'll also need to modify the PrivateInputs class (way above) to include an extra item: `previous_kernel: PreviousKernel`
 
-PrivateInputs *.. PreviousKernel: previous_kernel
+PrivateInputs *-- PreviousKernel: previous_kernel
 
 class PreviousKernel {
   public_inputs: PrivateKernelPublicInputs

docs/docs/protocol-specs/contract-deployment/classes.md

@@ -352,7 +352,7 @@ The `register`, `broadcast_unconstrained_function`, and `broadcast_private_funct
 
 To encode the bytecode into a fixed-length array of Fields, the bytecode is first split into 31-byte chunks, and each chunk interpreted big-endian as a field element. The total length in bytes is then prepended as an initial element, and then right-padded with zeroes.
 
-The log itself is prepended by the address of the contract that emitted it. This is not stictly necessary because the only contract able to broadcast contract class logs is the `ContractClassRegisterer` (this is enforced in the kernel circuits), but exists to easily check and manage logs of published blocks.
+The log itself is prepended by the address of the contract that emitted it. This is not strictly necessary because the only contract able to broadcast contract class logs is the `ContractClassRegisterer` (this is enforced in the kernel circuits), but exists to easily check and manage logs of published blocks.
 
 ```
 chunks = chunk bytecode into 31 bytes elements, last element right-padded with zeroes

docs/docs/protocol-specs/cryptography/proving-system/overview.md

@@ -34,7 +34,7 @@ IVC schemes are used by Aztec in two capacities:
 
 Both use IVC schemes. Client-side, each function call in a transaction is a "step" in the IVC scheme. Rollup-side, aggregating two transaction proofs is a "step" in the IVC scheme.
 
-The client-side IVC scheme is substantially more complex than the rollup-side scheme due to performance requiremenmts.
+The client-side IVC scheme is substantially more complex than the rollup-side scheme due to performance requirements.
 
 Rollup-side, each "step" in the IVC scheme is a Honk proof, which are recursively verified. As a result, no protoocols other than Honk are required to execute rollup-side IVC.
 
@@ -50,7 +50,7 @@ The main two families of folding schemes are derived from the [Nova](https://epr
 
 ## Protogalaxy
 
-The [Protogalaxy](https://eprint.iacr.org/2023/1106) protocol efficiently supports the ability to fold multiple Honk instances (describing different circuits) into the same accumulator. To constrast, the Nova/Supernova/Hypernova family of folding schemes assume that a single circuit is being repeatedly folded (each Aztec function circuit is a distinct circuit, which breaks this assumption).
+The [Protogalaxy](https://eprint.iacr.org/2023/1106) protocol efficiently supports the ability to fold multiple Honk instances (describing different circuits) into the same accumulator. To contrast, the Nova/Supernova/Hypernova family of folding schemes assume that a single circuit is being repeatedly folded (each Aztec function circuit is a distinct circuit, which breaks this assumption).
 
 It is a variant of [Protostar](https://eprint.iacr.org/2023/620). Unlike Protostar, Protogalaxy enables multiple instances to be efficiently folded into the same accumulator instance.
 

docs/docs/protocol-specs/cryptography/proving-system/performance-targets.md

@@ -120,7 +120,7 @@ If we reserve 10% of the block production time for verifying user proofs, at 10
 
 If the block producer has access to more than one physical machine that they can use to parallelise verification, we can extend the maximum tolerable verification time. For an MVP that requires 20ms to verify each proof, each block producer would require at least 2 physical machines to successfully build blocks.
 
-100tps with one physical machine would require a verifiation time of 1ms per proof.
+100tps with one physical machine would require a verification time of 1ms per proof.
 
 ### Memory consumption
 
@@ -141,7 +141,7 @@ An Ethereum block consists of approximately 1,000 transactions, with a block gas
 As a conservative estimate, let us assume that every tx in a block will consume 10,000 AVM steps.
 
 Our AVM model is currently to evaluate a transaction's public function calls within a single AVM circuit.
-This means that a block of `n` transactions will require `n` pulic kernel proofs and `n` AVM proofs to be generated (assuming all txns have a public component).
+This means that a block of `n` transactions will require `n` public kernel proofs and `n` AVM proofs to be generated (assuming all txns have a public component).
 
 If public VM proof construction consumes 20% of block time, we must generate 10 AVM proofs and 10 public kernel proofs in 2 seconds.
 
@@ -163,7 +163,7 @@ For a rollup block containing $2^d$ transactions, we need to compute 2-to-1 roll
 
 Note: this excludes network coordination costs, latency costs, block construction costs, public VM proof construction costs (must be computed before the 2-to-1 rollup proofs), cost to compute the final UltraPlonk proof.
 
-To accomodate the above costs, we assume that we can budget 40% of block production time towards making proofs. Given these constraints, the following table describes maximum allowable proof construction times for a selection of block sizes.
+To accommodate the above costs, we assume that we can budget 40% of block production time towards making proofs. Given these constraints, the following table describes maximum allowable proof construction times for a selection of block sizes.
 
 | block size | number of successive 2-to-1 rollup proofs | number of parallel Prover machines required for base layer proofs | time required to construct a rollup proof |
 | --- | --- | --- | --- |

docs/versioned_docs/version-v0.82.3/run_node/concepts/deployments/what_is_deployment.md

@@ -205,7 +205,7 @@ This contract is the “assembly of Aztec citizensˮ that is the final arbiter o
 
 This contract decides what is the canonical instance which gets block rewards.
 
-The Proposals contract tables proposals for voting, Holders who lock their Hypothetical Assets with the Governance contract may vote once for each Hypothetical Asset locked. They can vote either Yea or Nea.
+The Proposals contract tables proposals for voting, Holders who lock their Hypothetical Assets with the Governance contract may vote once for each Hypothetical Asset locked. They can vote either Yea or Nay.
 
 Once a proposal garners the minimum number of votes, and the Yay votes exceed Nay by at least the `quorum%` , the proposal can be executed by the Governance contract.
 

docs/versioned_docs/version-v0.82.3/run_node/guides/run_nodes/how_to_run_sequencer_draft.md

@@ -49,12 +49,12 @@ You can use `npx aztec-spartan [start/stop/logs/update]` to start, stop, output
 :::note
 The above deploy script will connect your node to the p2p network where it will register peers and start receiving messages from other nodes on the network. You will not be in the validator set just yet.
 
-Once you connect and begin to see gossiped messages such as attestations, proposals etc notify notify a team member and they will add you to the validator set.
+Once you connect and begin to see gossiped messages such as attestations, proposals etc notify a team member and they will add you to the validator set.
 :::
 
 ## Node Configuration
 
-The `aztec-spartan.sh` script will set the following required variables on your behalf. You can ofcourse override the variables set by the script by simply changing the `.env` file directly and re-running `./aztec-spartan.sh`
+The `aztec-spartan.sh` script will set the following required variables on your behalf. You can of course override the variables set by the script by simply changing the `.env` file directly and re-running `./aztec-spartan.sh`
 
 | Variable       | Description                                                                                                                            |
 | -------------- | -------------------------------------------------------------------------------------------------------------------------------------- |