Ethereum Execution Layer Specifications (EELS) by Guruprasad Kamath | Devcon SEA

[Music] [Music] so I'm going to be doing the rest of the talk in English I'm Guru uh I work on the E team at the ethereum foundation and I'm really excited to be here and talk to you a little bit about eels what we are all about and what we do where we fit in the larger ecosystem uh broader picture so I'll start with what eels is eels stands for the ethereum execution layer specifications uh which means simple enough we specify the execution layer but what does it mean to specify the execution layer there are all these different aspects to the execution layer different components to it and what do we mean by specifying the execution layer we focus solely on basically the core of the execution layer which is basically the state transition function the evm uh and when we talk about the state transition function what I mean is there are a couple of very important questions that we focus on uh let's say I have a blockchain and I'm looking to add a new block to the end of this chain there are two important questions that e tries to answer answer very precisely first one is if this new block that I'm trying to add is it a valid block at all the second question that we're trying to answer is let's say it is an valid block and I try I add this block to the end of this chain how does that operation change the state of the chain so those are the two uh basic questions that eels tries to answer and like I said tries to answer very precisely the some of the other aspects of the El is not something we really look at we don't look at reog networking transaction pool and so on so those are not focused on when we talk about eels and that's our GitHub repository in case you're interested I'll give you a QR code at the end of the uh presentation that you can scan um when we talked about specifying the execution layer we do this in Python uh as you can see on the screenshot on the right you have a screenshot of the state transition function there are a few things that you'll already notice when it in the screenshot it is executable it's written in Python which means you get all of the nice things that you have when you have executable specs you can kind of isolate components run components individually see how they function uh try to see the inputs and outputs uh all that nice stuff one of the things that we've done while uh building eels is uh that we have tried to focus heavily on uh optimizing for readability that means we want the code to be very readable we want it to be easy to update and this is important uh when I talk a little bit about why we are doing eels uh uh this readability aspect of Els is going to be extremely extremely important and has some interesting consequences um and when we also talk about optimized for readability we also mean it's extensively documented we have taken uh a lot of effort to document every single component every single function uh that's there in Neil what it does and kind of uh speak a little bit more of that and we have tried to uh I mentioned earlier that we have written this in Python but uh that is true to the extent to an extent but we have not used all the advanced aspects of python as well again coming back to the readability aspect because we have tried to keep it as close to pseudo code as possible so that it's not something that's like super focused on python developers we want everyone to be able to read this we want everyone to be able to update it so we have tried to keep the code as close pseudo code as possible which is again important when we uh speak about the broader aims that eels has because of these reasons it's a great playground for prototyping new eips it's something that we have as a focus we want new eips to be prototyped in eels and the readability aspect the ease of updating the ease of reading ease of understanding plays a huge role there the question then is uh next question is why do we need eels at all if I were to answer that question I would like to First Look at the El development cycle that goes on right now so the execution layer how new things are added to the execution layer so typically when I talk about the development cycle there are these are the two ends of that cycle where uh on the one hand you have research uh researchers basically uh come up with new uh ideas that they would like to see in ethereum new features that they would like to see they come up with new eips uh eips are ethereum Improvement proposals um and on the other end of the spectrum is basically the client developers who uh um who look at who take these eips update the uh update the clients to reflect these changes and uh do it in a super optimized way so that it can run in a production level kind of an environment uh there it is heavily optimized for performance and now with this kind of a of a framework uh there are a few implications that uh this kind of a framework will have on the El development cycle so now let's say you are a uh EIP proposer who's uh EIP author who's proposing a new change with this kind of a system there will be a few implications for you one of the first ones is you will have to update your EIP in one of the clients yourself now like I just mentioned these clients are production level softwares those are the these are not uh very simple softwares to work with uh um and uh there are a lot of moving parts to them so uh someone who's not intimately familiar with the software code is software code base might find it a bit of a step to uh kind of go and Implement their eips u in the production level client a second implication or a second thing that you can do if you are an EIP author is you can wait for a client Dev to pick this up pick up your EIP and implement it in their client but as I think all of you know client devs are extremely busy they have limited bandwidth their bandwidth is extremely precious and so unless like the broader Community is kind of uh considering your EIP very seriously it's unlikely that uh a client Dev will uh pick up your EIP and implement it in the uh in in the clients a third implication that this kind of development cycle has is you might end up with different eips being uh added to different clients uh for example uh recently we had uh for the Prague uh there was discussion around including uh eof and uh 7702 within Prague and it turned out eof was implemented on evm 1 and uh uh 7702 was first implemented on ethereum JS so if we are to talk about eips and and try to kind of find out how eips might interact with each other what are the different side effects and if they are on multiple different clients it it's a bit of a challenge you have to wait for it to be implemented all in one place and then you can kind of answer some of those questions about interactions so you will have this uh the eips scattered in different clients with this kind of a architecture because uh I maybe I should mention that when I talk about client implementations we are talking about multiple different clients so in a post eels world we are looking to move to something slightly different from this what we are trying to do is this so uh and a quick shout out to the east team East is basically the testing team and uh they generate the tests and uh I think they have a talk and workshop tomorrow I would highly recommend you guys check them out uh check the talk out tomorrow but for the purposes of this talk all you will need to know is East is a uh package that kind of uh uh takes a working evm implementation and spits out tests it generates tests for you so uh that knowledge is enough for the purposes of this talk so what we are looking for is to move to something like this where the researchers come and Implement uh their eips in eels which should be extremely easy because it's like I said earlier we have optimized for readability and uh for writing new code for updating so this should be uh uh very easy even if the EIP author is unfamiliar with a with a client code and Eels is very focused to the state transition function so there's not a lot of clutter in the eels code and then eels talks to East generates the tests and the clients even before they Implement their first line of code have all the tests that they need ready to go so basically before they write their first line of code they have all the tests ready so uh there's benefits on both ends of the spectrum the researchers have a easy way to play around with stuff iterate on their ideas and see what are some of the weird edge cases that might come up and so on and the client of just have to focus on optimizing their uh implementation they don't have to worry about tests being there so eels and E together will take care of that scenario okay uh just to summarize some of the advantages of uh using eels a faster iteration cycle uh researchers playing around with eels and um yeah on the other side the client having all the tests ready um uh with it being a playground it can throw light on uh some of the weird edge cases that might come up so if you were to write a EIP document in Word or in some kind of um plain English it is sometimes going to be a little bit difficult to kind of imagine all the weird edge cases that might come up whereas if you're implementing it somewhere it's more likely that you'll encounter some something will come up to the surface that you are not considered uh it's a One-Stop shop for EIP prototyping which means all the eips that we are considering for subsequent updates are in one place we can answer multiple questions regarding how EIP is interact with each other and what are some of the side effects and those kinds of things and the last thing is uh this also means that the EIP authors get to leverage all the tools that e eels has developed we have developed a lot of tools to make uh writing EIP simpler uh we have a lot of code analysis tools linting tools test filling tools and uh these become accessible to the EIP author right out of the box so it's extremely beneficial and we are also closely integrated with east east is also uh written in Python so uh there's more scope for uh closer integration uh when it comes to e and East and finally you have us uh uh the members of the eels team who are ready to uh support you uh in case you uh in case you need any help writing the eips or in case you need any help regarding East uh eels uh where are we right now in terms of our uh in terms of our road map um we have implemented all folks up to and including Prague um so Prague is still not live on Main net but we have all the eips ready to go uh we have implemented them all um we have a working implementation of eof eof uh a fully functional version of eoff is available which is I think currently being considered for the next Folk it is Right Now the default test filler for East so uh if you were to go to East and uh uh try to fill the test uh eels would be the uh uh evm uh implementation that it uses to fill the tests and finally the last two points I would uh so we consume all the current tests as well and uh the other thing is we have verified all the main net blocks using eels uh this is for us to give a an additional level of confidence that whatever we have implemented so far everything until and including Prague is uh accurate so we have verified main net blocks up until Cancun so far but we are uh quickly progressing towards the tip of the chain and this is where we would like to go in a in the in the road map that we that I showed you earlier why we need eels we want to be the first ones to have all the EIP implementations and all the updates to EIP subsequently so we in the post eels in eels world uh this is is uh one of our main objectives um we would like to develop more uh uh tools for EIP auths our entire thing is to make uh development and prototyping of EIP simpler so we would like to uh build more tooling for EIP authors we would also want to integrate into the EIP process there are currently discussions going on around how we kind of uh enforce this uh whether we make it uh a mandatory part of the EIP process or uh I mean there are discussions going on on this we would this is something we would like to uh uh we would like to integrate in the EIP process largely and finally we would like to also participate in Dev Nets uh when when something is being developed and there are Dev Nets that are live we would want to be able to uh have the capacity to verify the verify the chain finally how how do you how can you use eels uh like I mentioned this is our repository on GitHub ethereum execution specs uh we support uh it supports um python 310 and uh above uh the I'd like to talk a little bit about our repository structure and the folder structure so uh the folks that are live on mainnet are in the master Branch so that is the stable Branch so right now this is everything up until Cancun um and the folks that are under development are in their own Branch uh this is the nomenclature that we use folk Prague is the current uh development folk and each EIP within Prague is maintained in its own uh Branch separately so if you were to uh if you were uh trying to add a PR you would create a new EIP Branch for your EIP and this is kind of what the folder structure looks like the source ethereum is basically what houses all the specs and one thing that uh if you notice um there's a separate fold for each hard folk on the execution layer for example Homestead is basically an entire copy of Frontier plus the additional folks that were meant for Homestead and so on the next folk is basically Homestead plus the next eips now uh this is a deliberate choice that we have made uh it's not so great for COD from a perspective of code duplication but it's great when it comes to readability uh I've mentioned this a few times already readability has been a big Focus of us so you can just go to um one of the folders for example Istanbul and that folder will tell you exactly how the entirety of Istanbul folk works so there's no clutter with different folks U so you can just go to a particular hard folk and understand entirely how that hard Fork works so this means there are no conditionals so if you go to a real client you'll have uh all these conditionals if shangai do this if Cancun do this and so on and so forth there's no such thing here because because of this choice that we have made um there's no clutter in the code so you can uh look at each code each hard Fork individually uh it's extremely easy to read uh but also in a scenario like this one might legitimately ask the question how do I track the updates that happened in each for right so that's a important question a lot of there are a lot of scenarios where you want to answer questions like oh what happened in London what happened in Berlin and so on for that we have a custom diffing tool and um if you look at the screenshot on the right that's a screenshot of what was the difference between the two hard folks that I've highlighted here mu Glacier and Istanbul so what changed between Istanbul and Muer Glacier and if you look at the diffing tool diffing tool is again it renders the diffs in HTML uh on GitHub pages and if you look at it it tells you all uh that happened between Istanbul and mu glacier is that we pushed the difficulty bomb so yeah so you can so you can look at the diffs between any consecutive folks this way and have your questions answered yeah this is a team uh right now so it's me uh Sam and Peter Peter's I think in the in the audience uh Sam uh could not make it to Devcon this this year so yeah shout out to both of them finally how can you contribute uh like any other good open source project we welcome all kinds of contributions from uh documentation to any kind of pull requests that that you might want to create any kind of issues that you might want to work on on a repository but there are two specific ones that I would like to particularly highlight um if you are working on a project that uses an evm back end we would love to see if you can integrate eels into your project and see how easy or difficult that entire process was uh we would love to hear uh from you uh how that was so that we can kind of improve anything that uh we we have not considered so far and same with if you're an EIP author uh we would love for you to implement your EIP on eels and again would love to hear back from you uh any any kind of thing that was difficult or easy uh anything that we can improve any kind of feedback extremely appreciated yeah that's all I had to say this uh QR code takes you to our GitHub repository and uh in case there are any questions I'd be happy to take them thank you thank you Guru so we have uh one question and again uh the QR code if you want to get a question in um just throw that up there but we will start off with this one um how do you write a code that is able to test El Behavior which would could require CL input like a specific engine API call do you also have to implement CL changes uh no we don't Implement CL changes uh we take uh so there's tools that um um we can uh we we use the T1 tool for this P purpose and the t810 tool can take the inputs from the uh from the uh CL for example I think we are already doing this in Shanghai with withdrawals so we take the withdrawals as an input we don't do any kind of checks on them so that's something that we assume the input that we've gotten is basically what it is and then try to run the El block assuming that as the input thank you then how do you use slimport block States when validating an existing block um do you mean I'm I'm trying to understand we we we imported as Json so if you have uh if you have uh all the block parameters in a Json file we can import it that way um I'm uh trying to understand if that's what this question is uh meant to ask or if not if it was your question quickly put a followup yeah I think uh that answer question okay we got it um well thank you thank you um if we have no more questions we'll wrap it up there let's give Guru a huge round of applause thank you so much