To make sure the python notebooks work properly, please click the button below to start the binder environment
We highly recommend familiarizing yourself with how Python notebooks work – we’ve created a short tutorial for you in the binder.
In the first part of STARK 101 we start by introducing the statement we will be proving throughout this workshop.
Then we take the first steps into the STARK protocol, introducing two concepts: Low Degree Extension (LDE) and commitment using Merkle tree.
In part II, we create a set of polynomial constraints. We use this set in order to reduce the original statement we want to prove to a new statement, that will be the input for the next step of the protocol.
After that, we create a composition polynomial and commit on it.
In part III of STARK 101 we dive into the FRI protocol. We introduce the concept of proximity between a function and a polynomial and learn how to use the FRI protocol to prove that the composition polynomial we just created in the previous part is close to a polynomial of a bounded degree.
In the last part of STARK 101 we tie it all together to build an end to end proof.
We go through the commitment phase, that was gradually described in the first three parts, and describe the decommitment phase that follows.
We explain how the prover convinces the verifier, using the proof, that the statement we set out to prove is true.
Congratulations! You’ve completed the STARK 101 workshop! Watch this final talk for a recap, and some ideas on what you can do next.
6 Questions, 1 Minute, Better STARK Workshops for All
During the workshop you’ll generate a STARK proof for the 1023th element of the FibonacciSq sequence over a finite field. In this section, we explain what this last sentence means.
For the workshop we define a sequence that resembles the well known Fibonacci sequence. In this sequence any element is the sum of squares of the two previous elements. Thus the first elements are:
1, 1, 2, 5, 29, 866, …
All the elements of the sequence will be from the finite field (which means that both squaring and addition is computed modulo p).
We will create a proof for the claim “The 1023th element of the FibonacciSq sequence is …”. By “proof” we don’t mean a mathematical proof with logical deductions. Instead, we mean some data which can convince whomever reads it that the claim is correct. To make it more formal we define two entities: Prover and Verifier. The Prover generates this data (the proof). The Verifier gets this data and checks for its validity. The requirement is that if the claim is false, the Prover will not be able to generate a valid proof (even if it deviates from the protocol).
STARK is a specific protocol which describes the structure of the proof and defines what the Prover and Verifier have to do.