Merge pull request #35 from rex4539/typos

Fix typos

docs/docs/developers/bridges/dataprovider.md

@@ -33,7 +33,7 @@ forge script DataProviderDeployment --rpc-url $ETH_RPC_URL --sig "read()"
 
 Updating values stored in the data provider is only possible by the owner of the contract.
 
-Before running the commands bellow export relevant environment variables:
+Before running the commands below export relevant environment variables:
 
 ```bash
 export RPC="https://mainnet.infura.io/v3/737bcb5393b146d7870be2f68a7cea9c" && PRIV_KEY="PROVIDER_OWNER_PRIVATE_KEY"

docs/docs/developers/bridges/subsidy.md

@@ -19,10 +19,10 @@ When building a bridge, the bridge needs to have a way of calling the `setGasUsa
 
 Thereafter, you need to decide how your bridge is to compute the criteria values. If your bridge is limited in the actions it can take, e.g., the Yearn bridge only deposits/withdraws into/from yearn, it might be useful to have simple criteria that are shared between different flows, as it is then straightforward to subsidise multiple of them at once (in this case Yearn subsidised all the deposits, regardless of asset). If the bridge is more general purpose (such as ERC4626) it is beneficial to allow subsidising based on the combination of input and output assets. This can be done by computing a hash of input/output token addresses and converting that value to `uint256` and should be implemented in the `computeCriteria()` function.
 
-With setup and criterias managed, you just need to make sure that the `convert()` function claims the subsidy through the `claimSubsidy()` function, which takes the criteria and the rollup beneficiary (address passed by sequencer). Without this function, no subsidy is given. 
+With setup and criteria managed, you just need to make sure that the `convert()` function claims the subsidy through the `claimSubsidy()` function, which takes the criteria and the rollup beneficiary (address passed by sequencer). Without this function, no subsidy is given. 
 
 # How do I subsidise?
-When you have found a bridge to subsidise, you need to figure out what flows you want to subsidise (the criteria). This criteria will depend on the bridge and the best way to figure out the meaning of different criterias is to simply check the bridge's code. 
+When you have found a bridge to subsidise, you need to figure out what flows you want to subsidise (the criteria). This criteria will depend on the bridge and the best way to figure out the meaning of different criteria is to simply check the bridge's code. 
 For bridges that follow the base implementation, there will be a `computeCriteria()` function taking assets and auxdata as input that should compute the criteria for a given interaction. *Note*: multiple flows can have the same criteria.
 
 

docs/docs/glossary.md

