EOF Implementers Call #20

Transcript

hi all welcome to the eof implementers call number 20. let's just go ahead and get started with some client updates does anybody want to start us off um basically I'm working on implementing create three that I think that brings us up to parity have a community that won't be until next week but it'll bring us up to parody with evm1 um that includes the renumbering of the code sections um you know with some of the things in flux as far as changing the container ordering and op code numbering I don't know that there is a single unified um spec most of everyone's been

implementing to um so we're not you know like like all the other clients I think we're stuck in uh dencoon um in rep mode so there's not able to get too much um time focused on this right now is the Mega eof spec not what people are targeting is there like changes to it that haven't been reflected um not everyone's implemented all the changes um there's also some changes that just went in with stack height that um are proposed and haven't gone in for final yet um so it's it's still a bit in flux we haven't had a big uh interrupt hubba around a version like we did back around

December January okay but there is a spect version that people can be implementing to right not everyone is up to date on that okay okay that makes sense great other client updates cannot hear you if you're speaking Andre I just don't know

uh well Andre is working on his audio do you have any updates I'm in amazing um okay let's just jump to compiler updates and when Andre comes back he can say what's been going on with evm1 anything on the compiler front uh nothing for me cool

that's probably it for compilers Dano I know that you've got a couple things you want to discuss on the spec do you want to go ahead and get started talking about extra data um sure I was hoping to get more of the um the Epsilon team and other people you know right involved in the theoretical parts of it um to get considered this around adding EXT um EXT data load which is something that has been requested to make it easier for the um the s store 2 Community I think is what they're calling I'm not sure what they want to refer to themselves as before they're using contracts to store immutable data do things like put Vector

art for nfts on chain cost efficiently um so uh I guess there's not much that can be discussed on that and since there's really not much room to get consensus on and buy-in from Epsilon are they out this week will they be back in two weeks or is everyone in Den Con in in in dencoon Burnout mode no one's not from Epsilon are they I'm from Epsilon dot networking now uh currently on eif but uh answering if we'll become back here if you will he will have some update and yeah but this

week we are mostly mostly off um and I think next week we will have better availability okay um trying to find where the the Gen items I added were I've got so many things with juggling right now is also the other problem so the uh I pissed the issue in chat 838 so the first one was the EXT code data and the data op codes um I guess that's another question for Epsilon does anyone need help writing it um is it coming along is it yeah yeah so we need to get some final specs out and then finally my last

question was about the proposed stack range change that um Viper was asking for for its uh outlining to see if that would have been sufficient so you got to get a progress statement status on that because from looking at the spec it feels like those might be last issues and then I think we can look into um starting to pack things up and and ship it um or at least you know do a dress rehearsal for shipping it and make sure that that's everything the community needs so that's that's my take on it I don't know if other people think there's other things that are broken or need to be revised or need to be um updated with their opinions and

thoughts on this are because if we get the stack range change we may not need qualify and um jump fi or maybe we do that's why I need to hear from Viper from Viper's perspective well I was looking at the the thing that Andre proposed and it's yeah I I think that um I think that the allowing forward

um yeah this forward jump thing but not the backward jumping feels a little awkward from a design perspective um but I I if it works it works I think the main issue is going to be with the red f stack cleaning thing so given all of the options so far and given that I also haven't made that much progress of Pavel um on the camera outline everything entirely um just because of bandwidth reasons um call Fi and jump the fire looking like probably the the easiest way to move

forward here uh unless we we do make some progress on this okay and I'm fine with that status we don't need to push it to resolutions today I'm just mostly trying to keep a running list of what the open issues are and as that list approaches zero you know once it's zero and we have answers on that I think we could say that we're we're ready to propose a shipping version of it so enough more issues come up don't hide them bring them up I think we should still be tracking alternatives to create three or where it can take potentially in external address

init code at an external address and uh this doesn't uh this isn't like a deal break or anything but I think it would be nice uh if if if init codes were were validated when they get on chain for the first time instead of I mean I I think that's just more efficient for all if they if they get validated the first time instead of every time and uh create is called so you say validated knit code first

time they come on chain that would be if it's in a sub container or just when it's in the transaction and you catch the results no when it's in a sub container like I I think that it'll that uh maybe we just needed in a Nick code kind section kind so I kind of went with that with creative and um I think the problem we get into it is you get into the net code um to run the init code you need to know specifically what the address is that you're developing to so that would involve I mean maybe it's not a bad thing maybe the address is still going to be a

