chore: fix spelling issues

acvm-repo/acir/acir_docs.md

@@ -32,7 +32,7 @@
 In summary, the workflow is the following:
 1. user program -> (compilation) ACIR, a list of opcodes which constrain (partial) witnesses
 2. user inputs + ACIR -> (execution/solving) assign values to all the (partial) witnesses 
 3. witness assignement + ACIR -> (proving system) proof
 
 
 Although the ordering of opcode does not matter in theory, since a system of equations is not dependent on its ordering, in practice it matters a lot for the solving (i.e the performance of the execution). ACIR opcodes **must be ordered** so that each opcode can be resolved one after the other.
@@ -43,7 +43,7 @@
 
 *Remark*: The value of a partial witness is unique and fixed throughout a program execution, although in some rare cases, multiple values are possible for a same execution and witness (when there are several valid solutions to the constraints). Having multiple possible values for a witness may indicate that the circuit is not safe.
 
-*Remark*: Why do we use the term partial witnesses? It is because the proving system may create other constraints and witnesses (especially with BlackBoxFuncCall, see below). A proof refers to a full witness assignements and their constraints. ACIR opcodes and their partial witnesses are still an intermediate representation before getting the full list of constraints and witnesses. For the sake of simplicity, we will refer to witness instead of partial witness from now on.
+*Remark*: Why do we use the term partial witnesses? It is because the proving system may create other constraints and witnesses (especially with BlackBoxFuncCall, see below). A proof refers to a full witness assignments and their constraints. ACIR opcodes and their partial witnesses are still an intermediate representation before getting the full list of constraints and witnesses. For the sake of simplicity, we will refer to witness instead of partial witness from now on.
 
 
 ## ACIR Reference
@@ -91,11 +91,11 @@
 
 **SHA256**: computes sha256 of the inputs
 - inputs are a byte array, i.e a vector of (FieldElement, 8)
-- output is a byte array of len 32, i.e a vector of 32 (FieldElement, 8), constrainted to be the sha256 of the inputs.
+- output is a byte array of len 32, i.e a vector of 32 (FieldElement, 8), constrained to be the sha256 of the inputs.
 
 **Blake2s**: computes the Blake2s hash of the inputs, as specified in https://tools.ietf.org/html/rfc7693
 - inputs are a byte array, i.e a vector of (FieldElement, 8)
-- output is a byte array of length 32, i.e a vector of 32 (FieldElement, 8), constrainted to be the blake2s of the inputs.
+- output is a byte array of length 32, i.e a vector of 32 (FieldElement, 8), constrained to be the blake2s of the inputs.
 
 
 **SchnorrVerify**: Verify a Schnorr signature over the embedded curve
@@ -114,7 +114,7 @@
 - output: 2 witnesses representing the x,y coordinates of the resulting Grumpkin point
 - domain separator: a constant public value (a field element) that you can use so that the commitment also depends on the domain separator. Noir uses 0 as domain separator.
 
-The backend should handle proper conversion between the inputs being ACIR field elements and the scalar field of the embedded curve. In the case of Aztec's Barretenberg, the latter is bigger than the ACIR field so it is straightforward. The Peredersen generators are managed by the proving system.
+The backend should handle proper conversion between the inputs being ACIR field elements and the scalar field of the embedded curve. In the case of Aztec's Barretenberg, the latter is bigger than the ACIR field so it is straightforward. The Pedersen generators are managed by the proving system.
 
 
 **PedersenHash**: Computes a Pedersen commitments of the inputs and their number, using generators of the embedded curve
@@ -163,7 +163,7 @@
 - verification_key: Vector of (FieldElement, 254) representing the verification key of the circuit being verified
 - public_inputs: Vector of (FieldElement, 254)  representing the public inputs corresponding to the proof being verified
 - key_hash: one (FieldElement, 254). It should be the hash of the verification key. Barretenberg expects the Pedersen hash of the verification key