@@ -24,7 +24,7 @@ The accounts registered by users on Aztec are represented by account notes. An a
 
 Used when a user loses access to all of their registered [Spending keys](#spending-key). Note that a user must have the [viewing key](#viewing-key) in order to recover an account.
 
-Read more about acccount recovery in the SDK docs [here](./sdk/usage/account-recovery.md).
+Read more about account recovery in the SDK docs [here](./sdk/usage/account-recovery.md).
 
 ### Account Registration
 

docs/docs/how-aztec-works/aztec-connect/technical-intro.md

@@ -6,7 +6,7 @@ This page is taken from the [Aztec Connect Bridges repository](https://github.co
 
 ### What is Aztec?
 
-Aztec is a privacy focussed L2, that enables cheap private interactions with Layer 1 smart contracts and liquidity, via a process called DeFi Aggregation. We use advanced zero-knowledge technology "zk-zk rollups" to add privacy and significant gas savings any Layer 1 protocol via Aztec Connect bridges.
+Aztec is a privacy focused L2, that enables cheap private interactions with Layer 1 smart contracts and liquidity, via a process called DeFi Aggregation. We use advanced zero-knowledge technology "zk-zk rollups" to add privacy and significant gas savings any Layer 1 protocol via Aztec Connect bridges.
 
 #### What is a bridge?
 
@@ -32,13 +32,13 @@ The source of funds for any Aztec Connect transaction is an Aztec shielded asset
 
 #### Batching
 
-Rollup providers are incentivised to batch any transaction with the same `bridgeId`. This reduces the cost of the L1 transaction for similar trades. A `bridgeId` consits of:
+Rollup providers are incentivised to batch any transaction with the same `bridgeId`. This reduces the cost of the L1 transaction for similar trades. A `bridgeId` consists of:
 
 ## Virtual Assets
 
 Aztec uses the concept of Virtual Assets or Position tokens to represent a share of assets held by a Bridge contract. This is far more gas efficient than minting ERC20 tokens. These are used when the bridge holds an asset that Aztec doesn't support (e.g. Uniswap Position NFT's or other non-fungible assets).
 
-If the output asset of any interaction is specified as "VIRTUAL", the user will receive encrypted notes on Aztec representing their share of the position, but no tokens or ETH need to be transfered. The position tokens have an `assetId` that is the `interactionNonce` of the DeFi Bridge call. This is globably unique. Virtual assets can be used to construct complex flows, such as entering or exiting LP positions (e.g. one bridge contract can have multiple flows which are triggered using different input assets).
+If the output asset of any interaction is specified as "VIRTUAL", the user will receive encrypted notes on Aztec representing their share of the position, but no tokens or ETH need to be transferred. The position tokens have an `assetId` that is the `interactionNonce` of the DeFi Bridge call. This is globally unique. Virtual assets can be used to construct complex flows, such as entering or exiting LP positions (e.g. one bridge contract can have multiple flows which are triggered using different input assets).
 
 ## Aux Input Data
 
@@ -125,7 +125,7 @@ interface IDefiBridge {
 
   /*
   @dev This function is called from the RollupProcessor.sol contract via the DefiBridgeProxy.
-    It receives the aggreagte sum of all users funds for the input assets.
+    It receives the aggregate sum of all users funds for the input assets.
   @param AztecAsset inputAssetA a struct detailing the first input asset, 
     this will always be set
   @param AztecAsset inputAssetB an optional struct detailing the second input asset, 
@@ -156,7 +156,7 @@ interface IDefiBridge {
 
 If a Defi Bridge interaction is asynchronous, it must be finalised at a later date once the DeFi interaction has completed.
 
-This is acheived by calling `RollupProcessor.processAsyncDefiInteraction(uint256 interactionNonce)`. This internally will call `finalise` and ensure the correct amount of tokens have been transferred.
+This is achieved by calling `RollupProcessor.processAsyncDefiInteraction(uint256 interactionNonce)`. This internally will call `finalise` and ensure the correct amount of tokens have been transferred.
 
 #### convert()
 

docs/docs/sdk/overview.md

@@ -19,7 +19,7 @@ The Aztec SDK has many capabilities, many of which are associated with the follo
 - Register new accounts
 - Handle signing keys to spend notes or withdraw assets to Ethereum
 - Query Aztec transaction fees and specify settlement time
-- Lookup user aliases associated with spending account to make transfering assets easier
+- Lookup user aliases associated with spending account to make transferring assets easier
 - Migrate accounts to a new public key
 - Recover accounts for which a spending key was lost
 - Initiate interactions with smart contracts on Ethereum (i.e. defi deposits, token swaps, or unique interactions with custom [bridge contracts](https://github.com/AztecProtocol/aztec-connect-bridges))

docs/docs/sdk/usage/ethereum-interaction.md

@@ -43,7 +43,7 @@ You can get the bridge `addressId`s from the published [Deployed Bridge Info tab
 You can also query the bridge ids on the rollup processor contracts directly. [Here is the link](https://etherscan.io/address/0xff1f2b4adb9df6fc8eafecdcbf96a2b351680455#readProxyContract
 ) to read the contract Etherscan. You can get the bridge contract addresses from the `getSupportedBridge` or `getSupportedBridges` functions. The bridge `addressId` corresponds to it's index in the supported bridges array returned by `getSupportedBridges`.
 
-Once you have the bridge `addressId`, you can initialize a new bridge instance. The `BridgeCallData` contstructor looks like this:
+Once you have the bridge `addressId`, you can initialize a new bridge instance. The `BridgeCallData` constructor looks like this:
 
 ```ts
 const bridge = new BridgeCallData(

docs/docs/sdk/usage/withdraw.md

@@ -24,7 +24,7 @@ AztecSdk.createWithdrawController(
 
 | Arguments | Type | Description |
 | --------- | ---- | ----------- |
-| userId | [GrumpkinAddress](../types/barretenberg/GrumpkinAddress) | The Aztec account to make the withrawal from. |
+| userId | [GrumpkinAddress](../types/barretenberg/GrumpkinAddress) | The Aztec account to make the withdrawal from. |
 | userSigner | [Signer](../types/sdk/Signer) | A signer for the provided `userId`. |
 | value | [AssetValue](../types/barretenberg/AssetValue) | The asset type and amount to withdraw. |
 | fee | [AssetValue](../types/barretenberg/AssetValue) | The asset type and amount to pay for the Aztec transaction fee. |
@@ -40,7 +40,7 @@ AztecSdk.createWithdrawController(
 
 Fees for withdrawals are calculated using a similar method as for [registrations](register#calculating-fees), deposits and [transfers](transfer#transfer-fees), but using the `getWithdrawalFees` method.
 
-`getWithdrawalFees` has a second optional argument `reciepient?: EthAddress`. This is used to check if the recipient address is a contract wallet, for which the fees are higher.
+`getWithdrawalFees` has a second optional argument `recipient?: EthAddress`. This is used to check if the recipient address is a contract wallet, for which the fees are higher.
 
 The settlement time is inferred from the fee a user pays, it is not explicitly sent to the controller.
 

docs/docs/spec/account_circuit.md

@@ -130,7 +130,7 @@ _There's a little diagram at the diagrams link too._
 4. If a `spending_public_key` becomes compromised, Alice must do the following:
 
 - generate a _new_ account note with a `new_account_public_key` and her existing `alice` alias (using the `migrate` flow). The new account note's spending keys SHOULD be different to the compromised key (although there are no protocol checks to enforce this).
-- Use the account `update` flow to assign additional _non-comprimised_ spending keys to her new account note`.
+- Use the account `update` flow to assign additional _non-compromised_ spending keys to her new account note`.
 - Alice transfers funds assigned to `(account_public_key, alice)` and sends them to `(new_account_public_key, alice)`
 
 1. Similarly, if Alice's `account_private_key` becomes compromised, she can use the account circuit to migrate to a new `account_public_key`.
@@ -147,7 +147,7 @@ As previously, the field $\mathbb{F}_p$ is from the BN254 specification.
 
 ### Public Inputs: Detail
 
-Recall that all inner circuits must have the **same number of public inputs** as they will be used homogenously by the rollup circuit. Hence, most of the account circuit's public inputs are 0, because they're not actually needed for the account circuit's functionality.
+Recall that all inner circuits must have the **same number of public inputs** as they will be used homogeneously by the rollup circuit. Hence, most of the account circuit's public inputs are 0, because they're not actually needed for the account circuit's functionality.
 
 1. `proof_id = PublicInputs::ACCOUNT` (i.e. this is effectively a witness which can only take one valid value).
 1. `output_note_commitment_1`

docs/docs/spec/claim_circuit.md

@@ -42,7 +42,7 @@ At a high level, the claim circuit does the following:
 
 #### Inputs
 
-Recall that all inner circuits must have the **same number of public inputs** as they will be used homogenously by the rollup circuit. Hence, some of the inputs to a claim circuit are unused and so set to 0.
+Recall that all inner circuits must have the **same number of public inputs** as they will be used homogeneously by the rollup circuit. Hence, some of the inputs to a claim circuit are unused and so set to 0.
 
 ##### Public Inputs
 

docs/docs/spec/primitives.md

@@ -70,7 +70,7 @@ $$
 H(m_1,m_2) = m_1.g + m_2.h
 $$
 
-for generators $g,h \in \mathbb{G}$ chosen independently by public randomness (e.g. hueristically as distinct outputs of a random oracle simulating hash function).
+for generators $g,h \in \mathbb{G}$ chosen independently by public randomness (e.g. heuristically as distinct outputs of a random oracle simulating hash function).
 
 We wish to define a variant of Pedersen to enable hashing strings of any desired length. As our group $\mathbb{G}$ we will use the Grumpkin curve group described above.
 
@@ -103,7 +103,7 @@ For details on how $h_i$ have been generated, please see *Global Constants*.
 
 #### Blake2s Hash
 
-We use the Blake2s Hash more sparingly, because it is not SNARK-friendly, but it does exhibit psuedorandomness not offered by Pedersen. That is, it is considered a reasonable hueristic to use it in place of a random oracle used for a security proof. 
+We use the Blake2s Hash more sparingly, because it is not SNARK-friendly, but it does exhibit pseudorandomness not offered by Pedersen. That is, it is considered a reasonable heuristic to use it in place of a random oracle used for a security proof. 
 
 We employ the standard implementation of the Blake2s hash, which is fully documented [here](https://tools.ietf.org/html/rfc7693).
 

docs/docs/spec/rollup_circuit.md

@@ -73,8 +73,8 @@ The following inputs are private to reduce proof size:
 - `Aggregate` **Proof Aggregation Function** for ultimate batch verification outside the circuit, given a verification key and (optional, defined by 4th input parameter) a previous output of Aggregate. Returns a BN254 point pair
 - `NonMembershipUpdate` **Nullifier Update Function** checks a nullifier is not in a nullifier set given its root, then inserts the nullifier and validates the correctness of the associated merkle root update
 - `BatchUpdate` **Batch Update Function** inserts a set of compressed note commitments into the note tree and validates the corretness of the associated merkle root update
-  Update - inserts a single leaf into the root tree and validates the corretness of the associated merkle root update
-- `ProcessDefiDeposit` **Processes Defi Deposit** ensures that if a given inner proof is a defi deposit proof, it has a valid bridge call data that matches one of the input bridge call datas to the rollup. Further, it also adds the `defi_interaction_nonce` in the encrypted claim note of a defi deposit proof.
+  Update - inserts a single leaf into the root tree and validates the correctness of the associated merkle root update
+- `ProcessDefiDeposit` **Processes Defi Deposit** ensures that if a given inner proof is a defi deposit proof, it has a valid bridge call data that matches one of the input bridge call data to the rollup. Further, it also adds the `defi_interaction_nonce` in the encrypted claim note of a defi deposit proof.
 - `ProcessClaim` **Process Claims** checks if the claim proof is using the correct defi root.
 
 ### Circuit Logic (Pseudocode)

docs/docs/spec/schnorr.md

@@ -95,7 +95,7 @@ Given $\text{Sig} = (s, e)\in \{0,1\}^{256} \times \{0,1\}^{256}$, purported to
 The signature is verified if and only if $e'== e$, where the comparison is done bit-wise.
 
 Imprecise rationale: The verification equation is $e = h((e.pub + s.g).x, m)$ where both sides of the equation are represented as an array of 256 bits. 
-VERIFIER has seen that SIGNER can produce a preimage for a given $e$ which is outside of SIGNER's control by chosing a particular value of $s$. 
+VERIFIER has seen that SIGNER can produce a preimage for a given $e$ which is outside of SIGNER's control by choosing a particular value of $s$. 
 The difficulty of this assumption is documented, in the case where $\mathbb{G}_1$ is the units group of a finite field, in Schnorr's original paper [Sch] (cf especially pages 10-11).
 
 ### Variable base multiplication
@@ -113,7 +113,7 @@ scalar presented as a `wnaf_record`, provided along with a `current_accumulator`
 
 ### `variable_base_mul(pub_key, current_accumulator, wnaf)`
 
-- This function is only called inside of `variable_base_mul(pub_key, low_bits, high_bits)`. There is an `init` predicate given by: "`current_accumulator` and `pub_key` have the same x-coordinate". This is intended as a stand-in for the more general check that these two points are equal. This condition distinguishes between two modes in which the function is used in the implementation of the function `variable_base_mul(pub_key, low_bits, high_bits)`: on the second call, the condition `init` is espected to be false, so that the results of the first call, recorded in `current_accumulator`, are incorporated in the output.
+- This function is only called inside of `variable_base_mul(pub_key, low_bits, high_bits)`. There is an `init` predicate given by: "`current_accumulator` and `pub_key` have the same x-coordinate". This is intended as a stand-in for the more general check that these two points are equal. This condition distinguishes between two modes in which the function is used in the implementation of the function `variable_base_mul(pub_key, low_bits, high_bits)`: on the second call, the condition `init` is expected to be false, so that the results of the first call, recorded in `current_accumulator`, are incorporated in the output.
 - There is branching depending on whether on the parity of the scalar represented by `wnaf`.
 
 ### `variable_base_mul(pub_key, low_bits, high_bits)`
@@ -130,7 +130,7 @@ This function has not been investigated since I propose it be removed. It is not
 
 ### `convert_field_into_wnaf(context, limb)`
 
-- When accumulating a `field_t` element using the proposed wnaf representaiton, there is branching at each bit position depending on the 32nd digit of the current `uint64_t` element `wnaf_entries[i+1]`.
+- When accumulating a `field_t` element using the proposed wnaf representation, there is branching at each bit position depending on the 32nd digit of the current `uint64_t` element `wnaf_entries[i+1]`.
 
 ## Security Notes
 
@@ -155,7 +155,7 @@ We would need to derive two independent signing and PRF keys from one 256-bit se
 
 Given a valid signature $(s,e) \in  \{0,1\}^{256} \times \{0,1\}^{256}$ , it is possible to generate another valid signature $(s',e) \in  \{0,1\}^{256} \times \{0,1\}^{256}$, 
 where $s'\neq s$ but $\mathbb{F}_r(s') = \mathbb{F}_r(s)$ (take $s'$ to be congruent to $s$ modulo $r$).
-The solution would be to check that $\text{int}(s) < r$, but this would incurr an additional range check within the circuit
+The solution would be to check that $\text{int}(s) < r$, but this would incur an additional range check within the circuit
 which we avoid for efficiency reasons. 
 
 In our context, signatures are used within the `account` and `join_split` circuits to link the public inputs to the user's spending key

docs/docs/zk-money/assetvaluation.md

@@ -13,4 +13,4 @@ Chainlink provides no direct oracle for wstETH, but does provide an [oracle for
 
 ## Element fixed yield positions
 
-Over time we interpolate between the asset quantitiy locked in your position and its promised output. The interpolated quanity is then given a dollar valuation with use of Chainlink.
+Over time we interpolate between the asset quantity locked in your position and its promised output. The interpolated quantity is then given a dollar valuation with use of Chainlink.