function of the contract of the of the factory contract and the um the section that's the init code versus you know that's going to be the thing to make it unique if you have different init codes to call that a knit code oh why do you need the address that it's deploying to in order to to validate it because you well not to validate it but to execute it yeah you can still call the address op code inside of the net code and it's supposed to return the address that you're at yeah sure so we would need to have in that spec so that's why for my create F spec I would have to drop the return the split returns because you wouldn't know you know the key Parts the address would

come from whether you're returning from the container returning from something external Source you still need to know where it's coming from yeah so so that's that's one of the issues yeah so that's still open on it and try and maybe iterate on my create app to see if we can get something there but that was the issue I ran into was how do we Define what the hash is going to be for the derivative address and make sure that it's got the right kind of protections you would want to see from create two or probably safer possibly safer than create two um I don't think we can prevent uh well we're getting rid of self-destruct so in one way we can um but prevent uh multiple contracts being ex being deployed possibly for the

same init code based on call parameters um you know because the idea is that the original create two proposal the idea was you would put some money at a remote address with a fixed hash and you would have certainty as to what it is and I guess the argument there is to go read the init code you need to make sure it's not polymorphic and make sure it's only going to result in one so that just increases the level of knowledge but those are the the concerns that I would want to see resolved for this um you know create copies easy that's you just point to the address and that would be part of the op code but you would need to have the address resolved and solid before you start initializing running the first operation of the init code in case the first thing

to do is ask for the address so that's in those proposals that's one thing we would need to work on yeah I'm wondering if you can do something which is just like validate the outside container if it has subcontainers that's the current proposals you validate the outside container and then when you I mean a good person sorry the first the first layer of of DNA yeah I mean oh see just just the first layer just the first subcontainers but you don't validate Sub sub containers right yeah exactly the the if you see anything which has like section kind init code which I'm not sure exists yet

but I think it would be useful uh to have that distinction between data and um sections in the code sections but if you see those then you validate the outer layer of that thing and and I think that would just save a lot of gas at runtime because then you don't have to run the validation again every every deploy yeah let me think about it while I'm on the plane I think there might be something in Creative I'll have to think about all the implications on it yeah and then it's nice to have would be

uh be able to to deploy from a net code that's not in the current uh contract but from an external contract so in an additional address parameter so you want both unit code in the contract and be able to reference an external contract with your net code it's not a showstopper but it's a nice to have couldn't we do that with a factor pattern that's why I said it's not a showstopper but yeah it requires a special

Factory contracts and so on all right I'll add that to the still open list uh call Fi create optic code where we copy external contracts by address validate subcontainers instead of the of yes or no solutions to not having to double Nest containers for factories along with EXT data copy and stack range all right so I love that I added that to

the agenda is still open items okay unless unless we have like a Powell or some of the other um original here now I'm actually Foundry on here should I start up with my beginning of my list again then go for it um one thing we discussed in the past few calls was a need for EXT data copy uh in the data op codes this would make the job a lot easier for um contract storage based Solutions

um rather than having to go through an interface ask for the data through the RC method I know that was initially deliberately dropped from the spec um how strongly does epsilon feel about adding it in I personally am slightly against just to you know to increase the scope but not super against especially if someone else works on this pick Asic yes sir I've been kind of out of the

loop um for various reasons I imagine the this is actually dissimilar to what we discussed in um well I'm in advice yep yeah that somehow we get a native code into an account and then you have the instruction to deploy from the decades right oh so this is a separate issue I started back at the beginning we're talking about XT data copy we also talked about the create copy issues is a separate one that uh Viper was concerned about but I was starting at the EXT data copy op code yeah I mean yeah I have no no reasons against it the only reason I left it out

was just for the scope so the next point was if you need help writing the spec if I were to write it it could go in is that what I heard from Andre yeah yeah okay the big blocker is right at the spec so I'll add that I'll add that to my plate then that I'll I'll do a first draft on the uh data op code ZIP unless someone else already has a draft that they're working on um cool stuff goes back huh just I didn't like a soft pushback just generally to the notion of

increasing the scope because um you know we have been um so far unlucky you know um to to get this in two minute and I guess initially we did start with like a release simplified stack and and then you know over time we extended it and now we're getting into territory where it's gonna be like I don't know 25 instructions um some kind of worried that uh our chances are are getting even lower um with all of that um long story short Maybe maybe the best way if I mean I did miss like the first 10 minutes so maybe there was like a really strong reason that we want X data copy

