EOF Implementers Call #24

Transcript

hey everybody Welcome to the 24th eof implementers call uh this I think is the last eof call before the all Court those were we wanted to present so I'm sure there's a lot of things to talk about with respect to that in the meantime maybe we just go through some updates from client teams really quickly and then move into that discussion so does anybody have an update they want to share from the last few weeks Guido's been working on a new fuzzing framework um all the clients are working on it um Bas is uh got support for it so um I think there's going to be a lot of great fuzzing support for

whatever we propose um because EF is paying for some really good stuff on it so that's update from basic that's cool do you haveen to have a link to the interface he was he's proposing um writing custom stuff into each client and writing it that way so put how do you add support for it um he contacts you he already has G working okay cool basically the question is do you have efficient apis to get at just the evm and not the entire data stack so

awesome anyone else updates from the last couple weeks on implementation yeah inm one we've implemented cr4 uh is discussed last time so it doesn't depend in any way on 4844 anymore and it's a new kind of transactions that just based on 1559 transactions and so this still needs a bit more testing but I think will be ready soon um we also merged the EC recover implementation using evm Max uh Primitives which was

a uh proof of concept work to uh to see how even Max Primitives work in practice uh which we did during e Pro haathon and I think that's mostly it regarding UF uh We've also support we also support running blockchain test no that's another think related to testing that's it that's awesome thanks for that [Music] update that's probably all the client updates Charles do you have anything you want to share from the Viper side

updates from last couple weeks uh no compiler updates cool let's move on to spec updates and questions does anybody want to kick us off um I was looking at the the note that Andre put together I think um swap MN would be good and there's a couple different variations of it um kind of you want to think about because

the most General one is like requires kind of four immediates actually because you're like swapping anywhere in the stock any two items in the stack but usually you don't really want to do that um so I think that you can get better code size compression with a couple different variants of swap why would you need four immediat because there's 1,24 addressable items in the stack oh I see but we limit Swap and to 256 or 128 I think Max uh I think that so like if

you if you allow one by immediate that already allows you to address 16 items for 256 total combinations which is like one nibble per item and then um I think the most I think actually like a lot of the swap operation a lot of the Swap and dupe operations can actually be dropped I think if you look at um evm code most Swap and dupe operations are like through six maybe um so like you can drop dupe seven and swap seven up and then you can add

like swap NM with and then you can maybe add Swap 2 three as a specific instruction I think would be good and then swap sorry these are just kind of off the top of my head actually um swap two three and then the swap with one immediate bite and then one with two immediate bites and I think that covers most cases um I'm trying to think if Swap 2 m is useful yeah you could get rid of Swap 2 three and give a Swap 2 N instead

but the easiest thing to do is just have swap NM with like two variants I've got a custom build of Basu that tracks live op code usage and there are some high order swaps that are used by current contracts so SW all way to 16 know that are actually executed I know that they're used but I think the frequency is uh there's aode versus uh usage versus op code slot usage tradeoff right um yeah I mean we're talking like you know 10 100 times less than some of them but like uh right now I'm looking at billions of operations and there is like

10 million calls to some of these high ones I mean swap swap 16 is you know subm million but you get to swap you know 10 and 11 and they're still up in the tens of millions right I mean that's like 1% of all swaps right right and that's considering there's like almost 100 operations that's not too bad um I mean they can be replaced with swap with one bite immediate yeah like I I think another way to think about it Dano is like what if you were designing this from scratch how many um how many you want that's I think where

the friction in my mind is coming is if we design it from scratch we're going to get more resistance they say we don't want to do this um we've already tried that before and we got pushed back so while you are right if we design it from scratch there's lots of great things we could do there's going to be less likelihood we'll ship it is trimming out codes very um the more this differs from Legacy eof the more testing surface we create and the more testing surface we create people are going to be less and less comfortable with these changes okay in that case I think the the the minimal useful swap andm is like a single one which takes one bite

immediate uh and you can address the top 16 items in the stack and if wanted to add one more op code it would be swap NM with two by two immediate bites what if we just had swap man with two immediate bites would that and didn't have the one bite variant how would that work out code size um I think that the one bite variant is actually more useful than the two variant okay but we would keep swap in that has full depth as well not not full depth 256 depth I think it's better to drop that one and add the two by immediate variant

