►
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/building-a-unirep-ecosystem/
What does an identity ecosystem built on top of Unirep look like? Learn how reputation works in a system where participants are anonymous and how it can be used to build applications.
Speaker(s): Chance Hudson
Skill level: Intermediate
Track: ZKPs: Privacy, Identity, Infrastructure, & More
Keywords: identity,reputation,privacy
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
B
B
Then
I'll
talk
a
little
bit
about
improving
the
user
experience
of
ZK
and
blockchain
applications
in
general,
and
then
I'll
talk
a
little
bit
about
how
we
can
scale
ZK
on
the
blockchain
and
sort
of
where
we're
at
with
the
capacity
right
now
right.
So,
let's
dive
into
it.
Unirp
is
short
for
Universal
reputation
and
you
can
think
of
it
as
two
different
things.
First,
it's
an
identity
system
that
gives
you
anonymity
and
it
does
this
by
creating
public
keys
that
change
over
time.
The
second
component
is
this
attestation
system.
B
So
that's
one
component
of
the
user
State,
the
other
is
this
graffiti
value
which
the
the
a
tester
can
use
for
anything
in
anything
they
want
to
within
the
application-
and
this
is
just
32,
bytes
and
yeah.
The
assessor
can
use
it
as
they
like
and
so
one
example
use
case
of
this
is
and
a
tester
can
allow
users
to
register
a
username,
and
so
the
user
requests
a
username
and
then
the
tester
attests
giving
the
hash
of
the
username
as
graffiti
to
the
user.
B
Now,
when
the
user
takes
an
action
or
makes
a
proof,
they
can
prove
the
pre-image
of
the
graffiti
and
move
from
anonymity
to
pseudonymity.
So
that's
one
example
use
case.
That's
relatively
simple.
A
more
complex
example
would
be
storing
the
state
route
of
a
Merkle
tree
inside
of
this
graffiti,
and
then
the
attester
can
extend
the
ZK
proof
system
to
prove
things
about
the
contents
of
that
tree.
That's
in
the
graffiti,
so,
for
example,
they
could
use
an
incremental
Merkle
tree
to
give
achievements
to
the
user
or
to
track
actions.
B
The
user
has
taken
anything
like
that,
so
very
extensible
system,
so
the
two
main
properties
of
unirp
are
anonymity
and
non-confidentiality.
That
means
we
can
see
everything
that's
happening
inside
of
the
system,
how
much
reputation
is
being
transferred
and
whatnot,
but
we
don't
know
who's
doing
what.
B
So,
let's
talk
a
little
bit
about
the
unirap
identity
system.
We
build
on
top
of
a
system
called
semaphore,
which
is
also
developed
by
the
privacy
and
scalability
team,
and
with
some
before
we
have
this
public
private
Key
System.
That's
the
most
simple
explanation:
it
has
two
Secrets
a
chapter
and
a
nullifier
and
we
defined
a
public
key
as
the
hash
of
the
hash
of
those
two
secrets.
B
We
also
call
this
an
identity
commitment
in
semaphore
talk
and
we
use
the
Poseidon
hash
function
to
calculate
these
values,
which
makes
it
a
ZK
friendly
protocol,
and
that
means
that
you
can
extend
it
to
do
arbitrary
things.
So
so.
In
this
example,
we
have
just
a
public
private
key
system
which
isn't
particularly
useful,
but
using
a
ZK
proof.
You
could
extend
it
to
do
signatures,
for
example,
by
writing
a
proof
that
proves
the
secret
values
as
well
as
the
hash
of
some
data
that
you
want
to
assign.
B
We
also
have
this
nonce
value,
which
is
a
value
between
like
one
and
or
zero
and
two
by
default,
and
it
allows
us
to
give
the
user
multiple
Epoch
keys
for
a
single
Epoch.
So
if
your
user
wants
to
commit
an
action
and
then
wants
to
give
it
another
action
but
doesn't
want
to
link
their
identity
between
the
two
keys,
they
can
use
different
epochies
and
still
be
able
to
prove
the
same
amount
of
reputation
and
whatnot
and
just
like
some
of
our
this
system
is
ZK
friendly
and
therefore
extensible.
B
So
if
you
want
to
make
a
signature
system
using
these
epochies,
you
would
use
the
exact
same
approach
where
you
prove
the
proof,
control
of
the
nullifier
and
the
public
signals.
And
then
you
pass
in
whatever
you
want
to
hash
and
it
all
gets
output
yeah.
So
now,
I
want
to
talk
a
little
bit
about
data
structures
that
we
use
in
unit.
So
we
have
like
this
identity
system.
But
how
do
we
assign
reputation
and
graffiti
to
users
in
the
system
and
then
like
continue
to
prove
it?
B
We
have
this
state
tree
first,
which
controls
or
measures
whether
or
not
a
user
is
a
member
of
the
current
Epoch
and,
as
you
can
see,
it's
an
incremental
Merkel
tree
that
we
store
completely
on
chain
and
the
the
leaves
themselves
are
the
hash
of
this
private
identity,
nullifier
the
tester
in
the
epoch
and
then
the
reputation
the
user
has
at
the
start
of
the
epoch.
So
this
tree
control
or
this
tree
has
leaves
that
a
user
inserts
into
when
they
join
the
current
Epoch.
B
B
So
in
the
previous
slide,
you
saw
that
the
epoch
key
is
just
smash
of
some
arbitrary
data
and
we're
able
to
apply
or
were
able
to
determine
a
leaf
in
the
tree
by
taking
the
modulus
of
that
hash
across
the
the
number
of
leaves
in
the
tree.
So
if
we
use
this
exact
tree,
we
would
take
the
hash
modulus
two
to
the
third,
because
it's
only
three
levels
deep,
but
of
course,
if
we
did
that
we
would
have
lots
of
collisions.
B
B
So
the
whole
idea
behind
unirp
is
users,
have
these
identities,
for
that
are
valid
for
an
Epoch
and
then
at
the
end
of
that
Epoch
they
pack
up
their
reputation
and
they
move
to
a
new
identity
and
the
next
Epoch
by
inserting
a
leaf
into
the
new
state
tree.
I
didn't
say
this
before,
but
we
have
a
copy
of
these
trees
every
Epoch
that
we
that
we
use
right.
So
let's
change
gears
a
little
bit
and
talk
about
the
user
experience
for
zero
knowledge
applications.
B
B
The
first
proof
we
have
is
a
sign
up
proof,
it's
very
small,
it's
700
constraints
and
all
it
does
is
output,
a
hash
value
so
less
than
one
second,
a
little
bit
bigger.
We
have
an
Epoch
keep
proof.
This
proves
control
of
an
Epoch
key
and
also
proves
a
leaf
in
the
state
tree.
So
it's
a
little
bit
bigger
3000
constraints,
still
less
than
one
second
on
most
devices
and
way
over.
B
Here
we
have
this
user
State
transition
proof,
and
in
this
proof
we
add
up
the
value
in
the
state
tree
leaf,
as
well
as
the
values
in
all
of
the
epoch.
Tree
leaves
and
output
a
new
state
tree
leaf
with
the
sum
of
the
reputation
the
user
owns.
So
we
have
to
do
multiple
inclusion,
inclusion,
proofs
over
trees-
that
are
quite
large,
but
we
still
end
up
with
about
29,
000
constraints,
so
less
than
five
seconds
on
Modern
devices,
and
we
can
also
execute
this
proof
in
the
background.
B
Right
so
I
think
a
good
goal
for
zika
applications
and
for
blockchain
in
general.
Is
users
not
being
aware
that
they're
using
the
blockchain,
while
they're
using
the
blockchain?
So
a
lot
of
you
probably
use
websites
or
applications
like
Spotify
or
Twitter
or
Reddit
or
stack
Overflow.
Just
raise
your
hand.
If
you
know
what
kind
of
database
those
applications
are
using
right.
No
one
raised.
Okay,
one
person
raised
their
hand.
B
We
have
at
least
one
nerd
in
the
crowd,
but
for
the
most
part,
users
don't
really
care
about
the
data
structures
that
are
backing
the
applications.
They're
using
and
blockchains
are
really
the
same.
They're
just
databases
with
different
properties,
and
so
the
user
shouldn't
have
to
be
aware
that
they're
using
the
blockchain.
B
So
luckily,
if
we
use
ZK
identities
instead
of
wallets,
we
can
build
this
more
traditional
three-tier
architecture,
where
we
introduce
a
relay
that
that
bundles
the
transaction
and
sends
it
so
the
flow
would
be
the
web
app
generates.
A
ZK
proof
gives
it
to
the
relay
the
relay,
creates
a
transaction
and
then
post
it
to
the
blockchain
and
the
economics
of
why
the
relay
would
do
this
are
sort
of.
There
are
a
lot
of
different
schemes.
B
You
could
build
like
subscription
models
or
just
like
free
trial
models,
all
sorts
of
different
things
you
could
do,
and
so
one
one
note
about
like
this
architecture.
The
relay
is
not
a
trusted
entity.
The
Relay
can
censor
transactions
that
can
go
offline,
it
doesn't
matter
the
web
applicant
or
the
user
can
only
send
their
ZK
proof
with
a
different
relay
or
broadcast
it
to
the
blockchain
themselves.
B
B
So
how
can
we
build
an
ecosystem
using
like
ZK
proofs
in
this
sort
of
abstracted
architecture?
One
approach,
I,
think,
is
sort
of
detailed
in
this
diagram.
You
can
see
there
are
three
different
attestra
applications
and
a
user's
browser
and
each
tester
application
is
managing
a
unique
identity
for
the
user
inside
of
the
browser,
local
storage
and
the
advantage
to
this
is.
We
can
treat
these
identities
more
like
web
2,
authentication
tokens
and
less
like
Bitcoin
or
ethereum
private
keys.
B
So,
instead
of
prompting
the
user
for
permission
to
do
a
signature
or
make
a
transaction,
we
just
in
the
background,
make
these
ZK
proofs
and
give
them
to
the
relayers
and
at
the
same
time,
when
we
use
different
identities
for
each
of
these
websites.
If
one
of
the
identities
is
compromised,
because
the
website
injects
some
malicious
JavaScript
or
does
something
like
this,
the
damage
is
contained
to
that
single,
a
tester.
B
But
at
the
same
time
we
want
a
testers
to
be
interoperable.
So
if,
for
example,
this
to
review
a
tester
wanted
to
get
a
proof
of
from
the
Cyber
resistance
tester.
How
could
we
do
that?
And
the
answer
is
basically
oauth
for
ZK,
so
for
so
in
this
example,
flow
I'm
trying
to
sign
up
for
this
review
a
tester
and
the
reviewer
tester
wants
a
proof
that
I
am
a
human
being
in
the
form
of
a
reputation
proof
from
this.
B
We
should
definitely
request
that
the
user,
Make
This
proof
because
we're
going
to
hand
it
to
a
different
third
party,
and
so
if
the
user
says
yes,
then
we
prove
that
we
have
like
the
reputation
and
we
sign
the
hash
of
the
sign
up
proof
to
prove
that
we're
the
same
person.
And
then
we
get
redirected
back
to
the
the
original
application
and
we
can
continue
sign
up.
So
using
this
flow
we
can
get
ZK
proofs
from
different
applications
into
different
sort
of
Origins
okay.
So
this
is
part
three
of
the
presentation.
B
B
So
let's
talk
about
call
data
first,
so
for
graph
16
we
have
about
130
bytes
per
proof
and
for
plonk
we
have
about
half
a
kilobyte
per
proof,
so
assume
that
we're
talking
about
EIP
like
a
post
eip4844
world,
and
we
have
two
megabytes
per
block
that
we
can
use
for
blob
data.
So
at
that
point
we're
able
to
do
1300
across
16
fruits
per
second
and
330
plonkers
per
second,
it's
not
not
terrible.
So
let's
open
door
number
two
and
look
at
the
verification
costs
so
across
16
of
Planck.
B
B
So
the
ethereum
maina
is
doing
two
and
a
half
million
gas
per
second
right
now,
they're
doing
30
million
gas
every
12
seconds
which
comes
down
to
this.
So
it
gets
to
verify
10
proofs
per
second
on
ethereum
Main
net,
so
on
arbitrum
and
L2,
for
example,
they're
doing
7
million
gas
per
second,
so
that
number
is
bumped
to
24
proofs
per
second.
B
So
we
see
an
obvious
bottleneck
here.
It's
the
verification
cost
on
chain,
and
these
numbers
are
also
extreme
upper
bounds.
This
assumes
that
we're
filling
entire
The
Blob
blocks
with
two
megabytes
of
ZK
proofs
and
we're
filling
entire
blocks
with
verification
of
ZK
proofs
and
not
even
factoring
call
data
all
right.
So
how
can
we
scale
unit
up
and
how
can
we
scale
ZK
proofs
in
general,
given
those
bottlenecks?
B
So
this
is
a
proof
from
the
U
interrupt
system
where
we're
generating
a
user
State
transition
and,
as
you
can
see,
there's
I
think
seven
public
signals
and
for
every
user
that
wants
to
join
a
new
Epoch.
We
make
one
of
these
and
put
it
on
the
blockchain
and
verify
it.
So
how
can
we
make
this
a
little
bit
more
efficient?
B
B
We
can
also
build
Asics
to
make
proof
of
it,
make
proofs
very
quickly
and
then
we're
able
to
see
the
sort
of
improvements
that
we
want
to
see
like
if
we're
able
to
bundle
10
proofs
at
a
time
we
get
a
10x
Improvement,
100x,
Etc
and-
and
this
does
introduce
a
little
bit
of
complexity
because
we
have
to
deal
with
approved
aggregator
and
now
the
user
potentially
has
to
like
wait
on
that
or
potentially
optimistically
evaluate
the
aggregator.
But
this
is
a
decent
approach
to
scaling
right.
B
So
now,
that's
most
of
the
presentation
I'm
just
going
to
talk
about
like
some
of
my
tester
ideas
that
I
think
are
kind
of
cool
that
we
can
build
with
unirp
or
the
other
Universe
protocol.
So
the
first
is
just
like
ZK
Dows.
We
can
keep
the
balance
hidden
or
the
balance
controlled
by
a
user
hidden
within
the
Dow.
We
could
also
do
things
like
vote
for
proposals
anonymously.
B
A
lot
of
interesting
ideas,
a
lot
of
interesting
things
that
can
be
done
with
this.
The
next
is
anticipal
reputation.
I
use
this
as
an
example
in
one
of
the
previous
slides,
but
what
you
could
do
is
basically
take
like
proofs
that
you
have
a
web
2
identity
and
give
reputation
for
that
or
potentially
use
like
bright,
ID
or
or
approve
that
you
have
like
poapps,
for
example,
and
just
get
reputation
and
then
use
that
to
sign
up
for
other
testers.
B
The
third
is
like
really
simple
and
generic,
which
is
a
recommendation
system
as
a
web
app.
Everyone
has
things
that
they
use
or
that
they
would
want
to
recommend
to
other
people.
You
having
like
reputation
for
good
recommendations,
seems
like
a
good
use
of
the
system
and
then
the
final
one
is
one
that
I
thought
of
when
I
was
given
the
Devcon
poapp
I
I
really
hate
claiming
co-ops
on
chain,
because
I'm
just
giving
people
a
history
of
like
the
places
I've
been
in
the
real
world,
which
I
think
is
kind
of
weird.
B
B
To
me,
at
least,
is
we
don't
have
the
space
to
use
trusted
setup
that
is
circuit
specific,
so
with
unirp,
we
want
people
to
extend
the
proofs
that
we've
written
and
write
their
own
to
build
their
own
functionality
and
with
Ross
16,
that's
very
difficult
to
do,
because
they
have
to
run
a
trusted
setup
ceremony
for
the
circuits
that
they
build,
and
this
is
a
huge
amount
of
coordination
and
effort,
can't
really
expect
most
developers
to
reasonably
do
so.
With
Planck
we
cut
all
the
head
out.
B
So
we
have
proofs
in
the
browser
using
snark.js,
but
you
have
to
like
configure
webpack
really
specifically,
and
it
also
uses
like
Z
key
and
webassembly
file
and
a
second
webassembly
file
for
a
curve
and
it'd
be
much
easier
if
we
had
a
tool
that
just
sort
of
bundles
all
of
that
into
a
single
web
assembly
that
we
can
run
in
the
browser
just
pass
in
signals
and
get
the
proof
back.
This
will
give
us
like
three
asynchronous
operation
as
well
yeah.
It
would
just
be
a
nice
thing
to
have
yeah.
B
That's
pretty
much
the
end
of
the
talk.
We
have
a
few
events
happening
related
to
unirap,
so
first
we
have
a
unwrap
workshop
on
Friday
at
10
30
a.m.
That's
going
to
be
on
the
first
floor
at
the
ZK
Community
Hub.
We
also
have
a
demo
at
Thursday
at
three
o'clock
in
the
same
place,
a
big
thank
you
to
Xerox
park
for
putting
on
those
events
and
inviting
us
to
participate,
and
then,
if
you
want
more
information
about
unirp,
you
can
go
to
github.com
unit
or
you
can
scan
this
QR
and
it'll.
B
C
A
product
standpoint,
or
maybe
from
the
user
perspective.
How
do
you
explain
the
need
to
sequentially
create
new
identities
in
order
to
remain
anonymous
and
also,
if
there's
a
way
to
apps
like
that,
maybe
save
it
in
the
session
in
the
browser
you
know:
appstock
the
user
away
from
such
a
involved
mechanism
of
creating
like
a
sudden
anonymous
name,
every
every
Epoch
sure.
B
B
We
can
do
this
silently
in
the
background
in
the
browser,
so,
like
the
user
enters
the
the
web
page
and
then
the
web
page
checks
if
they
need
to
generate
a
new
identity
and
if
they
do,
they
generate
a
ZK
proof
in
the
background
and
submit
it
to
a
relayer,
and
it's
done
yeah,
there's
not
a
way
to
make
that
less
manual
without
changing
the
architecture
of
the
system.
Like
pretty
substantially,
though.
D
B
Yeah,
so
the
state
transition
happens
anytime.
You
want
to
move
to
a
new
Epoch.
So
if
you
are
participating
consistently,
then
yeah,
it's
every
Epoch
we
can
adjust
or
testers
can
set
the
epoch
length
themselves,
though
so
this
could
be
like
pretty
short,
maybe
one
hour
or
it
could
be
like
a
week
or
it
could
be
a
month
or
anything
like
that
and
we're
also
planning
to
make
it.
B
F
I
would
be
curious
to
understand
if
you
have
like
more
detailed
thoughts.
In
particular
two
questions.
I
was
thinking
of
those
like
one.
If
you
don't
have
your
I
guess
proof
in
call
data.
Instead,
it's
in
the
blob,
you
would
have
to
verify.
There's
some
batch
proof
right,
opening
your
Kate
polynomial
inside
this
narc
and
then
doing
recursive
rules
or
I.
Guess
what
is
the
exact
setup,
you're
thinking
of.
B
B
But
this
still
involves
like
the
aggregator
receiving
the
full
proof
and
then
like
calculating
the
hash.
We
honestly,
we
haven't
gotten
we're
not
really
close
to
doing
that
yet
like
we're,
proving
especially
for
like
solidity.
Approvers
are
a
little
bit
far
out
but
yeah.
It's
probably
going
to
be
some
sort
of
optimistic
system,
so
the
user
experience
is
pretty
good.