diff --git a/acvm-repo/acir/acir_docs.md b/acvm-repo/acir/acir_docs.md index fd89b3f292b..1215ea22330 100644 --- a/acvm-repo/acir/acir_docs.md +++ b/acvm-repo/acir/acir_docs.md @@ -43,7 +43,7 @@ The values of the witnesses lie in the scalar field of the proving system. We wi *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 @@ input: (witness, bit_size) **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 @@ The proving system decides how the message is to be hashed. Barretenberg uses Bl - 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 @@ $a=low+high*2^{128},$ with $low, high < 2^{128}$ - 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,8 +179,8 @@ This opcode is used as a hint for the solver when executing (solving) the circui - 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