EOF Implementers Call #14

Transcript

hey y'all welcome to the eof implementers call number 14. um let's just go ahead and get started with some client updates does anybody want to share what they've been up to the last couple weeks I'm in uh from another mine side we don't have that many updates besides we were going fixing minor problems will be found in our PR's and we were Pro we are prototyping

the three static and static call that I guess call and call alternatives for eof and we haven't merged that yet into the eofbr so yeah that's it cool um anything from AVM one hi everyone um yeah so we kind of reached the point yeah I wasn't on the last call so if something could be overlapping with the previous updates um forgive me but uh so first of all we

had a release of evm1 and included all the Shanghai trainers and all of that but it also has kind of sealed this eof 1.0 that we planned to have for Shanghai originally um and this is more or less reflects the the state of the spec that we had some time ago and there's also a Target version of uh ethereum Slash tests that actually agrees with this um so that kind of like the Milestone that is is finished and on top of that we started applying

uh so far um like some changes to eof what what is I think nothing well I think there's one more change that we actually already included uh I will check it in one but we're doing like some of the modifications in parallel and uh this is a bit of um sending up uh some new infrastructure which means uh we want to be able to kind of tighten the loop of development and don't rely off on this official ethereum slash tests

so we we're doing a fork of that which will be at upstreamed later but we don't want to wait for this Upstream to happen so we can move on with features and we're kind of doing the this is something we mentioned for longer like delegate call restriction uh some new instructions are being implemented like uh the instructions related to data access in the data section create three and probably many others as well yeah jump F like all of that is happening in parallel some of them are

almost done and will trying to merge them in coming days yeah so so mostly that's that's the update yeah I'm just checking if there's something new I think not uh the one more like VM change was M Copy it was added but that's kind of outside of eof that was added to Cancun or yes that's added for Cancun because we kind of work want to work on this and also uh

generate status for that so people can take a look if it stayed or not uh I mean we don't know but uh I think it was kind of back and forth if how to exactly do it but evm1 it's not like doesn't have very extensive infrastructure how to enable eaps and all of that yeah so we decided to just put it into Cancun so the test will be kind of done this way but we kind of open to it like um the discussion how to exactly do it

if it's I I was we were considering like going one more revision uh into the future we also had this like eaps enables I think that was used some years before I mean this like yeah the hard Fork name plus something and I'm not sure if that's also like something people would like to continue working with uh because there are some changes to this like official tests and now the ap's tests are just going into different directory

so maybe that's enough so like I assume if the M Copy status will go into different directory in the test repo and um so if you want to check them I guess you just need to point your tool to this directory and you don't have to kind of extensively configure it but uh yeah we'll see how it's play out in the in practice so yeah so like nothing none of the like in expected eof changes has been the monitor in eof but I think there are at least four or five different set of

features that we work on in parallel and uh I guess it's like takes longer to to go from the Prototype phase to to something we like the team is happy with and we can merge but I think uh we kind of unblocked some of the obstacles um so I expect it will go a bit faster from now on yeah they make that makes a lot of sense cool sounds like a pretty good two weeks for you guys I don't know if Mario had anything any thoughts on if it's useful to have these like Fork name plus EIP number tests or like is

that a mechanism that you think is like useful for testing yeah I I'm fine either way I think we do use it in the python test so it's it's it's it's fine by by me either way I I do find it useful because you don't separate you can if you have the EIP number only you can really separate your tests from the the rest of the of the fork if you're not not entirely sure if that specific EIP is going to make it into the the fork that that way is useful but yeah I'm fine either way bass is not set up well to do the plus

EIP so the EIP directories are actually a great solution same for us okay sounds good uh I assume Daniel you didn't have any updates for Basu and um not too many been focused on uh optimizations mostly As far as the state we're at with our Mega um we have all the operations except for the call series and the create series mostly waiting for Clarity on some of those I don't think creates changing too much maybe an OP code number um the call series op code numbers um so that's you know what I'm waiting

