Ethereum Foundation DevCon 6 - Layer 1 Protocol Track, 14 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/eels-the-future-of-execution-layer-specifications/

Peter Davies gives an overview of the work of the EELS (Ethereum Execution Layer Specifications) team on the [new executable specifications](https://github.com/ethereum/execution-specs) for the Ethereum execution layer. He discusses why new specifications are needed and how they will impact future governance processes.

Speaker(s): Peter Davies
Skill level: Intermediate
Track: Layer 1 Protocol
Keywords: execution,specifications

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

A

A

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.

A

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?

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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?

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

B

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.

A

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.

A

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.

C

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.

A

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.

A

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.

A

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.

A

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.

A

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.

D

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.

A

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?

A

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.

E

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.

A

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.

A

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.

A

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.

A

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.

A

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.

F

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.

A

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.

A

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.