chore: redo typo PR by leopardracer (#10363)

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

barretenberg/cpp/docs/Fuzzing.md

@@ -2,7 +2,7 @@
 
 ## Intro
 
-We are gradually introducing fuzzing of various primitives into barretenberg, focusing first and foremost on in-cicruit types. If you are developing / patching a primitive and there is a fuzzer available for it, please take the time to update the fuzzer (if you've added new functionality) and run it for at least a few hours to increase security.
+We are gradually introducing fuzzing of various primitives into barretenberg, focusing first and foremost on in-circuit types. If you are developing / patching a primitive and there is a fuzzer available for it, please take the time to update the fuzzer (if you've added new functionality) and run it for at least a few hours to increase security.
 
 ## Build
 

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

@@ -37,7 +37,7 @@ However, there are nuances to this approach!
 One important aspect to consider is _when_ state can be accessed.
 In most blockchains, state is always accessed at the head of the chain and changes are only made by the sequencer as new blocks are added.
 
-However, since private execution relies on proofs generated by the user, this would be very impractical - one users transaction could invalidate everyone elses.
+However, since private execution relies on proofs generated by the user, this would be very impractical - one user's transaction could invalidate everyone else's.
 
 While proving inclusion in the data tree can be done using historical state, the non-membership proof in the nullifier tree cannot.
 
@@ -71,7 +71,7 @@ The verification keys of the core protocol circuits are technically (constant) s
 Is there any other state on L1 that we're forgetting about? The vk of the squisher circuit? The state hash? Message data?
 -->
 
-Below is a short description of the state catagories (trees) and why they have the type they have.
+Below is a short description of the state categories (trees) and why they have the type they have.
 
 - [**Note Hashes**](./note-hash-tree.md): A set of hashes (commitments) of the individual blobs of contract data (we call these blobs of data notes). New notes can be created and their hashes inserted through contract execution. We need to support efficient membership proofs as any read will require one to prove validity. The set is represented as an [Append-only Merkle tree](./tree-implementations.md#append-only-merkle-trees), storing the note hashes as leaves.
 - [**Nullifiers**](./nullifier-tree.md): A set of nullifiers for notes that have been spent. We need to support efficient non-membership proofs since we need to check that a note has not been spent before it can be used. The set is represented as an [Indexed Merkle tree](./tree-implementations.md#indexed-merkle-trees).

docs/docs/vision.mdx

@@ -12,9 +12,9 @@ These are our core values.
 
 ### Privacy
 
-The only true zero-knowledge rollup, built with a privacy-first UTXO architecture to allow developers to build privacy preserving programable applications.
+The only true zero-knowledge rollup, built with a privacy-first UTXO architecture to allow developers to build privacy preserving programmable applications.
 
-It refers to the ability of Aztec smart contract to have private (encrypted) state. Aztec abstracts away many of the complexities associated with managing private state, providing developers with an interface that feels familiar, but is much more powerful.
+It refers to the ability of Aztec smart contracts to have private (encrypted) state. Aztec abstracts away many of the complexities associated with managing private state, providing developers with an interface that feels familiar, but is much more powerful.
 
 Aztec provides a secure, private environment for the execution of sensitive operations, ensuring private information and decrypted data are not accessible to unauthorized applications.
 
@@ -28,7 +28,7 @@ Proving transaction validity via recursive aggregation of zero-knowledge proofs,
 
 We believe decentralization is premised on individual rights — without widely accessible encryption, we compromise our ability to choose how we live our lives and earn our livelihoods.
 
-Aztec is building a permissionless, censorship resistant, peer-to-peer network. It aims to be credibly neutral, where the same transparent rules apply to everyone, enforced by the protocol.
+Aztec is building a permissionless, censorship-resistant, peer-to-peer network. It aims to be credibly neutral, where the same transparent rules apply to everyone, enforced by the protocol.
 
 Aztec will have a network of sequencers that stake tokens to participate in the network. Sequencers are responsible for aggregating transactions into a block, generating proofs of the state updates (or delegating proof generation to the prover network) and posting it to the rollup contract on Ethereum, along with any required public data for data availability.
 

docs/internal_notes/api.md

@@ -4,6 +4,6 @@ title: API
 
 ## API Structure
 
-- Discuss PXE, it's purpose and what it's used for
+- Discuss PXE, its purpose and what it's used for
 - Discuss aztec.js and the generated typescript interfaces
 - Links to other pages within this api section

noir/noir-repo/tooling/readme.md

@@ -4,7 +4,7 @@ Below we briefly describe the purpose of each tool-related crate in this reposit
 
 ## nargo
 
-This is the default package manager used by Noir. One may draw similarities to Rusts' Cargo.
+This is the default package manager used by Noir. One may draw similarities to Rust's Cargo.
 
 ## nargo_fmt