►
From YouTube: IETF103-DINRG-20181106-0900
Description
DINRG meeting session at IETF103
2018/11/06 0900
https://datatracker.ietf.org/meeting/103/proceedings/
A
Good
morning
and
welcome
to
the
dinner
G
session,
I
found
this
place
difficult
to
locate
and
I
assumed
other
people
may
have
as
well
as
usual.
We've
got
our
IPR
policy,
also
known
as
the
note.
Well,
if
you
haven't
seen
it
before,
give
it
a
look,
it
covers
what
it
covers:
IRT
FIP
our
rolls
so
for
those
who
aren't
familiar
with
it,
our
mailing
list
is
here.
We
are
not
actively
maintaining
the
wiki
at
this
point,
but
pass
material
is
on
it
at
that
URL
and
here's
the
agenda.
B
A
C
D
A
D
A
D
And
so
the
core
of
this
draft
is
to
take
the
common
elements
from
all
of
these
structures
and
to
combine
them
into
a
data
structure
that
keeps
all
of
these
mappings
in
one
place.
And
then
we
leverage
each
of
the
parties
that
has
a
stake
in
keeping
these
mappings
secure
to
power,
an
underlying
consensus
layer
that
Giuliano
and
David
are
going
to
talk
about
in
a
little
bit.
So
that's
the
basic
structure
of
the
draft.
D
We
take
a
look
at
the
structure
very
simply
at
the
top
there's
a
root
key
listing
for
different
applications,
there's
a
series
of
links
to
different
tables,
with
key
value
mappings
and
in
those
in
those
tables.
You
can
these
cells
that
define
delegations.
So,
for
example,
if
I
want
Berkeley
to
maintain
a
set
of
domain
zone
files,
then
I'm
going
to
delegate
the
ability
to
a
key
owned
by
Berkeley
to
manage
this.
D
These
tables
kind
of
compose
themselves
recursively
until
you
get
down
to
leaf
cells,
which
are
value
cells
where
you
can
actually
map
to
the
actual
zone
file.
So
that's
you
know
the
five-second
description
of
what
the
draft
actually
does
and
now
I
want
to
go
into.
Some
updates.
Ok
updates,
a
couple
things
we
change.
The
first
is
we
change.
The
prefix
only
delegation
makes
everything
kind
of
simpler
in
the
draft
and
we
notice
that
for
pretty
much
any
scheme
that
you
use
for
delegation,
you
can
always
really
map
it
to
this
system.
D
So
that's
what
we
did.
For
example,
you
can
just
reverse
the
order
of
domains
to
get
a
nice
prefix
delegation
structure.
Second
thing
we
did:
is
we
simplified
an
update,
the
verification
rules,
so
there
are
more
details
in
the
draft
itself,
but
essentially,
if
they're
valid
time
stamps
and
the
fields
changed
or
signed
by
the
parties
authorized
to
change
those
fields
and
the
cell
doesn't
violate
the
prefix
property,
then
it's
a
valid
update
and
can
be
applied.
D
Third
thing
we
flushed
out
is
a
bunch
of
security
considerations,
so
discussions
on
how
the
system
actually
behaves
in
the
face
of
several
types
of
compromises.
The
nice
thing
is
that,
because
this
is
based
on
a
consensus
layer
with
a
lot
of
nice
security
properties,
those
properties
bubble
up
to
the
actual
structure.
Here
and
finally,
we
introduced
the
notion
of
these
table
allowances.
D
This
gives
a
total
upper
bound
on
the
size
of
delegation,
trees,
recursively,
where
you
can
just
sum
the
number
of
leaf
cells
and
the
allowances
you've
given
to
delegations
to
you
know,
stay
underneath
that
boundary,
and
so
this
is
important.
I
want
to
talk
about
this
for
the
rest
of
the
time,
because
for
the
first
time,
we've
made
a
change
to
the
draft
that
deals
with
how
we
govern
the
structure
itself,
how
we
decide
which
entries
are
valid
or
invalid,
based
on
some
sort
of
restrictions.
D
So
I
want
to
talk
about
this
governance
issue
because
that's
come
up
in
several
meetings
in
the
past,
so
I
think
it'd
be
good
to
talk
about
it.
Ok,
governance.
The
nice
thing
about
the
structure
right
now
is
that
it
gives
us
a
very
clean
separation
of
concerns.
So
on
one
hand,
there's
the
generic
structure
safety.
D
That's
the
delegation
rules,
the
update
rules,
you
know
who
can
modify,
which
cell
and
the
global
consistency
that
every
client
looking
at
the
structure
will
see
the
same
value,
mappings
and
that's
handled
by
the
consensus
and
there's
a
very
clean
split
between
that
and
all
the
you
know
nitty-gritty
details
like
which
table
should
be
in
or
which
entry
should
be
in
each
table
and
who
actually
gets
to
a
subset
of
the
namespace
who
gets
the
delegations?
How
do
you
remove
cells?
How
do
you
renew
cells-
and
the
nice
thing
about
that
is?
D
We
can
always
in
most
cases,
point
to
the
one
person
as
the
ability
to
make
those
decisions
which
are
the
table
authorities
and
that's
useful,
because
there
are
a
lot
of
real-world
systems
that
we
already
have
to
maintain
these
mappings,
that
we
don't
need
to
recreate
inside
the
structure.
So
this
is
a
very
well
and
good,
but
there's
one
kind
of
side
case
that
actually
bridges
the
gap
which
is
comp
knowing
and
that's
the
root
key
listing.
D
The
issue
is
that
it's
content
specific
because
each
of
the
applications
are
rooted
there,
but
there's
no
actual
single
Authority
that
we
can
point
to
you
like
I,
Anna,
to
say.
Okay,
you
need
to
you,
know,
modify
or
maintain
who
is
actually
in
this
listing.
So
this
issue
is
not
really
solvable
with.
D
You
know
the
table
authorities
or
straight
consensus,
and
so
what
we
propose
here
is
that
we
strengthen
the
idea
of
consensus
with
a
voting
system
and
by
doing
so
we
can
lump
in
the
root
key
listing
administration,
with
all
of
the
safety
of
the
safety
measures
that
were
already
taking
with
consensus.
And
so
what
is
voting?
D
I
mean
it's
pretty
simple:
it's
it
gives
consensus
and
as
the
agency
to
actually
make
decisions
on
certain
updates
to
the
trees,
so
they
can
either
vote
for
or
against
changes
to
the
root
key
listing,
and
it's
an
explicit
additional
requirement,
because
there
are
some
consensus
schemes
like
pbft,
for
example,
they
don't
actually
have
a
voting
system
right.
So
you
can't
actually
do
this
with
you
know
classic
consensus.
The
nice
thing
is
that
a
lot
of
existing
systems
already
have
something
like
this
built
in
so
SVP
and
slice
infrastructures.
D
They
have
quorums,
which
naturally
kind
of
translate
to
this
type
of
voting.
And
you
know
you
have
you
know
bitcoin.
You
have
their
system
for
determining
protocol
changes
that
can
actually
be
adapted
to
this
and
hard
Forks
and
stuff
like
that.
So
by
using
this,
we
can
actually
leverage
that
to
actually
govern
the
Ruki
listing
and
so
they're
kind
of
two
things
that
you
have
to
keep
in
in
mind
when
you're
thinking
about
this.
D
So
if
you
get
a
prospective
route
entry
and
it's
from
the
Pirate
Bay,
some
of
you
might
or
some
nodes
might
you
know
be
okay
with
this,
but
some
nodes
say
if
they're
run
by
Sony-
probably
wouldn't
be
okay
with
that,
and
so
you
can
address
this
issue
very
simply
by
just
voting
on
it.
Those
that
disagree
with
you
know
allowing
the
Pirate
Bay
into
the
Rikki
listing
can
just
vote
against
the
new
route.
Nice
thing
is
they.
You
have
a
set
of
potential
outcomes
that
come
out
of
that
either.
D
The
vote
succeeds,
which
means
that,
although
you
disagreed
with
the
actual
application,
you
can't
disagree
with
the
fact
that
it
was
actually
added
to
the
listing.
In
the
first
place,
the
move
fails,
the
remaining
structure
actually
doesn't
isn't
impacted,
because
all
of
your
mappings
are
still
there
and,
if
there's
a
very
fundamental
disagreement
between
large
sets
of
nodes
that,
in
the
case
that
it's
probably
not
a
good
idea
that
they
should
be
trusting
each
other
and
consensus
in
the
first
place.
That
might
be
an
argument
that
part
of
the
network
should
be
split
into.
D
D
Okay
and
then-
and
so
if
Tory
shows
up
with
the
perspective
root
entry
and
it
wants
a
billion
cells,
you
know
you
probably
don't
want
to
do
that,
because
some
consensus
nodes
might
not
be
able
to
handle
it,
and
so
what
that
force
is
tor
in
this
case
to
do
is
to
find
a
large
enough
set
of
nodes
that
will
actually
support
a
billion
cells
or
to
adjust
its
request,
so
that
I,
you
know,
quorum
or
or
any
sort
of
converting
party
can
agree
that
that
is
a
good
idea
to
add
it
to
the
root
key
listing
all
right,
so
that
is
it
I'm
happy
to
take
any
more
questions.
D
A
D
B
F
My
sincere
apologies
for
some
transport
mishaps
this
morning.
Okay,
so
I'm
gonna
update
you
guys
and
just
kind
of
a
refresher
on
the
stellar
consensus
protocol
draft.
So
if
you
remember
the
motivation
here
is
that
we
think
there's
a
need
for
kind
of
like
internet
level,
consensus
right.
So,
for
example,
say
you
want
to
atomically
transact
across
completely
incompatible
or
mutually
distrustful
systems
like
I
want
to
pay
you
money
and
an
exchange.
I
want
you
to
give
me
a
domain
name,
for
example,
or
let's
say
you
want
to
do
with
Ron.
F
Duke
was
talking
about
irrevocably
delegate,
identifiers
or
rebek
ibly
for
some
certain
period.
Right
then,
having
this
kind
of
internet
level
consensus
where
everybody
keeps
everybody
else
honest
and
makes
sure
everybody
obeys.
The
rules
is
very
useful
if
you
want
to
say
verify
public
disclosure
and
time
stamping
of
information
like
let's
say
you
want
to
build
an
IOT
device
and
you're
worried
about
getting
strong-armed
into
signing
compromised
a
bootloader.
So
what
you
might
want
to
say
is
hey.
F
My
devices
will
only
install
boot
loaders
that
have
been
publicly
logged
in
in
some
kind
of
like
firmware
transparency.
Log
right,
so
all
of
these
things
are
enabled
if
we
have
some
kind
of
append-only
log
whose
semantics
are
enforced
by
intranet
level,
consensus,
okay,
so
the
model
in
which
we
propose
to
implement
this
we're
now
calling
a
a
slice
infrastructure.
Actually
Giuliana
coined
this
term.
F
So,
basically,
a
slice
infrastructure
is
a
set
of
nodes,
each
of
which
selects
a
set
of
quorum,
slices
that
are
sets
of
other
nodes
and
basically
a
node
should
pick
a
pick.
Corn
places
that
it
believes
are
important
enough
for
large
enough
to
speak
for
the
internet
as
a
whole
right,
and
the
idea
is
that
we
want
these
things,
these
kind
of
dependencies
to
to
work
transitively.
F
So
let's
say
that
I
pick
Stanford
and
the
ITF
is
my
form
slice,
and
you
pick
you
know,
Baidu,
we
chat
and
Alibaba
is
your
warm
slice
and
it
turns
out
that
you
know
Alibaba
and
Stanford.
Both
include
Google
and
they're
warm
slices,
so
it's
kind
of
transitively.
We
both
depend
on
Google,
and
so
we
want
the
consensus
mechanism
to
make
sure
that
we
always
stay
in
sync
and
never
get
forked
from
one
another
right.
F
As
long
as
in
this
case,
in
this
example,
Google
would
need
to
be
honest
and
of
course
you
might
want
fault
tolerance,
so
for
fall
torrents
you
would
probably
pick
multiple
quorum
slices,
any
one
of
which
were
acceptable
to
you.
So,
for
example,
you
might
say
four
fifths
of
the
fang
companies
need
to
sign
off
on
something
before
you
believe
that
that
it's
happened
right,
the
Facebook
app
will
Amazon
Netflix,
Google
or
maybe
more
realistically.
These
are
big.
F
Companies
are
probably
running,
multiple
servers,
so
maybe
you
want
three-quarters
of
the
servers
belong
to
each
of
these
companies
to
sign
off
on
things
so
that
if
they
have
downtime
for
individual
servers,
that's
fine!
So
in
this
model,
basically,
if
we
let
capital
V
be
the
set
of
all
nodes
and
for
some
node
little
V,
we
let
Q
of
little
V
be
the
set
of
quorum
slices,
decided
by
node
little
V.
We
can
define
a
quorum
to
be
a
set
of
nodes
that
contains
at
least
one
slice
belonging
to
each
of
its
members
right.
F
So
this
is
kind
of
a
key
definition.
This
is
a
repeated
slide
from
last
time,
but
like
if
you
don't
get
this,
the
whole
talk
won't
make
sense.
I
want
to
kind
of
just
work
through
this
simple
example
to
make
sure
we're
all
on
the
same
page.
Here
it's
a
very
simple
example
where
every
node
has
only
one
quorum,
slice
and
so
I
can
draw
the
quorum
slice
by
depicting
it
by
an
arrow
from
a
node
to
all
the
other
nodes
that
has
chosen
to
be
in
its
quorum
slices
right.
F
F
However,
v1
is
effectively
saying
I'm
only
going
to
agree
to
something
when
b2
and
b3
agree
to
it
and
between
b3,
by
virtue
of
the
quorum
slices,
they
chose
or
saying
we're
not
going
to
agree
to
anything
unless
before
agrees
to
it
as
well.
So
this
is
not
a
quorum
and
the
smallest
quorum
that
includes
v1
is
actually
the
set
of
all
four
nodes.
In
this
example,
and
as
you
can
see,
there's
a
question
earlier
about
you
know:
can
you
have
veto
semantics
right
and
here
every
node
has
nodes.
F
V1,
v2
and
v3
all
have
veto
semantics
right.
So
in
a
more
realistic
example,
you
would
have
maybe
more
quorum
slices,
but
if
it's
extremely
important
that,
for
example,
ini
be
able
to
veto
something,
then
you
know
you
could
configure
your
quorum
slices
such
that
I
Ana,
or
at
least
one
of
I
Ana
servers
and
like
every
single
one
of
your,
your
quorum
slices.
F
Okay,
so
the
way
this
consensus
protocol
it's
going
to
work
is,
it
knows,
you're
going
to
send
messages
and
you're
gonna
collect
messages
and
a
node
v
is
going
to
take
action
when
the
number
of
kind
of
identical
messages
that,
when
the
set
of
senders
who
sent
all
sent
the
same
message
reaches
two
important
thresholds
right.
So
the
first
is
quorum
threshold.
That
means
that
every
node
in
a
quorum
that
you
belong
to
has
actually
including
yourself,
has
actually
transmitted
a
message
right,
so
they're,
all
kind
of
in
agreement
with
this
message.
F
Note
that
you
have
to
belong
to
the
quorum.
You
don't
care
about
forums
that
you
don't
belong
to
you,
it
kind
of
intuitively.
That's
what
makes
this
of
resists
civil
attacks
right,
because
in
a
you
know,
you
might
have
some
weird.
No,
that
creates
a
million
fake
civil
nodes
to
try
them
out
some
civil
attack
and
claim
the
innocent
a
quorum
with
those.
You
don't
care
about
that,
because
you
only
care
about
the
quorums
that
represent
that
include
your
quorum
slices.
F
The
second
threshold
is
blocking
threshold
and
we
say
that
a
set
of
senders
reaches
blocking
threshold
when
they
all
send
the
same
message:
em
and
there's
at
least
one
node
from
each
one
of
your
quorum
slices.
That
has
sent
this
message
out.
So
this
means
that
you
know
as
assuming
these
nodes
are
honest,
that
there's
and
don't
contradict
each
other,
that
there's
no,
so
that
you
will
not
be
a
member
of
any
honest
quorum.
F
That
contradicts
em
right,
because
every
one
of
your
quorums
is
gonna
include
more
of
your
quorum
slices,
we're
just
going
to
include
one
node
that
already
contradicted
or
the
other
that
already
said
em,
so
it
can't
contradict
them.
Okay,
so
the
main
subroutine
and
this
algorithm
is
this
thing.
We
call
federated
voting
and
this
is
basically
a
way
to
a
grammar
statement.
So
you
start
in
some
kind
of
uncommitted
state
and
then,
if
there's
some
kind
of
abstract
statement
a
and
we're
gonna,
this
is
subroutines.
F
We're
gonna
fill
in
a
with
various
values,
and
you
decide
that
a
is
valid.
You
can
vote
for
a
and
then,
if
the
votes
for
a
reach
quorum
threshold,
then
you
decide
that
you've
accepted
a
and
once
you've
accepted
a
you
kind
of
broadcast,
the
fact
you've
accepted
a
and
when
the
set
of
nodes
that
have
accepted
a
reaches
quorum
threshold,
then
you
say:
you've
confirmed
a
and,
and
at
that
point
good
things
will
happen.
You
can
kind
of
count
on.
You
know
on
all
the
other
nodes
also
confirming
a.
F
Conversely,
you
may
have
thought
that
not
a
was
that
both
a
and
not
a
were
valid,
and
you
may
have
just
decided
to
vote
for
not
a
that's
okay.
You
can
actually
still
accept
a
if
there's
a
blocking
threshold
of
nodes
that
also
accepts
a
write,
and
then
you
proceed
to
broadcast
you've
accepted
a
once
that
reaches
quorum.
Threshold,
you've
confirmed
a
right
now,
two
very
important
rules.
F
You
are
not
allowed
to
vote
for
two
contradictory
statements
and
you're
not
allowed
to
accept
two
contradictory
statements,
but,
as
you
can
see
in
the
diagram,
you
can
vote
for
one
statement
and
then
accept
its
contradiction.
If
the
contradiction
reaches
reaches
quorum
threshold,
then
you
can
go
on
to
to
confirm
okay.
So
why
do
we
like
confirming?
Well,
first
of
all,
if
you
have
this
property
called
intactness.
F
The
bad
news
is
that
you
might
start
voting
on
some
statement
and
not
make
it
to
the
confirmed
phase.
And
if
that's
the
case,
then
you
will
not
you,
you
may
get
permanently
stuck
so
until
you've.
Reach
confirmed,
there's
no
guarantee
that
you'll
ever
resolve
whether
this
statement
is
true
or
false,
okay.
So
so
let
me
now
give
an
overview
the
protocol
kind
of
by
phase.
So
you
start
in
this
nominate
phase,
and
the
goal
is
to
pick
some
value
to
kind
of
try
to
agree
on.
F
So
we
run
this
nomination
protocol
and
nodes
are
likely.
If
the
network,
you
know,
has
good
timing
and
has
a
you
know,
is
a
synchronous
network
like
there's
no
network
outage
or
long
delays,
then
nodes
will
very
likely
all
agree
to
nominate
the
same
value
or
set
of
values,
but
it's
not
guaranteed
right,
because
you
can
have
hiccups
in
the
network
and
and
and
it's
only
probabilistic
so
then
the
kind
of
the
whole
rest
of
the
protocol
is
to
kind
of
clean
up.
F
The
the
mess
in
case
nominate,
didn't
work
out
and
converge
by
the
time
you
you
decide
to
do
is
over
so
the
first
phase
is
prepare
and
it
really
breaks
down
of
the
two
parts.
In
the
first
part,
the
goal
is
to
confirm
a
statement
or
set
of
statements,
prepare
be
for
some
ballot
be
and
a
ballot
is
a
pair
that
has
an
integer
counter
and
a
value
which
is
the
thing
you're
trying
to
agree
on.
F
So
value
would
be
like
a
set
of
updates
to
the
Dell
Maps
data
structure
that
John
Ruth
was
talking
about,
for
example,
right
now.
What
does
prepare
us?
That
is
a
set
of
statements.
It's
a
set
of
the
it's
a
set
of
votes
to
abort
a
whole
bunch
of
ballots,
namely
every
ballot.
B-Prime,
that's
less
than
B,
but
has
a
different
value
and
I'll
illustrate
this
in
a
few
slides
and
kind
of
initially
take
B
dot
value
from
the
output
of
the
nomination
phase.
F
Until
such
point
is,
you've
actually
confirmed
some
ballot
prepared,
at
which
point
you
take
the
value
from
the
highest
confirm
prepared
ballot.
Now,
if
part
one
succeeds,
then
you
you've
confirmed,
prepare
be
so
kind
of
part
to
prepare.
Is
that
you?
Actually?
The
goal
is
to
kind
of
vote
and
accept
commit
B
to
actually
commit
that
ballot.
We're
committing
a
boarder
opposite,
so
you
can't
vote
to
both
commit
and
a
board
a
ballot.
So
so
now
you
try
to
you
vote
to
commit
this
ballot.
F
F
Otherwise,
you
you
proceed
to
the
commit
phase.
Where
you
try,
you
you
broadcast
the
fact
you've
accepted.
Can
it
be,
and
you
now
try
to
confirm
that
statement
right
and
once
you've
confirmed
that
statement.
You're
done,
you
can
output.
You
can
decide
on
the
value
that
is
embedded
in
that
ballot
and
you
also
output
an
externalized
message,
but
that
message
is
kind
of
an
optimization
helps
slow
nodes
like
prune
their
quorum
search
when
they're
trying
to
figure
out
what
happened
while
they
were
cut
off
from
the
network.
F
F
The
the
key
invariant
is
that
you
cannot
vote
to
commit
a
ballot
B
unless
you
first
confirm
that
that
ballot
is
prepared,
there's,
okay,
so
here's
kind
of
the
nomination
flow
just
quickly
you're
kind
of
voting
to
nominate
values.
You
never
vote
against
nominating
a
value,
so
nomination
actually
never
get
stuck.
And
what
happens?
F
Is
you
stop
voting
to
confirm
new
value
if
you
first
stop
voting
to
nominate
new
values
as
soon
as
you
confirmed,
one
value
nominated
so
at
that
point
kind
of
the
set
of
values
is
that
have
are
in
play,
gets
frozen
and
eventually
they
kind
of
trickle
out.
In
the
background,
until
everybody
agrees
on
the
same
set
of
values
that
are
nominated,
and
then
you
just
need
to
combine
them
in
a
deterministic
way.
So
if
there,
for
example,
sets
of
transactions,
you
might
take
their
Union
and
then
that's
guaranteed
to
be
the
same
everywhere
eventually.
F
But
the
problem
is
you
don't
know
when
the
nomination
is
finished,
so
you
might
say:
okay,
nomination
is
over
prematurely,
in
which
case
different
people
will
have
different
values.
So
then,
for
the
balloting.
Essentially,
what
you
do
in
the
common
case
is
that
you
vote
well,
you
send
this
prepare
message
and
the
prepare
phase
to
prepare
ballot.
If
that
succeeds,
and
you
actually
manage
to
accept
the
fact
that
that
ballot
is
committed,
then
you
vote,
you
said
commit
message
is
essentially
confirming
that
commit
vote
and
then
you're
good.
F
Let's
say
that
initially
you
prepare
one
you've
confirmed
all
the
lesser
ballots
as
aborted
and
then
you
vote
to
commit
one
comma
G,
but
you
might
lose
that
vote
and
you
might
accept
that
one
company
has
aborted
anyway
right,
no
problem,
you
bump
the
counter,
and
now
let's
say
you
prepare
to
comma
F,
and
so
now
you
vote
to
commit
to
thumb
I
F
and,
as
I
said,
a
vote
can
get
stuck.
So
maybe
that
gets
permanently
stuck
and
we'll
kind
of
we'll
never
know
we'll
kind
of
never
agree
whether
F
to
come.
F
Okay,
how's
my
time:
three
minutes:
okay,
okay,
so
there's
there's,
there's
only
kind
of
lunch,
really
substantive
change
since
the
last
draft,
which
is
that
there
was
a
ballot
that
the
people
from
mobile
coin
pointed
out,
really
only
need
it
to
be
a
counter,
and
ballot
and
values
are
large
about
it
as
a
counter
and
a
value
and
the
value
is,
you
know
like
256
bits
or
larger.
The
counter
can
be
very
small,
like
32
bits.
So
so,
basically
we
replaced
this
ballot,
which
is
kind
of
like
this
prepared.
F
The
accepted
prepared
ballot
the
highest
accepted,
prepared
ballot,
but
that
a
different
value
from
prepared,
but
really
all
you
need
to
know,
is
the
below
a
certain
counter.
You've
you've
accepted
all
ballots
as
aborted,
so
that
makes
that
shorter.
So
that
was
nice.
We,
like
you,
know
shorter
messages.
F
The
the
rules
are
basically
that
you
set
that
a
counter
filled
based
on
the
second
highest
or
the
the
prepared
accepted
prepared
ballot
that
is
highest.
That
has
a
different
value.
So
you
have
to
remember
that,
but
it
makes
the
message
is
smaller,
okay,
so
the
important
point
is
status.
So
basically,
we
have
kind
of
some
good
news
and
some
bad
news.
The
good
news
is,
you
know
the
draft
I
think
is
stabilizing,
like
people
have
read
it
and
started
a
point
here.
F
You
know
asked
a
bunch
of
questions,
but
we've
addressed
those
questions
and
you
know
if
we're
going
with
this
protocol,
it
could
be
that
we're
very
close
to
having
something
final.
The
some
other
good
news
which
maybe
Juliana
will
touch
on
is
that
it
turns
out
that
the
existing
protocol
is
has
slightly
better
liveness
than
we
had
initially
proved.
So
we
get
that
for
free,
but
that
doesn't
mean
we.
We
can't
do
better.
F
And
finally,
the
draft
is
actually
having
the
intended
effect
that,
like
people
are
out,
there
are
like
reading
the
draft
and
actually
implementing
it.
So
now,
I'm
aware
of
at
least
four
different
implementations,
one
of
which
is
the
original
one
in
stellar
core
someone
named
Bob,
Glick
Steen
has
done
one
and
go
mobile
coin
is
implementing
this
in
rust
and
that
Pearce
Polson
for
Jay
I
misspelled
here.
Sorry,
they
can
fix
that
is
he's
been
active
on
the
dinar
G
mailing
list.
He's
he's
a
point
that
as
well
now
there's
some
bad
news.
F
The
bad
news
is
that
you
know
we
might
either
need
other
documents
or
like
a
huge
change
to
this.
If
we,
if
we
really
want
this
to
take
off
the
first
run,
is
that
there's
no
hope
of
interoperability
between
these
implementations,
because
the
draft
deliberately
hasn't
specified
how
the
messages
are
multicast
right
and
that's
because
we
don't
know
what
the
right
solution
is.
But
we
think
that
I
personally
think
that
that's
like
an
important
thing
that
this
research
group
might
need
to
address
a
lot
of
systems
need
this
kind
of
end
system
multicast.
F
In
fact,
if
you
look
at
a
whole,
bunch
of
block
chains
are
doing
this
and
they're
doing
it
kind
of
in
a
bad
way,
and
it's
not
really
very
failure
resistance,
some
other
kind
of
either
good
or
bad
news.
Depending
on
how
you
look
at
it,
it
turns
out
we
can
improve
on
aliveness,
but
it
makes
it
protocol
a
little
bit
more
complicated.
So
now
we
have
this
trade-off.
F
You
want
to
go
with
a
new
protocol
that
has
extra
stuff
to
have
this
increase
in
liveness
and
what
might
be
kind
of
a
corner
case,
but
is
maybe
something
you
want.
I'm,
not
sure.
Julianna
I
think
well
we'll
talk
about
this
and
also
there
may
be
a
simpler
protocol
for
slice
infrastructures.
So
maybe
we
just
want
to
like
junk
this
draft
or
I
have
a
continued
draft
or
something
I'm,
not
sure
so
that's
kind
of
where
we
are
right
now.
B
So
I
had
one
so
it's
draft
version,
five,
what's
Akunyili
core,
no.
F
I
went
with
the
decision
to
try
to
make
the
thing
as
simple
as
possible,
instead
of
exactly
documenting
what's
happening,
and
especially
until
we
have
a
multicast
layer
specified
that
that
seems
to
be
important.
So
particularly
the
latest
change
wasn't
implemented
and
stellar.
There's
like
some
repeated
fields
in
stellar
that
are
like
later
in
messages.
It
was
just
cleaner
to
like
move
them
out
into
like
the
message
envelope
and
I
figured.
You
know,
since
this
is
kind
of
his
chance
to
start
over
like
we
should
do
it,
do
it
cleanly.
F
Yeah
I'm
not
sure
so
it
is
I'm
also
not
aware
and
I
highly
suspect
that
there's
stuff
happening
at
the
ITF
that's
like
relevant
to
this
and
that
people
here
know
more
about
this
than
I
do
so.
Ideally,
you
know,
if
you
know
of
like
things
that
would
be
useful
towards
implementing
as
kind
of
standard
end
system
multicast
for
these
kinds
of
distributed
systems.
Can
you
talking
about
I'd
love
to
hear
suggestions?
If
not,
we
can
just
go
off
and
try
to
do
something
to
make
a
Byzantine
felt.
F
Aren't
and
open
is
actually
a
fairly
tricky
problem
and
Juliana
and
I
have
been
talking
about
that.
It
may
be
that
we
can
leverage
slice
infrastructures
to
actually
do
what
would
be
really
hard
without
slices
and
actually
have
a
robust
Byzantine
fault,
tolerant
and
system
multicast
algorithm,
but
we
haven't,
we
don't
have
one
yet.
G
F
G
F
But
well
it
sort
of
needs
to
be
reliable
and
that
you
don't
want
these
so
called
Eclipse
attacks.
Where
someone
comes
in
like
if
you
want
to
attack
Bitcoin.
What
you
can
do
is
like
there's.
Each
node
is
like
eight
outgoing
connections
and
whatever
two
hundred
some-odd
incoming,
basically
monopolized
incoming
wakeful,
you
monopolize
outgoing,
and
then
you
can
cut
I'm
a
one
mining
Co
off
from
the
other
mining
pool.
So
would.
A
B
H
Hello,
so
my
name
is
Giuliano
I'm,
a
postdoctoral
researcher
at
UCLA
and
so
I'm
going
to
talk
about
the
new
results
and
aliveness
properties
of
the
star
consensus
protocol.
So,
as
CBS
you
say,
satisfy
the
safety
and
latinus
properties
of
consensus,
consensus
algorithm,
so
the
safety
properties
are
namely
validity.
So
intertwined
nodes
must
not
externalize
invalid
values,
where
Invalides
means
the
value
is
not
well
formed
or
does
not
pass
application
level
checks
and
also
agreement,
which
means
that
intertwined
nodes
must
never
external
eyes
different
values.
H
So,
as
david
said
before,
intertwined
nodes
are
set
of
well
behaved
knows
that
whose
quorums
all
intersect
now
for
liveness.
What
we
want
is
that
if
we
wait
long
enough
or
intact
nodes
should
externalize
some
value,
so,
in
fact,
is
another
set
of
what
we
have
note.
That
I
will
describe
a
little
bit
later.
So
here
you
can
see
the
table
that
shows
what
are
the
guarantees
provided
by
SCP
depending
on
what
we
about
the
system.
H
So
if
we
assume
the
system
is
purely
asynchronous
meaning
we
have
no
idea
how
long
it
takes
for
a
message
to
be
delivered
or
what
or
the
clock
skew
between
node
is
then
SCP
can
only
guarantee
safety,
and,
in
fact
this
is.
This
is
not
surprising
because,
according
to
the
famous
FLP
theorem,
it
is
impossible
to
have
both
safety
and
aliveness
in
an
asynchronous
system.
If
a
single
node
may
fail
by
crashing.
H
So
assuming
a
synchrony
is
it's
kind
of
strong
in
in
a
real
system.
We
have
some
idea
of
what
the
message
delay
is
or
what
the
clock
skew
is
at
worst,
but
sometimes
it's
not
accurate
enough
and
there
are
some
periods
where
those
are
bound
to
do
not
hold
so
the
in
theory.
We
model
this
with
what
we
call
eventual
synchrony.
So
in
eventual
synchrony
we
assume
that
initially
the
system
is
asynchronous.
H
There
are
no
bounds
on
message,
delay
or
clock
skew,
but
it
comes
a
time
after
which
the
system
stabilizes
and
now
we
have
some
bound
on
message,
delay
and
clock
skew.
So
if
we
make
this
assumption-
and
we
also
assume
that
nodes
fail
only
by
crashing,
then
SCP
guarantees
safety
and
also
liveness
with
probability
1
for
the
intact
nodes.
So
what
does
this
mean?
Well,
SCP
is
a
probabilistic
protocol
where
nodes
used
a
random
number
generator
to
make
some
choices
and
live
with
probability.
H
One
means
that,
as
time
advances
the
probability
that
no
intact
node
externalized
value
goes
to
zero
ok.
So
this
is
for
a
crash
top
failures
only,
but
now,
if
we
assume
that
some
nodes
may
be
malicious,
then
things
change
and
in
fact
SCP
does
not
guarantee
life,
and
this
is
what
we're
going
to
try
to
fix.
Now
there
is
a
third
assumption
which
is
in
between
both
that
we
can
make.
So
we
can
assume
that
eventually,
there
are
some
malicious
nodes
in
the
system.
H
H
Okay,
so
before
delving
into
this
case
of
malicious
nodes,
I
want
to
say
a
few
things
about
this
intact
set,
so
the
intact
set
is
a
set
of
nodes
for
which
is
possible
to
guarantee
safety
and
liveness,
and
so
in
the
SCP
whitepaper.
The
set
I
was
defined
to
be
intact.
If,
after
deleting
its
complement,
V
minus
I
I
became
intertwined,
meaning
all
its
quorum
intersect
at
a
good
note,
and
also
I,
is
on
its
own.
In
the
original
system,
a
quorum.
H
H
So
this
is
good
because
we
realize
that
we
can
ensure
safety
and
rightness
for
more
notes
than
we
previously
thought,
and
we
also
conjecture
that
this
is
optimal
in
the
sense
that
no
protocol
can
ensure
safety
and
aliveness
for
a
larger
set,
but
you
haven't
proved
it
yet
so
now,
let's
go
back
to
liveness
and
their
eventual
synchrony
when
there
are
some
malicious
nodes
and
we'll
start
with
the
simplest
case,
simpler
case
of
crash
top
notes.
So
eventual
synchrony
is
very
nice
because
it
gives
you
the
ability
to
emulate
a
synchronous
system.
H
So
here
we
have
a
synchronous
system
with
three
nodes.
I
know
this
is
a
closed
system
of
like
a
CCP
for
simplicity,
and
so
we
can
slice
time
in
two
synchronous
rounds
and
in
each
round
we
know
that
every
node
will
hear
from
every
other.
So
in
such
a
system,
it's
very
easy
to
sort
consensus.
We
can
just
ask
the
node
to
collect
values
and
then
decide
on
the
maximum
value
the
see,
for
example,
since
all
the
nodes
will
see
exactly
the
same
values,
they
will
all
agree
on.
H
So
can
we
do
the
same
thing
in
SCP?
Well,
in
STP,
we
cannot
do
round-robin
because
we
don't
know
who
are
the
participants,
so
we
got
choose
a
leader
by
robbing,
so
instead
we
will
use
the
nomination
protocol
to
kind
of
emulate
leader.
So
the
nomination
protocol
guarantees
that
all
the
in
Technos
can
agree
on
some
value
with
nonzero
probability,
and
so
this
is
like
having
a
leader
that
distributes
a
value
to
everybody
and
we
preserve
probability
succeeds
in
convincing
everybody
to
adopt
at
the
same
time.
H
So
the
idea
to
fix
the
Waggoner's
problem
of
SCP
is
to
run
the
nomination
protocol
every
time
the
battle
counter
is
is
increased,
so
this
this
would
give
you
give
us
a
new
protocol
with
a
different
phase
diagram.
So
in
the
current
SCP
we
start
with
nomination
once
at
the
beginning,
and
then
we
never
run
nomination
again
and
we
cycle
between
prepare
and
commit
well
here.
Instead,
we
will
cycle
between
nomination,
prepare
and
commit
at
every
ballot
counter
until
we're
able
to
externalize
some
some
value.
H
So
in
practice
it's
not
clear
that
it's
worth
changing
SCP
and
making
it
more
complex
to
to
solve
this
liveness
problem,
and
this
has
to
be
discussed
all
right
so
finally
to
to
conclude,
so
we
have
some
upcoming
results:
streamlined
theory
of
slice
infrastructures,
including
the
new
definition
of
impact,
and
also
we
have
a
new,
simpler
consensus
algorithm
that
might
be
interesting.
I
collect
an
algorithm
and
not
a
protocol,
because
for
now
it's
been
analyzed
in
theory,
but
there's
no
implementation
and
there
might
be
some
practical
issues
that
we
have
not
identified.
A
F
So
you
know
this
is
the
you
know
what
I'm
still
hoping
for
is
like
a
free
lunch
like
what
would
be
great
as
if
we
could
kind
of
map
one
protocol
to
the
other,
and
that
like
this
will
be
a
way
of
kind
of
thinking
about
the
protocols,
but
that
on
some
level
we
can
show
them
that
they're
equivalent
and
that
it's
just
easier
to
think
about
it.
This
way
so,
but
we'll
have
to
basically
I
guess,
I'm
reserving
judgment,
it's
true
that
people
have
not
that
it
is
hard
for
you
all
to
understand.
F
A
A
H
J
H
J
H
Don't
have
time
to
describe
it
right
now,
but
it's
a
it's
a
probabilistic
algorithm,
where
every
node
basically
picks
somebody
from
their
slices
and
listens
to
what
he's
saying,
and
we
can
show
that
with
some
probability
this
will
form
a
big
tree
rooted
at
a
single
node,
and
everybody
will
listen
to
this
guy
I
can
describe
it
to
you
offline.
If
you
like,.
E
E
If
that
protocol
could
scale,
I
mean
most
of
the
most
of
the
objections
to
adding
the
FT
or
scalability
of
Jetix
right,
because
the
message
complexity
of
many
of
the
existing
bft
algorithms
is
quite
high,
so
I'm
trying
I'm
I'm
actually
struggling
with
what
all
the
other
complexity
and
SCP
buys
you
once
you
add
in
Byzantine
fault
tolerance.
Yes,.
E
H
F
So
so
I
think
that
the
what
this
is
try
so
I
view
consensus
is
kind
of
like
a
broader
thing.
Would
that
includes,
like,
let's
say,
like
the
Bitcoin
proof
of
work,
but
Byzantine
agreement
has
certain
like
properties
that
are
better
for
a
lot
of
applications,
and
so
this
is
just
you
know.
The
slice
infrastructure
is
the
first
model
that
can
actually
do
Byzantine
agreement
and
be
resistant
to
civil
attacks.
F
So
that's
essentially
what
we're
doing
is
saying
that
hey
instead
of
this
proof
of
work
stuff,
if
what
we
have
is
a
situation
where
there's
a
bunch
of
known
counterparties
that
you
have
trust
in
and
you
don't,
you
think
they're
not
all
going
to
misbehave,
but
you
can't,
you
know
magically
designate,
who
are
the
tier
1
validators
any
more
than
you
can
have
unanimous
agreement
over
who's
at
tier
1
is
P,
but
you
have
kind
of
rough
consensus.
Then
this
is
like
the
first
algorithm
that
actually
works
in
that
model.
I
B
L
Morning,
everyone
so
I'm
gonna
talk
about
something
that
that's
a
little
far
off
from
from
what
you
just
heard.
It's
about
namespaces
in
in
distributed
lectures.
Apologies
to
those
who
have
actually
seen
like
a
five-minute
talk
about
that
DNS!
Oh
it's!
It's
a
little
bit
between
you
know,
I
I,
know
Archie
and
and
Auntie
NS
off.
So
that's
why
I'm
I'm,
actually
talking
in
in
both
groups
about
that.
So
this
is
shared
work
between
myself,
my
colleague,
Dimitri
Federov
and
Marko,
so
Vitello
from
a
guy
who's
involved
in
industry,
decentralized,
identifier
definition.
L
Yeah
I
mean
the
first
problem
is
interoperability
so
that
that
that
string
doesn't
actually
reveal
which
ledger
which
blockchain,
which
infrastructure
it
is
so
I
could
I
could
actually
go
ahead
and
do
trial
and
error
on
a
couple
of
distributed,
ledger
infrastructures
and
see
whether
any
of
those
letters
is
well.
It
may
be.
Some
of
those
letters
will
not
even
reveal
whether
it's
valid
or
not,
and
the
example
involved,
for
example,
is
a
Bitcoin
address
and
the
second
one
is
more
like
a
usability
problem.
L
I
hope
you
haven't
seen
something
like
like
on
the
on
the
top
right
bottom
right
yet,
but
if,
if
you
ever
tried
to
like
actually
pay
to
a
Bitcoin
address
to
get
back
your
encrypted
data,
then
you'll
probably
have
realized
that
the
addresses
are
actually
really
hard
to
type.
They
are
impossible
to
remember.
They
feel
a
little
bit
like
European
IPAN
numbers,
but
that's
a
different
story,
so
the
problem
be
is
usability,
so
so
we
really
pay
at
a
trim
remembering
addresses
and
humans
want
names.
L
So
we
need
to
solve
those
two
problems
and
and
solving
problem.
One
interoperability
is,
you
need
to
add
identification
of
the
the
ledger
instance
to
the
address.
Only
that
qualifies
it
in
a
ways
that
you
actually
know
where
to
use
it,
so
that
creates
a
unique
and
hopefully
resolve
a
pro
address.
So
in
that
case
you
can
say,
like
oh
pay
me
at
the
Bitcoin
address
blah,
which
makes
it
pretty
clear
which,
which
light
rain
stance.
L
So
there's
actually
work
going
on
in
the
w3c
credentials.
Community
group
and
I've
heard
from
from
Markos
that
it's
that
it's
soon
to
be
upgraded
to
a
real
working
group,
which
means
they
can
actually
create
w3c
standards
and
what
they
did.
They
went
ahead
and
defined.
Actually,
a
URI
scheme
that
solve
does
interoperability
problem.
L
It's
currently
a
provisional
registration,
we
switch
the
URI
scheme
registry
and
it's
a
hierarchical
scheme,
so
the
scheme
prefix
is
D
ID
for
decentralized
identifiers
and
under
that
there's
of
methods.
Each
method
like
sort
of
refers
to
a
mr.
Bridget
Leger
infrastructure,
for
example,
PTR
cs4,
Bitcoin
and
after
that
is
a
method,
specific
ID
which
in
that
case,
is
an
encoded
Bitcoin
address.
So
that
actually
is
also
a
problem,
a
because
if
at
least
an
engineer
sees
the
ID
column,
btrc
Kalyan
blah,
and
they
know
how
to
resolve
actually
that
address.
L
L
L
So
it's
at
label,
dot,
label,
yeah
and-
and
that
is
that
is
a
little
bit
two-sided
to
me
on
one
hand,
I
think
that
it's
really
a
little
bit
like
of
creativity,
because
if
you
invent
a
completely
new
infrastructure
for
Internet,
then
you
would
probably
at
least
on
the
topmost
layer.
You
would
that
means
least
me
to
like
look
into
inventing
a
different
type
of
naming
scheme.
L
There's
one
one
pioneering
distributed
ledger,
which
is
easier
name
service
they
actually
assign
or
auction
off
names
and
OTEC
age,
which
is
probably
not
the
wisest
suffix
chosen,
because
it's
also
just
really
at
the
country
call
to
ATO
Pia,
so
name.
Cohen
was
a
little
bit
of
a
different
thing.
As
you
might
remember,
it
took
like
the
administration
of
the
DNS
onto
the
blockchain
instance,
but
it
didn't
really
address
blockchain
resources.
It
addressed
normal
Internet
resources.
So
a
couple
of
example:
initiatives
cos
n
NS,
io
e.
L
L
In
that
case,
it's
not
a
little
bit,
but
anyway,
on
the
left
side
we
have
new
TNS
work
and
in
the
middle
we
have
sort
of
like
part
of
the
NS
community.
Who
says
we
need
to
defend
the
kamo
from
from
from
new
work.
So
so,
with
that
in
mind,
we
went
back
and
said
we
wanna
to
do
as
little
as
possible
actual
protocol
development
to
get
that
going,
and
so
what
we
put
in
our
draft,
we
used
an
existing
TN
s,
RR
type.
L
That's
the
URI
RR
type
we
used
for
the
mapping
from
an
email
address
to
a
tid.
We
used
an
existing
experimental
RFC,
that's
called
pain
for
open
PGP,
so
it
transforms
the
email
address
into
a
hash
and
uses
test
hash
as
the
owner
name
and
for
for
the
owner
name
of
the
DNS
record.
We
are
trying
to
trying
to
propose
this.
We
are
using
an
existing
Guyana
registry
yeah.
L
We
do
have
running
code.
There's
there's
a
tid
resolver
called
uni
resolver,
it's
sort
of
like
the
prototype.
Resolver
it's
on
a
web
page
and
you
can
actually
enter
a
domain
name
under
our
labs
infrastructure
and
you
get
back
at
the
ID
on
the
sovereign
test
network
and
that's
free
and
resource
to
the
total
public.
Key
of
that
of
that.
So
it's
it's
really
simple.
It's
existing
DNS
technology!
L
Essentially
it's
available
on
each
and
every
operating
system
out
in
the
world
and
yeah
Connect,
sort
of
the
world
of
decentralized,
identify
us
with
openly
resolve
able
t
NS
and
hopefully
makes
it
easier
to
find
resources
and
blockchains
next
steps.
So
my
question
sort
of
to
the
group
is
like
do
people
think
this
is
used,
have
I
missed
another
development
in
naming
schemes
on
on
on
distributed
lectures?
And
if
you,
if
you
wanted
idea
to
proceed,
please
consider
getting
involved
on
a
DNS
of
discussions.
Yeah,
that's
about
it
from
my
side,
yeah!
Oh.
A
L
Maybe
next
time
maybe
in
Prague
yeah.
So
that's
the
way
forward,
I'm
going
to
have
a
discussion
with,
hopefully
the
transport
area
director,
because
they
are
responsible
for
the
service
name,
parameter
registry,
which,
where
the
policy
doesn't
really
allow
something,
that's
not
connected
to
a
protocol
to
be
included
in
there.
It.
A
G
Do
you
know
I
have
two
comments:
first
on
interoperability
and
the
second
on
naming.
If
we
just
write
a
spec
that
says
what
hash
is
used
to
generate
the
address,
I
think
the
block
chains
can
interoperate
just
fine.
So
that's
just
the
one
comment
in
terms
of
naming
I
think
it's
useful
but
dangerous,
because
today,
when
I
look
at
a
block
chain,
I
see
these
opaque
addresses.
That's
a
feature,
not
a
bug.
It
just
says
somebody
sends
so
many
bitcoins
is
something
somebody
else
it
could
be.
Somebody
could
be
as
process.
G
It
could
be
a
service.
The
fact
now
that
I
have
that
data
and
I
can
I
hope
you
don't
want
to
do
reverse
lookups,
because
then
you're
going
to
be
able
to
tell
me
it's
Dino,
comm
or
something
like
that.
So
I'm
not
convinced
it
needs
to
go
in
a
global
database
that
anybody
can
look
up
and
find
Bitcoin
addresses
or
any
blockchain
address.
It
sounds
like
it
would
be
more
secure
and
more
private.
G
If
we
just
use
contact
lists
like
we
do
on
our
phones,
not
everybody
gets
their
contact
list
out
of
sight
out
of
sync,
but
my
contact
list
is
fine
and
I
have
addresses
of
people,
and
nobody
else
knows
what
addresses
I
have
so
I
think
the
applications
should
just
implement
this
independently
and
not
have
a
global
scale.
Sort
of
designed
for
this
I
think.
L
It
depends
on
the
use
case,
you're
right
if
I
look
at
self,
serene
identity,
I
definitely
don't
want
my
identities.
Relations
that
I
have
is
somebody
included
in
the
table.
Tina's,
because
you
mentioned
reserved
averse
search
I
would
suppose
that
there
would
be
some
search
engine
singing
coming
up.
So
even
if
we
don't
do
the
reverse,
there
will
be
some
passive
DNS
infrastructure
that
actually
exposes
that.
L
M
Hoffman,
this
is
the
DI
NRG,
where
we're
talking
actually
not
just
about
payment
systems
and
hopefully
not
at
all-
about
payment
systems,
but
about
distributed
internet
type
stuff.
If
it's
on
the
internet-
and
you
want
it
found,
I
would
hope
that
you
in
fact
would
want
it
found
and
you
would
want
it
found
in
an
interoperable
fashion
and
so
I
think
what
Alexander's
proposing
here
is
exactly
right
using
you
know
part
of
the
of
what
we
have
now
on
the
Internet
to
help
identify
things
on
the
Internet.
M
L
L
A
Other
thing
is
that
there's
people
need
to
support,
distributed
applications
as
well,
and
those
may
have
their
own
requirements
around
naming.
Excuse
me
I
had
one
question,
and
that
is
that
the
structure
of
the
di
D
looks
a
lot
like
a:
u
RN.
Why
did
you
choose
to
go
with
a
new
scheme?
Rather
than
put
you
are
in
namespace.
L
I'm,
not
the
right
person
to
answer
that,
unfortunately,
because
I'm
I'm
not
involved
in
the
D
IDE
in
that
yet
development,
but
we
simply
discovered
that
there's
ongoing
work
in
that
space.
My
my
initial
intention
would
also
be
that
a
year
end
would
probably
be
fine
yeah,
so
that
Yeti
scheme
could
actually
live
under
the
urine
space
as
well,
but
I
think
that's
a
question
to
ask
the
w3c
community
group.
Okay,
thank.
B
N
O
Hi,
can
you
see
me.
O
She'll
speak
a
little
bit
louder:
okay,
hi
hi,
everyone
very
good
morning
to
all
okay,
so
this
is
Nathan
and
today
I'm
gonna
share
with
everyone.
What
are
some
of
this
interesting
research
issues
that
I'm
working
on?
Okay,
hope?
You
can
hear
me
up
Jimmy
right.
Let
me
just
control.
Can
I
control
from
my
computer
I'm.
O
Nix
Nix,
okay,
so
I
wanted
to
start
off
this
session,
with
sharing
some
of
the
issues
and
constraints
identified.
They
have
been
identified
with
with
the
use
of
decentralized
identity,
okay
and
in
the
area
of
my
work
right.
So
so
a
little
bit.
Let
me
just
do
a
quick
summary
scalability
privacy,
protection
and
interoperability.
Pretty
much.
Some
of
the
challenges
have
been
shared
by
the
previous
speakers
and
then
some
of
this
solutions,
which
I
think
could
possibly
be
the
key
to
solving
these
issues
for
scalability,
would
be
separate.
O
The
consensus
mechanism
from
execution
and
probably
having
some
private
data
on
off
chain
insecure
and
claim
securing
claims
is
an
area
which
is
very
exciting
a
lot
of
people
working
at
it
right
now,
Google
as
a
Google
SEO,
for
example,
and
that
Oasis
let
this
start
up
in
us
really
doing
some
exciting
stuff.
We've
got
Keystone
and
cliff
alright,
and
also
a
privacy
protection
right.
How
can
the
right
to
be
forgotten,
reconcile
with
immutability,
which
is
often
associated
with
these
centralized
platforms
right?
O
So
we
look
I
I,
look
into
zero
knowledge
set
membership,
one
of
the
one.
What
I
just
want
to
research
that
one
of
the
big
financial
institution
chef
we
wish,
which
is
which
has
which
has
done
right,
very
interesting
there
and
also
interoperability?
How
can
multiply
decentralized
identity
platforms
coexist
together,
perhaps
through
the
use
of
hash
time
lock
contracts?
You
know
the
concept
behind
it.
It
doesn't
have
to
be
just
for
funds
transfer.
It
could
be
again,
you
know
for
interpreting
interoperability
purposes.
Alright,
next
slide.
It's
like.
O
Perhaps
the
next
night,
okay
right,
okay,
so
for
I-
think
everyone
here
would
be
an
expert
in
this
area
all
right.
So
just
let
me
do
a
quick
sharing
on
the
background,
challenges
and
constraints
all
right.
So,
as
we
know
on
the
internet,
you
can
be.
Nobody
knows
whether
you
are
who
you
are
and
what's
the
problem
statement
right.
O
That's
a
missing
identity
layer,
which
is
why
Facebook
linking
you
know
all
of
this
platforms
exists
to
a
few
there
for
it
to
feel
that
a
few
that
missing
part
right
all
right
and
then
we
can
know
that
centralized
systems
right,
such
as
Facebook
such
as
Facebook,
has
been
hacked.
So
the
solution
there's
often
asks
whether
a
secure
is
the
solution.
A
more
secure,
centralized
system,
I
think
that's
fool's
errand.
A
O
Systems
have
always
been
open
to
hacking
and
vulnerabilities,
so
perhaps
not
you
know
why
not
explore
decentralized
identity
or
self
sovereign
identity.
Ssi
right.
This
is
something
very
interesting
and
and
areas
which
I've
been
looking
into
for
the
past
one
year.
Okay
looks
like
alright,
so
why
is
the
digital
identity?
So
is
the
social
is
a
social
construct?
Wonderful
context,
that's
important
here
right.
O
Everyone
has
a
social
construct
who
you
are
right
and
the
friends
you
have
right,
for
example,
myself,
Nathan
now
and
the
blockchain
engineer,
with
with
a
banging
in
Singapore
right
and
who
others
who
are
dispersed.
If
you
to
be,
you
know
a
geek
for
example,
so
some
of
this
context
could
be
the
people
around
you
right,
your
family,
your
groups,
the
organizations
we
should
belong
to
institutions
and
perhaps,
most
importantly,
no
identity,
identity,
has
an
identify.
Your
context
right
and
this.
O
A
O
O
For
example,
in
Singapore
through
my
NRI
see
my
passport,
and
you
know
my
freaking,
my
figure,
flyer
numbers
and
my
hotel
loyalty
numbers
so
pretty
much.
How
one
is
identified
is
true,
these
different
mechanisms.
So
the
question
is:
how
can
we
strengthen
our
decentralized
identity
through
all
of
this
various
you
know,
centralized
identifiers
repository
right
next
slide,
all
right.
So
what
problems
are
we
trying
to
solve
or
other
what
problems
am
I
trying
to
solve
them?
O
And
you
know
contribute
to
this
community
right
I
realize
that
there's
no
standard
that
makes
it
easy
for
users
to
assert.
They
are
verifiable
qualifications
to
a
service
provider
right,
so
verifiable
claims
very
popular
right,
for
example,
my
loyalty
card
is
this,
and
I
have
a
counting,
Bank
right
and
I'm
over
the
issue
of
that.
You
want
right
and
I'm
abduction
engineer
right,
so
there's
no
standard
per
se
across
many
of
this
providers.
Right
and-
and
this
has
resulted
in
manual-
input,
multiple
multiple
manual
input
and
fraud.
O
Next
slide
right
and
so
also
another
one
is
we've
existing
attribute,
exchange,
architectures
right,
open,
ID
connect
users
and
they
are
verifiable.
Claims
do
not
independently
exist
from
service
providers.
This
means
users
can
easily
change
the
service
provider
without
losing
or
fragmenting
their
digital
identity
right.
So
you
have
many
islands
of
your
digital
identity
sitting
all
around
the
islands
right
Facebook,
link
in
github,
and
all
of
these
things
was
a
result:
vendor
lock-in
identity
facility,
duplication,
confusion
and
inaccuracy
and,
of
course,
reduce
competition
in
the
marketplace
and
reduce
privacy
for
all
stakeholders.
O
Okay,
next
slide
all
right.
So
in
short
right,
what
is
the
pin
point?
Users
cannot
control
your
identities
and
information
leading
to
a
lack
of
security,
vendor
lock-in
and
industry
specific
solutions.
So
perhaps,
at
this
point
I'd
like
to
share
what
are
some
of
the
things
that
Singapore
the
Singapore
government
is
working
on,
the
Singapore
government
is
working
on
this
thing
called
the
national
digital
identity
of
reach
I'm
keenly
watching
this
progress.
Also,
the
government
has
plans
of
you.
O
If
any
one
of
you
has
have
visited
Singapore,
you
will
see
a
trout
machine
right
where
your
red,
where
your
fingerprints
will
be
captured.
You
know
along
the
customs
right,
so
the
government
is
keeping
our
biometric
information.
Storing
our
biometric
information
and
then
using
it
as
a
form
of
identity,
right
and
and
this
this
identity
cuts
across
social
service,
for
example,
you
know
application
for
social,
it
and
so
on
and
so
forth.
Right
so
and
also
at
the
same
time,
Singapore
recently
encountered
a
cyber
heck
where
our
health
care
records
were
hacked
right.
O
So
this
is
a
really
pertinent
issue:
identity.
How
do
we
secure
identities
right
in
all
these
centralized
repositories?
So
this
is
an
area
where
we're
many
challenges
abound.
However,
at
the
same
time,
constraints
means
opportunities
right.
So
I'll
talk
more
about
this
later
on
in
the
next
slide
right
mix
like
okay,
so
a
decentralized
identifiers.
Again
it
was
mentioned
just
now
right,
I
wanna
talk
about
the
history,
everyone
knows
about
it
and
we
have
this
D
ID
right
di
d,
sovereign
D
ID.
O
Indeed,
eiv
you
bought
so
I'm
on
the
ERC
seven-25
alliance,
so
I
look
into
ether
own
based,
blockchain
identity,
I've
used
you
pod
before
and
then
I'm
gonna
show
you
a
quick
demo
later,
normally
a
demo
or
at
the
link
which
you
can
access
to
do
to
do
to
get
your
hands.
You
know
dirty
on
this
decentralized
identify
concept,
but
are
there
many
challenges?
They
are
and
I'm
gonna
talk
about
it.
Okay
next
slide
all
right,
okay.
So
this
is
a
di
D
document.
O
Alright,
as
we
know,
the
D
ID
identify
assets
on
the
blockchain,
different,
blockchain,
sovereign
and
perhaps
easier
than
the
public,
with
ROM
and
so
on
and
so
forth.
Right
and
then
he
resolves
to
a
di
D
document.
Where
you
can
see
this
D
ID
documents
will
point
to
service
endpoints
right
where
it
will
be
a
repository
of
your
information.
So
I
can
imagine
a
landscape
where
I
have
my
own
D
ID
right.
O
We
should
start
on
perhaps
a
theorem,
and
then
it
points
to
this
endpoint,
the
Singapore
government,
a
repository
for
example,
right
where
it
contains
my
biometric
information,
my
retina,
my
retina
information
right.
So
this
is
how
it
it
should
look
like
you
know,
but
are
we
moving
I'm
gonna
talk
about
how
we
can
possibly
move
to
a
semi
public,
private
infrastructure
architecture
right
for
for
for
our
identity
stores,
our
identity
repositories,
all
right
mix
an
exciting
next
slide?
Okay.
O
O
You
know
a
sort
of
a
cap
theorem
right
for
for
identity
right
where,
where
you
can't
have
something
which
is
meaningful
and
at
the
same
time
easily
remember
and
unique
at
the
same
time,
so
there
are
significant
trade-offs
in
this
area
of
work
right
so
again,
a
very
interesting
research
topic.
How
can
we,
you
know,
transform
this
so
that
you
know
people
like
my
parents,
my
grandparents
could
use
it
right.
O
Okay
mix,
like
all
right
so
begin
this
definition
to
claim
it's
an
assertion
made
about
a
subject
right
and
credentials
said
all
more
claims
me
by
issuer
right.
Perhaps
the
Singapore
government
right
and,
of
course,
the
verification
process
and
then
the
decentralized
identifiers,
D
ID.
That
does
not
require
a
centralized
registration
authority
because
it
is
registered
with
a
distributed,
ledger
technology
or
the
form
of
the
centralized
network.
So
you
will
be
interesting
to
see
how
the
centralized
platforms
blockchain,
for
example,
could
walk
hand-in-hand.
O
Visa
vie,
centralized
repository,
such
as
the
Singapore
government,
identity,
identification,
repository
right
mix
like
okay,
so
one
of
the
connections
between
a
verifiable
claims
and
the
ID
the
ID
can
exist
without
verification.
Today
you
know,
I
can
have
a
D
ID
on
interim
and
verifiable
credentials
are
identifiers
agnostic,
meaning
this
credentials
are
not
tied
to
a
particular
identifier
right,
but
you
know
verifiable
claims
can
write.
O
These
claims
that
make
can
verify
ID
ID
right,
whether
Nathan
out
right
all
this
is
the
ID
right
and
the
combination
can
afford
certain
things,
such
as
cryptographic,
security
by
a
hyper
ledger
and
so
on
and
so
forth.
Right
next
slide,
alright,
so
the
idea
infrastructure
can
be
thought
as
a
global
key
value
database.
O
You
know
hyper
ledger,
perhaps
uses
couchdb
or
lab
ODB
right
and
and
it's
all
the
idea
of
a
table
right,
and
why
is
in
a
tid
document
and
the
D
ID
the
cryptographic
materia,
the
public
is
your
poverty
spiral
keys
and
the
protocols
and
the
service
endpoints
for
interaction
with
a
subject
time,
steps
and
JSON
linked
data
signature
right
next
slide.
O
Ok,
so
this
is
the
very
high
level
of
how
this
ecosystem
would
look
like
how
you
will
work,
you
have
your
issuer
or
I
could
be
linking
Facebook,
github
right
and
then
issues
credentials,
and
then
the
holder
acquires
stars,
and
then
you
would
present
with
a
verifier
right.
You
know
this
is
the
process.
This
is
a
step
where
you
know
zero
knowledge
proof
might
probably
come
in
right,
because
very
often
we
talk
about
the
challenges
where:
how
can
we
keep?
O
How
can
we
ensure
that
our
data
is
it's
not
privy
to
others
right,
and
this
is
where
zp0
noise
proofs
will
really
come
in
handy
and,
of
course,
the
identifier
registry
right
away
maintains
or
the
identifier?
Yes,
all
right,
next
slide,
okay,
so
this
is
interesting.
So
this
is
an
ER
c75
demo
implementation.
So
I
work
closely
with
the
origin
protocol
fox
folks
to
discuss
how
we
can
advance
some
decentralized
identity
on
the
Ihram
platform.
However,
it
is
only
just
one
of
the
platform's
said
that
I'm
experimenting
on.
O
You
know
I
pleasure,
indeed
being
the
next
one,
one
of
the
one
of
platforms
that
really
interests
me.
Okay,
so
I'll
recommend
everyone
to
you
know
get
out
the
URL
try
out
the
URL
and
you
know
and
your
identifiers,
you
know
perhaps
not
really
any
identifiers.
You
know
if
you
want
to
it's
a
private
net,
it's
a
it's
a
private
test
net.
So
not
to
worry
it's
not
on
the
public.
Is
the
RAM
chain
right,
where
you
can
add
your
identity,
your
claim
into
your
claim,
insurers
and
claim
checkers
right,
really
fun,
all
right.
O
It's
like
okay,
so
I
think
some
of
the
areas
which
I'm
doing
some
research
on
right
now
is
exploring
the
usage
of
securing
place
to
enable
privacy
protection
right,
Google
s
low
over
extremely
promising
one
of
the
one
of
the
open
source
and
cliffs
framework,
which
allows
secured
enclaves
to
be
achieved
right
so
one
this
is.
This
is
certainly
an
area
which
I
believe
will
be
incorporated
to
decentralise
platform
in
the
years
to
come.
So
I
encourage
everyone.
O
Capabilities
right-
and
it's
like
all
right-
also
zero
knowledge
proof
how
how
not
as
a
key
piece
can
be
leveraged
to
limit
exposure
of
our
PII
during
the
process
of
attestation
right,
thereby
achieving
GDP,
our
so
in
the
industry
which
I'm
in
a
lot
of
challenges
comes
from
storing
customer
data.
How
do
we
secure
the
customer
data
right?
These
centralized
database
or
decentralized
platform
and
zkp
is
subtly
an
area
which
many
financial
institutions
are
looking
at
right.
So
I
also
like
to
share
with
you
the
ing
bang
you
busily
just
this
man.
O
Just
last
month
came
up
with
this
paper,
which
is
a
zero
knowledge.
Sec
ESM
write
a
zero
knowledge
set
membership.
They
came
up
with
this
research
idea
right
where
the
prove
could
prove
something
you
know
without
without
the
and
the
verify
came
verified
it
without
knowing
what
the
prover
has
right.
So
I'm
thinking
of
incorporating
this
into
the
centralized
identity
platforms.
Of
course,
it's
a
work
in
progress,
but
again
you
know
would
like
would
like
everyone
to
really
explore.
Go
deep
into
this
area
or
annex
life
all
right.
O
So
again,
I'm
going
back
to
this
issues
and
constraints
identified
right
scalability.
I
know
it's
a
bit
of
a
stretch.
How
can
we
put
seven
billion
people,
identity
onto
any
permission
and
decentralized
platforms
and,
of
course,
privacy,
protection
and
interoperability
right?
All
of
these
issues
very
very
pertinent
issues
for
any
decentralized
platforms
to
gain
mass
adoption
right
and
and
again,
I
think
it's
interesting
that
all
of
us
are
here
today
and
really
looking
forward
to
how
we
can
collaborate
on
this
issues
all
right
next
slide
all
right!
That's
it!
O
P
O
So
this
is
okay.
This
is
very
interesting,
so
the
guy
okay,
so
I'm
I'm
leveraging
some
of
this
concepts
which
I've
learned
in
the
financial
sector
right
so
in
Singapore,
the
central,
the
central
bank
mes
right
he's
doing
the
abyss
project
called
project
Rubin,
where
they
they
have
embarked
on
the
decentralized
platform
solutions
for
for
the
real-time
gross
RTGS.
We
called
it
in
right
at
Central.
O
Bank
systems
ready
sheeps
money
right
from
banks
of
X
right,
so
we
are
exploring
the
use
of
hash
time
locks
to
perform
fun,
transfer
across
different
platforms,
different
decentralized
perform
technologies,
so
the
concept
even
Dorai
is
limited
currently
to
funds
transfer,
but
I
believe
personally,
that
this
concept
could
could
could
help
could
help
could
help
connect
the
different
decentralized
platforms
together.
I
am
sovereign
dids.
How
do
we
resolve
the
IDS
right?
How
do
we
do
single
sign-on,
for
example,
across
different
platforms
right,
so
some
of
this
hashed
I'm?
O
Not
concepts
could
be
leveraged,
even
though
it
is
somewhat
you
know,
and
at
first
glance
it
is
proof
is
coming
right.
No,
it
is
a
value.
Transfer
might
not
be
putting
on
to
decentralise
identity,
but
I
believe
that
it
holds
some
of
these
clues.
Some
of
these
ideas,
right
through
to
making
different
blockchains
different
D
IDs
on
different
dockets,
speak
together.
Write
connect
together,
yeah.
Q
O
I've
seen
it
might
not
be
identity,
but
you
know
there's
this
use
case,
which
we
are.
We
are
exploring
where
you
know,
there's
a
single
sign-on.
Currently
you
know
we
have
loved
this
thing
else.
Ion
platforms
right
when
you
sign
in
and
all
your
identity
is
sync
across
different
different
different
islands
right
in
an
organization
account
traditionally
Active
Directory.
O
So
could
we
perhaps
could
we
perhaps
leverage
hdl-c,
for
example,
to
perform
a
single
sign-on
across
multiple
blockchain
platform
right
because
your
D
IDs
could
be
sitting
on
different
islands
right
so
again,
extremely
high
level
might
not
result
in
anything,
but
that's
the
direction
where
you
know
myself,
and
some
of
my
peers
are
looking
at
okay.
O
B
B
C
So,
first
of
all
a
little
bit
about
me,
so
my
name
is
Alastair
Berg
I
work
for
the
blockchain
innovation
hub
at
RMIT,
University,
Melbourne,
so
I'm,
a
researcher
I'm,
also
a
PhD
student.
So
about
the
hub.
We
are
a
social
science
research
center,
so
we're
primarily
economists,
but
we
also
have
legal
scholars
and
digital
at
the
nog
refers
and
and
another
social
scientists.
C
But
we
explore
the
the
economic,
the
social
and
the
political
consequences
of
blockchain
and
distributed
ledger
technology
and
the
conclusions
that
we're
largely
reaching
is
that
they're
an
institutional
technology,
and
we
really
think
that
they're
going
to
change
as
well
as
compete
with
firms,
markets
and
governments.
So
we
look
at
a
few
different
I
guess
use
cases
you
can
you
could
consider
them.
So
we
look
at
things
like
supply
chains.
C
We
could
look
at
civil
society
with
governance
more
generally,
and
but
we
also
look
at
identity,
which
is
I'll
be
talking
about
today,
and
so
next
slide
please.
So
this
is
what
I'll
be
talking
about
today.
So
first
I'm
going
to
briefly
introduce
institutional
crypto
economics,
which
is
the
the
school
of
thought
that
we're
developing
I'm
then
going
to
talk
about
identity
as
a
pretty
peculiar
and
an
interesting
economic
good,
and
then
I'll
talk
about
the
way
that
identity
is
used
in
contracting.
C
If
it's
changed
more
general
I'll
then
broadly
talk
about
what
I
see
is
the
current
state
of
identity
sort
of
where
we're
sitting
today
and
how
I
think
we
got
here
as
well,
and
then
I'll
move
on
to
self
sovereign
identity
and
hopefully
leave
it
to
lead
into
a
brief
discussion
about
about
the
importance
of
identity,
technologies
and
institutions
insertable
or
wires
wider
societal
and
economic
and
political
context.
So
next
slide,
please
so.
C
Briefly
about
institutional
crypto
economics,
so
we
think
that
block
chains
are
really
significant,
because
if
nothing
else
they
proved-
or
they
are
a
proof
of
concept
or
an
economic
form
of
economic
governance
that
we
didn't
know
was
previously
possible.
So
we
now
know
that
it's
possible
to
run
a
decentralized
ledger,
and
so
they
just
spread
across.
They
dispersed
computer
network
without
the
need
for
any
spiritual
authority
in
charge.
C
Owen
and
I
think
that
legends
one
of
the
most
fundamental
economic
technologies
that
we've
ever
seen
so
usually
as
economists,
we
don't
really
pay
a
lot
of
attention
to
Ledger's,
would
traditionally
thought
of
them
as
a
fairly.
You
know,
boring
and
dull
tool
used
in
the
context
of
accounting,
stock
management
and
auditing
auditing
and
that
sort
of
thing,
but
in
fact,
ledger
technologies
of
really
really
fundamental.
So
here
you
can
see
up
on
the
screen,
a
relationship
between
ledger
technology
and
the
institutional
makeup
of
an
economy
or
of
a
society.
E
C
C
I
will
quickly
look
and
see
how
do
I
do
that?
Oh
here
we
go.
This
looks
like
there.
We
go
sorry
about
that.
I'm,
not
sure
how
long
I
was
I
was
not
visible
to
you,
but
I'll
I'll,
sort
of
I'll
sort
of
keep
keep
pushing
on,
and
hopefully
it'll
make
sense.
So
just
returning
to
this
slide,
we
can
see
here
the
relationship
between
ledger
technology
and
the
institutional
makeup
of
an
economy.
So
writing
and
simple
bookkeeping
leads
through
far-flung
trade
and
also
early
empires
and
kingdoms.
C
Double
entry,
bookkeeping
introduced
in
Italy
in
the
in
the
14th
and
15th
century,
leads
through
early
capitalism
and
then
even
more
complex
forms
of
what
you
might
consider.
Empire
capitalism
as
whole
classes
of
bureaucrats
emerge
to
service
these
Ledger's
and
then,
of
course,
digital
Ledger's,
later
to
global
financial
capitalism
and
the
sort
of
the
world
that
we
that
we
live
in
today
and
then
now
after
2008
in
2008
and
2009,
we
see
your
type
of
ledger
that
we
didn't
really
think
was
possible.
In
fact,
we
thought
was
impossible.
C
Next
slide,
please
so
after
Bitcoin,
we
now
know
that
money
can
be
thought.
As
of
as
a
ledger
of
ownership,
so
indeed
much
of
what
governments
do
is
actually
managed
Ledger's.
So
we
have
Ledger's
of
property
titles.
We
have
legends
of
Taxation
obligations,
entitlements
and
even
consider
citizenship
as
a
ledger
of
rights
and
obligations
towards
and
sort
of
derived
from
us
from
a
nation-state.
But
of
course,
firms
alleges
also
firms
in
networks
of
contracts
and
capital
arranged
in
a
way
that
produces
economic
stuff,
so
economic
goods,
widgets
and
and
what-have-you.
C
So
you
can
imagine
if
the
loose
as
the
list
of
relationship
which
maps
who
were
in
what
department
who's
got
onto
militant
for
what
product
and
which
machine
and
production
that's
owned
and
where
to
get
more
of
them
and
how
inputs
move
through
it
to
become
stuff,
which
you
can
then
sell
to
other
people
and
and
firms.
So
that's
a
ledger.
A
firm
is
a
ledger
or
really
it's
a
complex
network
of
ledger,
but
you
can
consider
it
and
from
a
ledger
centric
view.
C
So
we
use
the
the
economic
theories
of
a
few
Nobel
laureates,
including
Oliver
Williamson,
who
built
on
the
work
of
Ronald,
Coase
and
Douglas
north,
so
Oliver
Williamson,
who
won
a
novella
in
2000
and
I,
want
to
say
2009.
We
believe
that
this
is
the
ideal
theoretical
framework
to
understand
the
blockchain.
So
what
williamson
was
primarily
interested
in
is
understanding
the
make
or
buy
decision
that
firms
resolve.
C
So
is
it
better
to
buy
stuff
on
the
open
market
inputs
on
the
open
market
or
produce
them
yourself
so
producing
in-house,
and
this
choice
fundamentally
defines
how
big
a
firm
should
be,
and
the
incentives
faced
by
corporate
decision
makers
and
block
chains
are
really
interesting,
because
what
block
chains
do?
Is
they
substantially
eliminate
what
we
call
opportunism
so
and
they
do
this
by
being
a
trustless
technology?
C
So
a
key
determinate
of
a
key
determinant
of
the
limit
of
the
firm
is,
is
this
opportunism
or
what
Williamson
described
as
self-interest
seeking
with
guile
and
which
is
a
key
component
of
human
behavior,
so
in
short,
institutional
crypto
economic
studies
are
like
social
and
political
structures
in
the
light
of
these
new
types
of
Legends,
so
distributive
decentralized,
ledger
technologies
as
basically
block
chains.
So
next
slide
please.
So
we
think
identities
are
really
interesting
good
if
you
can
consider
it
as
a
good.
C
C
Now,
I've
got
quite
a
bit
up
on
the
screen
and
I'm
not
going
to
go
through
all
of
it,
I
sort
of
let
you
have
a
look
through
yourself,
but
identities
really
peculiar
and
it's
a
peculiar
type
of
good.
Because
not
only
do
you
couldn't
identity
information
about
yourself,
so
you
go
to
university
degree.
You
you
build
up
your
reputation
by
doing
good
things,
but
others
produce
identity,
information
about
you
as
well,
and
often
without
your
knowledge,
or
you
can
consider
your
your
reputation
for
instance.
C
Identity
is
primarily
a
means
of
coordination,
so
the
absence
of
identity
information
would
likely
completely
stifle
and
prevent
change
and
all
forms
of
contracting
so
you've
made
by
a
ours
from
the
side
of
the
road
without
any
identity
technology
being
involved.
But
anytime
gap
between
trade
Norman
requires
a
promise,
so
I
can
forms
a
key
part
of
all
that
the
least
sophisticated
economic
and
political
transactions.
So,
who
are
we
transacting
with?
How
do
we
know
they
are?
Who
they
say
that
they
are
so
this
is
what
identity
does.
This
is
what
it
is.
C
So
participating
in
markets
and
social
and
political
exchange
requires
that
you
prove
who
you
are
so
anytime.
You
make
a
promise.
Promises
require
that
you
provide
a
proof
of
who
you
are
in
order.
Fulfillment
of
a
promise
can
be
followed
through
at
a
later
time,
there's
no
contractual
around
without
identical,
so
more
complex
or
significant
transactions
demand.
More
formal
identification
of
the
parties
involved.
C
Identity
is
necessary
for
credit
markets
and
intellectual
property
has
an
identity
function,
of
course,
banks
in
ensuring
to
recognize
customers
with
whom
they
have
an
existing
relationship
and
and
obligations
as
well.
So
governments
also
need
to
recognize
voters
to
confirm
that
they
have
the
right
to
vote
and
recognize
recipients
of
Social
Security
to
confirm
their
entitlements.
C
Governments
seek
to
identify
tax
payers
to
verify
that
they
pay.
What,
though,
so,
to
grossly
simplify.
We
see
identity
as
having
two
broad
purposes.
One
is
to
facilitate
economic
exchange,
while
the
other
facilitates
exchange
in
the
political
realm
and
to
facilitate
these
types
of
exchange.
We
see
in
the
historical
record
of
the
emergence
of
identity
technologies,
so
they
might
be
as
simple
as
surnames
passports
driver's
license
and
what
happened.
C
Identity
technologies
also
a
function
to
dictate
the
size
of
markets,
so
I
consider
just
the
humble
Magnus.
So
names
are
one
of
the
most
simple
means
of
distinguishing
between
two
individuals.
They
can
basically
be
considered
universal
and
they
provide
a
robust
means
for
entering
in
direct
interaction.
C
So
we
can
say
that
identity
has
public
good
attributes,
so
as
a
public
good,
it
can
be,
it
can
be
provided
a
variety
of
ways
and
the
means
of
provision
actually
can
affect
the
quantity
of
the
good
provided,
so
public
goods
can
be
under
supply
due
to
things
like
free
writing
or
oversupply,
vinaigrette
speaking
and
knowledge
problems.
In
addition,
identity
also
has
properties
that
occur
at
reduced
good,
as
I
mentioned
before,
where
you
can
have
identity
produced
by
traditional
producers,
as
well
as
what,
as
known
as
consumer
producers,
so
we've
seen
I.
C
We
see
government
production
of
identity
services
as
being
supplemented
by
subjective
and
subjective
identities
as
emphasized
by
individuals,
so
these
subjective
identities
might
change
some
share
some
common
characteristics
with
the
uniform
identity
issued
by
the
state,
so
like
a
name
for
instance,
but
the
variety
of
identities
individuals
themselves
have
provides
far
greater
nuance
and
malleability
than
which
can
be
provided
by
a
driver's
license,
and
from
this
we
can
actually
derive
to
theses.
So
the
first
one
is
that,
as
as
an
individual
as
an
individual,
we
want
a
variety
of
identities
for
subjectivist
and
privacy
reasons.
C
C
2
so
suggested
the
oversupply
by
suggest
that
there
is
an
oversupply
of
identity
and
and
through
government
monopoly
that
have
identity
provision
and
as
well
as
technological
errors,
we
can
see
the
situation
today
where
we
so
often
bundle
identity
contributes
as
part
of
exchange,
so
the
oversupply
on
this
oversupply
of
identity
information
is
most
clearly
illustrated
in
the
situation
in
the
past
when
we
would
go
to
a
bar.
So
in
order.
C
Sorry
so
so,
through
the
government
monopolization
of
identity,
provisioning
as
well
as
technological
barriers,
we
can
see
the
situation
today
where
we
sell
off
to
entity,
attributes
and
used
in
this
part
of
exchange.
So
this
oversupply
of
identity
information
is
most
clearly
illustrated
in
this
situation,
as
many
of
us
would
have
had
when
we
go
to
a
bar
or
a
club
or
a
restaurant.
C
So
in
order
to
prove
one
attribute
about
ourselves,
we
need
to
provide
something
like
a
driver's
license,
which
contains
a
whole
lot
of
superfluous
information,
which
we
don't
need
in
that
particular
exchange
where
in
reality,
all
the
bouncer
or
the
back
end
or
whoever
needs
to
know
is.
Am
I
older
than
18,
yes
or
no
or
whatever?
The
drinking
age
happens
to
be
in
that
jurisdiction
and
talking
about
minimal
attributes
and
then
moving
beyond
the
bar
example.
I'm
just
given
and
means
that
you
also
want
to
contextualize
your
multiple
coexisting
identities
for
privacy
reasons.
C
C
So
we've
not
previously
had
a
way
to
prove
directly
in
a
prudent
and
attribute
to
a
counterparty
short
of
produced.
Some
tamper-proof
physical,
artifacts
or
direct
like
contacting
the
institution
that
issued
some
credential
to
confirm
its
authenticity
next
slide.
Please
so,
of
course,
identity
institutions
are
subject
to
taking
technological
change,
so
I,
for
instance,
literacy
rates
and
and
norms
about
record-keeping,
where
technologies
that
facility
facilitated
the
increasingly
prevalent
diseases
of
birth
records,
increased
instances
of
digital
digitization
of
commercial
and
government
sectors.
C
These
may
also
have
some
real
impact
on
how
identity
is
managed
in
the
future.
So
the
future
that
I'm
talking
about
now
is
is
the
future
where
identity
is
scripted,
cryptographically
secured
decentralized,
giving
individuals
ownership,
as
well
as
graduated
permission
and
control
over
many
identity
attributes.
C
Allow
for
probabilistic
certainty
that
a
specific
individual
is
the
owner
of
a
given
attribute,
while
preventing
third
parties
from
necessarily
correlating
links,
buttons
actions
and
hence
relating
them
to
a
particular
individual,
so
asymmetric,
asymmetric,
cryptography,
insurers
of
verifying
entities
are
able
to
cheaply
verify
identity,
attribute
claims,
but
are
unable
to
alter
them
and
with
alloy
technologies
such
as
zero
knowledge
proof.
It
may
also
become
possible
to
verify
the
existence
and
correctness
of
a
claim
without
ever
sharing
the
nature
of
that
claim
with
a
verifying
entity.
C
So,
of
course,
we
can
see
and
I'm
sure
that
this
is
all
very
familiar
to
you,
but
we
can
see
some
of
the
main
characteristics
of
self
sovereign
identity
which
of
course,
has
been
written
about
at
some
length
by
by
those
under
starting
with
Christopher,
Alan,
Devon,
Loreto
and
many
others
of
course,
and
it
also
goes
without
saying
all
the
work
that
people
like
yourselves
are
doing
on
work
and
things
like
decentralized
identifies
verifiable
claims
by
many
other
groups,
including
the
w3c
next
slide.
Please.
C
So
what
does
this
mean
for
the
future?
So
in
short,
well
I'm
patiently
waiting
for
software
engineers
and
computer
scientists
to
continue
the
very
hard
work
that
that
you're
doing
on
the
technology
and
the
standards
that
will
truly
put
the
individual
at
the
center
of
an
identity,
administration
and
one
which
emphasizes
context,
dependence
and
individual
control,
rather
than
administrative
necessity
in
the
words
of
duct
cells.
C
But
I'm
also
really
excited
about
this,
because
I
think
it
may
fundamentally
check
the
privacy
equation
as
well
and
as
well
as
the
way
in
which
many
markets
work,
so
first
privacy
in
surveillance,
so
storing
your
own
attributes
and
find
by
some
institution
and
simply
sending
that
claim
to
whoever
needs.
It
allows
you
to
prove
some
intermediate
tribute
without
someone
in
with
the
institution
issued
the
claim,
so
this
fundamentally
reduces
the
Big
Brother
problem
and
the
capacity
for
state
or
corporate
surveillance,
which
I
think
is
really
something.
C
The
reason
banks
exist
is
Bank
economize
on
these
costs.
This
is
one
of
the
most
fundamental
reasons
why
we
have
retail
banks
vertical
integration
to
save
on
such
identity
costs
is
also,
of
course,
dependent
on
the
identity,
technologies
available,
so
new
ways
to
coordinate
economic
activity
and
hopefully
or
at
least
that
much
reduced
us
verify.
Identity.
Information
passed
them
by
counter
counter
parties
may
actually
cause
such
economies
of
scale
to
disappear.
So
we
could
see
we
could
see
banking,
the
banking
sector
and
other.
C
What
I
call
trust
institutions
become
less
and
less
necessary
for
complex
economic
and
financial
interaction
and
I'm.
Just
looking
over
my
time-
and
it
looks
like
I'm
bang
on
time
flow,
I'll
move
on
to
the
next
slide.
If
that's
right
and
and
I'll
ask
any
questions
and
I
I
do
understand
that
I
had
some
some
internet
problems,
so
I'm,
sorry
that
I,
not
all
that
went
through,
but
hopefully
most
of
that
came
through
and
if
there
are
any
questions,
I'm
of
course
happy
to
take
it.
Thank.
K
Sure
yeah
hi
Dan
Bogdanovich,
please
few
slides
back.
Where
he's
talking
about
the
centralized,
that's
current
model
of
the
identity
versus
this
self
sovereign
identity.
You
were
showing.
You
know
this
attributes
of
that,
and
these
are
very
nice
goals
to
achieve
the
biggest
problem
and
what
we
know
today
for
some
of
them
is
the
economic.
K
You
know
from
the
from
the
economists
point
of
view
from
the
economic
point
of
view
is
why
they
should
let
you
sell
sovereign,
your
identity,
because
by
having
having
a
identity
control,
they
are
extracting
economic
value
out
of
that
and
there
isn't
a
way
how
to
as
at
least
we
don't
know
how
to
extract
the
economic
value
out
of
youth.
When
yourself
suffer
when
your
self
governing
your
identity.
C
So
you
know
in
many
ways
we
are
the
product,
which
is
that
that
well
used
phrase
and
sorry
to
interrupt
but
government
as
well
yeah
yeah,
indeed
indeed
so
I
mean
any
any
sort
of
large
institution
like
government's
and
like
these
large
corporate
entities,
yeah
I
mean
that
they're,
certainly
not
gonna
gonna
roll
over
and
accept
us
doing
what
they
have
done
for
us
for
the
last
thousand
years,
and
this
yet
again,
I
don't
have
a
clean
answer
for
you.
C
You
know,
through
the
through
the
through
the
publicity
of
large-scale
hack,
that
we've
seen
so
much
over
the
last
few
years.
Then
perhaps
it
might
crank
their
business
model.
I
also
see
I
also
see
a
large
role
for
privacy
regulations
like
the
GD,
P
R,
so
you'll
notice.
What
we're
on
the
right
drugs
photos.
You
can
think
a
lot
of
the
characteristics
of
scoffs,
of
an
identity
align
quite
well
with
privacy
regulations
and
like
the
GD,
P
R.
C
So
things
like
control
and
transparency,
consent,
minimization
I
mean
they're
almost
the
same,
the
same
requirements
of
the
GD
P
R,
so
I,
don't
really
have
a
good
clean
answer
for
you,
but
but
I
think
things
like
new
privacy
regulations,
people's
understanding
of
how
our
data
is
used
by
companies
and
governments.
The
may
see
a
shift.
B
Right
so
in
the
energy,
so
for
the
last
meetings
we've
had,
we
have
largely
seen
maybe
three
types
of
topics,
so
maybe
number
one
could
be.
You
know
called
principles
or
concepts
like
digital
identity
cells.
Around
identity
number
two
could
perhaps
because
say:
infrastructure
things
like
Stella
delegated
knapping
chain,
space
open
up
these
things
and
topic
number
three,
largely
application
ideas,
so
decentralized,
a
tki
topics.
We
discussed
last
time
not
too
much
today,
so
we
would
also
like
to
get
a
bit
of
a
feedback
from
from
the
group.