The ultimate goal of the sum-check protocol in SNARK design is to reduce a claim made by a prover to a set of operations that can be executed efficiently by a corresponding verifier. In this article, we will learn the inner workings of the sum-check protocol while also touching on its practical applications.

Hypothetical Context

Before we drill into the mathematical definition of the sum-check protocol, lets try to understand the protocol at a high level in the context of a hypothetical arithmetic circuit, a prover P and a verifier V.3

P wants to convince V that some circuit was executed correctly with a specific witness and that they know a multivariate polynomial f which represents this execution. The polynomial f was derived from an algebraic representation of the circuit which contains M constraints and N variables. Somehow, V must be convinced that f is the reduction of M many constraint polynomials that evaluate to 0 when paired up with their corresponding variables from the execution trace.

Because we want our interactive proof to be succinct,4 we need V’s runtime to be much more efficient than the runtime exhibited by P’s construction of the proof for f. This efficiency can be achieved through the sum-check protocol, which allows P’s claim about M constraints to be reduced to a single claim about a random linear combination of those constraints. The randomness in this linear combination is provided by V and it allows the protocol to leverage the probabilities involved in the Schwartz-Zippel lemma which we have covered extensively in previous articles.

If the number of constraints M is equal to 2ᵐ, then the sum-check protocol involves m many rounds of interaction between P and V.5 V must also compute an evaluation of f at the end of the protocol, meaning that V’s runtime is O(m+z) where z is the cost to evaluate f at a single input in the relevant field. This is a drastic improvement from O(2ᵐ) which is P’s runtime when computing the polynomial f.

The Protocol

Now that we have some high level context for the sum-check protocol in SNARKs, lets define the protocol precisely as an interactive proof.

As above, the prover P has a v-variate polynomial f defined over a finite field Fp.

P claims to know the sum of the evaluations of all Boolean inputs (the Boolean hypercube) over f.6

P sends this sum S to V.

The remainder of the protocol is designed to reach a stage where V can confirm the correctness of S, to a sufficiently high probability of success, through a single evaluation of f. To reach this final stage however, V and P must execute v rounds of communication, each of which involve a single low degree univariate polynomial derived from f.

The v number of rounds of the protocol proceed as follows.

Round 1

Firstly, P sends the univariate polynomial g₁(X₁) which is claimed to be the sum of f over a subset of the entire set of variables, namely (x₂,…,xᵥ):

Lets compare this equation to the one for S. The difference is that the first variable x₁ of our v-variate polynomial has been replaced with a fixed variable X₁. The value of X₁ in our domain is either 0 or 1, so V is able to verify the following:

At this point, V has been able to compute the claimed sum of f over the Boolean hypercube much more efficiently than P did. However, V is not yet convinced that the claimed sum is in fact the correct sum. The remainder of the protocol will allow V to be convinced of the correctness of S.

V must also check that g₁ is a univariate polynomial of degree less than or equal to the degree of x₁ in f.

V then selects a random element r₁ from Fp and sends it to P.

Remaining Rounds

The process from round 1 is repeated for all remaining variables (x₂,…,xᵥ).

For each of the ith rounds, P sends a univariate polynomial gᵢ(Xᵢ) claimed to equal:

V checks that gᵢ is a univariate polynomial of degree less than or equal to the degree of xᵢ in f.

V checks that the evaluation of the previous univariate polynomial and corresponding random element is equal to the sum of evaluations of gᵢ over Boolean inputs for Xᵢ:

V selects another random element rᵢ from Fp and sends it to P.

Final Round

During the final round, V will gain access to gᵥ which is confirmed to be a univariate polynomial of sufficiently low degree equal to:

V then selects a final random element rᵥ and confirms the following equality:7

If this check succeeds, then V is convinced as to the correctness of P’s original statement that the evaluation of f over all Boolean inputs is equal to S.

Minimal Worked Example

Lets walk through a worked example of the sum-check algorithm to improve our understanding of the protocol.

We define the multivariate polynomial f as follows:8

The sum of the evaluations of f over the Boolean hypercube is S=18:

The first univariate polynomial g₁ provided by the prover is as follows:

The verifier checks that g₁ is a univariate polynomial of degree at most 1 and that the sum of its evaluations over Boolean inputs is equal to S=18.

The verifier selects a random r₁=3. The prover responds with a second univariate polynomial g₂:

The verifier checks that g₂ is a univariate polynomial of degree at most 2 and that the sum of its evaluations over binary inputs is equal to g₁(r₁):

The verifier selects a random r₂=2. The prover responds with a third univariate polynomial g₃:

The verifier checks that g₃ is a univariate polynomial of degree at most 3 and that the sum of its evaluations over binary inputs is equal to g₂(r₂):

