EOF Implementers Call #29

Transcript

hey everyone uh welcome to the eof implementers call I think this one is 29 the last one I put last agenda I put up was 27 and I'm pretty sure there was one in between somewhere that I didn't have an agenda for so we'll call this one 29 let's just jump into updates from people do any client teams client devs have updates on their eof implementations ISM one call on the call I know I think you said evm one right

yes uh yeah we are um do we have any updates in terms of the implementation I don't know we've been trying to follow the the spec clarifications that we've done two weeks ago and you're starting to Output uh reference tests generated from your local tests I think that's worth noting that's going to be very helpful yeah yeah I think that was Pavo doing this but he's not here Bas who's been following the reference tests and um been mostly chasing down some security reports um unrelated to eof but uh over Christmas

I'm going to do like last Christmas and focus on getting testing and on up to-date implementation um one concern we have is um op code allocation for some of the things on the to-do list you know what are some of the op code numbers for some of these things thanks uh that's I guess our two clients here um comp any compiler updates uhand cool spec questions and updates um I don't have any updates but

I heard on the last call there was some discussion about return data load um and um yeah I think there was some confusion about what whether there was consensus on it but I think that my understanding of the call we had the other week or like now two months ago or something with solidity is that like yes we um all the Comm teams want return data load I think the question whether we zero extend or whether we violate on boundary violations or whether we fault

on boundary violations um it should have the same behavior as return data copy yeah for return data load I have we have the notes that the concern is semantics of out of bounds I just posted the link in the in the chat either way is fine it just seemed like it was the opportunity to go back to zero extending it because that's always a subject of all of the solidity and evm quirks panels um or if we should stick with the old fault on um boundary

violations um I'm cool with either I just want to clear commitment to one um Daniel in Discord and make a decision I I don't care too much it's fine either way I think um the zero padding is a little bit more future proof and we still charge for the proposed link um so zero padding won't

become an attack Vector right sorry what the uh cost of the copy um we're going to charge up front based on the expected length and fail before we even try and allocate memory correct let's say it's out of gas and they ask for a billion copy uh I mean if it's out of gas it doesn't matter if you touch memory right right right so we charge gas based on memory and we check memory before size that is the only um argument against zero extension and since we take

care of it I don't think it's much of an issue wait I don't actually understand uh the there's memory expansion for return data copy but none for return data load right but we would still need a the amount of data you're copying um let's say you're referencing something that's one bite but it's a gigabyte down this down the line well zero extended would be a problem because you can figure it from the end but if you're allocating um a gigabyte of memory that you're copying a gigabyte of memory we'll do the Z memory expansion on the

target there um I just want to make sure that if we do zero extend it's not going to open a um out of memory and resource exhaustion attacks but I think the gas um and smart handling of it would take care of it because if you're going to do a large return anyway you're already paying for the memory space for the return higher up the stack so it will be gas limited um to whatever your gas limit is to what you can return so that will provide resource protection so I just yeah that I think that's the only argument that could be made against zero extension and I'm fairly certain we're fully protected against it because we would have been hit by this way early in the ev's Life are talking about return data copy yes I mean it would just be the same gas check as call data copy or

code copy yep so we would behave exactly like those yeah I think we mostly were not clear about return datal load out of bound semantics we didn't want to change return data copy which ex boards return data load should do whatever return data copy does yeah I think so too yes so it will be exception but I think the question is whether uh both should be changed yeah so like that would be unprecedented in

terms of changing existing instruction into something else in e that's why we I think didn't want to do this so let's advance that they both have the same behavior with just a faon extension um and if there's strong push back we go back to zero extend on both of them um I think there was also maybe uh well

is this topic done sure um I think there was also maybe some discussion about compressing the the length encoding for um section headers and I would just like to advocate for that because I think that's uh kind of important for code size it's probably like a 1 to 5% win I think depending on the contract [Music] um which is important since we're in a constrained environment yeah I pitched for Leb

encoding or something like it last week too for actually not just the header but all op codes but even if we can just get in the header size will be fine but also my header concerns are um that we have for for fragmenting that we have total sizes but we need to be careful how we do that because we don't want to constrain the size of eof to 64k by using fixed length so if we were to put the sizes in the header it would need to be a variable width size as it is yeah I agree and if we're going to be using variable um size pointer SL length then we

should in my opinion do it everywhere for reference that's exactly what move does we could actually get rid of all the push instructions if we did that I think we'd see size regression because all the push instructions would go to two bytes um sorry I don't understand so push is one B plus the whatever data you're putting in and if we do push and then

size and then data I'm concerned with CSI regression no I think we use the what is this called like the zigzag encoding zigzag is for negative values that's for relative jumps yeah lab is also one bite for values below 128 I think or maybe yeah there some limit yeah Leb um unsign Leb is up to 128 for one bite

I just m myself there there must be some encoding which um doesn't do that right so Leb has a signed encoding which is 64 toga 64 in one b um it would basically be seven bit bytes in the high bit would be the sign protuff does a zigzag um where they put the sign bit in the zero and the rest of it is positive and negative and z and Z is zero so so ne0 becomes negative 1 it's still two complement they just move where the sign hides um yeah so there's this vlq thing

