Book: repair links with mdbook-linkcheck (manually)

book/Makefile

@@ -9,20 +9,23 @@ MDBOOK_LINKCHECK_VERSION = 0.7.7
 MDBOOK_MERMAID_VERSION = 0.12.6
 MDBOOK_TOC_VERSION = 0.14.1
 
+
+all: deps check build serve
+
 #
-# use `make deps` to install the dependencies required to serve or build the book
+# Installs the dependencies required to serve or build the book
 #
 
 deps:
 	cargo install "mdbook@$(MDBOOK_VERSION)"
 	cargo install "mdbook-admonish@$(MDBOOK_ADMONISH_VERSION)"
 	cargo install "mdbook-katex@$(MDBOOK_KATEX_VERSION)"
-	# cargo install "mdbook-linkcheck@$(MDBOOK_LINKCHECK_VERSION)"
+	cargo install "mdbook-linkcheck@$(MDBOOK_LINKCHECK_VERSION)"
 	cargo install "mdbook-mermaid@$(MDBOOK_MERMAID_VERSION)"
 	cargo install "mdbook-toc@$(MDBOOK_TOC_VERSION)"
 
 #
-# use `make check` to check if your installed dependencies match what we've listed above
+# Checks if your installed dependencies match what we've listed above
 #
 
 define check_version
@@ -37,21 +40,21 @@ check:
 	$(call check_version,mdbook-toc,$(MDBOOK_TOC_VERSION))
 
 #
-# use `make` to serve the book locally
+# Builds the book
 #
 
-all: check
-	mdbook serve --open
+build: check
+	mdbook build
 
 #
-# use `make build` to build the book
+# Serves the book locally
 #
 
-build: check
-	mdbook build
+serve: check
+	mdbook serve --open
 
 #
-# use `make clean` to clean the generated artefacts
+# Cleans the generated artefacts
 #
 
 clean:

book/book.toml

@@ -33,3 +33,10 @@ command = "mdbook-mermaid"
 [preprocessor.toc]
 command = "mdbook-toc"
 renderer = ["html"]
+
+
+# See docs: https://github.com/Michael-F-Bryan/mdbook-linkcheck
+[output.linkcheck]
+follow-web-links = false
+traverse-parent-directories = false
+warning-policy = "ignore" # At the moment linkcheck overshoots because of latex

book/specifications/kimchi/template.md

@@ -195,7 +195,7 @@ Similarly to the generic gate, each values taking part in a lookup can be scaled
 The lookup functionality is an opt-in feature of kimchi that can be used by custom gates.
 From the user's perspective, not using any gates that make use of lookups means that the  feature will be disabled and there will be no overhead to the protocol.
 
-Refer to the [lookup RFC](../rfcs/3-lookup.md) for an overview of the lookup feature.
+Please refer to the [lookup RFC](../kimchi/lookup.md) for an overview of the lookup feature.
 
 In this section, we describe the tables kimchi supports, as well as the different lookup selectors (and their associated queries)
 

book/src/SUMMARY.md

@@ -7,7 +7,7 @@
 - [Terminology](./fundamentals/zkbook_foundations.md)
 - [Groups](./fundamentals/zkbook_groups.md)
 - [Rings](./fundamentals/zkbook_rings.md)
-- [Fields](./fundamentals/zkbook.md)
+- [Fields](./fundamentals/zkbook_fields.md)
 - [Polynomials](./fundamentals/zkbook_polynomials.md)
   - [Multiplying Polynomials](./fundamentals/zkbook_multiplying_polynomials.md)
   - [Fast Fourier Transform](./fundamentals/zkbook_fft.md)

book/src/fundamentals/zkbook.md → book/src/fundamentals/zkbook_fields.md

@@ -60,7 +60,7 @@ In short, $F$ should be an abelian group over $+$ with $0$ as identity and $\mat
 
 The point of defining a field is that we can algebraically manipulate elements of a field the same way we do with ordinary numbers, adding, multiplying, subtracting, and dividing them without worrying about rounding, underflows, overflows, etc.
 