The verifier selects a random r₃=1 and confirms that f(r₁,r₂,r₃)=g₃(r₃):

After this final check, the verifier is convinced that the original claim by the prover that S=18 is in fact correct.

Example in Rust

The above worked example can be executed from the Rust crate found here:

$ cargo run -p sumcheck

Defined:        f   = a + 2b^2 + 3ac^3
Round 1:        g_1 = 4 + 10x   r_1 = 3 
Round 2:        g_2 = 15 + 4x^2 r_2 = 2 
Round 3:        g_3 = 11 + 9x^3 r_3 = 1 
Finalized:      g_3(r_3) = 20

The crate is factored to be an approachable learning resource. For example, instead of random values, the code uses the r₁, r₂, and r₃ from the worked example above. The protocol round functions are also factored to reflect the iterative breakdown covered in this article. So if you are interested in getting a better understanding of the protocol, a look into the code and its explanatory comments should be very helpful.

Sum-Check in Snark Design

Justin Thaler refers to the sum-check protocol as a “hammer in the design of efficient interactive proofs”.9 In Chapter 4 of the book, Thaler shows how the sum-check protocol can be used to implement application-specific interactive proofs. This includes interactive proofs for triangle counting, matrix multiplication, and Boolean circuit satisfiability.

The sum-check protocol is leveraged by modern SNARKs both as a fundamental component to GKR and as a stand-alone building block in its own right.

In this article, we will unpack how MLE works and how it can be implemented, while also touching on the significance of MLE in the context of interactive proofs.

Multivariate Functions

We are now concerned with multivariate functions defined over the v-variate domain {0,1}ᵛ . This domain contains 2ᵛ unique Boolean tuples.

For example, f ( x_1, x₂ ) is a bivariate function where v=2 and the domain is {0,1}²:

And f ( x_1, x_{2, …,} x_v ) is a v-variate function whose domain contains 2ᵛ unique tuples.

These functions map Boolean tuples to elements in a finite field:

Importantly, every such function has an extension polynomial that is multilinear.

Multilinear Polynomials

In a multilinear polynomial, every variable is of degree at most 1. The total degree of a polynomial is the sum of the degrees of the variables in the highest-degree term.

So, for example, the following MLE of f ( x_1, x₂ ) over {0,1}² has a total degree of 2 due to the final term being composed of both x₁ and x₂:

Since the highest-degree term of a multilinear polynomial can only involve v Boolean variables, its total degree cannot be greater than v. This means that the total degree of a MLE of a multivariate function is logarithmic to the domain size, 2ᵛ.

Remember that univariate low-degree extension required polynomials of degree n-1 which was linear to the domain size, n. As such, MLEs can be leveraged for the purposes of SNARK design in different ways to their univariate counterparts.

The Boolean Hypercube

Another way of describing our multivariate function is in relation to a Boolean hypercube. Specifically, our function maps a v-dimensional Boolean hypercube to a finite field element.

A Boolean hypercube is a geometric representation of the set of all Boolean tuples of a given length. The hypercube represents the domain {0,1}ᵛ which consists of all possible Boolean tuples of length v. We can visualize the cube as a graph in which each vertex corresponds to a Boolean tuple and is connected to another tuple that differs by a single bit. The distance between two vertices is the number of bit positions that the two tuples differ at (the Hamming distance).

The 3-dimensional Boolean hypercube can be visualized as follows:

             000---------001
            / |          / |
           /  |         /  |    3-Dimensional Boolean Hypercube:
          010--------011   |    {000,001,010,011,100,101,110,111}
          |   |        |   |    
          |   100------|-101
          |  /         |  /
          | /          | /
          110--------111

Notice that in the domain of {0,1}³, each vertex in the Boolean hypercube has 3 edges and the maximum Hamming distance is also 3.

When we compute the MLE of some multivariate function, we compute it over the Boolean hypercube that represents the input domain.

Extension of the Multivariate Function

As mentioned above, every multivariate function, f(x), that maps the v-dimensional Boolean hypercube to a finite field has a unique corresponding multilinear extension polynomial. The extension polynomial evaluates identically to f(x) for every Boolean tuple from the hypercube. However, the extension polynomial’s domain is Fᵛ rather than 2ᵛ because it has evaluations for every tuple in {0,1,2,…,|F|-1}ᵛ.As such, g(x) is a distance-amplifying encoding of f(x).

As always, distance-amplification allows us to exploit the probabilities involved in the Schwartz-Zippel lemma for the purposes of interactive proofs. With respect to multivariate polynomials over finite field F, the Schwartz-Zippel lemma states that any two distinct polynomials of total degree at most d can agree on at most d/|F| inputs. So if two multivariate functions over the domain {0,1}ᵛ disagree at even a single input, then any extensions of those functions of total degree at most d must differ virtually everywhere, given that d is much smaller than |F|.

