►
From YouTube: IETF102-DINRG-20180720-0930
Description
DINRG meeting session at IETF102
2018/07/20 0930
https://datatracker.ietf.org/meeting/102/proceedings/
A
All
right
good
morning,
so,
on
the
final
lap,
this
is
energy
decentralized,
Internet
infrastructure.
Thanks
for
coming,
it's
my
kochiya,
millander
sure,
I'm
Kucha
and
sewed
energy
is
a
proposed
research
group
in
the
IRT
F.
So
we
have
been
a
meeting
for
a
couple
of
times
and
so
have
been.
You
know
trying
to
think
about.
You
could
scope.
A
You
know,
try
to
figure
out
what
are
the
communities
that
that
could
work
on
on
this
topic,
and
so
this
is
basically
our
meeting
as
a
proposed
research
group
and
so
I
think
we
have
a
pretty
cool
agenda
and
you
probably
have
seen
some
discussion
on
the
like
scope
or
Chara
on
the
main
list,
thanks
for
everyone
who
contributed
to
that,
so
we're
gonna
come
back
to
this
at
the
end
of
the
session.
So
if
you,
you
know
want
to
spend
some
thoughts,
maybe
if
you
have
some
additional
feedback
or
ideas
on
that
discussion.
A
You
know,
please
start
thinking
about
it
quickly.
We
have
an
IPR
policy
in
the
IRT
F.
So
essentially,
please
let
us
know
like
quickly
if
you
see
IPR
in
this
room,
that
you
are
aware
of
all
that.
You
if
you
present
something
that
is
connected
tool
to
IPR
quickly,
our
you
know,
group
infrastructure,
so
we
have
a
main
list.
A
A
Fortunately
we
already
have
a
note-taker.
So
thanks
a
lot
man,
you
see
and
she's
doing
it.
For
us,
it's
super
helpful,
so
we
sometimes
we
use
the
iPad
to
only
about
feel
free.
What
to
use.
What
would
you
like
quick
overview
of
the
agenda?
So
we
have
two
hours
today
and
I
start
with
an
update
on
the
Acela
protocol
in
the
presentation
on
a
family
vacation,
a
vacation
approach,
and
then
we
talk
about
disability
mapping
so
something
we
also
talked
about
before
she
Habano
is
joining
from
London
remotely.
A
So
it's
gonna
talk
about
her
coconut
project.
Jonas
is
giving
us
some
black
perspectives.
How
Dynegy
could
relate,
or
relates
to
what
the
anima
working
group
in
the
IETF
has
been
doing,
and
then
we
have
bringing
you
talking
about
their
work
on
decentralized
trust
was
the
Internet
infrastructure
we
kind
of,
as
I
said,
we
left
some
time
at
the
beginning
to
allow
for
some
discussion
on
scope
like
steps
feedback
from
you.
Perhaps
so,
let's
try
to
make
this
happen.
All
right.
Is
there
anything
we
need
to
do
on
the
agenda?
B
C
So
if
you
tried
to
read
version
zero
and
didn't
couldn't
make
heads
or
tail
of
it,
you
know
now
might
be
a
good
time
to
to
try
again,
okay,
so
quickly
by
way
of
motivation.
You
know
the
goal
here
is
to
have
some
kind
of
like
internet
level,
consensus
where
the
internet
can
can
agree
on
something
right
now.
Why
would
you
want
this?
There'll
be
other
motivation
in
later
talks.
C
I
can
particularly
the
distributed
mapping
talk
for
which
there's
actually
a
draft
now,
but
you
know
it's
able
to
see
wanted
to
transact
atomically
across
incompatible,
or
you
know
mutually
distrustful
systems
right
like
maybe
you
want
to
do
a
transaction
where
you
transfer
a
domain
name
to
someone
and
they
send
you
a
payment
on
some
completely
different
payment
network
that
has
nothing
to
do
with
the
domain
name
registry
right.
Well,
what,
if
kind
of
like
the
internet,
was
maintaining
this
secure,
append-only
log?
C
Right
another
example
which
will
come
up
in
the
in
a
later
talk
is
what,
if
you
want
sort
of
irrevocable
or
temporarily
irrevocable
delegation
right,
you
know,
I
create
an
email
account
for
you
on
my
system
and
I
want
to
now
certify
your
email
address
in
such
a
way
that
I
can't
later
equivocate
insert
sorry
I
want
to
certify
public.
Your
email
address
and
I
don't
want
to
do
it
in
such
a
way
that
I
can't
take
that
back
and
certify
somebody
else's
key
for
the
same
email
address
later
on.
C
So
again,
you
know,
could
be
internet
somehow
enforce
these
delegation
rules,
and
you
know
yet.
Another
example
would
be
to
verify
to
have
kind
of
verified
disclosure
of
information
all
right.
So
this
comes
up,
particularly
in
the
case
of
firmware
transparency
right
you
want.
You
would
like
to,
for
example,
put
out
an
IOT
device
and
make
sure
that
random
hackers
can't
you
know,
load
malicious
firmware
on
there
and
so
one
way
to
prevent
that
is
to
say,
okay,
you
can
only
load
firmware
on
these
production
devices
once
the
firmware
has
been.
C
You
know
disclosed
that
we
can
advance
on
some
public
log
and
the
firmware
can
refuse
to
update
itself
unless
there's
proof
of
that
and
and
again
if
the
internet
were
maintaining
this
this
this
kind
of
transparency
log
and
you
could
trust
the
internet.
Then
this
would
work
right.
So
all
of
these
would
be
addressed
if
there
was
some
public
append-only
log
that
were
sort
of
agreed
on
by
the
whole
internet
right.
So
so
the
next
question
is
well.
What
is
the
internet?
C
Can
that
dole
out
identifiers-
and
many
of
these
have
recursive
delegation
capabilities,
and
this
is
all
well
defined,
but
you
know
in
practice,
if
say
like
you
know,
Google
and
Netflix
and
Amazon
and
Comcast
all
like
moved
to
some
parallel
IP
network,
where
they
kind
of
reused,
domain
names
and
IP
addresses,
for
you
know
in
in
a
way
that
was
completely
incompatible
with
Ayana.
You
know,
no
one
in
the
u.s.
very
few
people
would
actually
care
right.
C
People
think
oh
well,
you
know
the
Internet,
that's
the
thing
where
I
can
go
watch
movies
on
Netflix
and
search
on
Google
right
and
you
know
most
people
haven't
heard
of
Ayana
and,
like
you
know,
don't
really
care
what
it
is.
Similarly,
you
know
if
you
go
in
China
people
would
have
a
different
idea.
You
know
they
would
want
to
reach
you
know,
maybe
by
you
and
and
and
we
Chen
whatever
they
that's
a
lot
of
people
most
people
and
trying
to
can't
even
reach
Google
right.
C
But
there's
a
hypothesis
here,
which
is
that
all
these
notions
of
Internet
will
sort
of
transitively
converge
right
and,
and
the
reason
for
that
this
hypothesis
makes
sense.
Is
that
the
Internet
has
this
kind
of
inherent
brinksmanship
built
into
it
right
where
it's
it's
a
global
network,
it's
not
centrally
governed.
It's
it's
built
out
of
these
pairwise
peering
and
transit
relationships
and
the
sort
of
the
penalty
for
going
off
and
starting
your
own
network.
C
That's
completely
disconnected
from
the
Internet
is
so
high
that
it
sort
of
forces
the
thing
together
and
forces
people
to
work
things
out
such
that
there's
transitivity.
So
the
the
goal
here
is
to
leverage
this
kind
of
internet
hypothesis,
the
idea
that
you
know
transitively.
Everyone
can
talk
to
everyone,
even
if
there's
not
direct
connectivity,
to
create
a
consensus
protocol
that
basically
who's
kind
of
trust
mirrors
this
a
pairwise,
peering
governance
structure
of
the
Internet,
and
so
the
idea
is
that
everyone
is
participating
in
this
consensus.
C
Protocol
is
going
to
pick
a
set
of
nodes,
a
set
of
other
participants
that
they
think
is
kind
of
important
enough
to
speak
for
the
whole
internet
right.
So
let's
say
you
know,
I
think
that
you
know
the
Internet
is
whatever
contains
like
the
ITF
website
and
wiki
and
mailing
list
and
Stanford
right.
So
those
are
the
sites
that
I
care
about,
maybe
you're
from
China.
You
think
that
the
internet
is
where
we
can
reach.
You
know,
Baidu.
We
chat
and
Alibaba
right,
and
you
know
so
famously.
C
If
you're
in
China,
you
can't
even
reach
Google.
So
it's
just
not
even
part
of
your
internet
experience
right.
On
the
other
hand,
both
Alibaba
and
Stanford
depend
critically
on
Google
right,
because
you
know
at
Stanford
we
do
a
lot
of
Google
searches,
Google
hires
a
lot
of
our
graduates.
If
you're
Alibaba,
you
actually
need
your
inventory
to
be
indexed
on
Google
right.
C
So,
even
if
your
employees
can't
search
on
Google,
you
still
need
connectivity
to
Google
right,
and
so
so
the
idea
is
that
as
long
as
you
know,
since
we're
all
kind
of
indirectly,
depending
on
Google
as
long
as
Google
is
honest
in
this
example,
we
want
this
consensus
protocol
to
be
safe.
Now,
of
course,
we
might
also
want
fault
tolerance.
C
In
case
you
know,
Google's
unavailable
or
some
of
Google
servers
are
unavailable,
and
so
for
that
you
can
say
like
pick
multiple
quorum
slices
and
then
say
you
know
any
one
of
those
kind
of
satisfies
you
that
if
everyone
in
the
quorum
slice
agrees
and
everyone
they
think
is
important,
agrees,
then
you're
kind
of
dealing
with
something
that
the
whole
internet
can
agree
on
right,
mom
and
you
know
so,
for
example,
maybe
an
example
of
a
multi-course
last
configuration
might
be.
You
depend
on
four
out
of
the
five
Fang
companies
right.
C
C
Okay.
So
so,
once
you
have
this
notion
of
a
corm
slice
and
individual
people,
you
know
think
this
quorum.
Slice
speaks
for
the
internet.
A
quorum
is
simply
the
transitive
closure
over
quorum.
Slices
right,
so
quorum
is
a
set
of
participants.
You
that
contains
at
least
one
quorum.
Slice
of
each
of
its
members
and
the
quorum
also
can't
be
non.
It
has
to
contain
at
least
one
participant.
Obviously,
okay,
so
using
this
SCP
builds
is
basically
a
Byzantine
agreement
protocol
that
has
open
membership
and
kind
of
relies
on
this.
C
C
It's
not
fresh
in
your
mind
here:
I'm
visualizing
quorum
slices
by
drawing
an
arrow
from
a
node
to
all
the
other
nodes
at
that
node
depends
on
right,
and
so
in
this
example,
you
can
see
that
v1
v2,
v3
v4
is
a
quorum
because
it's
also
quorum
slice
for
each
of
its
members.
V1
v2
v3
is
a
quorum
slice
for
a
node
b1,
but
it
is
not
a
quorum
right.
V1
is
saying:
I'll
agree
to
stuff.
C
If
you
need
to,
and
b3
2
B
2
and
B
3
are
saying
will
agree
to
stuff,
if
you
four
does
so.
The
smallest
quorum,
including
v1
in
this
example,
is
the
set
of
all
nodes,
and
so
that
gives
you
kind
of
a
sense
for
how
the
this
transitive
property
works.
You
know
if
I
depend
on
just
Stanford,
but
Stanford
depends
on
a
bunch
of
other
people,
then
kind
of
you
know:
I'm
not
gonna,
be
forked
from
anybody.
C
I'm
not
gonna,
be
forked
from
Stanford,
but
I'm
not
gonna,
be
forked
remaining
when
Stanford
considered
as
important,
either.
Okay.
So
the
way
we
represent
these
quorum
slices,
of
course,
the
quorum
slice
kind
of
mathematically.
It
can
be
an
arbitrary
set
of
nodes,
including
yourself.
You
have
to
be
an
everyone
in
Coram
slices,
but
in
practice
that
would
not
be
easy
to
represent
compactly
and
often
if
you
want
to
kind
of
like
three
out
of
four
type
k
out
of
n
type
configurations.
C
So
it
says
this
will
be
less
prone
to
kind
of
implementation
issues.
Okay,
so
that's
how
we
represent
a
quorum
slice
and
and
every
single
message.
This
part
of
this
protocol
is
now
going
to
specify
the
sender's
quorum
slice
as
a
shot,
256
hash
of
the
serialized
quorum
slice
data
structures.
That
I
showed
you
on
the
on
the
previous
message
on
the
previous
slide.
So
basically
this
that
you
know
the
protocol
is
specified
in
XDR
since
that's
already
an
internet
standard,
and
you
can
see
that
every
message
basically
comes
an
envelope.
C
We
have
a
statement
and
then
a
signature
on
that
message
and
the
the
statement
basically
includes
a
note
ID,
which
is
a
public
key
of
the
sender,
a
slot
index
because
you're
using
SCP
to
agree
on
a
series
of
slots
at
five
second
intervals.
That's
your
log,
then
the
quorum
set
hash
is
the
shot
to
physics,
hash
of
the
quorum
slices
and
then
there's
four
different
messages
that
I'll
go
through
and
you
can
embed
one
of
these
in
any
given
side
message
right.
C
These
are
nominate,
prepare
commit
and
externalise,
so
the
main
subroutine
that's
used
kind
of
over
and
over
again
in
these
messages
is
this
thing
called
federated
voting,
which
you
sort
of
maybe
think
of
as
a
weird
form
of
like
bracha
atomic
broadcast.
If
you're
familiar
with
with
asynchronous
protocols
anyway,
you
sort
of
you,
you
use
this
protocol
to
decide
between.
You
know
some
statement
a
and
potentially
either
decide
on
a
or
maybe
you
want
to
be
able
to
decide
on
a
zop
Asit
which
I'll
call
a
bar
here.
C
You
know,
conversely,
you
could
vote
for
not
a
you.
Can
then
accept
not
a
and
confirm
not
a
or
if
you
voted
for,
not
a,
and
you
see
a
set
of
nodes
that
is
all
accepted.
A
they've
accepted
the
opposite
of
what
you
voted
for
and
that
set
is
big
enough
to
intersect
every
single
one
of
your
quorum
slices.
So
basically,
you
know
that
they'll
never
be
you'll,
never
see
a
quorum.
That
actually
includes
a
voted
a
then
you
can
move
to
accepted
a
you,
can
kind
of
change
your
mind
and
well.
C
Even
though
I
voted
for
not
a
I'm
actually
gonna
accept
a
but
then
to
get
to
confirm,
you
still
need
a
quorum
that
that
accepts
that
right,
and
so
the
nice
properties
that
you
get
from
this
here
are
that
you
cannot
accept
contradictory.
You
will
never
accept
contradictory
statements
so
long
as
you
have
quorum
intersection.
C
Alright,
so
you
won't
accept
contradictory
statements
if
you're
not
intact,
you
won't
confirm
contradictory
statements
so
long
as
you're
in
twines
the
intertwine.
So
even
if
you're
not
intact,
you
will
and
you
accept
contradictory
statements.
You
won't
confirm
those
contradictory
statements
right.
So
during
this
voting
process
you
could
get
stuck
right.
There's
no
guarantee
they'll
make
it
all.
The
way
to
confirm
a,
but
if
there's
any
intact,
node
that
actually
confirms
some
statement,
then
there's
a
guarantee
that
all
the
intact
nodes
will
confirm
it
right.
C
So
once
you've
confirmed
something,
you
know
great
I
can
assume
both
for
safety
and
liveness,
that
all
the
other
people
I
care
about
who
are
not
compromised
are
actually
going
to
accept
this
as
well.
Okay,
so,
basically
the
album
the
outcomes
you
can
get
from
from
federated
voting.
Are
you
know?
The
good
outcome
would
be
that
you
know
you.
So
the
system
is
a
valent
meaning
like
this
there's
a
quorum,
that's
voted
for
a
and
because
you
have
quorum
intersection.
C
That
means
no
other
value
will
be
agreed
on
by
quorum,
and
then
everybody
kind
of
realizes
that
a
quorum
did
this,
and
so
everyone
can
kind
of
agree
on
a
as
being
true.
However,
if
you
have
people
voting
against
a
you
might
get
a
split
vote
right.
You
can
imagine
a
situation
where
neither
a
nor
a
bar
gets
a
quorum,
because
just
the
votes
are
split
and
we've,
and
even
if
you're
doing
like
a
thin
majority
thing
you're,
you
could
have
notes.
C
Failing
so
they
don't
vote,
and
so
you
just
get
stuck
and
you'll,
never
actually
finish
right
or,
of
course,
you
could
end
up
agreeing
on
a
bar.
Now
there's
this
other
property,
though
that
if,
if
you
cannot
vote
against
a
if
the
protocol
does
not
admit
a
vote
against
for
a
bar
or
if
you
can
reason
about
the
fact
that
a
correct
node
will
never
vote
against
a
bar
well,
then
you
will
not
get
stuck
right.
C
There's
always
hope
that
either
people
have
a
vote
or
they
voted
for
a
so
you
as
long
as
there's
a
valid
quorum,
an
on
faulty
quorum.
You
can
kind
of
convince
enough
people
to
vote
for
a
who
haven't,
voted
yet
and
eventually
get
a
quorum,
and
eventually
the
system
can
agree
on
a
so.
If
there's
a
statement
that
a
kind
of
non
faulty
node
can't
vote
against,
then
we'll
call
that
statement
irrefutable
okay.
C
So
with
that
background,
I
can
now
talk
about
how
the
protocol
works
and
basically
applying
this
federal
voting
idea
to
a
bunch
of
different
statements.
So
the
first
phase
of
the
protocol
is,
you
have
to
kind
of
decide
what
value
to
even
try
to
reach
agreement
on
in
the
first
place
right,
and
so
we
call
this
the
nomination
phase,
and
so
you
start
off
in
this
nomination
phase
and
you're
trying
to
grin
these.
These
values
and
values
you're
sent
opaque
string
of
bytes
from
the
point
of
view
of
the
consensus
protocol.
C
You
don't
really
care
you
just
care
that
there's
some
up
call
to
say
like
is
this:
is
this
a
well-formed
value?
So
you
don't
nominate
a
your
reen
Amin
ater
a
broken
value,
but
basically
you
are
voting
to
nominate
values
and
there's
no
way
to
vote
against
nomination.
You
can
vote
vote
to
nominate
value.
C
You
move
the
values
from
voted
to
accepted,
and
you
keep
going
like
this
until
you
actually
confirm
at
least
one
value
nominated
right,
and
at
that
point
you
stop
voting
to
nominate
new
values
right.
So
the
nice
thing
is
here
that
this
protocol
will
actually
converge
on
a
set
of
values
right
because
at
some
you
know,
you're
only
going
to
vote
for
a
finite
number
of
values
and
there's
no
way
to
vote
against
a
value.
It's
irrefutable
attempt
to
nominate
values.
C
C
So
so,
and
basically
one
problem
in
the
last
draft
is
I,
never
said
kind
of
like
when
you
could
stop
the
nomination
protocol,
and
so
we
made
some
changes
so
that
you
can.
You
have
to
keep
sending
your
nominate
messages
until
such
point
as
there's
about
that's
confirmed,
prepared
and
I'll
talk
about
what
that
means
when
we
get
to
the
prepare
phase
of
the
protocol
right.
But
at
that
point
once
you've
confirmed
some
bail
prepared,
you
don't
care
about
the
nomination
value
until
then,
the
nomination
value
is
how
you
try
to
get
a
ballot
prepared.
C
It's
the
value
that
you
choose.
Okay,
so
kind
of
here's.
The
nomination
flow
right.
You
kind
of
echo
these
nominations,
you
know.
Eventually,
everybody
stops
nominating
you
values
we
could
save,
because
they've
seen
at
least
one
value
nominated,
confirmed,
nominated
and
then
kind
of
the
rest
trickle
around
in
the
background.
I
totally
converge
on
this
set
of
values,
and
then
you
just
deterministically
can
combine
those
values
again
in
an
application-specific
way.
But
if
we
were
doing
transactions
it
could
be
like
the
Union
or
the
set
of
transactions,
and
this
thing
is
guaranteed
to
converge.
C
The
only
catch
is
you
don't
know
when
it's
converged
right.
There's
this
famous
FLP
impossibility
result
which
says
you
can't
get
consensus
in
an
in
an
asynchronous
system
with
a
deterministic
protocol,
and
and
so
because
of
that,
if
this
protocol,
if
you
knew
the
protocol,
we're
done
and
had
converged
that
you'd
violate
the
possibility
result
to
it
mean
this
protocol
doesn't
work.
So
we
have
this
thing
that'll.
C
You
can
kind
of
guess
that
this
is
probably
converged,
but
we
have
to
do
something
else
to
actually
make
sure
that
we're
safe
and
we
all
agree
on
the
same
value
and
that
second
part
of
the
protocol
is
the
balloting
okay.
So
what
is
the
ballot
about?
It's
just
a
a
pair
where
you
have
a
counter
and
a
value
counter
is
just
an
integer,
and
the
value
is
kind
of
a
candidate
that
you
would
output
from
the
consensus
protocol
for
a
particular
slot
in
your
log.
C
The
ballots
are
totally
ordered
where
the
counter
is
more
significant
than
the
value
and
there's
two
kinds
of
statements
that
you
can
vote
on
for
a
particular
ballot
commit
and
abort,
where
they're
contradictory,
like
abort
means
not
commit.
So
you
can
only
vote
for
given
ballot,
you
can
only
vote
for
either
commit
or
abort,
not
both
and
there's.
C
Instead,
we'll
just
you
know,
you
know,
if
both
votes
got
stuck,
then
they
had
to
have
the
same
value.
So
then
you
can
just
vote
to
commit
a
higher
numbered
ballot
that
has
the
same
value
in
it.
Okay,
so
we
start
off
the
balloting
with
a
prepare
phase,
and
this
is
what
the
prepare
phase
contains.
You
know
it
contains
a
ballot.
Two
optional
ballots
called
prepared
and
prepared
Prime,
and
then
these
two
counters
age
counter
and
C
counter,
and
what
does
this
actually
mean?
C
Well,
we
can
kind
of
translate
this
into
federated
voting
messages
at
its
core.
This
is
a
vote
to
prepare
ballot
right,
but
it
could
be
that
you've
also
accepted
ballot.
You
voted
against
it,
but
then
you
change
your
mind
and
accepted
it.
So,
but
basically,
if
for
bala,
this
means
you're
either
voting
for
ballot
or
you're.
Accepting
that
that
this
ballot
is
prepared
right,
meaning
everything
less
than
it
with
a
different
value
has
been
confirmed,
has
been
aborted
or
you're
voting
to
abort
everything
less
than
it.
C
Then
you've
got
these
two
optional
vowels
prepared
and
prepared
Prime.
If
they
are
no,
it
means
that
you've
actually
accepted
them
as
prepared,
not
just
voting
for
prepare,
but
you've
actually
accepted
for
them
as
prepared,
so
a
slightly
stronger
statement
than
what
you're
saying
about
the
ballot,
and
the
reason
there
are
two
of
these
is
because,
if
you
remember
the
way
define
prepared,
it
says
that
everything
less
than
the
ballot
with
an
incompatible
value
with
a
different
value
has
been
aborted
right.
C
So
all
you
need
is
the
top
two
prepared
things
that
you've
accepted
is
prepared
with
different
values,
to
kind
of
fully
define
everything
you've
ever
accepted
as
a
board.
It
right,
because
you've
accepted
as
aborted
all
ballots,
less
than
prepared
Prime
and
all
balance
between
prepared
primary
prepared,
except
those
that
have
the
same
value
as
prepared
and
then,
if
each
counter
is
not
zero.
That
means
you're
actually
confirming
this
prepare
of
each
counter
and
the
ballots
value.
C
And
you
don't
you,
don't
you
don't
strictly
need
to
and
tell
people
that
you've
confirmed
something
is
prepared,
but
but
it's
actually
useful
because
it
lets
you
kind
of
prune
the
corm
slices
like.
If
someone
tells
you
to
confirm
something.
That
means
that
you
can
kind
of
not
check
their
quorum
slices
when
you're
doing
your
quorum
check
to
see
if
something
actually
constitutes
a
quorum,
because
they've
already
checked
that
one
of
their
slices
satisfies
that's
recursively
and
then
there's
a
C
counter
which,
when
it's
nonzero
means
you're,
actually
voting
to
commit
some
ballots.
C
Basically,
everything
between
C
counter
and
H
counters,
so
C
counters
kind
of
like
the
lowest
ballot
that
you're
voting
to
commit
and
H
counter
is
the
counter
the
highest
ballot
you're
trying
to
commit,
and
once
this
committee
vote
is
commit
phase
actually
succeeds
and
you've
accepted
a
ballot
as
committed
for
any
ballot.
Then
you
move
on
to
the
next
phase,
which
is
the
commit
phase
right.
So
this
is
just
a
little
bit
about
how
am
I
on
time.
Not
good.
Okay,
so
I'll
skip
this.
C
So
so
then
we've
got
some
like
nut.
Could
me
I'm
over
already?
Okay?
Well,
so
we've
got
two
other
messages
that
basically
are
also
doing
federated
voting
and
I.
Guess
I'll
skip
straight,
it's
a
question,
others
say
in
terms
of
status.
You
know,
we've
got
people
implementing
this
and
you
know
there's
a
couple
things.
We
still
need
to
figure
out
in
the
protocol
and-
and
you
know
we're
in
this
work-
they're
gonna
hear
about
now
and
I'm
formally
verifying
it.
D
One
question
yeah
or
yeah
yeah,
alright,
I'm,
Shane,
Curran,
so
I
think
you
mentioned
that,
because
you
can
only
vote
for
things
not
against
them,
that
you
avoid
the
stuffed
case.
Well,
if
for
a
nomination,
yeah
not
for
balloting
okay,
but
it
seems
like
the
intuitive
notion
of
stuck
is
missed
there,
because,
if
not
enough
people
vote
for
it,
it
will
never
proceed
right
which,
like
just
to
a
layman
that
sounds
like
it's
stuck
even
though
formally
it's
not
stuck
well.
C
It's
not
stuck
in
that,
like
you,
can
always
change
your
mind
and
vote
for
it
right.
If
you,
if
need
be
right,
the
problem
with
the
problem
with
the
about
the
not
irrefutable
messages,
the
ones
you
can
throw
it
against
is
we
can
be
in
a
situation
where,
like
I
voted
for
it,
you
voted
against
it.
You
know,
and
now
we're
like
bummer
we'd
like
to
actually
make
progress
here,
but
there's
nothing.
C
D
C
But
the
thing
is
like
there's,
not
a
problem
with
nominating
multiple
values:
right,
there's,
a
problem
with
both
confirming
and
aborting
the
same
ballot,
but
not
with
with
with
nominating
multiple
values.
Okay.
My
second
question,
sorry,
very
quick
is
a
bit
related.
There's
no
clocks
in
any
of
this
there's
some
timers,
so
the
timers
are
not
required
for
the
safety
or
for
the
non-blocking
liveness,
but
the
kind
of
make
progress
in
practice.
There's
a
there's,
a
there's,
it's
kind
of
like
there's
timers
and
it's
kind
of
self
synchronizing.
C
So
what
happens
is
as
soon
as
you
see
a
quorum.
That
is
that
your
ballot
number
at
your
ballot
counter
you
armed
a
timer
which
gets
longer
as
the
counter
in
the
ballot
gets
bigger.
And
then,
when
that
timer
fires
you
move
to
the
next
ballot
and,
however,
if
you
see
a
blocking
set
that
has
a
higher
counter
than
you,
then
you
bypassed
your
timer.
C
A
Okay,
that's
a
few
people
and
it
would
be
better
if
we
could
more
get
more
eyes
on
it,
so
I
mean
David
and
his
team
has
been
have
been
working
on
this
for
for
some
time
and
just
kind
of
significantly
reworked
this.
This
is
a
like
candidate,
for
you
know
a
piece
of
work
that
you
know
the
energy
you
know
could
work
in
the
future.
So
if
you
have
any
opinions
on
that,
please
share
that
on
the
main
list,
or
get
back
to
David
and
steam
directly
thanks
thanks.
B
B
So
the
ghost
of
the
this
project,
our
first
to
produce
a
formal
specification
of
SCP,
so
essentially
a
formal
version
of
the
the
current
internet
draft
then
to
produce
a
formal
proof
of
the
intended
properties
of
the
protocol
that
is
specified
and,
finally
to
produce
a
formally
verified
reference
implementation.
So
I
start
with
the
specification.
So
what
is
a
formal
specification?
B
So
it
comes
in
the
form
of
an
abstract
state
machine,
so
we
state
and
from
here
you
have
an
example
of
a
trivial
specification
of
a
door
which
has
two
states
opened
and
closed
and
the
transitions
are
to
open
it,
which
you
can
only
do
if
it's
closed
and
to
close
it.
If
that
you
can
only
do
if
it's
opened
so
more
complex
specifications.
So
look
like
programs,
we
can
use
a
kind
of
programming
language
to
try
to
specification,
but
there
are
some
differences.
B
So
why
would
we
choose
to
specify
something
formally
well
because
it
gives
us
an
unambiguous
description
of
what
the
protocol
is
supposed
to
do
all
right.
So
this
means
that
if
you
give
me
a
trace
of
the
course
to
the
API
it
is
being
specified,
then
it
is
very
clear
whether
this
trace
satisfies
the
specification
or
not,
and
so
the
advantages
are
that
improves
communication
between
the
protocol
designer
and
implementers.
There
is
no
interpretation
else.
B
So
so
here
are
a
few
excerpts
of
the
specification
of
SCP,
which
is
underway.
So
here
we
describe
the
state
of
the
system
with
three
relations
that
you
can
think
of
as
SQL
tables
that
each
contain
what
the
nodes
did
in
the
protocol.
So,
for
example,
vote
contains
information
about
whether
or
no
TV
voted
for
either
commit
or
abort
or
ballad
B
right.
So
this
is
the
state
of
the
specification,
and
now
we
can
specify
what
are
the
transitions,
which
are
called
actions
in
this
language,
IV
that
we
are
using.
B
So,
similarly,
this
is
the
confirm
action.
Another
example
of
node
V
for
ballad
B
statement
s
and
according
to
information
from
node
set
Q,
which
requires
that
Q
is
a
quorum
and
that
all
members
of
this
quorum
accepted
statement
s
for
ballad
B.
In
this
case,
we
update
the
confirm
relation
all
right,
okay,
so
that
is
the
specification.
Actually
what
we
want
is
it
correct,
so
what
we
can
do
to
check
that
is
produce
a
formal
proof
which
will
prove
that
all
possible
executions
of
those
actions
of
the
specification
will
satisfy
their
intended
properties.
B
So
where
are
the
intended
properties
for
SCP?
So
David
talked
about
that
earlier,
but
I
will
repeat
so.
We
need
two
definitions
to
state
those
properties,
first
intertwined
nodes
which
are
nodes
whose
quorum
intersect
at
the
well-behaved,
node
and
intact,
nodes
which
are
nodes
which
are
intertwined
and
additionally,
are
part
of
a
quorum
of
well-behaved
nodes.
B
So,
given
those
two
definition,
the
first
property
we
want
SCP
to
satisfy
is
that
it's
safe,
meaning
that
no
two
intertwined
nodes
will
ever
externalize
different
values
for
the
same
slot
and
that
SCP
is
non-blocking,
meaning
that
intact
nodes
always
remain
able
to
externalise
value.
They
never
stretch.
B
All
right,
so
why
do
we
want
to
prove
formally?
Can
we
just
maybe
you
know,
do
a
an
informal
argument
like
it's
done
in
in
the
SCP
white
paper?
Well,
this
is
because
distributed
protocols
are
notoriously
hard
to
get
right
and
in
formal
arguments
usually
do
not
cut
it.
So
the
convince
you
of
that
have
one
example.
This
is
the
the
court
protocol
very
famous
protocols
cited
about
thirteen
thousand
times
according
to
Google,
Scholar
and
so
in,
published
in
2001,
and
the
author
says
that
attractive
features
of
court
included
simplicity
and
provable
correctness.
B
So
this
is
a
protocol
that
implements
a
distributed
hash
table
in
a
peer-to-peer
network.
So,
unfortunately,
about
a
decade
earlier,
another
researcher
looked
more
closely
at
court
using
formal
methods,
and
she
found
that
in
fact
not
a
single
one
of
the
properties
that
code
was
supposed
to
satisfy
was
actually
true.
So
this
means
that
if
you
implemented
court
according
to
the
description
in
the
initial
paper,
then
you
got
a
system
that
risked
becoming
inconsistent
all
right,
so
our
formal
proofs,
a
realistic
goal.
B
So
yes,
the
the
formal
proof
technology
has
been
measuring
very
fast,
and
very
complex
system
have
been
recently
proved
correct,
such
as
full
C,
compiler,
hypervisors,
cryptographic,
libraries
and
so
on.
So
we
want
to
do
that
for
SCP.
So
what
is
a
formal
proof?
So
it's
like
a
mathematicians
proof,
but
it's
much
more
detailed
and
because
it
has
so
many
details
that
we
need
to
keep
track
of.
We
want
it
to
be
a
machine
checked,
so
a
program
will
verify
that
that
the
proof
is
correct.
B
B
So
how
do
I
prove
this
formally
well
by
producing
a
proof
tree,
which
is
a
tree
like
this,
where
the
leaves
are
the
assumptions
here
and
here
and
here
which
can
be
canceled
like
this
one
and
the
root
is
the
conclusion
which
we
want
here
and
every
node
is
obtained
from
its
children
by
applying
a
basic
rule
of
logic.
So
here
and
here
we
apply
the
rule
modus
ponens,
which
is
a
basic
rule
of
logic,
and
here
we
apply
assumption
elimination
where
we
take
an
assumption.
We
eliminate
it
and
we
put
it
in
indigo.
B
So
that's
a
very
simple
formal,
but,
as
you
can
see,
if
you
want
to
prove
anything
interesting
in
this
way,
it's
going
to
blow
up
completely
and
be
very,
very
tedious.
So
in
fact
people
have
tried
it,
and
here
I
have
the
example
of
a
proof
of
the
raft
protocol
which
implements
a
state
machine
replication.
We-
and
this
proof
is
done
with
the
Verde
framework,
and
it
took
50
thousand
lines
of
proof
to
prove
that
just
five
hundred
lines
of
code
are
correct.
B
So
obviously
we
don't
want
to
do
something
like
that,
and
what's
great
is
that
we
now
have
amazing
automated
solvers,
like
z3,
for
example,
which
can
find
those
proofs
automatically
for
us,
so
they're
really
amazing
tools
but
they're
also
not
all-powerful.
So
what
we
want
to
do
is
strike
a
good
balance
between
automation
and
in
manual
proof.
So
we're
going
to
do
this
for
four
protocols
like
like
SCP,
using
the
concept
of
an
inductive
invariant.
So
what
is
an
inductive
invariant?
B
So,
let's
say
I
want
to
prove
that
property
P
holds
for
every
reachable
state
of
the
specification.
What
you
do
that
I'm
gonna
find
a
property,
an
inductive
invariant
called
even
such
that
three
things
hold
first,
the
invariant
holds
in
the
initial
state.
Second,
if
I
assume
that
the
invariant
hold
in
in
any
state
and
I
take
one
step
of
the
specification
one
transition,
then
the
variant
should
hold
again,
so
it's
preserved
by
the
specification
and
finally
safety.
It
implies
the
property
P
I
wanted
to
prove.
B
So,
in
fact,
this
is
just
proof
by
induction
like,
like
maybe
you
learned
in
high
school
and
it's
Yoast
rated
by
the
Dominos
here.
So
if
you
tell
me
that
the
first
domino
will
fall-
and
you
tell
me
that
if
a
domino
falls
then
the
next
also
fall,
I
can
conclude
that
all
the
dominoes
before
this
is
the
reason.
B
So
we
can
use
this
in
a
proof.
Method
called
deductive
verification
where
we
ask
the
user
the
human
to
come
up
with
this
inductive
invariant.
This
is
a
creative
process
and
then
we
use
an
automated
prover
to
check
the
three
properties
of
that
we
saw
before
automatically
all
right.
So
in
the
end,
it
will
look
like
this,
so
we
start
with
the
protocol
specification,
the
the
invariant
that
the
user
came
up
with
and
the
safety
property,
so
this
is
the
job
of
the
user,
and
then
we
feed
this
to
our
tool
called
IV.
B
The
front
end
of
the
tool
will
translate
all
those
things
to
logical
formulas
in
first
order
logic.
So
those
are
the
three
properties
I
talked
about
earlier.
That
will
be
translated
in
first
order
logic,
and
then
we
will
send
those
formulas
to
a
first-order,
Sat
solver,
which
is
automated.
So
this
is
the
job
of
the
machine
here
and
the
soldier
now
answer
the
question
of
whether
there
is
a
counter
example
to
the
properties.
So
if
it
says
no,
there
is
a
no
counter
example,
it
will
also
produce
a
proof
and
we're
happy.
B
Okay,
so
here
is
as
an
example,
SCP
is
inductive
invariant.
So
this
is
the
property
that
we
want
to
prove
P.
So
we
want
to
show
that
if
two
new
nodes
confirm
two
different
battles
as
committed,
then
the
value
for
those
ballots
is
the
same.
Unfortunately,
this
property
alone
is
not
inductive,
because
it
doesn't
say
anything
about
the
rest
of
state
of
the
system,
such
as
vote
and
accept
messages
so
to
make
it
inductive.
B
Okay,
so
the
current
status
of
the
project,
so
there
we
have
a
specification
for
a
CP
with
formally
verified
safety
property
and
we
next
I'm
going
to
work
on
producing
a
form
of
document
out
of
this
specification
that
would
be
readable
along
with
the
internet
draft
and
prove
the
non-blocking
property
and
and
produce
a
verified
reference
implementation.
So
if
you
want
more
information
on
IV,
so
the
prover
that
we're
using
or
the
the
verification
techniques,
you
have
a
a
few
links
here.
B
E
B
That's
a
very
good
question
and
so
in
in
this
instance
we're
still
in
the
process
of
defining
the
protocol,
so
that
makes
it
a
little
bit
easier
because
I
mean
we're
defining
it.
So
there's
no
existing
protocol
that
we
want
to
match.
But
if
we
could
also
check
that
an
implementation
and
existing
implementation
corresponds
to
the
specification
by
using
the
specification
as
a
test
oracle's,
what
I
could
do
is
run
the
system
collect
some
traces
and
then
using
a
model.
B
F
B
F
B
F
So
you
know
hacking
involves
using
things
in
ways
that
you
didn't
expect
it
to
be
right
and
and
right.
If
there
is
alternative
inputs
or
I
mean
you
gave
examples
of
well,
you
have
to
make
sure
that
some
of
you
didn't
vote
both
for
and
against
something
you
know,
and
then
you
have
to
think
about
well
what
if
they
voted
twice.
What,
if
you
know,
I
mean
all
these
sorts
of
things
and
making
sure
that
there's
no
other
forms
of
input
that
could
be
go
into
the
system
that
hadn't
been
accounted
for
right.
B
G
B
H
You
know
I'm
converting
all
these
invariants
to
assertions
that
are,
you
know
automatically,
for
example,
put
in
the
code
and
that's
fine.
Then
the
system
will
never
do
something
that
violates
this,
but
I
think
it
doesn't
tell
me
why
the
system
shouldn't
kind
of
stop
at
a
point
in
time.
It
says
that
the
assertion
has
failed
right.
Yes,.
B
H
I
Okay,
so
my
name
is
jean-luc
I'm
joined
today
by
Sydney
and
concore
in
the
back
can
answer
questions
afterwards.
If
necessary,
we
managed
to
sneak
a
draft
in
under
the
deadline
for
these
things
called
distributed,
delegated
mappings.
Basically,
what
this
presentation
is
about
is
we've
heard
a
lot
about
the
SCP
protocol
and
now
it's
time
to
build
something
on
top
of
it,
mmm-hmm
so
I.
If
you've
been
to
previous
meetings,
you've
probably
seen
some
of
this,
but
some
a
little
bit
of
motivation
before
we
start
there
are
a
lot
of
mappings
on
the
internet.
I
So
if
I
want
to
send
an
encrypted
email
to
say
:
at
email
comm,
we
have
to
rely
on
a
centralized
source
of
trust,
in
this
case
the
email
provider,
to
give
us
Colin's
public
key
to
encrypt
the
email.
So
that's
one
problem:
we
have
this
mapping
from
email
to
public
key.
That
requires
a
lot
of
trust
in
the
email
provider.
Even
worse
that
email
provider
can
unilaterally
revoke
that
mapping.
So
we
would
never
be
able
to
send
Colonie
an
email
or
it
could
change
that
mapping
unilaterally.
So
we
would
be.
I
You
know
encrypting
with
the
wrong
key,
so
there's
this
issue
of
unilateral
revocation
and
the
last
thing
is
that
there's
you
know
there's
a
lot
of
these
examples
that
we'll
get
into
on
the
next
slide
and
they
all
have
different
interfaces.
So
the
goal
of
this
is
to
provide
a
common
interface
for
authentication
in
mappings
and
to
provide
support
for
delegation.
So
there,
as
I
said,
there
are
lots
of
use
cases.
You
know
for
domain
mappings
your
mapping
zone
files,
where
you
have
to
trust
the
domain
roots
in
PKI.
I
You
have
to
trust
the
the
CAS,
and
you
know
you
have
HS
yes,
preload
lists
that
you
have
to
manually
insert
into
browsers
and,
for
example,
if
you
want
to
allocate
IP
addresses,
you
have
to
trust
Tomas
systems
when
you're
doing
BGP
and
stuff
like
that.
So
there
are
tough
point
solutions.
What
we
want
to
do
is
we
want
combine
those,
and
so
the
basic
structure
is.
I
We
have
all
these
applications
and
we
have
this
nice
consensus
protocol
that
can
provide
a
public
append-only
log
and
meet
some
glue
between
the
application
and
the
consensus
protocol
to
actually
make
use
of
that.
That's
where
these
delegated
distributed
mappings
come
in.
The
really
important
thing
is
that
a
lot
of
these
mappings
have
a
delegation
structure,
and
so
we
wanna
make
sure
that
we
have
explicit
support
for
that.
Okay,
so
dog
a
mappings.
Basically,
the
overview
of
this
is
for
every
application.
I
We're
going
to
have
a
set
of
tables
and
the
tables
are
basically
lookup
key
value.
Mappings
and
the
values
can
be
either
the
items
that
you
want
to
secure
and
make
available.
So
those
are
say,
zone
files
or
keys
mm-hmm
or
you
can
delegate
a
sub
space
or
a
sub
part
of
the
namespace
to
another
owner
who
will
kind
of
modify
and
maintain
that
portion
of
the
namespace
independently.
So
that's
where
the
arrows
are
we're
gonna
do
is
we're
gonna,
you
know
drill
down
to
the
individual
components
and
then
build
it
back
up.
I
So
first
part
is
a
cell.
That's
the
basic
record
of
delegation
has
a
couple
of
fields:
it
has
a
creation,
timestamp,
a
revision,
timestamp
and,
most
importantly,
a
commitment
timestamp.
That's,
let's
go
that's!
What's
going
to
provide
a
measure
of
security
against
unilateral
modification
by
the
authority
that
is
granting
the
mapping
so,
for
example,
I
you
know
the
email
provider
for
Colin
can
say
you
can
specify
a
public
key
and
it's
guaranteed
to
be
valid
until
at
least
this
time.
I
Throughout
this
presentation,
all
the
red
squares
are
going
to
be
fields
that
the
authority
is
going
to
be
modifying
and
all
the
green
squares
that
we'll
see
in
a
bit
are
going
to
be
values
that
only
the
owner
of
the
cell,
so
Colin
in
our
email
example
can
modify
no
Islands.
Anyone
can
modify
depending
on
the
operation,
so
the
contents
of
each
cell
can
vary
if
it's
a
leaf
node,
it's
just
going
to
be
a
value.
I
I
The
goal
is
to
be
as
extensible
as
possible
and
if
you
want
to
delegate
something
you're
going
to
use
a
delegate
cell-
and
that
has
the
key
that
you're
the
public
key
of
the
entity
that
you're
delegating
to
and
it
has
a
signature
from
the
authority
and
a
sub
range
of
the
namespace,
you
can
see
why
it's
important
that
we
kind
of
specify
which
fields
are
Marthaville
by
who,
because
in
this
case
the
provisions
are
a
little
bit
different.
Only
the
authority
granting
a
delegation
can
modify
the
actual
namespace
that's
being
delegated.
I
I
Basically,
there
is
one
key
that
is
the
authority
over
the
table,
who
can
insert
new
mappings
and
there's
a
rule
for
how
we
generate
delegations.
So,
unfortunately,
we
can't
just
let
the
the
authorities
do
whatever
they
want
they
have
to.
We
have
to
ensure
that
they
are
delegating
namespace
ranges
that
are
within
their
own
zone
of
control.
So
there's
two
delegation
rules
right
now.
I
There's
a
prefix
delegation
rule
and
a
suffix
delegation
rule
use
prefix
delegation,
for
you
know:
IP
address
allocation
and
suffix
delegation
for,
for
example,
domain
name
delegation,
so
yellow
is
delegation,
and
you
can
also
have
value
cells
in
there
that
just
allocate
individual
mappings
okay.
So
it's
not.
It's
not
tables
all
the
way
up
and
fortunately
you
have
to
have
a
route
somewhere,
and
so
what
we
propose
is
a
root
key
listing.
It's
going
to
store
the
root
key
for
each
namespace
that
you
have
now.
I
A
big
question
is
how
you
actually
manage
this
table
and
we
can
talk
about
that
a
little
bit,
but
for
now
we
can
look
at
it
in
terms
of
a
list
of
root
keys
for
each
namespace,
an
application
identifier
to
identify
what
exactly
you're
using
that
series
of
tables
for
and
a
signature.
So
it's
a
list
that
have
links
down
into
the
tables.
Once
we
have
all
these
parts,
we
have
cells,
we
have
tables
and
we
have
the
root
key
listing.
I
You
can
actually
do
something
with
this
structure,
and
so
this
is
what
it
will
look
like.
You
start
a
namespace
key
and
that
key
controls
a
table
which
can
delegate
ranges
of
its
namespace
to
other
tables,
which
can
you
know
arbitrarily
go
on
forever,
almost
and
eventually,
delegate
or
assign
a
mapping
to
an
individual
entity
and
they're
really
nice
part
about
this
is
that
the
same
structure
can
be
used
for
a
ton
of
different
applications.
I
Authority
insert
a
new
delegation
cell
into
the
table
and
to
create
a
new
table
for
that
Delhi
to
then
create
its
own
mappings
in
the
proof
of
those
additions
to
the
overall
structure
is
simply
passed,
the
consensus
layer
that
we'll
talk
about
in
a
couple
of
slides
next,
if
you
want
to
key
rotation,
this
is
really
really
easy,
because
all
you
do
is
you
update
your
own
key
in
the
cell
and
you
just
sign
it
again
and
submit
to
the
consensus
there.
So
that's
why?
I
Separating
these
fields
by
by
their
modification
rules
is
really
important,
because
it
allows
the
owner
of
the
cell
to
without
needing
authorization
from
the
authority
to
update
and
rotate
its
own
keys.
But
you
know
it
can't
modify
the
commitment,
because
that's
the
delegate
errs
priority
or
prerogative.
Finally,
you
can
look
up.
I
You
know
arbitrary
mappings
in
the
table
by
starting
at
the
root
key
listing,
finding
the
root
table
and
then
following
by
either
prefix
or
suffix,
match
the
entries
in
the
delegations
until
you
reach
the
value
cell
that
you
want
to
find
or
not
all
right.
So
this
is
all
well
and
good,
but
you
have
to
secure
the
table
structure
somehow,
which
is
why
you
need
a
consensus
algorithm.
I
So
that's
what's
going
to
be
providing
the
safety
and
the
consistency
between
different
nodes
in
the
network
to
actually
provide
these
mappings
and
really
the
interface
is
really
simple.
You
can
pretty
much
use
any
consensus
protocol
that
you
want
as
long
as
it
you
know
actually
does
consensus
and
it
provides
a
way
for
the
application
to
specify
which
proposed
modifications
are
valid
or
not
valid.
I
You
know
you
can
use
threshold
encryption
or
make
a
vote
against
root
authorities,
so
that's
still
kind
of
open
and
we
would
love
discussion
on
that.
Second,
spam
I.
You
know
the
reason
we
have
this
root.
Key
listing
with
you
know,
limit
on
which
entries
can
be
in
there
is
to
prevent
you
from
just
blowing
up
the
entire
structure.
The
same
problem
applies
to
individual
delegations.
I
So
as
soon
as
you
delegate
a
range
of
the
namespace,
you
can't
let
that
go
and
the
del
key
can
do
whatever
they
want
with
their
table,
which
is
an
issue
so
I.
You
know
a
couple
things
that
were
working
on
is
looking
at
a
delegation:
quotas
for
the
size
of
the
tables
that
you
can
actually
delegate
or
making
delegate
errs
responsible
for
their
delegates,
so
kicking
them
out
of
the
tables.
I
If
they're,
you
know
if
they
become
a
problem
and
finally,
in
terms
of
scale,
this
really
depends
on
how
we
run
the
consensus,
algorithm
and
the
data
structures
involved.
You
know
how
many
full
consensus
nodes
do
we
need
and
is
the
system
scalable
to
a
per
user
record
level?
That's
a
question
that
we're
looking
into
okay,
so
we're
going
to
keep
making
changes
and
updates
to
the
draft.
But
in
the
meantime
we
would
love
any
questions
that
you
might
have.
J
Hello,
Brian,
Trammell,
cooler,
cold,
roof,
I,
really
like
this
presentation,
I
have
a
little
bit
actually
I.
Think
it's
gonna
want
to
pick
on
your
your
considerations
at
the
end.
It's
you
know
so
like
this
is
a
pretty
elegant
solution
to
sort
of
the
the
technical
problems,
but
the
dental
problems
are
the
uninteresting
problems,
great.
J
How
like
yeah
so
I
mean
like
the
the
the
I
I,
don't
exactly
see
how
we
take
sort
of
some
of
the
more
you
know
the
more
delicate
questions
of
governance
who
gets
to
say
what
and
map
them
on
to
the
consensus
protocol.
Do
you
have
any
thoughts
there?
It
would
this
be
the
correct
place
for
that
all
right?
Well,
it
would
II
mean
by
governance.
Okay.
So,
like
the
the
consensus
protocol
basic
as
a
K
of
n
right,
you
know
you,
you
send
things
off
to
to
various
observers.
J
J
Question
mark
I'll
turn
this
back
around
and
I.
So
this
is
not
a
please
answer
this
question.
This
is
not
a
gotcha.
This
is
a
think
hard
about
this
yeah
and
I'm.
Wondering
I,
don't
know
if
there's
a
question
for
you
or
for
the
chairs.
If
this
is
the
right
document
for
that
to
be
in
or
but
that
would
there
be
a
different
document
for
that.
L
No
kanata
CMOS.
Okay,
could
you
show
me
that
derogations
slides,
yes,
I'm,
not
sure
about
I
I
couldn't
be
just
back,
but
so,
for
example,
like
I
think
Riksdag
a
sheen,
so
it's
like
in
this
case,
like
Stanford's,
transferred
address,
do
that
company,
which
is
out
of
the
ailing,
that's
needs
in
this
case
cycle.
We
need
to
move
to
the
entry
to
the
Anna's
er
like,
for
example,
a
beanie
or
other
things.
So
it's
this
team
can
do
this
kind
of
things,
so
I
type
in
direct
redirect
to
the
we
delegate
to
the
other.
L
I
So
if
you
want
move
blocks
between
delegations
yeah,
so
that
that's
why
you
know
we
don't
say:
hey
you've
committed
to
delegate
this
forever
so
that
that's
why
there's
a
timeout
on
that.
So
you
know,
obviously,
if
you're
Erin
and
you're
gonna
lose
a
block,
then
you
should
probably
know
about
that.
But
yeah
there's
a
mechanism.
So
once
the
timestamp
expires,
the
table
Authority
can
just
modify
the
mapping.
Okay.
N
N
So
in
very
simple
words,
it
is
a
cryptographic
scheme
that
allows
to
issue
and
verify
credentials
in
such
a
way
that
the
credential
can
embed
multiple
attributes,
for
example,
h,
name
and
so
on,
and
the
selective
disclosure
means
that
you
can
choose
a
user
can
choose
which
attributes
to
reveal
and
which
attributes
not
to
renew
when
they
show
the
credential
to
the
verifier.
Next.
N
So
coconut,
as
I
mentioned,
is
a
selective
disclosure
credential
scheme
which
supports
the
following
properties.
It
supports
blindness,
unlink
ability,
threshold
authorities
and
non
interactivity
between
those
authorities.
Next
and
here
is
a
very
high-level
overview
of
how
coconut
works.
So,
as
you
can
see
to
the
right
side,
there
is
a
set
of
n
authorities
and
a
user
sends
a
request
to
each
of
those
authorities
and
each
of
those
authorities
then
issue
a
partial
credential.
N
N
So
what
do
we
mean
by
threshold
authorities
so
that
basically
means
that
we
don't
require
all
the
authorities
to
be
online.
In
fact,
only
a
subset
of
them
have
to
be
online
or
honest
to
be
able
to
issue
the
partial
credentials
and
for
the
users
to
gather
them
and
consolidate
them
into
a
single
credential.
N
N
So
here's
a
diagrammatic
representation
of
what
I
just
said.
So
we
have
n
authorities
what
we
need
only
shares
from
T
of
those
authorities.
Next,
then,
by
the
second
property
of
non
interactivity,
we
mean
that
the
authorities
do
not
have
to
coordinate
synchronize
or
interact
with
each
other.
In
fact,
they
can
entirely
independently
issue
those
partial
Prudential.
N
Next
by
blindness
we
mean
the
authorities
issue
the
credential,
without
learning
any
additional
information
about
the
private
attributes
which
are
embedded
in
the
credential
and
by
unlink
ability.
We
mean
that
it
is
not
possible
to
link
multiple
showings
of
the
same
credential
across
multiple
verifiers,
even
if
all
of
the
cocoanut
authorities
collude
with
each
other.
N
So
there
have
been
other
systems
in
previous
literature
which
offer
a
subset
of
those
properties.
But
coconut
is
the
scheme
that
offers
all
of
these
properties
next,
so
coconut
is
based
on
three
existing
schemes
which
I
have
cited
below,
and
you
can
read
full
details
about
the
cryptographic,
construction
of
coconut
credentials
in
the
paper
which
I
will
link
in
one
of
the
following
slides.
N
So
we
believe
that
it's
very
useful
to
integrate
coconut
into
book
chains.
The
idea
is
to
enable
only
authorized
users
to
enable
certain
smart
contracts,
so
you
can
imagine
that
in
in
the
standard
web,
we
might
want
to
offer
certain
services
only
to
authorized
users,
usually,
but
instead
user
name
and
passwords
for
authentication.
N
But
it
turns
out
that
it's
not
that
straightforward
in
the
context
of
blockchain,
because
carrying
on
with
the
previous
example
of
user
names
and
passwords.
That
would
basically
mean
that
all
the
blockchain
nodes
process,
the
password
which
is
obviously
not
next
automatically
other
alternatives,
is
to
get
users
to
credentials
from
single
trusted
third
party.
But
then
that
is
not
aligned
with
the
decentralization
goal
of
having
a
distributed
ledger
in
the
first
place.
N
Next,
so
we
feel
that
coconut
addresses
those
issues
and
it
can
be
integrated
into
the
options
in
one
of
these
two
scenarios.
So
in
the
first
case-
and
this
is
the
default
model
that
we
assumed
through
the
rest
of
these
slides-
but
the
other
alternative
is
also
to
more
deeply
integrated
into
the
blockchain,
for
example,
by
allowing
the
block
chains
to
serve
as
coconut
authorities
and
issue
partial
credentials.
Now,
as
you
might
imagine
that
this
makes
sense
only
in
the
context
of
understood
on
the
previous
slide.
K
N
N
So
we
implemented
a
smart
contract
library
for
chain
space
and
also
the
same
library
for
etherium,
and
the
smart
contract
has
different
functions.
So
a
set
of
nodes
can
use
the
create
function
in
the
smart
contract
to
create
a
set
of
coconut
authorities.
The
users
can
use
the
request
function
to
send
a
request
to
those
authorities.
The
authorities
can
issue
the
partial
potentials
to
the
users
using
the
issue
function
and
then
any
third
party
can
use
the
verify
function
to
verify
that
the
credential
has
actually
been
issued
by
the
coconut
authorities.
N
Now
here
is
an
application
of
privacy-preserving
petition
that
we
built
on
top
of
the
chain
space,
the
coconut
smart
contract
library
for
change
space.
So
the
idea
is
that
several
authorities-
Manito
city,
for
example,
Barcelona-
and
they
want
to
issue
some
long
term
credentials
to
its
citizens.
This
allows
the
citizen
to
obtain
a
credential
from
the
coconut
authorities
and
then
use
the
same
credential
across
multiple
different
petitions
without
revealing
their
identity
or
being
linked
across
those
petitions.
N
Next,
so
here's
the
diagrammatic
representation
of
this
privacy-preserving,
a
petition,
smart
contract.
So
the
part
on
the
top
happens
only
once
where
the
citizen
obtains
provides
a
proof
of
identity
to
the
coconut
authorities
and
obtains
a
long
term
credential
corresponding
to
that
proof
of
identity.
And
then
the
citizen
can
use
that
credential
to
sign
multiple
petitions
for
across
different
campaigns
without
being
identified
or
traced.
N
N
Next,
the
citizens
can
reuse
the
same
credential
all
times
across
different
partitions,
while
remaining
anonymous
and
unlink
Abel.
Third
and
the
use
of
multiple
coconut
authorities
allows
prevention
of
the
risk
if
there
were
a
single
Authority
and
that
authority
goes
rogue
and
creates
arbitrary
credentials
to
create
fake
warts
on
behalf
of
non-existent
users
or
citizens,.
N
N
So
I
will
very
briefly
mention
these
other
two
applications,
because
we
don't
have
that
much
time,
but
with
the
coin
tumbler.
The
idea
is
that
a
user
can
buy
goods
or
services
from
a
merchant
without
being
identified,
and
the
design
is
very
simple.
The
user
deposits
a
certain
fund
and
shows
the
proof,
coconut
authorities
which
issue
a
token
to
the
user,
and
then
the
user
sends
that
token
to
the
merchant
and
the
merchant
can
provide
that
token
to
withdraw
that
amount
from
the
buffer.
N
Next,
so
moving
on
to
performance,
the
performance
is
code.
Signing
is
fast
and
signing
takes
about
three
milliseconds
and
verification
takes
about
10
milliseconds.
Next,
the
size
of
potential
is
constant
in
two
group
elements:
no
matter
how
many
attributes
have
been
embedded
in
the
Prudential
and
no
matter
how
many
coconut
authorities
are
there.
N
So
we
set
up
to
ten
nodes
on
Amazon
Web
Services
across
the
world,
in
ten
different
countries
and
on
the
x
axis.
You
can
see
the
threshold
parameter
so,
for
example,
one
means
that
only
one
partial
credential
is
needed.
Two
means
that
two
partial
credentials
are
needed
and
so
on
and
on
the
y-axis.
You
can
see
the
latency
milliseconds
so
as
you
can
see
that
the
latency
increases
about
linearly
in
the
size
of
T,
which
is
the
number
of
potential
number
of
authorities
that
are
required
to
respond
next.
N
So
there
is
a
slight
jump
after
T
is
equal
to
two,
which
is
because
the
two
of
the
nodes
are
located
in
Europe,
so
they
respond
quickly
and
the
jump
is
because
the
third
node
is
located
outside
Europe.
So
as
its
affected
the
further
the
nodes
the
longer
it
takes
to
receive
all
the
responses
and
then
consolidate
them
into
a
single
credential.
N
So
to
conclude:
I
presented
coconut,
which
is
a
selective
disclosure
credential,
and
it
supports
threshold
issuance
which
is
suitable
for
distributed
Ledger's,
and
it's
supposed.
It
supports
free
randomization
of
those
credentials
to
allow
the
same
credential
to
be
used
across
multiple
verifiers,
which
enables
privacy.
N
G
Robert
Wilson.
Thank
you
very
much
for
that
presentation
and
I
have
one
sort
of
question,
and
one
observation
question
relates
to
what
you
said
about
coconut
being
the
first
scheme
that
offers
all
the
properties
you
describes
her
blindness
on
link
ability
and
so
on,
I'm
aware
of
two
other
selective
disclosure
architectures
you
prove
from
Microsoft
and
identity,
mixer
or
it
emits
from
IBM
and
I,
wondered
if
you
had
investigated
those
in
the
course
of
your
initial
research.
G
This
second,
the
observation
was
about
when
you
were
talking
about
change
space
and
its
use
in
smart
contracts
like
the
the
Barcelona
eat
petitions,
you
made
two
assertions:
one
was
the
user
can
use
a
single
coconut
credential
to
sign
multiple
repetitions
while
remaining
anonymous
and
unlink
Abel,
and
the
second
one
was.
The
use
of
a
decentralized
architecture,
mitigates
the
risk
of
a
single
Authority,
going
rogue
and
issuing
multiple
bogus
credentials,
and
my
question
was
if
the
user
can
use
a
single
coconut
credential
to
sign
multiple
partitions
while
remaining
anonymous
a
nun.
Linkable.
K
Hi
this
is
Daniel
Condor
or
just
to
clarify.
I.
Think
that
the
point
that
Robin
was
making
is
that
if
the
authorities
are
in
fact
distributed
and
not
colluding
with
one
another
and
registering
the
same
population,
it
seems
plausible
that
an
individual
could
register
themselves
with
multiple
authorities,
thereby
creating
multiple
identities
with
which
to
vote.
K
N
C
I
guess
I'm
confused
about
the
confusion,
could
wouldn't
I
mean
I'm
imagining
one
credential
says
you
have
the
right
to
vote.
Another
credential
says
you
have
the
right
to
drive
say
you
know
right
I
mean,
wouldn't
the
different
authorities
be
vouching
for
different
things
such
that
you
know
you're
only
using
your
voting
credential
to
vote
that
let
you
live
in
Barcelona
to
vote
for
something
in
Barcelona
or.
C
Yeah
I
mean
presumably
there's
only
one
Authority,
that's
actually
telling
people
the
certifying
people
as
residents
of
Barcelona
right
so
I
think
the
confusion
is.
If
there's,
if
there's
more
than
one
person
who
can
say
that
you're
a
resident
of
Barcelona,
then
you
can
get
to
credentials
that
you
live
in
Barcelona.
But
if
there's
one
authority
telling
you
that
your
resident
Barcelona
another
authority
telling
you
you
have
the
right
to
drive
another
telling
you
you
something
else,
then.
N
We
imagine
that
the
coconut
authorities
would
still
be
under
the
control
of
the
government
of
Barcelona,
but
they
would
be
run
by,
for
example,
different
departments.
So
it's
not
that
anybody
can
become
a
coconut
Authority
in
this
case,
for
example,
due
to
the
sensitivity
of
being
able
to
authorize
citizens,
they
would
have
to
come
from
the
government,
but
not
from
within
the
same
Department,
to
ensure
some
sort
of
transparency
or
distribution.
N
A
H
Okay
good
morning,
I
wanted
to
talk
a
little
bit
about.
You
know
how
closer
okay.
H
Right
so
I
wanted
to
talk
a
little
bit
about
how
I
can
see
that
you
know
the
energy
an
enema
working
group
in
the
ITF
you
know,
could
have
really
a
lot
of
common
interests
and
explain
a
little
bit
about
what
we've
done
and
how
it
could
relate
to
the
energy.
So
in
summary,
I
think
there
are.
There
are
two
directions
right
one
is
you
can
India
energy
leverage,
animal
work
that
was
done
to
make
life
for
what
you
built
easier
and
in
the
opposite
direction
would
really
love
to
see.
H
Yet
you
can
think
of
you
know
a
configuring
healing
managing
optimizing,
protecting,
and
so
the
key
building
blocks
would
be
these
autonomic
Service
agents
shown
here
in
the
middle.
That
would
have
self
knowledge,
network
knowledge,
feedback
loops
and
basically,
you
know
in
a
distributed
decentralized
fashion,
provide
these
self
X
functions
and
they
would
be
embedded
in.
You
know,
on
the
underlying
stuff
somewhere
on
the
bottom
right.
You
have
the
network
operating
system
off
the
network
equipment,
then
the
magic
autonomic
network
infrastructure,
which
would
basically
take
away
all
the
pain
stuff.
H
So
with
that
output,
the
Charter
of
animal
working
group
was
built
in
the
ITF,
and
so
the
first
charter
round
was
really
around
building
the
a
and
I
the
autonomic
network
infrastructure
and
also
to
have
to
proof
points
for
the
Ani,
and
so
the
one
proof
one
and
those
are
informational.
The
first
proof
point
is:
how
can
we
use
the
NI?
H
So
here
is
the
you
know
more
fine-pointed
overview
of
the
autonomic
networking
architecture
according
to
anima.
So
we
see
up
here
intent
and
reporting.
Then
these
autonomic
functions
really
are
just
you
know.
The
word,
for
you
know
a
set
of
distributed
a
si
that
just
something
useful
and
that's
pretty
much
as
much
as
we've
gotten
to
so.
We
haven't
really
worked
on
this
other
than
in
the
reference
model,
describing
the
structure
of
these
elements.
H
For
the
purpose
of
saying
what
does
the
a
and
I
need
to
provide
to
these
ASAS
that
we
think
would
be
great
not
to
have
to
reinvent
in
every
a
si
itself
right.
So
what
the
a
and
I
provides
in
the
first
place
is
that
any
type
of
you
know
fresh
from
the
vendor
and
configured
device
would
be
given
a
domain
certificate
so
that
you
can
have
secure
communications
between
these
notes.
The
second
and
that's
basically
done
by
this
bootstrap
protocol
Bruschi
secure
bootstrap
that
is
basically
providing
their
certificates.
H
We
equally
have
domain
certificates
assigned
to
all
the
existing
wonderful
current
Sdn
nodes
or
even
in
the
future
right
there,
a
lot
of
things
that
are
really
done
a
lot
easier
in
a
centralized
fashion.
So
what
we've
been
trying
to
evolve
from?
Is
you
know
not
autonomic
that
you
know
we
want
to
be
the
self
orchestrating
self
conferring
system.
H
However,
many
parts
are
distributed,
decentralized
or
centralized,
so
it
was
just
the
text
for
this
slide
so
where
we
are
today
current
investigation
future.
So
we
wanted
to
start
doing
our
recharge
ring
and
see
you
know
which
additional
blobs
we
want
to
take
on
and
how
much
to
chew
in
there.
So
right
now,
today,
there's
n
MRG
a
lot
of
the
folks
over
for
a
whole
day
of
discussing
intent.
So
little
progress
was
made
about
intent.
H
It's
now
the
big
buzzword
in
the
industry,
everybody's
talking
intent,
I
think
to
people
talking
about
intent,
we'll
have
at
least
three
different
options.
What
it
means,
then
the
distributed
services
right
on
that
side.
There
are
really
two
big
interesting
things:
right
is
what
distributed
services.
H
Would
we
really
think
to
be
the
next
ones
on
the
line
for
ITF
adoption,
because
ITF
really
means
we
want
to
have
things
that
are
so
important
that
you
know
a
majority
of
networks
would
like
to
have
them,
and
you
know
seeing
these
things
like
distributed,
consensus
and
others
I
think
there
are
really
good
things
that
could
start
coming
in
that
direction.
Of
course,
the
industry
is
a
fairly
slow
in
adopting
new
technology,
so
I'm
I
would
love
to
see
it.
H
You
know
proposals
of
what
we
feel
could
move
into
the
ITF
there,
but
yeah
I
think
that's
a
really
the
core
question
and
then
you
know
for
us
coming
more
from
the
bottom
side.
The
question
is
how
to
build
these
distributed
services
right.
So
what
are
the
common
methods
we
use?
We've
primarily
been
thinking
about
how
to
help
developers.
You
know
things
like
the
form
of
verification,
of
course,
could
be
cool
things
if
we
could
establish
at
any
point
in
time
standards
there,
but
of
course
the
Ani
itself.
H
We
have
worked
it
out,
I
think
well,
but
I
think
there
always
are
things
for
improvement
and
that's
what
I
wanted
to
focus
on
to
give
an
idea
of
you
know
what
problems
would
be
solved
if
applying
the
technology.
Geez
that
you
know
ya
energy
seems
to
be
looking
right
now
would
be
applied
to
the
a
and
I
so
but
a
and
I
itself
is
not
doing
anything
to
use
a
traffic
or
user
control
right.
It's
just
a
management
plane
right.
H
So
anything
that
you
want
to
build
to
basically
distributed
routing
protocol
improvements
distributed
addressing
all
these
things
were
just
the
management
plane
right,
so
you
can
invent
anything
there
for
actually
user
traffic
user
control
without
conflicting
with
the
a
and
I,
but
actually
leveraging
it
right
and
so
to
understand
what
the
what
the
main
purpose
of
the
a
and
I
is
in
the
context
of
actually
building
distributed.
Things
right,
try
to
figure
out
how
difficult
is
to
get
from
unconsidered
boxes
to
the
ones
where
these
distributed
agents
the
distributed.
H
So
even
when
you're
doing
things
completely
wrong
and
your
routing
is
broken,
your
agents
can
still
reach
each
other
perfectly
fine
through
the
a
and
I
right,
which
is
also
why
we're
very
simple
and
what
the
Ani
is
doing.
There
would
definitely
not
never
be
good
enough
for
really
more
complex
user
traffic
distributed
routing
in
addressing
okay.
So,
let's
talk
about
here
to
get
to
the
point
of
how,
like
you
know,
it
just
was
starting
to
think
about
how
to
get
to
federated
solution
acp
domains
right.
H
H
So,
ultimately,
what
we
want
to
have
is
basically
you
know
a
domain
of
all
these
wonderful
devices
here,
right,
we're
representing
them
as
ducklings.
I'll,
explain
us
in
there
in
the
next
slide.
Why
that
have
their
certificates
and
that
perfectly
well
can
talk
with
each
other
right
communicate
and
do
whatever
fun
distributed
services
these
devices
could
do.
But
the
question
is:
how
do
we
basically
get
to
that
point
of
security
that
each
of
these
devices
has
a
certificate
right?
So
our
terminology
is
we
start
out
with
a
completely
unconnected
device?
H
We
give
it
a
certificate
that
basically
expresses
its
membership
in
this
network
in
this
domain
and
that
what's
makes
it
a
member,
and
that
is
actually
the
very
interesting
part
because
this
from
that
point
on
that
the
devices
have
certificates,
everything
is
really
nice
and
all
these
distributed
decentralized.
Things
can
be
done
very
nicely.
But
how
do
we
get
to
this
point,
and
so
this
is
the
process.
H
This
is
the
mechanisms
that
we
have
and
they're
very
much
built
on
really
looking
at
the
you
know,
current
pkx
architectures
that
we
have
in
the
eight
ITF
take
the
you
know
best
well-established
protocols,
extend
them
and
come
to
a
solution
that
is
fully
automated
and
basically
pulls
these
devices
out
of
the
mud
and
getting
them
enrolled.
So
the
first
thing
is,
the
model
really
is:
is
all
around
the
domain
registrar,
who
is
orchestrating
the
process
and
basically
interleaving
all
the
necessary
steps?
H
So
the
first
thing
is,
you
know,
a
new
pledge
comes
up
and
basically
you'll
discover
it.
You
know
the
Registrar
discovers
it
figures
out
that
its
identity
may
go
to
a
domain
admission
controller
and
say:
how
do
you
know
the
pledge
with
this
identity
would
like
to
join
the
domain,
get
into
the
lake,
and
is
that
permitted
and
there
might
be
all
type
of
policies
with
that.
So
the
next
thing
is
then
ok,
so
let's
assume
the
pledge
is
permitted.
H
H
Research
are
the
objects
that
are
very
gullible
and
let
them
you
know
you
can
do
anything
you
want
to
them
as
soon
as
your
the
first
instance
like
you
know
the
mother
duck
that
they
see
right
and
in
many
cases,
that's
by
far
not
secure
enough,
which
is
why
in
brewski
we
come
up
with
the
notion
of
a
voucher
where
the
vendor,
the
NASA
here,
is
basically
providing
an
attestation
to
the
domain
that
this
domain
owns
the
duckling.
So
basically
you
provide
that
essa'
station
the
voucher
to
the
pledged
on
and
then
the
pledge
says.
H
Ok
now
you
can
configure
me
and
then
the
final
step
happens.
You
try
to
give
the
duckling
a
certificate
and
now
because
we're
also
wanting
to
establish
distributed
connectivity.
We're
also
embedding
the
address
of
the
new
duckling
into
the
certificate,
so
that
we
also
have
a
secure
mapping
between
the
you
know:
secure
identity,
the
certificate
in
the
address
it
can
use
in
the
network.
So
this
is
all
you
know.
If
you
look
at
it
all
these
components
are
yeah.
You
can,
maybe
you
know,
make
them
to
some
degree
redundant
but
they're
all
based
on
individual.
H
You
know
non
decentralized
trust
models
and
so
would
really
be
interesting
to
figure
out
how
this
overall
security
model
could
be
moved
into.
You
know
a
decentralized
federated
solution,
and
so
this
was
basically
a
little
bit.
How
I
was
thinking
about
this?
Applying
you
know,
block
chain
distributed
Ledger's
and
the
voting
mechanisms
to
this
problem
space
right.
H
So
the
first
problem
that
we
have
is
we
really
have
no
good
ways
to
express
ownership
of
notes
right
who
actually
owns
a
note,
so
that
he
can
basically
express
what
should
happen
to
it
right
and
obviously
those
things
could
be
done
through
distributed
ownership
and
ledger
systems.
And
if
we
look
at
you
know
the
problems
that
individual
vendors
might
have
to
bring
up
systems
like
the
Massa
through
which
this
is
done
on
their
own.
This
might
actually
be
very
interesting
area
to
apply
ledges
to
and
figure
out
how
it
could
be
done.
H
On
the
other
hand,
you'll
have
you
know
all
these
policies
for
these
domains
right
and,
if
you,
for
example,
don't
want
to
send
up
a
domain,
that's
owned
by
an
individual
entity
by
the
federated
domain.
Maybe
you
want
to
have
exactly
a
distributed
ledger
based
mechanism
to
establish
policies
for
the
domain
right
which
nodes
are
allowed
into
the
domain
and
whatever
other
policies.
H
That
would
come
from
exactly
that
ownership,
ledger
and
then
the
overall
operations
of
the
domain
itself,
based
on
the
policies
that
you
know
the
management
they
you
know,
the
federated
management
has
done
right,
so
that
would
be
kind
of
maybe
a
starting
point
of
thinking
how
to
apply
these
federated.
These
distributed
ledger
voting
system
and
so
on
basically
get.
G
H
A
How
does
it
resonate
with
you?
Do
you
see
a
potential
connection
here?
So
one
of
the
contributions
of
an
IRF
group
is,
of
course,
also
to
you
know,
provide
directions
or
you
know,
neck
options
for
next
steps
for
for
IETF
work,
and
so
we
are
does
kindly
you
know
came
up
with
some
ideas
how
this
could
look
like.
C
H
Haven't
even
gotten
to
that
point,
excellent
I
mean
I
hadn't
even
had
the
time
to
look
into
this
suite.
There
is
the
working
group
in
the
ITF
to
do
primarily
all
this
software
upgrade
mechanisms,
primarily
in
the
IOT
space
and,
of
course,
even
more
security
mechanisms
to
be
safe
against
the
quantum
attacks
and
so
on,
but
we
haven't
really
in
anima,
taken
up
and
try
to
integrate
any
output
of
that
into
this
framework,
because
you
know
the
operating
system
that
needs
to
be
there
below
to
it.
E
Think
that's
an
excellent
question
and
what
I
see
on
this
diagram
are
really
not
so
many
protocols
about
some
of
them
are
protocols,
but
we
most
of
them
are
actually
documents
that
claim
something
and
are
signed
by
somebody
else.
You
just
take
it
away
and,
for
instance,
in
the
software
update
working
group,
the
main
outcome
will
be
a
document
called
a
manifest
that
contains
signed
claims
and
I.
E
Think
it's
really
interesting
to
see
that
we
have
all
these
various
sign
claims
coming
up
and
some
of
them
legacy
ones
that
really
are
verging
FTAs
I
do
have
a
different
problem.
Certificates
were
designed
to
pair
names,
with
private
keys,
there
were
public
keys
and
now
we're
using
them
in
a
weird
way.
Anyway.
We're
seeing
all
these
documents
coming
up,
and
maybe
one
thing
we
should
think
about
is:
do
we
have
something
like
a
calculus
for
deriving
assertions
from
all
these
sign
claims
that
we
get
so
the
people
were
the
choice
in
this
picture.
E
They
actually
have
to
make
decisions
based
on
multiple
of
these
documents
and,
of
course,
we
can
design
all
these
documents
to
be
different
and
come
up
with
the
bespoke
ways
to
make
those
decisions
or
we
can
try
to
extract.
What
do
you
actually
are
the
commonalities
between
all
these
sign
claims
and
to
be
able
to
actually
construct
new
sign
claims
without
having
to
necessarily
define
new
software,
to
understand
and
process
that,
and
that's
something
that
I
would
call
security,
semantics
and
I?
Think
it's
a
pretty
pretty
important
thing.
E
H
I
mean
that
that's
a
great
point,
I
feel
that
right
now
in
the
IDF
were
kind
of
a
little
bit
in
the
opposite
direction.
We're
spending
90%
of
our
time
on
you,
know
five
or
more
variants
of
presentation
layers,
and
you
know
different
protocols
that
are
doing
the
same
thing.
So
I
mean
to
an
extent
if
there's
in
this
interest
in
the
industry,
it's
it's
hard
for,
for
the
you
know
the
IDF
to
push
back,
but
yeah
that's
the
core,
and
that
would
be
great
to
concentrate
on
yeah.
H
A
L
Good
morning,
one
whooping
up
from
hallway
today
I'm
going
to
talk
about
the
decentralized
internet
resource,
trust
in
Fletcher
and
I.
Think
this
topic
is
relative
to
some
topic
presented
today,
including
the
medic
interrogation,
the
consensus
algorithm.
So
this
were
in
this
work.
We
collaborate
with
uc3m,
unique
and
eternal
telecom,
the
background
that
some
critical
infrastructures,
the
trusted
infrastructure
in
the
internet,
our
centralized,
including
the
resource
PTI,
which
is
the
trusty
instructor
for
IP,
addresses
and
IAS
numbers
in
sack
for
domain
names
and
the
PKI
for
identities.
L
So,
basically,
these
systems
are
all
have
a
centralized
or
hierarchical
structures,
typically
tree-like
structures
in
these
structures.
The
root
nodes
often
have
privilege
over
the
subtrees,
malicious,
malicious
or
a
misconfigured
rules
can
cause
problems
of
the
sub-trees.
So
but
I'm
not
going
to
talk
about
the
general
problems
and
solution
to
the
in
system.
Instead,
I
will
focus
my
talk
on
the
resource
PKI.
The
resource
bhai
follows
the
same
hierarchy
of
the
IP
address
allocation
system.
L
L
Then
the
regressor
owner
can
sign
a
root
original
third
authentication,
which
is
called
RA
to
map
the
prefixes
to
the
s
numbers.
Then.
The
fourth
step
is
on
the
BGP
routing
plan.
The
BGP
routers
can
rely
on
the
are
ways
to
detect
the
root
origin
hijack
attacks,
that
is,
to
detect
the
perfect
as
mapping
the
fig
mappings.
So,
basically,
ideally,
the
RPK
can
help
with
mitigating
the
BGP
hijack
attacks.
However,
misbehaving
RPI
authorities
cause
risks
to
BGP,
so
these
two
papers
listed
here
study
the
flipped
threat
model
where
the
BGP
route
is
illegitimate.
L
Well,
the
RP
car
is
at
fault,
so
in
these
papers
miss
Bea.
They
study
that
misbehaving
or
30
can
unilaterally
take
it
down
the
descendants
by
the
droughts
by
adding
or
writing
the
erase
by
revoking
deleting
or
over
writing
the
are
seized
and
the
RA
objects
in
the
RPI
repository.
So
there
are
some
word
case
studies,
so
the
real
root
cause
of
these
problems
is
that
an
entity
in
the
hierarchy
does
not
independently
owns
is
its
address
space?
L
Actually,
the
parent
or
the
ancestor
note
in
the
hierarchy
they
own
the
address
base
and
only
sub
allocates
the
address
space
to
the
children.
So
so
they
have
the
privilege
to
manage
the
children's
are
seasoned
always
so
we
want
to
ask:
can
we
design
a
new
trustee
infrastructure
to
solve
those
problem
and
anybody
can
use
independently
on
their
address
base?
L
So
these
are
our
design
goals.
The
top
design
goals
include
any
organization
like
the
ISP
content
provider,
enterprise
and
university.
Anyone
independently
owns
is
resources,
including
the
IP
addresses
and
Leia's
numbers,
and
the
validity
of
source
resource
ownership,
and
the
mapping
only
depends
on
the
ownership
itself
instead
of
any
third
party.
There
are
also
some
secondary,
secondary
level
goals,
including
preventing
the
address,
exhaustion,
enforcing
prefix,
aggregation
and
enforcing
the
organization,
level,
traceability
and
admission
control.
L
So
this
system
will,
with
the
obvious
ipv6,
address,
allocation
and
ipv6,
and
before
address
transferring
ok,
let
me
introduce
the
system
design.
This
is
the
first
part
for
the
address
ownership
when
we
use
a,
we
use
a
different
right
commando
at
blockchain
for
the
consistent,
perfect
ownership
and
prefix
to
a
at
making
these
this
system
is
broke
chain.
It's
wrong
by
the
eligible
organizations.
I
will
talk
about
what
are
the
eligible
organizations
later,
but.
J
L
The
in
this
figure
you
can
see
that
we
have
example
on
four
nodes
on
the
figure
run,
the
distributed
library,
including
SP,
a
SP
P
comes
in
provider
C
and
the
university
team.
They
are
the
eligible
organization
and
wrong
the
blockchain
and
Evernote.
We
were
smart
contract.
We
use
the
smart
contract
technology
for
the
tree,
ensure
the
unique
and
aggregated
prefix
allocation.
L
So
the
procedure
is
very
simple:
if
SP
you
want
to
apply
for
new
ipv6
prefix,
it
just
stands
a
request,
which
is
a
transaction
asking
for
a
P
basics,
for
example,
age,
32,
prefix
and
insert
the
annual
fee
into
the
transaction
then
send
the
transaction
to
the
other
node.
The
other
node
running
in
the
spawn
will
run
the
smart
contract
to
calculate
calculate
continuous,
perfect
for
B
for
from
the
available
address.
Poor
then
write
the
transaction
and
as
well
as
address
ownership
into
the
ledger.
L
So
today,
at
this
point,
SPB
will
be
allocated
or
prefix,
and
then
it
can
verify
its
ownership
on
the
blockchain.
So
we
can
see
that
as
PP
doesn't
apply
for
for
the
address
space
from
any
third
party.
Instead,
it's
just
can
the
thinks
or
mines
the
perfect
from
the
blockchain?
Okay,
so
but
SPE
doesn't
owns
the
ultra
space
forever
after,
for
example,
if
the
prefix
expires
and
the
50,000
lira
near
the
prefix,
then
the
smart
contract
will
be
triggered
and
return.
The
address
prefix
back
to
the
pool.
L
L
I
verify
that
the
sender
is
actually
the
address
owner
then
writes
the
RA
into
the
ledger,
and
a
third
staff
is
on
the
routing
plane.
Mm
parties
can
guide
the
updated
RAS
from
the
ledger
and
is
synchronized
to
the
BGP
routers.
We
should
then
verify
the
BT
for
us
to
detect
the
hijack
problems,
so
we
can
see
that
the
Rutter's
doesn't
have
to
the
router
do
not
have
to
change,
because
they
can
still
you
this
the
current
interface
to
the
relying
parties.
So
the
change
is
only
on
the
manage
or
the
trust
plane.
L
The
third
part
of
the
system
is
preventing
address.
Exhaustion.
Ipv6
has
a
very
large
address
space,
but
it
isn't
still
within
it.
So
we
want
to
prevent
any
party
from
exhausting
the
address
space.
We
have
two
methods
to
prevent
it.
The
first
one
is
at
the
answer.
It
is
a
also
the
practice
today.
The
Anna
sites,
which
are
early
small
networks,
can
get
smaller
address.
Space
such
as
you
know,
/
48,
a
nice
piece.
L
They
can
get
larger
address
space
for
its
employee,
it
can,
they
can
get
/
32,
but
if
they
want
to
apply
for
a
new
332,
they
have
to
prove
that
the
host
density
ratio
of
the
existing
traffic's
is
over
a
threshold.
So
there
are
equation
here
to
calculate
the
HD
visual,
but
basically
it
is
a
utilization,
your
retention
rate
of
the
existing
prefix
okay.
If
they
they
have
hire
a
very
high,
they
have
their
HD
visuals
over
a
threshold
that
they
are
eligible
to
require
for
request
for
a
new
selection.
L
Okay,
the
second
measure
that
we
want
we
can
prevent
the
address.
Exulting
is
using
money,
you
know.
Currently,
the
I
are
a
new
fee
for
32
is
around
from
$1,000
to
$2,500,
and
so
as
48
is
from
$100
to
$800,
but
if,
let's
assume
that
we
use
$2,000
as
annual
fee
for
us
right,
32,
then
consuming
the
whole
IP
basics
or
trespass
will
cost
10%
of
the
whole
world
GBP,
so
I
think
the
attack
is
impractical,
impractical.
L
The
forest
part
of
the
system
is
a
perfect
aggregation.
You
know
we
want
the
entity
to
apply
for
the
continuous
address
space,
not
the
fermented
ones.
So
you
can
see
that
in
our
system
you
can
now
decide
which
prefix
it
would
get.
You
can
only
specify
how
large
space
it
space
you
want,
and
the
smart
contract
will
calculate
a
continuous
address
perfect
for
you
for
the
address
aggregation
and
the
the
smart.
Our
contract
will
run
the
sparse
delegation
algorithm,
which
is
also
currently
used
by
the
IRS.
L
The
fifth
party
is
the
admission
control,
so
for
the
purpose
of
the
security
and
traceability,
we
think
that
only
the
organization's
also
write
by
the
IRS
or
IRS
are
invisible
to
the
roger
and
they
are
info
and
anything
information
should
be
registered
for
accountability
and
feasibility.
Just
like
today's
who
is
did
this
so
traditionally
you
the
permission,
ledger
only
the
entities
who
who
the
entity
identities
are
induced
by
the
IRS,
for
example
the
IRS
and
IRS,
are
permitted
to
the
gym.
L
You
can
see
that
we
still
have
the
IRS
in
our
system,
but
I
think
difficult.
It
is
different
than
today,
because
in
our
system
the
IRS
are
only
the
indulge
in
dozers.
You
can
see
that
we
separately
true
functionalities
in
your
system.
One
is
endorsement,
the
other
is
address
allocation.
So
in
our
system
the
IRS
did
not
own
or
control
manage
of
the
resource.
The
adjust
in
dozers
and
beside
that
in
our
system,
the
IRS
and
owner,
are
just
equal
and
independent.
They
do
not
have
the
such
as
a
top-down
leadership
from
each
other.
L
Okay,
we
are
still
working
on
some
open
questions
and
the
first
one
is
the
intro
dependency
between
the
blockchain
and
the
PGP,
the
decentralize
er.
You
know
we
want
to
use
the
blockchain
to
secure
BGP,
but
we
should
depend
on
the
EPC
to
secure
the
blockchain,
so
it
is
a
interdependency
we
were
working
on
that,
but
we
think
that
our
pita
has
a
similar
problem.
The
second
open
question
is
about
the
consensus
algorithm.
L
Currently
we
are
implementing
permission,
the
e
theorem,
which
is
part
you
know
powa
pure
ask,
but
eventually
we
think
we
are
going
to
implement
a
new
best
con
censor
algorithm
for
our
specific
sake,
application,
so
I
simply
may
be
a
Content.
The
last
question
is
how
to
get
started.
We
want
to
request
4/20
ipv6
address
space,
to
do
the
experiment
and
so
that
the
solution
we
want
to
use
I.
L
M
J
Sorry,
hi
Brian,
Trammell,
okay,
three
for
the
same
question
from
the
last
question
that
I
asked
when
I
was
up
here.
I'm
actually,
can
you
go
back
to
your
open
questions?
I'm
gonna
leave
all
of
the
venue
problems
out.
You
have
a
missing
open
question
with
respect
to
you're,
basically
trying
to
build
a
smart
contract
system
that
will
more
or
less
for
the
address
policy
allocation,
replace
the
policy
development
process
of
the
various
are
ers.
J
Have
you
done
an
analysis
of
the
policy
development
process,
the
outputs
of
that
process
to
verify
that
you
can
actually
model
those
in
the
smart
contract
right
like
so
there's
a
lot
of
complexity.
There
that's
there,
for
you,
know
various
historical
reasons,
but
most
of
that
complexity.
That's
currently
in
those
policies,
is
there
for
actual
reasons,
so
streamlining
that
out
is
not
a
feature.
Yeah.
L
F
J
L
C
C
The
del
map
work
okay,
that
was
presented
earlier
today
that
delegated
mappings,
because
then
you
could
sort
of
have
a
side
by
side
apples
to
apples
comparison
of
how
much
do
we
gain
you
know,
obviously
we
gained
by
the
by
giving
ownership
of
stuff.
So
like
the
counter
examples,
you
have
the
beginning.
C
L
Thank
you
very
much
for
your
question.
I've
give
the
great
concerts
the
first
one.
It's
about
the
dedication
chin.
What
we
think
is
different
from
their
solution,
because
we
do
not
want
the
dedication
chin,
because
if
we
want
the
dedication,
can
you
depend
on
other
others?
True
give
you
the
resource,
so
we
do
not
run
that
in
this
system.
The
second
question.
C
Could
be
you
could
plug
yours,
your
allocation
scheme
into
their
thing,
where,
instead
of
a
single
Authority,
it
would
be
a
it
would
be
the
output
or
some
other
process
determining
that
this
is
a
valid
delegation,
but
it
will
be
nice
to
make
them
work
together
such
that
you
can
sort
of
compare
apples
to
apples.
Okay,.
L
Yeah
I
will
think
about.
Thank
you.
The
second
question
is
about
you
said
about
probing
the
networks
for
the
HD
racial.
However,
in
this
case,
we
just
calculated
the
assignment
I
mean
I,
didn't
to
introduce
it,
but
the
assignment
is
also
locked
on
the
ledger
so
that
we
can
use
the
assignment
to
evaluate
to
the
HTT
ratio
just
inside
the
system.
It
is
a
closed
system.
C
J
O
Just
because
here
on
this
slide,
it
you
know
sort
of
indicates
who
would
receive
it,
but
then
on
the
next
slide,
you
have
it
looking
more
like
it
would
be
DRI
R.
So
that
seems
like
an
area
where
some
more
clarity
would
be
useful.
My
other
comment
is
just
because
there's
been
a
little
bit
of
confusion
lately
out
there
in
the
world
about
how
address
blocks
can
be
assigned
for
experiments
lately,
that's
a
process
that
requires
IETF
review,
so
just
wanted
to
make
a
note
of
that.
So
everyone's
aware
it.
A
M
A
So
we're
almost
out
of
time,
but
we
still
want
to
give
you
an
update.
What
what
happened
to
the
energy
Chara
and
our
future
plans,
so
I'm
not
going
to
read
that
and
right
now,
I
personally,
but
we
had
this
discussion
on
the
main
list
and
thanks
to
everyone
who
provided
comments,
so
today
we
had
to
be
quite
selective.
A
We
couldn't
really,
you
know,
have
all
the
offered
presentation
on
the
program
to
apologize
for
that,
but
we
wanted
to
give
you
say
some
impression
of
what
we
think
could
be
a
good
mix
for
future
work
in
this
group.
So
you
know,
protocol
work,
application,
work
systems
and
also
some
ideas,
for
you
know
IETF
impact
in
the
future,
so
we
are
actually
quite
happy
with
that.
We
would
like
to
you
know,
get
more
feedback
from
you.
What
what
do
you
think?
So
we
thought
a
bit
to
a
to
Alice
in
the
IETF
chair
and
I.
A
Think
we
are
in
a
pretty
good
shape.
With
the
you
know,
chata
you
can
always
optimize
it.
We
good
we
will
kind
of
fix
on
Mnet's
but
from
our
perspective,
I
think
we
add
a
point
because
a
week
we
can
go
ahead
and
we
have
some
time
to
discuss
this
now
at
length,
but
so
please
get
back
to
us
or
on
the
mailing
list.
If
you
have
youth
on
this,
thank
you
very
much
and
we
will
probably
have
more
time
at
the
next
meeting.
So
women
make
make
virtual.