which does um a continuation bit I think you I think Leb is just a continuation bit I think unod is the weird one with a full size in the first bite everything else is just a continuation bit in blocks of seven right so I think in general you just get a 1/8 overhead so like if you really wanted to push 32 bytes you would end up with um 32 * 8 over 7 right oh move the continuation of the

whole push I see what you mean yeah yeah so push accepts a compressed integer so so that would have a um 12% size bump probably because everything would then go up everything Beyond one bite would go up and there's a lot of addresses that that are pushed in a lot of hashes yeah yeah yeah okay but it works for um code offsets for the mediate AR like um R jump if R jump was an Leb signed um there is a lot of I mean most jumps for

64 forward back um it would it would result in a lot of code size savings there yeah I agree so I think that's a desirable property to have but I think because some of the people I've been talking to on Basu who aren't all in on eof their first argument is what does this get us today you know everything's all Downstream and and if we can pitch um 5 to 10% size reduction um is what you get today that would be

very persuasive at least the app developers but I think more important than the lower size reduction is the ability to safely uncap and I think our code validation gets that and that might also be something we could sell with the current situ with the current structure of the headers without changing anything any opinions from Epsilon on

this yeah nothing substantial just it just feels like a big change to entire spec and we are at the point where we should finalize it as soon as possible if we want to make it to brog that's basically why I'm reserved about this um I actually don't think it's a big change to the spec and it doesn't necessarily add a lot of complication because there's good libraries for um doing um these various encodings

yeah I mean yeah incing itself is not that complicated I guess it's just yeah a lot of implementations need to be changed in all of the tests and yeah I'm not sure I'm not sure so what else is on the agenda I've got

nine minutes before I have to go yeah I mean I think that's about it there's probably no testing updates was there any other things that people want to talk about that we didn't cover yet does anybody want to talk about Prague or have we beaten that to death I mean I think we want to ship in prod I think it's not a discussion for

this room because everyone's kind of aligned on getting there um we can argue about the finer details but I think we'll all align when it's you know ship or don't ship I think the bigger discussion is going to be in allore devs in the verl tree versus eof question and the question for me is when will verl actually be in a shippable position I think honest my my honest take is if verl can get a compelling story that they're going to ship in Q3 we're out but if they're going to start talking like it's 25 q1 we're in it's Q4 that it becomes tricky yeah Q3 sounds unbelievable from my perspective

but yeah I think there's no chance it even ships in 2024 to be fully honest I I'm just guess I'm curious if anyone else has been talking with teams or people to see what the appetite is and I mean obviously everybody wants to ship eof in Prague but we still have to make it through the allord devs process so Bas is a little split but it's split amongst Engineers who work on vertical and Engineers who work on the evm um which I think answers one concern which is we split engineering interest and we've got of you know everyone that

we need to on both sides of the coin I think what Andre mentioned is it's quite important you know we're still considering changing the header significantly if we I think if you want to be successful in front of all cevs really have to be decided on you know semifinal details we we cannot just and then a few weeks after it changed like a significant part of the spec I mean yeah I don't think you can even come to allord at this point and not have a quote unquote finalized

spec I would not even mention that there's really openness to changing anything because the feedback is just going to be you know eoff was presented over one year ago and there's still questions SL things to change why will that be any different in six months as we're trying to ship it onto the fork obviously think will change as if it's accepted and clients start implementing there'll be small things but we definitely have to have you know this header stuff sorted out before January what is the current plan

for Cancun as in ship shipping yeah uh I think the idea is probably around March now for main net going to try and do girly as soon as we can in January so first couple weeks and then twoe Cadence but Tim was talking about having some of one of the first out Court devs calls next year talk about Prague some Prague planning and it's probably going to be led with priorities so we're going to ask like what is the priority for clients right now is it to ship veral eof there's also some chatter about things like inclusion lists because you

know 93% of blocks are coming from censoring Builders so there's other competition but that's probably going to happen in the first week week two weeks of January and so eof should be ready by then to be a contender seems like a tough plan again given the holidays so the The Proposal is we stick with what's proposed for Prague um which I think is gives us the advantages we need it's not perfect you

can always change things um I think we've been changing things mostly because we've had time um so I'm okay going with it as is um but if it slips out of Prague into 24 I think we revisit the um the variable sizing if that's going to give us a full Fork to mess around with um but yeah if we need to commit in January large changes like this would have need to happened three months ago yeah just some things to consider I

guess anything else before we close out yeah what is the the plan regarding the calls given the the holidays yeah the next one is right after Christmas the 27th so I probably won't be around that day but yeah I mean I'm not the blocker for having this call because the zoom meeting is there and if you guys want to meet up you should definitely do it should we try to have a call next week to make up to to ro call and um and then well I guess then we break

the the cycle with Cavs but yeah what I was going to propose have one next week and then uh two weeks after that so the third but yeah I guess I breaks it with EPS in Austria on a family vacation on the 3 so my availability for that date for call is very questionable I'm available next week I've got a conflict next week but I can set the meeting up if if you want to do next week too yeah how about we do one next

weekend then regular schedule on the 10th um sound sounds good it basically means that the call on the T going to be kind like finalizing all details right if you going to meet that deadline yeah cool let's let's plan on that and we can chat more on the evm channel if some other things come up or we want to have some sort of ad hoc call in the meantime and I'll set the meeting invite up for next week on the protocol calendar awesome thank you yep uh thanks

a lot guys have a good rest of your day thanks bye thanks