[Music]
so you say you want a a revolution how
about a mauve
Revolution metallic cool yay okay
um where is the clicky thing oh there it
is perfect so in the uh wait how does
this even work in the interest of press
I'll get right to the point so well okay
maybe I won't get right to the
point where is the clicker
so well first what people read the comic
that the that the mo paper is named
after although I'm sure lots of you have
already seen
it which color you want the blockchain I
think move has the most Ram so let's
scale the blockchain let's add some more
RAM let's make the blockchain
mo so ethereum is obviously a complet a
table system it's uh as uh Jeff Coleman
said it's a smartphone from 1999 world
is trying to process hundreds of
thousands of transactions a day and for
some reason we're trying to convince
people to use this thing that can only
process 15 or hundreds of thousands a
second rather than we can only process
15 transactions take 14 seconds to get
into one block and minutes to finalize
so when uh a uh payment is uh when a
payment normally takes seconds to block
is minutes away very little privacy at
based protocol layer so clearly not good
for anything fortunately that's what the
research team is for we have Solutions
we have solutions for most of these
problems so our main focus in in
research is basically figuring out where
exactly the thean platform falls short
and seeing if we what parts of this we
can improve so there's different parts
to this problem so privacy zuku made
this wonderful presentation on zcash and
we're going to be integrating lots of
that stuff over the next couple
of months years we'll see um 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 mining centralization selfish
mining vulnerabilities interfaces
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 $1,000 you use your $ th000 to buy
a minor you take your minor plug it into
the internet plug it into electricity
and your minor has the ability to
stochastically generate blocks if you
have a minor of $1,000 you might produce
like one block a day if you put $2,000
into your monitor you might produce two
blocks a day but in put money in and you
make blocks and rewards for you come out
proof of stake take $1,000 convert the
$1,000 into 83 ether and then convert
the 83 ether into a virtual minor and
the
virtual and the
uh then the pro inside of the protocol
there's a rule that says if you have a
virtual minor 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 minor is if
you get a $1,000 virtual minor then you
can maybe create one block a day if you
have a $2,000 virtual minor 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 solves Wast the electricity problem
so here's the approach that we're taking
in C 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
do people here remember what the state
is it's an evil entity that steals a
third of your money and bombs people in
third world
countries no it's uh a uh
State the state is the set of sort of
current information that things like
balances and nonces that you have to
keep track of and part of the state now
is basically keeping track of some set
of sort of blonded validators so blonded
validators are kind of active
participants in the protocol and uh they
uh active participants in the consensus
protocol now if basically the state is
the set of people who have virtual
minors the minors are virtual and where
where exactly are these virtual miners
kept track of or they 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 a number 255 and if you
send a transaction to it and this
transaction calls the deposit function
then you basically and if along with
your call you send some ether in then
you can become a validator so you
specify a bunch of parameters validation
code randale 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 2 so
like between 12 and 24 hours from now
your validator joins the active
validator pool and at that point you
basically your virtual minor is active
now while a validator is inducted they
will sometimes be pseudo randomly
assigns the right to create blocks and
the probability at any given time that
you'll be pseudo randomly given the
rights to create a block is based per to
the amount of ether that You' deposited
now in proof of work a block has to
contain a non and that non kind of pro
is a solution to a proof of work puzzle
and that solution to 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 and the signature
is basically in simplest forms the
signature is signed by the validator
private key and it's checked against
evaluator's public key but one thing
that we want to do here is we want
instead of having a just using a public
key we have this notion of validation
code 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 zero or one 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 one otherwise return zero if
let's say us a validator are concerned
about let's say Quantum cryptography
let's say you think that the NSA know as
an arm the uh pervasive arm of the state
that it is has access to quantum
computers and it can break public
elliptic curve signatures in an instant
then you might want to switch to Lamport
signatures Lamport signatures are a type
of signature that's called want
resistant and if you care about that
then basically can you don't have to
wait for the protocol to Heart Fork you
can just switch to it yourself
tomorrow 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 minor
and sort of turn it right back into
liquid ether so it's not a oneway
process if you're done mining you can
call this function called start
withdrawal and you withdraw and then one
to two EPO later you you are no longer
part of the active validator pool you
can check your note off 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 assigned the right to create
blocks keep that thing online then when
you get bored call withraw then after
another 12 hours you can shut your note
off and then after another some point in
time this might be something like a few
months you can take your you can call
withdraw 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 problem s is
validator selection so the challenge is
how do we choose which validator creates
the next block 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 the state grunting problem
basically says there may exist an
economic incentive for a validator to
perform computations due VAR things to
try to manipulate validator selection in
their favor so if let's say you as a
validator you have 1% of like the total
AC 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 weight to like getting
1.4% of the blocks and if you can do
that then you have the incentive to
spend anywhere up to 0.4% of the total
block rewards in order to get yourself
that privileged position so here's some
examples in like one old NXT algorith
validator was suud randomly sampled
based on the signature of the current
block so the attack Vector there is
basically to just grind a bunch of
signatur until you find one that favors
you in other 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 where that address would get
assigned to block fairly soon move your
coins to it get then get make the block
and then immediately move your coins to
another favorable address and so forth
so these issues are
fixable 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
this 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 but the point
there's several different caveats to
this the most important one is that it's
not enough to say that if you can't
exploit it people will you you have to
show that 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 that's not yet AV
information that validators have
committed toally submit the hash but the
validators reveal the information while
creating a block while creating their
block so block n contains basically I
see contains this random number that
gets revealed 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 that you 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 one of them is well you
try to like manipulate what your
original commitments are the problem is
that the 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 that you have no way of kind of
predicting sort of which direction of
manipulation is going to be in your
favor 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 produce a block
and that will benefit me but the problem
is that that has a cost and the cost
basically is 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
so another problem is let's say we
select a validator let's say the
validator is not present
so what do we do well obviously the
blockchain can just stall and we can all
go home right okay the's done go back to
ethereum
Classic so what we do instead is we
basic instead of selecting one validator
we select the sequence of validators so
basically we select like an infinite
sequence where if validator zero doesn't
show up then say then after some point
point in time validator one can create a
block if validator one also is offline
then validator 2 can create a block and
so forth so this is actually fairly
standard so like NXT works this way a
lot of existing proof of stake
algorithms work this way so this is not
particularly novel and generally sort of
is the standard way that 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 practice this has worked fairly
well so next next Point let's talk about
nothing at so nothing at stake is this
other reason why proof of stake is
terrible and can never never work which
why we should just like give up and go
back to proof of
work no um so basically here's here's
the problem so in the normal case you
have you as a minor have four choices
let's say there exists a fork let's say
there exist two two blocks A and B let's
say you as a minor think that block a
has a 90% chance of winning and Block B
has a 10% 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 or I should say option one
is you vote on Nei option two is you
just create a block on top of a now 90%
chance a is going to win you're going to
create a block on top of a and you're
going to win with them the option three
vote on b b only has a 10% chance of
winning if you create a block there then
you have a much smaller chance of
getting a reward option D is to split
your vote between both but if you split
your vote then you get H because you
have to actually split your work in half
you get only half of one and half of the
other and that so it turns out that the
best choice is to just vote on a now
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 a
sort of thing that we wants to have in
virtual mining as
well now naive proof of stake economics
so this is how the older proof of stake
algorithms worked okay votee on neither
zero you can make a block on top of a
okay 0.9 you can make a block on top of
B 0.1 problem is now you can create a
block on top of both and the problem is
because you no longer have computing
power as a limiting factor you don't
actually have to sort of split your vote
in half you can literally just make a
block on one side and make a block on
the other side in whichever one wins you
profit yay so everyone actually even if
there are no attackers everyone has the
incentive to create a block on every
single ch at the same time and therefore
in an economic of model a thing just
never converges 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 PR it's been called it's been
called different names like there's
slasher now we call now we call them
dunal um and there's a reason for
calling them dunkles that I won't go
into um there the general principle is
if you 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 ether equal to the block
reward now what does this do to the
incentive structure well it does
this actually this this is slightly
wrong the the the green thing should
actually see 0.9 minus 0.1 equals 0.8
but it's still the winner 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
that get penalized and it hurs you
unless think a chain is going to win you
actually have the incentive not to
create blocks on it if you think a chain
is going to win you have the you do have
the incentive to create blocks on it so
the consensus game is conent so this is
the basic kind of principle now let's
talk about
finality so there's cap theorem so Vlad
talked about flp impossibility
um which is the Floy Lynch pattered to
Ft impossibility which says you can't
travel F
light that was a
joke I'm going to talk about the cap
theorem so it basically the cap theorem
says in the event of a network partition
you can either have a consistency or you
can have availability but not both now
if you want to understand the capap
theorem like the one of the simplest
ways is to just like 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
know 10 ether from me to Vlad on the
left half and on the right half I'm
going to send the same 10 ether from me
over to Ming now let's say there's two
possibilities one of them is on the left
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 the
network that believe different things
the second possibility though is at
least one of those transactions is
blocked so at least one of them like
just doesn't go through now this is
called being unavailable because
basically try to send a transaction
doesn't go in the network is or the
protocol is unavailable to you so our
now proof of work is availability
favoring if there is a partition it
favors availability most traditional
bantine F tolerance algorithms are
consistency favoring if there 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 it's not
really a half it's uh 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 uh kind of
looks roughly like uh like that this
sort of Bas layer proof of stake chain
is availability favoring 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 um what the finality G 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 so one of the principles is the
sort of foru rule so in proof of work we
talk about the blockchain that has the
most work proof of work backing 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 at loss
backing it wins so the blockchain where
people stake sort of the most ether
behind it wins how do you stake ether
behind the blockchain now one of that is
by making a block in it if you make a
block in a blockchain then basically you
stake your ether behind that 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 Stak 0.2 ether on
chain a now guess 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 so
in this case you have a finality claim
that says this block has some particular
hash with probability
99.9% 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 one in all histories 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 in
to do this if you actually believe this
block will have this hash with 99.9%
probability
so now basically bets start off sort of
being very conservative so let's say a
finality cycle Begins for some block
validators start off making sort of very
low odds bets they might say oh this
thing's going to can be finalized with
odds 4 to1 5 to1 6:1 10:1 then over time
as validators see that everyone else is
betting let's 10 to1 on a particular on
a particular block they're going to be
willing to bet 20 to1 once everyone sees
that everyone else is betting 20 to1
they're going to be willing to bet 40
to1 and so forth and the third of Hope
is that value at 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
bets to such an extent that they're they
are willing to lose all of their ether
in all all histories except for those
histories that contain a particular
block
why do they do this because in the
history in the histories that do have
that particular block they get some
mediumsized reward so you know over here
sort of the right side of the chart you
see there's a mediumsized 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 basically because it
makes even forks and rollbacks that are
backed by 51% validator collusions 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 like 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 is it really
benefits like line syncing because when
a single trans one a single claim when a
single cryptographically signed claim
represents a milon basically like a
million dollar worth of value loss on a
particular block then it's actually very
easy for light clients to sort of light
verify that a particular block is
correct because all they do is they
download a bunch of these of these
claims and they see oh look people are
betting $ 12 million that this block is
correct so I'm just going to assume it's
correct I'm going to then I assume it's
correct then I download the new state
and then I see what what blocks in the
future people are betting another $12
million on and so forth and so forth so
sharding so all that I've talked about
so far is non-shed not particularly
scale while sort of simple proof of
stake that can basically keeps
everything fairly similar to proof of
work except it makes walk times a bit
faster it makes the system more
efficient it means the amount of ether
that uh has to be issued in order to pay
for miners goes down a lot and so forth
Shing so the dream basically is to
achieve unchain scaling to tens of
thousands of transactions a second but
at this through a fully decentralized
peer-to-peer Network that can if needed
run on nothing but consumer laptops
sounds like a contradiction how do you
do it answer is every note in the
network only keeps track of a small
portion of transactions but it can it
can use mer proofs to verify everything
if needed now bitor scales like this
with bit torent you know it has huge
like pedabytes of data but somehow it's
still a decentralized network and the is
because each this happens because each
note Only Stores a tiny portion of the
of the data so basically we want to do
this for blockchains as well the
challenge of doing it in blockchain land
is that you also wants to make sure that
on top of all this you still have a
robust consensus so sharding 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 blockchains 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 you store the validator
set and that's sort of The Shard that
still kind of works as before all the
other shards at at any particular point
in time you only have about you randomly
select or pseudo randomly select 100
validators to be a to validate that
chard at at any particular point in time
so during each Epoch at you at the start
of an Epoch you say you choose for each
Shard Su or randomly these 100
validators are validate chart one these
100 will validate chart two these 100
will validate chart three and so forth
why do we do this well number one the if
the random sampling works well then it
means the mechanism can be secure reason
is if you're an attacker you can't
choose which Shard you're going to
you're going to validate on so an
attacker will still need to take over
the majority of the entire of close to
the majority of the entire network to
take over even one chard so this is sort
of the basic principle um if he wants to
find out more read the M paper which
will be a releas soon and we have a
proof of concept not for charting but at
least sort of for a lot of the earlier
proof things and you can feel free to
pray with it yourself so thank you