instead yeah then we had the dupen and swap in is the EIP forever and that also is um some weight that grants um opens up acceptance of the changes we're doing um um so I mean that is the risk if we go too far from that Old EIP um you know we we got a certain credibility says hey people been asking this for literally years well and is actually on this call maybe he can chip in yeah with with his opinion on that if you and as go in with a combined um front on this I think that would help if if you both agreed on that we could

dispense with the year ago it's like well we didn't even think of this years ago so I think that would be a good argument if you get you know say we want this instead of that I mean I'm I'm not in ipsilon so I I can't even change any eips if I want so all all I get to do is provide feedback no you can you can certainly push um um a PR to the IP repo for review but specifically regarding swap in uh swap in versus swap

MN I think the yeah I hear Dan's argument um but I think I would extend it that um I think at the time you know for many of those year years we didn't reallyu had feedback from Viper what would be the preference from Viper perspective From solid's perspective just a swap and uh was good enough um they don't actually see like to reason to have MN but it doesn't um I mean apart from using one more immediate um it doesn't seem to have a d side uh to solidity U but regarding all these like other um exotic variations of

swaps and removing um removing some of them I think that probably is something we don't want to attempt uh at this stage um as denos said people are like really afraid to take in any changes and the more we propose the less likely it is um but removing the highly specific ones um I guess kind of goes against the um code density argument right because you already have these specific ones and if if you if you remove them then you're going to replace it with a a larger instruction in terms of btes um and just one more note regarding uh all of this is uh we had some earlier

discussions how to handle um op Cod allocation in the sense that would we rename an OP code or change semantics or would we rather retire the op code and introduce a new one um and I think for most of these cases in eof we have chosen to do the second route uh which means we disable op codes and we introduce new ones um to avoid confusion um but I guess you know even in this case um once CF would go live um you know in the future after that we could start reusing those all disabled up codes if we if we would run out of space but I guess the the current idea is that we we don't try to repurpose of codes um and so just

removing these old spops um seems to be not very useful I see and leaving the old op codes um one of the advantages of retiring op codes is if we get an assumption wrong like Gast observability is actually important we could unretire the op codes with a minimum of fuss so that's one argument for not reusing old op codes um I think that the specialized variants um are are probably actually more useful

than like swap 16 but I think it's not worth um like I said the the important one is swap NM um at all um I think you mentioned actually two different pieces one is um wer would definitely prefer the MN to have the ability to swap any two locations but the second you mentioned is we actually go above the 256 limit um how strong are you feeling with the second case um the yeah what what is the the usual stack layout in in Viper soorry what's the can you repeat that um that you want to access the

entire stack not just 20 the top 200 56 items and at some point we reduced it to the top 256 items to um have you know single bite immediate so I'm just wondering what is the the stack lay out of Viper which um which would you know necessitate having access to the entire stack uh I I was just that's the four by immediate one and I don't think that's super useful like in any case that at some point you need to start Spelling into memory and um having more addressable stack just kind of pushes that out

further the limit at which you need to do that but in terms of Stack scheduling um being able to swap arbitra the being able to generally swap two items in this deack is is useful but how typically need to go um I think we're moving more things into the stock so I think you know within 128 items would be would be good but that like I said it's actually kind of not the issue is like how much

stack needs to be addressed so I think that you know being able to address 256 items is funny and baring that I think that being able to address 16 items is actually quite good already because most most of the time that you're doing stack scheduling you're you're doing things that are kind of local things that are near kind of near the top of the yeah I think generally our assumption was that um maybe that's the reason why you know initially there was little feedback from

Viper that the Assumption was that Viper is more memory heavy and um uses stack lass um and maybe it didn't occur to us but you know on thisal I guess we're I just conscious of time maybe um we should move some of this swap discussion to the end um but probably we should also like discuss this more async um just to understand uh the requirements better um but to answer your original question um I personally don't really have any any strong opinion whether it's Swap n or MN um what I care about is that it becomes yeah my my feedback is that the most