Lagrange Interpolation of Multilinear Polynomials

Just as we did for univariate low-degree extension in the previous article, we can use Lagrange interpolation to perform MLE of some multivariate function.

Recall that basis polynomials are designed to evaluate to 1 for one particular input and 0 for all other possible input. Just as with the univariate approach, the algorithm involves a linear combination of basis polynomials. But this time, we create a basis polynomial for every (Boolean) variable in the multivariate function.

The MLE of f is the sum of all multilinear Lagrange basis polynomials with interpolating set {0,1}ᵛ, weighted by the evaluation the respective element from the interpolating set:

For every Boolean tuple w in {0,1}ᵛ, we multiply its evaluation under f with the set of multilinear Lagrange basis polynomials interpolated by the Booelan variables in w.

To evaluate the set of interpolated basis polynomials, we pair each Boolean tuple w with a tuple x. Because we intend to evaluate x over the MLE of f, the tuple x has a domain of {0,1,…|F|-1}ᵛ. For each pair, we evaluate an equation that will yield 1 when the i’th variables of w and x are equal and 0 if they are unequal while x is inside the domain of {0,1}ᵛ. This equation is repeated for every variable in w and x and the results are multiplied together:

As you can see, the above algorithm allows us to evaluate some field element under the MLE of f through the use of multilinear Lagrange interpolation. Now lets apply the algorithm to a simple example.

We define a bivariate function over the domain {0,1}²:

The MLE of the bivariate function is then:

Notice that each of the four terms on the right hand side of the equation ensures that the MLE evaluates equally to our predefined values for the bivariate function:

Now that we have observed the patterns at play, lets replace the variables a, b, c, and d with actual evaluations1 of f and see what the corresponding MLE looks like over a finite field Fp where p=5:

Given the above evaluations, our MLE equation is:

Which we can simplify to:

So our MLE over Fp, where p=5, looks like this:

With the above example, we can observe the distance-amplification of MLEs and understand how it was achieved. To further improve our understanding, we can look at how this algorithm can be implemented in Rust. A simple implementation of the algorithm for educational purposes is available here. Running the MLE package will execute the working example we covered above:

$ cargo run -p mle

Computed f(w) over the hypercube {0,1}^2:
f[0, 0] -> 1
f[0, 1] -> 2
f[1, 0] -> 3
f[1, 1] -> 4

Computed MLE(x) for every x in Fp:
1 2 3 4 0 
3 4 0 1 2 
0 1 2 3 4 
2 3 4 0 1 
4 0 1 2 3 

Multilinear Polynomials in SNARK Design

Today, the most common approaches to SNARK design tend to involve some combination of a polynomial interactive oracle proof (IOP), a polynomial commitment scheme, and the Fiat-Shamir transformation.2 The polynomial commitment scheme transforms the IOP into succinct interactive arguments while the Fiat-Shamir transformation renders the arguments non-interactive and publicly verifiable.

Some polynomial IOP approaches leverage multivariate polynomials while others rely on univariate ones. Univariate polynomial commitment schemes can be transformed into multivariate ones at the expense of some computation.

The sum-check protocol is an interactive proof protocol which provides a means of designing efficient polynomial IOPs using multivariate polynomials. In the sum-check protocol, the verifier forces the prover to sum up all the evaluations of a multivariate polynomial over a Boolean hypercube. If you have read this article to completion, this should sound like a very familiar procedure to you.

In the next article, we will explore the sum-check protocol for interactive proofs.

Previously, we treated the values of the input vectors as coefficients to a univariate polynomial of degree n-1. It turns out that, in the context of interactive proofs and arguments of knowledge, it can actually be more useful to treat those values as evaluations of some polynomial rather than its coefficients.

From Coefficients to Evaluations

Lets illustrate the differences between treating our input elements as evaluations as opposed to coefficients of a polynomial with a simple worked example. Say we have an input vector a where n=4:

The Reed-Solomon encoding interprets a as the following polynomial:

Then we can achieve a distance amplified encoding of the original vector by evaluating its corresponding polynomial over a field of prime order p. In the past we mentioned that p should be a prime bigger than n², so lets say p=67. Then the Reed-Solomon encoding of a in Fp is:

Now, if we instead treat a as evaluations of a univariate polynomial over some canonical input set, our encoded vector must look something like this:

Notice that the encoded vector is a superset of the input. As such, the encoding can be thought of as an extension of the input vector. Soon we will see that it is specifically a low-degree extension of a, or LDE(a),1 and that low-degree extensions are actually more useful in the context of interactive proofs than our previous Reed-Solomon encodings. But how do we find this polynomial that corresponds to the evaluations found in LDE(a)? We do this through Lagrange interpolation.