on before I get too invested I do have one um small test that is a smoke test for the operations not by any means uh an extensive test it just makes sure that the operator is expected which was a good thing to put in because they weren't at first um but yeah I guess um it's it's until there's there's Clarity on where we're moving some of the op code numbers and then we can get really excited about writing the tests and and moving those forward so that's where base is at right now makes sense cool uh okay I guess we can switch gears

probably no compiler updates all right so we can just go ahead and jump into spec updates is there anything that you guys wanted to discuss on the call here I didn't see a lot of chatter on the evm channel over the last two weeks I think we've all been worrying about SSD versus rlp yeah so one thing I would like to discuss at hammer down as there was discussion of moving some of the op codes around um something like moving all of the eof

only up codes into the E-Series taking them out of the B series and if we move stuff out of the B series do we need to move t-store down to b0 or are we fine keeping it wherever it's at in the B series um and also where the um I think we did have Clarity well there was some conflict with stuff like return contract were some of the final op codes were so those are um I think some things we need to we need to lock down before we can make a real serious proposal we also need a spec for the um gas-free ones I forgot who was going to take a stab it two weeks ago but if they don't have time I could take a stab at it myself if there's no or progressing on that EIP spec for the gas recall series

those are the things I think we should discuss today um yeah did you end up writing down a proposal for the exact op code layout or did we just discuss it on the call last week we discussed it on the call I thought did it not get captured in the chat I think it was in the chat and the chat disappeared so we have to go back to those yeah but someone had expressed the desire that the EIP only ones get concentrated in one place because there's some op codes coming in that are still useful in Legacy um so those could be in a different yeah I don't have I can't pull the notes

up in front of me right now so I don't remember what the exact layouts were uh I think I don't know how contentious these are I think it's more important just to say like this is what we think the op code should be like we still have the opportunity to change 1153's opcodes and we should sort that out ASAP okay um it might be a couple days for me to write that up uh got my son's High School graduation this week so a lot of uh non-work time yeah uh I don't know if anyone from the Epsilon team has a strong feeling about how the op code should be set out

yeah I I don't really have like any strong preferences um although we kind of I mean this is kind of recurring issue and we had the same for M Copy for example so it doesn't really have nice fit into considering consistent grouping of opcos and and so on I don't know how to exactly solve that so we don't have to kind of have like big coordination calls to resolve that practically uh if we consider like this Transit

Transit storage think maybe the good solution would be to move them to this m store s store group but we just took three three slots there for air jumps and they are like eof only so we can move them from there put somewhere like to UF only section and then have a place for this store so t-store doesn't use this b0 whatever section I mean this this number of ways we can do it I don't know

um what what would be good yeah just like maybe just have kind of spreadsheet with like all proposed the APS and um I don't know something that we can have like overview but also with enough details to understand where the op codes are targeting so we don't have to kind of go into individual eaps documents and like because it's kind of people have the same idea where to put new instructions and they usually conflict with each other and I kind of feel it's doesn't it's not like a big deal in the end

I mean it's random selection would be fine for me as well uh so I think doesn't really affects so much the the software is just like probably like pedantic nature of of Developers for sure yeah so but like maybe have uh I don't know how much you want to invest in organizing this but something or like like one place when you can at least see some suggestions where to put new instructions on something and uh um so I'm trying I think this is a great

candidate for an informative eat a living document of it and as eip's go in and out it gets added and updated and that's the duty of an opcode EIP is to do their changes there yeah yeah maybe it sounds like yes I agree this is anybody want to take a stab at it did you have something to say Alex yeah I would actually suggest why don't we but then then I realized that technically it's not easy um why don't we Fork evm.codes

uh do you have like a new Fork there and you know which has like you know tentative or whatever it's like a nice visual representation uh the technical issue is that it depends on ethereum Js um and the forks in there and you know it's kind of messy right um but regarding the informative eips I think there has been like a really strong push to not have anything but technical specs in the Erp repo and maybe people would be more receptive if if we wanted to start such a list uh it to exist in the execution specs repo