-- input_aggregation_object: an optional vector of (FieldElement, 254). It is a blob of data specific to the proving sytem.
+- input_aggregation_object: an optional vector of (FieldElement, 254). It is a blob of data specific to the proving system.
 - output_aggregation_object: Some witnesses returned by the function, representing some data internal to the proving system.
 
 This black box function does not fully verify a proof, what it does is verifying that the key_hash is indeed a hash of verification_key, allowing the user to use the verification key as private inputs and only have the key_hash as public input, which is more performant.
@@ -179,18 +179,18 @@
 - bytecode: assembly code representing the computation to perform within this opcode. The noir assembly specification is not part of this document.
 - predicate: an arithmetic expression that disable the opcode when it is null.
 
-Let's see an example with euclidian division.
-The normal way to compute a/b, where a and b are 8-bits integers, is to implement Euclid algorithm which computes in a loop (or recursively) modulos of the kind 'a mod b'. Doing this computation requires a lot of steps to be properly implemented in ACIR, especially the loop with a condition. However, euclidian division can be easily constrained with one assert-zero opcode: a = bq+r, assuming q is 8 bits and r<b. Since these assumptions can easily written with a few range opcodes, euclidian division can in fact be implemented with a small number of opcodes.
+Let's see an example with euclidean division.
+The normal way to compute a/b, where a and b are 8-bits integers, is to implement Euclid algorithm which computes in a loop (or recursively) modulus of the kind 'a mod b'. Doing this computation requires a lot of steps to be properly implemented in ACIR, especially the loop with a condition. However, euclidean division can be easily constrained with one assert-zero opcode: a = bq+r, assuming q is 8 bits and r<b. Since these assumptions can easily written with a few range opcodes, euclidean division can in fact be implemented with a small number of opcodes.
 
 However, in order to write these opcodes we need the result of the division which are the witness q and r. But from the constraint a=bq+r, how can the solver figure out how to solve q and r with only one equation? This is where brillig/unconstrained function come into action. We simply define a function that performs the usual Euclid algorithm to compute q and r from a and b. Since Brillig opcode does not generate constraint, it won't be provided to the proving system but simply used by the solver to compute the values of q and r.
 
 In summary, solving a Brillig opcode performs the computation defined by its bytecode, on the provided inputs, and assign the result to the outputs witnesses, without adding any constraint.
 
 ### Directive
 This opcode is a specialisation of Brillig opcode. Instead of having some generic assembly code like Brillig, a directive has a hardcoded name which tells the solver which computation to do: with Brillig, the computation refers to the compiled bytecode of an unconstrained Noir function, but with a directive, the computation is hardcoded inside the compiler. Directives will be replaced by Brillig opcodes in the future.
 
 ### MemoryOp: memory abstraction for ACIR
 ACIR is able to address any array of witnesses. Each array is assigned an id (BlockId) and needs to be initialised with the MemoryInit opcode. Then it is possible to read and write from/to an array by providing the index and the value we read/write, as arithmetic expression. Note that ACIR arrays all have a known fixed length (given in the MemoryInit opcode below)
 - block_id: identifier of the array
 - op: describe the memory operation to perform
 	- operation: constant expression having value 1 for a write to memory and 0 for a read
@@ -199,8 +199,8 @@
 - predicate: an arithmetic expression that disable the opcode when it is null.
 
 ### MemoryInit
 Initialise an ACIR array from a vector of witnesses.
 - block_id: identifier of the array
 - init: Vector of witnesses specifying the initial value of the arrays
 
-There must be only one MemoryInit per block_id, and MemoryOp opcodes must come after the MemoryInit.
+There must be only one MemoryInit per block_id, and MemoryOp opcodes must come after the MemoryInit.

cspell.json

@@ -49,6 +49,7 @@
         "forall",
         "foralls",
         "formatcp",
+        "frontends",
         "fxhash",
         "getrandom",
         "gloo",