From 6a629e3c28e9a36cc5e34b8c4f60adaf37241c32 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Tue, 27 Aug 2024 14:16:41 +0300 Subject: [PATCH 1/3] fix benchmarks.md --- docs/src/fft/benchmarks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/src/fft/benchmarks.md b/docs/src/fft/benchmarks.md index 92dffd142..7d2fd1804 100644 --- a/docs/src/fft/benchmarks.md +++ b/docs/src/fft/benchmarks.md @@ -10,7 +10,7 @@ Three methods of polynomial interpolation were benchmarked, with different input these were run with criterion-rs in a MacBook Pro M1 (18.3), statistically measuring the total run time of one iteration. The field used was a 256 bit STARK-friendly prime field. -All values of time are in milliseconds. Those cases which were greater than 30 seconds were marked respectively as they're too slow and weren't worth to be benchmarked. The input size refers to *d + 1* where *d* is the polynomial's degree (so size is amount of coefficients). +All values of time are in milliseconds. Those cases which were greater than 30 seconds were marked respectively as they were too slow and weren't worth to be benchmarked. The input size refers to *d + 1* where *d* is the polynomial's degree (so size is amount of coefficients). | Input size | CPU Lagrange | CPU FFT | GPU FFT (Metal) | |------------|--------------|-----------|-----------------| From 05039ca422dbcb92cddca420ce1a43914669797e Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Tue, 27 Aug 2024 14:17:39 +0300 Subject: [PATCH 2/3] fix implementation.md --- docs/src/plonk/implementation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/src/plonk/implementation.md b/docs/src/plonk/implementation.md index a06aa61e3..ede032fa9 100644 --- a/docs/src/plonk/implementation.md +++ b/docs/src/plonk/implementation.md @@ -51,7 +51,7 @@ assert!(verifier.verify( )); ``` -Let's brake it down. The helper function `test_common_preprocessed_input_2()` returns an instance of the following struct for the particular test circuit: +Let's break it down. The helper function `test_common_preprocessed_input_2()` returns an instance of the following struct for the particular test circuit: ```rust pub struct CommonPreprocessedInput { pub n: usize, @@ -295,4 +295,4 @@ Check out the following resources to learn more about it. - [What can go wrong (zkdocs)](https://www.zkdocs.com/docs/zkdocs/protocol-primitives/fiat-shamir/#what-can-go-wrong) - [How not to Prove Yourself: Pitfalls of the Fiat-Shamir Heuristic and Applications to Helios](https://eprint.iacr.org/2016/771.pdf) -- [Weak Fiat-Shamir Attacks on Modern Proof Systems](https://eprint.iacr.org/2023/691) \ No newline at end of file +- [Weak Fiat-Shamir Attacks on Modern Proof Systems](https://eprint.iacr.org/2023/691) From 04bbafef8a6ba2bf1b7df416d235c96924485586 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Tue, 27 Aug 2024 14:19:29 +0300 Subject: [PATCH 3/3] fix recap.md --- docs/src/plonk/recap.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/src/plonk/recap.md b/docs/src/plonk/recap.md index c3e0ef0ce..4346d32cf 100644 --- a/docs/src/plonk/recap.md +++ b/docs/src/plonk/recap.md @@ -9,7 +9,7 @@ We use the following notation. The symbol $\mathbb{F}$ denotes a finite field. It is fixed all along. The symbol $\omega$ denotes a primitive root of unity in $\mathbb{F}$. -All polynomials have coefficients in $\mathbb{F}$ and the variable is usually denoted by $X$. We denote polynomials by single letters like $p, a, b, z$. We only denote them as $z(X)$ when we want to emphasize the fact that it is a polynomial in $X$, or we need that to explicitly define a polynomial from another one. For example when composing a polynomial $z$ with the polynomial $\omega X$, the result being denoted by $z' := z(\omega X)$. The symbol $'$ is **not** used to denote derivatives. +All polynomials have coefficients in $\mathbb{F}$ and the variable is usually denoted by $X$. We denote polynomials by single letters like $p, a, b, z$. We only denote them as $z(X)$ when we want to emphasize the fact that it is a polynomial in $X$, or we need to explicitly define a polynomial from another one. For example when composing a polynomial $z$ with the polynomial $\omega X$, the result being denoted by $z' := z(\omega X)$. The symbol $'$ is **not** used to denote derivatives. When interpolating at a domain $H=\{h_0, \dots, h_n\} \subset \mathbb{F}$, the symbols $L_i$ denote the Lagrange basis. That is $L_i$ is the polynomial such that $L_i(h_j) = 0$ for all $j\neq i$, and that $L_i(h_i) = 1$. @@ -38,7 +38,7 @@ The idea here is that the verifier holds some value $x$, say $x=3$. He gives it In the context of PLONK, both the inputs and outputs of the program are considered _public inputs_. This may sound odd, but it is because these are the inputs to the verification algorithm. This is the algorithm that takes, in this case, the tuple $(3, 8, \pi)$ and outputs _Accept_ if the toy program was executed with input $x=3$, some private value $e$ not revealed to the verifier, and out came $8$. Otherwise it outputs _Reject_. -PLONK can be used to delegate program executions to untrusted parties, but it can also be used as a proof of knowledge. Our program could be used by a prover to demostrate that she knows the multiplicative inverse of some value $x$ in the finite field without revealing it. She would do it by sending the verifier the tuple $(x, 0, \pi)$, where $\pi$ is the proof of the execution of our toy program. +PLONK can be used to delegate program executions to untrusted parties, but it can also be used as a proof of knowledge. Our program could be used by a prover to demonstrate that she knows the multiplicative inverse of some value $x$ in the finite field without revealing it. She would do it by sending the verifier the tuple $(x, 0, \pi)$, where $\pi$ is the proof of the execution of our toy program. In our toy example this is pointless because inverting field elements is easily performed by any verifier. But change our program to the following and you get proofs of knowledge of the preimage of SHA256 digests. @@ -444,4 +444,4 @@ $$ This last step is not obvious. You can check the paper to see the proof. Anyway, this is the equation you'll recognize below in the description of the protocol. -Randomness is a delicate matter and an important part of the protocol is where it comes from, who chooses it and when they choose it. Check out the protocol to see how it works. \ No newline at end of file +Randomness is a delicate matter and an important part of the protocol is where it comes from, who chooses it and when they choose it. Check out the protocol to see how it works.