yeah that's a good idea too I miss like some markdown uh table or something in the execution specs yeah one more idea is like how to combine both of these maybe if the format is like something the evm that codes can pull into the web page somehow would be nice yeah like some machine readable format yeah I mean I guess I guess maybe I mean even if like the the structure like if this markdown what we've

fixed structure I think maybe yeah it's all Machinery Magnum I guess it would work as well this one may want to take a stab at this you would like to I would not like to I was hoping someone else um give me till Monday I'll take a stab at it if I'm not in it Monday um hold me accountable okay yeah let's record that uh I would really like to have a recommendation for what we want to change T load into store to by Thursday next week for the uh awkward deaths call though that's why I wanted by Monday so we can

pitch it in there and socialize it so people aren't surprised on the call I think I'll have time we'll see Alex yeah you also asked earlier whether anybody anyone has like a strong opinion on where they should lie and I think I'm building up more uh more of a strong opinion that all the UF specific op code should be on the e0 Range and it actually you know frees up or at least solves a lot of these problems because then all those other spaces are kind of free and we can just have you know below then whatnot um in the regular whatever 40 or 50 range

and um and the lastly with the the calls discussion um you know maybe from two weeks ago I'd really like the idea that it's it's actually not related to UF meaningless we discussed um and they they fit nicely in the F0 range so I think all of this kind of solves their problems if we if we move the EOS related to specific ones into e0 okay yeah that makes sense yeah does contract return eof only yes well yeah I agree because I just like take

took a look on the opcode table and uh yeah kind of eof eof up goods are kind of spreaded into different places and like it kind of created conflicts so for example t-store cannot go into like natural place because we took it for eof only instructions kind of the same issue is on the like call whatever so if we like move you have only instructions in like some separate place I think that will solve many like pending issues yeah so I think it's a good idea to do it this way

great any other thoughts on this op code cool I also want to say that we talked maybe I don't know if it was async or last call about trying to get 444 to rename their op code from um data hash to something else and that change has been accepted and merged into 444 so now it's uh blob hash because there's not a conflict with that from eof now uh okay the other topic what was the other topic

we wanted to talk about the delegate call stuff we did not get the blob fiddled hash yeah I mean honestly they're all pushovers we could make it however we wanted to at this point they just want to ship 444 they'll accept any name okay do we have something to talk about on the the delegate call things okay what exactly like the context of

I thought Daniel had mentioned there was something else around delegate quality he wanted to talk about um don't recall maybe I was talking about where to put the call series off codes and I think that was covered in the opco accounting um and that was the clarity is mostly around the numbering of the opcos yeah got it any other spec related things we want to talk about here um yeah actually on this I know that even on the the last school I promised that um we're gonna have like the cold CIP um yeah we haven't finished it yet um but it's it's in progress

yeah I really hope you know we we're gonna get it um done this week so that it can be discussed on all core devs um but we'll of course share it with the team um you know with with the people on Disco um as soon as it's in a shareable form and then we can discuss the specifics including the op code numbers in there sounds good discussions thoughts okay I was just I I have just a simple

question regarding the dupe pen and Swap and op codes uh can we do the same thing for push of codes or push-up codes are two abundance and too frequent to suck to justify that extra byte or the immediate so I think the issue with push in with not pushing with swap hand and do pen is they only have 16 reserved in the opcode table and push is up to 32. and um they want us to be able to swap deeper than 16 in the stack uh we could do multibind op codes with push

but that would be an extra bite and the the registers only accept up to 32 bytes so we've got the full space of push um where that might be useful and I don't think we're there yet is if we need to start reclaiming op code space in a future version of eof so we can um get more space for operations but I don't I think that's at least a five-year issue down the road to be honest true yeah makes sense thanks let's move on to testing updates I know

Mario sorry go ahead Alex do we even need any pushes besides booster we would at least push one right or Inc or incrementing oh you're right so we could just Define push one in terms of increment all right that'll be a fun mapping oh but we don't have an increment operation yeah it's very like client go ahead

