[Music]
I'm Greg Colvin I spend my time for
aetherium working on the virtual machine
working on improving its performance and
working on designs for possible
successors to what we have in order to
solve some of the performance problems
that were running into if this works
there will be another slide how about
that the first problem you run into an
any sort of optimization work according
to my old friend Jerry Schwartz is one
all benchmarks are bogus you'll never
have a set of benchmarks it actually
represents the real world but if you
don't have benchmarks you will just go
in circles you'll you'll never make
progress
so the benchmarks I'm working with are a
few algorithm kernels that are relevant
to what we're doing
RC 5s and old and useless cipher but
it's a good example of a cipher that
uses a lot of 32 and 64-bit arithmetic a
lot of complex logic and Blake to be is
still an important hash function it's
also a lot of 64-bit logic blum blum
Schaub is a cryptographic rant random
number generator I think it's one of the
slowest in the world it operates on big
registers so we could use the 256 bit
registers of the VM effectively an DC
mall also can use big registers
effectively and then I have a few tests
of act individual EVM operations and
those are small EVM assembly programs to
try to isolate individual opera
ratios and this is a graph of what I got
with the whole thing and it's a bit
complex but what you can see down along
the bottom is the different benchmarks
and along the right are the first three
are some major clients EVM is our go
client parity is Russ client EVM is the
C++ client the rest aren't clients yet
but EVM to wasm is part of the Azzam
research it's a program that takes EVM
code translates it into Azzam code and
then I fed that to Google's v8 engine
which generates assembly code EVM JIT
Pavel was just talking about it
generates assembly code directly from
EVM code and then the native C++ is I
rewrote the benchmark programs in C++
instead of solidity or EVM assembly and
compile those to assembly so pretty
clearly the C++ wins the race and pretty
clearly exponentiation is pretty hard
for everybody which isn't surprising but
it's a little concerning there there
might actually be possible exploits by
writing contracts that do exponentiation
and get charged only a few gasps but
take a whole lot of time and rc5 looks
pretty hard because rc5 works on dynamic
shifting and EVM does not yet have a
shift operator and so it gets imitated
with exponentiation and in between
things are relatively regular
and the speed you could actually predict
by the language that the client is
written in oh where did that come from
the next slide I can't see the screen
these glasses on so to simplify it this
is looking at one angle
it's a harmonic being of the performance
of each client yeah and it shows pretty
much the same thing
so clearly the interpreters are not as
fast as as going straight to machine
code by any route yeah and clearly some
interpreters are better than others but
they've all been good enough so far for
our purposes and of course I love car
races as examples last year somebody in
the audience shouted out that instead of
used in classic cars burning tons of
gasoline I should be using Tesla and
Tesla's are nice it's George Hallam here
are you here George George would agree
that rather than a Tesla this would be
much cooler this is a 68 Mustang
hatchback under the hood is actually
some powerful electric motors and the
trunk is full of lithium-ion batteries
and if this works where's the button we
will see how this does against the Tesla
is ready sound just no such luck
but there goes the Mustang Tesla doesn't
have a chance
it did just missing but after a
quarter-mile it had gotten to 140 miles
an hour
that's a lot so what what keeps those
interpreters from reaching native speed
and the first answer is their
interpreters so they've got that
overhead you can work hard you can
reduce the overhead but generally you
can't do better than about three three
or four to one compared to native code
um for our particular interpreter the
256 bit registers slowed us down because
real hardware has you know 32 64 bit
registers and the unconstrained control
flow hurts us a lot and I'll get to that
the 256 Hertz if you remember you know
grade school math adding multiplying you
know two numbers is pretty easy you can
do it in your head if you have you know
four numbers suddenly it gets a lot
harder and it's quadratic so it gets
worse and worse 256 squared there's a
lot control flow the jump operator an
EVM I mean you know go twos are
considered harmful but at least you know
if you say go to label it will go to one
in exactly one label in the EVM you say
go to whatever's on the stack
so there's no way of knowing often
statically where it's going to go
so you could have a nice little program
like this and F calls G and H and
returns and it calls AI and returns etc
nice clean structure no trouble no
trouble to understand static analysis
anything no trouble what's it actually
looked like to the EVM that's what it
looks like to the EVM so if you're
trying to do formal analysis if you're
trying to write a compiler if you're
trying to do anything with it again the
number of paths goes up quadratically
and you're in trouble because pretty
much if you can't do it in linear time
or at least n log n time on the
blockchain you know that deployment time
or at runtime you can't do it so how do
we do better
well EVM JIT is already doing better I
won't back up but if you look at the
slide the EVM JIT is actually pretty
close to the native speed you know it
does very well on the wide arithmetic
and not so well uh narrow arithmetic and
complex logic but it's a very good chip
I've told Pavel he gets to be the
electric Fox he's tired of these little
you know three and four letter names
that don't mean anything this is a
racing team out of Latvia that's a
completely electric dragster and here it
is winning the European world record
there it goes
drag races are fast it's not impressive
is it it's over
hello 275 miles an hour just a few
seconds love these things so we've got
we've got two research programs who'd
have been going on how to improve things
they've been nicknamed EVM 1.5 and EVM
2.0 which doesn't really mean anything
except those are the nicknames yeah
and for 1.5 that's that's a suggestion
to extend the current EVM by adding
adding new op codes and requirements so
we forbid those unconstrained jumps you
just we will not allow you to do that
and we we then have to provide a way to
do the things that you otherwise do with
those jumps so there's up there's up
codes for subroutines and then we've got
to get away from having nothing but 256
bit registers so we've got up codes for
native scalars and op codes for sim D
because real hardware has all this
silicon devoted to sim d registers and
if you go to google and type sim D
crypto you get a lot of results so it
would be useful to make that hardware
available and at deployment time there's
a validation phase that goes through the
code and make sure that it actually does
follow the rules what a concept
and then 2.0
[Music]
well gee it provides opcodes first got
your control flow you know it's stricter
than 1.5 it actually looks like a
high-level language with if-else and
such and it provides opcodes for native
scalars it's Cindy provoke the Cindy's
coming later but there's a Cindy
proposal and it also has a validation
phase where it validates control flow
and stack discipline and type safety so
they're they're very similar at that at
that level so we've got some technically
very very similar proposals um they both
provide for for very fast compilations a
native code it could be done as the JIT
yeah we've come to realize etherium
cannot do jets there they are actually
exploitable that is if you find or write
a contract which takes a long time to
compile with the JIT but requires very
little gas to run and you start
hammering those contracts you can you
can do a really nice you know do s
attack so if you're going to do any
compiling you've got to do it up front
at deployment time and Marvin's notion
of transpilers I think is very important
here um
1.5 could be transpiled to 2.0 yeah 2.0
can be transpiled to 1.5 1.5 or 2.0 can
be transpiled to 1.0 either of them can
be transferred to the JVM
you can make up new ones pretty much you
know you can compile any VM you wanted
to some other VM and he also has a
notion of gas injection so you put
little pieces of code into the right
places to count the gas and what this
means to me is it doesn't matter what
execution engine a client chooses
because on the blockchain you can put a
contract that translates into that
execution engine so these are these can
be completely independent choices and we
could actually choose to support a
number of VMS if we wanted to and
independent parties could decide to
support a different VM but a transpiler
on the blockchain and away they go gee
I'm almost out of slides and there's no
sound that's really too bad so what what
is the big deal about native performance
and what's the big deal about being lean
and mean and close to the metal well we
saw the electric dragsters here's like a
real top fuel dragster they run on a
mixture of diesel fuel and nitro methane
and just about a month and a half ago
not too far from Ming's place in
Michigan this guy got the world record
and it's over 338 miles per hour and a
quarter mile these guys pull about 5 or
6 G's which is about the same as an
astronaut taking off in the space
shuttle but there's a problem with going
fully native in the save world we call
it undefined behavior hello
no that's the less come here okay
play play there it goes what's going on
my screen
we'll try it again dudu the driver
actually walked away unscratched I love
this guy we'll give you one more and it
turns out I'm done so I knew it
audiences love explosions
[Music]