Fix typos and improve clarity in documentation

README.md

@@ -30,7 +30,7 @@ If so, the owner of the issue will:
 
 4. **Get approval**:
    - When approvers are satisfied with the design, they will approve the PR on github.
-   - When all approvers have signed off, merge the PR with the design
+   - When all approvers have signed off, merge the PR with the design.
 
 5. **Implement the design** based on the finalized design document.
    - Any changes or decisions made during the implementation phase should be captured in user docs or protocol spec *and flagged in PRs*.

in-progress/0003-native-merkle-trees.md

@@ -12,21 +12,21 @@ This design attempts to solve the problem of slow sync and merkle tree insertion
 
 ## Introduction
 
-We require high performance merkle tree implementations both to ensure nodes can stay synched to the network and sequencers/provers can advance the state as required to build blocks. Our cuirrent TS implementations are limited in their single-threaded nature and the unavoidable constraint of have to repeatedly call into WASM to perform a hash operation.
+We require high performance merkle tree implementations both to ensure nodes can stay synced to the network and sequencers/provers can advance the state as required to build blocks. Our current TS implementations are limited in their single-threaded nature and the unavoidable constraint of have to repeatedly call into WASM to perform a hash operation.
 
 Some analysis of the quantity of hashing and the time required can be found [here](https://hackmd.io/@aztec-network/HyfTK9U5a?type=view).
 
 This design proposes the creation of a set of multi-threaded merkle tree implementations in C++ using LMDB. It builds upon some previous prototyping to develop concurrent indexed tree insertions.
 
 ## Implementation
 
-There are many parts to this design, we will walk through them individiually and discuss the choices made at each stage.
+There are many parts to this design, we will walk through them individually and discuss the choices made at each stage.
 
 ### Overall Architecture
 
-A new C++ binary, World State, will be created that will be started by the node software. It will be configured with the location in which Merkle Tree data should be stored. It will then accept and respond with msgpack-ed messages over one or more streams. The initial implementation will simply used stdio, but this will be absrtacted such that this could be replaced by other stream-based mechanisms.
+A new C++ binary, World State, will be created that will be started by the node software. It will be configured with the location in which Merkle Tree data should be stored. It will then accept and respond with msgpack-ed messages over one or more streams. The initial implementation will simply used stdio, but this will be abstracted such that this could be replaced by other stream-based mechanisms.
 
-To interface with the World State, an abstraction will be created at the `MerkleTreeDb` level. This accurately models the scope of functionality provided by the binary as owner of all the trees. It was considered that the abstraction could sit at the level of individual trees, but this creates difficulty whan we want to send an entire block to the World State to be inserted. This is an important use case as synching entire blocks is where signifcant performance optimisations can be made.
+To interface with the World State, an abstraction will be created at the `MerkleTreeDb` level. This accurately models the scope of functionality provided by the binary as owner of all the trees. It was considered that the abstraction could sit at the level of individual trees, but this creates difficulty when we want to send an entire block to the World State to be inserted. This is an important use case as synching entire blocks is where significant performance optimisations can be made.
 
 
 ``` TS
@@ -47,7 +47,7 @@ An abstract factory will then be created to construct the appropriate concrete t
 
 ### Interface
 
-The interface will be an asynchronous message based communication protocol. Each message is provided with meta data uniquely identiying it and is responded to inidividually. It is not necessary to wait for a response to a message before sending a subsequent message. A simple message specification will be created, some examples of which are shown here:
+The interface will be an asynchronous message based communication protocol. Each message is provided with meta data uniquely identifying it and is responded to individually. It is not necessary to wait for a response to a message before sending a subsequent message. A simple message specification will be created, some examples of which are shown here:
 
 ``` C++
 enum WorldStateMsgTypes {
@@ -144,7 +144,7 @@ As a sequencer/prover inserts transaction side-effects, the resulting new state
 
 #### Commits
 
-When a block settles, the node performs a commit. It verifies any uncommitted state it may have against that published on chain to determine if that state is canonical. If it is not, the `uncommitted` state is dicarded and the node perform an `Update` operation using the newly published side effects.
+When a block settles, the node performs a commit. It verifies any uncommitted state it may have against that published on chain to determine if that state is canonical. If it is not, the `uncommitted` state is discarded and the node perform an `Update` operation using the newly published side effects.
 
 Once the node has the correct `uncommitted` state, it commits that state to disk. This is the only time that a write transaction is required against the database.
 
@@ -163,7 +163,7 @@ Indexed Trees require significantly more hashing than append only trees. In fact
 For each leaf being inserted:
 
 1. Identify the location of the leaf whose value immediately precedes that being inserted.
-2. Retrieve the sibling path of the preceeding leaf before any modification.
+2. Retrieve the sibling path of the preceding leaf before any modification.
 3. Set the 'next' value and index to point to the leaf being inserted.
 4. Set the 'next' value and index of the leaf being inserted to the leaf previously pointed to by the leaf just updated.
 5. Re-hash the updated leaf and update the leaf with this hash, requiring the tree to be re-hashed up to the root.
@@ -209,4 +209,4 @@ As the World State is used heavily in all operations, we will gain confidence th
 
 ## Prototypes
 
-Areas of this work have been prototyped already. The latest being [here](https://github.com/AztecProtocol/aztec-packages/pull/7037).
+Areas of this work have been prototyped already. The latest being [here](https://github.com/AztecProtocol/aztec-packages/pull/7037).

in-progress/5040-native-merkle-trees-napi.md

@@ -11,7 +11,7 @@ This document proposes integrating the [Native Merkle Trees database](https://gi
 
 ## Introduction
 
-The original native Merkle tree spec proposed building a `MerkleTreesDb` native binary in C++. The TypScript code would use message passing over streams to communicate with the database. A long lived process would be started once and accept messages over an input stream (e.g. stdin or a socket), process the messages and return the result over another stream (e.g. stdout).
+The original native Merkle tree spec proposed building a `MerkleTreesDb` native binary in C++. The TypeScript code would use message passing over streams to communicate with the database. A long lived process would be started once and accept messages over an input stream (e.g. stdin or a socket), process the messages and return the result over another stream (e.g. stdout).
 
 [Node-API](https://nodejs.org/docs/latest-v18.x/api/n-api.html) is an API for building native addons that integrate seamlessly into NodeJS.
 
@@ -21,7 +21,7 @@ This approach would simplify deployment and maintenance (no new binaries need to
 
 A new module would be written in C++ that would adapt the existing Native Merkle Trees database to Node-API semantics. This module could sit alongside the stream-based message passing implementation detailed in the [original spec](https://github.com/AztecProtocol/engineering-designs/blob/f9d1a897303c1481c790cecc4616961e1c183622/in-progress/0003-native-merkle-trees.md#interface)
 
-This module would be build with CMake normally as the rest of the C++ code, with the exception that its build artifact would be a shared library (with a custom extension `.node` instead of `.so`). The TypeScript project would use [`bindings`](https://www.npmjs.com/package/bindings) to load the native module and re-export the functions and classes from C++.
+This module would be built with CMake normally as the rest of the C++ code, with the exception that its build artifact would be a shared library (with a custom extension `.node` instead of `.so`). The TypeScript project would use [`bindings`](https://www.npmjs.com/package/bindings) to load the native module and re-export the functions and classes from C++.
 
 > [!NOTE]
 > TypeScript definitions would have to be written from the C++ code. Ideally these would be generated from existing code, but if that doesn't work then they would have to be written and maintained manually.

in-progress/7025-instrumenting-the-node-with-open-telemetry.md

@@ -11,7 +11,7 @@ The node should emit useful stats about the way its running so that node operato
 
 ## Introduction
 
-In order to confidently deploy and maintain a node in production it needs to provide basic information about how it's operating. These metrics need to be emitted in portable manner so that monitoring tools can easily ingest them. These metrics should be optional such that running a node does not require running any other infrastructure to ingest the metrics.
+In order to confidently deploy and maintain a node in production it needs to provide basic information about how it's operating. These metrics need to be emitted in а portable manner so that monitoring tools can easily ingest them. These metrics should be optional such that running a node does not require running any other infrastructure to ingest the metrics.
 
 OpenTelemetry is a framework for capturing instrumentation data from applications and encoding them into a standard format that's vendor neutral. In the past we've used Prometheus and Grafana to capture metrics from services, OpenTelemetry would enable us to continue running that stack while also giving the community the chance to ingest data into different systems (e.g. Clickhouse, DataDog).
 

in-progress/7346-batch-proving-circuits-and-l1.md

@@ -30,7 +30,7 @@ The circuit then performs the following checks and computations:
 
 - Recursively verifies the left and right inputs
 - Checks that the tree is greedily filled from left to right
-- Checks that constants from left and right match
+- Checks that constants from the left and right match
 - Checks that the end state from left matches the start state from right (ie they follow from each other)
 - Outputs the start of left and end of right
 - Hashes together or sums up any accumulated fields (tx count, effects hashes, accumulated fees, etc)
@@ -201,7 +201,7 @@ contract Rollup {
 
 ### State
 
-To track both the proven and unproven chains, we add the following state variables to the contract:
+To track both proven and unproven chains, we add the following state variables to the contract:
 
 ```diff
 contract Rollup {

in-progress/7482-sequencer-prover-test-net.md

@@ -100,7 +100,7 @@ In Spartan v1 the committee will solely be responsible for building the Pending
 
 The validator set will be selected by the multisig.
 
-At the beginning of each epoch, we will assign proposers from the the validator set to slots.
+At the beginning of each epoch, we will assign proposers from the validator set to slots.
 
 The exact number of validators will be determined via stress tests, modeling, and feedback from the community.
 
@@ -133,7 +133,7 @@ sequenceDiagram
 
     P->>L1R: Watches for new L2PendingBlockProcessed events
     P->>L1R: Download TxEffects
-    P->>P: Apply TxEffects to world state
+    P->>P: Apply TxEffects to the world state
     PXE->>L2N: Submit TxObject+Proof
     L2N->>MP: Add TxObject+Proof
     MP->>P: Broadcast TxObjects+Proofs

in-progress/7520-testnet-overview.md

@@ -43,7 +43,7 @@ A deployment of the Aztec Network includes several contracts running on L1.
 
 TST will be an ERC20 asset that will be used to pay for transaction fees on the Aztec Network.
 
-It will also used on L1 as part of the validator selection process.
+It will also be used on L1 as part of the validator selection process.
 
 Protocol incentives are paid out in TST.
 
@@ -322,12 +322,12 @@ There will be penalties for proposers and provers who do not fulfill their dutie
   - committee members
   - proposers
   - provers
-- What is require to convince L1 that the conditions are met?
-- What is the "cost" of an enforcement action? e.g., if tiny penalty it might not be worth to enforce it.
+- What is required to convince L1 that the conditions are met?
+- What is the "cost" of an enforcement action? e.g., if the penalty is tiny it might not be worth to enforce it.
 - What are the penalties for proposers and provers?
 - How can it be ensured that the penalties are fair?
 - What should be burned, and what should be distributed?
-- Expected annual return for validators (mean, median)?
+- What is the expected annual return for validators (mean, median)?
 
 ## Disclaimer
 

in-progress/7588-spartan-clusters.md

@@ -20,7 +20,7 @@ We will:
 
 To properly test a decentralized system, we need the ability to spin up networks with different topologies such as the number of nodes, validators, provers, pxes.
 
-Additionally, we need to test under simulated stress/attack conditions.
+Additionally, we need to test under simulated stress and attack conditions.
 
 Further, we need to be able to deploy these networks in a repeatable and automated way.
 
@@ -33,7 +33,7 @@ This allows us to define a network configuration in a helm chart and deploy it t
 K8s is also easy to use in CI via [kind](https://kind.sigs.k8s.io/).
 
 > kind is a tool for running local Kubernetes clusters using Docker container “nodes”.
-> kind was primarily designed for testing Kubernetes itself, but may be used for local development or CI.
+> kind was primarily designed for testing Kubernetes itself, but it may be used for local development or CI.
 
 Further, we can use [chaos mesh](https://chaos-mesh.org/) to simulate network conditions such as node failures, latency, etc.