►
From YouTube: Decentralized Programmable Key Pairs | Devcon Bogotá
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/decentralized-programmable-key-pairs/
Join this talk to get an introduction to Decentralized Programable Key Pairs (PKPs), by Lit Protocol.
PKPs are 'distributed custody cloud wallets' that act as a personal compute platform that can write to a variety of state machines (e.g Ethereum, IPFS) because they are 'smart contracts with a secret' that can make arbitrary HTTP requests and use that data in the computation.
Speaker(s): David Sneider, Chris Cassano
Skill level: Intermediate
Track: Developer Infrastructure
Keywords: decentralized compute,threshold cryptography,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
A
My
name
is
David
Snyder,
that's
Chris,
casano
and,
as
you
can
see,
we're
going
to
talk
about
decentralized,
programmable
key
pairs.
We
are
the
two
co-founders
of
a
project
called
lit
protocol
and
to
start
with
a
big,
exciting
hook.
We
are
living
in
a
world
where,
with
threshold
cryptography,
from
a
certain
point
of
view,
you
can
consider
that
private
Keys
no
longer
exist.
So
what
do
we
specifically
mean
by
this?
A
This
netlit
network
is
essentially
a
distributed,
custody
programmable
key
and
one
of
the
key
Technologies
at
the
heart
of
this
is
something
called
a
dkg,
a
distributed
key
generation,
and
so
what
lit
is
specifically
is
a
distributed
network
of
nodes
that
are
custodying
shares
of
an
underlying
private
key
I'll.
Take
a
quick
moment
to
talk
about
how
security
works
on
this
network
and
then
we'll
get
into
some
of
the
use
cases.
But
essentially
this
key
is
formed
in
this
distributed
key
generation
context
and
stored
as
shares
across
the
these
nodes.
A
And
then
all
the
nodes
operations
take
place
inside
of
a
trusted
execution
environment
and
then
there
are
named
node
operators
who
are
staking
that
are
running
the
programs
on
this
underlying
key,
and
so
now,
let's
talk
about
what
some
of
those
programs
can
be.
So,
as
you
know,
a
key
can
functionally
do
two
things
it
can
read
or
encrypt
and
write,
and
this
network
provides
the
same
functionality
in
a
programmatic
way.
So
let's
talk
about
how
the
read
works.
First,
the
hexagons
in
the
middle
represent
the
lit
nodes.
A
In
this
case,
Alice,
let's
say,
is
a
Creator
and
wants
to
say
anybody
who
owns
Alice's
nft
can
see
her
video.
She
would
encrypt
that
video
client
side
and
store
it
somewhere
in
public,
whether
it's
on
a
blockchain
or
a
storage
Network
like
ipfs
and
then
create
a
set
of
rules.
That
says
only
somebody
who
owns
Alice's
nft
can
see
that
video
Bob
owns
that
nft.
He
shows
up
later.
He
signs
a
message
and
he
broadcasts
that
to
the
nodes.
A
Each
of
the
individual
nodes
validates
against
the
blockchain,
does
Bob
own
that
nft
and
the
whole
kind
of
frame
of
view.
Here
is
thinking
about
these
Public
Storage.
Excuse
me:
public
State
machines,
as
Access
Control
lists,
at
which
point
the
nodes
verify
that
Bob
has
that
node
or
excuse
me
has
that
nft
and
each
of
the
individual
nodes
produces
something
called
a
decryption
share.
A
You
could
think
about
this,
like
an
authorization,
those
authorizations
are
then
sent
to
Bob
who's,
collecting
them
client-side
and
a
good
mental
model
is
kind
of
similar
to
the
way
that
you
may
think
about
torrenting.
You
know
torrenting
you're
collecting
little
bits
of
media
from
a
bunch
of
nodes,
in
this
case,
you're
collecting
bits
of
authorization
and
once
you've
collected
a
threshold
of
those
authorizations.
A
In
this
case,
decryption
shares
Bob
can
reproduce
that
symmetric
key
associated
with
the
video
or
that
content
and
decrypt
that
client
side,
and
so
some
of
the
applications
that
we're
seeing
this
used.
For
today,
a
are
things
like
token
gated
social
media
like
tokengated
chat.
This
technology
is
used
hand
in
hand
a
lot
with
like
the
lens
protocol,
for
example,
where
only
let
somebody
who's
following
me
on
on
lens
see
my
posts.
A
A
But
in
a
way
this
is
kind
of
one
definition
of
web3
where
the
user,
rather
than
necessarily
showing
up
to
a
website
with
their
own
kind
of
self-sovereign
server,
they're
arriving
with
their
own
encrypted
Shard
of
the
open
web
and
then
selectively,
disclosing
two
various
friends
or
applications.
What
information
from
that
Shard?
They
can
decrypt
or
read,
and
so
this
product
has
been
out
since
January.
We
still
are
running
all
the
nodes
centrally
and
we'll
have
those
decentralized
by
the
end
of
the
year
and
there's
hundreds
of
applications
that
are
leveraging
this.
A
We
kind
of
like
think
about
it
as
a
paintbrush,
we're
really
just
starting
to
explore
some
of
the
application
potential
here,
but
I'll
run
through
a
couple
right
now,
so
one
would
be
like
defy
automation.
The
state
of
the
art
for
self-custody
defy
today
is,
if
you
have
some
staked
tokens
and
you
have
to
the
state
of
the
artist
to
sign
up
for
some
defy,
alerting
Service
Such,
that
when
the
price
starts
to
drop,
you
get
a
text.
You
have
to
wake
up
in
the
middle
of
the
night
and
push
a
button
on
your
Ledger.
A
But
in
a
world
where
you've
staked
those
tokens
from
one
of
these
Cloud
wallets,
as
we
can
kind
of
call
them,
you
could
have
that
program
listening
to
a
feed
and
when
the
price
drops
have
a
program
that
kicks
off
that
unstakes.
The
tokens
sells
them
for
usdc
on
a
decks
and
sends
them
to
your
Ledger,
and
this
is
all
happening
kind
of
without
a
human
signer
in
the
loop,
because
the
key
is
custody
in
this
distributed
context
at
the
network
level.
A
Chris
will
talk
a
little
bit
more
about
vaults,
but
in
a
way
what
we're
talking
about
here
is
making
private
Keys
liquid.
So
you
could
send
a
bunch
of
nfts
and
tokens
to
a
given
address
and
then
trade.
The
underlying
ownership
of
that
address,
there's
also
a
lot
to
explore
here,
as
it
relates
to
account
abstraction
doing
things
like
cooking
up
a
biometric
auth
like
apple
Pass,
key
as
the
auth
method
into
one
of
these
Cloud
keys.
A
In
this
whole
context
of
how
do
we
bring
the
next
billion
users
into
this
ecosystem
and
Abstract
away
the
complexity
associated
with
the
seed
phrase?
This
is
really
exciting
and
certainly
a
lot
to
explore
in
the
context
of
cross-chain
messaging
and
bridging
as
well,
and
so
with
that
I'll
pass
this
clicker
off
to
Chris.
B
Thank
you,
David
yeah,
so
I'd
like
to
introduce
the
idea
of
a
decentralized
programmable
key
pair,
which
we
call
pkps.
A
pkp
is
an
ecdsa
key
pair,
that's
held
as
private
key
shares
custody
by
the
lit
nodes.
You
can
create
a
pkp
by
minting
an
nft
that
represents
ownership
over
that
pkp,
and
so
whoever
owns
that
nft
can
ask
the
pkp
to
sign
anything
on
their
behalf,
including
ethereum
or
even
Bitcoin
transactions.
B
B
Lit
actions
live
on
itfs
and
are
immutable
just
like
smart
contracts
and
I
just
explained
that
whoever
owns
the
pkp
nft
can
request
a
signature
using
the
pkp,
but
what's
actually
more
interesting
is
that
you
can
also
Grant
the
ability
to
sign
using
your
pkp
to
a
lit
action.
This
is
very
similar
to
the
Token
approval
pattern
that
we
use
on
ethereum,
where
you
can
grant
a
smart
contract.
The
ability
to
transfer
your
tokens,
but
instead
of
granting
the
ability
to
transfer
tokens
you're,
granting
the
ability
to
sign
anything
with
this
programmable
key
pair.
B
B
To
add
a
laser
cool
and
they
pass
in
an
itfs
CID,
which
is
some
JavaScript
code
and
a
cryptographic
signature
that
could
come
from
their
ethereum
wallet
and
apple
Pass
key
or
any
public
key
cryptography
scheme.
They
send
that
execution
request
to
all
of
the
lit
nodes.
In
parallel,
the
lit
nodes
use
a
JavaScript
runtime
to
execute
the
lit
action
from
ipfs.
B
B
B
They
combine
those
signature
shares
and
they
broadcast
that
signed
transaction
to
ethereum
or
any
ecdsa,
blockchain
and
I'm
talking
about
a
transaction
here,
but
it
doesn't
actually
have
to
be
a
transaction.
It
could
be
any
signed
data
like
a
right
on
a
ceramic
or
anything
else
like
that.
An
interesting
pattern
that
Lit
supports
is
called
mint
Grant
burn.
B
B
A
kind
of
fun
toy
example
would
be
creating
a
lit
action
that
takes
any
number
as
input,
but
will
only
sign
that
number.
If
it's
Prime,
since
anyone
can
check
that
the
signature
matches
the
public
key
of
the
pkp,
they
know
that
any
number
signed
by
the
corresponding
private
key
must
be
Prime
and
the
signature
acts
like
a
proof
that
the
number
is
prime.
B
The
the
way
that
you
interact
with
and
Grant
access
to
use
things
is
by
talking
to
a
pkp
Smart
contract
that
currently
lives
on
cello,
but
we're
going
to
move
that
to
polygon
soon
and
you
mint
the
pkp
grant
access
for
it
to
use
the
lid
action
in
this
authorized
lid
action
table,
and
then
you
burn
it
all.
In
one
transaction,
we
talked
a
little
bit
about
using
a
pkp
as
a
vault.
B
You
can
mint
a
pkp,
then
send
a
bunch
of
assets
to
it
like
nfts
tokens,
ethereum
and
even
ones,
not
on
ethereum,
like
Bitcoin
or
Cosmos
tokens,
then
you
can
sell
the
pkp
nft
on
openc
and
transfer
all
the
assets
at
once.
You
are
essentially
trustlessly
trading,
a
private
key,
something
that
has
been
impossible
until
now.
B
B
B
B
B
B
A
Out
we
could
talk
about
some
of
these
ideas.
I
think
is,
is
worth
pointing
to,
but
maybe
just
a
few
more
metaphors,
like
one
of
the
ways
that
I
really
like
thinking
about
this
programmable
key
pair
notion,
what
we've
been
calling
a
pkp
in
a
way
like
the
centralized
equivalent
is
thinking
about
this,
like
an
Amazon
Lambda
function,
plus
the
Amazon
KMS.
A
But
in
this
case
the
KMS
isn't
something
that's
centralized
it's
distributed
across
this
threshold,
cryptography
based
Network
and
these
lit
actions
are
the
equivalent
of
the
land
Lambda
functions,
and
so
it's
this
distributed
system
for
doing
the
same
type
of
operations
that
you
would
build
with
Lambda
function
and
Amazon's
KMS.
But
in
this
case
you
as
the
application
developer.
A
When
you
come
and
bring
customers
on
board,
you
have
this
kind
of
distributed
back
end
where
you
can't
get
access
to
the
keys
where,
if
you
like,
build
the
defy
automation,
bot
and
start
selling
to
somebody
as
a
subscription
today,
you
you
could
jump
into
Amazon's
KMS
and
grab
the
keys
and
the
funds
out
at
any
point.
A
couple
other
interesting
things
that
I
think
are
really
fun.
To
think
about,
when
we
start
to
think
about
the
notion
of
kind
of
this
Cloud
key,
there's
a
lot
of
implications
for
this
as
a
Dows
key.
A
Algorithm
starts
to
get
really
interesting
because
you
can
have
the
same
rules
around
governance,
issuing
verifiable
credentials
for
your
Dao,
making
transactions
on
eth,
doing
right
to
rights,
to
ceramic
all
from
the
same
underlying
curve
and
then
yeah
I
think
another
one.
That's
kind
of
really
interesting
here
is
thinking
about
this
in
the
context
of
mainstream
adoption.
We
touched
on
this
a
little,
but
you
know
there's
always
capacities
to
add
different
levels
of
authorization
and
security
to
wallets.
A
But
we've
been
really
really
excited
about
groups
that
have
started
to
integrate
this
with
the
likes
of
Discord
and
apple
Pass,
Key,
and
there's
definitely
a
lot
of
opportunity
to
build
really
sophisticating
Tooling
in
this
ecosystem.
It's
one
of
the
reasons
that
we're
really
excited
to
give
this
talk
like
we
have
a
core
team.
That's
super
focused
on
this
threshold,
cryptography
component,
but
there's
all
kinds
of
opportunities
to
like
stick
an
email
server
inside
of
an
enclave
and
use
that
as
a
methodology
for
authorizing
this
with
email.
A
That's
something
that
we're
not
going
to
build
internally,
and
so,
if
that's,
if
this
kind
of
tooling
and
privacy,
tooling
and
mainstream
adoption
tooling,
is
something
that
you're
interested
in
definitely
come
talk
to
us
us,
but
yeah.
Maybe
we'll
keep
this
slide
up
and
we'll
take
questions
for
the
next
10
minutes.
If
there
are
any
thanks
so
much.
B
B
B
C
B
Absolutely
yeah,
so
we
use
a
technology
called
proactive
secret
sharing
and
what
that
lets
us
do
is
it
lets
the
the
nodes
like
new
nodes,
join
and
leave
the
network
and
keep
the
underlying
secret
the
same,
but
the
private
key
Shares
are
incompatible
between
like
epochs
when
it
when
nodes
leave
and
when
nodes
join.
Basically.
A
The
this
process
of
proactive
secretaring
is
quite
similar
to
the
distributed
key
generation
process,
and
you
know
the
the
secret
is
very,
very
simply
put
right
a
line
on
a
graph
and
in
this
key
refresh
process,
you're
signing
new
points
along
the
same
underlying
secret,
such
that
the
shares
in
Epoch
2
are
incompatible
with
Epoch
one,
but
they
still
represent
the
same
underlying
secret
and
that's
functionally.
The
goal
of
this
network
is
to
persist
a
shared
Crypt,
photographic,
Secret
in
perpetuity.
C
Okay,
I
think
that
that
ties
into
my
third
question,
which
is
how
do
you
ensure
kind
of
like
the
any
form
of
like
non-so
like
counters,
so
that
you
know
essentially
like
the
number
of
time
that
this
thing
has
been
signed
or
like
decrypted?
Maybe
you
want
to
like
ensure
it
that,
like
you
know,
you
can
decrypt
it
x
amount
of
times
you
don't
want
to.
C
You
know
you
you
may
want
to
like
sequence
essentially,
especially
for
vaults,
like
operations
right
like
the
signing
of
like
specific
nonsense
or
like
just
ensuring
that,
like
you,
you
don't
have
is
essentially
just
like
resigning
operations
with
different
announces
either
I'm
actually
curious.
How
do
you
think
about
that?.
B
B
D
B
Do
yeah
I
mean
they
need
some
kind
of
key
right,
it
could
be
an
ethereum
wallet
or
it
could
be
like
apple
passkey,
which
is
like
one
click
and
they
generate
a
public
private
key
pair
for
you,
that's
backed
up
to
your
iCloud
in
an
encrypted
way.
It
could
also
be
like
potentially,
a
web
2
auth
method
like
Discord
login.
B
D
A
B
Like
the
number
threshold
like
yeah,
we're
using
two-thirds
right
now
and
that's
like
hard-coded
across
the
network,
so
it's
not
user,
changeable
and
yeah
and
we're
using
you
know:
ecdsa
non-interactive,
signing
on
the
the
signing
side
and
then
on
the
encryption
and
decryption
side
we're
using
BLS
keys
super.
We.
D
A
A
Oh,
it's
just
people
makes
the
network
be
able
to
become
like
more
Dynamic
over
time,
but
currently
there
is
the
capacity
for
new
nodes
to
join
the
network
and
for
the
key
to
be
refreshed,
creating
those
new
shares
in
Epoch,
two,
three,
four
and
so
on,
and
then
practically
in
terms
of
the
plan
by
the
end
of
the
year.
This
network
will
be
up
with
a
handful
of
named
node
operators
and
then
those
node
operators
are
functionally
a
Dao
of
sorts
that
decide
who
comes
in
and
who
comes
out
to
the
system.