TITLE SLIDE

Placeholder

AGENDA SLIDE

Placeholder

9:30 -10:30 AM - Catered breakfast & mingling

10:30 AM - 12:00 - Part I: SNARK Landscape & Overview; Izaak Meckler, Co-founder & CTO, O(1) Lab

12:00 - 1:00 PM - Catered Lunch

1:00 -3:30 PM - Part II: Programming SNARKs; Izaak Meckler, Co-founder & CTO, O(1) Labs

3:30 - 3:45 PM - Bobbin Threadbare, ‘AirScript - Defining AIR Constraints for zk-STARKs’

3:45 - 4:00 PM - Brian Gu & Brice Huang, ‘Dark Forest - Using zk-SNARKs to build a strategy MMO on Ethereum’

4:00 - 4:30 PM - Closing Remarks, Vitalik Buterin, Founder & Chief Scientist, Ethereum Foundation

4:30-5:30 PM - Meet & Greet + Happy Hour

​

​

Agenda

What we’ll cover

What SNARKs are useful for

How to use them in the context of a full application architecture

How to use snarky to program SNARKs

Snapps: SNARKified apps

A SNAPP gives its users strong, verifiable guarantees about its behavior while preserving user privacy to the greatest extent possible.

​

​

An application: workplace democracy

Workers join an org based on endorsements from other org members

Workers can vote on relevant issues without revealing how they individually are voting.

How to implement this?

Goal: By the end of today, you’ll know enough to make this application.

An application: workplace democracy

We’ll implement a simplified version where the set of voters is fixed.

Voting architecture

Two phases

1. Registration: Users register their information with a registrar
2. Voting: Users vote on whatever elections they like

Security desiderata

1. Registered users can vote exactly once. Users who have not registered cannot vote.
2. Privacy of votes.

Voting architecture

Registrar

Voter

Register voter record

Submit votes

Broadcast votes from all

Registering a voter record

Registration closes

Voting

Registrar checks:

• Does this key belong to a registered voter?
• Has this key voted in this election yet?

Problems

Registrar can see how individuals are voting

Keys broadcast on network, so others can impersonate

​

Registrar checks:

• Does this key belong to a registered voter?
• Has this key voted in this election yet?

Registering a voter record

Instead of record, send its hash

Voting

Instead of sending private key with election, send hash

Voting

Registrar needs to check

• Does this key belong to a registered voter?
• Has this key voted in this election yet?

Voting

SNARKs let us selectively reveal information

​

“This is a hash of some data”

SNARK

SNARK

Voting

This solves the problem of “no double voting”

​

Remaining problem: How do we know the hidden private key belongs to a registered user?

SNARK

Voting

Problem: How do we know that hidden private key belongs to a registered user?

SNARK

Voting

Solution: Merkle trees!

SNARK

Proving knowledge of a preimage

Proving knowledge of a preimage

Proving knowledge of a preimage

SNARK

Crash course: Fields

A “field” is a type supporting

• Addition +
• Subtraction -
• Multiplication *
• Division /

We can make a field out of the numbers 0, 1, …, p - 1 if p is prime (e.g., 17)

In our setting p is a large prime, think ~2²⁵⁶ or even larger.

Crash course: Fields

Inside the SNARK, the only efficient thing is field operations

Relevant for us: hashes operate on field elements

Crash course: Merkle trees

-> whiteboard

Install docker

• docker load < snarky.tar.gz
• docker run --name sfbw -it $HASH_OUTPUT_FROM_LOAD
• On linux: sudo usermod -aG docker $USER

Install vscode

• Install: Remote-Containers extension
• Install vscode-reasonml extension

Links

codaprotocol.com/docs/snarks/snarky/

reasonml.github.io/docs/en/syntax-cheatsheet

Complex authentication

Goal: Decentralized Facebook

Each users hosts their own profile

They shouldn’t be able to know who is looking at their profile, just that the person is allowed to look at their profile.