but I will probably put it into like a separate optionally IP that specific instruction and or at least emphasize that we can launch without it um because we have to have the data copy ones that's given so I could put EXT in a separate file and that could be Advanced separately um because it's yeah I definitely like the the notion you brought up you know months ago that uh if somebody wants X data copy they can actually have like a maybe like a five um in the contract to perform them right with a call um okay did did that notion change

there was concern about gas optimizations yes and we don't have too many real world examples so if we have two eips going forward one with data op code and one with ext data copy um then there's a possibility is it me um I'm willing to write these if time's the issue both of them or one of them just the XD data copy and you have the other data op codes either way just let me know what what would help and Alex's internet just went out I can work on data code spec this week

okay except next so I'll write a separate one on EXT data copy and then we can advance them separately and see what the appetite of all core devs is and then the rest of the open issues that I pasted into the agenda callify jump fi again there's the meta concern about too many op codes um create app code for external is the same open question about validating subcontainers instead of the UF containers currently the spec is no validation and you validate when you use the the stuff pulling out of the

container yeah so I think those are still the open issues yeah validation I also have to think about because somehow we rejected this idea in the beginning in in Austria yeah so I have to remember there isn't still um you don't have time to to remember so I'm not sure maybe it can be possible of about qualify and jumper fire I had one question or

thought that it so far on the jumper if I make sense to me because qualify if you call a function with outputs what would it do in case it's not that's a good question I think that it should only be allowed for uh or other returning zero things that don't modify the stack right I mean is it needed at all maybe we can do a jumpify only I think I have to double check because we wrote Our code when uh jump if I was not on the table and so I need to check

if it violates the assumptions or something okay because I thought these are only needed for like outlining reverts so it jump you would jump into a terminal function anyway so you wouldn't need a return uh right I'm not sure if if you can use jump fiber for that or if you need qualify uh probably you can use trumpify yeah because if the only if the only exit from the function is a revert or a return then there's no need to call our Red Death yeah uh I think qualify is is okay

um power only if it doesn't change itself because it's very in that way it's under your way it's like very different from our Jump by it doesn't actually affect control flow it's just conditionally jumping into this function but like the next instruction is going to be the next instruction right there's no it doesn't actually conditionally change the PC anything else that Epsilon wants to

share voice concerns about or open discussion about at least not from my side I just wanted to give a tiny bit of update and in the sense that I think we have been mostly focusing on uh evmx and reports related uh to that if you're not aware of what evmx is it's

a very simple instruction um set just three three four um and it makes it possible to implement a lot of the pre-compile elliptic curve functions and I think you're probably going to get to the point um in a monster um that we get back to the US part of that it's we're trying to implement this on the EPM directly but what instead of what we have done in the past few months is um using the same Primitives but implementing all of that in in C plus um just to validate the

uh the idea that those Primitives which would go into um being given instructions um those are actually enough to implement the actual pre-compats and and I think we did prove that and so like a second stage will be to actually move that over to evm and and then the UF requirements are the discussions together why is that there would be probably some kind of like a setup section or a different kind of memory Etc um in any case I think there there will be more uh connections of of this work with the UF work at that point and

I think this this may be the reason we have been uh less we had less output on the us because we put the effort into cvms in the past few months so would your evm max be required in the first revision of the of or could it come in on a follow-on revision how tight is it no it's it should not be okay we we don't want to make any more you know complications into EOS okay so it could Target Osaka and eof could Target Prague exactly all right so that brings up a meta question how do we want to proceed in advocating this to all core devs

do we think it's ready enough to give a presentation like vertical trees gave do we want to wait until after duncoon to have that presentation for UF or evmx for eof so so vertical trees I mean people are familiar with purple trees and they gave us status update uh all core dabs do we want to give a similar one just for eof or maybe for eof and EDM X or maybe two separate ones to kind of um advocate for a position and make sure that it's on a schedule or do we just want to go straight to um putting it into the when we start talking about Prague stuff proposing it as the headliner no I definitely like the the idea that

we should we should start advocating for it yeah because we did here you know a number of times that stuff has proposed late and why is it even considered and yeah I mean there's only so much space left in in people's minds regarding what is important and it's in many cases a game of uh what do they hear about the most right so yeah definitely should start giving updates about the US and just to to have it a discussion point um is this a presentation we want to give in three weeks or five weeks I don't think we want to go into next

