Light Client Self Led Session

foreign [Music] wants to talk about an EIP just like raise your hand so we can like roughly keep track of time one okay if you're in the back it's not going to happen you need to move forward yeah okay so sorry I I didn't count because these guys again again okay one one and a half two three four five six seven eight nine okay so we get like five minutes each it's hard to like cap that okay I can like keep the timer yeah you can roughly keep track of time should we start yeah okay yeah um okay I'll start I'll start on this side okay hey guys um I'm Sarah I'm a smart contract engineer at uniswap um and I'm here I'm Mark and I'm a protocol developer from optimism and um so we're gonna we're in we're done should I drop the mic um cool so we're gonna kind of tag team this EIP today um yeah first of all I want to thank you guys for hosting the session I think it's super important that you know when we're planning for building open source software we're really bringing a lot of diverse perspectives to the table um you know I think it's you know a lot of times client devs and core devs were you know focused on this really long-term vision for ethereum and unfortunately for application developers that means some of the stuff we want to see does not get through um and so hopefully I'm here today to convince you that this is worthwhile and actually this EIP really will complement the kind of Future Vision for ethereum um so let me hand this off to Mark to give a little a little rundown okay so we're here today to talk about EIP 1153 which is transient storage and this EIP adds two new additional op codes to the evm and this concept of transient storage which is basically like a key Value Store per account and anytime that you um you know UT store your t-load which are synonymous to uh s load and s store but you instead of putting in a state you put it into this transient storage map and each one is namespaced by the account and it persists throughout the duration of the single transactions execution yeah and so so actually we have this concept of um you know kind of storage is used sometimes in a transient way right now in the evm you can see this sometimes with like re-entrancy locks right so this is when we clear a slot back to its original value before the end of the transaction and then you know we're allotted some amount of of refunds um and you know to achieve transientness in this way is actually quite messy um from you know the developer point of view um you know it's really not straightforward you know how the accounting will work for this um especially because refunds are now capped um and so you know enshrining this directly in the evm is is a more direct uh kind of use case to get transientness um you know also developers are kind of having to go and do the sort of messy implementation where you'll see a lot of times like you know one zero one instead of clearing to zero we're clearing to some dirtied value because as we actually end up getting you know more refunds in that case and so it's really the sort of patchy way of achieving transientness in the evm and so kind of the way that that we look at this EIP is actually sort of a cleanup it's it's relieving some of this Tech depth here um because this is a real use case and it is wanted so one really cool side effect of this is it actually helps a lot with parallelization because um you know we want we want to scale ethereum we want to increase the throughput of the system and we can do that by paralyzing the evm and right now anytime that there is um a lock taken in a contract it is writing the storage and that prevents parallelization of that transaction with other transactions that are trying to interact with the same contract so if we move all these into transient storage instead then we'll be able to paralyze a lot more transactions and it's important to try to get this change in sooner rather than later so we can start adopting this pattern now and have more of the network using this kind of way of doing locks so we can have more parallel execution in the future another problem is that it's really difficult to know how much gas or how much gas is going to be used when you're allocating memory because there's this like crazy non-linear function so this makes it much more straightforward because every you know t-store uses the same amount of gas so it's easier for a developer to like know how much gas they're going to be using when they're writing their smart contracts cool and kind of on the on the last note here I just want to re-emphasize that this is not necessarily an addition to the evm it's it's really we're thinking about it as a cleanup a cleaner way of of achieving this use case in the evm I also want to point out this is a really siled change it's two op codes it's easily testable um and uh also benefit it's already been implemented across four clients so nethermind Bay Zoo ethereum JM or ethereum jmbs and uh also Geth is implemented we've also written tests for this they all pass um and so the kind of the final ask today is to just really get some more client Dev eyes on these PRS on the tests we've written and to actually kind of seriously open this conversation of having CFI for 1153 in Shanghai um thank you I guess just to make sure we have time like are there like a couple client devs with strong opinions about this we probably can't do everyone but uh okay I know first I have a minute opinion on this I think it's awesome that people from outside the core team are not just riding the spec writing the implementation but also writing the tests I mean big round of applause [Applause] [Music] any other comments Peter so um only know just FYI I do like the EIP however um I kind of have a feeling that the russianizations are not necessarily all equally valid with the parallel execution I think that's kind of a far away dream so I I yeah I mean essentially every time you execute a transaction you will touch some state so if you touch the same contract you will touch the state some State anyway so that I don't think it helps there however I I mean personally I think it might be nice one thing it would be yeah let's just keep it at that I I don't really see the point but I'm also not a not a not a contract developer um it seems to me like a nice to have but nothing that's critical for for us right now so I can read about that one of the one of the points that I do like about it is that with the with these mutexes essentially it touches the state and even if it does nothing just flip some bits back and forth it still has to touch disk and this would allow us to do these things without touching this so that's a net benefit for me have you talked to the solidity team yet there is an open draft PR with the assembly op code in the solidity repo right now um yeah I see like it's really parallelization that has been quite a lot of work in analyzing how much the transaction can be paralyzed and even at flashbots we were running the analysis of the of the clashes the bundle clashes the transaction clashes so something uh any improvements in this would would be quite nice to see there are some Builders there like I've seen actually the the modifications to get that were introducing parallelization and they were working and I was really surprised like how some developers were able to to do that in their own in their own implementations just for the simulation efficiency uh consider already gains from paralyzing transactions such as the the implementations are so complex and so specific for for searching uh that they are not coming to the journal View uh so it'd be great to see that uh I think the pitch was really great so I I was not considering this one because I was always thinking that anything that was touching the storage was awful amount of testing and huge risk of of something escaping and and some contract breakages so so this is my biggest worry like we were modifying the cost of storage in the past we're modifying the behavior of refunds um and this one feels a bit like that like when you say oh it's uh it's a known cost but do we do we cup the the storage okay I see yeah refunds are capped nowaday they started transition storage because if it's not capped it again it should be exponentially growing and it's it's the same it doesn't exponentially grow but we looked at it to see kind of you know the upper bound and it seemed like it was safe but it's the same with memory right yeah so with memory we have the exponential cost and here we have the linear one yeah so I guess just to wrap it up sorry but like is there something that any like we have tests for this we have patience I guess my question is like from the client teams very quickly is there something like you want to see from here like a big open question you have about this Daniel you have the solidity question but like yeah just to wrap it up anything you wish you would see from this that would help you better understand do you have uh tests or benchmarks for like just writing as much uh to the storage as possible writing in uh in like small chunks into it doing uh doing separate calls into different um different contracts that each write their own I would really like to see this yeah there's an open PR in the ethereum test repo I think most of those cases that you just said are covered I haven't looked in a bit but um yes re-entrancy I think is covered um I'm happy to share that out with with the wider group but there's extensive tests something that I did want to do is use Felix's mem size library and basically just like look at the gas limit and just like you know fill in as many things as possible that would fit in the gas limit and then like observe the size in the implementation itself um I have that like on my like computer someplace but it's like not really pushed but that is like something that we could add add to make it better wrap this up to the next one oh one last question okay I just had a comment on this already depart um adding it to the assembly well the pr there wasn't a PR we just edited it but um it's easy to add the op code and you can use it in an inline assembly um and if the AIP goes live that's going to be added like instantly but adding it into language is going to take quite a bit because it's a lot of changes um I don't expect it to to happen anytime soon um so if you guys want the help in implementing it which may take like 1000 signs of code um that would be welcome okay we need to wrap this up I'm sorry but uh Igor you're up next thank you my name is developer and I'm here to Champion EP 5978 Untitled guest refund and reverse some motivation for this Eep is that revert of a transaction or any its sub calls drops any state modifications but the user has to pay the full price for the state modifications while with State modifications are not preserved for forever and this has two problems with this is that users overpay and then it limits some solidity patterns where you may may have a call and revert it and it makes it extremely expensive to the point where sometimes instead of reverting the call you may just like transfer easy tokens from one address to another just to like restore the storage instead of uh paying the higher gas price of reverting the call and in my opinion it's an anti-pattern because some side effects can be missed and it may result in a critical hacks and lots of funds eventually and vcp suggests to reprise the following op codes as a s store create so so distract through the gas refund mechanism so they're not going to be free still gonna pay some price for touching uh with addresses or storage variables but it seems unfair to pay a full price vcp is a in a in an early version so I just want to spread more awareness around this problem and hear what kind of comments people have thank you uh question uh I'm maybe I missed something but um is the suggestion essentially to reprice some of the storage of codes and let's say sloth is sorry for the clarity so if let's say if s load operation store operation inside the reverted transaction uh costs 22 000 and then with some we score reverts then the cost of the separation should be repriced as just like a attaching this load for a different number so you should not pay twenty two thousand for modifying uh storage slot which is not modified at the end of transaction and the pricing should happen through the gas refund mechanism uh does it bring any clarity foreign idea so um it mostly means you would need to remember all of the changes you've done and then it's like single point on the reverts goes you would need to go through all of the changes and apply a compute at least the refund you you get from that so like you have like single operation that it's actually like unbounded in the complexity internally and that might be like doable if you have this journal Journal implementation of the state because you do also there like on journal the the changes but if someone has different implementation of that it might be really difficult to implement and just one more comment that um usually with when reverters you can actually have nested reverters and you that can end up quite nasty when you have subcodes that revert and the outer code doesn't revert then the outer cool again reverts so it's not a very very easy EIP to tackle it might not be too hard but it's I think the reason about it is not necessarily easy yeah I think that if if like that is assuming that we have to keep the journal all the time and use it for all all the other apartment operations and uh it kind of this idea fits into that perfectly I think that might be considered but if there is something that you would need to keep different data structure just for that I think it should be really difficult to have it and I know some of the implementations actually don't use the State Journal light I mean that's not something we mandate to to be used so you would need like in other words it would be forced to keep something like that anyway although it's not required uh in particular right now you have to keep track of a whole lot of information for um for the uh for the refunds anyway for the for the storage refunds anyway so it's the same stuff and all implementations I think whether it's journal or cash you have all the info you need um but I'm just still traumatized by some of the code I had to write for the um for when we were doing the the repricing of the the 2200 um I can't remember exactly the name of the of it where it was over fitted fitted to get and um our code analysis tool freaked out of the complexity of the code so I'm kind of concerned about that about the maintainability of some of these I mean I was implementing the algorithm as specified and sonar said that's too complex you can't do it actually um it was it was the same uh EIP transient storage um so without maybe just Reviving you know everything and reiterating everything there um it just just kind of adding on a few points one um you know right now some of the higher level oh sorry uh background uh so I'm actually a contributor to the Hof language which is a low-level uh Assembly Language and then uh formerly um I worked with the superfluid protocol and so I think I think both of these could benefit from transient storage so on the Huff side you know higher level languages like solidity and Viper you know they have these re-entrancy locks or modifiers to facilitate re-entrancy locks that you know are very well built and it's very easy to build this in a safe and secure way but when it comes to assembly languages this is actually a problem because if you set a lock in storage and you don't explicitly free it by the end of the transaction those are now bricked which obviously you should catch this and unit tests right but it's just it's one more foot gun on the stack um sorry to interrupt you I think you kind of uh capturing the the governance process right now because we already talked about the CIP and now rehashing the discussionist kind of I think not great uh so I would if the if I would rather move on with the next Erp and uh because we discussed this one already I do think though it is valuable to know that like low-level languages and like projects like this uh if you can like write it on the eat magicians post or somewhere yeah yeah we could go we're not going to be done already though yeah sorry so I was gonna say yes we probably don't have time to rehash it if but it is valuable I do think like putting it in writing on the East magician's post is probably good to document um yeah sorry uh also the microphone don't be scared it's mainly for Direct ly okay cool cool sorry you had any IP as well yes okay um so I'm working on on 5027 um and also another VIP 5478 so I just discussed five zeros 27 first uh so basically it's uh aims to remove the right now the contract limit as 24 kilobytes uh that it was introduced in uh EIP 170. um so uh the reason is like I think the motivation is pretty clear that a lot of people complain regarding 24 kilobytes contract size especially right now the contract is significantly much more complicated when EIP 170 was introduced so the major concern of EIP 170 is basically DDOS attack uh if a large counter maybe fix 100 kilobytes that was deployed on the ethereum damn uh if it's just charging using a flat fee like for example right now is 2600 then you may uh specifically significantly under charged so basically the idea is like right now the solution basically is that split the contract to multiple contrast and then I call kind of like chain of contracts so they can retrieve their data but it basically make the whole larger much more complicated so the current my idea of solving this EIP basically the DDOS tag the cup two weights one is basically introduced uh basically a contract called hash versus the to the country size so when we call our contract then we immediately to know basically the size because size is very small like four bytes number then we are able to pre-charge according to for example what the actual size of the country is like maybe we can just charge uh charge to 2614 per 24 kilobytes so that we are able to basically have similar um right now gas behavior of calling multiple contracts but just putting it in a single contract so this is one idea another idea is we can if the counter size is greater than 24 kilobytes then we are able to append a size together with the current 24 kilobytes and then tells the what's the actual size it is and when when the first time it costs its first charge 22 600 about the the first 24 kilobytes and then the conscious size and then once we know country size then we can further charge the corresponding the rest of contracts and then put in the memory and then execute so basically this is the basic idea uh when it takes a explore the ebm code and also I have a single basic implementation together with some concerns of addressing one and code storage and also be concerned of the P2P package size because right now we have a limitation on the P2P packet size but with for example 50 million gas block gas limit divided by 200 gas price per byte and so the contract limit size actually is essentially limited to 250 50 kilobytes so right now that's still fit into the P2P package so the basically there's a couple of concerns that regarding this if we are able to remove this limit yeah happy to so um there's also EIP 3970 not 3978 um 3860 which is to limit meter and net code which is like we got two conflicting eips um so I'm not opposed to changing the limit but completely unlimiting it I think it has issues um I think it's Martin that has some really glorious code that shows the performance problems with the current jump analysis on on um the Legacy formats but another thing to consider is what if we change the code to required to be done in the eof and it's the code limit it applies to and then we could reconsider how much data you could bring in that is not subject to this because you're not supposed to do the jump analysis on the data the jump analysis is different in eof2 there's not the same risks but then as you mentioned you get into the issues of how does it impact the storage bringing out you know kilobyte not kilobyte megabyte codes code out of the storage um and yeah I I think the unlimiting is going to be a hard sell I think changing the limit I think is going to be an easier sell I guess my question is kind of similar to this that uh saying that 24K is too small I can definitely accept that I think that's a valid concern my question is what is reasonable because if uh if you go towards saying that well it should be arbitrary large and it will get so complicated that it definitely won't ship but for example saying that well let's raise it from from 24 to item 64. that's that thing can be analyzed there we can put the number on it it doesn't mean that it won't require additional changes but it's relatively simple to understand the implications the moment you introduce these Dynamic changes I think that's that's not really Gonna Fly it's going to be too complicated in my opinion um yeah um so because I do some experiment and and using a code so right now I feel like pick some instant synchronization and put out some deploying a lot of uh like some 200 kilobytes of contract on top there uh it looks like everything is working fine on my test net um so uh has been running for um more than half years um yeah especially like right now in the gas regarding the jump analysis right now the glass metering is charged for 2600 per 24 kilobytes which essentially I think the same is equivalent to I call this contract and call another one this Country Corner another one so basically I charge this the chain of this calling to in a single but you see using a single payment so so if we tie this to eof um you can have larger contracts if you do it in an eof container we simultaneously solve the jump test analysis problem and uh reasons to motivate people to use eof so I I think there's a lot of things we could combine and trade some horses to make this work I I just in my opponent trivia for why 24 kilobytes was chosen as well it was a convenient representation I think it was two to the six plus two to the seven and at the time of the gas limit it wouldn't have broken any contracts because it was impossible to reach that so I it's not possible to do this on uh on uh mainnet right now and I think it think it's also not possible to to increase the code size uh if you're a client stuff and you're interested about my reasoning come talk to me afterwards um what is possible is to do it in UF and I think that's what you what you should strive for uh do it any eof when we have the the jump test stuff cool I'll get us commented just a tiny tiny bit of dot comment you mentioned that you had to test setup and running and it's been running perfectly the with all these changes the catch is it's uh the average case we know that it runs perfectly because the code is written well the problem is how attackable it is and in your private task that nobody is going to attack it cool thank you um dang crab did you have any IPS do you want to talk about self-destruct who's the self-destruct guy Proto okay uh hello everyone I'm proud of I work with Opie lumps um we have this dream of serenity Serenity includes proof of stake and sharding they have achieved proof of Stack I want to continue with sharding I'm fully bolt into the ethereum for this combination not for one and not the other and I think right now the process that eaps has been like kind of imbalanced with the merge because we have a exclusion layer consensus layer I think an EIP that does both of these and actually does touch on the testing infrastructure is the thing we need to repair it right now the merge was I think still shipped in relative hurry but with scaling we have actual incentives outside of just client teams to improve this infrastructure to improve analysis of ethereum to improve integration testing and so we can get the best of both worlds where we can improve ethereum and we can improve the process that we have to accept erps and so that we can be happy to enter future erps without as much concern because you have to write testing in place and then outside of testing and the whole process just in case before it prefer if you're not familiar already before it prefer it increases the data for Layer Two layer 2 is meant to be an extension of ethereum you could think of the previous charting dream of ethereum as this execution charting thing where it was all the complexity left on ethereum itself layer 2 enables this to be more competitive and be split from ethereum where we have exclusive layer as layer 2 and we have the layer bomb just focus on the securing data fatability and this is what this EIP focuses on and achieves and then through this means we can adopt a lot more ethereum users onto Layer Two and projects like like coinbase or other like larger ethereum users don't have to look at these ethereum killers in quotation marks where they can actually host these users at low cost um just because we talked about it a bunch before um the client teams have anything else to add or numbers numbers okay you heard it here um yeah I just I want to make sure we can get to as many people in the next 20 minutes as possible or thank God we're gonna add something on I think I've already said the main things I wanted to say but yeah once off destruct I think Mario's has the pitch oh do you want to do the pitch mares or do you want to listen to more of the other pitches um we should remove self-destruct um yes that's the picture we agree okay okay and we need we need to remove self-destruct for vertical and history expiry and uh sorry State expiry and all of these upcoming changes so it needs to be done uh the question is do we do we do it now or do we do it later and I think it's it's a really small change so we should do it now for legacy and dof so just to I think this uh if somebody is not really on the page of why we want to remove self-destruct essentially every single op code on the evm is the cost is linear or I mean tries to approximate the actual execution that the resources it consumes and self-destruct is one of those OP codes where deleting the contract store essentially it's a it's a single op code call but it can result in an arbitrarily large execution and currently the only reason why currently it works is because self-destruct assumes that clients represent the state in a specific way in the market Patricia way and if it also assumes that this state does not get deleted from disk it's just a couple of branches of the market Patricia gets updated but the moment you want to do something fancier like what Aragon is doing or what gets new pruning is doing a sensors essentially self-destruct will become Berlin a completely unbounded opcode and that's it prevents us from going forward with in the implantations Imagine self-destruct on usdc yeah two sorry yeah and and to like make this uh add to this like if you want to be stateless it would be an unbounded number of State changes and that completely kills statelessness so yeah comment that the currency of this track has a quirk that you can destroy Eve with that and the question if if we want to actually like to make the the scent all work the same way or we want to kind of fix it and make it more intuitive I think so I think it's kind of the the choice between like more backwards compatibility between something that is more obvious how it works oh so the way I implemented it now it um just it doesn't destroy it either so it and and the idea for everyone the final implementation right the first implementation was okay and uh for everyone in the room we are not trying to remove self-destruct but we're changing it uh so that um so that the self-destruct will just send all of The Ether um that is in the contract and the but the contract itself will stay and so so it's like it will keep the current way the only the only thing that is kind of iffy about it is there's some pattern where you self-destruct and create uh to uh uh contract but there have been an analysis about it and it doesn't break too much stuff and and we and we talk to the people that that we would break with it and uh they seem to be okay with it how did gasto can take it um okay uh beside you Proto uh sorry I don't know your name uh you don't think that's back yeah um Ronan uh I basically build the own chain games uh and basically also other application uh many things actually but um and by that I mean application or games that have a zero back-end and where uh the user player uh provide their own node through the wallet the truth and in that context um I am building an indexer that runs in the browser um and so you can fetch the logs and it will all fine and but some application of game rely on time information and most developer assume rightly that the timestamp is available and so they don't need to add the timestamp in the event that they emit unfortunately the logs don't contain the timestamp information and so in my game for example like 20 000 events I can fetch them very quickly like in five seconds it's all all the state is synced but if I have to uh add the timestamp then I need to make 20 000 more requests and account even batch it because uh eip1193 which is only interface I have cannot do that so the idea is a very simple proposal is simply to add the Block timestamp in the logged object when you query the logs and actually someone will say you we could also add the timestamp to the transaction received Etc but basically yeah adding the time some information so one of my uh questions here is that long term the essentially long-term ethereum attempts to remove access from old chain segments and ideally I would also completely remove access from law accessing logs that are older than I don't know I would remove I would say a month three months something fairly High so uh essentially I mean is it already your consensus because we talked because I feel we are talking now about another thing like so what I was getting at is that uh this is kind of a consensus in ethereum that the past chain segments needs to be pruned otherwise the the network implodes and in from that perspective uh the amount of logs you will have to access is more limited so it might not be that big of an issue not to I mean you could always retrieve the timestamps if if you have a bounded number of logs you can access don't you think that if we go to that stage uh the the wallet interface will also evolve uh with a different mechanism so that the application can remain decentralized or are you giving up on complete decentralization from the application point of view I'm I don't understand what because like most applications we kind of as a developer we understand that we need to index the data and that's why we use event um but okay so I think events are completely being misused and they are used as a database instead of events and uh in my opinion ethereum should use it as events and should everybody ask you the tabs but that's my two cents what do you mean by using as event so by event I mean that that emits something and anybody interacting with adapt can react to it within a specific time frame but not to look up events that happened 10 years ago because that's that's not an event that's a kind of a database at that point yeah I mean I have other common to make because I think it's a bigger discussion like a lot bigger than what we have time for now but because I've we have all applications rely on this so the reason why we use the event of the database is because I mean the typical example is the NFC if you want to know the list of the token you own uh you can add and a lot do that they have this further called Fetch all you know by providing the starting index and the lens at which and and you can do that but it adds gas codes to the implementation and many decide actually to not do that and use the event and I feel it's it's an I mean I feel normal to to do that and I feel we need to have a discussion about how do we will deal with that for applications that really want to remain decentralized have you looked at using the graphql apis because I think you can go into a Blog from a log and you can get the timestamp and you can do it in one step your graphql is not part of vip1193 which is the only thing I have access as an application the graphql is there's a standard for the graphql and it is in the execution apis so um gas and base we both implementing can expose it but you have I think what is important here is that I don't have access to a node the only interface we have for application is the ip1193 so I I'm trying to have actually added a further AIP to solve this using graphql as a mechanism by which sorry sorry but um just because this is not like a core it does touch on the cardboard we're going to have a whole session about erc's on Friday um it's an infrastructure issue yeah yeah so I I and I agree with you there's like a longer discussion about like how applications use this stuff but I think yeah that's probably a really good one to discuss on on Friday um yeah thank you yeah uh yeah that will be at 1 pm I'm not sure where but in some schedule somewhere yeah it's on there's not a lot of stuff on the schedule Friday yeah yeah I'm Matt do you have one I have an EIP e you get a minute I'll keep it short I'll keep it short um so my name is Matt I am an author of eip374 often off call more to the mic I thought she was going to take it away from me you're finished now um yeah so EIP 3074 adds to new OP codes off and off call the motivation of the EIP is to improve the user experience of ethereum I think if you're using dapps today you're realizing you're signing tons and tons of things when you're interacting with a single dap and the flow that we have is not the best and with auth and off call we're providing a very generic framework for adapt developers to Define like multi-transaction flows in a way that allows users to sign just a single message and they don't need to use any kind of smart contract wallets they get these types of benefits for free without deploying any smart contract wallet that's one reason another reason that I think the EAP 3074 is very valuable is it lets all users of eoas sign a message to create some sort of social recovery mechanism and if they happen to lose their metamask or their Ledger or whatever wallet that they're using they can go and recover it with the people that they signed through and the third thing I think is really interesting with 3074 and is a testament for like how powerful it is is a proposal that Alex came up with maybe I don't know maybe last year about replacing the wet erc20 token with a contract that uses the ip3074 to natively move the ether balances around whenever you're interacting with the erc20 token so that's the the data um there is some huge user experience risks with it is currently done and the revision took some of the guard rails off so um we don't have enough time to go into some of those those issues with safety and those are I think my number one concern on that right now but if we need meta transactions let's make a meta transaction transaction format and some of the other ones you know account abstraction yeah I think account abstract you can solve that and that's something we know we want to do yeah okay so the yeah yeah various ones to China man they're on the same team we have 10 minutes left sorry no um well I will give a shout out there is an account abstraction panel I think Matthew on it uh later this week so if you want to go ahead and do a heated debate about the various flavors of account obstruction and fake account obstruction and 3074 right um we'll have a whole hour to debate it yeah so yeah so that's okay cool can you raise your hand if you still had an EIP uh but Alex you don't have one okay just oh no sorry I mean Alex B in front ACC now Okay no Okay cool uh how about it well do you have it no no uh how about did you have one okay Daniel do you have a fully IP I have three of them but I only want a quick yay okay I also have a quick one for a Yin a okay Dino first and there we finish with Matt so I just I just want to get a temperature check on the three other eof ones on eof function static relative jumps and stack validation good idea bad idea too complex that's really all I'm looking for okay okay so the first one is eof functions where we'd have the call F and we'd split it up in different functions and have multiple code segments good idea bad idea too complex okay static relative jumps where it's an immediate operation you say jump ahead 10. yes okay and the stack validation which needs the functions where you can say that this function is only going to take five stack items and if it goes and it's not going to overflow so you could remove the Overflow check my thought on that is it's a bit complex to get into Shanghai so that's I want to see if I'm the only one of that opinion I wasn't saying that the other stuff should go into Shanghai I think it's it might be a good idea in the future good idea just Cancun or later so cool so no one actually proposed uof um so I guess the UF is approved for inclusion oh but I just wanted a temperature check so let's not discuss it oh sorry oh yeah these aren't in yet okay okay can I like like one comment is like if you combine functions and relative jumps you can get rid of of uh jobless analysis entirely because they kind of replace that um unless we get rid of the jump code too um the jump wood jump and jump I would have to get rid of those get rid of jump test analysis yeah like to remove all of these we can do that with these two features but uh like the way we didn't Champion it like because I think that's not on us to like actually say it's great because we need to input from people that say they want to use that but thanks for mentioning and yeah we have evm panel on Friday as well I do have another VIP I didn't wanted to like talk with the UF because we spent like two hours on like protocol Workshop um but this app is really cool it's called M Copy for memory copying it's not marriage yet because of the EIP process but um I'm going to summarize it so basically the only way to copy memory right now there are two ways one way is to do it at the Loop amp store M low damn store and that was really recognized in the identity pre-compile was introduced um I think the first like few months after the launch of ethereum that was used by the solid compiler but then with the Shanghai attacks it was repriced and the call was becoming too expensive so nobody used the identity compiler anymore it is just there I think Viper use it now but it's already still uses the loop um so then the mem copy op code fixes all of this and I just I'm trying to read the numbers so yeah it takes like 800 gas to to copy 255 256 bytes um with the Shanghai course with the recent cost is 160 we demo them towards 100 um and the dip it would be 25 by 25 gas we did some analysis um I think like 25 of all the memory copying would be improved by M Copy um and there's actually one feature in the solid compiler which is kinda be I mean it's not blocked by this but it's not implemented um slicing of memory arrays and a lot of cases people are doing like forcefully using call data stuff because that can be sliced in the compiler setting mem copy a cheap mem copy would also improve solidity as a language that's it yes the reason I said I have EIP because um it's almost certainly not for Shanghai but I don't think it's been talked about at all and it's nice to like um get people's brains Brewing on it so um first of all the ones based on this ERC 457 right which is so much the kind of abstraction that's like a way of getting a kind of abstraction without requiring a hard Fork to avoid all those like EIP processed mess um and um this we found that people quite like this approach right because um they can already start using their smart contract vaults but we found that users actually still complain quite a bit about um smart contract worlds because um like they already have their money on elas and switching all their balances and all their all their nfts and everything is just too much for them usually so we were thinking quite a bit about okay like how can we develop a kind of abstraction more how can we perhaps enshrine it a bit and so some ideas just floating around again there's no EIP set and there's no like specific roadmap set but an example is um making a new transaction type which converts an eoa to a Smart contract that you specify in the data field right and this basically should be quite a simple new transaction type there's not really that much complexity as far as I can tell but please love to hear some comments some more advanced ones and again just ideation is perhaps making an EIP which converts all current eoa accounts into a sort of default proxy smart contract World which uses the current ecdsa signature scheme that EO has already used right and another sort of a more advanced one is so this ERC 4537 it works with a so-called entry point smart contract which is through which you root all your user operations to interact with your wallet and this causes a lot of gas because you do all the signature verification all the um all the stuff on chain using well evm up codes right so what if instead you made this part of the protocol right in um that could be validated outside and so it would save usually lots of gas foreign oh yeah just real quick this isn't on that but uh it hasn't been suggested for Shanghai but prior to the merge it had a bit of support uh time aware base fee calculation it would essentially just make 1559 quite proof of stake friendly 1559 is aware of blocks it's not aware of slots you could have say like an empty block with proof of work but now you can have missed block proposal so here we go I think with a with the amount of missed slots we see right now I don't think it makes sense to to do it now uh it's it's like I don't know we're seeing like point point one percent point zero one percent of missed slots or something like this it would be a negligible Improvement to ux so yeah just for a cleanup but not necessarily to have so uh with the wallet uh I think there was three proposals uh I just wanted to mention there was one proposal where uh you said that we could just Auto convert everything uh no that's not going to happen essentially uh that that's already a huge issue for vertical trees where you just want to do an upgrade where the state just gets flipped over and it's a huge linear migration and we have absolutely no idea how we're going to do it for vocal trees so let's not do it twice but what if it's not actually touching every account and rather it's there's no code and there's a message signed from that account and it's treated as a default account and so it falls back to some default code um but that would actually break the new semantics that we introduced with right you know which exactly I mean that no eoa can also have contract code but there's no code in the account and so it's already empty and so it would basically be like me sending a transaction and rather than executing it the same way that we do today it would realize that the recovered address has no code in it and so then it would just start executing it in an evm frame with some default account code that implements the same concept of the ecdsa account okay I couldn't follow so so you wouldn't set the set the contract code you would not set the contract code okay it's a fallback okay I think we're going to wrap up uh it's past six um so first of all thanks everyone for coming um there's more places we can discuss all this this week so we mentioned there's an evm panel where we can get into eof 1153 all that good stuff there's an account abstraction panel uh and we just had some new fresh account abstraction content as well and then finally there's an ERC uh kind of Youth magician session as well um throughout the week I don't know when they are sorry they're all on the agenda is on Friday at Workshop room 4 at 1 pm you heard it um oh product right so Friday there's a session about tank shorting and prototank shorting if you're interested to the helpers of the Erp for Edge refer just please contact us and we are hosting co-work sessions yeah cool yeah thank you so much everyone for coming [Applause]