Fixup typos

Author: mrmr1993

automation/README.md

@@ -264,11 +264,11 @@ There are several public Grafana dashboards available here:
 
 The purpose of a public testnet is to allow end-users to try out the software and learn how to operate it. Thus, we accept sign-ups for stake to be allocated in the genesis, and commit those keys to the compiled genesis ledger.
 
-For context, these keys correspond to the "Fish Keys" in the QA Net deployments, and Online Fish Keys are ommitted in a Public Testnet deployment and "Offline Fish Keys" are instead delegated to the submitted User Keys.
+For context, these keys correspond to the "Fish Keys" in the QA Net deployments, and Online Fish Keys are omitted in a Public Testnet deployment and "Offline Fish Keys" are instead delegated to the submitted User Keys.
 
 ### Generate Genesis Ledger
 
-Once you have the keys for your deploymenet created, and the Staker Keys saved to a CSV, you can use them to generate a genesis ledger with the following command.
+Once you have the keys for your deployment created, and the Staker Keys saved to a CSV, you can use them to generate a genesis ledger with the following command.
 
 ```
 scripts/generate-keys-and-ledger.sh

buildkite/src/README.md

@@ -1,6 +1,6 @@
 # Buildkite CI
 
-This folder contains all dhall code which is an backbone for our CI related code for buildkite.
+This folder contains all dhall code which is a backbone for our CI related code for buildkite.
 
 # Structure
 
@@ -53,7 +53,7 @@ User defined value which describe current pipeline chunk of jobs to be executed.
 - coverage gathering - which gathers coverage artifacts and uploads it to coveralls.io
 
 To reach above pipeline configuration below configuration can be provided:
-(non important attributes where omitted)
+(non-important attributes where omitted)
 ```
 steps:
   - commands:
@@ -204,4 +204,4 @@ We want only to move dockers from gcr to dockerhub without changing version. Cur
   - "NEW_VERSION=3.0.0-dc6bf78"
   - "CODENAMES=Focal,Bullseye"
   - "PUBLISH=1"
-```
+```

docs/test_dsl_spec.md

@@ -192,7 +192,7 @@ DSL.List.iter (left_partition @ right_partition) ~f:destroy
 
 ALTERNATIVE TEST: keep two partitions separate with a fixed topology, with 1-2 intermediate
 nodes bridging the networks, then take the other bridge offline temporarily and then have them
-rejoin the network without topologoical restrictions and see if the chains reconverge
+rejoin the network without topological restrictions and see if the chains reconverge
 
 ##### Basic Hard Fork Test
 

docs/testnet-guardian-runbook.md

@@ -144,7 +144,7 @@ Following is the list of events that could occur after the release
 |--|------|--------|-------------|--|
 | 1| Issues preventing the users from completing the task | Since, we already tested all the challenges, either the user did the task incorrectly or in a different way that was missed by the engineering team. Usually, the community responds quickly to issues involving the challenges. Let the user know of the alternative way to finish the task. If the errors are real protocol/product bugs, create an issue and request the user to attach coda logs to the issue| Minor | |
 | 2| Users' nodes crashing intermittently | If these are not one of the known bugs then create an issue for the same. Request the user to attach the latest crash report| Minor | |
-| 3| Users' nodes crashing persistently | If it is for a specific user, might be that they did something differently when starting the node or their environment is not as expected. For example, connection timeouts (eventually causing the dameons to crash) between daemon and prover or daemon and snark workers could be because of resource constraints. If the cause is not determined, create an issue and request the user to attach the crash report | Major | Engineering team |
+| 3| Users' nodes crashing persistently | If it is for a specific user, might be that they did something differently when starting the node or their environment is not as expected. For example, connection timeouts (eventually causing the daemons to crash) between daemon and prover or daemon and snark workers could be because of resource constraints. If the cause is not determined, create an issue and request the user to attach the crash report | Major | Engineering team |
 |4| Unstable testnet | Create an issue for the protocol team to investigate. Coordinate with the owners of this event to discuss further actions based on the findings by the protocol team   | Critical | Aneesha, Brandon, Engineer investigating the issue|
 
 ## Change Log

nix/README.md

