EOF Implementers Call #17

Transcript

hey guys welcome to the eof implementers call number 17. it's been about a month since we've had to chance to chat so looking forward to hearing what you guys are up to maybe we can get started with some client updates from everyone sure Basu I'll go ahead and start um we still don't have create three written I've been focusing on other uh more foundational tasks that I think are going to be helpful for the eof process Basu can now run the execution client specs it can also uh through the t8n and b11 R tool and there's also a Graw compiled version of Basu that is able to run the um retest F tests at the same speed as the other clients because

there's you know with Java there's a lot of startup issues growl VM compiled version also um gets uh rid of that startup burden so that um increases the number of clients that can be used in reference test generation I think evm1 has also added some of that so I think this is you know some foundational steps to get us to uh start writing reference testing and start doing cross clients validation tests um create three assists you know I just got to spend the day you know fine tune fine filming through the spec and making sure we all do that that I do do all the steps right and applying all the other existing reference tests that sit in the um there's some reference tests they're a little bit out of date they're in some

of the PRS we've got everything renumbered as well inside of basic two and this is all in there's a it's not in the mainline basis yet it's in a branch uh it's in the mega eof branch on hyperledger basic repo so those are the updates for basic cool thanks Dano who else I'm in from Netherland side we were focusing mostly on Cancun by the way can you hear me guys wild and clear good we were focusing more on Cancun eips and for eof we just did some

cleaning up and matching correctly the spec fix in some box and we are planning on starting on implementing th and this week by the end of this week so hopefully after a week or so we will be also able to generate reference tests and yeah that's mostly it's from our site awesome uh do you also need to implement b11r have you looked at that yeah we'll do it um okay cool yeah I think for retest youth you only need to implement t8n but

to use yeah to use the execution spec um yeah you need to also be 11R cool um yeah Paul um so in evm1 we mostly like what is worth noting is uh we we did change the the op codes of following the the suggestion for Cancun and others so like all of that has been reworked and and uh and we we are working uh on updating existing tests to respect this

this change up codes and Hugo is working on this and I think there are two requests for uh for ethereum slash tests that does this and I think in terms of implementation uh Andre is working on creates three and all the different edge cases um so maybe he wants to to update but I think that's more or less uh overview of of the the change sweet did you want to mention anything about that Andre not much to add actually I think create three implementations finish now in the

vm1 uh one small final problem that I've fixed was uh there was a charge for hashing of input data applied by mistake because originally it was in the spec but then we removed it from the spec but this charge still remained and it also remained in the spec so I removed it from there too uh no it's 16. cool any other client related updates any compiler related updates

they um cross from Viper um so I think I brought up a couple meetings maybe two or three meetings ago about the code size issue from stock validation and not it's a little bit tricky [Music] there's a reason about but because of the stack validation issues you can't court it's not an issue but yeah because of the stack validation respect you can't really share code as well as it used to anyway so um we're seeing

kind of code size increases from one to five percent different kinds of things you can try to do to to review it but um I'm trying to well I'm wondering if like we can wax the stack validation rules um yes sure and then another thing I wanted to bring

up which is big but I think would be useful is I think immediates pointing to code locations should have a a variable link encoded because a lot of the time the jump is going to be to some place that's fairly close so if we can save a fight or two on every jump that would be really good and I I was talking about the stock validation thing with um Craig for a little while last time we

were and I'm not convinced that you need the the the stacking variant rule in order to write a you know a compiler for the UF code yeah thanks thanks for feed advice okay go ahead yeah maybe we'll finish first I was also comparing the code sections versus EIP 2315 and I think that maybe having code sections is not

necessary and kind of makes some optimizations more difficult yeah so about this uh stack height so I yeah I remember about the issue and I kind of planned to at least start working on this so what I mean by working is to just describe the the problem and give some examples that doesn't work but they could work I mean I kind of have impressioned this this is somehow fixable and we discussed that with with solidity some time ago and yeah so it's kind of minor to finding

time from my side to finally do it uh but I don't have final solution and cannot promise we'll find one but uh it's a bit like algorithmic problem to solve uh how to specify in the way that will still be able to work with this and yeah so if you have ideas how to exactly I think it's kind of like the difference between because you you can have recursion with calls right you can have like tail recursion so like a loop should in principle not be any different retail recursion so you should be able to like basically do the opposite of tail recursion which is like when you

see some instruction which can have multiple entry points which result in different stack Heights you just like kind of outline that basic block and then you would like on the back end you would have to issue like a call instead of a jump which like gives you a return PC or something which is not not as good as a jump but it's not that bad either yeah I I'm not sure I can like processes on the fly but I I would try to make it maybe for uh before the next call definitely

to like formulate the the current status like what the problem is and how people imagine changing this back a bit to a kind of accumulate for that I mean I think ideally we can I mean I can talk about it with you on a Discord or something but I think ideally we can just drop the stack validation requirement entirely and for and maybe make those code sections a little bit more expensive if if the back end is required to outline some some piece of code so that it requires a columns that are jumping okay let's talk let's talk after then

