# WHIR EthResearch

## Introduction: why and how WHIR could be used for Ethereum in the future?

- For Ethereum, proof size and verification time are crucial.
- We want validators to run on very small devices (ultimately Raspberry pi pico 2 as highlighted by Justin Drake during ethproofs call #2) in order to improve decentralization of the network.
- Signature aggregation for the beam chain will be considered as the main example during all this post without loss of generality.

- Recently, we have seen a wave of switches from traditional univariate polynomial techniques to multilinear settings for zk proofs.
- Jagged PCS is a very good example of this because it marks this very important switch, achieving real time proving for the first time using multilinear pcs.
- In univariate settings, the prover must commit to, and provide evaluation proofs of each of the column polynomials of the trace. As we often have a huge number of columns, these operations dominate the verifier's runtime in modern hash-based systems such as SP1.

- Justin Thaler has long emphasized the beauty, simplicity and importance that sumcheck should have in future proof systems.

- We are lucky because WHIR can handle both univariate and multilinear cases so we can construct a multilinear pcs with it.

- WHIR has a lot of qualities making it a suitable candidate for future proof systems on Ethereum:
- Multilinear setting possible
- Very small proofs
- Reduced verifier work

- For Ethereum, we want:
- Simplicity for proof systems we will use
- Hash based setting is attractive because it relies only on a hash function (as opposed for example to lattice based settings which are much more complex to setup properly)

## Some context on modern zk SNARKs

- How we build SNARGs through poly-IOPs
- Modern approaches use hash based SNARGs: poly-IOPs + compilation via the BCS transformation
- Only random oracles needed + many advantages: transparent setup, post quantum security, fast prover perf
- But right now we have slow verifier on traditional techniques leading to potential limitation for Ethereum and proof verification (decentralization). For example, FRI could be quite expensive on this point.

- Big question is: how to reduce verifier time without degrading prover efficiency or inflating the proof?

## What WHIR can offer?

- Extremely low query complexity,
- Verification in microseconds,
- Compatibility with both univariate and multilinear poly-IOPs.

This traduces directly in:
- faster SNARG verification
- smaller proofs in both univariate and multilinear settings

Here it would be nice also to explain clearly what is the function of WHIR in the whole proof system: where does WHIR intervene?

## How does WHIR work?

Here I will rather see a complete explanation but without entering in demonstration details or things like that. Rather something that both engineers and mathematicians can understand.

### Reed Solomon code proximity test

- What is the goal of WHIR: to check if a function is close to being a valid Reed–Solomon codeword, under some extra constraint.
- Recall on why we need this?
- What is being tested and how?
- Probably the definition of constrained Reed Solomon codes
- Probably an illustration would be nice here

### Problem folding

- How do we fold the problem in WHIR vs FRI/STIR
- Maybe we need a small illustration here, something like this but probably simpler
- Folding Reed–Solomon Codes and preserving distance
- Mostly explaining this: folding reduces the complexity of the function we’re checking without significantly affecting how far it is from being a valid codeword
- Why does folding preserves distance?
- I guess we need to define properly here the notion of mutual correlated agreement that is quite new
- We should probably also mention: Why folding preserves lists?
- i.e. what if $f$ is *close* to multiple codewords? Could folding disrupt that structure or introduce new "fake" codewords?
- The good news is: **folding behaves well with lists, too**. This is another benefit of mutual correlated agreement. It ensures that folding **commutes** with list decoding

### Summary with a WHIR iteration
- After all the explanations we can probably summarize things by showing how a WHIR iteration works:
1. Inputs
2. Interation phase: prover and verifier exchange messages
3. Decision phase: the verifier performs various checks to confirm consistency

## Specific highlight on signature aggregation

Without loss of generality, we would like to make an emphasis on why we specifically investigated a lot WHIR for signature aggregation of the beam chain and how we plan to use it.

- Beam chain small recap:
- Refactor/simplification of the consensus layer
- Signature aggregation via post quantum cryptography as opposed to BLS signatures that rely on elliptic curves and for which aggregation is easy via pairing.
- We need a post quantum way to aggregate signatures and verify them
- Proofs need to be ultra small (aggressive target is 128 kib) and this appears increasingly obvious that classical PCS (and univariate settings) cannot afford this.
- We need to rethink the proof system we will use from scratch
- Hash based proof system is attractive because of simplicity and only relying on hash function

- Constructing our proof system on the top of the WHIR multilinear PCS proved amazing on our first experiments with Poseidon hashing
- We have small proofs
- Fast verifications
- With some implementation tricks we are making WHIR prover part faster and faster day after day

## Summary and next steps
- Describe our whole proof construction in a subsequent post
- Continue making WHIR faster and faster with low level tricks and more modular to be use widely all over Ethereum
- Discover potential other use cases of WHIR for Ethereum (lots of zkVM teams already showed interest in integrating WHIR to their proof system).