Before we explain Lagrange interpolation, lets restate the context a little more formally. Paraphrasing lemma 2.3 from section 2.4 of Proofs, Arguments, and Zero-Knowledge: let p be a prime larger than n and Fp be the field of integers modulo p. For any vector a that is a subset of integers less than or equal to n in Fp, there is a unique univariate polynomial of degree at most n-1 such that:

This formula relates to the following definition of the input vector a:

All that we are saying here is that there exists a unique univariate polynomial which, given some list of canonical inputs, evaluates to the values found in LDE(a).2 We will show that this polynomial can be constructed as a linear combination of Lagrange basis polynomials. But first, we need to understand what a Lagrange basis polynomial is.

Univariate Lagrange Interpolation

In order to find the polynomial that evaluates the canonical input, (0,1,…,n-1), to LDE(a), we need to perform a linear combination of a set of Lagrange basis polynomials. We need a basis polynomial for every element in the canonical input.

Conceptually, a Lagrange basis polynomial is designed to map a single element of the canonical input to 1 and all others to 0. Specifically, the i’th Lagrange basis polynomial maps i to 1 and all other elements to 0. With that understanding, we can try digesting the following formula for Lagrange basis polynomials:

At face value it is probably unclear as to how this formula achieves the mapping we described above. For now, just trust that it does; when we go on to do the worked example, we will elaborate on this.

Next, we define our interpolated polynomial as the linear combination of the basis polynomials:

This simply means that the polynomial which evaluates each canonical input element to an element in LDE(a) is equivalent to the sum of all of our Lagrange basis polynomials weighted by their respective evaluations.3

Now lets do a simple worked example and build an intuition around why this makes sense. If n=4, then our basis polynomials behave as follows.

The first basis polynomial ensures that the evaluation is 1 when x=0. And that the evaluation is 0 when x is any of the remaining elements of the canonical input domain (1, 2, and 3).

The second basis polynomial does the same for i=1.

And the third and fourth basis polynomials do the same for i=2 and i=3, respectively.

Lets evaluate the fourth basis polynomial to make sure we understand whats going on here. When x=3:

Obviously, when the numerator and denominator are equal and non-zero, the result is 1. This is the case whenever x=i , due to this part of the basis polynomial formula:

Another way to put this is that the denominator normalizes the linear factor x-k. This normalization ensures that when all these terms are multiplied together, the resulting polynomial will evaluate to 1 when x=i.

When x is any element from the canonical input domain other than 3, say 1:

Then the result must clearly be 0. This is because one of the n-1 factors in the equation will always evaluate to 0 when x is not the i’th element.

So now we should have an intuition as to why basis polynomials evaluate to 1 and 0 when they need to. Here is a plot of the four basis polynomials:4

Notice that each x value that corresponds to an element in our canonical input relates to either a 0 or 1 y value. The next question you might ask is why a linear combination of the Lagrange basis polynomials results in the polynomial LDE(a).

Linear Combination of Basis Polynomials

Recall that the linear combination of the Lagrange basis polynomials is the sum of all the basis polynomials weighted by their respective evaluations. Lets break this out in our worked example from above, which involved the vector a=(0,1,2,0):5

This reduces to the following equation:

And if we plot this equation, it should look like an interpolation of our four basis polynomials:

Take a moment to verify that this polynomial satisfies our LDE(a) which looks like this:

While we can only verify the first four evaluations this way, we know that the interpolated polynomial is unique. Any two distinct polynomials of degree at most n-1 can agree on at most n-1 inputs. Since we created our polynomial from n inputs, there cannot be two distinct polynomials of degree at most n-1 that satisfy the equation.

If you are curious as to the full evaluation of LDE(a) or you want to walk through an educational implementation of the algorithm in Rust, you can use this. Running the relevant package will execute the worked example from above:

$ cargo run -p lagrange
    a = [0, 1, 2, 0]
LDE(a)= [0, 1, 2, 0, 59, 42, 13, 36, 41, ..., 2]

To conclude, we have used Lagrange interpolation to construct a low-degree extension of our n-sized vector a. The low-degree extension allows us to leverage those same probabilities we used in the previous articles with Reed-Solomon encoding due to the Schwartz-Zippel lemma. However, all of the techniques so far have resulted in polynomials of a maximum degree of n-1. This linear relationship between input size and polynomial degree is something that determines the utility of such techniques in the context of interactive proofs.

Multilinear Extension

In contrast to univariate low-degree extension which produces polynomials whose degree scales with input size, multilinear extension can produce polynomials whose total degree is logarithmic to the domain size. So, for example, if the domain of our elements is 2³², then the total degree of the multilinear extension is 32. Because their degree does not scale with input size, multivariate polynomials of ultra-low degree can be more practical than their univariate counterparts for various use cases.