and about like variatic encoding I don't know we kind of consider that long time ago uh I think the the Simplicity has won but I I don't know maybe others have comments about it I think variable length encoding is not that complicated but it's not as simple obviously as oh oh you know um location encoding is being static but it's easy to understand like kind of everybody gets it and I think you would see a pretty significant code size savings so I think it's worth it did you have a couple other things there

Charles or was that most of your questions uh I think though the last thing was um meeting code sections um I think all right you could have just as good code generation or better if you had one Global code Etc instead of multiple code sections or one code section for 17. do you guys have thoughts on that if if it works better if one Global code

section what can't that just be a compiler preference as to how to go about it do we need to remove code sections uh yes because call off only works in code sections you can't use uh call sub to it's like call F versus call sub and the difference is that call F goes to a different code section bar whereas call sub uh which would be with you know the global code section and it would jump to some instruction uh with the return PC on the call sack and I'm distinguishing the call snack from the App instead I also want to address what Android is

saying is that you can use jump f to not change the call stack but what that doesn't include is that it doesn't work with hard Jump by so like if you have a conditional jump to some code section that you want to share you can't do that you have to Branch around a cola for a jump path instruction so it's an overhead of several bytes and other instructions it's not just an implementation problem

it's a spec problem because of the jump on an issue that I just can you write these out with examples so we can reason more closely about it with uh concrete examples foreign or just bump your post I'll do that after that we'll have to

actually thanks okay that was kind of compiler and spec related things any other I guess we just move on to spec related updates and questions explain anyone have anything on that topic hazing hey uh just uh quick question about uh the spec so I think uh I I guess I'll be a small representative for the

on chainers or the consumers or the DAP Builders so uh we're put together a small working group uh with like art blocks and uh noun style and everyone chainers um and we're kind of going through uh yeah we've kind of gone through uh the spec and we're trying to figure out what should be the game plan for the eof changes and so we put together about a couple of proposals and Dano I know you commented on it um and so what we wanted to do is to start testing this out part of the concern is is that looking around at the every people that are consuming things

um we noticed that like token bound accounts I think is also using xcode copy and so that's gaining a lot of steam within sort of just the nft ecosystem and so um they're using that as a sort of minimal proxy to uh like create new sort of derivative uh contracts um that are like smart contract accounts um so it just seems like it would be good to be able to put together a test harness or just to know whether or not uh X data copy is going to be a thing or if we should sort of take on board Dano's suggestion and then how should we

test it so that's like quite a few little questions in there sir what should we do or like when will we know what's supported there we go I guess I can make like a quick comment that if this is going to happen for Prague that would be sometime mid next year most likely and we would probably have a good idea that that's going to happen

by this fall the exact specifics I think things are settling for the spec so depending on you know what the likelihood of eof going into progress you can sort of used that as a guide if you have like specific issues I think it's a good time to like erase them like if people are using X data copy or xcode copy then these are this is a good time to have the discussion about what's the right way for people to achieve the same functionality yeah that makes sense uh I linked it in the Discord um what may be the sort of hidden

broader implication uh and I can link it in the chat real quick if I can find it um but that's it and so it's looking like next year sometime I would guess Prague would would be sometime in next year because Cancun we're targeting for this fall if you usually add six to eight months after the fork that's kind of a rough estimate for when the next one might be okay so none of the xcode copy changes would land until mid next year until Prague we'll say right um I actually have a

thing about Mexico copy which is that I think it's um kind of a common pattern Viper uses it for these blueprint contracts it's erc5202 and it's used for these kind of factory contracts which can read the Nick code from like a bigger contract basically I think that's generally pretty good way of splitting code out so I guess the pattern could be changed but it might also get to just haven't posted a copy

so one of the high level goals that we're trying to achieve with this right now until we formally abandoned it is to get rid of the ability to introspect code within code you could think of it as basically the NX bit that the iPhone is subject to um you can't take data that has been processed by code and then execute that um so as as far as EXT code copy going into the code segment that is something we've had explicit requests from very high level people to not have functional because it's going to have strong impacts on on ZK systems it's going to have strong impact on cross-compile systems

um it's it's long term the direction we would want to go to ensure upgradability of of eof code so um yeah I that's that's one one thing that's putting it at odds with with some of the requests um however um as far as copying data in not code um and using a standard you know like this Fe 71 that is something that that I think is something that could be worked in maybe not necessarily the first draft but I think there isn't possibly room for it and I think it's less contentious than copying the init code itself so that's that's kind of the table Stakes going on I don't have any um you know strong yes or no's on that

yet but those are the the the that's what we're trying to navigate around what we're trying to achieve um can you maybe explain a little more around so I can understand better what uh like do we need to are we trying to ban code contracts introspecting themselves or uh code introspect what kind of code introspection are you trying to build um code introspecting introspecting code and full stop now itself for other people um so we don't want um code basically doing just the time compilation um we would like that the code that's going to be executed to be fixed at the

