so this talk is basically designed to
come out to my first talk which
hopefully I mean there were more of you
listening to that talk in this talk so I
guess we won't have a big problem and
basically the the first talk was kind of
discussing this the problem space what
are the kind of design requirements that
we have when we are trying to build a
public consensus protocol and Casper is
my kind of and you know in collaboration
with italic and the field people
solution attempted solution to this
public consensus problem so this talks
to give you kind of an overview of the
process that led to the development of
Casper Casper's Deline design philosophy
the different parts of Casper as a
protocol and then the failure modes like
you know what can go wrong given how
many faulty nodes so let's let's get
started so the first design principle is
that it should be suited for public
consensus which is basically to say
Center for the kind of analysis that I
shared in my talk earlier this morning
basically Casper should work in a
context where a majority you've knows
our rationale including to undermine
protocol
eventually around in large majorities in
order to undermine protocol guarantees
so as long as that's profitable so
basically what we want to have is
coverage of Byzantine faults with
disincentives specifically been the
default that undermine protocol
guarantees so and and the reason we want
to cover them with dissing symptoms is
because we want an attacker who has a
budget to spend to have to budget a lot
of money in order to undermine the
properties of the consensus protocol so
this is like the first most important
design goal of kaspar we want to make it
expensive for an adversary to bribe a
rational majority of nodes under Moe
undermine the protocol so and so we want
to cover this base of Byzantine faults
with disincentives that's important but
not in gold so another another key
design of goal is that it should be like
client friendly and then the last design
goal is that it should be good for users
and application developers basically and
there and there's - in this two main
ways that I that I with what that means
to me one of them is that Kasper tells
you the state of the finality of
transactions so you won't be surprised
if a transaction is reverted and you
will know when it can't be reverted and
then Casper's also a little latency
which i think is like really important
for user experience I mean as everyone
probably agrees when you're out of
website you want to respond right away
and distribute application it should be
the same way
so and we're gonna cover some background
knowledge before we really get into the
heart of what's new about Casper so
first thing is security Casper is a
variation on security deposit based
proof mistake so it's hard to stress
enough how important security deposits
are to secure in public because it's
protocol especially for state because
it's protocols and I'll explain why
first I'll mention that this this
concept was discovered independently by
many people including j-kwon Nick
Williamson credits Jake Wanda is working
on his protocol tenement Dominic
Williams who he saw on a panel earlier
in vitalik and I we all thought of this
protocol this idea that we can use
security deposits to secure a consensus
protocol ideas that people would have to
place the security deposit in order to
produce blocks and if they do something
bad then they would lose their deposit
so please stake in general uses digital
assets it's not defined in the consensus
as anti-civil mechanism or as proof work
uses computational resources to find
outside of the consensus as T to the
mechanism and there are other variations
on this kind of proven work thing theme
of using outside resources like you have
proof the store is proof of bandwidth
and all these things could be used
conceivably as ante civil mechanism and
there have been some people who look at
designs of crypto currencies based on
those but basically there's
traditionally said to be two fundamental
problems of forsake there nothing is a
problem and the long-range attack
problem so the thing is a problem
basically is an traditional proof state
court goes like you know pure coin
etc next
nodes don't have any disincentive from
being Byzantine signatures are easy to
produce and they don't lose tokens for
being Byzantine and so they have an
incentive to like sign on both chains
and they they cannot they basically have
no expenses and so any profit they can
make from underlying undermining the
Contessa's protocols guarantees is
something that they will do in a
worst-case analysis because they don't
have any disincentives and they'll so
basically do it for free the security
deposit solve anything at stake problem
by requiring that valide just put
something at stake and by making by
removing that security deposit when
there are demonstrably Byzantine in some
way so it basically requires that this
proof of them being Byzantine is
discovered and published to the
blockchain in order to affect their
balances in their deposits right because
everything that affects the state of
Archon has to be published in through
box in and so that the state transition
function can update their state of the
state of their bonds or the state of
something in the ledger so basically as
long as these evidence transactions
aren't censored faults can be punished
and now this is kind of a broad almost
philosophical point where in proof of
work the consensus in producing changes
the consensus is always expensive in an
effort to make it prohibitive the
expensive for an attacker to produce a
longer more a heavier fork so it's it's
more expensive always for the network
then it should then an attacker should
be willing to spend at any time in
security deposit groups take consensus
should be cheap for everyone except for
attackers during an attack and this is
kind of a big shift in approach where
instead of everyone always incurring
more of an expense than attacker might
ever incur people don't incur an expense
but an attacker will incur a very large
expense so this this kind of it's this
approach promises to be much more
economically efficient because instead
of everyone having to always in current
expense only attackers occurred the
expense during attack so this is an also
very was like an important perspective
change and how to secure consents
so in purport the disincentive is
basically again that you the
disincentive is not receiving an
incentive for which compensates you for
your computational work and security
deposit base mistake the disincentives
is basically just a forfeiture of their
security deposit so then we have a
long-range attack problem one attack
problem has basically that an adversary
controls old keys he's no longer have
coins in them perhaps and well the
reason we assume they don't allure
normal teasing them because it's cheap
for the attacker to buy these keep by
these two keys technically to use old
keys it's a pretty change that for I
have a higher score and this this is
kind of fundamental traditional proof
mistake and it's fundamental
all-purpose takes so long as the thing
that people use to authenticate the
current state is the Genesis block
because the Genesis block is something
those by our current assumption produce
a long time ago and the people who have
is something at stake then no longer
have something at stake now and so if
you rely on you can't rely on their
signatures their signatures effectively
mean nothing because they no longer have
something at stake and it can't be
punished for making for equivocating for
making bad signatures so what we need to
do to get around long-range attack
problem is to change the authentication
model instead of authenticating
everything based on your knowledge of
the Genesis block you authenticate based
on your knowledge of who currently has
something at stake and therefore who
currently has signatures that you can
trust so basically this means that
clients have to know who currently has a
deposit in order to synchronize to the
state and if they're able to stay online
often enough then they'll be able to
maintain this list so the validators
rotate over time the the state of the
set of validators today is not to be the
same as the set of validators in two
years so if you come online in two years
of the only knowing the list of the
validators today you're not be able to
synchronize to consensus but if you come
online regularly enough to watch the
validators rotate then you can use the
fact that you know who's bonded today to
learn who's bonded in the future at
every step using the eken
assurance that if these people were
lying to you they would lose their
security deposits so this this kind of
is thing called weak subjectivity and
basically it's kind of like a single
public key for the whole blockchain
which you need to authenticate
out-of-band before you can synchronize
and which kind of changes over time but
you can figure out you can watch the
change happening if you have the current
public key so you can kind of be
man-in-the-middle attacked if you have
the wrong key there and you'll let show
up in some kind of non-existent economy
but and so there's basically some
trade-offs here right in kind of proof
work you just need to know the Genesis
block and you can authenticate the
current state whereas in this kind of
proof state model you need to be online
sufficiently often to have a current
picture of the set of Ponta validators
so that there is some cost there in
terms of what we can provide as a
service to notes who are offline very
often but there is one main benefit to
this approach which is that it's much
much much more like client friendly than
proof work or any agenda Genesis block
authentication model could ever be
because you don't have to download the
header change you don't have to compare
scores of forks that come from the
beginning of time you just you have a
piece of currently economically
meaningful information which you can use
to immediately sync up with the current
state and so the level of like kind of
friendliness that's possible in this
kind of weekly subjective model is much
much greater than what's possible in a
proof of work or kind of Genesis block
authentication model so those are the
trade-offs for that design it's it's
it's this again this this idea of that
you need to know that people are
currently deposit is fundamental to
using security deposit based per stick
in a way that is economically secure
because people who no longer have
deposits are willing to sell their keys
for free almost straight perhaps on an
epsilon is greater than zero
so some more background knowledge
there's the ghost protocol for proof of
work this is a protocol called 3d
heaviest observed subtree produced by
Samba Samba Linsky in zohar quite some
time ago and basically it can reduce the
block latency without reducing the
security for a purple work chain in
proof of work a miner is only rewarded
for a block if it is eventually part of
the chain so if there are these things
called orphan blocks which miner finds
but doesn't get included in the chain
and these blocks don't contribute to
security of Bitcoin for example but in a
theorem we have this kind of
implementation of ghost that makes it so
that we include orphan blocks and they
contribute both to the score of the fork
and we compensate the miners for their
work so the miners aren't screwed by
having their block be orphaned and the
spork is secured because we don't lose
the work the work still become still as
part of like the comparison of the forks
so so basically ghost made proof of work
lower latency without compromising on
security so and basically there but
there there are in theorem we have an
implementation of ghost but it's not the
full ghost protocol is given by Zohar
and somke Lansky and basically we
include orphan the headers of orphan
blocks into the into block chains and I
think should be to their fork but what
we don't do is actually have a block
tree based rule and basically so and the
reason we do this is because it's kind
of simpler and we get most of the
benefits but if we did have the full of
the full implementation we could have
even lower at lower latency blocks we
also kind of execute transactions for
Morphin blocks and selfish mining and
and and money of course would be even
less even less attractive
so Casper is an adaptation of ghosts to
prove thick and we have this similar
kind of thing where we can have like a
more complex version with like trees and
or a simpler version that still has some
of the ghost-like properties and this is
one of the things that we're still
debating between me and Alec about what
would be appropriate for the release of
Casper basically so certainly incentives
will be a function of orphaned
information so that much we agree on now
what we don't agree on is whether or not
we will allow orphaned locks to have the
the bets that there including contribute
to the that history or whether to
execute transactions for market blocks
if we allow these things then we will
have it'll be like a little bit more
complex from the protocol point of view
but it will have we'll be able to have
slightly lower latency and basically
with more complex versions of Casper
that like fully implement this tree
choice rule we can go well below the
end-to-end Network latency in terms of
producing blocks which is good for user
experience but it increases the
implementation complexity because we
actually have to do tree choice as
opposed to just blockchain choice so if
the old blocks are retained in the
innocent in a single chain then they
have to you kind of have to wait for at
least half a network latency say well
you have to wait for the next validator
to produce a block on previous ones so
we kind of arguing about whether the
complexity of the of bringing the block
time below the network latency is worth
it additionally this is kind of a neat
thing I came up with a way to make this
tree choice rule light client friendly
so you could imagine that as a light
client watching like so network latency
blocks you might have a kind of a
nightmare really only through mist left
you're kidding
oh my god
do I actually have Theresa oh my god
okay so you can't the teachers world and
state transition function from our
previous talk
Castro chooses availability what we're
gonna do consensus by having iterative
betting on whether blocks win at a
particular height and basically the
betting games of different heights are
independent and if and the betting games
can finalize blocks if you have a whole
bunch of finalist blocks in row then you
have finalized state so non non
finalized blocks sorry final light box
aren't reverted for two reasons one of
them is that reverting a finalized block
would would create a very large amount
of evidence of malfeasance which would
lead to a very large amount of loss of
security deposits so we have an economic
assurance that to finalize blocks won't
be created because it creates a lot of
this evidence which can be used to
punish a lot of them which means that an
adversary we have to spend a lot of
money to refer to finalized block and
the other reason is that clients were
there for choice rule will refuse to
adopted work that doesn't include a
finalized block a finalized block and so
this this version of finality via
clients strict unwillingness River
blocks can lead to consensus failure in
the case where there's two finalized
blocks shown to G different clients
before they see each other's finalized
blocks but it provides an ironclad
guarantee of finality in the sense that
this we know that this block will not be
reverted because the client just refuses
to do it based on their fortress wall so
Casper designed to be sensitive
resistant basically what the way we do
this is mean if some nodes are offline
we're going to disincentivize if we're
going to see that they were censored and
punish everyone so it so if you were to
censor some some majora it's a minority
then the remaining everyone would would
lose lose money so that if a large
coalition were to cooperate to censor a
minority then they would have to do that
at their expense so unlike before in
traditional mistake it's you don't get a
raise for censoring you get
you know you lose money your salary goes
down so and and then we basically have
to go through our failure modes really
quickly so history perversion is
something that can happen for non
finalized blocks in which case clients
will know that the block wasn't
finalized because Caspar tells you the
state of the finality of the block and
so so the that's that's there is like
some significant mitigation there
preventing finality is kind of a more
serious failure mode where a coalition
could stop an ally from occurring which
prevents them from introducing a new set
of validators this is kinda important
that you need to introduce you need to
finalize a new set of validators before
the first set of validators can can
rotate because you must know for sure
who the validators are when you come
online as a client censorship is another
is like the most severe failure mode if
censorship is successful then evidence
transactions can't get in and people
aren't gonna be disincentivized from
committing Byzantine behavior because
they won't lose their security deposit
so while we do have an economic
assurance that they're sensitive is
expensive if you get sufficiently close
to 100% of nodes to get together to
censor that disincentive shrinks because
the protocol can't tell if there's any
censorship at all knows our sensory if
some ones are missing it could it could
no it could kind of infer that maybe
those in the blocking those nodes aren't
being included so and moreover the cost
of censorship only exists for a finite
amount of time because we can't punish
people forever if some nodes are offline
so there's an there's like a cost that
an adversary can pay to censor Network
and in there but there are some there
are some ways you can mitigate it one of
them is through like cryptographic means
you're like time locket ography and
sorry I'm really close to done or on the
skating transactions basically to make
it hard to censor sound transactions as
though censoring all of them there's
also economic sanctions clients can
detect censorship under certain Network
assumptions and then they could treat
that fork as having a low score and
therefore choose another fork which
might have a minority of nodes
though who aren't censoring or we could
just create a hard fork that removes the
censoring validators from the set of
alligators
there's enough community backing behind
it then that's like a very strong
economic disincentive to attack because
if the community is able really to
govern the code so well that they can
hard work in response to censorship so
while some of these flailing Mo's are
pretty bad actually
Casper has more complete coverage of
faults and in this kind of economic
setting than any other consensus
protocol out there right now but the
devil is in the details there's lots of
Parsley's the way that these rules for
incentivizing consensus in
disincentivizing things have to be
specified so the the complete
specification isn't available yet as you
may have noticed there's still details
of the protocol they may be finalized
however we are starting to do formal
implementation and verification of the
protocol specifically we're looking at
some of the economics but mostly the
convergence properties and that and that
concludes my talk sorry for the way