From 0d1b722ef7fdc501ca78cfca8f46009a29504c8f Mon Sep 17 00:00:00 2001 From: Aztec Bot <49558828+AztecBot@users.noreply.github.com> Date: Tue, 3 Dec 2024 06:37:48 -0500 Subject: [PATCH] chore: redo typo PR by leopardracer (#10363) Thanks leopardracer for https://github.com/AztecProtocol/aztec-packages/pull/9697. Our policy is to redo typo changes to dissuade metric farming. This is an automated script. --- barretenberg/cpp/docs/Fuzzing.md | 2 +- docs/docs/protocol-specs/state/index.md | 4 ++-- docs/docs/vision.mdx | 6 +++--- docs/internal_notes/api.md | 2 +- noir/noir-repo/tooling/readme.md | 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/barretenberg/cpp/docs/Fuzzing.md b/barretenberg/cpp/docs/Fuzzing.md index c413ba3ddfb..3acfbc4fa72 100644 --- a/barretenberg/cpp/docs/Fuzzing.md +++ b/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 diff --git a/docs/docs/protocol-specs/state/index.md b/docs/docs/protocol-specs/state/index.md index ed7b34837c8..4dd342cfb80 100644 --- a/docs/docs/protocol-specs/state/index.md +++ b/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). diff --git a/docs/docs/vision.mdx b/docs/docs/vision.mdx index a7e748579fa..855805e9e01 100644 --- a/docs/docs/vision.mdx +++ b/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. diff --git a/docs/internal_notes/api.md b/docs/internal_notes/api.md index d6c4767c0b6..d29e496d614 100644 --- a/docs/internal_notes/api.md +++ b/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 diff --git a/noir/noir-repo/tooling/readme.md b/noir/noir-repo/tooling/readme.md index 20d1b560b5b..3172062241a 100644 --- a/noir/noir-repo/tooling/readme.md +++ b/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