time that the contract is loaded into the blockchain system either through a transaction or through um another piece of code for example we have the sub container codes that are put in there to support things like pool creation and uniswap and you can bring in code via the transaction via create four you can bring in the code there in a separate container well we don't want to have to support is the code that can enter transient storage uh frame memory storage or planal contract storage then becoming byte code in the system so that's I think the barrier that we want to make sure doesn't get crossed so that when other systems change uh you know how how the code is represented they

don't then have to put in a cross compiler in their execution environments um for for these codes they can compile the code they can put the blocks at the transaction entry points and they can do whatever work they need to do there and not necessarily the runtime of the evf of however they're executing evm and what's representing the runtime of the evm so if I'm understanding correctly basically we don't want to be generating code at runtime to point contracts from there or running code that is uh that we generated correct data is fine that's much more easily here to manage and conceptualize and to deploy contracts and append data

at the end that's actually kind of necessary for the modern uses of the evm um but as far as yeah generating code at runtime we want to get the byte code out of the out of all processing streams that are run during execution time that is not actually being executed I think I have to jump off right now so I have a follow-up question about that which would be um so just to recap as a very sort of simple example and be like uh I have some contract

um it has some byte code in it I call xcode Copy and I would potentially take the byte code that's there and then execute that within uh a new contract and that's the behavior that you want to ban is that correct basically if you're taking the data loading into a memory stream changing the memory or creating it rather than a simple copy from another contract so yeah we don't want to have like um you know if you want to create a contract that responds to two different calls you have logic that basically compiles it within the evm it creates the code within EDM and then deploys it

that's the sort of changes we don't want to have to support basically jitting okay but a common thing that we have to support is to take an existing contract and put in the data segment hard-coded constants like saying my pool trades this token and this token hard code those as data in the contract steal that data and put that out there that's something we have to support and I think something that the current spec does support okay so it's just like General like hey

here's some data that's non-like code segment related um yeah can we copy that from somewhere and then you can do something with it but uh anything that would be sort of like an OP code or something that you need to like execute um you just wouldn't support that and like it doesn't make sense to have just a general like hey don't do this because it's not supported uh type of thing um like don't hard code like gas numbers into your smart contract um it's better left as not a convention but a hard restriction right and that's the point of the call 2

Series is that you can't limit gas um which is how a lot of these contracts got wedged as they'd specify a small number of gas we'd increase the cost of storage and those contracts would be broken Forever Until We did uh EIP 29 29 29 30. we don't want to have to do that again so if we change the gas schedule the solution is and should always be send more gas and things will start working again right but I guess uh the contracts I got yeah I guess it's just because they were not following conventions so the approach here is exactly a little bit more restricted to say like hey look um we're just gonna lock this down so

now you're you just can't do it and I guess the thing that um you probably would need uh to understand more of the use cases would be to see some of these like minimal proxies I think a lot of people use like a pattern with VIP 1167 um and they're using xcode copy and that context which it seems like maybe uh create three would do the right thing yeah you'd have an encapsulated contract that you could then send you wouldn't xcode copy it you would do your encapsulated contract you would put in what you're proxy to in it and then you would submit that and the contract would

reference the uh the its data section to do its jump and because it's encapulated in the contract it can never change so you get the immutable proxy cool cool thanks any other questions comments on the spec you need testing related updates

yeah I've been working on Can You Hear Me yeah I hear you yeah I've been working on uh updating the test cases according to the mega mega aspect according to this specification and yeah there is currently a work in progress for requests in the at even test repo which contain these changes it is the tests has already been has already been changed to um to the black hard fork and also the it is also using the new proposed opcode

and I'm currently working on on changing the tests to also support the the containers sections this is what I'm currently working on right now so yeah that's it for me awesome thanks any other testing comments updates yeah Alex yeah it's just uh coming to the earlier

discussion regarding the the code size stack verification so solidity initially when Daniel was implementing that he went into some similar problems um but then he actually figured out um it really to use the code sections which were efficient enough and in the end at least on the especially the compiler has a lot of savings in many cases and they weren't at that time at least they weren't outliers in sense of like generating much larger you know we did discuss the number of

other features which um I think we agreed to having respect and I think lately they have been added but they may not have been implemented fully and one of the important ones was the non-withaling functions the worst accoladation itself I mean you don't need to validate the number of retail items this feature was at least a source of most of the problems in solidity because it has um the error pass they just stand there like Reverb and with this in place all of that can be deduplicated so I'm not sure you know what other cases in Viper um but it may be interesting to have

like um a discussion together with solidity just to figure out you know which are the the real problems of bugs um and which maybe requires some better understanding how to use it um and then lastly with this in a number of other like feature discussions including like tail jumps I don't remember what was the completion of those but we can probably take up the comments from around January I think we lost Charles

but okay yeah still probably figure those things out as well at some point anything else people have on the agenda they wanted to discuss I guess in that case let's end it a little bit early

we'll have the next call again in two weeks in the meantime hopefully Charles will post his comments that he had on Discord or bump them on Discord and we can just take a look at that offline thanks a lot everyone see you again in a few weeks thank you thank you bye