# RareSkills Authors - Groth16 Explained (Highlights)  ## Metadata **Review**:: [readwise.io](https://readwise.io/bookreview/38850709) **Source**:: #from/readwise #from/reader **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[RareSkills Authors]] **Full Title**:: Groth16 Explained **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **URL**:: [www.rareskills.io](https://www.rareskills.io/post/groth16) **Host**:: [[www.rareskills.io]] **Highlighted**:: [[2024-03-21]] **Created**:: [[2024-03-21]] ## Highlights - It uses auxiliary elliptic curve points from the trusted setup to prevent forged proofs. ([View Highlight](https://read.readwise.io/read/01hsdyxt2rj9t8096yexaxjtma)) ^695421222 - We need to force the prover to be honest without introducing too much computational overhead. The first algorithm to accomplish this was “[Pinocchio: Nearly Practical Verifiable Computation](https://eprint.iacr.org/2013/279.pdf).” This was usable enough for zcash to base the first version of their blockchain on it. ([View Highlight](https://read.readwise.io/read/01hsdz08mj7az8616x55p385r6)) ^695421400 - However, groth16 was able to accomplish the same thing in much fewer steps, and the algorithm is still widely in use today, as no algorithm since has produced as efficient a verifier step (though other algorithms have eliminated the trusted setup or significantly reduced the amount of work for the prover). ([View Highlight](https://read.readwise.io/read/01hsdz0g0wjfncn37c693pw71r)) ^695421425 - These are created by the trusted setup agent randomly sampling α and β, creating elliptic curve points [αG] and [βG] and then destroying α and β. ([View Highlight](https://read.readwise.io/read/01hsf5xgy17s2hh48nbt4astgw)) ^695633803 - Under the new formula, the prover can no longer invent A, B and compute C, or invent C and derive A and B. ([View Highlight](https://read.readwise.io/read/01hsf64t7tmgwwvdxsca63xws2)) ^695634747 - However, the term βu(τ) + αv(τ) + w(τ) can be precomputed at τ at the trusted setup. ([View Highlight](https://read.readwise.io/read/01hsf6qfsc8vf0e4e3r1vz97hs)) ^695636419 - The underlined parts are what we send to the prover. ([View Highlight](https://read.readwise.io/read/01hsf6x91afadeb732np1kjhg9)) ^695637131  - The only thing that changes from above is that [C] is computed over the private inputs, instead of the entire witness vector. ([View Highlight](https://read.readwise.io/read/01hsf71fdmj8wta9xrvp3xabs9)) ^695641174 - and the verifier has to compute the public portion using the elliptic curve points from the trusted setup. This is the new verification formula ([View Highlight](https://read.readwise.io/read/01hsf72e0ewm0ch4w1hmw6j40y)) ^695642422 - To prevent this, the trusted setup agent divides w₀(τ) and w₁(τ) by a secret variable γ the prover portion by a different variable δ. ([View Highlight](https://read.readwise.io/read/01hsf77ek6jqgbsyda7ghj8h29)) ^695649232 - The [γ] and [δ] terms will cancel out if the prover truly used the polynomials from the trusted setup. The prover (and verifier) do not know the field element that corresponds to [δ], so they cannot cause the terms to cancel out unless they use the values from the trusted setup. ([View Highlight](https://read.readwise.io/read/01hsf76tg3ngsn27q3er7vqz1b)) ^695648737 - Our scheme is not yet truly zero knowledge. If an attacker is able to guess our witness vector (which is possible if there is only a small range of valid inputs, e.g. secret voting from privileged addresses), then they can verify their guess is correct by comparing their constructed proof to the original proof. ([View Highlight](https://read.readwise.io/read/01hsf7ehmpm9e089f16tqpafzp)) ^695656857 - To do this, we introduce another random shift, but this time at the proving phase instead of the setup phase. ([View Highlight](https://read.readwise.io/read/01hsf7etre873pghn7ft7ks552)) ^695657059