-> In Rust, we use the trait [`Field`](docs.todo) to represent types that are fields. So, if we have `T : Field` then values of type `T` can be multiplied, subtracted, divided, etc.
+> In Rust, we use the trait `Field` to represent types that are fields. So, if we have `T : Field` then values of type `T` can be multiplied, subtracted, divided, etc.
 
 ### Examples
 
@@ -156,5 +156,3 @@ Actually, on a practical level, it's more accurate to model the complexity in te
 As a result you can see it's the smaller $n$ is the better, especially with respect to multiplication, which dominates performance considerations for implementations of zk-SNARKs, since they are dominated by elliptic curve operations that consist of field operations.
 
 While still in development, Mina used to use a field of 753 bits or 12 limbs and now uses a field of 255 bits or 4 limbs. As a result, field multiplication became automatically sped up by a factor of $12^2 / 4^2 = 9$, so you can see it's very useful to try to shrink the field size.
-
-

book/src/fundamentals/zkbook_ips.md

@@ -4,7 +4,7 @@ Earlier we defined zero-knowledge proofs as being proofs of a computation of a f
 
 We will now go beyond this, and try to define zero-knowledge proof systems for computations that proceed **inductively**. That is, in pieces, and potentially over different locations involving different parties in a distributed manner.
 
-An example of an **inductive computation** would be the verification of the Mina blockchain. Each block producer, when they produce a new block, 
+An example of an **inductive computation** would be the verification of the Mina blockchain. Each block producer, when they produce a new block,
 
 - verifies that previous state of the chain was arrived at correctly
 
@@ -31,7 +31,7 @@ Another way of looking at this is that they let you prove membership in sets of
 $A_f := \{ a \colon A \mid \text{There exists } w \colon W \text{ such that} f(a, w) = \mathsf{true} \}$[^1]
 
 