week's awkward devs I don't think there's enough prep time for that although I'm willing to be persuaded against it I'm wondering if we should propose for three weeks which would be the beginning of September or middle of September and I think more people will be back at work in September I think it'll be better then yeah now it's just cut out again so this is something I think we could actually mid-september sounds good I think this is something we could coordinate on the Discord channels um you know also the issues of who gets the biggest present who presents probably Epsilon um and uh what the content of the slides are um because I think you know prague's really starting to

want certainly once we get test net dates picked out for um Dan then we can really start shifting into being serious about focusing on what's on Prague I think this is the right time to start bringing some of those discussions up and Asics go switch devices um so I think that's my my meta questions and my con my uh issues I'd like to see Advanced here and do we wait for Asic to uh switch devices still listening okay

it feels like maybe closer to five weeks would give us a bit more time it still feels we're pretty deep in the thin cone uh triaging even like in three weeks I don't know um eip663 is going to be part of UF yeah I think we've learned to roll out together with your small requests um basically hasn't implemented I think evm1 hasn't implemented yes uh because I uh think that

663 probably needs some changes in I think for it to be really useful it needs swap NM instruction which one swap NM swap the nth n amps items in the stack oh swap NM and there's uh by the way I don't I I don't since uh my understanding now is that um future UF versions are the strategy is to try to transpile them like so elf V1 if you if we have ufe2 then we're going

to try to transpile from V1 to V2 then uh I actually don't feel as strongly about uh dupe n swap sorry dupe and starting from from one instead of 17. Eamon says what is Swap and M useful for it's very useful for stack scheduling when you're when you're scheduling items on the stack you right now you need three Hideout three instructions to to schedule things that are more than one item deep in the stack you can yeah Swap and and allows you to do that in one instruction

and I mean from the the you know implementation you can kind of see that it costs the same amount from uh from the implementation perspective um a little bit of a tangent as far as the transpilation my thought was that the transplation would only be necessary when we do a breaking change like let's say we get rid of the swap X and this in the dewback series of operations and rely on Swap and dupin that would be uh incompatible change that we could transpile into but doing things like adding new

operations that don't break things are what I would turn forwards compatibles or the full set of valid eof programs um is not reduced but only increased those I would consider forward compatible it wouldn't require a version change would require transpilation we just treated like we've done it before we just add the new operation we update the code validation rules what used to be invalid is now valid so you know adding an operation like swap NM or EXT data copy wouldn't require a major version ever change so yeah so that's that's my my thought on the need for transpilation so like the desire the the product management

thing of making it the smallest necessary change and then bringing in these other changes later like swap NM and the XT data copy I think would be the more prudent one um I am persuaded by Alex I do want to see EXT data copy but not to the point that it causes eof as a whole to be rejected and it you know by floating the two separate proposals and proposing swap in them later that gives us the option of either bringing it into Prague if people think it fits in or bringing it in an Osaka when you know there's there's more when it's already in and we're just growing it to increase to improve user experience and the uh the compiler experience and

making it more accessible from my perspective by the way swap NM is more important than all the other instructions in eip663 yeah actually if yeah my concern with uh dupe and starting from 17 is if we start to remove other dupe instructions um then tooling then tooling will have to maintain like we will have to be able to deal with multiple versions of UF um which is like not the end of the world but also not really ideal so it I think it's better

if it's kind of more future proof from the get-go but it yeah it's also I mean I think Daniel and act six uh concerns are like yeah now there's like duplicate instructions basically which is which is weird so the mega eof spec has dupan without the 17 shifting so there is in essence a duplicate set of instructions it's the immediate plus one and they swaps there's no 16 base Shifting the same with swap there's no 16-base shifting according to the mega eof spec

yeah and I think that's something that I requested from from accent and well I'm here to say I don't feel that strongly about it anymore but um yeah the issue of of backwards combat forwards compatibility is yeah I I don't know really what what is the right call here so maybe leaving it as it's just fun I like the way it's coded right now so in case we get rid of it in the future the transpile burden if you're using the old dupe code so the old swap if using duplex or swap X those just get transpiled into a two by instruction and the existing dupin and swap in stay the mild preference totally willing to lose

on it but that's what I like about the current setup any other questions should we give people 20 minutes back

it's good with me any last comments thanks a lot guys we'll talk again here in two weeks have a good rest of your day thanks bye thank you thank you