foreign
[Music]
execution layer specifications and we're
working on the future of how do you
specify the execution there so we've
just heard about how the consensus layer
do their specifications in Python
if you think what I'm talking about is
similar it's because that's where we got
the idea from before I begin I want to
talk about what I mean by the execution
layer we're only here interested in the
state's transition function so you have
like a long chain of blocks you have
some State you add in some new state and
the question is firstly is that block
valid are you allowed to add it to the
state and secondly what is the new state
afterwards we don't care about anything
else we don't care about networking we
don't care how we input reorgs we only
care about what is the state transition
function
So currently let's suppose you're like
someone you want to know about the state
transition function the Executioner how
it works where would you go for
information well the first place you
could go is the yellow paper where I
have the yellow paper here this is a
lovely extract that explains um what the
hell of a validity conditions are and
some people think this is readable
um
they are in the minority if you're
curious about the like weird mountains
um they're not mountains that's how
mathematicians write down
um the other problem with the yellow
paper is that it's actually really out
of date um this is the Berlin version
the reason it's the Berlin version is
because no one's implemented London yet
um secondly you can look at eips eips
are individual slices of like changes
they're specific change proposals and
they're like you can look at them and
see the history but they're they're not
you don't they don't tell you about the
relationship they only tell you about
individual changes in isolation so if
you like for example if you re you can
read heaps where it's like well this
thing says this and this thing says this
but how do those two things interact and
you just can't get that from the IVs
um at that point you can then go again
when I look at the test suite and the
test Suite is great it is full of loads
and loads of tests but ultimately it's
just a pile of tests it's not
particularly well organized and if you
want to find some Behavior like maybe
you can find somewhere in the test Suite
where that behavior is tested but it's
not specifying anything
and then you can just give up and look
at the gas source code
um I fundamentally if you've like got to
the point where you're reading the
having to read the client source code to
work out how the execution layer works
we have failed at specifying it these
clients they are big like complicated
high performance pieces of code they're
not like designed for the reader
the other thing about specifications is
they need to be passed the standards
process you can't just like fail we're
going to implement all this stuff and
then we're going to update the
specifications later this is the big
problem with the yellow paper is that
it's not part of it no one like proposes
A Change by saying this is how I would
change the yellow paper
so the yellow paper just gets updated
later on as an after foot
the other problem is that the other
paper is just like a documentation it's
not executable you can't test whether it
works
um at least close to eops as well so
this here is a sample from the EIP that
changes how the cost of the mod x
pre-compile works it was proposed it was
accepted and you're like this is nice
there's a nice piece of easily readable
python that says exactly what it does
problem this is this python is wrong
now no one has ever executed this python
because if they had they would discover
that it doesn't really make any sense
um and I mean as Donald crew said Beware
bugs in the above code I have only
proved it correct
I haven't executed it
so you need a this is our approach
um we want to start with like a code
first approach to specifications
um we take like Python and we're not
just writing any old python we're like
trying to create the python that if you
open like some programming book and
someone had an example algorithm
that python so we don't use classes it's
just methods and effectively structs
this is like the common language that
all programmers speak this
um you know anyone who's done any
programming will immediately know what
this is you don't need to like
understand fewer mathematics like you do
with the yellow paper
and crucially it can be executed we can
test it if you want to know what the
python python does you can run it if you
want to compare it to a client you can
run this you can run the client do they
do the same thing
we're purely here interested in
readability we don't care about
performance it's extremely slow it can
think mainnet I think it takes about
probably getting about six to nine
months if you want to start from Genesis
and get to the head of the chain
it's not a viable client
we also make some very weird like design
choices we look at hard Forks in
isolation so if you have various if you
go you'll see it's ethereum slash uh
theorem slash Frontier and slash
Homestead and each of those is an
independent implementation of those hard
Forks
so this is like terrible for like code
duplication like literally every time we
include a new hard Fork there's like
this massive coffee of like thousands of
lines of code
uh but it's great if you're like a
reader you want to read it
you know you can see like how Homestead
works completely in isolation you don't
have to have to think about how it
relates to other things whereas if you
read a real client it's just a pie of
like if we're later than spiritious
Dragon do this thing otherwise do this
thing um if you do want to see look at
the comparison so we're developing
specialist diff tools and those diff
tools
um allow you to compare like this is
exactly what happened this is the
specification for Frontier this is the
specification for Homestead this is
what's changed exactly line by line in
code that we have tested
um so here's a sample
this is the S load opcode to give you
like a feel
um a number of things here first you can
immediately see we've really tried to
make it as readable as possible we've
also divided that up into these like
individual sections which we've given
headers
um this actually like matters there are
a number of quite subtle semantics that
the evm has that relates from the fact
that gas
calculations are done before any
computation is done and you can get very
confused about some of the subtleties of
particularly the cool lock codes if you
don't realize this
um now I want to move on to like now we
have these things how can that like
affect the development process how does
having these specifications make
improving and building on the evm better
and I think it's helpful here to think
about two signs of development process
on one hand you have like your r d
people think of italic and then on the
other hand you have implementers um
Peter who's the gef team lead
um the r d people
um they're doing research
um they want to throw together some
simple python they don't really care
about performance they just want to
write it test it and think is this a way
we should do this thing
on the other hand you have the
implementers who are trying to write her
robust production-ready system they want
to know every single subtle detail of
every single thing that has to happen
because if they get it wrong that's a
major security instance and also they
have to like spend all their time
thinking about the subtleties of like DB
disk performance which is a endless bug
there for anyone who has worked on the
execution there
um and Eels provides a common framework
it allows these two sides to talk to
each other it's a Common Language your r
d people they can write that Python and
this is what is already when they're
doing their research they write little
python models well now you have these
specs if you've written that little
python model you can like stick it in
eels you can implement it eels it's not
much more work and already you have like
you have something that you can then
show to the implementers this leads to
this sort of development process you
have your r d people they develop their
idea they prototype it in eels you then
give it to us at the eels team and we as
of like the governance process integrate
all of those things together we make a
hard Fork exactly what goes in obviously
is like a theme for all quartet it's not
like we're taking all the power here and
quickly once you've done that there's a
whole bunch of things you can do because
you have an executable spec
we are executable spec will be able to
fill all the test sectors it might even
be able to like run its own very
miniature like two million gas a block
test net and that means that you can
have tests and for size specs before
you've even written a line of code in
your production class
this like frees up um production clients
to not have to be also the r d
playground that they cut that they
sometimes are it is not like a perfect
thing like often you have to go and
Implement models in production clients
to deal with performance issues there
are networking issues we don't deal with
but currently like anyone who wants to
propose any like significant change they
have they like implemented in geaf or
wherever
um whereas now you have this playground
to do it in
and critically this is like a sort of
paralyzation stage because like
currently you know you currently you
have this like situation where like the
instrumentals and the r d people like
get have to like interact much more
tightly if you have this like eels
process you can like separate that out
and do these in parallel so that you can
like have the implementers finishing up
one hard Fork while eels are like
getting ready to prepare the next hard
Fork whereas if you're like busy
modeling things in gef and the
implementers are also tied into doing
the r d you just don't get the same
parallel efficiency I just now talk a
bit about where we're at we have
implemented all the hard folks um uh the
merge is still a PR but we're nearly
there
um we're going to need to do a bunch of
like
um refactoring
um and then we need to freeze the code
because we're asking people to like
build it we're saying if you want to
take an EIP and you want to build on top
of that change it you have to take
our latest Fork copy it Implement your
own changes and we can't ask people to
do that sort of thing until we've freeze
the code and said we're not going to
like refactor it under you and we're not
quite there yet once we've done that
we're playing like Shadow the current
governance process for Shanghai so
Shanghai is going to go through in
exactly the way that all previous like
hard Forks have gone through but we're
going to also be working with a whole
bunch of people to try and Implement
those changes changes as eels proposals
and then we're going to like see how the
government's process works and then
hopefully we can like improve on that
and talk about moving away from some of
these Legacy approaches to specifying
execution there finally there's the
question of how you can help first if
you actually need your help yet we're
still
um uh code we're still coding we need to
finish that once we've done that we ask
you to like Implement your favorite EIP
um and like give us feedback like how
was it because we didn't want this to be
a world where we as like the eels team
can like develop what we want develop
things and we can propose changes but no
one else understands it I don't want to
be in the situation that you're
currently with DNA people actually only
a really quite small minority of people
know how to write Tech
um and how to change the Euro paper so I
want this to be like an open process
where anyone who's like oh I want to
propose something to just clone that
repository run the new fork tool and
Implement their change and like produce
a proposal without being burdened by
having to think about like how the FDB
works or whatever or whatever else
they're going to do they're modeling
um yeah
um that's the end of my talk
um we are have plenty of time so do
people have any questions
State growth so if I make a commit to
the execution spec and I want to see how
that influences State growth over time
and like the capability to run a node
and things like that have those sort of
things those mutations been thought
about from a uh you know
metrics Gathering level
um I mean this is a thing that like
people who implement this like think
about this all the time
um like I mean yes because we hold the
whole state you can like model that sort
of thing I think a lot of that is mostly
about gas pricing and gas accounting and
like there are advantages here so for
example there was a proposal about how
withdrawals worked because I have the
execution specs I could like look up the
table of gas prices in the execution so
I can say well this is how much this
sort of thing should cost and like yeah
but I don't I don't think our tool is
like particularly useful for like
modeling State growth particularly you
just need to understand like What
patients can cause State growth and how
much gas those could those cost
how is this going to interact with the
reference tests that the eels there's a
lot of crazy edge cases in reference
tests such as integer boundaries and
other strange things
oh yeah I mean I I've had a lot of fun
with crazy edge cases I should do a talk
on Crazy Edge cases once they at some
point they are amazing I mean firstly we
run all of the reference tests so if you
go in our test Suite you type talks the
automatic
um like test Suite will run all of the
reference tests and So currently we pass
every single one of them and I have like
learned an awful lot about the crazy
edge cases of the VM we actually hope to
confirm that you know we want to be the
mechanical builder of the um execution
test So currently for those who are not
familiar we have test fillers
um which are like they're not like a
complete test they say here is what the
pre-state's like here are some
assertions about what it should be like
per state
then you run you take a client um it's
usually gef and you run a filling
process that gives you a completed
um reference test
um that reference reference test and it
tells you what the state bridge is it
tells you basically exactly what the
block should be after you can perform
this execution
um we will think that we should be like
the chemical filler of those tests we
can fill them before the execution
clients had even implemented those tests
um and then we can if you want to and
that means that clients can like use the
test to build their clients whereas
currently until you've implemented
something you can't fill the reference
tests and you have to invent a
production client
um there is also and I haven't thought
about in great detail the question of
whether we should use the whether we can
like analyze the structure of the
alleles to like generate new reference
tests and basically do some sort of path
analysis and say well these are the
possible parts of this sort of code base
can we follow every possible path and
make sure there's a reference test that
follows every possible path but that's
like r d that we like haven't done yet
you mentioned you implemented
no you care only about State transition
function and that means you implemented
your own evm and you can fill the test
and and
you provide the post State hash yeah
like if you have a chain and you want if
you have a chain and you want and you
have a block and your proposal is to add
that block to the end of that chain and
update the state we can tell you we our
tests specify exact our thing specifies
exactly
um whether that block is valid are you
allowed to do that because blocks
something to take advantage tend to be
invalid um in that case you're just not
allowed to do it and if it is valid it
tells you what the state changes are and
then you can do the next thing we don't
do anything else that's the only
question we answer
um so this is obviously uh inspired by
the consensus specs or the pi spec are
there any particular architecture
changes or learnings you've gotten from
the pi specs oh yeah that's a really
good question okay so there's a couple
of different tiers here
um the first one
um is that the
um Pi spec is you connected to this
price spec is a document
um that can be it is a bunch of
documentation that can be compiled to
code so if you look at the pi spec it's
a bunch of MD files with some code in
then there's a compilation process that
spits out code we are a bunch of code
um that is
um we can then you can then compile
using standard documentation tools to
documentation
um the second big change if the pi spec
does this like incremental building
stage where
um in the price spec you have phase zero
and then you have outer and the out her
documentation just adds a few changes to
the face hero whereas what we did was we
copied we copy the entire thing and
create a new version that contains
everything which means because otherwise
what would happen is if you wanted to
know how
um the merge worked in Paris Works you'd
have to read Paris which would say these
are the changes versus London and then
London would say well these are the
changes versus Berlin then Berlin would
say well these are the changes versus
istanbula it'll just keep going on and
on and so we don't think that's a
particularly good way especially because
a lot of the historical details are
really quite Legacy and not things that
people need to be concerned with
nowadays because they've been changed
out and so we just like do isolate
they're completely isolated files this
cause like a whole bunch of code
duplication issues and complexity but it
does mean it's like really simple you
can read a particular Fork completely in
isolation from any other Fork whereas if
you can't do that with the consensus
face I was wondering for the executables
back how do you think it might change
and improve like the eeip process of
ethereum there was lots of conversation
in terms of governance of how when
you're proposing an EIP maybe this
should be like a requirement to kind of
speed up the testing process but would
love to hear your thoughts on how it
could be integrated and what parts of it
it could improve to change that that EIP
flow so on the one so there are some
people who think that we should get rid
of the EIP process for the execution
layer we should have bullish erp's the
execution layer instead you should have
whatever eels proposals are coordination
just if you want to change the execution
layer you write an eel's proposal you
might write a small amount of ancillary
documentation but both you just request
PR there are other people who think that
we should do a like hybrid process where
there is a EIP and the EIP comes with as
like a mandatory component a yields
change
um I actually don't have particularly
strong opinion of this I can see the
argument for both sides
um yeah but there's lots of thoughts on
this I generally take the attitude that
I'm going to wait until like we've
started using this and people have like
seen it in production and then they can
start talking about what they actually
want to do