[Applause]
okay hello everyone how are you
happy anniversary of the satoshis white
paper ten years yeah they are 10 in
binary counting okay so today I'm going
to basically talk about a ton of a
theory I'm 2.0 but I'm not just from a
technical point of view but more from
the point of view of why aetherium 2.0
what is a theorem 2.0 and kind of how we
got here right so what is a theorem 2.0
first of all if the arrium 2.0 is this
kind of combination of a bunch of
different features that we've been
talking about for several years
researching for several years actively
building for several years that are
finally going to come together into this
one coherent whole and these features
include proof of stake Kaspar
scalability sharding virtual machine
improvements awasum improvements to
cross channel contract logic
improvements the protocol economics and
so really the list goes on and on and
there is some power law distribution so
lots of great stuff now how did we get
here right so the road to proof of stake
actually started way back in 2014 with
this blog post that I published in
January describing this algorithm called
slasher which was introduced kind of the
really most basic concept and a lot of
proof of steak algorithms which is this
idea that if you get caught doing
something wrong then this can be proven
and you can be penalized for it and this
how this can be used to increase
security but at the time as you can see
from the slide I believe that quote
Salah sure is a useful construct to have
in our war chest in case proof of steak
mining becomes substantially more
popular or a compelling reason to switch
but we're not doing that yet so at the
time it was not even clear yet that
of steak is even the direction that
we're going but as we know now over time
that changed quite a lot so what
happened in 2014 so first of all went
through a bunch of kind of interesting
and aborted ideas proof of proof of work
was this kind of suggestion to try to
improve scalability hub-and-spoke chains
so basically you kind of have one chain
in the middle and a bunch of chains on
the edges um this was a kind of very
early scalability and sharding proposal
that tried to improve scalability for
local transactions but not for
transactions that are global so not for
transactions that jump from one car to
another hypercubes
so basically except the cube should have
twelve dimensions instead of three so we
can get more scale even more scalability
with hubs and spokes by going with hyper
cubes now unfortunately for various
reasons the sides he ended up getting
abandoned but someone else has a big ICO
to make it work so happy someone's
trying it out so in 2014 there was still
some progress right so there was this
concept of weak subjectivity that we
came up with which was this kind of semi
formal security model that tries to
capture the idea of kind of under what
conditions are proof of stake deposits
and slashing and all of these concepts
actually secure also I know we got more
and more certain that algorithms which
much with much stronger properties than
the proof of stake algorithms that
existed at the time so things like pure
coin and all of its derivatives were
actually possible and kind of growing
understanding that there was some kind
of proof of state scalability strategy
that you could somehow do is through
random sampling but we had no idea how
and we had a road map so there was this
nice blog post from Vinay grouped in
March 2015 where he outlines the four
big stages of a theorems roadmap at the
time Stage one
frontier if you REM launchings yay Stage
two Homestead which is kind of going
from alpha to beta stage three
metropolis which at the time was
supposed to be about Myst and user
interfaces and improving user experience
but
since then the focus has kind of
switched more to and if enabling strong
cryptography but interface work is
skillful going forward in parallel and
stage for serenity proof of stake right
so from now on we're not going to call
it a theorem 2.0 I also refuse to use
the word chaste because I find an
insanely lame we'll call it serenity
so after this came a bit of a winter so
we had a bunch of different kind of
abortive attempts at solving some of the
core problems and proof of steak some of
the core problems and scalability
research on Casper quietly began Vlad
kind of quietly began to hang all of his
work on Casper CBC one of the first
interesting ideas was this kind of idea
of consensus by bet where basically
people would kind of bet on which block
becomes finalized next and then once
more people bet on a block that itself
becomes information that gets fed into
other people's bets and so the idea is
that you would have this kind of
recursive formula or and more and more
people would bet more and more strongly
on a block at a on a block over time and
after a logarithmic number of rounds
everyone would be betting their entire
money on a block and that would be
called finality that so we actually took
this idea really far we created an
entire proof of concept for it and you
could see it finalizing you can see here
is a signature function
I mean burns most of our time on this
but then that in whole idea kind of
ended up going away basically once we
realized how to make kind of proper BFT
inspired consensus actually work sanely
um rent so this is the idea that instead
of charging a big one-time fee for
filling storage we would kind of charge
fees over time so basically for every
day or every block or whatever that some
storage slot is filled you would have to
kind of pay some amount of ether for it
there was this one I'm ap number number
35 that I tried to call EAP 103 but
really it was a IP number 35 because
that was the issue number that takes
precedence and
this was one of the really early ideas
are trying to kind of formalize this
concept and we've had many iterations on
the idea of how to implement can rent
maximally nicely since then there was
also this scalability paper that we
tried to do back in 2015 and this tried
to kind of formalize the idea of kind of
quadratic sharding super quadratic
sharding but it was very complicated it
had these kind of very complicated
escalation games it had the a lot of
them were kind of inspired by ideas of
how escalation works in court systems an
analogy that I know Joseph with
philosopher Roy lobster Hughes as well
but we tried to use it for the base
layer deep state reversions so basically
if something goes wrong then potentially
large portions of the state could and if
get reverted even fairly far into the
future so there was a bunch of
complexity right now one of the
fundamental problems that we couldn't
quite capture but that we were kind of
event slowly inching towards was this
idea of the fisherman's dilemma and this
is a fundamentally and very fundamental
concept in shorting research that
basically describes the big difference
between scaling execution of state and
scale and execution of programs versus
scaling availability of data and the
problem basically is that with an
execution of programs you can have
people commit to what the answer is and
you can later kind of play a game and
try it's a kind of binary search your
weights or who actually made a mistake
and you can he knows everyone who made a
mistake after the fact the problem with
data availability is that whatever the
game is you can cheat the game because
you can just not publish the any data at
all until the mechanism tries to check
if you published it and only then do you
publish just the data that the mechanism
checked for and this turns out to be a
fairly large flaw in a fairly large
class of the scalability algorithms and
I wrote this a blog post if you want to
search for it you can call it it's
called a note on a racial coding and
data availability that describes some of
the issues and more deets
but still this was one of the things
that delayed us but even still we were
happily making progress aetherium was
moving forward we were on our way
wait then this happened okay
no more problems oh wait then this
happened so the dow hack the daus
attacks all of that ended up delaying a
lot of people's time and attention by
potentially up to six months but even
still work move forward he wasa moved
forward the work on the virtual machine
moved forward and work on the end of
alternatives things like EVM 1.5 moved
forward and people were still continuing
to kind of get a better and better idea
of look basically what a more optimal
blockchain Algar
from many different angles so after this
that we started making huge progress and
very quickly right so during all of this
time there were these different strands
of research that we're going on some of
them around proof of stake and trying to
do base layer consensus more efficiently
some of them were around scalability in
trying a shard base layer consensus some
of them were around improving the
efficiency of the virtual machine some
of them were around things like
abstraction that would allow people to
use whatever signature algorithms they
wanted for their accounts which could
provide post quantum security it would
make it easier to make privacy solutions
among a bunch of other benefits protocol
economic improvements and really all
these things were still happening all
the way through so at some point around
the beginning of 2017 we finally came up
with this con the sum protocol that we
gave this very kind of unambitious name
of a minimal swashing conditions and
minimal swashy conditions was basically
a kind of translation of pbft style
traditional Byzantine consensus so the
same sort of stuff that was agreed on by
a lamp or work wench stockmeyer and all
those fate and all those wonderful
people back in the 1980s but sim
flying it and kind of carrying it for
forward into more of a blockchain
context right so the idea basically
basically is that in a blockchain you
just keep on having these new blocks
appear over time and you can gain these
nice kind of pipelining efficiencies by
merging sequence numbers and viewers
every time a new round starts you would
add new data into the round you can also
have the second kind of round of
confirmation for one piece of data be
the first round of confirmation for the
next piece of data and you can really
kind of get experiment amount of
efficiency and out of all of that so the
first part was step was minimal swashing
additions which had six /e conditions
then it went down to four and finally
about half a year later we ended up
merging prepares that commits and this
gave us Casper the Friendly finality
gadget Casper FFG so last year at Def
Con I presented this new shorting design
that basically kept the main chain and
then creed did sharding as a kind of way
all kind of layer two system on top of
the existing main chain that would then
kind of get upgraded to being the layer
one once it gets solid enough from Vlad
the Casper CBC paper the Casper FFG
proof of concept so December 31st 2017
2340 bangkok time because we happen to
be in thailand at the time basically
what happens here is we pretty much
managed to nail down what the spec of a
version of hybrid proof of stake would
look like and this version of hybrid
proof of stake would basically use the
ideas from Casper FFG use these a kind
of traditional Byzantine fault tolerant
consensus inspired ideas of how to do
proof of stake on top of the existing
proof of work chain so this would be a
mechanism that would allow us to get to
hybrid proof of stake fairly quickly
with actually a fairly minimal level of
disruption to the existing blockchain
and then the theory is that we would be
able to upgrade to full proof of stake
over time and we got very far
in this direction and there was a test
that there were Python clients there
there were messages going between
different VPSs and different servers and
different computers and it got very far
and at the same time we were making a
lot of progress on sharding so we Hakeem
continued working on the shortening SPAC
eventually we had this retreat in Taipei
in March and around here a lot of the
ideas around how to implement he shorted
blockchain seemed seems to solidify
seemed to solidify so in June we made
this kind of very difficult but I think
in the long term really very beneficial
and valuable decision which is that we
said that hey over here we have a bunch
of teams that are trying to implement
hybrid proof of stake and they're trying
to do the do the Kasper FFG thing build
the Kasper effigy implementation as a
smart contract inside of the existing
blockchain make a few tweaks to the
fortress rule then over here we had a
completely separate group that was
trying to make a sharding system that
was trying to make a validate or manager
contract so that was later renamed into
a shorting manager contract on the main
chain and that was trying to build a
shorting system on top of that these
groups were kind of not talking to each
other too much
then on the shorting side it eventually
became clear that we would get much more
efficiency by making the kind of core of
the shorting system not be a contract on
the proof of work chain but instead be
its own proof of stake chain and because
that way we could make validation much
more efficient we did not have to deal
with EVM overhead we did not have to
deal with gas we would not have to deal
with unpredictable proof of work block
times we can make block times faster
along with a whole bunch of other
efficiencies and we realized hey we're
working on proof of stake here we're
working on proof of stake here why are
we doing two separate proof of stake
things again and so we decided to just
merge the two together this did end up
kind of nullifying a lot of work that
came
for but what it meant is that instead of
have it working on these two separate
implementations we were working together
on this one spec this one protocol that
would get us the benefits of Casper
proof of stake and sharding essentially
at the same time right so basically
instead of trying to go to go to I go to
one destination then go to another
destination then later on have the Miss
massive work of figuring out how to
merge the two we would just take a path
which would take a little longer at the
beginning but the place that it gets to
actually is a proof of stake and sharded
blockchain with the properties that we
were looking for so in the meantime we
spent a lot of time arguing about fork
choice rules B's we ended up kind of
getting closer and closer and deeper
into realizing that fortress rules based
on ghost the agree D heaviest observed
sub-tree algorithm that was originally
intended for proof of work but
repurposed by us for proof of stake made
a huge amount of sense
we were Justin started doing research on
verifiable delay functions we had this
workshop at Stanford and we made a lot
of progress on verifiable to wave
functions there and justin is still
collaborating with a lot of researchers
from there more ideas on how to do
abstraction how to do this idea where
individual users can choose their own
signature algorithms for their accounts
more ideas on rent which we decided to
rename to storage maintenance fees for
political reasons and research so
there's a lot of work on cross shore
transactions so for example there is
this a post I made on cross shard
contract yanking which kind of
generalizes the traditional distributed
systems concept of walking into
something that makes sense in this kind
of asynchronous to cross short context
also wrote this paper on resource
pricing which includes ideas about a
kind of optimized and my ends up much
more fish
Phee market along with storage how to do
storage maintenance fees and why and the
different trade-offs between different
ways of setting them and I mean Casey
here a de trio wrote this post on doing
synchronous squash across chart
transactions so and of course in the
meantime Kasper CBC research also
expanded into and if Kasper CBC is own
brand of sharding which is totally not
called vlaardingen opswat Lee hates that
term so development right so be there's
one of the kind of key strategies that
we tried to really push forward in the
etherium 2.0 path is the idea of
creative multi-client decentralized
development and this wasn't just a kind
of because we have an ideological belief
in decentralization this was also a kind
of very pragmatic strategy to not
basically had your bet first of all
hedge your bets against the possibility
that any one software development team
would not perform well second because we
already we have plenty of experience
from the shanghai das attacks of how you
know there are many of cases where if
one client has a bug having other
clients being available allows the
network to continue running better also
wanting to kind of make the development
ecosystem less dependent on the
foundation itself so the client that the
etherion foundation works on is I'm
actually the Python client and so it's
in it has plenty of use cases but in
Python just as a language has inherent
performance limitations and so there's
always going to be an incentive to try
running the stuff built by the wonderful
folks at prismatic and white house and
status and Pegasus and all the other
teams that are popping popping up
seemingly every month so soon something
which is totally not going to be called
Jasper serenity begins yay
[Applause]
right so what is serenity right so first
of all it's the fourth stage after
frontier and homestead and metropolis
and where metropolis is broken down into
Byzantium in Constantinople with
Constantinople coming very soon as well
and that's um a realization of all of
these different strands of research that
we have been spending all of our time on
for the last four years right so this
includes Caspar and not just hybrid
Caspar 100% organic genuine pure Caspar
sharding awasum and all of these other
prong of protocol research ideas this is
a new blockchain for in the sense of
being a data structure but it has this
kind of link to the existing proof of
work chain right so we be able to like
the proof of stake chain would be aware
of the block cassius of the proof of
work chain you would be able to move
ether from the proof of work chain into
the into the proof of stake chain so
it's a new system but it's a connected
system and the kind of long long-term
goal is that once this new system is
stable enough then basically all of the
applications on the existing blockchain
can be sort of folded into a contract on
one shard of the new system that would
kind of be an EVM interpreter written in
e wasum and not finalized but this seems
to kind of roughly be where the road map
is going at this point serenity is also
the world computer at its really as it's
really meant to be not a smartphone from
1999 that can process 15 transactions
per second and maybe potentially play
snake and it's totally centralized and
we hope that on in many metrics that can
be even more decentralized than today so
for example as a beacon chain validator
your storage requirements at this point
seem like they will be under one
gigabyte as compared to like something
like 8 gigabytes of state storage today
and the 1.8 terabytes that trolls on the
internet seems to thank the ethereum
blockchain require
for some stupid reason expected phases
so phase zero beacon chain proof of
stake and beacon chain proof of stake is
actually it's kind of the blockchain
stock kind of hold any information right
it's kind of like a dummy chain so all
that you have is you have validators and
these validators are executing and
they're running the proof of stake
algorithm so this is kind of like
halfway between a test at anim net it's
not quite a test net because you would
be able to actually stake real ether and
earn real rewards on it but it's also
not quite a main net because it doesn't
have applications and so if it breaks
people are hopefully not going to cry
too badly yes they were as they did when
the shanghai das attacks made everyone's
ICS go slowly
phase one shards as data chains so
basically the idea here is that this is
where they're kind of shorting part
turns on right so here it's just it's a
kind of simplified version that doesn't
do shorting of state it does shorting of
data so you can throw data on the chain
you could try to make just do a state
execution engine yourself but really the
simplest thing to use it for is data and
so if you wants to do decentralized
weather on a blockchain you'll now have
the scalability to do this but you won't
really have the kind of all of the state
execution capability to build you know
it's smart contract applications and all
of the really fancy complex stuff stays
to enable state transitions and this
includes enabling the virtual machine
enabling accounts contracts ether ether
moving between shards all of this cool
stuff and phase three and beyond
iterate improve add technology so
expected features pure proof of stake
faster times a synchronous confirmation
so about 8 to 16 seconds now notice that
because of how the fork choice rule and
the Outlands the signing mechanism works
in the beacon chain one confirmation in
the beacon chain involves messages from
hundreds of validators and so for all
probabilistic points of view it's
actually equivalence to hundreds of
confirmations of say the etherium
fortune right so you under a synchronous
model you should be able to treat one
block as being close to final economic
finality and safety under a synchrony
comes after ten to twenty minutes
and fast virtual machine execution via
awasum and hopefully a thousand times
higher scalability we will see post
serenity innovation improvements in
privacy in perso there has already been
a lot of work done so for example in
Byzantium we activated the pre compiles
for elliptic curve operations an
elliptic curve pairings and Barry White
has been doing great work on building
layer 2 solutions to preserve privacy of
coin transfers voting reputation systems
and all of this work could be carried
over cross our transactions semi private
chains so the idea here is that if he
wants to build some application where
the data is kept private between a few
users you could still dump all the data
on the public chain but you would just
dump it in an encrypted form or you can
dump hashes of it and you zero knowledge
proof select your choice proof of stake
improvements there's definitely a place
in our heart and the roadmaps heart for
Kasper CBC when it becomes it becomes
clear that it's that there is a kind of
a version that makes sense from an
overhead point of view post serenity
innovation so at some points we have all
what we wants you and we had you have a
door open to kind of upgrade everything
that starts so using Starks for
signature aggregation for verifying
erasure codes for data availability
checks maybe eventually for checking
correctness of state execution maybe
stronger forms of cross shore
transactions faster single confirmations
getting the confirmation time down from
8 seconds even lower medium-term goals
eventually stabilize at least the kind
of functionality of layer 1 think about
issuance think about fees agree more and
more over time on kind of what specific
guarantees people expect from the
protocol and things that people expect
as features for the protocols
for a long time think about governance
now what's next immediately so what
happens before kind of the big launch
well first of all stabilizing the
protocols back so for those who have
been watching github.com slash aetherium
slash eath - 2.0 or sorry if 2.0 -
backslash dream master specs beacon
chain md something like that this spec
has been kind of moving fairly quickly
fairly quickly but you know it will
stabilize fairly soon continue
development and testing there's
something like eight implementations of
the etherium 2.0 protocol happening now
cross clients test that so I believe a
free the madest made a statement idea he
hopes to see you cross client work like
really picking up in q1 next year I mean
we'll see that would be definitely nice
to see a kind of test networking between
to implementation in August move gonna
be nice to see a test networking between
one implementation like really like so
as I kind of quick hysteria aside
rightly iam aetherium 1.0 development
time between conception of the white
paper and launch nineteen months
part of the reason why it took so long
is because we tried to get kind of cross
clients compatibility way before the
spec even finished and so we had to
agree test release test net a weight
protocol changes agree test release it
says that await more protocol changes
and we had about five cycles of this
this time around we have the luxury of
kind of learning from that lesson and we
don't really need to kind of focus on
cross client compatibility until we have
something close to a release King a
release candidates of the spec but I
think we're actually not that far from a
release candidate of the spec at least
for kind of limited portions that don't
that don't include a state execution so
we'll see security audits who here
thinks security audits are important
who here thinks security audits are not
important who's here thinks the world is
a literally controlled by Lizardman okay
that's okay so more people from the
third of the second that's good to hear
and then what's words on that launch uh
who here thinks launching is not
important okay um who here fix like your
favorite political candidate is
literally a lizard man okay so launch
there we go I mean that's basically you
know the milestone that we've all been
waiting for that we've been working
toward for the last five four to five
years and a milestone which is really no
longer so far away so thank you what oh
sorry
okay enjoy
[Applause]
you