►
From YouTube: The Mauve Revolution
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more.
https://archive.devcon.org/archive/watch/2/the-mauve-revolution
Proof of stake and sharding present two of the biggest upcoming milestones in the ongoing development of the Ethereum protocol. Proof of stake offers the promise to greatly reduce the cost of consensus and increase security guarantees, while sharding presents an approach to allow on-chain scaling to tens of thousands of transactions per second while still retaining a network that can, if needed, run on nothing but a sufficiently large set of consumer laptops. The Casper approach to proof of stake also introduces a number of novel concepts, including consensus-by-bet and fork choice by value-at-loss.
Speaker(s): Vitalik Buterin
Skill level: Intermediate
Track: Scalability
Keywords: sharding, casper, pos, zcash, scalability, cost, latency, pos, mining, pow, validators, miners, casper, epoch, node, incentives, proofs, bittorrent
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 2 was held in Shanghai, China on Sep 19 - 21, 2016.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
A
A
So
if
your
aim
is
obviously
I
can
play
terrible
system,
it's
as
Jeff
Coleman
said
it's.
A
smartphone
from
1999
world
was
trying
to
process
hundreds
of
thousands
of
transactions
a
day
and
for
some
reason,
we're
trying
to
convince
people
to
use
this
thing.
They
can
only
process
fifteen
or
hundreds
of
thousands
a
second
rather
and
we
can
only
process.
Fifteen
transactions
take
14
seconds
to
get
into
one
block
and
minutes
to
finalize.
So
when
a
payment
is
when
a
payment
normally
takes
seconds,
the
blockchain
is
minutes
away.
A
A
We
are
exact
with
your
iam
platform,
falls
short
and
seeing
if
we,
what
parts
of
this
we
can
improve,
so
there's
different
parts
of
this
problem,
so
privacy
tsuzuku
means
wonderful
presentation
on
c--
cash
and
we're
going
to
be
integrating
lots
of
that
stuff
over
the
next
couple
of
months
years
will
see
scale,
but
here
we're
going
to
focus
on
three
things.
One
of
them
is
scalability.
One
of
them
is
cost
and
with
a
bit
of
latency,
so
and
there's
also
a
bunch
of
other
smaller
problems
that
we
have
to
worry
about.
A
Mining
centralization,
selfish,
blinding
vulnerabilities
interface
is
unclean
I'll
talk.
If
people
want
me
to
talk
about
this,
I
can,
but
not
here
so
step
one
proof
of
stake.
So
basically,
what
is
the
point
of
proof
of
stake?
The
intuition
that
I
generally
use
to
describe
it
is
what
I
call
virtual
mining.
So
proof-of-work
you
have
a
thousand
dollars.
You
use
your
thousand
dollars
to
buy
a
miner.
You
take
your
miner,
plug
it
into
the
internet,
plug
it
into
electricity,
and
your
miner
has
the
ability
to
stochastic.
We
generate
blocks.
A
There
is
a
rule
that
says:
if
you
have
a
virtual
miner,
you
have
the
ability
to
stochastically
generate
blocks,
so
the
protocol
itself
basically
defines
you.
It
gives
you
the
right
to
create
these
blocks,
and
it
gives
gives
you
the
right
to
create
these
blocks
in
proportion
to
sort
of
how
big
your
virtual
miner
is.
If
you
get
a
thousand-dollar
virtual
miner,
then
you
can
maybe
create
one
block
a
day.
A
If
you
have
a
two
thousand
dollar
virtual
miner,
you
can
create
two
blocks
a
day
and
so
forth,
so
same
thing
as
proof
of
work,
but
without
wasting
any
actual
electricity.
So
that's
the
kind
of
dream
now
proof
of
stake.
It's
existed
since
about
2011
what
solves
with
the
electricity
problem.
So
here's
the
approach
that
we're
taking
in
cat
in
at
least
my
version
of
Casper,
so
in
the
state
there
is
a
there
is
a
set
of
there-
is
a
set
of
bonded
validators.
The
people
here
remember
what
the
state
is.
A
It's
an
evil
entity,
that's
the
also
third
of
your
money
and
bombs
people
in
third
world
countries.
No,
it's
a
a
stateless
state
is
the
set
of
sort
of
current
information.
That
was
things
like
balances
and
nonsense
that
you
have
to
keep
track
of
and
part
of
the
state
now
is
basically
keeping
track
of
some
set
of
sort
of
bonded
validators.
So
bonded
validators
are
kind
of
active
participants
in
the
protocol
and
they
are
active
participants
in
the
consensus
protocol.
A
Now,
if,
basically,
the
state
is
the
set
of
people
crowd
miners,
the
miners
are
virtual
and
we
are.
We
are
exactly.
Are
these
virtual
miners
kept
track
of
old
or
kept
track
of
in
the
state
of
the
protocol
itself?
Anyone
can
join
the
set
by
sending
a
transaction
to
this
contract.
That's
called
the
Casper
contract,
so
this
Casper
contract
has
a
special
address
in
this
case.
It's
the
number
255
and
if
you
send
a
transaction
to
it
in
this
transaction,
calls
the
deposit
function.
A
Then
you
basically-
and
if
you
along
with
your
call,
you
send
some
ether
in
then
you
can
become
a
validator,
so
you
specify
a
bunch
of
parameters,
called
validation,
code,
Rand,
L
withdrawal
address,
we'll
talk
about
those
later
and
if
you
call
this
function
during
epoch
n,
so
one
epoch
is
like
a
period
of
about
12
hours,
then
at
the
start
of
epoch,
n
plus
two
is
so
like
between
12
and
24
hours.
From
now,
your
validator
joins
the
active
validator
pool,
and
at
that
point
you
basically,
your
virtual
miner
is
active.
A
Now,
while
at
our
data
is
inducted,
they
will
sometimes
be
through
a
randomly
assigns.
The
right
to
create
blocks
is
the
probability
at
any
given
time
that
you'll
be
pseudo
randomly
given
the
rights
to
create
a
block
is
based
proportional
to
the
amount
of
ether
that
you've
deposited
now
in
proof
of
work.
A
block
has
to
contain
a
nonce
and
that
non
span
of
prove
is
a
solution
to
a
proof-of-work
puzzle,
and
that's
a
wishing.
A
The
proof-of-work
puzzle
basically
proves
that
you
in
the
proof
of
work
lottery,
you
got
lucky
and
you
have
the
right
to
create
this
block
here.
Instead
of
doing
that,
blocks
have
to
contain
a
signature.
Now,
what
is
then?
The
signature
is
basically
in
simplest
forms.
The
signature
is
signed
by
the
validators
private
key
and
it's
checked
against
evaluators
public
key,
but
one
thing
that
we
want
to
do
here
is
we
want,
instead
of
having
up
just
using
a
public
key.
We
have
this
notion
of
validation
code.
A
So
what
this
means
is
that
okay,
well,
the
validation
code
is
a
function
and
the
function
says
it
takes
a
signature
and
it
takes
a
hash
as
input
and
it
returns
0
or
1.
Now,
normally,
the
validation
code
might
be
something
as
simple
as
a
signature.
Checker,
so
validation
code
basically
says
take
a
signature
as
input
check
it
against
the
public
key
and
if
the
signature
checks
out
return,
1,
otherwise
return
0.
A
If,
let's
say
us,
a
validator
are
concerned
about,
let's
say
quantum
cryptography,
let's
say
you
think
that
the
NSA
secretive
as
an
arm
the
pervasive
arm
of
the
state,
let
it
is
up-
has
access
to
quantum
computers
and
it
can
break
public
elliptic
curve.
Signature
is
in
an
instant,
then
you
might
want
to
switch
to
Lamport
signatures,
Lamport
signatures
or
type
of
signature.
That's
quantum
resistant,
and
if
you
care
about
that,
then
basically
you
can.
You
don't
have
to
wait
for
the
protocol
too
hard
fork.
You
can
just
switch
to
it
yourself
tomorrow.
A
So
a
validator
can
also
call
start
withdrawal
to
withdraw.
So
one
of
the
differences
between
real
miners
and
virtual
miners
is
that
with
virtual
miners,
once
you're
done
mining
you
can
actually
sort
of
can
unfreeze
the
miner
and
sort
of
turn
it
right
back
into
a
liquid
either.
So
it's
not
a
one-way
process.
If
you're
done
mining,
you
can
call
this
function
called
start
withdrawal
and
you
will
draw
and
then
one
to
two
epochs
later
you're,
you
are
no
longer
part
of
the
active
validator
pool.
You
can
check
your
note
off.
A
You
can
stop
creating
blocks.
Then
you
have
to
wait
a
bit
more
and
after
waiting
a
bit
more,
you
can
withdraw
your
deposit
plus
any
rewards
that
you
earned
minus
any
penalties
of
the
protocol
assigned
you
for
acting
incorrectly.
So
this
is
basically
your
experience.
As
a
validator.
Take
ether
call
the
deposit
function
after
12
hours,
you
become
a
validator.
You
have
to
keep
your
note
online,
make
sure
create
blocks
to
when
you,
whenever
you
get
assign
the
right
to
create
blocks,
keep
that
thing
online.
A
Then,
when
you
get
bored
call
withdraw
then
after
another
12
hours
you
can
check
your
node
off
and
then
after
another
some
point
in
time.
This
might
be
something
like
a
few
months.
You
can
take
your
ease,
you
can
call
schwa
and
you
can
take
your
ether
out
nice
and
simple,
so
people
according
to
some
people,
there
are
supposed
fundamental
flaws
in
proof
of
stake,
so
let
me
go
through
some
of
them,
so
one
of
the
main
problems
is
validator
selection.
So
the
challenge
is:
how
do
we
choose?
Which
validator
creates
the
next
block?
A
Now
in
proof-of-work?
The
problem
is
kind
of
solved
automatically
because
well
one
validator
just
like
randomly
solves
the
puzzle
and
gets
lucky
here.
We
don't
have
that
here
we
have
kind
of
virtual
mining,
and
so
we
have
to
simulate
randomly
assigning
validators
the
right
to
create
a
block.
So
the
state
grunting
problem
basically
says
there
may
exist
an
economic
incentive
for
a
validator
to
perform
computations
do
various
things
to
try
to
manipulate
validator
selection
in
their
favor.
A
So
if,
let's
say
us
a
validator,
you
have
1%
of
like
the
total
active
you
are
1%
of
the
active
validator
set.
If
the
algorithm
is
fair,
you
should
be
creating
1%
of
the
blocks,
but
if
you
can
manipulate
it,
maybe
you
can
manipulate
your
way
to
like
getting
1.4
percent
of
the
blocks,
and
if
you
can't
do
that,
then
you
have
the
incentive
to
spend
anywhere
up
to
0.4
percent
of
the
total
block
rewards
in
order
to
get
yourself
that
privileged
position.
So
here
are
some
examples.
A
In
like
one
old
NXT,
algorithm,
validator
was
sued
a
randomly
sample
based
on
the
signature
of
the
current
block,
so
the
attack
vector
there
is
basically
to
just
grind
a
bunch
of
signatures.
Let
you
find
one
that
favors
you
in
other
there.
In
some
other
older
proof
of
stake,
algorithms,
the
incentive
was
actually
to
find
a
favorable
address
to
move
your
coins
to
so
you
can
figure
out
which
address
you
can
move
your
coins
to.
You
know
we
are
that
address.
We
get
assign
the
block
here.
A
A
So,
for
example,
the
address
moving
issue
we
fixed
by
just
requiring
people
to
kind
of
deposit,
their
ether
well
in
advance
and
by
kind
of
having
a
sort
of
long
lockup
period
and
the
long
withdrawal
period.
So
you
can't
just
like
move
coins
around
quickly,
so
the
other
problems
are
solved
by
basically
having
a
kind
of
by
having
a
validator
selection
algorithm
that
actually
is
fairly
economically
robust.
So
in
general,
this
problem
actually
is
solvable.
So
you
might
hear
arguments
that
say
things
like
marginal
cost
approaches,
marginal
revenue
or
whatever.
A
But
the
point
there's
several
different
caveat
to
this.
The
most
important
one
is
that
it's
not
enough
to
say
that
if
you
can't
exploit
the
people,
will
you
you
have
to
show
that
you
know
the
algorithm
actually
can
be
exploited,
so
the
arguments
that
I
can
make
is
we
have
this
approach
where
basically,
the
random
number
generation
is
for
validator
selection
is
based
on
information.
A
This
random
number
can
only
be
one
particular
thing:
there's
no
choice
about
which
number
you
reveal,
because
it
gets
checked
against
something
else
to
be
submitted
previously,
but
once
you
submit
that
value,
then
that
becomes
a
source
of
randomness
for
the
next
block
and
then
whoever
creates
the
next
block
is
going
to
reveal
their
value.
That's
the
source
of
randomness
for
the
next
block
and
so
forth.
So
the
argument
here
is:
yes,
you
can
manipulate
it,
but
there's
two
ways
to
manipulate
it.
A
One
of
them
is
while
you
try
to
like
manipulate
what
your
original
commitments
are.
The
problem
is
that,
when
you're
choosing
what
your
original
commitments
are,
it's
like
so
far
back
and
the
validator
selection
is
going
to
be
based
on
so
much
future
entropy.
So
you
have
no
way
of
kind
of
predicting
sort
of
which
direction
of
manipulation
is
going
to
be
in
your
favor.
A
The
other
way
you
can
manipulate
it
is
by
not
producing
a
block,
so
you
get
the
chance
to
produce
a
block,
but
then
you
see
oh
well,
I
might
produce
a
block,
but
I
might
not
producible.
I
can
that'll
benefit
me,
but
the
problem
is
that
that
has
a
cost
in
the
cost.
Basically,
as
if
you
do
produce
a
block,
you
get
the
block
reward.
If
you
don't
produce
a
block,
then
you
don't
get
the
block
reward,
so
the
number
of
opportunities
where
manipulation
actually
is
more
profitable
than
the
cost
is
very
small.
A
A
So
what
we
do
instead
is
we
baste?
Instead
of
selecting
one
validator,
we
select
the
sequence
of
validators,
so
basically,
we
select
like
an
infinite
sequence
where,
if
value
to
zero
doesn't
show
up,
then
save
then
after
some
point
of
point
in
time,
validator
one
can
create
a
block
validator
one
also
Softline
the
evaluator
to
could
create
a
block
and
so
forth.
So
this
is
actually
fairly
standard,
so,
like
NXT
works,
this
way
a
lot
of
existing
pro
se
algorithms
work
this
way.
A
So
this
is
not
particularly
novel
and
generally
sort
of
is
the
standard
way.
The
sort
of
stuff
is
done.
In
my
opinion,
there
are
some
sort
of
incentive
issues
that
remain
that
should
be
researched
more
regarding
whether
or
not
sort
of
timing
is
incentive
compatible,
but
in
general
this
at
least
in
the
in
practice.
This
has
worked
fairly
well.
So
next
next
point:
let's
talk
about
nothing
at
stake,
so
nothing
at
stake.
Is
this
other
reason
why
proof
of
stake
is
terrible?
A
So,
basically,
here's
here's
the
problem.
So
in
the
normal
case
you
have
you
as
a
miner,
have
four
choices.
Let's
say
there
exists
the
fork.
Let's
say
there
exists,
two
two
blocks
a
and
B.
Let's
say
you
as
a
miner.
Think
that
block
a
has
a
ninety
percent
chance
of
winning
and
Block
B
has
a
ten
percent
chance
of
winning
option.
One
is
you
just
mine
on
neither
of
them
and
if
you
do
that,
you
get
no
reward
option.
B.
Is
you
vote
as
the
option?
One
is
you
vote
on
either
option
two?
A
Is
you
just
create
a
block
on
top
of
a
now
90
percent
chance
a
is
going
to
win
your
integrative
block
on
top
of
a
and
you're
going
to
win
with
them
of
the
option.
Three
vote
on
B
B
only
has
a
ten
percent
chance
of
winning.
If
you
create
a
block
there,
then
you
have
a
much
smaller
chance
of
getting
a
reward
option.
A
This
is
actually
good,
because
what
this
says
is
if
a
block
is
winning
it's
in
everyone's
incentive
to
help
it
win
even
more
so
this
is
basically
the
proof
of
work
as
an
economic
consensus.
Game
has
a
nice
convergence
property.
So
this
is
the
sort
of
thing
that
we
wants
to
have
in
virtual
mining
as
well,
now
naive
proof
of
steak
economics.
So
this
is
how
the
older
proof
of
steak
algorithms
worked.
Okay
vote
on
either
zero.
You
can
make
a
block
on
top
of
a
okay
0.9.
A
A
So
this
is
the
problem,
so
in
we've
had
the
solution
that
we've
been
thinking
that
we've
had
like
as
a
core
concept
for
about
two
years,
but
the
basic
Princeton
called
it's
been
called
different
names
like
there's
slasher.
Now
we
call
it
now.
We
call
them
Dunkle's
and
there's
a
reason
for
calling
them
Dunkle's
that
I
won't
go
into
there.
A
The
general
principle
is,
if
you
make
a
block,
and
if
you
make
a
block
that
doesn't
make
it
into
the
main
chain,
then,
instead
of
being
rewarded,
you
actually
get
penalized.
You
lose
an
amount
of
either
equal
to
the
block
reward.
Now.
What
does
this
do
to
the
incentive
structure?
Well,
it
does
this
actually
this.
This
is
slightly
wrong,
that
the
green
thing
should
actually
see
is
0.9.
Minus
0.1
equals
0.8,
but
it's
still
the
winner.
A
The
point
is,
if
you
look
on
the
third
one
on
B
vote
on
B,
there's
a
10%
chance,
B's
the
right
chain
is
going
to
win
and
you've
got
your
block.
There's
a
90%
chance,
a
is
going
to
win,
and
so
the
fact
that
you
made
a
block
on
the
other
chain
actually
means
that
you
get
penalized
and
it
hurts
you.
So
unless
you
think
that
a
chain
is
going
to
win,
you
actually
have
the
incentive
not
to
create
blocks
on
it.
A
If
you
think
a
chain
is
going
to
win,
you
have
it,
you
do
have
the
incentive
to
create
blocks
on
it,
so
the
consensus
game
is
convergent.
So
this
is
the
basic
kind
of
principle.
Now,
let's
talk
about
finality,
so
there's
c.a.p
theorem,
so
vlad
talks
about
FLP
impossibility,
which
is
the
Floyd
Patterson
result
as
opposed
to
FTL
impossibility,
which
says
you
can't
travel
faster
than
light.
A
A
Now,
if
you
want
to
understand
this,
EAP
theorem
like
this
is
one
of
the
simplest
ways
is
so
just
like
a
look
at
the
sketch
proof,
so
it
basically
says
if
you
have
a
decentralized
network,
then
if
the
network
splits
in
half
we're
going
to
send
transaction
a
which
sends
note
n
ether
from
me
to
Vlad
on
the
left
half
and
on
the
right,
half
I'm,
going
to
send
the
same
ten
ether
from
me
over
to
Ming.
Now,
let's
say:
there's
two
possibilities:
one
of
them
is
on
the
left.
A
Half
my
transaction
to
Vlad
is
accepted
on
the
right
half
my
transaction
to
Ming
is
accepted.
That's
called
inconsistency,
because
now
you
have
two
parts
of
network
that
believe
different
things.
The
second
possibility,
though,
is
at
least
one
of
those
transactions
is
blocked,
so
at
least
one
of
them
would
just
doesn't
go
through
now.
This
is
called
being
unavailable
because,
basically
try
to
send
a
transaction.
Does
it
go
in
the
network
is
or
the
protocol
is
unavailable
to
you
so
ours
now
proof
of
work
is
availability
favoring.
A
If
there
is
a
partition,
it
favors
availability,
most
traditional
Byzantine
fault,
tolerance,
algorithms,
our
consistency
favoring,
if
they're.
If
the
network
splits
in
half,
unless
one
of
the
halves
is
like
more
than
twice
as
big
as
the
other
half
in
which
case
is
not
really
a
half,
it's
basically
the
thing
just
stops.
In
our
case
we
have
a
kind
of
availability,
favoring
base
layer,
so
like
the
concept
of
this
sort
of
proof
of
stake
chain,
that
kind
of
looks
roughly
like
like
that,
this
sort
of
basically
your
proof
of
stake
chain
is
availability
favoring.
A
If
90%
of
the
nodes
go
offline,
the
other
10%
will
carry
it
on.
But
we
have
this
notion
of
a
finality
gadget
and
the
finality
gadget
is
consistency
favoring.
So
basically,
what
the
what
the
finality
gadget
does
is.
It
tries
to
kind
of
get
stronger
confirmations
on
particular
blocks
from
inside
of
the
protocol.
So
how
do
we
do
this?
A
So
one
of
the
principles
is
a
sort
of
fortress
rule,
so
in
proof
of
work
we
talked
about
the
blockchain
that
has
the
most
work
that
proof
work
packing
it
sort
of
winning
right
longest
chain
wins
chain
with
the
most
proof-of-work
wins
in
Casper.
What
we
talk
about
is
the
blockchain,
with
the
most
value
out
lost
backing.
It
wins
so
the
blockchain,
where
people
stake
sort
of
the
most
either
behind
it
wins.
How
do
you
stay
either
behind
the
blockchain?
Now
one
of
them
is
by
making
a
block
in
it.
A
If
you
make
a
block
in
a
blockchain
and
basically
you
stake
your
ether
behind
a
blockchain,
because
in
every
blockchain
other
than
that
blockchain
you
lose
the
you
lose
one
block
reward
worth
of
ether.
So
if
you,
if
the
block
reward,
is
0.2
ether,
you
make
a
block,
you
make
a
block
on
chain
a
you,
have
actually
staked
0.2
ether
on
chain
a
now
against
what
we
do.
Basically,
we
let
people
stake
even
more
ether,
so
we
have
a
separate
mechanism
that
basically
gives
people
the
opportunity
to
make
what
we
call
finality
claims.
A
So
in
this
case,
you
have
a
finality
claim
that
says
this
block
has
some
particular
hash
with
probability
99.9
percent.
Now
what
does
this
mean
to
you
as
a
validator
in
practice?
It
means
in
all
histories
where
this
is
the
case.
You
get
a
reward
of
1.
You
know,
history
is
where
this
is
not
the
case.
You
lose
a
thousand.
Now,
of
course,
it's
sort
of
easy
to
mathematically
see
you
only
have
the
incentive
to
do
this.
If
you
actually
believe
this
block
will
have
this
hash
with
99.9
percent
probability.
A
So
now,
basically
bets
start
off
sort
of
being
very
conservative.
So
let's
say
if
I
now
any
cycle
begins
for
some
block.
Validators
start
off
making
sort
of
very
low
odds
bets.
They
might
say.
Oh
this
thing
is
going
to
be
finalized
with
odds
4
to
1
5,
to
1
6,
to
1
10
to
1,
then,
over
time,
as
validators
see
that
everyone
else
is
betting.
Let's
say
10
to
1
on
a
particular
4
on
a
particular
block,
they're
going
to
be
willing
to
bet
20
to
1.
A
Once
everyone
sees
that
everyone
else
is
betting
20
to
1
they're,
going
to
be
willing
to
bet
40
to
1
and
so
forth,
and
the
third
of
hope
is
that
value
loss
on
a
particular
block
will
increase
exponentially
and
eventually
it's
going
to
hit
what
I
call
economic
finality
and
economic
finality
basically
means
validators
make
these
beds
to
such
an
extent
that
they're
they
are
willing
to
lose
all
of
their
either
in
all
all
histories,
except
for
those
histories
that
contain
a
particular
block.
Why
do
they
do
this?
A
Because
in
the
history
in
the
history
is
that
you
have
that
particular
they
get
some
medium-sized
reward
so
in
over
here
sort
of
the
right
side
of
the
chart,
you
see
there's
a
medium
sized
reward
and
there's
a
pretty
huge
loss.
But
if
you,
if
you
really
are
that
sure
about
the
block,
then
you'll
take
it.
So
that's!
If
then,
if
one
particular
block
gets
finalized,
then
the
finality
cycle
sort
of
starts
again.
So
why
finality?
A
Basically
because
it
makes
even
Forks
and
rollbacks
that
are
backed
by
51%
valuator
collisions
so
expensive
as
to
be
impractical
once
a
block
is
finalized.
It
can't
be
reverted
like,
even
if
two-thirds
of
the
validators
are
evil
look,
they
can
do
still
do
quite
a
few
mean
things,
but
they
can't
revert
the
block,
and
this
is
a
really
nice
property
to
have
another
nice
property
to
have.
A
Is
it
really
benefits
like
client
sinking,
because
when
a
single
transit,
when
a
single
claim
on
a
single
cryptographically
signed
claim,
represents
a
million
basically
like
a
million
dollars
worth
of
value
loss
on
a
particular
block,
then
it's
actually
very
easy
for
white
clients
to
sort
of
like
verify
that
a
particular
block
is
correct
because
all
they
do
is
download
a
bunch
of
these
of
these
claims
and
they
see.
Oh
look.
A
So
all
that
I've
talked
about
so
far
is
non
sharted,
not
particularly
scale,
while
sort
of
simple
proof
of
stake
that
can
it
basically
keeps
everything
fairly
similar
to
proof
of
work,
except
it
makes
block
times
a
bit
faster.
It
makes
the
system
more
efficient.
It
means
the
amount
of
ether
that
has
to
be
issued
in
order
to
pay,
for
miners
goes
down
a
lot
and
so
forth
shorting.
A
So
the
dream
basically
is
to
achieve
unchanged
scaling
to
tens
of
thousands
of
transactions
a
second,
but
it
is
through
a
fully
decentralized
peer-to-peer
networks
like
can,
if
needed,
run
on
nothing
but
consumer
laptops
sounds
like
a
contradiction.
How
do
you
do
it
answer
rails?
Every
node
in
the
network
only
keeps
track
of
a
small
portion
of
transactions,
but
it
can
nor
it
use
morkul
proofs
to
verify
everything
if
needed.
Now.
A
Bittorrent
scales
like
this
with
BitTorrent,
you
know
it
has
huge
like
petabytes
of
data,
but
somehow
it's
still
a
decentralized
network,
and
the
answer
is
because,
if
this
happens,
because
each
node
only
stores
a
tiny
portion
of
the
say
of
the
data,
so
basically
we
want
to
do
this.
For
block
chains
as
well,
the
challenge
of
doing
an
involved
chain
wind
is
that
you
also
wants
to
make
sure
that,
on
top
of
all
this,
you
still
have
a
robust
consensus
so
sharding.
A
Basically,
the
idea
is
that,
instead
of
having
just
one
shard,
you
would
have
multiple
shards
and
these
multiple
shards
are
kind
of
sort
of
mini
block
chains
that
sort
of
grow
in
parallel,
and
these
shards
also
talk
to
each
other.
So
there's
sort
of
one
shard
called
the
home
shard
and
on
the
home,
shard
restore
the
validator
set
and
that's
sort
of
the
shard
that
still
kind
of
works
as
before,
all
the
other
shards
at
any
particular
point
in
time
you
only
have
about
you
randomly
select
or
pseudorandom.
A
We
select
100
validators
to
be
able
to
validate
that
short
at
any
particular
point
in
time.
So
during
each
epoch
and
you
at
the
start
of
an
epoch,
you
say
you
choose
for
each
shard
pseudo
randomly
these
hundred
validators
are
valid,
shared
one,
these
hundred
without
danger
to
these
hundred
or
thousand
or
three
and
so
forth.
Why
do
we
do
this
well
number
one,
because
the
if
the
random
sampling
works?
Well,
then
it
means
the
mechanism
can
be
secure.