We will explore multilinear extension and other techniques involved in interactive proofs in future articles.

It turns out that we can also use Reed-Solomon encoding to reduce the computational cost of certain algorithms. Freivald’s algorithm is one such algorithm which can be used to verify that the result of a matrix multiplication is correct in less time than the fastest known deterministic algorithm.

Freivald’s Algorithm

We have three n × n matrices - A, B, and C. The matrices are over a finite field Fp where p > n². We want to verify that C = A⋅B in a more efficient manner than the fastest known deterministic algorithm which runs in worse than O(n²) time.

The algorithm starts by selecting a random element, r, from the finite field, Fp. We then produce a vector of field elements, x, which will allow us to treat the rows of the matrices as univariate polynomials1:

We then want to evaluate the following which will allow us to conclude that C is (probably) equal to A⋅B:

Why does this perform better than just evaluating A⋅B - C = 0? Because multiplying a matrix by a vector yields a vector:

Observe that the resulting vector looks like a univariate polynomial. Again, if you prefer to think in code, you can use this as a playground:2

use ndarray::{arr2, Array1};

fn main() {
    // A and B
    let a = arr2(&[[4, 0, 0], [0, 3, 0], [0, 0, 2]]);
    let b = arr2(&[[1, 0, 0], [0, 2, 0], [0, 0, 3]]);
    // C = A . B
    let c = arr2(&[[4, 0, 0], [0, 6, 0], [0, 0, 6]]);

    // Select a random r and generate x = (r^0, r^1, r^2)
    let n = 3u32;
    let r = 2u32;
    let x: Array1<_> = (0..n).map(|i| r.pow(i)).collect();

    // Check that Cx = A . B x
    let cx = c.dot(&x);
    let bx = b.dot(&x);
    let abx = a.dot(&bx);
    assert_eq!(cx, abx);
}

The matrix and vector multiplication operation can be thought of as performing Reed-Solomon encoding of every row of the matrix. Whereas in the previous article we reduced a vector into a single field element, in Freivald’s algorithm, we are reducing some number of matrices into vectors of field elements. Both techniques can be thought of as reducing the problem of comparing large data sets to a comparison of Reed-Solomon fingerprints because both are subject to the same probabilities. This is to say that the Schwartz-Zippel Lemma for the special case of univariate polynomials applies here:

Two unequal polynomials of degree at most n, with coefficients in some finite field Fp, can evaluate to the same field element from the same input for at most n values in Fp.

Applying this lemma to our problem means that if C is not in fact equal to A⋅B, then the chance that the polynomials represented by Cx and A⋅Bx evaluate to the same field element is (n-1)/p.3 So if Cx and A⋅Bx end up being equal, we have a 1-(n-1)/p probability of correctly concluding that C = A⋅B. By ensuring that p is sufficiently large, we can increase our chance of correctness to a sufficient degree.

As such, we can view Freivald’s algorithm as a probabilistic proof system where the proof is the matrix C and the verification procedure is the evaluation of Cx = A⋅Bx which has O(n²) time complexity.

To conclude, we have now observed two probabilistic techniques that reduce runtime and communication costs of algorithms by transforming input data into distance-amplified encodings. This distance amplification moves the problem space into a domain of sufficiently high order such that the probabilities involved in the Schwartz-Zippel lemma allow us to efficiently verify equality of two arbitrarily sized values from the input domain.

So far, we have treated elements from our input vector as coefficients to a polynomial over a finite field:

Which can be Reed-Solomon encoded over a finite field for the purpose of distance amplification:

In the next article, we will look at an alternate approach which instead treats these elements as evaluations of a univariate polynomial over some canonical set of inputs. We will then explore how Lagrange interpolation can be used to derive this univariate polynomial for the purposes of our proof systems.

We begin with chapter 2 as this is where the book itself begins technical analysis of proving systems.

Reed-Solomon Fingerprinting

Chapter 2 of Thaler’s book is entitled The Power of Randomness. It explores how a probabilistic procedure can be used to maximize the efficiency of communication required to verify equality of some data held by two independent parties. These parties are, naturally, called Alice and Bob.

Alice and Bob want to verify that they possess the same ASCII encoded file. The file could be very large. Its size in characters is denoted by n.

No deterministic procedure can be used to communicate less information than the trivial solution of sending Alice’s file to Bob. However, a randomized procedure can be used to reduce communication cost exponentially; so long as this procedure has negligible probability of producing an incorrect result.

One such such procedure involves creating a short “fingerprint” of Alice’s file. This fingerprint approximates a unique identifier to a sufficiently high degree. In order to produce the fingerprint, we use a hash function.1