oh good uh yeah let's move into testing um I know Mario has some some things he wanted to talk about do you want to share what you guys been up to Mario well yes it's not much I just started last week on updating the python tests to for UF so basically I have this Branch where it has all the um python modules and constructs to easily build and compile EOS containers and I have just made this to the mega UF um but at the moment I haven't been able to test it because I require the get um yeah to get to get minorities to be able to run this this tests

um and yeah basically this Branch I will share with you guys is not ready um it has most of the construct but not every single one and I think it's compiling uh EF containers correctly but and I should be able to write more tests uh soon as as soon as I fix all the remaining issues with the crossroads um but Jessica yeah basically this is work in progress but I think it's going to be very valuable in the future that we can use um we are currently migrating to buy tests from python to from basic python to python so what this does is it brings a lot of parameterization and utilities

to easily write yeah in like a parameterized way so you can for example if you want to write a test for the stack in UF you can basically just parameterize a single test case with all the op codes for example and if you have the number of Stack items that each upgrade pops or pushes into the stack you can very easily just um iteratively just create um automatically accurate tests for all see every single lab code in in in in by this format um so yeah I think it's going to be very useful for for us for for eof neuron to make very quick changes to tests and

make the best adaptable to any packaging that might come in future um this is not done yet as I said is as working progress but I will keep you guys updated um one thing that I noticed while writing the container the container module in this python construct um so yeah basically we have this EOS container construct that it makes it very easy to to build EF containers inside these tests and this thing is um you can you can put containers inside containers and it will basically construct the entire back code for you

automatically with whichever code you want whichever sections you need it's everything is very automatic and very easy to follow um one thing that I noticed that it's making my My Level a little bit harder and and it's not it's not complain I just perhaps wanted to know the reason of the of this is that the header and body order of the data and container sections is not the same and I mean in the other antibody and I this is this is a minor issue it's just I just wanted to know if there was any reason why the order was inverted in her in the header and body um but apart from that it has been is it has been smooth to update from the the

previous version that I had a few months ago to Disney new mega eof version yeah basically that's it sweet anybody know why those fields are inverted you mean the order of sections on the header and in the body is different yeah exactly um I think it was a typo in this book and I fixed it since then oh nice okay then yeah then what what's the correct order data is the Indians perfect okay thank you

yeah and I will give you guys updated on this on the state um I I will work on the following week weeks on this new branch and I will I I want to prepare a guide on how to write the tests and maybe I I'd like to present yeah but this is ready uh to for you for you guys to see how easy it is to to write a test to modify a test or write iterative or automatic test cases with this um with this thing yeah that would be really awesome thanks for that update Mario yeah I have I have something to add um

so uh one thing is that uh evm1 was was getting support for this common line tools for test generation in specifically this t810 radek from our team we're working with Spencer for your own team I believe and uh I think they got it to the point that it somehow works um so I think that's is in the context what you said that you need like Gap update updated and maybe that's not needed but yeah we can figure out um later

if that works if you can include the vm1 as the like driver for for the test uh generation and so on yeah definitely so um to give a little bit more context we are in the in the main branch we are currently making a switch from uh normal vanilla python into pieces um but this I think once we have done this this conversion I think we can focus on bringing evm1 into the um set of Builder tools that we can use to produce the best definitely um I think it was yeah as you mentioned I'm not sure

um if inspector had that already implemented but I think it should shouldn't be a big deal and should be doable rather quickly once we finish with the python version yeah is ethereum JS in the current set of tools that are accepted no they correctly how we test ethereum BS is um um we output the test the the blockchain Json fixtures and then we break we pick them those up in Hive and then we'll run with either MBS um yeah that's that's the only support we have right now because in my work on the T8 Java startup is not that hot and when I was

