Protocol Overview

In this section, we start diving deeper before showing the formal protocol. If you haven't done so, we recommend reading the "Recap" section first.

At a high level, the protocol works as follows. The starting point is a matrix that encodes the trace of a valid execution of the program. This matrix needs to be in a particular format so that its correctness is equivalent to checking a finite number of polynomial equations on its rows. Transforming the execution to this matrix is what's called the arithmetization process.

Then a single polynomial is constructed that encodes the set of all the polynomial constraints. The satisfiability of all these constraints is equivalent to being divisible by some public polynomial . So the prover constructs as the quotient called the composition polynomial.

Then the verifier chooses a random point and challenges the prover to reveal the values and . Then the verifier checks that , which convinces him that the same relation holds at a level of polynomials and, in consequence, convinces the verifier that the private trace of the prover is valid.

In summary, at a very high level, the STARK protocol can be organized into three major parts:

  • Arithmetization and commitment of execution trace.
  • Construction and commitment of composition polynomial .
  • Opening of polynomials at random .

Arithmetization

As the Recap mentions, the trace is a table containing the system's state at every step. In this section, we will denote the trace as . A trace can have several columns to store different aspects or features of a particular state at a specific moment. We will refer to the -th column as . You can think of a trace as a matrix where the entry is the -th element of the -th state.

Most proving systems' primary tool is polynomials over a finite field . Each column of the trace will be interpreted as evaluations of such a polynomial . Consequently, any information about the states must be encoded somehow as an element in .

To ease notation, we will assume here and in the protocol that the constraints encoding transition rules depend only on a state and the previous one. Everything can be easily generalized to transitions that depend on many preceding states. Then, constraints can be expressed as multivariate polynomials in variables A transition from state to state will be valid if and only if when we plug row of in the first variables and row in the second variables of , we get for all . In mathematical notation, this is

These are called transition constraints and check the trace's local properties, where local means relative to specific rows. There is another type of constraint, called boundary constraint, and denoted . These enforce parts of the trace to take particular values. It is helpful, for example, to verify the initial states.

So far, these constraints can only express the local properties of the trace. There are situations where the global properties of the trace need to be checked for consistency. For example, a column may need to take all values in a range but not in any predefined way. Several methods exist to express these global properties as local by adding redundant columns. Usually, they need to involve randomness from the verifier to make sense, and they turn into an interactive protocol called Randomized AIR with Preprocessing.

Polynomial commitment scheme

To make interactions possible, a crucial cryptographic primitive is the Polynomial Commitment Scheme. This prevents the prover from changing the polynomials to adjust them to what the verifier expects.

Such a scheme consists of the commit and the open protocols. STARK uses a univariate polynomial commitment scheme that internally combines a vector commitment scheme and a protocol called FRI. Let's begin with these two components and see how they build up the polynomial commitment scheme.

Vector commitments

Given a vector , commiting to means the following. The prover builds a Merkle tree out of it and sends its root to the verifier. The verifier can then ask the prover to reveal, or open, the value of the vector at some index . The prover won't have any choice except to send the correct value. The verifier will expect the corresponding value and the authentication path to the tree's root to check its authenticity. The authentication path also encodes the vector's position and its length .

The root of the Merkle tree is said to be the commitment of , and we denote it here by .

FRI

In STARKs, all commited vectors are of the form for some polynomial and some fixed domain . The domain is always known to the prover and the verifier. It can be proved, as long as is less than the total number of field elements, that every vector is equal to for a unique polynomial of degree at most . This is called the Lagrange interpolation theorem. It means, there is a unique polynomial of degree at most such that for all . And is an upper bound to the degree of . It could be less. For example, the vector of all ones is the evaluation of the constant polynomial , which has degree .

Suppose the vector is the vector of evaluations of a polynomial of degree strictly less than . Suppose one party holds the vector and another party holds only the commitment of it. The FRI protocol is an efficient interactive protocol with which the former can convince the latter that the commitment they hold corresponds to the vector of evaluations of a polynomial of degree strictly less than .

More precisely, the protocol depends on the following parameters

  • Powers of two and with .
  • A vector , with , with a nonzero value in and a primitive -root of unity