For the purposes of the hash function, we select a prime number, p, greater than n².2 This is because we want all arithmetic to be done in a finite field, Fp, which can represent at least as many integers as there are elements in the input’s domain. Our input is Alice’s ASCII encoded file, so the input domain has 128 elements:

Whereas the finite field has at least 128² elements:

Alice selects a random field element, x, from this finite field:

The hash function interprets its input as the coefficients of a univariate polynomial of degree n-1, and outputs the polynomial evaluated at x.3 The polynomial represents a Reed-Solomon encoding of the input vector. Ultimately we want to evaluate this polynomial so that we can send the result to Bob:

If you prefer to think in code, you can take a look at my rough implementation of this here. It involves a fair bit of boilerplate for the FieldElement type and its arithmetic operations so here is a snippet of the most relevant parts:

fn hash(a: &[FieldElement], x: FieldElement) -> FieldElement {
    a.iter()
        .enumerate()
        .fold(FieldElement::new(0, x.modulus), |y, (i, &a)| {
            y + a * x.pow(i as u64)
        })
}

fn main() {
    let n = 128u64;
    let p = n.pow(2);
    let a: Vec<FieldElement> = (1..=n).map(|a| {
        FieldElement::new(a, p)
    }).collect();
    let x = FieldElement::new(511, p);
    let y = hash(&a, x);
    println!("h(a, x={x}, p={p}) = {y}");
}

The communication protocol is that Alice picks a random element x from the finite field, executes the above-defined hash function on the series of ASCII characters and sends Bob the output, y, along with x. Bob executes the same hash function with x and his file and compares his output to that of Alice’s.

If Bob’s y matches Alice’s, Bob resolves that the results would be equal for every possible choice of x. This is a deterministic corollary based on the nature of the hash function’s equation we mentioned above - if all coefficients match, it doesn’t matter which field element you specify for x. However, to understand why Bob can conclude that the files are not equal on the basis of unequal y values, we need to understand the probabilities at play.

Two unequal polynomials of degree at most n, with coefficients in some finite field Fp, can evaluate to the same field element from the same input for at most n values in Fp.4 So the probability that Alice picks an x which evaluates to the same y for two unequal polynomials is (n-1)/p. If p is sufficiently large, then the chance of this happening is negligible.

We can visualize this low probability with a simple example. Lets take a look at a representation of two small vectors as polynomials over real numbers.5 Each vector contains only four elements so their corresponding polynomials are of degree 3 at most.

Observe that the polynomials only share one equal evaluation for x. But there are many more unequal evaluations. The same is true for our protocol where we use polynomials over a finite field. The number of unequal valuations depends on the finite field because it determines the size of our domain. The larger the p compared to the degree of the polynomials, the greater the disparity between equal and unequal evaluations grows. This is why we chose p to be at least n² earlier.

So when Bob observes a discrepancy between his output and that of Alice’s, he knows that Alice could not have selected an x which evaluates to the same y across two unequal polynomials. The chance that Bob’s conclusion is correct is 1-(n-1)/p. And because we specified that p>=n² we know that this is at least 1-1/n.

Because the protocol only involves communication of two field elements (x and y), we are able to achieve an exponential improvement in communcation over the deterministic approach.

To conclude, we saw that there is a relationship between the finite field’s order, p, and the length of the input, n which affects the probabilities relied on by our protocol. We also saw that the input domain (128 ASCII characters) is treated as a subset of the finite field; meaning the procedure involves an extension of the input domain.

Now we can start to understand how we can use polynomials over finite fields to provide probabilistic solutions to problems that would otherwise require impractical, deterministic approaches.

In the next article we will explore the remainder of chapter 2 which constructs more sophisticated probabilistic procedures through Freivald’s algorithm and Lagrange interpolation.

Go developers are well aware of how the built-in panic and recover funcs behave. But most of us haven’t dug into the Go source to understand why they behave the way they do. Why does recover need to be a defer call? Why is a panic only recoverable within the goroutine it occurred? To answer these questions, we need to understand the Go runtime.

The Go Runtime

The Go runtime is composed of code to be executed (goroutines), OS threads, and runtime resources such as scheduler and memory allocator state. The Go source refers to these in the runtime pkg as G, M, and P, respectively. Each M has a system stack associated with it (referred to as g0 in the source). The Go runtime executes on the user stack unless making explicit calls to mcall or systemstack funcs. The behaviour of getg can also tell us when the runtime is executing on user or system stack.

Each goroutine has a user stack associated with it and, importantly, all values of the panic struct reside on this stack.

Panic and Recover in the Go Runtime

Panics are initiated via the gopanic func. Panic structs are simply initialized with the argument supplied to the panic() call:

var p _panic
p.arg = e