useful thing and I think Solly may or may not find this out eventually is that um swap NM is is the most useful thing to have just because of how stack scheduling works like when you start to write a stack scheduling algorithm it becomes very useful to be able to swap two things that are not at the top of the but but yeah I think we can move on

um uh Andre do you want to talk about the updated list of questions that you have or is there something else we want to talk about first yeah we can I can uh maybe let me share my screen uh so first one was SP man second one is uh deployed on Val validation of the subcontainers and in general I like the idea if we can elegantly achieve this like originally

we started with this before we realized data load in problem and we were validating recursively uh in the container during normal validation uh and so ideas there were so far Charles suggestion to drop data load then completely then we don't have a problem and we just validate data load argument at run time and another idea that we had is somehow also Charles also mentioned this somehow to provide the final deploy size to to in the container I guess at uh at factory deployment time I guess uh

so that we don't we can Val still validate data all then without having full full data section so it can be either we somehow add full subc container expected size in the header maybe or data section expected size that's yeah just an idea but yeah know um no concrete proposals about this yet has there been any thought of the security implications of recursive validation I think it should be fine because we just we still validate every

bite it's still linear time I think because it's still Bound by full container size it's will just call the validation recursively but in the end the size of the code being validated is bound by the outermost container and uh when you're deploying an inter container would you then validate it again I think you it's enough to validate that the size of the ox data is the same as uh expected or as declared okay I mean I'm fine with this just my my concern is that we're going

to hit it some performance issues and not just on exponential versus linear time but I think even the linear time maybe too expensive even though we're doing it one per bite we're raising the constant of how much time we need to consider for each bite potentially and there is a there is a cap but I mean actually we're considering each bite multiple times because we have to step through it to reach outter container and then come back and check it again and my concern is security okay I think there's an argument to just also dropping data load and like if we're

looking for things to prune um I mean I just because it's kind of it was already kind of causing this issue with um recursive validation and so and I'm not sure that it it it's that useful that it merits that right we can totally work around it with a push on data load it's just code size expansion but I don't know that that's worth the issue with the other complications it causes so I could get behind it so we already have container size

encoded into the header for each subc container so I think we implicitly get um the subc container size and we could presume um that extensions were fine but dropping data load in solves the whole problem right there we could presume that all data load ends are valid on subc container loads but that's an extra validation mod so first option solves most problems yeah it's simpler change for

sure I agree by the way what is the behavior of data load on out of bounds data I think we opted for exceptional halt similar to uh return data

copy if it did the same thing as code cop well actually what does data copy do the same exceptional hold does call data change in eof no no you asked the data if you meant call data then call data stays the same it's returns Z because if data load just returned zeros then we wouldn't have to validate data load and but return data copy ready respects the boundaries and exceptional faults we have both Solutions already in op codes right but code copy right now does um return the

zeros so I'm I'm just saying that uh if data load n return zeros then it wouldn't need to is return data copy exception of halting considered a plus or a minus in the solidity in the smart contract Community we discussed a couple weeks ago or maybe four weeks ago now that it's a good thing because it helps with API validation um and it doesn't change things I think pav was on that call

um I think it depends on who you ask because a lot of people say it's it's a negative it's irregular and um yeah and that's why you also have to take care of of um written lat size and all that I mean that yeah I originally thought it was a negative but then after thinking about the alternative is actually good because um because you're always validating externally like data that some other contract is giving back to you so you need to validate it anyways that it's like within bounds and so the

exceptional halt is good um but data is always something that you have control over so like right now like I think solidity and Viper both use um call data loading zeros past the end as like a as like a zeroing trick like you can zero memory that way so it's it's actually not a bad thing always to to return zeros but if you still have it from call data copy then you still have access to the zeroing trick uh yeah I'm aware of that I'm just

saying that there that one is not one kind is not necessarily better than the other and um if data load and loads zeros um first of all you don't have to validate it and second of all um you get actually very cheap way of loading a zero loading zero data which is cheaper than the the call data thing the call data copy thing and

same with data copy and um another thing is that the relative cost of code copy versus uh call data copy might change so so I don't know which direction they would change but it might be um beneficial in the future to be able to choose between the two um or we could just like add an m0 OP code and then we wouldn't have to think about it I was kind of joking that's kind of a joke