A prover holds a vector , and the verifier holds the commitment of it. The result of the FRI protocol will be Accept if the unique polynomial of degree less than such that has degree less than . Even more precisely, the protocol proves that is very close to a vector with of degree less than , but it may differ in negligible proportion of the coordinates.

The number is called the blowup factor and the security of the protocol depends in part on this parameter. The specific shape of the domain set has some symmetric properties important for the inner workings of FRI, such as for all .

Variant useful for STARKs

FRI is usually described as above. In STARK, FRI is used as a building block for the polynomial commitment scheme of the next section. For that, a small variant of FRI is needed.

Suppose the prover holds a vector and the verifier holds its commitment as before. Suppose further that both parties know a function that takes two field elements and outputs another field element. For example could be the function . More precisely, the kind of functions we need are .

The protocol can be used to prove that the transformed vector is the vector of evaluations of a polynomial of degree at most . Note that in this variant, the verifier holds originally the commitment of the vector and not the commitment of the transformed vector. In the example, the verifier holds the commitment and FRI will return Accept if is the vector of evaluations of a polynomial of degree at most .

Polynomial commitments

STARK uses a univariate polynomial commitment scheme. The following is what is expected from the commit and open protocols:

  • Commit: given a polynomial , the prover produces a sort of hash of it. We denote it here by , called the commitment of . This hash is unique to . The prover usually sends to the verifier.
  • Open: this is an interactive protocol between the prover and the verifier. The prover holds the polynomial . The verifier only has the commitment . The verifier sends a value to the prover at which he wants to know the value . The prover sends a value to the verifier, and then they engage in the Open protocol. As a result, the verifier gets convinced that the polynomial corresponding to the hash evaluates to at .

Let's see how both of these protocols work in detail. The same configuration parameters of FRI are needed:

  • Powers of two and with .
  • A vector , with , with a nonzero value in and a primitive -root of unity

The commitment scheme will only work for polynomials of degree at most (polynomials of degree are allowed). This means: anyone can commit to any polynomial, but the Open protocol will pass only for polynomials satisfying that degree bound.

Commit

Given a polynomial , the commitment is just the commitment of the vector . That is, is the root of the Merkle tree of the vector of evaluations of at .

Open

It is an interactive protocol. So assume there is a prover and a verifier. We describe the process considering an honest prover. In the next section, we analyze what happens for malicious provers.

The prover holds the polynomial , and the verifier only the commitment of it. There is also an element chosen by the verifier. The prover evaluates and sends the result back. As we mentioned, the goal is to generate proof of the validity of the evaluation. Let us denote the value received by the verifier.

Now they engage in the variant of the FRI protocol for the function . The verifier accepts the value if and only if the result of FRI is Accept.

Let's see why this makes sense.

Completeness

If the prover is honest, is of degree at most and equals . That means that for some polynomial . Since is of degree at most , then is of degree at most . The vector is then a vector of evaluations of a polynomial of degree at most . And it is equal to . So the FRI protocol will succeed.

Soundness

Let's sketch an idea of the soundness. Note that the value is chosen by the verifier after receiving the commitment of . So the prover does not know in advance, at the moment of sending , what will be.

Suppose the prover is trying to cheat and sends the commitment of a vector that's not the vector of evaluations of a polynomial of degree at most . Then the coordinates of the transformed vector are . Since was chosen by the verifier, dividing by shuffles all the elements in a very unpredictable way for the prover. So it is extremely unlikely that the cheating prover can craft an invalid vector such that the transformed vector turns out to be of degree at most . The expected degree of the polynomial associated with a random vector is .

Batch

During proof generation, polynomials are committed and opened several times. Computing these for each polynomial independently is costly. In this section, we'll see how batching polynomials can reduce the amount of computation. Let be a set of polynomials. We will commit and open as a whole. We note this batch commitment as .

We need the same configuration parameters as before: , with , a vector .

As described earlier, to commit to a single polynomial , a Merkle tree is built over the vector . When committing to a batch of polynomials , the leaves of the Merkle tree are instead the concatenation of the polynomial evaluations. That is, in the batch setting, the Merkle tree is built for the vector The commitment is the root of this Merkle tree. This reduces the proof size: we only need one Merkle tree for polynomials. The verifier can then only ask for values in batches. When the verifier chooses an index , the prover sends along with one authentication path. The verifier on his side computes the concatenation and validates it with the authentication path and . This also reduces the computational time. By traversing the Merkle tree one time, it can reveal several components simultaneously.

