Merge pull request #2918 from oliveredget/typo

docs: fix typos
o1-labs · Jan 2, 2025 · 98f0239 · 98f0239
2 parents ce5d6f6 + fc5755d
commit 98f0239
Show file tree

Hide file tree

Showing 6 changed files with 8 additions and 8 deletions.
diff --git a/book/src/pickles/diagrams.md b/book/src/pickles/diagrams.md
@@ -7,7 +7,7 @@ The legend of the diagrams is quite straightforward:
   - `MFNStep`/`MFNWrap` is an abbreviation from `MessagesForNextStep` and `MessagesForNextWrap` that is used for brevity. Most other datatypes are exactly the same as in the codebase.
 - The blue boxes are computations. Sometimes, when the computation is trivial or only vaguely indicated, it is denoted as a text sign directly on an arrow.
 - Arrows are blue by default and denote moving a piece of data from one place to another with no (or very little) change. Light blue arrows are denoting witness query that is implemented through the `handler` mechanism. The "chicken foot" connector means that this arrow accesses just one field in an array: such an arrow could connect e.g. a input field of type `old_a: A` in a structure `Vec<(A,B)>` to an output `new_a: A`, which just means that we are inside a `for` loop and this computation is done for all the elemnts in the vector/array.
-- Colour of the field is sometimes introduced and denotes how many steps ago was this piece of data created. The absense of the colour means either that (1) the data structure contains different subfields of different origin, or that (2) it was not coloured but it could be. The colours are assigned according to the following convention:
+- Colour of the field is sometimes introduced and denotes how many steps ago was this piece of data created. The absence of the colour means either that (1) the data structure contains different subfields of different origin, or that (2) it was not coloured but it could be. The colours are assigned according to the following convention:
 
 ![](./pickles_structure_legend_1.svg)
 

diff --git a/book/src/pickles/overview.md b/book/src/pickles/overview.md
@@ -27,4 +27,4 @@ We note that the Step circuit may repeat items 2-3 to handle the following case:
 
 The accumulator is an abstraction introduced for the purpose of this diagram. In practice, each kimchi proof consists of (1) commitments to polynomials, (2) evaluations of them, (3) and the opening proof. What we refer to as accumulator here is actually the commitment inside the opening proof. It is called `sg` in the implementation and is semantically a polynomial commitment to `h(X)` (`b_poly` in the code) --- the poly-sized polynomial that is built from IPA challenges. It's a very important polynomial -- it can be evaluated in log time, but the commitment verification takes poly time, so the fact that `sg` is a commitment to `h(X)` is never proven inside the circuit. For more details, see [Proof-Carrying Data from Accumulation Schemes](https://eprint.iacr.org/2020/499.pdf), Appendix A.2, where `sg` is called `U`.
 
-In pickles, what we do is that we "absorb" this commitment `sg` from the previous step while creating a new proof. That is, for example, Step 1 will produce this commitment that is denoted as `acc1` on the diagram, as part of its opening proof, and Step 2 will absorb this commitment. And this "absorbtion" is what Wrap 2 will prove (and, partially, Step 3 will also refer to the challenges used to build `acc1`, but this detail is completely avoided in this overview). In the end, `acc2` will be the result of Step 2, so in a way `acc2` "aggregates" `acc1` which somewhat justifies the language used.
+In pickles, what we do is that we "absorb" this commitment `sg` from the previous step while creating a new proof. That is, for example, Step 1 will produce this commitment that is denoted as `acc1` on the diagram, as part of its opening proof, and Step 2 will absorb this commitment. And this "absorption" is what Wrap 2 will prove (and, partially, Step 3 will also refer to the challenges used to build `acc1`, but this detail is completely avoided in this overview). In the end, `acc2` will be the result of Step 2, so in a way `acc2` "aggregates" `acc1` which somewhat justifies the language used.
diff --git a/book/src/snarky/kimchi-backend.md b/book/src/snarky/kimchi-backend.md
@@ -107,7 +107,7 @@ It is the role of the `add_constrain` logic to enforce that at this point consta
 This is done by adding enough generic gates (using the `reduce_lincom()` or `reduce_to_var()` functions).
 
 ```admonish
-This is a remnant of an optimization targetting R1CS (in which additions are for free).
+This is a remnant of an optimization targeting R1CS (in which additions are for free).
 An issue with this approach is the following: imagine that two circuit variables are created from the same circuit variable, imagine also that the original circuit variable contained a long AST, then both variables might end up creating the same constraints to convert that AST.
 Currently, snarkyjs and pickles expose a `seal()` function that allows you to reduce this issue, at the cost of some manual work and mental tracking on the developer.
 We should probably get rid of this, while making sure that we can continue to optimize generic gates 
@@ -142,7 +142,7 @@ The `finalization()` function of the kimchi backend does the following:
 
 * add as many generic rows as there are public inputs.
 * construct the permutation 
-* computes a cache of the circuit (TODO: this is so unecessary)
+* computes a cache of the circuit (TODO: this is so unnecessary)
 * and other things that are not that important
 
 ## Witness generation

diff --git a/book/src/snarky/snarky-wrapper.md b/book/src/snarky/snarky-wrapper.md
@@ -48,7 +48,7 @@ The wrapper is designed to be used in different ways, depending on the fields se
 
 ```admonish
 Ideally, we would like to only run this once and obtain a result that's an immutable compiled artifact.