I think we actually did discuss m zero somewhere at some point I think generally it's nice to you to have tricks but I think with these tricks we get just too entangled in the tricks which then in the end puts us in a position where it's hard to to change or um you know even change anything kind of instructions or just exactly what came up here do we want to have tricks on an instruction or do we want the instruction to be more like pure um so following that logic maybe m0 would be the right approach uh you can't actually do it for

call data size because like normally you're loading the first four bytes of like the first thing every single contract does is like call data load zero and then figure what to do with that um you can also do call data copy with four bytes but that's more expensive so with the deploy size um of the subc

container what are the the main questions in their sides do we I mean would we error out if the auxiliary data plus the actual data doesn't end up matching the expected deploy size would would be zero f in that case um I think the best behavior is to error out I think so too yeah also consider the impact on

Auditors if we have to refer to something as a trick is it necessarily the right thing for a code auditor or op code auditor to look at stuff that encourages Simplicity I think is valuable in that regard but not a blocker I'm wondering why does the existing code copy load zeros past the end does does anybody here not everything zero padded in the beginning including division by zero um so with this um deploy

size we would just put it into the would it be in the subc container header or the init code I guess the subc container header yeah yeah I'm thinking either sub container header so it would have two sizes then or maybe it could be data size of the subc container but that's a bit weird um yeah I'm thinking more about this and I think for both return data and data load um like right now they both kind of depend on the fact that everything is 32

by padded like ABI always returns 32 by padded stuff and generally stuff that's in the data section is um easier to work with if it's 32 by pattered but if you were to have a scheme Which packs data more tightly than like if you return like a uh un8 or something that that's packed to one but so you just return one B of return data um then return data loads and um data load start to have problems and the only way I can see around that if is if there's some weird wrapping Behavior like you allow data load of neg5 or

something or return data load of Nega five or something data Lo not data load and it allows addresses by single bytes so you can read from any offset yeah but if there's the data section is only one B uh then data Lo will always fail all right you would have to pad it I guess you would have to use data copy data copy is also a

board yeah you can data copy one bite exactly yeah I'm sorry I'm lost what what is the the main concern we having is that um the data load n should have should be able to to read uh less than words or are we afraid to put in the size into the header um that the data that the data section that you might want to read some data like towards the end of the data section and the clearest example is that the data section is only one

bite yeah I mean the data load then is is a tradeoff um and prefers the regular case um but there's always data copy right yeah and I'm saying that the issue actually kind of is still there with return data load and it kind of hasn't been uncovered by accident which is that the ABI always has 32 by padded data everything in in the AI is word aligned but like if we wanted to have

some version of the AI which is not word aligned which is which packs data more tightly then then return data load starts failing um whenever the return data size is less than 32 which is kind of the the same thing as what's going on with call data um like everything in the ABI is 32 by padded except for method IDs and so with call data you kind of need this zero padding Behavior actually to deal with um cases where functions have no arguments and you only have the method ID in call data and so it's kind of

um you can't really make call data load start aing out at this point I think with the I mean you can also always manually zero pedit um the the data section and then even if your payload is is one p you can still use data load then but I think getting

into a position where we want to have multiple versions of data Lo um I think we will we will lose the fight there um the answer would be then uh not have any data loow then um I I imagine that would be the answer which I think would be in a worse position um I'm not I'm not really proposing multiple versions of data load and I'm just talking about the zero zero padding versus exceptional behavior for data loan and data load end but I don't see like a single bite has that with a zero pading useful because you can have it on the high bite right so then you need to shift it then

it's cheaper I think it's cheaper to pay the onetime deploy cost as opposed to always being the deploy cost to shift it um I mean it's you have to consider the deploy cost which I think it's still probably cheaper to shift it than pad was zeros and the issue also applies to return data load and the issue is kind of more about uh whether you need to start to have edge

cases to to start padding data sections that are less than 32 bites and I think this is more a question of forward compatibility because right now I'll return data and probably all data sections are going to be 32 by padded but I think as code size State size gets and gets more and more valuable um we are going to want to start packing stuff as much as possible

