up next we have a panel on EVM which is
the etherium virtual machine there's
obviously some overlap here with the e
azam topic including those of us on the
stage unfortunately we had a couple of
other none II wasn't panelists who were
not able to make it but we do have Greg
with us thrilled to have him join us for
this part and just to be clear this is
the topic is EVM as I said I mean we may
touch upon some some you want some stuff
but we'll be focusing more upon the
etherium virtual machine what it looks
like today the road forward challenges
that kind of stuff so cool
I'll moderate but why don't we kick off
with the introductions Greg do you want
to start
yeah I've I put a lot of work into the
what's now called Aleph is it ADM 1.0
and put a lot of work into specification
for making fairly quickly some
improvements to get better performance
better formal tractability for the VM
that could be get begot that we can get
into place much more quickly than the
full US and development those those got
sort of set aside for the last year I've
a month I don't know why but they did
okay what's that that's a really
interesting topic we'll come back to
that just does that come back yeah we'll
just do a quick intros and then start
with that or not we're just doing intro
yeah okay so that's what I did and I'm
working on plans to to get that going
again quickly and well integrated with
the EMC work and he was some work so we
can sort of front run on that and get
people get people going and thanks Greg
Hyman Paulo and I working for to you for
some time and I was mostly interested in
EVM a long time ago I even created
project to compile a VM code
to machine code some kind of jet
solution and that also inspired some
small but important changes in IBM's
back before it's even even launched and
now I'm trying to bring some cooperation
to to be emulated software by
introducing this Eve EMC product to
allow quickly swap VM implementations
and I am also cooperating with you
wasn't team I'm Casey I really got my
start as a core developer on a theory
MJS the JavaScript client well virtual
machine back in 2017 or Byzantium and I
also try to help with security and
testing fuzz testing finding consensus
bugs and then I try to help out with
contribute to research on you know
Durham 2.0 sharding my name is Alex
I started off 52 mgs as well working
mostly on the VM in JavaScript but at
the same time started to work on
solidity trying to fix bugs and then
actually adding features so that
resulted a lot of DVM works like both of
these and ended up contributing to a VM
C and ended up contributing to he wasn't
in the end but I'm still also very
interested in improving the EVM and so
actually with Pavel we submitted a
couple of the IPS and which are accepted
to constantly Poland Pavel osis
submitted his only IPs and I was really
excited of the IPC
greg was doing regarding given 1.5 but
they are much bigger IPS than what we
have submitted and so that's that's
basically about me interested in EVM as
well not just he wasn't cool I'm Lane
I'm also on he wasn't team that a member
of that team since the beginning of this
year
I think my interest in things like
instruction sets and he was a man EVM
comes from just a deep curiosity of
starting at the very bottom of a system
and kind of working my way up there's a
lot of amazing work being done at higher
layers layer 2 layer 3 etc but really
understanding this virtual machine this
aetherium machine that we're building
from from the bottom to start cool so
let me actually I'll come back to EVM
one-point-five stuff in just a sec I
promise I just want to kick off with an
introductory question which is maybe
Alex you could take this one
just what is EVM how did this thing come
into existence what is it supposed to be
or do I mean you want to pass in there
someone else wanted up to that I mean it
started from the beginning there's a
section of the yellow paper which
describes the VM and so it's it's an
essential part of even the concept of
etherium we have smart contracts and
that what that's what initially
distinguished etherium from others and
the VM is is what did it and not to be
too nasty but a part of my job is to be
a nasty old man and yeah Grouch Grouch
of people because I've been in the
industry a long time and DVM we have was
designed by cryptographers not by
virtual machine experts so it has
certain problems which I ran into when I
when I went into it when I got here and
said this thing needs to be a lot better
some of the problems affect performance
even worse some of the problems make it
very difficult to formally analyze the
code and that's something that's
important to me
I sneered at formal and formal analysis
my whole career because I didn't see
that taking ten thousand a hundred
thousand my program and then writing a
million line proof was going to help
anything now we're looking at programs
which are even smaller than what we used
to write for our
Apple two's smaller than the 64k
segments mmm estas that we use staff to
write in I remember squeezing a
relational database into a 64 K segment
it suddenly starts to make sense when
you've got you know an awful lot of
money hanging on 24 K of code to spend a
lot of money doing anything you can to
prove it right and the current VM makes
that very difficult Lassa makes it a lot
easier but when I arrived wasm was not
yet a thing there was it was agreed I
don't know exactly where it was in the
realm map but it it was not there was no
spec for it it was finished it was
minimal minimal Viable Product was not
even there so I set out to say well I
don't want to wait that long
and I'm getting back to doing that but
that's basically what the EVM is right
now and part of the troubles we're
running into it and what I joke here's
the t-shirt from Cancun they day the
dead it's a day after Halloween now
there was a accident with laundry bleach
so it's been to hell and back and I
never again want to be awakened on a
Caribbean beach during the vacations to
discover that you know yet another
million eath is falling down a rat hole
because there was a long line bug in
your program and so that's my goal right
now and sees me so I'm just trying to
get together some people and some money
to pursue that in parallel and trying to
get in coordination with the Lassen team
so we can get that done more quickly
onto the main chain
and we're going to be able to compile
that code to Assam code so there's not
going to be any real conflict or trouble
for customers as we as we event Eliza I
sort of see laughs and it's becoming the
assembly language of Ethier i think just
half a your interesting line i kind of
felt like that you're saying that was
him is ready now we don't need a DM but
then you iterate it on it and i think it
was very interesting what you said in
general i want to hear a bit more about
that at some point then you just add a
tiny bit more color to the introducing
EVM idea as you said Greg right EVM is
sort of the implementation of the yellow
paper right it's the state transition
machine in the yellow paper and it's a
really interesting unique really well
designed virtual machine and I'm gonna
hold on hold on wait till I share the
second half of my thought it's I'm
paraphrasing and paraphrasing Nick
Johnson here it's well designed however
it's a theoretical sort of virtual
machine right so you get these
interesting things like these 256 bit
words so even if you want to do very
simple integer math you know you're it's
very inefficient right because you have
all these kind of wasted bits and it
doesn't resemble anything like an actual
hardware instruction set whereas in
contrast to something like webassembly
web assemblies very close to actual
hardware is that sort of address your
concern Boris or do you still think it's
okay cool exactly okay
[Music]
okay so just to restate what what Boris
said for I guess recording and Internet
people's the EVM is a very well-designed
VM using technology that sort of comes
from the 1960s and that we could develop
a much better VM today using modern
technology it also has a very clever
feature yeah
called the dynamic jump which back in I
think actually 50s Fortran had it was
called a computed goto in which you can
do some sort of rithmetic that says
where you want to jump and then you jump
why is that a bad thing because when
you're doing formal analysis you get to
that point in the code and you want to
say well where's this jump go and the
answer is it can go anywhere in the
program and when I I you know I'd done
one round of optimization I think about
doubled the speed of the interpreter and
then I wanted to do the next round to
apply some techniques that I'd invented
in optimizing the interpreter in the
Oracle kernel and came around and went
uh-oh and I showed it to Christian and
he said well of course because of the
damage jump you don't know what level of
the stack you're at I'm going sheep and
stronger words than that and that's then
I started going okay how do I fix this
and discovered it's like there's no
basic subroutine you know just a sub
instruction and even in the 60s and even
in the 50s most computer architectures
had some sort of instruction for for
making subroutines and the idea was well
you can make those out of the dynamic
jumps and if you ever look at the code
this solidity generates
for calling a function it's just it's
pretty ugly
so my next sorry I gotta follow up
question Pablo you said earlier that you
suggested some small but important
changes to the EVM before you know
Genisys launched in 2015 was the dynamic
jump on your radar yeah that's what's
the problem so even before it was the
situation was much worse because now at
least you have specified what are
possible destinations for jump so you
have special jump this instruction so
these are valid places where you can
jump to before that there was no such
thing so you can drop anywhere including
data from push even so you can execute
code in push data and like so before it
was impossible to have any other
translation further translation of EVM
bytecode so that this like allows some
some way of compiling EVM byte code to
machine code because on this machine
code level you are not allowed to do I
mean this own way but that would be
horrible so yeah that's that was that
was the change and destination it kind
of like a joint quite late during the
process and also I didn't know much as I
know now and like didn't have courage to
to change into something like better
behaving although we had like JVM
example when there is like it's fixed
it's fixed how like what what the stack
height can be on when you enter the
function what yeah so kind of like yeah
this is this is missing definitely we're
getting deeply technical here I don't
know some people are probably excited
and some people are just
we have to have at least one nerd in the
room yeah we'll save tons of time for
questions
another problem is that you can you
can't optimize this the compiler can
look and go well yes you're using 256
bit registers but there's instructions
like add mod and mall mod so you can say
that really I'm operating but at 250 I'm
only using 64 of these bits the compiler
can generate 64-bit code but tough we're
still going to charge you gas as if you
were working with 256 bits
I think only in the last month I think I
figured out a way to fix that looking at
the work that's being done on the I le
virtual machine through procore and
other people of runtime verification
I've been working on the lab and that
time to talk to anyone and write up
right in the IP on that but basically to
charge the gas based on how wide you
actually know what you can tell is the
maximum with the register you need so
there's basically things that can be
fixed and we think Boris who just spoke
up there and I don't know if Brooke is
still around or not she's she's an
amazing formalist she's going to be
humble there before you go any further
I'm wanted to reflect on part mm-hmm
you said that maybe specified the actual
width of the data you want to apply the
computation on and there's just one
thanks to you two worth mentioning here
and currently the instruction set looks
like s there's a single instruction
which can have an immediate value and
that is the push instruction no other
instruction cap can have immediate
values every single other instruction is
just operating on the stack and there
were a couple of different proposals to
augment other instructions to have
immediate values or have like multi byte
codes op codes to encode you know
different behaviors and there was a big
resistance to do that and one of the
reasons people said that it's going to
make
the current verification tools have to
be changed and we cannot afford that so
there was a real big pushback and what
you suggest I think I would imagine it
to be implemented if say like the
additional addition up code would have
an immediate value specifying the bit
its operating on or you would have a
multiple byte codes and up code but we
have this perspective people don't want
to have changes there you can simply you
can simply call mod after you pulled
that data does you know you only need so
many bits and and you want to detect
patterns and in the VM that there's like
a multi four and then there's a
calculation then you charge this yeah if
if some data came in and then you might
you've just fouled away all those bits
and it means a compiler like solidity
will have to generate code to take
advantage of that and solidity is
actually today generating code like that
if you're using smaller data types
mm-hmm but since gas-discharge for even
the multi distraction it is more
expensive but so people don't use it
right so we have to change the gas model
so that that actually helps in the way
that was intended to help so we talked
about one thing that we kind of have
consensus that we could or should
and maybe will change which is removing
dynamic jumps I'm curious what other
things if you could change one thing
besides that any VM what would you
change maybe we could just love you guys
all have an answer I guess we have
overlapping answers the big one is to
remove dynamic gems have cold frames and
this will give a couple of different
benefits a lot of those craig explained
but another immediate benefit people
actually going to feel as you can
address more of the you can address like
different the arguments to the function
much more easily than right now and it
also makes compiler code generation
phase easier people have a lot of pain
with solidity giving this random awkward
error message stack too deep and it is
giving it in various different ways
where where is different locations
and it's just a lot of work to you to
work around that with the current EPA
model so I think this is the core which
which is blocking so many things and so
that would be my number one case you
have one no I'd rather just switch to
assembly for me would be all of this
let's say soft oils that you can get I
mean when you divide by zero if it's
zero it doesn't make sense when you
access data that doesn't isn't there you
get zero and like all of these sorry for
first it makes verification harder not
not easier although like some people
said like now it's defined what's going
to happen but it's mathematically it
doesn't make sense and it's also like
very dangerous and we have examples of
this being broken in in deployed
production ready smart contracts oh yeah
that that would be might change so I
would just terminate execution if
something like that happened mm-hmm Greg
up to you and feel free to use this
opportunity to introduce you yeah and
I'm with Casey and this part of why I
asked the question on scheduling um
because I know that I can much more
rapidly implement a IP 6 1 5 and we're
26 1 5 that's that's that's the proposal
to get rid of dynamic jump introduced
subroutines and a few other opcodes to
clean that up it would be a separate
there are separate things you could do
like what Powell mentioned those might
be work you don't want to do there's a
VIP six one six to put in Cindy it's not
clear if we want to do that or just wait
for Azzam but so for me work I'm working
with Boris and and Brook to just raise
the money and put the plan together to
do that just as personal reasons I
decided I didn't didn't want to do it
under contract with the foundation
directly down but wanted to have more
more control over the price
checked myself and this is this is EVM
1.5 what you're afraid yeah the
collection of these two yeah I guess
Boris is telling me getting out talking
to some fair number of other clients are
going if we can quickly get this stuff
we'd really like it Andy BMC means if we
wrap it up that way they can get it they
can plug it in they can use it mm when
wasm is available they can get it they
can plug it in they can use it and just
try and try and get past this problem
yeah much more quickly so there's kind
of two schools of thought right now
about the state execution engine and
ethereal one is we should focus all of
our resources on us um and sort of its
Casey alluded to before like that should
be the emphasis right now but there's
clearly another side another way of
looking at this which is that we should
not we should not we should not try to
deprecated EVM and we should except it's
gonna be with us for a while and we
should be investing more in it I'm just
wondering Greg maybe you want to make
the case for why that's worth doing even
in light of you blossom I haven't
counted but how many VM contracts are on
the blockchain now what rate is it
growing at is it quadratic or
exponential if it's exponential however
long it takes to Yeti wasm out how many
more EVM will be out there how many
existing tools exist for analyze EVM one
code how many new languages are being
created they'll basically there's
already an ecosystem growing up around
that you know so it doesn't help the
community to just say well don't bother
because at some point in the future
we're going to throw that away yeah
the Sinclair issue like both awasum and
GBM 1.5 I'm curious what are the
backwards compatibility concerns with
say removing dynamic jumps
I know I know II was um there there's
various proposals to add backwards
compatibility which might help alleviate
the Sinclair issue that I am Boris Boris
mentioned so I'm curious if you you guys
could maybe fill me in on that
and then we can well fulfill EBA 1.5 to
a simple idea to some progressing on the
deployment time so we don't allow
dynamic jumps anymore I mean we don't
allow to deploy let's say evn 1.0
contract at some point but they want our
dead they will be there all the time I
have an addition to this so we have
these two translation tools originally
named EVM two wasn't but now we have a
new version called ye VM which compiles
even bite kit was invited good now it is
not really optimal because of the very
same reason but would would even 1.5 we
implemented then we would have a much
more optimized compiler I think there's
like an overlap between these things I'm
not fully personally sold on the six one
six the IP which is the simple editor
but six one five I think it's a
low-hanging fruit and if you combine it
together with what Pablo said that okay
we disable the 1.0 deployments and it's
only just this one point five which is
the six one finds so many numbers anyway
it's just about the that could be moving
dynamic jumps jump so if we enable that
forcefully and disable deploying hold
contracts the solar compiler already
supports it I think there was an
implementation you made in allit it's
likely it's a low-hanging fruit which I
think could be I mean I would
optimistic to even have it after
Constantinople but just right people
have to be convinced but it definitely
this single step does help the
transition to tui was amiss well if you
want to keep backwards compatibility
between that's mean
yeah the code the code is in is in there
I think last time I looked you you've
moved it to the side that it's still
there
I think it's not there anymore over
didn't you have your legacy anyway it's
it's chip it's somewhere down in there
somewhere they can be pulled back out it
was implemented some testing needs to be
done yeah but it doesn't yeah I can work
alone for six months and and have
something then we'll need some more help
on some other stuff but it's just not
that hard to get that going in depending
on scheduling I think it can be done
more quickly than you ask them can be
can be delivered so it was related but
slightly higher level question why do
you guys think EVM has been so slow to
be evolved as a technical is it
political is it something else because
no resources were put into it I think
one of the issues that we have is we
look at a couple of things I see a split
split between researchers implementers
and people who are attempting to ship
bug-free production code on top of the
world computer all of which that are
happening at the same time and again
always a hard call to say when you
should ditch old and go to new and
everything else like that but if the
people who do research never have to do
production implementation it's the same
issue between DevOps and developers if
you never actually mean to have to
maintain separate production a research
engine needs to be built differently
rather than optimizing for people who
actually have to ship code in production
it feels like there was a large movement
for whatever reason to new new and we
should not be afraid to keep fixing old
stuff maybe there was another perception
that fixing a VM was hard but if you
just bring in people with vm expertise
it's not that hard my opinion we have a
late addition to the panel everyone
introduce yourself I'm every Eldon brand
I've been working on formalization of
VMs and stuff I gotta had some meetings
before this but one thing I've worked on
formalizing is the Waze and VM but not
as much recently
cuz I've been busy with things but don't
be shy you what's a big ke VM oh yeah
so one thing one topic can you speak
about I yell eat a tiny a little bit we
feel confident to do that one thing that
came up was this other virtual machine
would you mind taking 60 seconds to tell
us what that is and how it's similar or
different to the VM it wasn't so y la is
VM that we designed for weaving runtime
verification designed for the Cardinal
Network and it has a lot of similarities
to LLVM we've had some VM experts kind
of on our team who helped us design it
and we mostly tried to avoid building in
anything that would make verification
difficult to the VM so things like hem
store eight or other issues with the EVM
we kind of tried to avoid it's a
registered based machine so people have
different opinions on that I don't
really care either way and it supports
out-of-the-box unbounded integer
arithmetic so you can just use a proper
end type in the VM but then we have kind
of a more complicated gas model to
account for that just when I reread the
question because we were late the the
question was why didn t vm improve over
time
um and Boris explained a couple of
reasons I wanted to add a single reason
which also Greg mentioned that lack of
resources and a lot of resources were
shifted - he was him and there weren't
any resources left of IBM and then the
same time the the research team also
shifted their focus and they weren't
really interested in and getting
anything done an EVM so there was nobody
to propose except correct to propose
ideas and then there was nobody execute
those ideas it's really had to work
alone on improving the EVM so there's
been some conversations even here at Def
Con the past couple of days that maybe
while we wait for Jasper sorry of italic
eternity to like become a thing and be
alive but there there is value in
reinvesting in etherium 1.0 or 1.5 or 30
in the next generation or whatever you
want to call it is this could this be
part of that conversation
improving idiom and if so like what
would that look like maybe I can add one
one side to that I think we say a Tyrian
1.5 billion plan interim no regrets each
human ji all these different names refer
to the same thing that was there was not
really about the VM but other parts of
the network which may just make sense to
do them separately because they're not
that interconnected at least at this
level at this stage of where the
discussions are it wasn't the DVM
execution time which was the bound or
the reason we need to make those changes
so I think we can keep them separate and
therefore Greg kicked off with his idiom
one five proposal and if you keep them
separate you can also do them in
parallel and maybe get them in more
quickly but that's just my addition to
it maybe Casey you wanna secure I have a
comment actually about why it's
difficult to update the EVM and I think
it's actually just because it's well you
start with something that's EVM which is
kind of designed you know ad hoc ish
it's it's it wasn't like someone they
took some existing VM and then made it
blockchain capable they you know it was
just designed from the start
and then as the hard fork started piling
on logic behind various different parts
the VM got more complicated so the
recent constantinople hard fork the
rules for storage allocation just i mean
it like literally tripled it tripled in
length how many different cases we have
to handle and it's like different
depending on which pork you're on and
it's it's a major pain so i think part
of the problem with evolving the EBM is
kind of maintaining backwards
compatibility so having the ability to
support the new e vm execution model and
the old e vm execution model is just
going to complicate the clients to the
point where working on them to update
them for future hard Forks is getting
more difficult over time so i think that
could be a major barrier as well
basically the backwards compatibility
issue cannot be avoided at all you move
D you azzam that we still got all these
weird all this weird stuff it gets moved
up to your environment interface and
even with the current even with the old
VM I would love to take a whole lot of
those op codes it's really art they
really have nothing to do with the
virtual machine and I could easily as
you have with machine goes say okay
let's pull all of that out of the VM
deprecated it and move it up to the
environment interface you know again the
functionality is there we've got a we've
got a deal with it one note on on the
backwards compatibility and medium
itself and that promise actually was
broken I believe it spurious dragon or
tendering this or whatever the coding
was back like two years ago where cost
gaskets were increased and before that I
think it was never explicitly said that
gas cost cannot be increased but a lot
of contracts assume that and once you
increase the gas costs so one example
when a contract makes a call to another
contract previously they made like a
fixed calculation in the contract in
many cases and once you pumped up the
cost in in some cases they they just
failed I try them they were done so we
broke they're backwards compatibility
promise
and but all the proposal since then just
reduce the costs so like this s toward
change you mentioned that reduce the
cost but I think because we broke that
promise and a lot of the okay the two
languages don't they take that into
consideration I think it would be
possible to do like a cleanup of the gas
gas rules in in some cases may
definitely result in increased costs for
a given contract or a decreased cost but
it shouldn't break contracts entirely
but it is a say a political question at
that point if if a contract is increased
so much in cost that it kind of breaks
there the user experience and you know
it's an important country even if we
just ignore the complexity of the gas
model which is arguably where a lot of
the complexity in this happens there's
still complexly if we want to say
deprecated old off codes or something
like that and at that point what do you
tell the owners of contracts who you
know use those op codes if you want to
deprecate it and say you know we want to
remove this that we can start to evolve
it to something that's a little saner or
or a little more modular or is more
compatible with other VMs who knows but
it there's just there's not something
built into to the system that says you
know we're gonna at some point be able
to say no your contract is no longer
going to be able to execute on them that
wasn't what people signed up for when
they signed up for aetherium initially
there's there's this joke that goes
Intel we put the backwards and backwards
compatibility and we're stuck with that
any contract that works that got put on
the chain has to keep working forever
unless then look well it has to keep
working forever it has been as an
address they can be called ok can I just
mention a strange example to this ecole
code of code which which was quickly
fixed by introducing a new up code core
delegate for just right in two months
after launching deuterium because code
was supposed to do what delegate call is
doing but it was
and you have to still kept it and
nothing is using it because it's useless
yet we still have it how can we move it
the best we can do both both the best we
can do for any VM is when you deprecated
it is you keep you have to keep
supporting it null code but if they try
and put a new contract on the blockchain
that uses that uses a deprecated feature
they can't put it on the blockchain
anymore so yeah deprecating stuff is
definitely hard but about Everett's
comment that adding new features or new
app pose or changing the way existing
app codes work increases the complexity
of the code base because you the code
has to support the you know the old for
crawls and then you know next work rules
then the next one and you get all these
conditionals all that you can actually
get rid of that by just only supporting
the new fork rolls and resetting you
know essentially like resetting the
Genesis block at a more recent snapshot
I'm not sure why so many clients and you
know users are obsessed with being able
to process all the way from the Genesis
block and then through all the court
rules and then currently but what about
a contract that has some logic about how
their funds are supposed to be paid out
you reset your Genesis block you
essentially forget their code structure
or something like that and then what
happens to those funds sitting you know
you start at the snapshot of the current
of a state after the fork right then
that client sinks starting from that
snapshot and it only has to support the
new fork rules at that point you call in
to a contract that was created before
that on a previous Fork right it's logic
is broken on the new Fork potentially
well so maybe you've locked up someone's
funds or
yeah so I said you can't
did you really can't deprecated stuff or
it's really hard to you can only you
know change things again the the Intel
chip started out as a hand calculator
and that code still runs it doesn't run
very well that those op codes have
actually become pretty swell and there's
a good reason not to use them anymore
but that hand calculator is still in
there and to some extent you know we
says you're bitching about it and it's
just tough suck it out I want to
save some time for ID ask questions
let's speak maybe ten minutes left with
that let's go ahead and do that anyone
have a question or comment complaint or
it's always force so one of the things I
want us to think about is I'm starting
to think about the different components
of what is etherium just as we're maybe
thinking about what is web 3 and how
much we're integrating and eeap's and
other stuff like that with ipfs and so
on the EVM goes beyond
etherium public main net so today
Microsoft released released a new EBM
the EE BM written in C without gas
calculations that is designed for
private networks so how much from the
perspective of an EVM specification do
we broaden to support and work with
other chains like the way I see it we
might have a very large EVM community
that might want to work together and fix
some of the resources issue so just some
some thoughts that I'd love to hear the
panel's ideas on
I'd actually like like to ask you a
question because you there's nobody else
nobody wants to ask
yeah can you clarify a second very can
you clarify are you asking specifically
about are we going to support the other
E or I don't know I mean we can
certainly build formal models of those
other ones and then we can look at them
and see ok can we apply those changes
that they make to our EDM as well but ok
so so maybe this is not relevant and in
fact various things called EVM are gonna
live in their own worlds it just feels
like it might be a way to actually
broaden our community and get high
quality code together so she's an idea
so from my perspective that's one of the
main goals of you was it is that we're
stepping into a much broader community
so the other EVMS should all die no I
didn't say that but I'm saying if that's
our goal I think that he wasn't largely
serves that goal that's all I'm saying
mm-hmm in EVM over the years there have
been a couple of other chains using it
and most of those chains have made
additions to it inform self new up codes
to access data so one example I think is
good stuff they had like six sub codes
there were a couple of others that kind
of Cocoon right now but all of these may
be for the lack of the platform to
communicate these ideas they are Forks
they're not compatible and when they
made these changes they also had to
change the language is supporting EVM
which at a time with religious solidity
so they for solidity to support those
things and I don't really see any
communication between any of these other
forces their users of EVM at the moment
I think we have to overcome that issue
first get like a discussion flowing
between the different EVM forts between
like you know the maenette in front of a
IPS and as well as like the language
designers compiler others in the theorem
space and once that is solved you can
you can then
to learn how to you know make bigger
changes and get those changes down to
them but we we have those channels
closed for some reason so yeah so for me
it's it's yeah from my perspective it's
mostly communication easier and it's so
easy to fork and then never go back for
DFC project whatever direction the
communication should go so like everyone
is I think like own a IP repo with VIPs
like with different names even cover
network has what I find out like last
week there's like cover network
improvement proposals something and so
this information is not exchanged this
is I don't know how to fix it maybe you
have some ideas but yeah definitely to
having some some platform to communicate
that would be would be great I
personally hope like we can get a VM see
in spotting VM which is by its even
classic I haven't checked the details
what what changes they have they support
all of that what seems quite close to
our needs so that we interesting to to
try it on to your network any other
questions yeah I wanted to clarify that
Microsoft IBM implementation is for SGX
environments so basically the gas
calculation doesn't make sense they're
basically they want to you know enabled
it on the other and you can just you
know send code and get the get the
verified computation off train which is
pretty interesting but I guess the gas
calculation doesn't make sense there
it's negotiation you did the KVM work
I've had some conversations and work
with seed whoever he is
there's a man whose jitter tagged his
seed I don't know who he actually is but
we've had a lot of a lot of
communication he's working on a lamb
formalization forked off of a cheese
formalization and we've talked a bit
about where that the current the current
EVM gets in the way of that kind of
thing and how my proposals are intended
to help see this was quite excited and
contacted me it's like when did these go
in they would help so much but I'm
running as a formless what your opinion
is is how much would it help and how bad
is it right now
well nothing's crashing and burning so I
think it's not it's not too bad but it
it's it's quite a pain to update KB I'm
especially anything regarding the gas
calculations because there was I mean
you have to do things in a very specific
order and it's it's kind of annoying
that you have to do that I don't know
like for reference maybe I can say how
long it took to formalize EVM versus how
long it took to formalize the fragment
of wasum which is most of the execution
but just not the modules an EVM took I
want to say I mean depending on how you
count between you know 8 and 14 months
and and wasum was closer to the
six-month mark maybe so I think that
just that alone and the wasum definition
is just shorter and it's cleaner and it
just makes more sense and it it it just
feels more coherent it all kind of
presents itself nicely together instead
of feeling scatterbrained I don't know
Oh - van dynamic - oh that one
specifically how much does that proposal
oh my gosh that would help so much oh my
gosh
that that is a single like when we made
our own like EVM 1.5 I called it EDM
prime as a kind of just a toy like how
would I change the EVM type of thing and
that was the very first thing I did was
it was just okay all jumps are actually
labeled and you only can jump to the
jump labels or something like that and
then on top of that we put structured
control flow like if and wael and stuff
like that and and it makes static
analysis tools way more effective like
like worlds and worlds more effective
and then it makes verification efforts a
lot easier as well dynamic jumps are are
terrible like can't we hire you for what
we can do what one last questions we
have already asked questions can I hit a
question to Gregg oh sure all right
never mind sorry audience I'm gonna be
quick
Gregg you mentioned that at some point
that EVM might be the the general
description of the contract itself but
it's not the way it is executed it's
just translated to something else maybe
I got it wrong but that's what you
mentioned like in the first five minutes
that maybe you were translated to you
Azam at some point instead I'm saying we
can do the work now to get a better EVM
ready and going on the main chain
because sharding all of thats also
somewhere way out in the future we don't
know where it is you know and then when
Rasim is on the main chain solid
formalized
ready to go and your compiler to compile
from EVM to as and that's ready to go
there's not any big problem to migrate
code there is no migration that's just
that's just the way that it gets
executed right no one no one cares
whether you compile it to us and then
then compile the license of machine code
or interpreted or compiled what right to
machine code that the user doesn't care
about that as long as it gets executed
correctly
but short-term we we want to just get it
working and a little bit longer term
whoa excuse me just a little longer term
we you know we now have a a formerly
verified subset of C we've got I don't
know it's a subset or all but LLVM has
been formally verified yeah so we can
have a form of a formally verified EVM
1.5 executions of s mutations
mm-hmm we have specifications but I
wouldn't say it's verified it's just a
specification okay so as usual grigory's
problem seeing a little bit more than
exists but I want to put in another just
question and we shouldn't answer it
right now just leave it hanging if we
just culminating all these discussions
we had if we keep adding these changes
to EVM yet we have to keep backwards
compatibility you know to a certain
extent or the different ways to do it
and then we still plan to switch to
uoit's them does that leave us with more
legacy we have to keep because all of
this stuff is on the main net or you
know it's a better position but I don't
think we should answer this right now we
should just think about this or we did
we have time for one more question from
the audience okay a two second answer is
just as well as against more stable you
stop you cap off EVM one and say it's a
tail on the main chain and you have to
support it it has to be supported
forever I'm saying it can be supported
with the compiler and you stopped
evolving it so you don't keep creating
backwards compel it okay so we've a next
panel at some point thank you guys very
much thanks for listening
you