-These are called [NP sets](todo.link). In intuitive terms, an NP set is one in which membership can be efficiently checked given some "witness" or helper information (which is $w$).
+These are called [NP sets](https://en.wikipedia.org/wiki/NP_(complexity)). In intuitive terms, an NP set is one in which membership can be efficiently checked given some "witness" or helper information (which is $w$).
 
 Inductive proof systems let you prove membership in sets that are inductively defined. An inductively defined set is one where membership can be efficiently checked given some helper information, but the computation is explicitly segmented into pieces.
 
@@ -45,7 +45,7 @@ We will give a recursive definition of a few concepts. Making this mathematicall
 
 
 
-The data of an **inductive rule for a type $A$** is 
+The data of an **inductive rule for a type $A$** is
 
 - a sequence of inductive sets $A_0, \dots, A_{n-1}$ (note the recursive reference to )
 
@@ -59,7 +59,7 @@ The data of an **inductive set over a type $A$** is
 
 The subset of $A$  corresponding to $R$ (which we will for now write $A_R$) is defined inductively as follows.
 
-For $a \colon A$, $a \in A_R$ if and only if 
+For $a \colon A$, $a \in A_R$ if and only if
 
 - there is some inductive rule $r$ in the sequence $R$ with function $f \colon A \times W_r \times A_{r,0} \times \dots A_{r, n_r-1} \to \mathsf{Bool}$ such that
 

book/src/kimchi/final_check.md

@@ -126,7 +126,7 @@ $$
 \end{align}
 $$
 
-here are the actual lagrange basis calculated with the [formula here](lagrange.md), oh and we actually use $L_0$ in the code, not $L_1$, so let's change that as well:
+here are the actual lagrange basis calculated with the [formula here](../plonk/lagrange.md), oh and we actually use $L_0$ in the code, not $L_1$, so let's change that as well:
 
 $$
 \begin{align}

book/src/kimchi/foreign_field_add.md

@@ -15,7 +15,7 @@ If $f < n$ then we can easily perform the above computation. But in this gate we
 - our foreign field will have 256-bit length
 - our native field has 255-bit length
 
-In other words, using 3 limbs of 88 bits each allows us to represent any foreign field element in the range $[0,2^{264})$ for foreign field addition, but only up to $2^{259}$ for foreign field multiplication. Thus, with the current configuration of our limbs, our foreign field must be smaller than $2^{259}$ (because $2^{264} \cdot 2^{255} > {2^{259}}^2 + 2^{259}$, more on this in the [FFmul RFC](https://github.com/o1-labs/rfcs/blob/main/0006-ffmul-revised.md).
+In other words, using 3 limbs of 88 bits each allows us to represent any foreign field element in the range $[0,2^{264})$ for foreign field addition, but only up to $2^{259}$ for foreign field multiplication. Thus, with the current configuration of our limbs, our foreign field must be smaller than $2^{259}$ (because $2^{264} \cdot 2^{255} > {2^{259}}^2 + 2^{259}$, more on this in [Foreign Field Multiplication](../kimchi/foreign_field_mul.md) or the original [FFmul RFC](https://github.com/o1-labs/rfcs/blob/main/0006-ffmul-revised.md).
 
 ### Splitting the addition
 
@@ -155,13 +155,13 @@ So far, one can recompute the result as follows:
 ```text
 bits  0..............87|88...........175|176...........263
 r  =  (-------r0-------|-------r1-------|-------r2-------)
-= 
+=
 a  =  (-------a0-------|-------a1-------|-------a2-------)
 +
 s = 1 | -1
 ·
 b  =  (-------b0-------|-------b1-------|-------b2-------)
-- 
+-
 q  =  -1 |0 | 1
 ·
 f  =  (-------f0-------|-------f1-------|-------f2-------)
@@ -174,13 +174,13 @@ Inspired by the halving approach in foreign field multiplication, an optimized v
 ```text
 bits  0..............87|88...........175|176...........263
 r  =  (-------r0------- -------r1-------|-------r2-------)
-= 
+=
 a  =  (-------a0------- -------a1-------|-------a2-------)
 +
 s = 1 | -1
 ·
 b  =  (-------b0------- -------b1-------|-------b2-------)
-- 
+-
 q  =  -1 |0 | 1
 ·
 f  =  (-------f0------- -------f1-------|-------f2-------)
@@ -193,18 +193,18 @@ f  =  (-------f0------- -------f1-------|-------f2-------)
 $$
 \begin{aligned}
 r_{bot} &= (a_0 + 2^{88} \cdot a_1) + s \cdot (b_0 + 2^{88} \cdot b_1) - q \cdot (f_0 + 2^{88} \cdot f_1) - c \cdot 2^{176} \\
-r_{top} &= a_2 + s \cdot b_2 - q \cdot f_2 + c 
+r_{top} &= a_2 + s \cdot b_2 - q \cdot f_2 + c
 \end{aligned}
 $$
 
-with $r_{top} = r_2$ and $c = c_1$. 
+with $r_{top} = r_2$ and $c = c_1$.
 
 ## Gadget
 
-The full foreign field addition/subtraction gadget will be composed of: 
+The full foreign field addition/subtraction gadget will be composed of:
 - $1$ public input row containing the value $1$;
 - $n$ rows with `ForeignFieldAdd` gate type:
-  - for the actual $n$ chained additions or subtractions;  
+  - for the actual $n$ chained additions or subtractions;
 - $1$ `ForeignFieldAdd` row for the bound addition;
 - $1$ `Zero` row for the final bound addition.
 - $1$ `RangeCheck` gadget for the first left input of the chain $a_1 := a$;
@@ -227,7 +227,7 @@ A total of 20 rows with 15 columns in Kimchi for 1 addition. All ranges below ar
 | 9n+7..9n+10      | `multi-range-check` | $u$     |
 
 
-This mechanism can chain foreign field additions together. Initially, there are $n$ foreign field addition gates, followed by a foreign field addition gate for the bound addition (whose current row corresponds to the next row of the last foreign field addition gate), and an auxiliary `Zero` row that holds the upper bound. At the end, an initial left input range check is performed, which is followed by a $n$ pairs of range check gates for the right input and intermediate result (which become the left input for the next iteration). After the chained inputs checks, a final range check on the bound takes place. 
+This mechanism can chain foreign field additions together. Initially, there are $n$ foreign field addition gates, followed by a foreign field addition gate for the bound addition (whose current row corresponds to the next row of the last foreign field addition gate), and an auxiliary `Zero` row that holds the upper bound. At the end, an initial left input range check is performed, which is followed by a $n$ pairs of range check gates for the right input and intermediate result (which become the left input for the next iteration). After the chained inputs checks, a final range check on the bound takes place.
 
 For example, chaining the following set of 3 instructions would result in a full gadget with 37 rows:
 
@@ -250,7 +250,7 @@ $$add(add(add(a,b),c),d)$$
 | 30..33 | `multi-range-check` | $a+b+c+d$     |
 | 34..37 | `multi-range-check` | bound         |
 
-Nonetheless, such an exhaustive set of checks are not necessary for completeness nor soundness. In particular, only the very final range check for the bound is required. Thus, a shorter gadget that is equally valid and takes $(8*n+4)$ fewer rows could be possible if we can assume that the inputs of each addition are correct foreign field elements. It would follow the next layout (with inclusive ranges): 
+Nonetheless, such an exhaustive set of checks are not necessary for completeness nor soundness. In particular, only the very final range check for the bound is required. Thus, a shorter gadget that is equally valid and takes $(8*n+4)$ fewer rows could be possible if we can assume that the inputs of each addition are correct foreign field elements. It would follow the next layout (with inclusive ranges):
 
 | Row(s)   | Gate type(s)                                          | Witness |
 | -------- | ----------------------------------------------------- | ------- |
@@ -260,7 +260,7 @@ Nonetheless, such an exhaustive set of checks are not necessary for completeness
 | n+2      | `Zero`                                                |         |
 | n+3..n+6 | `multi-range-check` for `bound`                       | $u$     |
 
-Otherwise, we would need range checks for each new input of the chain, but none for intermediate results; implying $4\cdot n$ fewer rows. 
+Otherwise, we would need range checks for each new input of the chain, but none for intermediate results; implying $4\cdot n$ fewer rows.
 
 | Row(s)          | Gate type(s)                                          | Witness   |
 | --------------- | ----------------------------------------------------- | --------- |
@@ -273,7 +273,7 @@ Otherwise, we would need range checks for each new input of the chain, but none
 | 5n+7..5n+10     | `multi-range-check` for bound                         | $u$       |
 
 
-For more details see the Bound Addition section of the [Foreign Field Multiplication RFC](https://github.com/o1-labs/rfcs/blob/main/0006-ffmul-revised.md).
+For more details see the Bound Addition section in [Foreign Field Multiplication](../kimchi/foreign_field_mul.md) or the original [Foreign Field Multiplication RFC](https://github.com/o1-labs/rfcs/blob/main/0006-ffmul-revised.md).
 
 ### Layout
 
@@ -326,4 +326,4 @@ TODO: decide if we really want to keep this check or leave it implicit as it is
 When we use this gate as part of a larger chained gadget, we should optimize the number of range check rows
 to avoid redundant checks. In particular, if the result of an addition becomes one input of another addition, there is no need to check twice that the limbs of that term have the right length.
 
-The sign is now part of the coefficients of the gate. This will allow us to remove the sign check constraint and release one witness cell element. But more importantly, it brings soundness to the gate as it is now possible to wire the $1$ public input to the overflow witness of the final bound check of every addition chain.  
+The sign is now part of the coefficients of the gate. This will allow us to remove the sign check constraint and release one witness cell element. But more importantly, it brings soundness to the gate as it is now possible to wire the $1$ public input to the overflow witness of the final bound check of every addition chain.

book/src/kimchi/foreign_field_mul.md

@@ -610,7 +610,7 @@ $$
 
 ### Bound checks
 
-To perform the above range checks we use the *upper bound check* method described in the [Foreign Field Addition RFC](](https://github.com/o1-labs/proof-systems/blob/master/book/src/rfcs/ffadd.md#upper-bound-check)).
+To perform the above range checks we use the *upper bound check* method described in the upper bound check section in [Foreign Field Addition](../kimchi/foreign_field_add.md#upper-bound-check).
 
 The upper bound check is as follows.  We must constrain $0 \le q < f$ over the positive integers, so
 

book/src/kimchi/maller_15.md

@@ -1,10 +1,10 @@
-# Maller's optimization for kimchi
+# Maller's optimization for Kimchi
 
-This document proposes a protocol change for [kimchi](../../specs/kimchi/kimchi.md).
+This document proposes a protocol change for [kimchi](../specs/kimchi.md).
 
 ## What is Maller's optimization?
 
-See the [section on Maller's optimization](maller.md) for background.
+See the [section on Maller's optimization](../plonk/maller.md) for background.
 
 ## Overview
 
@@ -35,7 +35,7 @@ Note right of Verifier: verifies the evaluation proof \n to check that L(zeta) =
 ```
 -->
 
-In the rest of this document, we review the details and considerations needed to implement this change in [kimchi](../../specs/kimchi/kimchi.md).
+In the rest of this document, we review the details and considerations needed to implement this change in [kimchi](../specs/kimchi.md).
 
 ## How to deal with a chunked $t$?
 
@@ -50,7 +50,7 @@ L = L_0 + x^n L_1 + x^{2n} L_1 + \cdots
 $$
 
 where every $L_i$ is of degree $n-1$ at most.
-Then we have that 
+Then we have that
 
 $$
 com(L) = com(L_0) + com(x^n \cdot L_1) + com(x^{2n} \cdot L_2) + \cdots
@@ -87,7 +87,7 @@ To compute it, there are two rules to follow:
 * when **scaling** a commitment, its blinding factor gets scalled too:
     $$n \cdot com(a) \implies n \cdot r_a$$
 
-As such, if we know $r_f$ and $r_t$, we can compute: 
+As such, if we know $r_f$ and $r_t$, we can compute:
 
 $$
 r_{\tilde L} = r_{\tilde f} + (\zeta^n-1) \cdot r_{\tilde t}
@@ -130,7 +130,7 @@ $$
 \end{align}
 $$
 
-Because we use the [inner product polynomial commitment](../../specs/polynomial_commitment.md), we also need:
+Because we use the [inner product polynomial commitment](../plonk/polynomial_commitments.md), we also need:
 
 $$
 \tilde L(\zeta \omega) = \tilde f(\zeta \omega) - Z_H(\zeta) \cdot \tilde t(\zeta \omega)
@@ -156,8 +156,8 @@ Prover->Verifier: com(t) (several of them)
 Note right of Verifier: generates random point zeta
 Verifier->Prover: zeta
 Prover->Verifier: L_bar(zeta * omega) = y
-Prover->Verifier: proof that L_bar(zeta) = 0 
-Prover->Verifier: proof that L_bar(zeta * omega) = y 
+Prover->Verifier: proof that L_bar(zeta) = 0
+Prover->Verifier: proof that L_bar(zeta * omega) = y
 Note right of Verifier: produces com(L_bar)
 Note right of Verifier: verifies the evaluation proof \n to check that L_bar(zeta) = 0
 ```

book/src/pickles/accumulation.md

@@ -3,7 +3,7 @@
 ## Introduction
 
 The trick below was originally described in [Halo](https://eprint.iacr.org/2020/499.pdf),
-however we are going to base this post on the abstraction of "accumulation schemes" described by Bünz, Chiesa, Mishra and Spooner in [Proof-Carrying Data from Accumulation Schemes](/https://eprint.iacr.org/2020/499.pdf), in particular the scheme in Appendix A. 2.
+however we are going to base this post on the abstraction of "accumulation schemes" described by Bünz, Chiesa, Mishra and Spooner in [Proof-Carrying Data from Accumulation Schemes](https://eprint.iacr.org/2020/499.pdf), in particular the scheme in Appendix A. 2.
 
 Relevant resources include:
 
@@ -767,7 +767,7 @@ Note that the accumulator verifier must be proven (in addition to the Kimchi/Plo
 
 Note that the "cycles of curves" (e.g. Pasta cycle) does not show up in this part of the code:
 a <u>separate accumulator</u> is needed for each curve and the final verifier must check both accumulators to deem the combined recursive proof valid.
-This takes the form of [`passthough` data](passthrough.html) in pickles.
+This takes the form of `passthough` data in pickles.
 
 Note however, that the accumulation verifier makes use of both $\GG$-operations and $\FF$-operations,
 therefore it (like the Kimchi verifier) also requires [deferred computation](deferred.html).