working on some girl stuff to try and speed it up I don't know where that went but there was also requests from um Dimitri to include the um the batch mode uh server that I guess ethereum JS was implementing I wonder if that was figuring into your current tooling or not so that's why I asked yeah I think that that will come in really handy because I'm not sure what the status is but I think I suggested something you want to forget because right now for 48 before there's an issue where every time that you bring up the EDM tool it has to load all the um this um this very big array that's related to the to the kcg commitments and all that stuff so it's taken up to a second which started so to fill the test

it's really really hard so yeah if we can get some support for batches operations in the cm2 whichever ebm tool it is I think that will be very awesome very very great okay for base it'll probably be a variation of t8n since that seems to be the standard I think we can we can put a sunset on retesta awesome and you want to have other testing updates they want to share any other elf things in general though

we didn't get the cover yet hey uh sorry I've been a bit AWOL for the last few months so I haven't been uh really up to speed but I've been thinking about the stack validation rules and about outlining instead of sharing code but I think I still need to think about the

issue a little bit more but I think me and Daniel spoke about this in the Discord a little bit I'm wondering for for duplicated code that would normally just be collapsed um do we need to use jump F or call F going forward that sounds about right and I think the new phrasing of jump F would allow you

to have stack inconsistencies if you're jump effing to a terminal thing like raising um a revert oh I see uh is that new added to the spec I think that's in the new um jump F and I know we discussed adding it we got plenty of time to add it if we need to if it's valuable to have jump that um disrespect to some of the uh stat conventions if it's for for functions that are terminal because there could be cases where you kind of want to share code that are not terminal but um maybe maybe that means you shouldn't be using

your math right right we the uh the stack validation rules are going to make a lot of um transpilation options um linear time which makes them feasible in client infrastructure which is why I don't really want to mess with the um the call F semantics but it's the jump F that um this terminal will return it won't destroy the stack uh assumptions that have gone with it is why it's it's valuable for jump F and possible for jump f M yeah so just jump F and this is combined with this um non-returning function so it kind of

I think um yeah like um make some restrictions um invite them like you can skip some restrictions this way but this kind of works as you as you noticed um for the sleeve code blocks and for like kind of branching code we discussed that with uh with Daniel I think months ago and um oh there's one more there's one more simple change we can do uh which doesn't

really solve the problem but um now you have to be like very specific about the uh the the stack height you put in the in the UF container that can be kind of um made Let's restrictive if you just obeyed like inequality this way so like you put some number and you have when you validate the the computed number must be below that limit so we don't have to precisely compute it but I think that doesn't really affect compilers so much it can be useful for like people that want to write um some up codes by hand and yeah I can can put some arbitrary limit

but there was also like a second suggestion I think there are there are cases when when you can modify how this validation algorithm Works in a way that the stack height it's not exactly the same at every place but at least they are bounded and at least I wanted to what I wanted to do is like present the problem as the like document and like how it works right now and maybe like people can collaborate on how to improve that in this context but not so much progress has been done on this yeah I mean bounding the stack high is not

as clean right in a lot of ways and the problem with the bounce stack is it makes the trivial mapping the registers more difficult right when it's a fixed deck it's trivial when it's balanced you've got more complex logic and operations right and then like you can always just do something really horrible like force the bounce the stack bound to just be one 10 24 all the time which doesn't really improve the situation from where it was before I mean yeah um no I don't think it's it's so bad uh but in terms of like mapping the registers like

yeah I mean that's why I kind of wanted to write it down and like to see how it works I think it's also not so bad but can't we prove it I think it's it to my kind of limited understanding of of like the Practical use of that I think the fee notes that kind of translate different registers between basic blocks kind of work with this but yeah I've definitely would put um put um also like requirements to make it work for this this transpilers or whatever right so we don't want to break

it in any way uh but I think it would be nice to yeah kind of present the problem and uh and be able to collect some ideas how to to maybe modify it in the way that it just allows more programs to be written right so um yeah but I said it's not so much done be above the like Discord discussion so far um I think Daniel you were saying that for Jump apps to to

