 and Epsilon team at Ethereum Foundation, and this talk was originally about what's next in the EVM, but we shorted it a bit because like Nick talks, but what I want to tell you about today is quick, to give you a quick introduction to EOF EVM object format. But we have to start with the current EVM we have. So one of the design goals of current EVM is simplicity and the thing is that we kind of overdone it. And the current EVM can just execute whatever you will provide to it. And that's why I kind of sometimes thinking about it as a garbage-eating machine. So it brings some success to EVM but it also brings some inefficiencies to it. So one of these inefficient aspects of EVM is that you need to do a lot of work, except above the actual work the instruction are doing internally. So this is like the checks that every step in the interpreter you will need to perform to make sure that the EVM works as specification wants it to go. And this is kind of the motivation we want to create it up. And the cleanup of that is to introduce a container, binary container for the programs in EVM so that it will kind of translate the mixture of different features and some missed features in the legacy EVM to something that is a bit more structured and polished. So the main aspect of EOF is to provide some metadata about the program, including the version number and splits the bytes into code and data sections. We can also do a bit more about that. This is kind of the next proposal that can be applied to the MEV of EOF, which is to introduce functions. So we can partition the code section into more pieces with additional function type information. And to work with the functions in EVM we will introduce two new instructions. One is to call the other code blob and one is to return from the call to the caller. And this like the calling the functions internally works like allows you to move you between the different code sections. In the code sections you can use relative jumps, which would replace the existing dynamic jumps. And yeah, so this is the control flow instructions that will allow you move it around in the code sections and it won't be allowed to actually cross the boundaries of the partitions. And as I mentioned, having to this control flow features we can deprecate the existing jumps semantics. In particular, this is really useful because we can drop the jump this analysis which has to be performed about EVM programs before every execution. And if we kind of add up all of that, with additional code verification that will happen we can eliminate these like first three checks in the EVM. So this is the additional aspects that can be added to that which we can like verify how the functions behave internally with like simple algorithms, but to sum up all of that, yeah, that's kind of improved version of EVM that has some nice control flow, have the code and data separation and support 90 functions. Yeah, so that's mostly what I had to show you today. These are pointers when you can find more information. I think in particular, the EFCC talk from this year it's kind of the extended version of this talk. So yeah, you're invited to see it after it. And yeah, the five bullet points in the end are that all the APs that kind of specify the broad aspect of EOF. Yeah, I still have one minute. So if you want, you can shout some questions from the audience. That's hard question. I mean, we're kind of competing with the proto-dunkshark link and we've draws right now. So yeah, it's hard to tell actually. Some of these aspects were prepared for the show. Some of these aspects were prepared for Shanghai but not all of the features I talked about today. Hi, I have a quick question. I'm here. So in one of the slides you strike through stack on the floor and stack overflow. This one and only... Can you give a bit more details on that? Yeah, this is done by code validation. So when you want to deploy a code, it will go through additional validation process. And in particular, when you don't have dynamic jumps you can statically check if the function will never stack underflow. Stack overflow is a bit more complicated but you can compute like the maximum stack height the function reaches. And then whenever you call the function you can check if you still have enough stack space available. But the second one is a bit more complex and it has some trade-offs. I think it's my time, so thank you very much. Thank you.