there's about 15 minutes left on this call I want to make sure that we resolve the things that absolutely need to be resolved on this call is it basically just these questions here or is there anything else that we really need sorted before all C next week can we maybe spend like five minutes just um going through this list and um just making quick

decisions so at least we have um you know something to go with that sounds good yeah so maybe it's like uh raising hands anybody strongly against not including the deploy size and the subc container header all right then I guess let's let's try added approach then okay create a with drawn three three and create for the base cost of

32k the same as create 2 any any strong reasons we should change these um in any any way and if so then any ideas what should be the the cost be those reflect create one and create two prices so I think they're reasonable unless performance dictates otherwise and I think late gas schedule changes are a lot easier to handle so I think we

should just start there yeah I don't don't fully remember the the reasoning ran these prices I think they were hiked because creation was too cheap and it was just like one of those random numbers which guess retroactively somebody fitted a model onto them but yeah I wouldn't I wouldn't try to change them at this point um however there's one thing we did discuss changing is the init code some of the init code um pring because you have already

charges for that and the limits so maybe there there could be some different handling compared to Legacy um there um the the return data return contract pricing I don't know Andre do do you want to need that uh it's just uh I started with price zero because return is zero but return contract is very different because it appends uh the data section so it's uh all fine operation basically and should probably charge for each uh word appended as copy

instructions at least I mean isn't all of this already loaded so we're not loading it and then we are paying for I mean we're don't yeah I mean it's it's loaded the container plus the data pass which is already in memory so we PID expansion and then we're paying for storing the contract per bite right

so I mean I'm torn on this one um isn't it similar to return where uh the caller already kind of paid for memory expansion because like return contract can only happen in a nit code mode so uh you're already going to be paying per bite uh actually yeah we're getting the a data from memory so memory expansion is should be included too and I thought we were copying this

into memory so I don't know that we should do the memory expansion cost for the contract extension we should charge for it separately I think all you need to do is make sure that the memory expansion is paid for I think it should be consistent with the return rules so these contract the unlike uh Legacy the contract's not going to be sitting in memory when you when you load the contract it's going to be somewhere else so we're not getting return contract we're not getting memory expansion paid for already doesn't return contract refer to

a buffer it doesn't refer to anything in memory that would violate code observability it's going to refer to either something in the eof container and create three or something in the transaction and create four yeah it only returns to a section of data section that will be appended and this is in memory oh yeah the append okay the data where dependent cost got it never mind that was on the next line I didn't read far yeah it concatenates with the ox data offset memory segment yeah I think you just need to pay the memory expansion cost on that buffer

like if it's if it's not already paid for and then I think it's I mean thing is we are creating a new container by this appendant so we're doing a copy I think that's how I look at and that's how it is in implementation so far maybe not super optimized but this is the straightforward way we copy from the original container to to edm's memory to implementation memory and copy this appended data append in it so I think a copy operation aren't you already paying 200 gas per bite for deployment yes maybe that could cover it to

you yeah cuz I think the workflow is like you call create three and then the NIT code runs and then at some point you hit return contract and then return and then that just returns a slice to a buffer right so that it's not actually copied until um the code is actually deployed at which point you pay 200 gas per but the reason you want to pay for some

cost here if this would be a DS Vector right but we already paying 32,000 in order to execute code which can return return contract once and I guess the mostly the case of like create 4 well the case of create three and create 4 when we load this um container then we need to make sure that uh that is fairly priced um I think one thing you mentioned that for the aux data yeah I think for the ox data we do want to uh do memory

expansion because they they may just you know point to like some large offset for ox data yeah um made a quick calculation with the current um code size limits um it's zero oxidated this would be like a 2.3k uh like 2,300 gas um this pricing model here yeah I don't think there's a Dos thing because it just works the same as return

which is it returns a pointer to a buffer which has already been allocated and paid for expanded so you do need to pay the memory expansion cost but you don't need to pay for additional copy like with return data the cost of copying is born by the caller and in this case it's born by the colar of create three or create four yeah I'm still still not very sure they're different because return contract does this app pending this is the different part so it creates the new buffer with the deployed

