up next we have Paul and Guillaume who
are going to present on Watson engines
get away okay hello my name is Paul I'm
going to talk about webassembly engines
for awasum those are they one two three
four five six the first three or four we
have working at in some in some capacity
it seems that there's a big push to use
the Firefox in the chromium web assembly
engines they have they have various sort
of tiers of engines they have their
baseline engines which are just single
pass linear paths to compiled to machine
code then there are the optimized
versions but so I was asked to talk
about web assembly engines but I just
want to talk about what web assembly is
in general so there's 150 page
specification and it specifies a syntax
of the language sort of grammar so how
to construct programs and on top of this
definition of the syntax they define a
validity which says you're guaranteed to
return or pass some arguments and it's
guaranteed to do certain things and then
finally they define execution execution
is defined as rewrite rules what is that
okay so somewhere in some web assembly
program we have these two - app codes
kant's 0 and call 0 what does it mean
what does it do
imagine 0 ok so first of all web
assembly is given to you as a module
it's a web assembly module dot wasman
file it's a set of functions it's a
that's a memory it's some abstraction
that lets you do function pointers
that's called a table some things to
initialize these tables in these
memories things to import an export and
you have this module which is a set of
functions so it Maps well to an an
ethereal account which is also account
code which is also a set of functions
and you can call you have imports and
exports so different modules can call
between each other but somewhere in one
of the module
and one of the functions we see this
what is it what does it mean
so Const 32-bit Const and call zero call
zero means call a function the function
in this module which has index 0 so
imagine that's the function that has
index 0 that's what assembly code you
don't have to know what it means but
it's some chunk of whatever that you can
execute when you see this code somewhere
else in that module so this is how a web
assembly program executes we see this
these two app codes and then we execute
these app codes by rewriting wherever we
see this we replace it with that chunk
so what is this chunk we take everything
in this function loop to get local we
copy it we paste it here we've used
something called the frame this is just
what it says in the spec I'm just
mechanically doing what they tell what
they say in the spec to do it says well
then we have in these brackets we say
locals there's a parameter it takes that
constant zero we copy and paste it here
then we wrap all of this code in
something called the block that's just
what it says to do so that's what I'm
doing I'm just rewriting that I'm
deleting it and I'm replacing it with
that then what happens then we we
rewrite the thing that says block with
this I just read the specification I'm
just doing what it told me to do then
once I rewrite where it says loop and I
punch and I put in labels 0 and then I
copy and paste all of this this text
including the loop parts into here I
wrote it in small text so it could fit
what happens next
this get local so we're sort of going
going along we we saw a black we saw a
loop then we see a get local app code
what does that mean what does it do it
says to take that counts zero that's the
first local there could be more and copy
and paste it
delete where it says get local and paste
into it where it was I 32 can 0 then
what so we're sort of going along and
then we see these three app codes what
do we do with these three app codes
to rewrite rule again we replace these
three app codes with the sum the ad with
the sum of the two so we replace it with
a count one as you see it's just rewrite
rules the whole semantics the whole
execution semantics is we're just
rewriting chunks we're capping and
pasting text what's next we have a T
local which means we take whatever is
above it put it into the local cons and
then we also paste it here and we delete
where it says T local I'm just rewriting
stuff I'm not doing anything
controversial it's just what the spec
told me to do then I'm doing a less than
unsigned operation and replacing it with
the 1 because 1 is in fact less than 3
so anyway this just keeps going and
going and finally I get to this and this
is my last slide for the Oise imagines
talk so what's the point why did I just
waste your time with this sort of
rewrite rule stuff I went from this
somewhere in my code and I and I just
rewrote it a bunch of times all the way
down to this and that's how we executed
web assembly these rewrite rules so
what's the point that's how the spec
defines it it's just rewrite rules
nobody implements their engine like this
people implement their engines with
swift steps there could be one stack
there could be two stacks there could be
three stacks when I implemented the
engine I did it with three stacks for
for various reasons there's stacks for
these function call frames there's I
have a stack for the function call
frames I have a stack for the labels and
I have a stack for the for the operands
other people keep their frame their
function call frames and their and their
control flow labels in the same stack
there is advantages to doing it my way
because if you keep these in the same
stack you have to sort of every time you
return from a function you have you have
a linear time if you're nested in a
bunch of functions so that could be a
slow down the point is everyone
implements their engines however they
want to implement it and people do it
differently but they're the whole goal
is to make web apps they want to have
like you know alien fighting games and
in their browsers and things like that
and if
Crash's if it fails who cares but if
everyone's implementing things their own
way then maybe someone's going to have a
bug someone's going to introduce an
invariant that they're gonna ignore
later on and something's gonna go wrong
and if it's a web app who cares but if
it's adapt when there's a lot of money
on the line then we might have problems
so I think we have to focus and spend a
lot of time making sure we implement it
right to audit these engines these you
know we talk about Firefox and chromium
they want to have some micro
optimizations for their benchmarks that
they're interested in but but you know
we do we want these micro optimizations
so I'm just asking questions about do we
trust this stuff the spec says to
rewrite stuff no one's rewriting it
everyone's just doing it their own way
so what's the right way to do it I think
we have to audit and keep a close eye on
everything so that's the web assembly
engines talk so as lean so I'm giving
the next talk as well
it's called turbo awasum increasing
transaction through butter blossom is
our code word within our team of
increasing transaction throughput this
is joint work between Dielman ID and
other people on the team of course have
had good conversations with us and so
the big idea is what is what are we
doing now a theorem execution at serial
execution as you all know we're disk i/o
bound they say and we have max 20
transactions per second what does it
mean what a serial execution mean we're
executing transaction one then we're
executing transaction 2 then we're
executing transaction 3 and so on into
the last transaction
what does disk i/o bound mean this isn't
to scale by the way but if you took some
operating systems course you've seen
some image where you're doing some work
and then you're waiting for IO and
you're waiting and you're waiting and if
it's this guy o bound the disk these
these sort of i/o ranges dominates the
work ranges and so we're waiting and
waiting
and waiting for disk IO to come back and
it comes back and we do work and we do
work and it worked and now we're waiting
and waiting again and so we're doing 20
transactions per second and I don't know
when sort of engineers see this kind of
thing they're bothered why can't we fix
improve this because this is awkward and
we're engineers and we know how to do
these kinds of things so that's Geum and
I had some conversations about this
so aetherium shards we might have the
same thing shard one might also be
limited to 20 transactions
likewise with char - likewise with all
the shots so some use cases like these
plasma on ramps off ramps state channels
payment channels whatever might not be
usable if we only have 20 transactions
per second so sharding does scale help
us scale in some sense but is it
meaningful
we still can't use you know if a million
people want to get out of this payment
channel we still unusable so let's try
to talk about increasing throughput on
each individual shard and maybe cross
shards so when people say why can we use
sharding they start talking about
independent universes independent
galaxies things are independent what
does it mean what does independence mean
so I guess - transit so we'll define
what independence means - transactions
are independent if they do not touch the
same state location this is an
illustration transaction one in
transaction two transaction one touches
the upper-left the transaction two
touches the two bottoms and you can
consider these transactions independent
of each other so with inch so crushed in
different shards we're guaranteed if
they say that a transaction in shard 1
and a transaction in chart 2 are
independent of each other so we can
that's the whole idea they're
independent galaxies we can execute them
currently but how much transactions
within the same shard so the focus of
this talk is within shard transactions
into trash our transactions across our
transaction is the transaction for
example from shard one - char -
okay so what is someone that wants to
scale do an engineer usually will go to
perhaps Wikipedia and look up models of
concurrency and they'll read about
actors models and process calculus
models and maybe we can use these things
and people are using people are looking
at this I spoke with actors with
capabilities the gentleman that invented
the premia witch Definity is using Vanna
goreck is using these ideas process
calculi are chained rolling doing great
work fantastic work and they're talking
about paralyzing and increasing
transaction throughputs there are
they're also using these idea of
Independence with premia they're called
vats or with the actors and capabilities
in general they're called bats shardis
equivalents of that in some sense and
process calculi they call it namespaces
so everyone's using independence so you
know a good scientist or engineer says
what is this independence thing let's
define what this means and let's take it
as far as we can take it because you
know we're engineers we're working at
the margins let's see let's see what we
can do okay so we're going to define
what independent subset of a block is an
independent side a subset of a block of
transaction is such that each
transaction is a subset such that each
transaction in the subset is independent
of all transactions outside of that
subset that's a tough definition that's
a toughest definition of this talk for
example an independent subset is
transactions two and three they're
independent of all transactions outside
of the subset transaction two is
independent of one transaction three is
independent of one so these two are an
independent subsets just to clarify
that's because transaction one okay we
do not write to any location that the
set of teks two antiques transaction
transaction two and transition three
fright to correct yeah so we have some
sort of maybe you can have a visual
proof that you see that transaction one
writes to this and it's independent
based on this the definition of
Independence which was in a previous
slide which is a relationship between
two transactions and an independence
partition of a block is of transactions
as such is a it's partition into
independent subsets partition we know
this partitions
partition of a set is is a breaking it
into subsets such that their union is
the whole sudden there
pairwise intersections empty so the the
independence partition of this sort of
black would be one subset is this just
this transaction a subset with this
transaction and other subset is these
two transactions and we noticed that we
might be able to run these concurrently
because they're independent of each
other just like shards are independent
of each other okay so how do we how do
we build this independence partition for
three transactions we could just look in
point and say look these are independent
but if we have a whole block of things
it might be difficult so we have some
algorithms to partition the pool
transaction pool or block of
transactions into independent subsets
what is access lists first of all
there's a IP 648 there's a push with
each transaction you say I'm going to
touch these state locations and only
these state locations if I violate this
then then my transaction is invalid so
there's a push for access lists and
shards so there's there's two cases we
can either we can do it with access
lists or without access lists let's talk
first about with access lists so I'm
gonna do a visualization and it it is it
might be tough so we have our block we
order our transactions from one just
forget about anything below transaction
zero transaction one all the way to st.
transaction 60-63 we notice that
transact and then we write the same
transactions on this column we notice
that transaction 0 and transaction 0
interact which are dependent on each
other so we put a orange square there
and also 63 whatever this is based on
accesses we take these access lists we
compare see if they intersect with the
with you know 10 second 0 in 63 yes they
do 4 0 in 63 so we put a a orange square
there and we can partition this block of
transactions
into independent subsets so this subset
this this is upset you know this chunk
of transactions is independent of all
other transactions why because there's
no orange you know things colored in
here so this is maybe the kitty cat app
this is a decentralized exchange this is
some mixer this is some ICO these are
one-off transactions and we can execute
each of these sort of chunks
independently of each other because of
this independence property just like
shards are independent yeah I got it
okay likewise if you have many more
transactions you can break it into
independent subsets so this is just an
idea to paralyze a given block we're not
doing it yes so that's the big so you
see these independent there's many so we
can do it we can scale this okay without
excess list that's awkward we currently
don't have excess list and etherium so
we might execute a transaction see if it
sort of hinders our concurrency so if it
touches a bunch of these independent
subsets then we won't include it of
course there's a DA stack worst case
will go to serial execution but this is
one possibility to scale the main chain
and it's all based on independence the
simple idea that you know independent
universe's galaxies we're just taking
this as far as we possibly can like
we're maybe scientists or engineers so
then each independent subset we execute
on its own CQ perhaps we've already
known this since since e IQ 648 this is
nothing new but this but this sort of
act this this looks like the sharding
picture where shard zero shard one to
shard n but each one is sort of not
shard we're sort of dynamically creating
shards and we're solving two important
problems within a single shard and cross
shards we we can use these ideas so we
vom and I are sort of trained in
computer science science and we sort of
talk about operating systems and when
you take an operating systems course you
learn about threads and preemption and
we have this disk i/o bottleneck
so our idea is to use threads so each
thread corresponds with an independent
subset so we start executing thread 1
which is independent you know the top
left corner of independent or whatever
it starts executing it asks for disk i/o
there's a scheduler in operating systems
as you know it'll preempt this thread
while it's waiting for i/o and schedule
this thread so it's doing work this this
this thread starts waiting this
independent subset is waiting for for
i/o preempted this one is doing works or
essentially we're trying to use 100% CPU
so we're trying to eliminate this i/o
bottleneck whether it's disk i/o whether
it's network i/o whatever it may be and
we're just using a things from operating
so we can just use a regular operating
system with P threads or whatever this
stuff is available now or do it you know
with many CPUs so hopefully we can use
100% of hardware that's the dream of
like you know computer scientists use
100% of hardware I think so yawn play
clean up so as quick maybe a reminder so
the question thank you was about ball
neck so i/o was very well explained that
I always make in a theorem 1.0 it's disk
i/o it's apparently it's debated whether
it's the biggest bottleneck but it's
definitely up there in ECM 2.0 if you
start having stateless clients if you
need to get your state from the network
it's not so much this guy oh well altum
Utley will be this guy oh but it's not
so much this guy has network latency and
things like that but that means that you
will spend a lot of time waiting for
your data to arrive or to be written and
as a result this is this really makes
sense to try to get the the computer or
the the miner to do something while this
is happening so what we want to do with
this with this work like that was the
preliminary research work what we want
to do is to is to increase story to
extend the definition the definition of
independent independence between
transactions do
you want for example imagine you have
like let's say an IC or a crypto Kitty
kind of kind of profile where a lot of
transactions correspond to the to the
same into the same contract can you also
generalize the independence to two cause
within the same contract can you for
example use something like SIMD or you
know some MapReduce kind of kind of
programming paradigm so that you can
make sure that every single thread or
every single transaction touches a
different area of the state and run them
concurrently knowing that they won't
they wanted to hear so that yeah that's
that's what we're looking into we also
want to look into other other ideas for
example gas calculation so you heard
before about the metering or the
Sentinel contract something that will
scan your contract and add calls just to
use gas to make sure that gas get
properly accounted for what we would
like to do maybe is like to see if we
can explore what we would like to
explore possibilities to actually pre
meter the contract so reduce the need to
do this because first you have to scan
the contract but then every time you
have to make a call and that's kind of
inefficient so we want to see if we can
just have a simple gas rule see if we
can have an upper bound or a formula we
just look at at your binary we say okay
this is roughly what it's gonna cost and
charge that we one of the interesting
things that really where wisdom really
brings a benefit it's the replace
contracts contracts call with function
calls so right now when you call a
contract you have to reinstate a lot of
things like you basically I'm talking
about yes you create pretty much a new
VM a lot of data structures but
ultimately this is what you want to do
is is a function call you're not
actually calling a contract on a
different computer you're coming
something on the same computer so why
not make it a function call so you would
have something like imp
you know like pseudocode or sudo python
import that function from a contract
address and just get everything loaded
and you can start doing lots of things
that get inspired by operating systems
like you know manage modules like you
like operating systems manage libraries
if you see that a module gets loaded
very often you just leave it in memory
so that when you load it you it's
already there you can do something
require modules to have the full list of
contracts to basically like you had
access lists for state locations you
could also enforce the same thing for
modules we also get inspired by two
turbojet unfortunately the two bogus
presentation was at the concurrent time
in in a different room
but yes so they try to replace all the
state try or at least try to optimize
the way it stored the weight success
maybe that's still a suggestion from the
name escapes me Alex there at least say
thank you mark a very smart guy how to
maybe have all those contrasts all those
states in a like linear contiguous space
why not with protection of course yes
and we also want to use some of the
features of wisdom that are on the
roadmap they are not they haven't been
released yet or at least not officially
agreed on yet but you have mutexes you
have SIMD so for those who don't know
SIMD is a single instruction multiple
data so the processor has one
instruction that does the same thing
several times it uses the parallelism
that is inside the processor and yeah
that's what we're and we're looking into
[Music]
[Applause]
Thank You Kim and Paul there was really
intense big applause again for them one
addition to all of this is we are
considering all these different
improvements and we're lucky if you're
in a really lucky position that we can
consider adding these improvements today
wasn't test net or spinning up a new it
wasn't tested and add these improvements
to it but hopefully if we managed to at
any of these they're going to be a
really good test bed to have them fully
specified and finally implemented in the
main net now next one on stage is Casey
d3o Casey has been around forever he's
really into research and he's more into
keeping it to him alive and in to
improve etherium and his talk will be
about a new idea how you could do
scaling on a much bigger scale and we
may also consider having this on only
wasn't at some point big applause for
Casey thank you it's not exactly new
idea it's just a dream 2.0 the Jasper
serenity research which I heard in the
news recently that the etherium 2.0
research is stabilizing finally
stabilizing which is good to hear
because maybe now we can answer one of
the most basic questions just how do how
are we going to deal with a large and
growing account state this is one of the
main problems in scaling even if we
wanted to scale 1.0 we would have to
deal with the account state
[Music]
sorry and actually doesn't have really
anything to do with you awesome because
he was them is just an execution engine
and the execution reads and writes to
the state so if you want to implement an
execution engine then you've got to
decide how you're gonna handle the state
so I guess it kind of falls on us to
decide that so we wanted to say a little
bit about it this talk it's not going to
be highly technical this is supposed to
be an overview for you know of like the
developer experience and the user
experience and the challenges and
changes that will have to be made in
order to scale aetherium so just the
goal is having a a lot of users lot of
transactions and transactions and where
the gas price remains cheap if the gas
price is if the gas supply is limited
and you have a lot of users then the gas
price goes sky-high so how do we keep
the gas gas prices cheap again well if
you don't want to sacrifice
decentralization you could just run all
the validator notes on all transactions
on 21 validator nodes on supercomputers
but if you don't want to trade off do
you centralization then ideally you'd be
able to run a validator note on you know
any consumer laptop that way you can
just keep adding more laptops and
network and scale so to solve this
dilemma
our hero sharding chess perma card face
[Music]
what's the plan phase one we collect a
lot of data blobs
we have a pretty comprehensive spec for
doing this you know it's like eight
different teams building it out it's the
beacon chain they say you know some of
these prototypes should be functional
soonish
and then then there's phase - well phase
two we think we're gonna use yozma but
we still I mean we're not really sure
how we're gonna do phase two we still
have to iron out some details but there
is good news because phase one is
actually the hard part so phase one is
the consensus protocol the consensus
protocol comes to consensus on the order
of the data blobs coming to the
consensus protocol is actually you know
very complicated because the outcome is
non-deterministic every validator has a
different view of the network you know
data blobs arrive in you know different
orders and different validators you have
all kinds of hairy game theory issues
with you know malicious actors and
network partitions and it's yeah it's
it's it's a challenge phase two
relatively speaking is much more
straightforward you all you have is it's
a deterministic system the order of the
data blob is already known you have one
block you process it you get you know
the next block comes you process it and
so forth
so with if phase one is behind us and
you only have to worry about the
execution engine and Phase two next then
you're actually you know not that far
from the finish line
we learned yesterday that Jasper is
actually kind of lame it can be a bit of
a buzzkill my two main complaints about
Jasper are that for one it won't shard
it won't it won't scale contracts that
exist on the main chain
you know Jasper is going to be excuse me
serenity will be a new you know parallel
universe of 1,000 empty shards and users
will have to migrate to them you know I
don't know
redeploy contracts transfer state
somehow but when it launches it'll be a
ghost town get it Casper ghost own
secondly shards are gonna have the gas
prices will be independent on each
different shards so you know in theory
this is not really a problem because if
you end up on a really popular shard and
the gas price is expensive then you can
just you know move to a cheaper shard
where there's not as much activity I
think you know this is I mean yes in
theory it's kind of like telling people
you know who live in San Francisco and
are complaining that the city is not
scaling the supply of housing that well
it's no problem you should because you
can just move to North Dakota one point
no problem of this kind problem in
general 1.0 2.0 is that there's a too
much state users pay a one-time Gatsby
they create an account in the state tree
and that account is there forever and
all the full amount all the miners just
have to keep all this these you know
junk around indefinitely so what
techniques do we have what approaches we
have to reduce the state we have two of
them
stateless clients and storage ran with
stateless clients there's a single
32-byte
storage root and when you send a
transaction to the network so miners
Valladares have only the 32 byte storage
route and when you as a user send a
transaction to the network you have to
supply the merkel proof of your account
so you can prove that your account has
such-and-such a balance and you can send
either these merkel proofs have to be
up-to-date so i'm have a visualization
of that next but in contrast storage
rent validators basically users pay
validators to do this job to keep the
account in their state and to keep the
merkel proofs up-to-date and when you
have storage rent within an eviction or
sleep and awake like a if accounts don't
pay rent then they get evicted from the
tree but then there's ways that they can
be a can revive their account and come
come back into the tree then I mean
basically those techniques are very
similar to how stateless clients work so
it's kind of like with storage rent
there's two classes of users there's
like first class people who can afford
the rent who the validators handles all
of their merkel proofs and the second
class which is all the poor people who
have been evicted and will have to
supply their merkel proofs in order to
reawaken their accounts with stateless
clients there's just one class it's
everybody you know in coach
everybody has to supply their merkel
proofs yeah it's not a new idea either
just you know this is from the etherium
analysis report from lisa authority back
in 2015 and it was even you know
discussed in bitcoin before then
so yeah the problem with keeping your
Merkel proofs up-to-date is that at the
top is the stake road and then so at the
top of the tree at the bottom are the
leaves these are where the accounts are
so your account is one leaf and then
next next to you is a another account
and that's somebody else's account but
the branch the the proof data that you
want to supply is this Merkel branch
from you know your leaf account up to
the state route and in that branch are
these intermediate tree nodes now these
intermediate tree nodes change when the
guy next to you makes a transaction so
it's not so if you go offline and then
you come back it doesn't matter that you
didn't make any transactions it matters
that you know other people are making
transactions and now your proof is out
of date so you have to go back in
history and kind of reprocess these
transactions to get your proofs up to
date yeah so people really don't like
either statelessness or storage rent the
reason they don't like statelessness is
because again the problem of keeping
your merkel proofs up-to-date also
somebody who flirts and smokes weed a
lot such that when I wake up from
Crowley if I just want my brain wallet
to work I don't want to have to you know
you imagine if 50 years later your proof
would have just been changed like you
know within the first year after you
went to sleep so if those blocks are
still available somewhere then you're
okay but the question is you know what
happens if those blocks are no longer
available then well you're screwed and
that's kind of why people also you know
you
say setup there could be some service
that says I promise I will store you
know all the old blocks even if you come
back 50 years trust me they'll be here
and people say well I don't want to
trust these rickety you know layer 2
services I want you know about to have
some guarantee that validators will be
storing my my account obviously people
dislike rent because you get evicted if
you don't pay also capacity is limited
so the you know fees can spike high it
breaks user experience that we've you
know come to expect that a contract will
still be there there are workarounds for
this like if you know again this sleep
in awake but that's just you know adds
its complexity which maybe you can tuck
under the hood from the implementers
point of view if you're starting from
scratch then in my opinion stateless is
obviously the way to go it's clean
simple it's ideal about validator only
has to store a 32 byte State Road rent
is messy and complex there are lots of
parameters you have to decide well you
know I mean do you set it at 16 gigs or
32 gigs and then you know how do you do
the fee market so forth
I think some people even the stateless
is almost too simple so they just like
you know engineers who sometimes like
complexity and they just can't resist
from adding a rent feature onto the
stateless I mean if you're not starting
from scratch so if you have like if
you're in 1.0 today then it's probably
easier you already have a whole tree
that the miner is forced to to store
it's probably easier to you know add on
a rent feature and you know start
trimming the accounts then you know
swapping out the whole thing and
switching to stateless
so lastly point is that change is coming
here
currently minors have this full burden
and while it's you know it seems kind of
easy because you know somebody else's I
don't know if you're using in inferior
or made a mask or a light client it you
know it's relatively easy to sink if
you're running a full note it's still
difficult to sink what is going to
happen
is that it's not sustainable for miners
to keep storing all the state so
validators are the gist space is going
to be minimized the core of the network
you'll be able to sink very quick so
lifer a validator will become great you
know the process of sinking and
processing blocks will become very
streamlined but on the other hand if you
are a user or a wallet client life is
going to get somewhat painful sinking is
going to be harder scraping you know if
the data to you'll have to manage your
own data you have to come up with your
own proofs unless you you know can pay
the rent so that's it I mean you know
while it developers are gonna have a
tough time okay thanks
Thank You KC big applause for KC again
[Applause]
so thank you all for being here today
we're gonna pull up the the URLs again
please join the Gator room try the test
net the URL for that it's II wasn't that
material the doric all the demo what
Jarrett has shown should be visible
they're joined Gator again get the
discussion started we're gonna have the
CVM panel now focus on EVM we probably
gonna be free after that if you guys
have any more questions that's all the
details you need to know thank you
you