►
From YouTube: XAIN's energy-efficient consensus mechanism PoKW implemented in a Porsche Panamera - Laurence Kirk
Description
Recording by Livepeer.tv
B
Thank
You
Horace
for
inviting
us
this
evening.
Thank
you
all
for
turning
out
on
a
rather
miserable
day,
I'd
like
to
talk
about
saying,
I
can
now
work
for,
and
particularly
an
interesting
project.
We've
been
working
on.
So
what
I
would
like
to
talk
about?
Is
this
a
quick
introduction,
we're
going
to
see
a
video
about
it's
a
pilot
project
that
we
did
for
Porsche?
B
B
C
B
To
talk
a
little
bit
about
our
origins,
so
my
origins
are
five
years
ago:
I
was
a
developer.
I
working
on
financial
software
and
the
City
of
London
I
had
some
interesting
blockchain
I
managed
to
mine
about
half
a
Bitcoin
but
I
didn't
know
very
much
about
cars.
I
didn't
own.
A
car
I
then
decided
when,
when
a
theorem
came
out,
I
got
very
excited
about
this
very
interested
in
the
potential
and
etherium
heard
I
moved
to
Oxford
and
was
studying
at
Oxford
University
and
by
chance.
B
Thank
you,
okay,
so
that
was
February
2017.
We
incorporated
here
a
lot
of
the
people
who
started
saying
had
a
background
in
the
automotive
industry,
so
it
was
easy
for
us
to
work
with
companies
like
Daimler
and
then
in.
What's
this
talk
is
Graeme
mainly
about
was
the
results
of
a
competition
that
happened
last
summer,
so
Porsche
decided
to
hold
a
competition
to
start
a
pilot
project
for
companies
who
would
I
start
a
project
on
the
blockchain
for
them,
I'm
glad
to
say
that
I
have
over
a
hundred
and
twenty
applicants.
B
We
run
that
competition
to
start
a
project,
and
these
were
the
broad
aims
that
they
had
of
what
they
wanted
from
that
project.
So
you'll
have
seen
in
the
video
a
lot
of
the
functionality
that
they
wanted,
locking
and
unlocking
the
car
allowing
other
people
to
access
the
car,
allowing
somebody
to
deliver
packages
to
the
boot,
but
also
recording
traffic
data.
B
We
had
to
really
build
a
lot
of
the
hardware
or
use
custom
hardware
in
different
ways,
and
one
of
this
was
hadn't
been
done
before
we
were
trying
to
interface
to
the
car
system.
So
this
is
very
low
level
systems,
work
which
we
had
to
understand,
work
out
how
to
do
this
from
scratch,
and
we
were
trying
to
trend.
We
were
trying
to
control
the
vehicle
from
a
SmartWatch
or
a
mobile
phone
using
bluetooth
and
Bluetooth
Low
Energy
and
the
version
we
used
wasn't
encrypted.
The
messages
were
not
being
encrypted,
so
he
has
to.
B
We
had
to
develop
her
own
encryption
layer
on
top
of
that,
and
also
there
are
limits
on
the
volume
of
data
that
you
can
transfer.
So
there
was
another
challenge
and
finally,
a
general
challenge
to
all
blockchain
systems.
I
think
is
going
to
be
the
question
of
privacy
and
compliance
with
GD
P
R.
So
we
wanted
to
record
data
about
the
people
driving
the
car.
B
So,
given
that
those
with
the
challenges
and
the
aims
of
our
project,
how
did
we
use
the
technology
that
we
had
to
overcome
those
challenges?
So
I'll
tell
you
a
little
bit
now
about
the
technology
at
Seine
and
that's
our
consensus
mechanism.
So
you
had
a
good
introduction
there
about
consent,
some
mechanisms
and
particular
proof
of
work.
So
we
have
a
two-stage
mechanism.
So
now
we
start
with
this.
This
is
talking
about
a
a
private
network.
B
Actually,
so
we
may
be
moving
to
a
public
network
where
this
is
we're
talking
about
you
work
on
a
private
network
here
and
we
have
a
number
of
nodes
that
are
whitelisted,
so
these
are
ones
that
are
allowed
to
participate
in
the
mining
process.
From
that
one
listed
set
of
nodes,
we
produce
a
committee
and
we
do
this
via
a
process
called
cryptographic
sortition
and
the
committee.
B
The
size
of
the
that
set
of
Almaty
is
much
smaller
than
their
set
of
all
the
nodes,
and
that
committee
then
runs
proof
of
work
to
choose
a
leader
who
is
then
allowed
to
mine
a
block.
Now,
because
that
the
size
of
the
committee
is
quite
small,
we
can
have
a
very
low
difficulty.
We
end
up
doing
a
lot
less
computation
than
we
would,
if
you
were
doing
just
a
pure
proof
of
work
system.
B
How
we
do
this,
how
we
select
the
committee
is
very
interesting
and
we
use
some
ideas
from
our
grant
for
this,
and
it's
basically
relying
on
two
aspects.
So
we
have
some
data
that
is
public
and
some.
What
is
private.
The
public
data
is
a
seed
that
is
in
every
block
and
is
we
have
a
function
that
creates
a
new
seed
from
the
seed
in
the
previous
block
and
I
just
said
that
is
public.
B
Everybody
can
see
that
then
we
mix
in
with
that
some
private
data,
so
that
is
the
private
key
of
the
nodes
participating
in
the
network
and
the
way
we
do
this
is
we
have
a
verified
random
function
based
on
the
seed.
This
is
all
public
still,
and
then
we
put
that,
along
with
the
private
key
of
a
node
into
a
saw,
tition
function.
The
outputs
of
that
function
is
a
decision
whether
that
node
he's
accepted
to
be
on
the
committee
for
that
block.
B
So
if
we
look
at
the
first
block
here,
block
number
four
we've
taken
the
seed
we've
worked
out.
Our
vrf
put
that
into
a
sought,
ition
function
and
two
of
the
nodes
on
the
left
have
been
chosen
to
be
part
of
the
network.
Now
they
know
they're
going
part
of
the
committee,
they
know
they
will
be
part
of
the
committee.
No
other
nodes
would
know
that
the
third
node
there
is
not
part
of
the
committee.
B
The
benefit
of
this
is
that,
if
you're
attacking
this
system-
and
you
would
like
to
take
over
the
committee-
you
will
not
know
which
nodes
will
be
chosen
for
that
committee
at
any
particular
block.
So,
if
you
want
to
take
over
the
committee,
you
would
have
to
attack
all
of
the
nodes
that
are
part
of
the
whitelist
okay
mathematically.
B
This
is
a
simplified
version,
but
the
seed
is
chosen
based
on
the
seed
in
the
previous
block.
So
R
here
is
the
block
height
and
we're
just
taking
a
signature
of
the
previous
block
to
produce
the
next
seed.
So
that's
quite
simple:
the
sortition
function
itself
is
a
little
more
complex.
I'll
just
go
through
it
very
quickly.
The
pot
on
the
right
hand,
side.
B
This
is
a
ratio,
so
the
value-
and
there
is
the
target
size
of
the
committee
that
we
want
and
the
number
underneath
that
is
the
size
of
the
total
number
of
nodes
in
the
network.
Now
that's
a
whitelisted,
so
we're
using
that
ratio
to
then
decide
which
nodes
will
be
chosen.
Well,
we
do
that
by
the
left-hand
side.
So
so
far,
we've
had
all
public
information.
On
the
left-hand
side,
we
take
again
some
more
public
information,
the
block
height
the
seed,
the
we
do
something
private
now.
B
So
we
take
this
signature
of
that's
information
based
on
these,
the
signature
of
a
private
key
for
a
particular
node.
So
then,
that
elisa
private
information
that
gets
put
into
a
hash
and
put
into
a
decimal.
So
there
comes
a
number
between
0
&
1.
If
that
number
is
less
than
the
ratio,
then
you'll
be
chosen
for
the
committee,
otherwise
you're,
not
in
the
committee,
so
quite
a
simple
computation,
not
computationally,
expensive.
B
Ok,
so
in
order
to
do
all
this,
we
decided
we
would
have
to.
We
would
take
a
fork
of
the
go
aetherium
client.
We
did
this
after
the
Byzantium
hard
fork
and
to
be
to
the
vanilla
client.
We
added
some
extra
features,
so
we
added
our
consensus
mechanism.
We
also
could
reduce
the
size
of
the
the
data
set
that
is
used
for
the
proof-of-work
hash.
B
B
We
also
had
to
do
something
because
we
were
primarily
working
on
private
networks
here,
and
that
is
that
there's
a
problem
that
if
you
have
a
in
a
private
network,
there
is
less
incentive
to
act
honestly
and
it's
possible
that
if
there
was
a
miner
who
was
had
been
removed
from
the
whitelisted
set
of
nodes,
he
might
try
to
impersonate
one
of
the
approved
set
of
nodes.
So
he
might
send
out
a
block
pretending
that
that
block
came
from
a
miner
that
had
been
wide
listed.
B
So
to
prevent
that
we
make
sure
that
the
miners
signed
the
block
when
they
are
produced,
and
then
this
can
be
checked
by
all
the
nodes
that
accept
that
look.
Ok,
if
you
are
familiar
with
setting
up
a
a
private
network
on
ethereum
and
starting
on
Genesis
block,
you
will
perhaps
recognize
the
config
file
for
that.
So
I'm
sorry
is
pretty
hard
to
see
at
the
back
there.
But
basically,
just
the
part
I
wanted
to
show
is
that
we
added
some
extra
contracts
into
the
Genesis
block
and
these
are
they're
providing
our
access
control
layer.
B
So
these
contracts
are
then
available
for
every
client
and
they
are
used
then
to
whitelist
know
to
remove
nodes.
If
they
haven't
been
misbehaving
now
to
talk
about
the
the
project
itself,
we
collaborated
with
a
couple
of
teams
as
well
as
Porsche
themselves.
We
worked
with
the
portrait
digital
lab
in
Berlin
and
spin
lab
from
Leipzig
an
accelerator.
B
I
should
say
at
this
point
that
although
I
was
involved,
doing
some
of
the
architecture
and
setting
up
some
of
the
infrastructure
for
this
project,
most
of
the
hard
work
was
done
by
my
colleagues
and
I
should
credit
them
for
that.
So
there's
some
of
them
are
here
this
evening.
So
it's
like
the
thing
for
that.
B
B
So
here
you
have
some
four
clients
that
are
when
I'm
AWS,
for
example.
We
also
have
not
that
connected,
so
my
PFS
knows
because
we're
going
to
collect
data
and
store
that
in
ipfs
and
additionally,
we
will
also
have
some
extra
processor
clients
and
extra
mining,
because
we
are
until
their
vehicle
not
to
work,
has
reached
a
critical
size.
We
want
to
make
sure
we
have
sufficient
hash
power
in
the
vehicle
itself
that
I'm
sorry.
B
B
So
this
is
the
module
that
connects
the
canvas
in
the
car,
and
this
is
how
we
interact
with
the
in-car
systems,
so
this
sucks
in
two
ways
both
to
record
data
from
the
car
and
also
to
allow
us
to
perform
actions
so
to
allow
the
door
to
be
unlocked
or
the
boots
to
be
opened.
So
for
this
next
slide,
I
won't
go
into
a
huge
amount
of
detail
because
there
are
a
lot
of
keys
on
there.
B
This
was
just
to
show
you
a
little
bit
about
the
how
we
are
approaching
the
permissioning,
and
so
it
really
is
very,
very
straightforward.
It's
very
typical
of
the
ideas
usually
using
cryptography.
We
have
public/private
key
pairs
that
are
generated
on
mobile
devices
and
in
the
vehicle,
and
this
allows
them
to
verify
the
identity
of
each
other
and
we
use
in
answers
to
make
sure
that
we
don't
use
any
replay
attacks.
We
also
have
some
symmetric
trees
in
the
vehicle
that
are
then
used
to
sign
data
that
it
will
then
go
into
ipfs.
B
B
B
So
the
idea
behind
this
is
that
we
have
niacin
Bob
for
you,
where
you
measure
one
half
of
the
partnership
ur
in
the
previous
talk
now,
this
here
is
going
to
sign
some
text
and
she
so
say
this
is
some
data
that
she
has
perhaps
relating
to
the
driving
behaviour
or
perhaps
relating
to
her
ownership
of
the
car
and
how
it
has
been
serviced.
She
sighs
this
encrypts
it
with
a
public
key,
and
so
it
becomes
ciphertext
so
that
this
point
every
she
can
decrypt
this
data,
which
is
fine
for
her.
She
knows,
is
safe.
B
She
has
control
over
it,
but
obviously
it's
not
very
useful.
She
wants
to
be
able
to
give
access
to
that
data
to
other
people
and
in
particular
here,
which
is
wants
to
give
access
to
this
to
Bob,
and
so
the
way
we
do
this
with
proxy
encryption
is
that
she
creates
a
rien
Krypton
key
to
do
this.
She
uses
her
private
key
and
the
public
key
of
Bob,
and
with
this
she
can
then
sign
the
already
encrypted
text
with
this
proxy
encryption
key.
So
that
gets
rien
to
the
this
later.
B
You
see
on
the
right,
so
no
point
here:
does
she
have
to
reveal
her
private
key,
or
does
she
have
to
reveal
the
clear
text
that
she
had
initially
so
once
she's
rien
crypted
with
this
key
that
is
specific
to
Bob,
then
he
can
decrypt
that
final
data
with
his
private
key.
So
here's
the
means
by
which
Alice
can
allow
Bob
to
see
to
decrypt
this
data
and
to
see
the
data
in
clear
text
and
the
proxy
part.
B
There
is
used
that
you
can
set
up
proxy
nodes
so
that
Alice
does
not
have
to
be
online.
To
do
all
of
this,
she
can
grant
access
to
the
keys
via
the
proxy
and
Bob
can
go
and
go
to
the
proxy
to
get
the
keys.
Okay,
just
look
at
the
hardware.
This
isn't
what
hasn't
come
out
great,
but
we
also
used
a
Raspberry
Pi
here
manage
your
customized
heavily.
B
Now,
anyway,
didn't
take
the
project
initially,
so
we
used
a
the
top-of-the-range
pi
at
the
time
very
standard
things,
so
it
had
one
gig
of
ram,
so
you
can
run
standard
aetherium
node
on
this
without
too
much
trouble.
Now
we're
moving
to
getting
our
systems
onto
much
smaller
devices
and
devices
that
are
far
more
constrained.
B
We
did
have
the
problem
that
we
were
customizing,
this
adding,
what's
called
hats
to
the
pie,
the
pie,
hats,
and
we
had
a
problem
that
we
didn't
have
enough
pens
for
this.
So
we
had
to
be
careful
how
he
juggled
that's
the
pin
allocation
and
then
only
on
the
software
side.
On
a
theorem,
we've
developed
a
number
of
smart
contracts
and
libraries.
B
The
contracts
would
hold
the
car
state
so
whether
the
car
was
unlocked
or
not,
and
the
permissions
that
their
car
was
using,
who
will
be
allowed
to
access
it
at
what
time
example
allow
we
have
a
contract
that
allows
users
to
register
on
the
system
and
register
their
key
and
then
get
an
ethereal
dress
from
that,
and
also
we
have
the
user
history.
So
that
shows
what
that
user
has
been
doing.
Who
has
been
accessing
their
car.
For
example,
Porsche
wanted
to
record
certain
pieces
of
data.
B
This
is
just
a
small
set
of
the
what
they
would
do
ideally
like,
and
this
s
fairly
standard.
It
was
the
sort
of
thing
you
would
expect
so
location,
speed,
fuel
level,
mileage
also
outside
temperature,
and
obviously
they
do
need
to
know
what
their
personal
weather
is,
whether
the
driving
conditions
are
going
to
need
to
change.
Because
of
that.
So
this
is
the
data
that
we
took
would
then
be
passed
on
to
ipfs,
and
we
have
a
nice
little
front
end
to
show
this
data
and
again,
sadly,
it
hasn't
come
out
very
well.
B
B
So
that
was
the
the
basic
project
that
we
had,
but
of
course
that
was
just
the
basic
thing
and
since
we
have
completed
that
project,
obviously
we
can
then
expand
and
build
on
that.
So
now
we're
looking
along
with
our
AI
team,
that's
distribution,
machine
learning
for
autonomous
driving.
So
if
you're
looking
at
something
almost
driving,
these
are
generally.
This
is
often
trained
in
very
constrained
environments.
So
you'd
do
this
in
Silicon,
Valley
or
in
a
city
where
the
roads
are
well
defined,
and
you
have
very
nice
road
signs.
B
But
that
is
not
the
whole
picture
and
if
you
want
to
then
take
your
car
to
somewhere
those
it's
a
rural
setting
or
somewhere
that
has
very
badly
bad
roads.
You'll
know
Carlin
profs
not
perform
so
well.
So
our
idea
is
that
we
will
get
the
cars
to
train
in
whatever
setting
they
are
in
and
then
because
they
are
connected
via
blockchain.
B
They
can
securely
pass
that
training
data
around
to
each
other,
and
the
each
car
can
lend
benefit
from
the
experience
of
every
other
car
in
a
network
by
retraining
on
the
data
that
every
other
car
has
has
gained.
The
second
thing
that
we
can
develop,
we
can
build
upon,
is
integrating
with
third
party
systems.
B
So
in
summary,
I
just
like
to
say
this
is
a
very
exciting
and
interesting
project,
of
course,
initially,
because
it's
great
fun
hacking,
something
like
this
beautiful
car
also
I,
was
very
privileged
to
work
with
some
very
talented
people,
so
I'm
very
grateful
to
all
of
those.
This
is
some
of
our
team.
B
That's
it
I'm.
Thank
you
for
your
attention.
If
you
would
like
to
contact
us,
we'd
love
to
hear
from
you,
if
you
are
interested
in
what
you've,
which
you
heard
about
this
project
or
you'd
like
to
talk
to
us
generally
and
avoid
what
we've
been
doing,
you
can
contact
us
as
these
addresses,
but
also
we
have
a
couple
developers
here
in
the
audience
you
can
come
talk
to
me.
I
could
talk
to
Jesse
our
marketing
manager
at
the
end
and
finally,
yeah.
Thank
you
for
your
attention.
B
C
B
A
B
So
a
very
important
point
that
I
completely
forgot
to
mention
was
the
offline
mode.
So
of
course
this
is
going
to
be
important
for
you.
If
you
you've
gone
for
keishon,
you
go
somewhere
remote
and
you
get
out
of
your
car.
You
don't
want
your
car
to
then
be
locked
and
unable
to
be
accessed
because
you're
no
longer
connect
to
the
internet,
so
we
have
an
offline
mode
as
well.
B
So
the
idea
is
the
connection
to
the
car
from
your
device
is
by
a
bluetooth
which
you
will
always
be
able
to
do,
and
then
the
permissions
that
your
car
will
use
if
possible,
it
will
go
to
the
internet
and
download
get
the
latest
permissions
into
the
contract.
But
if
it
can't
connect
to
the
internet,
you
will
just
use
the
permissions
that
it
had
and
then
also
we
have
a
timeout
so
that
if,
after
a
certain
time
it
cannot
connect
and
cannot
get
more
permissions.
B
A
B
For
the
Consensus
itself
that,
as
part
of
the
way
the
committee
works,
this
is
probabilistic,
so
we
get
a
target
size
for
the
committee
and
then
obviously,
if
some
of
those
are
missing,
they
won't
be
able
to
do
proof
of
work.
But
if
you
have
a
Pacific
enlarge
target
size,
then
that
would
be
fine.
I
think
you
were
first.
B
So
question
is:
why
do
we
need
proof,
a
book
at
all
yeah?
So
a
couple
reasons,
first
of
all
me
proof
of
work
and
is
very
well
understood.
Mathematically.
You
can
reason
about.
It
is
a
very
good,
regular
system
from
that
point
of
view,
and
if
we
just
use
say
the
sortition
and
just
to
worked
out
the
committee,
we
would
still
have
to
find
one
leader
from
that
and
so
trying
to
get
the
committee
size
of
one
each
time
would
be
virtually
impossible
and
what
you're
saying
perhaps
that
I
think
is.
B
It
would
reduce
something
more
like
proof
of
authority
where
we
just
wireless
or
some
nodes,
and
we
did
around
robbing
amongst
those
well.
No,
we
not.
Although
we
do
have
these
white
list
of
nodes,
we
do
not
necessarily
cross
them.
It
is
possible
there
could
be
malicious
behavior,
so
we
still
want
the
option
to
be
able
to
remove
from
that
white
list,
so
it's
possible
that
there
will
be
that
will
be
removed
from
the
list
and
will
no
longer
be
able
to
partake
and
because
of
there's
been
malicious
behavior.
C
C
B
B
Then
the
nodes
on
the
cars
well
yeah,
so
very
we're
still
passing
it
back
to
ipfs
nodes
in
the
cloud
at
this
point,
because
we
can
have
a
large
amount
of
data,
the
problems
that
we
have
with
that
are
probably
around
privacy.
So
we
have
to
be
careful
that
we
anonymize
the
data
sufficiently
and
that
we
have
it
sufficiently
encrypted.
So
it's
other
people
cannot
gonna
read
this
data,
two
more
questions:
yeah
yeah.
B
So
this
is
obviously
a
big
problem
for
blockchains
where
data
is
meant
to
be
immutable.
So
we
do
that.
So,
if
we're
dealing
with
encryption
and
ipfs,
we
can
effectively
decide
to
remove
data
from
ipfs
by
allowance
of
garbage
collected
and
then
making
sure
it
hasn't
been
pinned
on
any
node,
but
then
because
we
have
it
encrypted
and
we
can
hold
keys
if
we're
using
the
key
management.
That
I
was
the
really
manage
meant
because
we
hold
those
keys.
We
can
also
burn
those
keys.
So
not
only
have
we
decided
the
data
is
gone.
B
B
So
this
really
came
out
of
the
research
that
life
had
done.
My
founder
had
done
originally,
and
so
he
had
been
looking
at
various
pbft
systems
and
found
that
they
just
were
not
secure
enough.
So
he
wanted
the
security
of
something
like
proof
of
work
with
then
something
that
was
much
more
energy
efficient.
So
that's
why
we
took
that
the
combination
of
the
two
he
found
that
he
could
easily
hack
into
the
into
this
and.