container cop is there I would suggest that um maybe we avoid the cost but explain this clearly in the security considerations of the relevant tip and then um I think that would be like a good starting point for you know all CFS to to actually understand it and yeah I think more I could could um could easily you know decide whether it this is a high enough risk to charge for it or not um I mean I personally find charging for it but I think we need to review this more uh carefully that's why I suggest that we document it in

security considerations but don't charge yet because removing the the charge I think it will be kind of impossible because we never remove anything but adding it will be will be possible yeah do you think this a good idea as a suggestion sounds good to me same uh Andre do you want to go through

the list uh yeah just to mention the next Point um did we discussed this internally and it was a bit un unclear in the spec and uh this is related to how creation transactions relate to e in general and now the idea is that Legacy creation transactions will not be valid with UF so any transaction that has empty2 and EF code in the data is invalid then and to deploy e you would always need to go through this Creator contract which uses cre for so you will always need this new type of transaction

and send it to create a contract and create a contract would need an regular State change probably to be deployed because there's no other way okay if no question about about this then another create four thing is uh so this is during implementation I stumble upon this uh limits are not defined for the

create for transactions for how many init containers we allow and how big are they so for this size maybe we can just rely on implicit limit of the uh container size or like section size actually not sure now because this one is in the transaction so maybe we still need a limit or at least Define the cost so this spe currently

yeah it suggests to use the same cost as for C data and the limit for the number of init codes in a transaction and for the size of each init code is not clear yet I I think we should just rely on the external init code size restrictions rather than coding it in um those I expect will be continue to be fairly Global restrictions Oh you mean 3860 restrictions like the restrictions that say that a nit code can only be 48k and contracts can only be 32 and if you try and do a create for that violates those

the create 4 fails yeah I'm not sure we had some discussion that this AAP 3864 should apply on the to Legacy Creations but not to but I'm not sure anymore now

why what to do with transactions what about the count of them do you have any idea how to limit it we have a code section count limit to 1,24 we could use that for un go too well that's kind of a lot aren't they kind of naturally bounded by the um G the block gas limit yeah because there's the block gas limit and then there's the 128k limit that gu

imposes for gossiping the transaction as well um so there's gossip will imply that but it won't be hard and fast because nodes could still emit their own and then the gas limit would would force that to be a limit as well because it all gets costed as call data yeah and 32 so the each create cost at least 32,000 so um uh just real quick 15 million into 32,000 is 469 plus call data cost of each create transaction which probably less than 32,000 I mean that is an extreme case we

need to test the limit when we do testing yeah I think the the only only main argument we had because uh the create for is like the specific um blobs in the transaction um so the existing GP for the init code limit guess doesn't naturally cover it so we need to either explicitly make it

cover it or we can um make up specific limits based on you know based on on the container sizes we have and and maybe that could be like one incentive for people to use CF so here's another angle and that goes into the next step um right now we're you know the initial specs as we reference AIT codes by index um but for things like um 4337 we may not be able to guarantee the index when bundled transactions get rebundle um what if we set the index limit to 256 thus any create four where that field has 31 leading zeros means it by

index but if it doesn't have 31 leading zeros I mean probably just say it doesn't have 20 leading zeros based on odds but we set the limit based on that then anything above that limit must be treated as a hash so that way you could still put in your random um list of a contract in there and you can have your bundler reorder them and whatever order it chooses and then access those by the hash if the op code comes across with um with insufficient leading zeros it then becomes a hash So based on that 256 is a nice limit meaning if only the lowest bite is in use and all the other bytes are zeros um then that you know creates thumb rationale why we pick 256 out of air

I'm just doing some calculations in the awkward silence uh the awkward silence makes me concerned this is too crazy of an idea but people don't want to step up and say no I mean actually I was considering like 256 for many of the the limits lied Co size was that because then it's just one bite but it it turned out to be too low but this is the number of different

contracts you can put inside a single transaction I mean unless we're talking like layer twos that have billion gas blocks or something well 256 um with the um like the 48k limit it's uh like 48 million gas so I guess 256 is as good as any other and it's got some rationale why we picked it rather than just fits in 15 million block or or doesn't fit in 15 million