@@ -605,7 +605,7 @@ happen when you try to build anything inside the pure shell. It happens because
 the stack size for every process is limited, and it is shared between the
 current environment, the argument list, and some other things. Therefore, if
 your environment takes up too much space, not enough is left for the arguments.
-The way to fix the error is to unset some of the bigger enviornment variables,
+The way to fix the error is to unset some of the bigger environment variables,
 perhaps with
 
 ```bash

nix/ocaml.nix

@@ -254,7 +254,7 @@ let
         done
       '') package.outputs);
 
-      # Derivation which has all Mina's dependencies in it, and creates an empty output if the command succeds.
+      # Derivation which has all Mina's dependencies in it, and creates an empty output if the command succeeds.
       # Useful for unit tests.
       runMinaCheck = { name ? "check", extraInputs ? [ ], extraArgs ? { }, }:
         check:

nix/rust.nix

@@ -5,7 +5,7 @@ let
     prev.makeRustPlatform {
       cargo = rust;
       rustc = rust;
-      # override stdenv.targetPlatform here, if neccesary
+      # override stdenv.targetPlatform here, if necessary
     };
   toolchainHashes = {
     "1.72" = "sha256-dxE7lmCFWlq0nl/wKcmYvpP9zqQbBitAQgZ1zx9Ooik=";

rfcs/0016-transition-frontier-persistence.md

@@ -8,7 +8,7 @@ This RFC proposes a new system for persisting the transition frontier's state to
 ## Motivation
 [motivation]: #motivation
 
-The Transition Frontier is too large of a data structure to just blindly serialize and write to disk. Under non optimal network scenarios, we expect the upper bound of the data structure to be >100Gb. Even if the structure were smaller, we cannot write the structure out to disk every time we mutate it as the speed of the transition frontier data structure is critical to the systems ability to prevent DDoS attacks. Therefore, a more robust and effecient system is required to persist the Transition Frontier to disk without negatively effecting the speed of operations on the in memory copy of the Transition Frontier.
+The Transition Frontier is too large of a data structure to just blindly serialize and write to disk. Under non-optimal network scenarios, we expect the upper bound of the data structure to be >100Gb. Even if the structure were smaller, we cannot write the structure out to disk every time we mutate it as the speed of the transition frontier data structure is critical to the systems ability to prevent DDoS attacks. Therefore, a more robust and effecient system is required to persist the Transition Frontier to disk without negatively effecting the speed of operations on the in memory copy of the Transition Frontier.
 
 ## Detailed design
 [detailed-design]: #detailed-design
@@ -30,7 +30,7 @@ As actions are performed on the Transition Frontier, diffs are emitted and store
 
 Having two different mechanisms for writing the same data can be tricky as there can be bugs in one of the two mechanisms that would cause the data structures to become desynchronized. In order to help prevent this, we can introduce an incremental hash on top of the Transition Frontier which can be updated upon each diff application. This hash will give a direct and easy way to compare the structural equality of the two data structures. Being incremental, however, also means that the order of diff application needs to be the same across both data structures, so care needs to be taken with that ordering. Therefore, in a sense, this hash will represent the structure and content of the data structure, as well as the order in which actions were taken to get there. We only care about the former in our case, and the latter is just a consequence of the hash being incremental.
 
-In order to calculate this hash correctly, we need to introduce a new concept to a diff, which is that of a diff mutant. Each diff represents some mutation to perform on the Transition Frontier, however not every diff will contain the enough information by itself to encapsulate the state of the data structure after the mutation occurs. For example, setting a balance on an account in two implementations of the data structure does not guarantee that the accounts in each a equal as there are other fields on the account besides that. This is where the concept of a diff mutant comes in. The mutant of a diff is the set of all modified values in the data structure after the diff has been applied. Using this, we can create a proper incremental diff which will truly ensure our data structures are in sync.
+In order to calculate this hash correctly, we need to introduce a new concept to a diff, which is that of a diff mutant. Each diff represents some mutation to perform on the Transition Frontier, however not every diff will contain the enough information by itself to encapsulate the state of the data structure after the mutation occurs. For example, setting a balance on an account in two implementations of the data structure does not guarantee that the accounts in each an equal as there are other fields on the account besides that. This is where the concept of a diff mutant comes in. The mutant of a diff is the set of all modified values in the data structure after the diff has been applied. Using this, we can create a proper incremental diff which will truly ensure our data structures are in sync.
 
 These hashes will be Sha256 as there is no reason to use the Pedersen hashing algorithm we use in the rest of our code since none of this information needs to be snarked. The formula for calculating a new hash `h'` given an old hash `h` and a diff `diff` is as follows: `h' = sha256 h diff (Diff.mutant diff)`.
 

rfcs/0020-transition-frontier-extensions-2.md

@@ -28,7 +28,7 @@ See [#1585](https://github.com/CodaProtocol/coda/pull/1585) for early discussion
 
 ### Extensions Redefined
 
-A Transition Frontier Extension is an stateful, incremental view on the state of a Transiton Frontier. When a Transition Frontier is initialized, all of its extensions are also initialized using the Transition Frontier's root. Every mutation performed is represented as a list of diffs, and when the Transition Frontier updates, each Extension is notified of this list of diffs synchronously. Transition Frontier Extensions will notify the Transition Frontier if there was a update to the Extension's view when handling the diffs. If an Extension's view is updated, then a synchronous event is broadcast internally with the new view of that Extension. A Transition Frontier Extension has access to the Transition Frontier so that it can query and calculate information it requires when it handles diffs.
+A Transition Frontier Extension is a stateful, incremental view on the state of a Transiton Frontier. When a Transition Frontier is initialized, all of its extensions are also initialized using the Transition Frontier's root. Every mutation performed is represented as a list of diffs, and when the Transition Frontier updates, each Extension is notified of this list of diffs synchronously. Transition Frontier Extensions will notify the Transition Frontier if there was a update to the Extension's view when handling the diffs. If an Extension's view is updated, then a synchronous event is broadcast internally with the new view of that Extension. A Transition Frontier Extension has access to the Transition Frontier so that it can query and calculate information it requires when it handles diffs.
 
 ### Extension Guidelines
 

rfcs/0026-transition-caching.md

@@ -8,7 +8,7 @@ A new transition caching logic for the transition router which aims to track tra
 ## Motivation
 [motivation]: #motivation
 
-Within the transition router system, the only check for duplicate transitions is performed by the transition validator, and each transition is only checked against the transitions which are currently in the transition frontier. However, there are two types of duplicate transitions which are not being checked for: transitions which are still being processed by the system (either in the processor pipe or in the catchup scheduler and catchup thread), and transitions which have been determined to be invalid. In the case of the former, the system ends up processing more transitions than necessary, and the number of duplicated processing increases along with the networks size. In the case of the latter, the system is opened up for DDoS attacks since an adversary could continously send transitions with valid proofs but invalid staged ledger diffs, causing each node to spend a significant enough amount of time before invalidating the transition each time it recieves it.
+Within the transition router system, the only check for duplicate transitions is performed by the transition validator, and each transition is only checked against the transitions which are currently in the transition frontier. However, there are two types of duplicate transitions which are not being checked for: transitions which are still being processed by the system (either in the processor pipe or in the catchup scheduler and catchup thread), and transitions which have been determined to be invalid. In the case of the former, the system ends up processing more transitions than necessary, and the number of duplicated processing increases along with the networks size. In the case of the latter, the system is opened up for DDoS attacks since an adversary could continuously send transitions with valid proofs but invalid staged ledger diffs, causing each node to spend a significant enough amount of time before invalidating the transition each time it recieves it.
 
 NOTE: This RFC has been re-scoped to only address duplicate transitions already being processed and not transitions which were previously determined to be invalid.
 

src/lib/mina_networking/README.md

@@ -2,7 +2,7 @@
 
 ## Typing Conventions
 
-In the context of this document, we will describe query and response types using a psuedo type-system. Tuples of data are in the form `(a, ..., b)`, lists are in the form `[a]`, and polymorphic types are represented as functions returning types. For example, we use the standard polymorphic types `optional :: type -> type` and `result :: type -> type -> type` throughout this document. The `optional` type constructor means that a value can be null, and a `result` type constructor means that there is 1 of 2 possible return types (typically a success type and an error type). For example, `optional int` might be an int or null, where as `result int error` is either an int or an error.
+In the context of this document, we will describe query and response types using a pseudo type-system. Tuples of data are in the form `(a, ..., b)`, lists are in the form `[a]`, and polymorphic types are represented as functions returning types. For example, we use the standard polymorphic types `optional :: type -> type` and `result :: type -> type -> type` throughout this document. The `optional` type constructor means that a value can be null, and a `result` type constructor means that there is 1 of 2 possible return types (typically a success type and an error type). For example, `optional int` might be an int or null, where as `result int error` is either an int or an error.
 
 ### Relevant types
 
@@ -15,7 +15,7 @@ In the context of this document, we will describe query and response types using
 - `protocol_state` == the proven contents of a block (contains `consensus_state`)
 - `block` == an entire block (contains `protocol_state` and the staged ledger diff for that block)
 - `staged_ledger` == the data structure which represents the intermediate (unsnarked) ledger state of the network (large)
-- `pending_coinbase` == a auxilliary hash which identifies some state related to the staged ledger
+- `pending_coinbase` == an auxilliary hash which identifies some state related to the staged ledger
 - `sync_ledger_query` == queries for performing sync ledger protocol (requests for hashes or batches of subtrees of a merkle tree)
 - `sync_ledger_response` == responses for handling sync ledger protocol (responses of hashes or batches of subtrees of a merkle tree)
 - `transaction_pool_diff` == a bundle of multiple transactions to be included into the blockchain
@@ -34,13 +34,13 @@ Broadcasts newly produced blocks throughout the network.
 
 **Data**: `transaction_pool_diff`
 
-Broadcasts transactions from mempools throughout the network. Nodes broadcast locally submitted transactions on an interval for a period of time after creation, as well as rebroadcast externally submitted transactions if they were relevant and could be added to the their mempool.
+Broadcasts transactions from mempools throughout the network. Nodes broadcast locally submitted transactions on an interval for a period of time after creation, as well as rebroadcast externally submitted transactions if they were relevant and could be added to their mempool.
 
 ### snark\_pool\_diffs
 
 **Data**: `snark_pool_diff`
 
-Broadcasts snark work from mempools throughout the network. Snark coordinator's broadcast locally produced snarks on an interval for a period of time after creation, and all nodes rebroadcast externally produced snarks if they were relevant and could be added to the their mempool.
+Broadcasts snark work from mempools throughout the network. Snark coordinator's broadcast locally produced snarks on an interval for a period of time after creation, and all nodes rebroadcast externally produced snarks if they were relevant and could be added to their mempool.
 
 ## RPC Messages
 
@@ -82,7 +82,7 @@ Serves merkle ledger information over a "sync ledger" protocol. The sync ledger
 
 **Response**: `optional [block]`
 
-Returns a bulk bulk set of blocks associated with a provided set of state hashes. This is used by the catchup routine when it is downloading old blocks to re synchronize with the network over short distances of missing information. At the current moment, the maximum number of blocks that can be requested in a single batch is 20 (requesting more than 20 will result in no response).
+Returns a bulk set of blocks associated with a provided set of state hashes. This is used by the catchup routine when it is downloading old blocks to re synchronize with the network over short distances of missing information. At the current moment, the maximum number of blocks that can be requested in a single batch is 20 (requesting more than 20 will result in no response).
 
 ### get\_transition\_chain\_proof
 
@@ -100,7 +100,7 @@ Returns a transition chain proof for a specified block on the blockchain. A tran
 
 **Response**: `[state_hash]`
 
-Returns the a list of `k` state hashes of blocks from the root of the frontier (point of finality) up to the current best tip (most recent block on the canonical chain).
+Returns the list of `k` state hashes of blocks from the root of the frontier (point of finality) up to the current best tip (most recent block on the canonical chain).
 
 ### get\_ancestry
 
@@ -136,4 +136,4 @@ Returns the best tip block along with the root block of the frontier, and a merk
 
 **Response**: `result node_status error`
 
-This acts as a telemetry RPC which asks a peer to provide invformation about their node status. Daemons do not have to respond to this request, and node operators may pass a command line flag to opt-out of responding to these node status requests.
+This acts as a telemetry RPC which asks a peer to provide information about their node status. Daemons do not have to respond to this request, and node operators may pass a command line flag to opt-out of responding to these node status requests.