EELS: The Future of Execution Layer Specifications by Peter Davies | Devcon Bogotá

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