block I mean depends on the size but assuming most contracts are around the size limit because people are constantly complaining um then it comes at around like 40 million over 40 million so yeah it doesn't fit so it's it's high enough in that sense but at the same time it kind of go goes against like the ear earlier argument how much cleverness we want because we could just make create for do

only by hashes rather than by index and then the size limit in the transaction is irrelevant by the way what happens if you have a duplicate in it codes in the uh transaction that have the same hash uh then they're the same code and it doesn't matter which one we pick yeah unfortunately with the indexing we cannot duplicate it so you would just pick the first matching one which would be fine because it's in distinguishable from any later matching

ones yeah and but you're paying extra for the call Dat you're the fool you're the one that assembled it I mean the downside of making all of them addressed by hash codes is it would make all the create fours longer because you'd have to have 32 bytes for each or however whatever hash we would use to to look it up with so you know index if you know you're not going to be bundled and hash maybe we could change the code that if a index look up fails then you look by hash um that might be another approach I think it's it's fine as long as you never want to expose the index in

the evm like transaction index or something I'm actually concerned about exposing the index in evm because that'll presume stuff about how you have to structure your transaction based on Smart contract code but I mean you would also be actually passing it in through a um through the stack which could then be put in through external data so it's not necessarily a bad idea but if you're going to be passing in external data you may as well pass in a half as well is the only concern with the hash addressing is the the size it takes and then it that's one negative and then you'd have to index all of the addresses that come in um but more than

just um layer one use I think there is Layer Two use for this and then the layer two could have an entire stable of default smart contracts available by hash that you can instantiate that you don't have to reference in your transaction so the the whole index by hash is broader than layer one in in full disclosure yeah but I mean is is the main concern for not going only with the hash is that it takes more more space in the NIT code or where there any other concerns we found I don't think you'd want it in the init code if you get put doing the init code just load it in as a factory and create

three I just think it's it feels a little weird that you're like going through this bundle like run the first init code and then you run the second init code but you're actually running some other init code which is like I know it's bite for bite identical but I don't know if there's some weird statefulness that could come in that kind of has some weird Behavior you'll have a new contract and new storage addresses to work off of but that's a problem with existing creates anyway I mean thinking about how people are going to use create for I really don't see them hardcoding addresses or

indexes into well maybe indexes into the transaction but definitely not addresses and indexes are much too brittle so I think the typical use case we would see from create 4 is it would be passed in by call data and then that's just a hash being passed in by call data and um that's you know not terribly expensive concerned compared to the whole cost of the create four because it's not occupying um space in in the code it's not running up against your code limit call data can be ridiculously large can you disallow um includ with duplicate hash that would be a transaction

validation rule if you don't have indexing then yes yeah I think that the reference by hash it makes sense to to only have one in it cod with that hash and I think another transaction validation rule would be it has to be an increasing order of the hash to make searching easier which would implicitly this something you would get out of your duplication check hanging anyway you would need to order it and would also make me searching against these a lot easier because you could validate that it's a valid

transaction much easier if you require the hashes to be incrementing yeah I wonder because we're like 10 minutes over um not sure how much time people have I mean I should have left 10 minutes ago but um should we still like at least briefly discuss you know what is the plan for next all Cavs or should we have an exceptional UF call next uh Wednesday as well I like the idea of a call next

Wednesday gives us more time sounds good I can set it up so then um I think we should try to close off all these questions by then um maybe async I think we did close many of them this big debate is because the transaction limits and um what do we go only with HH I personally like the only hash idea um but I think we never invested enough time to see any of the downsides it may have I do buy into the upsides I do like those and especially

like the transaction simplification Parts I just have no idea if if there's any downside we we haven't thought about because I think nobody ever spend too much time on that makes sense yeah let's look at these questions Asic and try and discuss them and resolve them via the evm channel on the Discord before next call I just put it on to the protocol call calendar and I will add another agenda shortly for that call and

we can post any questions or specific things we want to talk about with respect to the allart devs meeting cool I guess with that let's just go ahead and end it thanks a lot for the discussion everybody we'll see you next week thanks bye thank you byebye