►
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 IPFS and more.
https://archive.devcon.org/archive/watch/6/zkemail-decentralized-id-verification-on-chain-without-servers/index
We demo zk-email, a new primitive that lets you verify emails trustlessly. We demo a simple trustless Twitter badge on chain, and show how almost any data in web2 can be turned into trustless badges or zk badges on a blockchain. Launching with Personae Labs!
Speaker(s): Aayush Gupta, Sampriti Panda
Skill level: Beginner
Track: ZKPs: Privacy, Identity, Infrastructure, & More
Keywords: zk
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
Yeah,
so
we
have
a
UI
build
up,
it's
pretty
primitive,
but
the
idea
is
that
it
we
know
ZK
is
not
efficient
now.
So
it's
going
to
take
a
couple
of
minutes
to
run
this
proof.
So
hopefully
it
works.
I,
don't
know
if
this
internet
is
gonna,
oh
it
did
click
nice,
so
we're
gonna.
Let
this
proof
run
and
then
we'll
come
back
to
it
at
some
point
later
and
see
if
it's
generated.
B
Yeah
and
I
want
to
say,
like
this
project,
has
a
lot
of
people
behind
it.
Like
we've
used
a
work
from
a
lot
of
Open
Source
libraries,
a
lot
of
people
who've
helped
us
and
behind
the
scenes,
and
these
are
some
of
the
names
who
are
also
in
the
crowd,
but
we
can't
mention
all
of
them.
So
thank
you
to
everyone
again.
A
So
today,
we're
going
to
talk
about
trustless,
email
verification
on
chain
is
trust
us
in
the
sense
that
we
don't
run
our
own
server.
So
we
don't
see
any
of
your
private
data
but
at
the
same
time
we
are
trusting,
because
this
is
an
interoper
early
protocol
between
web
2
and
web3.
We
are
trusting
mail
servers
and
DNS
to
be
operating
as
they
should,
but
we
do
not
operate
any
of
our
own
infrastructure.
A
So
what
exactly
is
proof
of
email
or
a
ZK
email?
Well,
every
time
you
receive
an
email,
you
have
to
know
that
it
came
from
the
source
that
it
claims
to
be
coming
from,
and
so
one
might
imagine
a
great
way
to
do.
This
is
signatures,
so
what
they
effectively
do
is
every
email
you
receive
is
RSA
signed
with
a
shot
256
of
the
from
address.
The
two
address,
the
subject
and
a
body
hash
along
with,
and
this
entire
hash
is
RSA
signed
with
the
key
belonging
to
the
email
mail
server
domain.
A
C
A
A
A
A
The
things
we
want
to
keep
private
are
all
the
information
that
does
not
relate
to
what
the
user
wants
to
release.
That
is
specifically
the
entire
Deacon
signature
would
de-anonymize
them,
because
a
mail
server
would
know
who
they
are
the
length
of
the
pre-hatched
message,
data
or
general
lens
that
we
pass
around
to
ensure
that
computation
is
efficient
and
all
of
the
raw
data.
So
the
raw
message
data,
the
raw
slender
data,
the
identity,
is
everyone
involved
in
the
circuit.
A
Finally,
in
a
smart
contract,
we
verify
the
things
that
are
very
either
very
expensive
to
do
in
a
snark
or
have
to
be
done
on
a
decentralized
layer.
So
things
like
verifying
the
sender
domain
is
actually
the
center
domain,
that
people,
trust
and
verifying
the
claimed
RSA
key
is
an
RSA
key
that
people
Trust.
B
Let
me
go
see
if
the
demo
is
done,
so
it's
still
going
on
so
I'll.
Just
like
talk
about
some
of
the
innovations
that
we
did
so
obviously
one
of
the
things
he
noticed
was
regex
and
we
also
had
to
do
a
bunch
of
Shadow
56
inside
the
proof.
Now,
since
we
want
this
to
run
in
the
browser
like,
obviously
we
don't
want
people
to
have
to
send
their
email
to
a
private
server
that
we
own
and
then
we
are
on
the
proof.
B
So
everything
has
to
be
done
in
the
browser,
which
means
it
has
to
be
very
efficient.
So
we
had
to
use
some
tricks
to
make
sure,
like
our
proof,
runs
within
like
a
reasonable
amount
of
time.
So
one
of
the
things
was
shout
out:
56
hashing.
So
we
have
like
this
really
long,
email
body,
let's
say
like
the
one
that
Twitter
sends
us
is
like
16
kilobytes
and
if
we
try
to
just
hash
that
entire
thing
in
like
inside
a
circuit,
then
like
it'll,
take
like
millions
of
constraints.
So
what
we
realized
was.
B
We
could
only
take
the
part
of
the
message
body
that
contains
the
username.
We
want
which
is,
for
example,
the
Twitter
username,
which
is
at
the
end
of
the
circuit,
and
we
can
only
do
that
part
of
the
hash
inside
the
circuit
and
we
can
hash
the
first,
like,
let's
say,
10
000
circuit
in
like
and
pass
it
as
a
private
input.
Now
this
doesn't
really
break
any
security
guarantees.
Since
we
still
check,
we
just
checked
that
the
the
final
hash
is
equal
to
whatever
is
like
signed
by
the
mail
server.
B
And
if
you,
if
you,
if
you
could
break
this,
then
you
would
basically
be
calculating
a
pre-image
for
the
hash.
So
it's
the
same
security
properties,
but
we
don't
have
to
do
as
many
like
computations,
the
other
one
is
obviously
verifying
regex,
so
email,
headers
and
email
protocol
is
like
a
very
tricky
thing.
B
Oh
I,
didn't
I
didn't
even
see
this,
so
email
is
a
very
tricky
thing
where,
like
it
can
be
in
many
different
orders
and
there's
no
specific
structure.
So
it's
hard
to
verify
that
within
the
stock
and
like
just
using
IF
else,
checks
and
obviously
the
first
thing
that
comes
to
mind
is
kind
of
like
when
you
try
to
pass
the
email
addresses
to
use
the
regex
right.
So
that's
kind
of
the
most
simplest
thing
that
would
provide
more
security,
but
there's
no
obvious
way
to
do
regex
inside
a
snug
in
efficient
way.
B
B
So
if
the
letter
is
H,
then
you
go
from
one
to
two
and
if
there's
an
e
after
that-
and
you
go
from
two
to
three
and
obviously
at
any
point,
if,
like
a
letter
doesn't
exist,
then
you
kind
of
fail
and
you
just
go
back
to
the
beginning.
So
in
this
case,
if
we
get
to
the
last
state
which
is
12,
then
we
accept
so
it.
So.
B
B
B
Just
let
this
play
here
so,
as
you
can
see
like,
we
have
all
the
extra
data
masked
out
and
only
the
things
we
want
to
show
so
like,
for
example,
twitter.com
to
gmail.com,
and
then,
if
we
go
down
to
the
end,
we
have
the
username,
which
is
uses
username
from
the
circuit.
So
those
are
the
things
that
only
the
public
input
from
the
circuit
and
everything
else
remains
private
and
since
all
of
this
was
verified
using
a
proof
you
can
kind
of.
A
So
some
precautions
of
this
technology
before
we
dive
into
specific
use
cases
or
that
this
enables
a
tragedy
of
the
commons
on
institutional
reputation.
Now
what
this
means
is
that
using
ZK
email
you
can
prove
processly
that
you're
part
of
some
organization
and
post
or
act
on
behalf
of
the
organization
without
spending
your
own
personal
reputation
and
as
a
result,
for
the
first
time
effectively
ever.
You
can
spend
institutional
reputation
and
have
no
cost
to
yourself
and
no
account.
A
A
It
can
be
argued
that
you
want
to
be
able
to
argue
at
some
point
in
time
that
you,
you
can
deny
that
you
sent
an
email
and
so
the
way
that
a
lot
of
mail
servers
do.
This
is
every
year
or
six
months,
they'll
rotate
their
mail
server
keys
and
release
their
past
keys,
and
some
of
them
will
even
release
the
past
secret
Keys,
meaning
that
if
you
get
an
email
more
than
a
year
old
that
someone
could
have
easily
forged
it
using
that
secret
key
that
was
released.
A
A
And
finally,
one
interesting
thing
is
that
if
we
want
a
nullifier,
that
is
something
that
would
avoid
people
from
claiming
again
and
again
and
again
their
identity
on
chain
or
possibly
selling
this
identity.
Even
then,
we
have
to
allow
another
fire
which
is
derived
from
the
information
in
the
email,
but
this
would
allow
the
sending
mail
server
to
de-anonymize
someone
and
so
there's
a
trade-off
here
where
you
can
either
have
uniqueness
and
anonymity
or
you
can
have
the
mail
server
able
to
de-anonymize
the
people
who
are
interacting
with
the
protocol.
A
A
You
can
do
oracles
if
oracles
send
emails
to
you
with
information,
say
price
feeds
or
any
other
information
that
you
want
on
chain.
You
can
simply
verify
these
email
headers
on
chain
and
not
have
any
centralized
server
that
you
trust
or
decentralized.
Networker
verifies
that
you
have
to
trust
to
accurately
represent
this
data.
A
I
can
keep
going
on
and
on,
but
you
can
imagine
that
any
data
that
you
can
have
in
an
email
you
can
verify
on
chain
using
this
primitive.
This
is
extremely
powerful
for
decentralized
and
Anonymous
applications.
I
mean
things
are
going
to
enable
a
whole
new
era
of
ideas
for
residents
you
can
do
by
proving,
for
instance,
you
have
a
gas
bill
or
a
water
bill.
A
The
oracle's
Glassdoor
and
the
number
of
anonymous
groups
you
can
create
is
also
quite
unlimited.
You
can
prove,
for
instance,
groups
of
people
who
have
10
million
Twitter
followers
or
people.
You
can
prove
that
you
made
some
call
option
on
Robinhood
that
went
really
well
or
you
can
prove
that
you're.
You
have
some
dollar
bill
bank
account
dollar
bills
in
your
Chase
account,
because
Chase
actually
sends
your
balance
to
you
in
plain
text.
If
you
request
it,
I.
B
Just
want
to
point
out,
one
thing
is
like
right
now:
the
one
thing
we
have
to
rely
on
is
DNS,
so
either
we
hardcore
the
DNS,
the
DNS
Keys,
the
keys
in
the
DNS
in
in
the
contract,
where
we
get
it
from
chain
link.
Now,
if
only
we
had
something
called
dns6
which
had
actually
taken
over,
because
if
we
could
have
actually
done
all
of
this
on
in
a
contract,
because
we
could
have
just
verified
the
certificate
like
to
the
root
trust,
but
unfortunately
nobody
ended
up
using
DNS
SEC.
A
Is
you
have
to
go
through
these
four
steps,
but
you'll
notice
that
there
is
no
sending
to
server
involved
and
we
had
a
great
brainstorming
session
in
the
morning
in
which
we
got
a
ton
of
these
ideas
together.
So
kudos
to
all
the
people
came
to
the
morning
session,
helped
us
come
up
with
the
ideas
that
you
saw
earlier
awesome.
Thank
you
so
much
and
we'll
take
any
questions.
C
So
so
the
the
NSA
example
is
cool,
because
it's
like
oh
Edward
Snowden
could
have
done
this
without
revealing
his
identity,
but
on
the
flip
side
a
Russian
spy
within
the
NSA
could
also
just
reveal
all
the
nsa's
information
and
never
reveal
who
they
are.
How
are
you
guys
thinking
about
how
to
prevent
stuff
like
this
from
happening
or
what
safeguards
can
we
build.
A
Yeah,
this
is
a
great
question,
and
this
kind
of
comes
back
to
the
tragedy
of
the
comments
point
that
we
brought
up.
I.
Think
part
of
this
is
that
you
have
to
enable
some
amount
of
accountability,
ideally
in
these
situations-
and
this
can
come
in
the
form
of
say,
like
upvotes
and
downvotes,
where,
if
a
certain,
if
you
have
like,
say
a
nullifier
associated
with
a
certain
account
or
certain
address-
and
this
account
gets
a
certain
number
of
downvotes,
then
you
can
hide
this
from
feeds
that
are
being
shown
to
users.
A
Although
the
data
will
forever
be
immutable,
Unchained
from
the
perspective
of
users
who
might
benefit
from
this
or
get
harmed
by
this,
you
can
at
least
do
your
best
to
Shield
them
from
it.
But
part
of
it
is
that
it's,
it
might
be
very
difficult
to
solve
these
problems,
and
it
requires
a
lot
of
thought
to
think
about
how
to
do
this
very
carefully.
That's
a
great
question,
though,
is.
D
Is
thank
you
I'm
from
unipas
and
finally,
somebody
discovered
the
emails.
We
are
also
using
emails
as
a
proof
of
ownership
of
the
Smart
Control
wallet
and
my
question
is:
how
is
the
cost
of
the
dkp
on
chain?
Like
you
know,
you
have
to
verify
Isa
signatures,
you
have
to
verify
the
key
proof,
so
we
are
building
the
same
solution
so
I
wonder:
what's
your
benchmark
now,
yeah.