[Music]
so I'm Greg Colvin I work mainly on the
c++ evm louder I work mainly on the c++
d BM this is my friend Martin if you
want to introduce yourself
hi I'm Martin busy i'm working on
prototyping he was on and i also work on
the new MJS and
new hi I'm pavo and I'm working on small
sub project called a vm it's a kind
of just-in-time compiler does
translates a vm byte code into machine
code using llvm project
hey I'm Christina like listener I'm the
team leader of the c++ implementation
that I'm also
working on solidity which is basically
the main user of the etherium virtual
machine
hello my name is Alex Greig sassy and I
work with Martin on he wasn't as well as
with Christian on solidity and I'm
really interested to improve both even
one and the replacement of it called he
wasn't
so what I wanted to do this morning is
everybody got working so fast
approaching the conference getting
things done to talk about that I could
no longer keep track of anything but my
own work so I would sort of like to just
hear from people what they've been doing
the last few months and what direction
what direction they intend have to be
heading in um shall we start with Martin
here so the last couple months I've been
working on something called EVM tourism
which takes EVM code in trance compiles
it to web assembly and we are now
passing all the virtual machine tests
and the official test repository we also
have online demo if you want to check it
out know
what is a transpiler oh ok it's good
quick so we have two types of bytecode
start out with atheneum virtual machine
by code and we want to transform it to
you a new type of bytecode web assembly
so the chance compiler you can think in
math terms as a function that map's this
one input BBM to a new output what
assembly and
why web assembly
the interesting problem ok so web
assembly is a
new binary format that's targeted that's
designed and me targeted for the web the
web browser
and the interesting properties that has
no ever interested in it is
it's very fast and efficient it's
portable it's sighs
sighs efficiency so it's easy to press
easy to load and
it also has most importantly built in
it's designed to run the website
designed to run in untrusted
environments and that mask so closely to
what we're doing so yeah
good x
okay I can be next
so
the evm jet had
Assyrian the virtual machine
implementation I'm carrying off it's
fully compliant with the vm from from
the land of the cereal
but the problem I was trying to solve
from about couple of miles is how to
bring this
implementation to other clients so what
I was working on is a
new CC c language interface for
film virtual machine in general what we
call EV MC and
it's like
quite quite simple
interface then you can pack your vm
implementation with and bring it to two
other other other projects that might be
interested in so
just before the conference i was able to
plug a vm g to Python client it's still
syncing the blockchain but I hope it can
finish during this conference and
yeah so it's I'm not focusing on
optimizing the the execution time but
mostly to bring in my project to other
products
so so we now have a plug-and-play
interface for both the c++
execution engine
and the Python execution engine yeah
that's right so so the disciplines blast
client and Python client I able to use
the same interface for a vm g to be
operational on the on the blockchain
so it's still experimental but
very promising that's really cool
so that's that basically the idea is to
have a common interface between the the
client and the virtual machine and in
the end be able to swap different
virtual machines and we're also planning
to
to refactor the C++ interpreter to use
exactly the same interface so you could
seamlessly swap between
just-in-time compiler and the
interpreter and you can use the
interpreter with all client
implementations that support that
interface
very nice very nice
like this
[Applause]
rock and roll
that will be at the party later I have
to go buy a guitar if anybody knows a
good place
what else here
Alec enemy all right
yeah you will you will learn about you
awesome later on it will be the first
presentation today after lunch and I
invite everyone to listen to it because
if you'll be very interesting but i can
tell you up front a few details which
connects to this panel
that mostly we have been working on and
two different things first of all as
Martinez mentioned and was him is a
different bytecode so we need multiple
languages to compile code to this
bytecode because you don't want to write
byte code by hand and secondly you want
to run this bite good on something and
on the language side we have been
working on getting C and solidity ready
and we have written a lot of contracts
in these languages all ready for wasn't
and on the vm side actually be really
grateful to have all and his work on EV
MC because we have implemented vm on EV
MC and that means he wasn't can be used
with syllabus athyrium without any major
changes Thank You papa
why would you want to write contracts
and see
you don't really want to write contracts
as an end user in C but there are
certain contracts which probably makes
sense to be written in C and I don't you
want to go into a lot of detail you will
see a bit more in the presentation and
but just think about the precompiler you
already have and the for pecan pies like
sha-256 ripe em 360 and easy recovery
you want this to be written in a highly
efficient way and those should be
included by all the VMS and you don't
really want to f them as a pre-compiled
anymore in the future so those are
written in C right now and they are
limited set off of code which you can
much easily verify I wouldn't advise
anyone to write like a really complex
contract and see unless they know what
they're doing
solidity is hard enough it turns out
yeah I mean the thing is also that that
a lot of code already exists in see
especially cryptographic libraries they
already in see they have been tested
they are working and if we can just take
them without modification that's great
the advance of crypto code is written in
C and well long since well tested
that's the Assumption
fits the assumption that they well
tested
[Laughter]
it's not always a good assumption
when when people complain about solidity
being too hard though I I point out that
most of the world's most reliable
software has been engineered in see
most of your paychecks probably are
come out of an oracle system which was
written in C
so that it in the end it comes down to
engineering discipline more than
anything
so I really think the
GVMC
interfaces is really a powerful idea
that's going to help us quite a lot in
pulling together the different work they
are
providing the diversity we've talked
about
without
ball speak up Fred without vulcanizing
the work we can have a diverse number of
implementations of etherium without them
being in separate silos that can't run
together they can't talk to each other
so I think you can even do more about
that like having multiple
implementations of vm itself you can
build a quite
complex structure of that I mean you can
decide up front which implementation you
want to use for this particular code or
just select the randomly to avoid any
any crashes
how's that
you can implement like some kind of vm
that actually composites other vm and
behind it
so is it going to be part of the vmc
interface or the higher level that you
do things like start out with an
interpreter no you can use the same
interface for higher level like you can
write a
vm that compose other VMS but still X
exports the same interface vmc no I mean
by typically you start out running an
interpreter you notice the hot spots you
had pad you hand those up to a jit for
faster execution
you may do the compilation on a separate
thread because it could take a while
yeah it's that part of the interface or
will that be a lot it's all possible
with with this vmc interface
okay
so basically the interface only defines
the entry points and the way the VMS can
ask for data from the block chain and
that's very generic and it only gives
you the bare minimum you need and
because of that you can compose and
multiple levels if you wanted so the
composition would be at another level if
we wanted to we could abstract that but
we haven't yet now it works on the same
I works on the same level as basically
you just get in the the contract to
execute and then you can initially run
it as an interpreter if you wanted and
you can change it over right all right
so what's the what's the timing on this
I'm always asking that's always fuzzy
and changing yeah so for web assembly
pacifically it depends on the wc3
working group but as it stands now it's
implemented in all the major browsers
and it's on the
twelfth refreshing
prototype so I think it's getting pretty
close I would expect it in 2017
to finalize the spec after that then we
can move on to finalizing our eat
as we stand with a prototype we we have
most the major components implemented
next big thing we're going to be pushing
out as a test Network once again brought
to to us by facilitated by a PMC since
we can just drop the wazoo the woz some
chitter interpreter into all the other
clients yeah so that's pretty cool it's
great fun
if we used up our 20 minutes yet
you have six minutes left six whole
minutes and I have a question um I
cannot see anything but the most
blinding white lights I've ever seen in
my life
did you want to let you know about
security Christian so the the original
EVM was designed from the ground up to
have fixed bounds on resource
consumption and these bounds should
coincide with the gas usage what do we
know about existing he wasn't
implementations in that regard okay Oh
so regarding security in the virtual
machine I think like the number one
biggest security issue though is the
trusted computing base and that's
continually expanding with every
precompiled that we add so the point of
web assembly from a security perspective
and it is when Katie's perspective is to
minimize the overall trusted computing
base
now security from the metering
perspective is done by VM tourism or
sorry it's done by metering injection so
we can do static analysis on the code to
find it's very well delineated in web
assembly flow control so it's easy to do
static analysis on the flow control and
inject metering statements at the
beginning of each branch possible branch
condition that will meet her in the same
applies to memory usage so it provides a
so the the
gas model and the memory model as far as
metering is going to work the same way
with at a benefit that it's decoupled
from the evm
by default so it's not we have a nice
separation of concerns
and I think that also provides extra
security because we can think about
these two components separately now we
can think about okay here is our
metering injection algorithm right we
can examine that and then we have a
separate team or separate module all
together examining and looking at our
trusted computing base which would be
the awesome TN so two bolts there
minimizing the trusted computing base
that I think is the biggest
lowest hanging fruit most bang for the
buck right as far as increasing security
in our network
but do we know whether the I mean so for
example memory will probably be paid
with regard to the the memory of the
virtual memory of the virtual machine
and not with regards to the memory of
the actual physical implementation I
mean it's easy for memory because it
probably won't scale quadratically but
there could be some other edge cases
that
yeah could hurt us at some point so yeah
the memory is very explicitly allocated
with web assembly you use expand memory
and there's initial memory allocations
that the program declares up front in
the binary format okay we're starting
with this amount of memory here's what
we're going to have in memory so
it's actually kind of like a elf format
if you're familiar about how you know l
format initializes programs and then
whenever you need more memory there's
not good expand memory so it's very
clear where all the memory expansions
can happen and yeah that's what we
injector me drink
just like finesse break up code okay
like the S break in all UNIX I'm not
familiar with that yeah II have to tell
me about that it is similar to it ok
guess BRK yeah just a quick note on on
the metering part and so it's entirely
decoupled from the execution time and we
have the input byte code which doesn't
have metering because we don't trust the
input compilers so anyone who compiles
it wasn't we don't really want to trust
them to include metering in a correct
way and so when it gets to the execution
time we will inject these metering
statements into the right places in the
bytecode and during runtime there's no
need to do anything special all those
metering statements are just calls to a
specific function and so this kinda
works like how and it jet works and
like de la vm jet we have four EVM but
we do this upfront before execution so
it should be much faster and another
interesting point great so you were
thinking about like doing the metering
in another thread correct great yeah I
don't think that's going to work so will
it work but I don't think it's going to
be any faster now ok
and that is
it would save time on the very most
expensive instructions which cost enough
that it's not worth saving time and on
long runs of just doing addition and
multiplication and arithmetic you're not
going to save enough to bother
especially if you're going to push all
of that to the end of the basic block
but like doing a call cost enough that's
saving a bit of time
doing the need ring on the call
I was just going to say like we sorta
can do that now it's a little bit
hackneyed but we sort of get get the
separation concerns to free because like
whenever we call out to the interface to
do the metering that's going to be
possibly running on a separate thread so
but I don't know how much that's
improving our performance either so
ouchy for your stretch
right now we're using the eight to
prototype so we get 8 threads by default
and they're allocated when it starts up
so they're fairly cheap very cheap
actually thanks guy
thank you very much thank you all thank
you very much thank you
[Applause]
[Music]