If the panic occurred on a user stack, the panic procedure begins here with reference to the caller's program counter and stack pointer:

p.start(getcallerpc(), unsafe.Pointer(getcallersp()))

The goroutine is assigned a panic reference from the panic struct’s start() method here:

gp._panic = (*_panic)(noescape(unsafe.Pointer(p)))

After this, the user stack is unwound while looking for deferred function calls. If a stack frame with deferred func calls is found, the panic struct is assigned the relevant pointers for the continued unwinding and recovery process. The stack unwinding executes on the system stack here:

func (p *_panic) nextFrame() (ok bool) {
...
gp := getg()
...
	systemstack(func() {
...
		var u unwinder
		u.initAt(p.lr, uintptr(p.fp), 0, gp, 0)
...
		p.lr = u.frame.lr
		p.sp = unsafe.Pointer(u.frame.sp)
		p.fp = unsafe.Pointer(u.frame.fp)

The panic process then calls all the deferred funcs from the relevant stack frame here.

for {
	fn, ok := p.nextDefer()
	if !ok {
		break
	}
	fn()
}

Eventually, the nextDefer func will return the builtin recover() func which is implemented here, as gorecover(). The first thing that gorecover() does is get a reference to the relevant panic:

func gorecover(argp uintptr) any {
...
	gp := getg()
	p := gp._panic

The panic struct contains an argument pointer of the topmost deferred function call (p.argp, assigned in nextDefer() here). The gorecover() func checks that its caller has matched this pointer and executes the recover by returning the argument supplied to the panic call (p.arg, which was assigned to the panic in gopanic() here).

if p != nil && !p.goexit && !p.recovered && argp == uintptr(p.argp) {
	p.recovered = true
	return p.arg
}

Once the panic is in a recovered state (p.recovered), it will begin a recovery process on the system stack whereby the Go runtime ensures that the caller of the recovered func receives results as if the panic had never happened.

Summarising the Source

The source we covered above is overwhelming on first pass. The key takeaways are the following:

• The Go runtime executes goroutines (G) on OS threads (M);

• Goroutines have their own user stack space;

• The Go runtime manages panic instances with reference to values on the panicking goroutines’ stack space;

• The Go runtime uses the system stack to unwind the user stack frames;

• The Go runtime executes deferred funcs during the stack unwinding process; and

• The Go runtime initiates a “recovery” process if one of the deferred funcs was the built-in recover().

Now that we have an understanding of what happens under the hood, lets see it in action!

Using the Assembler

We can look at assembly of Go programs using godbolt.org. Here is a simple program that panics:

package main

func proc() {
    defer func() {
        if r := recover(); r != nil {
            println(r)
        }
    }()
    panic(1)
}

func main() {
    proc()
}

If we look at the assembly of this program, we can see the expected runtime calls we covered above.

proc_pc0:
...
        CALL    runtime.gopanic(SB)
...
        CALL    runtime.deferreturn(SB)

proc_func1_pc0:
...
        CALL    runtime.gorecover(SB)

The compiler inserts a call to deferreturn at the end of all funcs make defer calls. This func uses the panic struct for its purposes, but it has a different flow to the one we covered above.

The SB (static-base pointer) symbol is a virtual register that points to the beginning of the address space of the program. This symbol can be used to jump to function addresses, which is what the CALL instructions above are doing. If you are interested in understanding the Go assembler in greater detail, go.dev provides this primer.

Thanks!

Thanks for taking your time to read this article. This article was initially intended as an addendum to the Panic, Recover, and Relax (in Go) article published beforehand. However, while digging into the implementation inside the Go runtime, it became clear that there was a lot to explain!

Panic at the Disc-Go

We have all encountered panics when writing Go programs:

Panic is a built-in function that stops the ordinary flow of control and begins panicking. When the function F calls panic, execution of F stops, any deferred functions in F are executed normally, and then F returns to its caller. To the caller, F then behaves like a call to panic. The process continues up the stack until all functions in the current goroutine have returned, at which point the program crashes. Panics can be initiated by invoking panic directly. They can also be caused by runtime errors, such as out-of-bounds array accesses.1

Panics are required when there is simply no alternate behaviour for the relevant stack to exhibit. However, crashing our entire application abruptly may be undesirable for our system and our users. For example, web server frameworks will recover from panics caused by user-defined handler stacks so that a concurrent panic only affects a single request. See Gin's default recovery middleware for example.

Panics can only be recovered from within the goroutine that the panic occurred. This is because the Go runtime causes the entire process to exit when the panicking goroutine's stack has been completely unrolled.

So if we import a third party module that runs its own goroutines, there is simply no way we can stop our application from crashing if those goroutines panic. However, most third party modules probably don’t control concurrency themselves. Arguably they shouldn’t, and don’t need to, control concurrency when being reused by other projects; there is always a level of abstraction that can allow for other users to import your code and control concurrency for themselves. Anywho, thats not important right now. But that stance on concurrency is perhaps enough for us to justify further exploration of how we can build Go applications that guarantee panic recovery. So please indulge me on this.

By the way, if you are interested in digging into how panic and recover are implemented in the Go runtime, check out the companion article here.

Convincing Go to Relax

A single panic doesn’t need to end an entire application abruptly. We can (if desired) recover and shutdown gracefully, instead. But ensuring that panics are handled in complex projects is no simple feat; we can make Go relax, it just takes some convincing.

Because panic recovery is limited to goroutine scope, each recoverable goroutine needs to defer a call to recover().

Recover is a built-in function that regains control of a panicking goroutine. Recover is only useful inside deferred functions. During normal execution, a call to recover will return nil and have no other effect. If the current goroutine is panicking, a call to recover will capture the value given to panic and resume normal execution.2

Every time we wanted to turn a panic into an error, we would have to repeat the following snippet for each corresponding goroutine we launch:

defer func() {
    if r := recover(); r != nil {
        // Closure assigns panic to error
        err = fmt.Errorf("recovered from: %v": r)
    }
}()

We need to use an anonymous func here because we require a closure if we are to assign the recovered content to an error declared in the surrounding scope. You can imagine that most developers would not bother with this boilerplate. But even if you do bother, there are some pitfalls to be aware of. If the func within which the defer call is made is to actually return the error assigned inside the deferred closure, that func must define named return variables:

… if the deferred function is a function literal and the surrounding function has named result parameters that are in scope within the literal, the deferred function may access and modify the result parameters before they are returned.3

These complexities add up, making panic recovery a burden that most developers often wouldn’t bother with. But we can simplify things using the relax module, which abstracts away these complexities and makes it easy for us to write relaxed Go applications which always shutdown gracefully.

Instead of using the native go keyword, you can use relax.Go() which handles all the complexities of panic recovery for us:

routine := relax.Go(func() error {
        []int{}[0] = 1 // Panic for example
})

Once you have the relax.Routine which is returned from relax.Go(), you can either wait for it to return an error or release it with a callback that handles the returned error concurrently:

// Block on routine completion
if err := routine.Wait(); err != nil {
	// Handle the error...
}

// Handle error concurrently
routine.Release(func(err error) {
	// Handle the error...
})

The relax module also provides a wrapper around errgroup. Just like relax.Routine, relax.RoutineGroup will let you run goroutines without worrying about panic recovery:

// Instantiate the routine group
group, ctx := relax.NewGroup(relax.Context())

// Launch some goroutines via group.Go()
...

// Wait for routine group to return an error
if err := group.Wait(); err != nil {
	// Handle the error...
}

You may have noticed the relax.Context() above. The relax module also provides a way of shutting down your application gracefully when SIGINT and SIGTERM signals are received. You just have to derive all your application contexts from the one returned by relax.Context().

Recover, Relax, and Shutdown Gracefully

Being able to recover from panics doesn’t necessarily mean it is appropriate for your runtime to panic, recover, and then continue.

For example, if you have a runtime that executes some logic in an infinite loop, and that logic relies on side effects (such as state recorded in the relevant struct type), introducing a recover-and-continue pattern may just swap one error state for another, due to the effect of a panic on relevant side effects. In this case, you could try factoring your loop to reset state on recovery, but it is probably much simpler to shutdown gracefully after recovering from the panic.

Not all applications care about shutting down gracefully; it is perfectly fine to crash on panic if there are no negative consequences to doing so.

So what kind of applications care about shutting down gracefully? Here are a few concrete examples:

• API servers that may leave dangling resources in their corresponding databases or abruptly terminate a large number of parallel client connections due to a panic;

• CLIs whose stdout format is regularly relied upon by, for example, unix command pipelines;

• Applications that write state to a filesystem which may produce irrecoverable state if a series of dependent file writes is interrupted by a panic; and

• Tests, such as integration tests using Go's coverage capabilities, where a panic can cause you to lose your prized test results.

When implementing your next application, have a think about the consequences of an abrupt, panic-induced crash. Will it cause UX problems? Will it cause problems for some system upstream? Will it leave dangling resources in your data store? If so, consider taking measures to keep your application relaxed in the case of panics.

But remember not to overdo it - there are plenty of situations where its simpler and safer to let the panic unroll the stack and cause the application to exit.

Thanks!

Thank you for taking the time to read this article. It has been an interesting rabbit hole to explore and I hope you enjoyed the read.

If the relax module gets any contributions and usage, we can work towards a 1.0 release. Please feel free to submit contributions or create issues and discussions.