From 5a9e9af8283ffadb11cefc10cb389f2afc74f8d6 Mon Sep 17 00:00:00 2001 From: oliveredget <188809800+oliveredget@users.noreply.github.com> Date: Tue, 31 Dec 2024 08:22:02 +0800 Subject: [PATCH 1/6] Fix typo book/src/pickles/diagrams.md --- book/src/pickles/diagrams.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/src/pickles/diagrams.md b/book/src/pickles/diagrams.md index 63783603a6..a2728c7c10 100644 --- 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) From 33094e9858d6f39ecaeb3df520bd6eba41e91561 Mon Sep 17 00:00:00 2001 From: oliveredget <188809800+oliveredget@users.noreply.github.com> Date: Tue, 31 Dec 2024 08:22:08 +0800 Subject: [PATCH 2/6] Fix typo book/src/pickles/overview.md --- book/src/pickles/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/src/pickles/overview.md b/book/src/pickles/overview.md index 7d2d8bdb7a..7ec7f1b98a 100644 --- 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. From a1e6103cdb7d35336b3ec2f36f538014be89667f Mon Sep 17 00:00:00 2001 From: oliveredget <188809800+oliveredget@users.noreply.github.com> Date: Tue, 31 Dec 2024 08:22:14 +0800 Subject: [PATCH 3/6] Fix typo book/src/snarky/kimchi-backend.md --- book/src/snarky/kimchi-backend.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/src/snarky/kimchi-backend.md b/book/src/snarky/kimchi-backend.md index 7ab2e38bb6..5035dc8dec 100644 --- 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 From 2a6085dfd3f52855d4c117435eebab0ff09dba63 Mon Sep 17 00:00:00 2001 From: oliveredget <188809800+oliveredget@users.noreply.github.com> Date: Tue, 31 Dec 2024 08:22:20 +0800 Subject: [PATCH 4/6] Fix typo book/src/snarky/snarky-wrapper.md --- book/src/snarky/snarky-wrapper.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/src/snarky/snarky-wrapper.md b/book/src/snarky/snarky-wrapper.md index 9f652da76b..4a52fbaeb2 100644 --- 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. ``` From 8b4a231f17b0d11e8942306a8da6c8536a50af3e Mon Sep 17 00:00:00 2001 From: oliveredget <188809800+oliveredget@users.noreply.github.com> Date: Tue, 31 Dec 2024 08:22:26 +0800 Subject: [PATCH 5/6] Fix typo book/src/snarky/vars.md --- book/src/snarky/vars.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/src/snarky/vars.md b/book/src/snarky/vars.md index 41fabe82fd..69dced8d78 100644 --- 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: From fc5755dabe92873ab1e73aff41755e8886187eaf Mon Sep 17 00:00:00 2001 From: oliveredget <188809800+oliveredget@users.noreply.github.com> Date: Tue, 31 Dec 2024 08:22:32 +0800 Subject: [PATCH 6/6] Fix typo o1vm/README.md --- o1vm/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/o1vm/README.md b/o1vm/README.md index d8dbd5d3d0..9e728c4ad9 100644 --- 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