[Music]
say everybody I'm chasing out for a half
and I asked to moderate this panel
because I've been working on EBM and he
was him lately and I know there were
there are no other experts
besides these panelists so he saw
Martin's talk yesterday and well it was
on Crimea but it mentioned the precursor
to premier which is he was ohm and that
started in December 2015
by the summer of 2016 the first comment
was in April but by the summer there was
a pretty working prototype for the EVM
to ewaz 'm transpiler then so that was
the EVM 2.0 so after the 2.0 proposal
came the 1.5 proposal from Greg and
Pavel and you just saw hobbles talked
earlier about EVM C which is sort of the
the API to plug in and be able to swap
between awasum and an EVM 1.5 and then
came earlier this year was Julia
yesterday also saw Alex Alex's talk
about Julia which he and Christian
designed to upgrade solidity and be able
to make solidity target
the EBM 2.0 the next versions of the EBM
2.0 and 1.5 and then and since then also
pavel has made a lot of progress on the
the jet vm so it's sort of been
backwards where first EVM 2.0 was
proposed then more progress on EVM 1.5 I
hope this makes some sense so I I think
I'll ask our panelists what is what is
he was and what is bbm 1.5 what I
arrived I guess he was him had made some
progress substantial and a few things
struck me one is people were sort of
excited because gee whiz you could you
could run you know C++ contracts and he
was them and as a C++ expert I said why
on earth would you want to write
contracts and C++ haven't haven't people
lost enough money on the blockchain
already and the other thing that struck
me was why on earth would you want to
hand over to an outside committee the
definition of anything to do with the
core consensus protocol and I looked at
Eve you know the current EVM and said
there's an awful lot of white space for
more op codes and this thing's not
broken
it just it needs a little work so I set
out to say what what do we need to do to
this to bring it up to modern standards
and make good use of modern hardware
and so I got to work on that and I got a
lot of help from other people on the C++
team the documentation would not have
happened without Christian and so the
team put a fair amount of work into that
we've got a couple of the IPS Martin has
put a lot of work into the EU Azzam
proposal so they're sitting there and
we'll need to make some choices and we
might throw both of them away and say oK
we've learned a lot what should we
actually do we might choose one of them
we might stick with what we have and ask
and we advance our compiler technology
to compile what we have in to code yeah
that runs better and Pavel can speak
better to how possible that actually is
yeah I would be very happy to have any
of these but to add it more constrained
to the control flow would help a lot
there and I believe who can do much
better in grid-like EVMS if you have
that but you know just a step back so
last year when you came around and even
1.5 came around it was still in a point
of time where web assembly was not
finalized at all right and there was no
knowledge at least we didn't have any
knowledge when it's gonna be finalized
and since then this year the first
version came out so that problem went
away and you know like Beck a year ago
we had no idea when it's gonna be
finalized and how it's gonna look like
when it's finalized and so there was a
big concern and I think because of that
even 1.5 made a lot of sense to maybe
bridge the gap or have like a you know
back-up plan assuming that EVM 2.0 would
be finished in time but we cannot
release it because the web assembly
isn't finished and then if he could
finish even 1.5 quickly enough it could
be a good bridge between the two but
that problem went away today
you know the earlier this year so how do
you feel about the brokenness of
evm since did did anything change
I actually I think he wasn't gonna die
why do you think that because there's
been so many attempts to get a binary
format running in browsers and they've
all failed you're saying webassembly is
gonna die no one's gonna die whatever I
said that's a bold prediction but we can
step back and say what are the problems
with the current evm 1.0 I mean one
problem is that the gas limit in each
block is not enough to do everything
people would like to deploy contracts to
do is one example is the Blake to be
pre-compile there's a proposal for these
native pre compiles and pre-compiled
solve the problem of contracts that
people would like to deploy but they
might take you know a hundred million
gas when the current block limit is the
current block gas limit is 6 million gas
so how does EBM 1.5 or or webassembly
solve this problem well of assembly
allows you would allow you to can just
compile code directly to web assembly so
you most likely don't need native native
contracts because you would just write
them and whip assembly but it's partly
just that it's too slow you know I mean
pavel was working i remember on one of
the pre compiles that you were like
pushing all the compiler flags as far as
you could and trolling through multi
precision libraries to find one that was
mostly an hand-coded assembly you know
we just can't get enough speed out of
the VM
for these free compiles but then how is
1.5 in in 2.0 how are those coming
faster than then 1.0 i'm just like my
little grade school example you do a
multiply and you're doing one
instruction on a 64-bit pair of
registers as opposed to you know long
division or long multiplication on a you
know collection of registers I think
that the current if you have is quite
big difference in terms of speed
comparing to native code so we we cannot
actually effectively encode the
algorithm we want there for example some
hash functions and and that makes them
if if you like to implement them in pure
smart contracts that make quite
expensive and you have to pay for that
you have to pay a lot for that because
it's just the current EVM is not capable
of Express enough to have comparable
speed comparing to native code and I
believe that's what for example web
assembly gives like it's it's at least
comparable like if you implement the
same heart function in in C and web
assembly at least you have compare both
of them and not having like times time
ten to two 100 times slower performance
but actually if you if you take a step
back to like the first version of EVM
and look at why do we have or why did we
had an identity contract just for
achieve memory copying that maybe shows
that we didn't had everything thought
through properly and we started to
introduce these pecan pies especially
the one for copying memory that means
loading and storing memory was too
expensive yet we still wanted to do it
so we introduced the pecan pie
and another bigger issue which Craig
mentioned several times already is the
bit with everything is 2056 bit and
there was a proposal even before the 1.5
to have 64-bit arithmetic syn EVM and
you have folded that into the same D
proposal as I still there and but if if
we if we just look at these two problems
that it's quite wide for arithmetic and
we have we started to introduce all
these pecan pies just to get around that
that probably shows that we didn't
figure out the prices properly and which
webassembly espousal said it's resembles
the instructions much more closer to
traditional computers so there's a much
probably much easier way to figure out
what the real cost for those
instructions are and by figuring out the
real cost and we can probably avoid
having pecan pies it's worse than 10 to
100 but my graph was scaled by square
root and the slowest exponential
operation compared to the fastest native
code was ten thousand to one but that
was on EVM to blossom right axe it was
actually go versus C++ compiled straight
to assembly so another advantage of
another motivation for the USM proposal
was to be able to break contracts in
other languages that target web assembly
as a as a compilation target versus only
targeting EVM so we have the the EVM -
II was ohm transpiler as a prototype we
don't yet have the e wasum - EVM
transpiler so the reverse which would
make the evm 1.5 proposal equivalent to
almost the II wasn't proposal just then
you could still write languages write
the contracts in languages that target
webassembly transpile those two EBM 1.5
have asked before how we what would it
take to write the EVM the II was him to
EVM 1.5 transpiler and Gregg said it
would be easy Martin said good luck good
luck at all me with it's not impossible
I wouldn't and would never say it's
impossible you said it's gonna be
somewhere it was a fire escape in Berlin
I mean was I sober and also one of the
motivations for just skipping EVM 1.5
and just and because the original
proposal was just going straight to 2.0
the EVM 1.5 proposal came later and one
of those reasons was because well it
must be hard to write a JIT a compiled
VM and then and then you know Powell
wrote a prototype of a PBM JIT vm is
what was that easy problem so actually
the prototype of that it's still a
prototype it was it was it was done even
before the launch of a material it was
one of the performance benchmark project
that we want to have to actually assess
what can we do in the future in terms of
smart contract performance but yeah it's
it's it still struggles with some some
cases and
as I said we can do much better in this
case but and the required step is it's
at least discount referral restrictions
and subroutine support directly in the
in the EVM byte code that would allow
even more optimizations and on the other
hand like JIT compilers are hard I mean
the the network consensus depend on that
and like the risk is like we might might
get hard or it might be never finished
in terms of removing bugs and finding
educators because that's that's much
more complex construct comparing to
interpreter I mean another problem with
with just-in-time compilers is that I'm
not sure if there is a just-in-time
compiler that provides a fixed upper
bound in terms of resource consumption
and this is a very important guarantee
that we need in order to do to do the
the gas calculations properly right I
mean usually just-in-time compilers
generate code that is faster and takes
less resources but we don't have a
guarantee or do we well as I said we
can't do a JIT it's it's exploitable we
have to it has to be a compiler that
runs at deployment time not at run time
which means it can be a full compiler
depending on how long we want to take to
load a block then my understanding is
storage is the main constraint there
anyway but me I remember in my testing I
came up with one performance bottleneck
and you said it's not a priority I don't
think I can get to it and the next day
you had it fixed yeah this is a bit
different issues of immaterial weak
actually care about the worst worst
cases because this is what what the cost
must be for and and so this affects more
complex optimizations but also the big
big integer libraries that actually try
to squeeze the easy cases first but this
is not what what we point to like we
don't care if we can divide quickly for
small numbers because what weaker is to
have the worst case covered so yeah that
would be much more much more difficult
to control that within the drift because
it's like you have the big at least in
the in the in the in the in the EVM rate
that depends on LLVM you have a big
bucket library that does that for you
and it's really hard to tell what it's
actually doing but yeah I guess they are
different approaches to that and for
example it was and has some JIT
prototypes that are not depending on of
course one of my bigger concerns is not
technical theater of these either of
these programs technically does the job
I'm much more concerned about who
controls to specification and I really
believe the the etherium community
should completely control that
specification that the web browser space
is not the etherium space and i would
not want to get wet
with the with the wasm group moving in
the direction they need to move and us
shaking our heads and going no we don't
want to go in that direction yeah I
disagree with that because I think I a
much rather it's much more pluralistic
to go with a larger community a larger
body of people standardizing and coming
to consensus on a virtual machine
instead of just using a virtual machine
that can only be was created to only be
used in one Pacific use case and if you
look at the browser use case is very
similar to the blockchain use case we
need secure portable and size efficient
byte code right exact same concern we
have in the blockchain space I agree and
and furthermore like it's an open it's a
it's open to participation you can go to
the web assembly community meetings you
can voice your opinions you can submit
proposals on github it's very open and
in you know it's easy it's easy to get
involved that and within the blockchain
space I know of least three other
blockchain projects outside of aetherium
that are already prototyping and
actively have wasum running in in their
systems so we're seeing a lot of
momentum I think pick up around it in I
think that's sort of just going to be
the way it is because it's like once
there is the we start to have consensus
around VM everyone is gonna be the
obvious choice everyone's going to use
it and it's going to be a recursive
feedback loop right it's gonna be a
feedback loop where since there's more
people using it we're going to get
better tooling for it faster we're gonna
get better implementation
etc but it's not like hypothetically if
intra-syrian 2.0 it's not like that
vasin would introduce a new update and
that magically would work on a theory 'm
as you mentioned in your talk both 1.5
and 2.0 have a verification code which
has to run prior or deploying the
contract and that verification code
verifies the you know according to the
awasum specification which is the
current list of op codes in web
assembling and so if they introduce new
codes they wouldn't work without us
making this decision that we want to
support them so I don't really see that
as a risk that we would be exposed to
random new instructions being supported
by a Tyrian Baudette our review first
I'm more concerned so we come along and
there's an issue with wazzle I mean bugs
bugs show up in specs or if not a bug an
ambiguity and we resolve it one way and
it works for us
and we can't wait yeah we if something's
a little weird in a browser it's not a
big deal and the committee will get
around to it but if there's anything
that breaks consensus we have to fix it
immediately and then eventually it gets
around the committee and they go no we
don't like the way you fixed it we're
gonna do a different fix yeah and I just
feel like over time we will wind up
forking away from that standard and we
will lose these benefits of shared
design and tooling anyway in fact we're
a fork to begin with we're a subset so I
I mean I spent a couple weeks trying to
get C++ into Azzam I succeeded but it
wasn't easy and that I think that's
misleading it's a subset but the only
subset being with the we don't let
floating-point operators yeah that's the
only subset but you have to convince the
compiler
not to do that
yet it should be pretty easy I mean if
you don't use floating point inside the
compiler can decide that it's gonna use
the floating point unit just because it
feels like it fortunately we're out of
time so we'll have to kiss bye good
floating points versus what about Julia
sorry what about Julia I think Christian
you're gonna cover Julia a little bit in
the flexibility of solidity talk not too
much I mean Alex talked about it in
quite detail so well it's a very active
debate even went up five versi was um
hopefully we can do the magic of
translation come to a united front and
move forward with the evolution of the
with evolving the EBM thank you
[Applause]
what do we do with them
[Music]