-Currently, `public_input`, `private_input`, `eval_constriants`, `next_var`, and `mode` all need to be mutable.
+Currently, `public_input`, `private_input`, `eval_constraints`, `next_var`, and `mode` all need to be mutable.
 In the future these should be passed as arguments to functions, and should not exist in the state.
 ```
 

diff --git a/book/src/snarky/vars.md b/book/src/snarky/vars.md
@@ -18,7 +18,7 @@ where
     /// A constant.
     Constant(F),
 
-    /// A variable that can be refered to via a `usize`.
+    /// A variable that can be referred to via a `usize`.
     Var(usize),
 
     /// The addition of two other [FieldVar]s.
@@ -65,7 +65,7 @@ In some situations, we might not want to constrain the
 In general, a circuit variable only gets constrained by an assertion call like `assert` or `assert_equals`.
 
 When variables are added together, or scaled, they do not directly get constrained. 
-This is due to optimizations targetting R1CS (which we don't support anymore) that were implemented in the original snarky library, and that we have kept in snarky-rs.
+This is due to optimizations targeting R1CS (which we don't support anymore) that were implemented in the original snarky library, and that we have kept in snarky-rs.
 
 Imagine the following example:
 

diff --git a/o1vm/README.md b/o1vm/README.md
@@ -55,7 +55,7 @@ gvm use go1.21s
 ```
 
 You also will need to install the [Foundry](https://getfoundry.sh/) toolkit
-in order to utilize applicaitons like `cast`.
+in order to utilize applications like `cast`.
 
 ```shell
 foundryup
Original file line number	Diff line number	Diff line change
Expand Up		@@ -27,4 +27,4 @@ We note that the Step circuit may repeat items 2-3 to handle the following case:

		The accumulator is an abstraction introduced for the purpose of this diagram. In practice, each kimchi proof consists of (1) commitments to polynomials, (2) evaluations of them, (3) and the opening proof. What we refer to as accumulator here is actually the commitment inside the opening proof. It is called `sg` in the implementation and is semantically a polynomial commitment to `h(X)` (`b_poly` in the code) --- the poly-sized polynomial that is built from IPA challenges. It's a very important polynomial -- it can be evaluated in log time, but the commitment verification takes poly time, so the fact that `sg` is a commitment to `h(X)` is never proven inside the circuit. For more details, see [Proof-Carrying Data from Accumulation Schemes](https://eprint.iacr.org/2020/499.pdf), Appendix A.2, where `sg` is called `U`.

		In pickles, what we do is that we "absorb" this commitment `sg` from the previous step while creating a new proof. That is, for example, Step 1 will produce this commitment that is denoted as `acc1` on the diagram, as part of its opening proof, and Step 2 will absorb this commitment. And this "absorbtion" is what Wrap 2 will prove (and, partially, Step 3 will also refer to the challenges used to build `acc1`, but this detail is completely avoided in this overview). In the end, `acc2` will be the result of Step 2, so in a way `acc2` "aggregates" `acc1` which somewhat justifies the language used.
		In pickles, what we do is that we "absorb" this commitment `sg` from the previous step while creating a new proof. That is, for example, Step 1 will produce this commitment that is denoted as `acc1` on the diagram, as part of its opening proof, and Step 2 will absorb this commitment. And this "absorption" is what Wrap 2 will prove (and, partially, Step 3 will also refer to the challenges used to build `acc1`, but this detail is completely avoided in this overview). In the end, `acc2` will be the result of Step 2, so in a way `acc2` "aggregates" `acc1` which somewhat justifies the language used.