cyber teams which are which are terminal then you relax the stack height restriction but how do you know if it's terminal um if all of the exits from the function are stuff like revert or return or stop if there is a return F calling it then it's not terminal it returns do we want to do something restriction for any terminal node do we have to write up it becomes less clean because then we'd have to introduce a new class of

functions that are non-terminal functions um is there can we quantify what we would gain and lose by um relaxing and changing it in the solidity code I mean how much how much space reduction are we going to get by removing these duplicate nodes in production I guess would be one question I would have well it's not just a celebrity that people are I I work on viper right and Viper but as far as the optimizers what's what's the impact from an Optimizer step I think that there's I I have to think about it but like

if you're optimizing for byte code there's like kind of a lot of stuff that you can't do if you can't collapse jump destinations and I haven't thought about this in a few months but you might be able to do it with subroutines but I'm I'm not sure [Music] it's been a while since I was working the implementation too right because if we're talking one percent I don't know if the value but if we're talking like 20 to 50 then absolutely um it's between 21 that the real question happens I think the issue is more byte code size

right button size if we could save one percent by code size is it a big win if we could save 20 50 by code size absolutely let's do it but if we're talking like two to five you know is is it becomes a question of um effort versus return because right now the way it's written it's very simple and simple stuff is easier to prove um it's easier for implementations to get right the simpler the spec is that's one thing I've learned in these multi-client situations if we keep it

simple as possible there's gonna be less opportunities for um consensus failures the more complex we make it um I think our most recent consensus failures are around Net gas metering um the more likely it is bugs will pop up in different implementations um so there's also the the goal of let's keep it as simple as as reasonable but that's you know the question of what's reasonable where does this you know that's where engineering happens what trade-offs do we make so that's that's you know why I'm in favor of keeping it as simple as possible is to reduce these these consensus failures but there's other value brought in and we can increase our testing coverage um to reduce the consensus failure risk in proportion to the specification risk

that's something we can consider but is the return we get from it worth the increase in the test coverage on the testing effort so that's a lot of things that balance into it which is why some sort of a quantification of you know a lap restricting the stack height checking on Terminal functions would save us 80 code then you know that would be great I mean that's no one's going to get that in optimization but that's you know the sort of numbers we would want to get on code size because I think code size is going to be one of the big pitches that I think will there are still some Skeptics on the main all core devs call you know what is this going to do for the consensus clients um but I do think that being able to say that you know getting rid of jump tests

will will reduce code size by 10 we'll we'll turn a lot of heads and I think that some of the numbers we're getting back from the solidity team is somewhere in that neck of the woods I think push zero already got they already documented number I forgot what the number was but it's something on the order of two to five which was not not trivial it was a good number to get right well push zero is never going to increase code size I'm concerned it's going to decrease it right yeah I need to think about it more but

they're I'm pretty sure those cases that may be pathological but that where code size does increase and we I don't really want that I don't think anybody does yeah we don't want it to to grow in pathological cases um but that's why we have things like maximum code size the pathological case means you got to reconsider your code before you even deploy it so the pathological can't get too large with a 48k um init code and 24K runtime code so there's already limits it's going to hit quite early when it gets right I mean there may be

even cases where it's not pathological but uh you're not able to take the same bytecode optimizations so the code is bigger in UF than pre-eof right and those are those are numbers we need to know foreign do you have code working that doesn't optimize yet um I'm thinking about it I haven't done comparisons yet because I think that's what eof is gonna the updates to jump off

all right I think that's all unless we can talk about that for now sorry about that oh good glad to have you here we usually do like compiler related updates as the second thing too so would be glad to hear more of your guys's thoughts and things that change in that case I think we're good to go

ahead and close this call um yeah let's try it again in two weeks uh talk to you guys later and then we'll be on the lookout for the Post by Dano hopefully on Monday or so next week about the op code layout so we can talk on all core devs next week about uh how to change 1153s op codes so that's the main thing have a good rest your day bye thanks very well