The batch open protocol proceeds similarly to the case of a single polynomial. The verifier sends evaluations points to the prover at which they wish to know the value of . The prover will try to convince the verifier that the committed polynomials , evaluate to some values . There is a generalization of the variant of FRI where the function takes more parameters, and in this case is Where are challenges provided by the verifier. Then FRI return Accept if and only if the vector is close to the vector of evaluations of a polynomial of degree at most . If this is the case, the verifier accepts the openings. In the context of STARKs, the polynomial is called the DEEP composition polynomial.

This is equivalent to running the open protocol times, one for each term and . Note that this optimization makes a huge difference, as we only need to run the FRI protocol once instead of running it once for each polynomial.

References

High-level description of the protocol

The protocol is split into rounds. Each round more or less represents an interaction with the verifier. Each round will generally start by getting a challenge from the verifier.

The prover will need to interpolate polynomials, and he will always do it over the set , where is a root of unity in . Also, the vector commitments will be performed over the set where is a root of unity and is some field element. This is the set we denoted in the commitment scheme section.

Round 1: Arithmetization and commitment of the execution trace

In round 1, the prover commits to the columns of the trace . He does so by interpolating each column and obtaining univariate polynomials . Then the prover commits to over . In this way, we have . From now on, the prover won't be able to change the trace values . The verifier will leverage this and send challenges to the prover. The prover cannot know in advance what these challenges will be. Thus he cannot handcraft a trace to deceive the verifier.

As mentioned before, if some constraints cannot be expressed locally, more columns can be added to make a constraint-friendly trace. This is done by committing to the first set of columns, then sampling challenges from the verifier and repeating round 1. The sampling of challenges serves to add new constraints. These constraints will ensure the new columns have some common structure with the original trace. In the protocol, extended columns are referred to as the RAP2 (Randomized AIR with Preprocessing). The matrix of the extended columns is denoted .

Round 2: Construction of composition polynomial

round 2 aims to build the composition polynomial . This function will have the property that it is a polynomial if and only if the trace that the prover committed to at round 1 is valid and satisfies the agreed polynomial constraints. That is, will be a polynomial if and only if is a trace that satisfies all the transition and boundary constraints.

Note that we can compose the polynomials , the ones that interpolate the columns of the trace , with the multivariate constraint polynomials as follows. These result in univariate polynomials. The same can be done for the boundary constraints. Since , these univariate polynomials vanish at every element of if and only if the trace is valid.

As we already mentioned, this is assuming that transitions only depend on the current and previous state. But it can be generalized to include frames with three or more rows or more context for each constraint. For example, in the Fibonacci case, the most natural way is to encode it as one transition constraint that depends on a row and the two preceding it, as we already did in the Recap section. The STARK protocol checks whether the function is a polynomial instead of checking that the polynomial is zero over the domain . The two statements are equivalent.

The verifier could check that all are polynomials one by one, and the same for the polynomials coming from the boundary constraints. However, this is inefficient; the same can be obtained with a single polynomial. To do this, the prover samples challenges and obtains a random linear combination of these polynomials. The result of this is denoted by and is called the composition polynomial. It integrates all the constraints by adding them up. So after computing , the prover commits to it and sends the commitment to the verifier. The rest of the protocol aims to prove that was constructed correctly and is a polynomial, which can only be true if the prover has a valid extension of the original trace.

Round 3: Evaluation of polynomials at

The verifier must check that was constructed according to the protocol rules. That is, has to be a linear combination of all the functions and similar terms for the boundary constraints. To do so, in round 3 the verifier chooses a random point and the prover computes , and for all . With all these, the verifier can check that and the expected linear combination coincide, at least when evaluated at . Since was chosen randomly, this proves with overwhelming probability that was properly constructed.

Round 4: Run batch open protocol

In this round, the prover and verifier engage in the batch open protocol of the polynomial commitment scheme described above to validate all the evaluations at from the previous round.