All Core Devs - Execution #162

Transcript

foreign [Music]

Tim Beiko: welcome everyone to uh acde162 um okay so today I guess at the start uh We've commissioned an impact analysis uh by ddub around self-destruct removal so they'll be here to give us an overview of the analysis and there's already been some conversations in the last day or so about it and some you know potential issues with uh the proposal of uh eip6780 and then

um some counterpoints to those issues so we can have all that conversation and then there's a bunch of stuff around eip44 uh that's uh in the works so it makes sense to cover all of those and uh after that I think uh thinking about like how Cancun shapes up to be um so what are there some things we want to add or remove from CFI there's already some comments about that in the chat um and then Dano has uh Deno has uh put together a proposal to just align the op code uh the opcodes that are used across all of the proposed eips for both Cancun and the next Forks

um and then a couple more updates on some other VIPs so hopefully we get through all of this in 90 minutes um but yeah to kick us off uh sorry uh Neville do you want to give us a rundown of your impact analysis of a self-destruct removal and I'll post the link in the chat

Neville Grech: sure yeah can I share my screen as well yes yes please okay cool yeah so thanks for hosting um yeah so uh I'm Neville Greg from ddop uh we we were commissioned to do a study for design Foundation regarding the

removal of the self-destruct op code or the chain and semantics of that opcode um and it's the theme was basically me Leah satiris all three of us are on the call so feel free to ask us questions all right so the scope of the study was basically to determine the impact of changing the semantics of self-destruct and um self-destruct has recently been used or you know throughout its lifetime to either safely transfer it or to perform upgrades ever since grade 2 came about um but there are also some question

marks you know things like is it going is it actually being used to burn erc20 tokens um things like that so I wanted to find the affected projects we wanted to find the impacts um and all of these things are you know colored by the fact that you know some projects have not been recently used or they don't have a high balance they're not part of the known contract so the impact has to be considered against all of these factors and so we and the other thing is that we have two different proposals and we want to see you know which one or help determine which one to select if any at all right out of these two

so just to give a little bit of an overview of how self-destruct currently works for those who are you know external there's a bit of nuances here because so self-destruct um you know tops what I meant from the stack that's an address and what it does it sends all the Ethan the current in the current contract to the beneficiary address but unlike call it does not actually create a call frame to execute the beneficiaries code so it can be used in a way that even for smart contracts that block you know the receive function um yeah that block the receipt function then service track is still going to

work it also clears the runtime byte code of the current address resets the nonst to zero and resets all the storage bars to zero okay it does not issue a gas refund so that's changed you know uh I think one and a half or a couple of years ago so how is this going to change in EIP 4758 so very simply right it's going to be renamed sandal it's only going to send it to the beneficiary address but it's not going to clear the runtime byte code so I'm going to reset the nonce and it's not going to reset the storage bars so that's a simple proposal there and the way I remember which ones which one

is simple which one is more complicated is by the first number so the simple one starts with a four the more complicated one starts with a six so in eip6780 the semantics of self-destruct are essentially the same as they are now except that there's a condition that if the address and by address I mean specifically the op code address right is created in the same transaction then you do the same thing as in self-destruct you could run them byte code reset demands reset All Storage bars otherwise these these things will

not work they will not happen right um okay so now that we know which each one of these proposals what each one of these does here's a little bit of a summary of what we found in the study so um so first of all um some of these things are subjective so these are protocols which you think are affected some of them are you know we we estimated the impacts too low because they're more likely to be a false positive so we have to clarify for instance in the case of seller over here because we've seen some you know weird Behavior if you know the self-destruct

instruction is going to change but essentially the impact is you know quite quite minimal especially in one of the in the more complicated proposal right so 67.80 um so yeah um I'll go through these one by one just give it a little bit of a summary of what we saw there so in the case of axillary Network XLR creates contracts and then it destroys the contract in order to do some safe heat transfers um now we think that it is upgradable so impact is high but it is upgradable you know so that can can be fixed there is

no impact in the case of the axillary network if the second EIP is chosen that's 67.80 so it can remain operational without any upgrades with the second EIP the case of sorbet is similar to gelato um it's not upgradable but I mean that's that part of the smart contract that uses self-destruct but it really isn't used much right in the case of gelato it's used in conjunction with pine Finance cancer Pine Finance you know we think it's affected as well now I've skipped seller in the case of seller that one's interesting because it

re it seems to replay messages from another chain but the messages ought to be unique and the uniqueness of this message is used as part of the salt when creating a smart contract using Create two and then those smart contracts are subsequently destroyed so we think that in this case if the messages are indeed unique then that's not going to be effective but it's going to take a while obviously to go through the entire seller protocol it's very complicated we'd have to look at the way it interfaces with our chains as well but that's what we think at this

point you know we'll try to confirm with the with the Developers chain hop actually works in a very similar way to seller the parts that has this issue jpegd is affected and then thousand ether home page is also affected as well in theory um but you know we haven't seen an instance in the past where like if we had to replay this these sequences of transaction it would uh we would find the same effect but it is a you know impacted by this okay so note that all of these things

are subjective in the case of estimated impact but from the point of view of like finding potential protocols that are affected that is not subjective we conducted this by you know looking at past during transactions by doing in some cases static analysis of the contracts bytecode as well so we did Cover a little bit Mev Bots as well even though there weren't sources available now if we look at this from a quantitative point of view right so the usage patterns um so we we took at uh we looked at blocks between uh block 15 million and 17.23 million we measured the number of times for

instance that create or create 2 is used quite a few times as you can see over here image dominates there's an order of magnitude fewer self-destructs but interestingly most of the self-destructs are used in conjunction with short-lived smart contract Creations as you can see now potentially this can be impacted by EAP 4758 because there's a short-lived smart contract it's not going to be you know removed at the end of the transaction and so someone else can interact with it but then this is even more worrying so metamorphic patterns where

a contract is created at an address and then it's destroyed in the same transaction and then in another transaction it could be like you know weeks or months after that the same smart contract is recreated and then this one is destroyed now there's been 22 000 instances of this now this pattern will not be impacted by EAP 70 6780 but it will be like outlawed by by this other proposal and actually XLR Network this is It's responsible for a few of these yeah and

then finally this is what we were kind of like mostly worried about so long-lived metamorphic patterns were long-lived referred to the facts that a contract is destroyed in one transaction and then recreated as another a when I say short-lived it means that a contract is created and destroyed within the same transaction now in this case as you can see it's like two orders of magnitude almost toward the magnitude less than in the previous case like the the number of times that this has happened so um

yeah I mean just just looking at this quantitatively it seems like you know especially if eip6780 is selected uh most of these um you know usage patterns will will be will be valid and you know this will not be but then we'll see kind of like most of these 735 upgrades are not actually done in mainstream protocols they are done in you know unknown or MP Bots or things like that it's okay so let me give you an example here of a um an example of a short-lived metamorphic contract so a contract which

is created and destroyed at an address and then created and destroyed at another one I'll share these slides with you guys so you can see but basically these slides are just a they're just a summary of the full document so as you can see here we'll destruct here so this contract is created and destroyed and in the next transaction same contract is created and destroyed

so these two are separate transactions but as you can see like the same smart contract is created and destroyed so this is just an example um in axillary Network um yeah we've also looked at some protocols where this thing is done um or could potentially be done according to how the smart contract code operates but for instance in this case this is a product called revised we can look at sample transaction but there's no need basically what happens is that reverse creates a

smart contract and then I think it transfers um a an nft to that when you withdraw and it uses actually within the creates to solve the nft ID so again this is just an example you know if you want to see more of these you know examples look at the full report let's wait until this loads up but essentially what we think is because of this so so over here this clone deterministic call over here it's gonna pass

the nftid you know some entropy from the nft ID and then that clone deterministic down the line it creates a new smart contract and is going to use you know the nft ID as part of the salt and we think that you know since the nft ID is monotonically increasing there's not going to be clashes in the smartphones that are created so even though like the smart contract can cannot be destroyed if um if the proposal goes through um they're always going to be new smart contracts that are created because of so you know it takes quite quite a while

I mean this study was conducted over two weeks it takes quite a while to go through all of these protocols and and verify but all we need to do um you know essentially now that we have this discussion going on is you know just confirm that the ones that we thought were false positive are indeed false positive okay so um yeah so one of the other things that we try to do is to use static program analysis to find possible behaviors that we haven't seen on the blockchain um so far but they may potentially happen for instance you know someone deposits tokens to a Smart contract or

to some address and for some reason um with the proposal they cannot be you know retrieved right these tokens so someone asked the question um on one of the um amount of forms that is used as to discuss these proposals so what we did for this is we first of all we found all contract factories um so for this thing we um we actually we performed static analysis to find contract factories because um what contract Factories do is that they create a smart contract so they use something like create two but they are

actually within um within the init codes they would have like certain patterns there um okay then out of these okay so we find the ones that do create two and then we applied static analysis and static analysis in a nutshell I mean this is not the real code this is a pseudocode but I'm not sure what it did this um you know if it finds a self-destruct in a contract that was created by these and you know it doesn't have for instance an ERC transfer an arbitrary call like you know contracts.org and allows you to pass in any data or there's no delegate call then

potentially um you know you can have fun stuck in this smart contract after the EIP goes through so we looked at many of these examples I mean many of these were and would be bots of course Meg Bots don't have verified smart contracts sorry verify the sources so I had to use Rd compiler it takes a while to you know go through these implementations and there's you know there's trial in there here so it's not going to be an exact science but we thought that all of them were false positives for you know this particular pattern so we haven't found any examples Okay so

what was surprising is that um there's there's been a lot of discussion about uh create two and self-destruct being used to perform upgrades but in mainstream protocols we haven't actually found this anywhere but if you look at the fine print and you know some of the libraries that are used to do this metamorphic contract upgrades the ux is a problem when you do metamorphic contract upgrades using self-destruct and create two because you cannot do this atomically um so you have to do this in two separate transactions now imagine doing a governance proposal where you propose you know in one transaction you do

something and then the second one you have to recreate the smart contract um so and then in the meantime people might go in and use the uh protocol without with the smart contact number three created so that can cause you know all sorts of issues and then the other thing is that the state is set up you know the mainstream protocol would have you know quite a bit of state that needs to be recreated when you do a self-destruct and create two so that's not used much um it's mainly used in mainly view blocks and there's obviously there's arguments to be made um as to why for instance me view Bots would use that because it's like more efficient to do it that way you don't

have proxies but maybe we'll hear about this um in in the rest of the meeting so you know in summary we think the impact is moderate you know it's like and especially so with eip6780 like we EAP 6780 is not going to affect mainstream protocols metamorphic contract upgrades are low um one one thing that we found is that even though there's a lot of discussion about you know self-destruct being duplicated people are still using it um equally so irrespective of the uses of the ethereum blockchain again but very rarely right and also throughout the study there was a

coincidence that there was some evidence of self-destruct being harmful as well so um so yeah that concludes my you know just just the summary here and I think we'll we'll be discussing a few things throughout the call and if you have any questions just just ask me or my colleagues on the call thank you

Tim Beiko: thanks a lot for for the presentation that was that was very good

Neville Grech: um I guess before

uh William heard us here

Tim Beiko: oh thanks uh William I see you have your hand up before we go into the like set code stuff I just want to ask uh does anyone I guess on the client teams or others have like questions about the presentation or the the report in

general um and then yeah after that we can go about uh you know next steps for the specific proposals but just yeah any questions thoughts comments on the report or presentation um and then if not um I guess you know where we were at uh prior to this report was that uh we included uh 6780 which is uh basically the the second proposal uh mentioned in the presentation um and and allows self-destruct if it's within the same transaction as uh create

call um and so William you raised like a couple cases where uh this could break things uh do you want to take a minute to like walk through those and uh yeah we can take it from there

William Morriss: so I'm a user of the create to upgrade pattern uh I have a prepared statement uh so the report skims over Mev but doesn't speculate why this upgrade pattern is common among Mev Bots who wrote their contracts and assembly the reason is broader than Mev and applies to normal Dex trading indeed any actor trying to get competitive transactions included with any urgency must participate in priority gas auctions off-chain systems are being

built to allow anyone to participate in these auctions such options are denominated and gas used so any upgrade mechanism with any gas overhead whatsoever cannot be used competitively that leaves code replacement as the only viable mechanism for Traders suppose I want to be able to upgrade my code in order to trade on the newest protocol it is much simpler now when I'm able to replace the code without the disability I would need to redeploy to a new account instead every nft every token balance every token protocol approval every staking deposit every registration indeed my entire presence on the Chain has to move over to this new account accounts are identities and moving all your possessions to another

account is painfully expensive if your account is a smart contract having a secure way to upgrade it can avoid such a migration indeed this is the purpose of several of the mechanisms identified in the report such systems are inventing ways to secure the upgrade cost process for the masses self-destruct removal destroys their work set code inclusion renews it we can preserve the ability of accounts to change their code by including set code in the same Fort systems anticipating the fort can prepare by including set code if set code is not included in the same port we can not securely anticipate what the semantics will be it is critical for adoption of smart contract wallets that we preserve code mutability aside I've had some discussion in the uh

topic channel on Discord and uh it seems that it would be a significant Improvement for static analysis if we also disabled set code during uh delegate call and this would indeed limit the scope and risk and make it much easier to identify potentially mutable contracts because you would just be looking for the op code another note is that uh there's uh I forgot that anyway uh I'm gonna read your responses now

Tim Beiko: um and then okay we we had it not happen in the past day uh yo I've put like a a set of security concerns he had about

said code uh in the Discord I just shared him here he unfortunately couldn't make uh the call and then I think what it boiled down to in the Discord right before I hopped on the skull was that if we want to introduce set code as a mitigation for some issues caused by uh 6780 um there are some security concerns with that the worst of them have to do with using set codes within a delegate call and maybe we could enable set code without enabling it in delegate call and and

now it resolves sort of the issues

um and I guess oh yeah mirrors go ahead yeah I

Marius van der Wijden: I have a quick question can we add set code later on is it possible to add this op code later on if we or is it

Tim Beiko: assuming we do we do remove self-destruct right that's what you're asking

yes

William Morriss: so in order to allow contracts that are currently operating with self-destruct uh to remain upgradable through the upgrade it would be better that we don't have downtime in which code mutability is not possible and also it's important

to solidify that op code so that at the time of the upgrade uh the contracts that are frozen are able to be prepared it for the set code upgrade so it's better that they happen in the same

hardcore

Marius van der Wijden: is it technically impossible for them to be separated out

Tim Beiko: what do you mean by separated out

Marius van der Wijden: is it is it possible for them to be in separate

artworks

Tim Beiko: well I guess what if I understood correctly this means

yes but the contracts that are affected are basically bricked between those hard Forks right of of it and I don't really think we should

include this op code now um and I don't I also don't really think we should include this offcut in the future but we can have a debate debate about that um in order to unstuck or like make it cheaper for Mev Bots to to extract mov I don't think um I think this this op code has a huge amount of security implications and we should shouldn't YOLO it thanks uh gilm

uh yep uh I mean basically a lot of it

Mario's already said yes it's uh I think it's a huge security issue but the biggest problem my my question still would be if any of the arguments that that were just uh given in the statement were true uh or at least were significant enough to to to make us consider including set code uh would that's not be like would not simply not removing removing self-destruct be the Superior Solution like does that code offers something that uh not removing self-destruct would not solve in a better way

William Morriss: yes uh so the weakness of the

self-destruct upgrade pattern is that there's a downtime uh in the upgrade itself because the self-destruct takes place at the end of the transaction rather than during it so you must self-destruct in one transaction and then in another transaction recreate the contract set code would allow us to upgrade safely and securely uh in place if you all want more time to analyze set code please uh just postpone self-destruct thank you

thanks uh Ben um if select code and the

Ben Adams: self-destruct

depreciation happened wouldn't that code need to be in Fork before self-destruct because otherwise you couldn't upgrade the contracts to use set code without putting invalid op codes in because it's self-destruct happened first then you couldn't you can no longer upgrade the contracts and if it and that code didn't exist beforehand so you can't upgrade it to

use that code

William Morriss: uh yes so I think it can be in the same hard Fork because contracts can contain

invalid

op codes

Tim Beiko: okay so people would basically deploy the contract with an invalid op code prior to default and then the off code will become valid after before because all right

Ben Adams: yeah but they would be dead contracts during that time

Tim Beiko: yeah I guess I'd be curious to hear generally from you know client teams given all of this how do people feel about um 6780 set code like

do we want to basically I think that you know the first question is we agreed to like have 67 80 in pending the results of like the impact analysis and and and making sure that like not too many things would break are teams comfortable leaving it in regardless of what we do with set code and analyzing that separately or do we feel like the like remaining inclusion of 6780 should be dependent on

set code I think we should leave a six seven

eight here um in in Cancun and analyze set code separately

Marius van der Wijden: I feel the same way if we should um have six seven eighty as soon as possible and uh think about

set code more thoroughly

William Morriss: could we perhaps finalize the op code reserved for set code such that Brick's smart contracts might eventually be upgrade unbricked in a future upgrade

Tim Beiko: yeah we have a whole section about op

codes later on Thanos put a full list so I assume we can at least you know quote unquote reserve one for set code um yeah and we can discuss that as part of that I guess yeah okay so Aragon get on board with leaving self-destruct that is anyone else I guess does anyone disagree with that does anyone disagree that we leave we leave it um we leave the eip6780 in uh we discuss we can discuss insert code it may or may not be included in this upgrade

um and here you know just in the last like 12 hours there was a ton of discussions so there's still a lot of back and forth but does that make sense to people um okay so let's do that uh yeah so no actual changes to the uh to the fork uh inclusion list um and yeah I'll make sure to share well I guess if anyone wants to read the full impact analysis for self-destruct it's linked in the agenda and so people can uh can see it from there okay uh next up eip4844 there's a ton of PR's uh some

devnet updates uh some potential changes for the next devnet and then uh some rlp uh and SSD changes that might affect uh are currently CFI APS so I guess uh to start off a light client you had PR 7062 that adds data guests used to the block header do you want to briefly discuss this

Lightclient: yeah I just wanted to see if there is any interest from other El devs I'm not sure if Peter is on the call but while he was implementing some things related to sync he just kind of noticed that there were some uh it was a little bit different

interaction with the sync code than he was expecting and after digging until we kind of realized that the excess data gas and and the base fee are not as similar as we you know initially would have anticipated them to be so the ultimately the issue is that for excess data gas it's kind of that number is going to be used in the block the uh The Descendant block and so the value that you need to compute the cost of the data transactions is actually the excess data gas from the parent header and for base feed it's slightly different the base fee in the header is actually the base fee that's used during

the execution of transactions and so whenever you do your header validation that's when you are checking that the base fee is computed correctly from the header you know it this is kind of just a um I was sort of sketching out what it would look like to bring those two things in line so that they both are representing the value for the currently executing block and so that's kind of what that that PR is they both do essentially the same thing I think ultimately the question is just do we care enough about having these similarities to try and make this sort of minor change or are we okay with

um you know the status quo personally it's just like one of these things it's another one of these things where if we have the formatting slightly different it increases the overall code complexity of clients like we saw as you know Peter was implementing the syncing code whereas if the you know if we had a similar mechanism already and we just reused that mechanism in most of the same way it would have kept things a bit simpler so that's like you know my thoughts uh probably like slightly favor the data gas used approach in the PR but I'm curious what other people think about it oh Peter's here too

Péter Szilágyi: yeah so perhaps just a slight thing I I

maybe just an expansion to what Matt said that um I think the complexity comes from the fact that previously we had the the fee was defined is defined by the base feed and so essentially we have to head uh two header Fields one of them tell us how much gas we consumed and based on that we can validate the base fees from header to header and the base fee itself if I want to run the transaction I only need to to look at the current blocks base fee and with the the blood transactions we kind of merged these how much we used and how much does the next one cost into a single field and because it is a single field it makes basically everywhere where previously so previously when we

validated the header chain we just looked at the header fields we don't care about the block contact at all and then when we ran the block content then we just needed to look at the current header and since this field somewhat got convoluted it somehow means that I need to be able to both look at so when I'm when I'm running the blocks I somehow need to both look at the current header and the parent header similarly when downloading snap via snapsync because there I even if I'm not running the blog or executing block I'm still I still want to verify the blog body and uh the thing is that it doesn't really matter how we interpret access the access data gas whether it's for

pre-execution or post execution the thing is that I if I if I convolute these two Fields together I will have this extra complexity that all validation code will all of a sudden need both the parent header and the current header yeah whether this is something worth I mean the week one solution is to go with the current status quo and make the code around this structure a bit more complicated the other solution is to split out the the two Fields so that it follows a similar pattern to base fee and date and gas used and if you have the two fields and the code around you

become a bit simpler yeah it's not that complicated it was just something that that was surprising to me that it's a new mechanism something that was kind of unexpected

Tim Beiko: thanks uh Andrew

Andrew Ashikhmin: uh yeah I think uh in Aragon we kind of we have separate stages for headers and and bodies so uh I would be very much in favor of uh making the change so that that we don't need a parent's body to to verify the a block so yeah I I'm totally in favor

so with this change we only need parents header not not parents body correct

Péter Szilágyi: um no actually uh so what the origin current uh thing requires if you want to verify the current blocks body you need the parent header so that's the GUI thing that the current transactions require the parents header that the witnesses uh with the proposed change you could verify the headers completely separately and then when you want to run or execute a block you only need to look at the current header you don't need to look at the parent header at all so that's that's how currently everything else

works with Fields being split out so that's the cost I see so for example for us the complexity was that uh our in our in when we are snap thinking we essentially also have this two-phase thing where we download the header separately and then for every header if they're the the transaction hash is not empty meaning that there are transactions then we download the body block body and just fill the header and up until now we just said that okay I want to fill this header I downloaded the body contents and then I just mesh it it does this this transaction list

match what the header wants and if yes great and now with the blog transactions what I need to do is that after I'm downloading the the list of transactions what I need to do is that okay okay but now does the access data gas also get computed correctly for which I think I need the parents access data it gets a bit a bit funky it's it's doable so the way we did it is that from now on our downloader instead of a download task is a single header it's actually a header and it's parents so I mean it's not specifically complex but uh for example it makes uh if you interrupt synchronization and resume it then you will also need to dig up the

parent of the first header and yeah just these little tiny weirdnesses all over the place where up until now you you just had a single header and now you just need to and it's it makes things win wonky but again the question is is it worth it to add an extra integer to the header field or is it too much and I'm I don't want to make this decision really because the current design isn't that painful so if if people say that it's not really worth it to stir up the wasp nest for it then I can live with the current whatever design is

yeah I mean I think like this one simple thing is really not that big a deal but it's more of this mindset and I'm like worried what will happen if you know every Fork there's that one small thing that doesn't really align nicely and we could have just fixed it if we have that mindset in like five or ten years you know how many like special edge cases are we really going to have I think a lot

Tim Beiko: right I guess given that given Aragon's comments does anyone think we should not do this change so Deckard had a point about sort of refactoring the execution gas in

a way that might make the current thing before I perform make more sense I don't understand uh you know what he's envisioning well enough to really defend it but I wonder if anyone else has it written somewhere I don't think I've seen it yeah well so I guess I'm also a little confused like there's like maybe two things here one of them is just changing how it's just computed and moving to like a nicer sort of math to like better approximate exponentials separately it sounds like this change that we're bringing up right now is unrelated to that and it's just more about how do we actually validate these things is that correct yeah yeah I think it's it doesn't have anything to do with

the exponentials but more like what is the order of validation slash where do you get the data for validating and I don't think what Dan card is looking at doing it involves getting rid of the gas used field which is like kind of what allows us to make the base fee in the header the base fee for that header's block and that's kind of what we're missing for Access Data gas

Alex Stokes: yeah so maybe if there was pushback it was a miscommunication um I'm not sure but yeah it sounds I mean does anyone think this is going to push back for it for four timelines too much

oh Andrew

Andrew Ashikhmin: yeah I just just wanted to say

because I think um it doesn't so so yeah I misunderstood it in the beginning uh because I thought it eliminates the need to get so it's it's it's it's not relevant to parent bodies so I kind of I need more time to look at the proposal so I I don't have a position on it at the moment

Tim Beiko: does it make sense we have the 4844 call on Monday does it make sense to give people like the next two three days to look over it and and make a decision on the 444 call Monday sounds good to me

yeah

Tim Beiko: and if people can't make that call just leave your

comments uh on the pr directly and we can uh yeah you can consider those on the call okay uh next up uh a letter PR please sorry can I just uh add one more thing uh I don't just actually asked how this whole thing relates for example the live clients if you

Péter Szilágyi: want to to just verify the headers but don't have the bodies because obviously you don't download the bodies and the short answer is that a live client will not be able to verify the access data gas in its current form so the same way that a light client

cannot verify the gas used field because you need to run the transactions the same way a light and cannot verify the access data gas the the part of it which which tracks how many blobs are included and the other problem the this is another one of those weaknesses because even the light client can verify the the base fee but it won't be able to verify the block see because it's because of this dual nature of the like Access Data gas so for light clients you would just need to take it for granted that that field is correct

about um yeah again with live clients it's a if we're following the if we assume that the consensus network is on a semi-good chain then a lot of validations could be omitted I mean you could even debate that if the consensus client tells you that this is the header why even bother validating anything just roll with it so yeah again so it's not really end of the world it's just just a quirky thing that we have to decide which Quirk we want to live with

Tim Beiko: got it thanks

um okay next up uh this is like an old PR um that uh recently had to move in so uh refactoring the validity conditions for blocks so I believe was this is the thing where the blocks didn't actually check whether the blob cap was exceeded and only the individual transactions

did

Alex Stokes: yeah uh so onsgar is working on this I don't think he can make the call so I will answer any questions on this PR and yeah that's basically it some things kind of got dropped and I think the main change at this point is

exactly what you said so there is no way there's no way currently in 444 to specify that there's only so many blobs per block if you look at the current spec I could send uh maybe only a few blobs per transaction but I could send you know as many transactions as I can pay for and then now there's like you know 30 megabytes of blobs so it'd be nice to have this defined uh at the El and that's what this change does

Tim Beiko: got it anyone opposed to this like it seems pretty straightforward okay then I guess we could probably go

oh yeah sorry I was trying to find the button

Péter Szilágyi: um I think it was done yesterday who said that this field is uh already validated by the Consultants client my two cents I already wrote it on the channel too that in my opinion it would be nice to have it validated by the execution client it's too simply because well I wanted this simpler and I mean safer and the other is that I think it's um it would be useful to have the validation somewhat self-contained so basically have everything so that if the execution if I just give a batch of blocks to the execution claim then it can do as much validation as possible

maybe it cannot do chain selection but it should be able to verify everything else and this this uh extra check is needed to to forbid blocks containing hundreds of blobs

Alex Stokes: yeah I think we all agree and so yeah like it seems to make sense to me to like keep this in line with execution gas where it's like yeah there's a limit at the yell and that's sort of the ground truth um there is a cap at the CL but that's more networking thing at this point and again as we've discussed you could imagine this kind of varying independently uh subject to each layer be uncomfortable with that

Tim Beiko: okay so I guess we can go ahead and

merge this um whatever and Scar uh is ready okay uh Next Step okay so uh devnets so uh Barnabas you wanted to give a quick update five and then you had three PRS related to uh devnet6 um so let's do that um Barnabas

Barnabas Busa: yeah sure uh so to recap it uh in the past two weeks uh we had a long period of uh non-finalization on devnet5 and it ended up trading 900 validators accounts to force them to exit and we managed to

get into a final estate again with the lighthouse another mind and at that point we had 100 relators running on a single node and everyone was able to catch back to that using a checkpoint sync and I decided to make some new deposits so we can still see if any of the validatories go offline now so I made a thousand deposits yesterday to it and these are being processed right now we I noticed something that everyone get ejected about uh at balance of 31.7 which is a bit strange because uh in the config I have started to being ejected ejected at 31 so I'm not quite

sure why that happened uh here you can config for this and in the interruption we had some discussion about it

oh benz's hysteresis can you expand on uh if my microphone's working yes um yeah

Ben Edgington: it would be based on the effective balance and when the node's balance drops below 31.75 E the effective balance drops to 31 East so if you set the ejection

balance to 31 then when the actual balance reaches below 31.75 then you'll trigger the ejection which sounds like what

you'll see

Barnabas Busa: okay yeah that makes sense then I I have no idea anyway uh right now we are finalizing and we have about 500 Rogers on the Chain right now so it's looking quite nice now next we also have a beacon chain Explorer running with noise another thing is uh definitely six specs are being collected right now and I'm

open for including anything or not including anything else we have a link for that too there's quite some PRS that I would like to include in Denver six and this would still be a 4844 specific devnet and then hopefully devnet7 be a then from that message would combine other PRS that are not related to

3844 thank God that note 7 would come in a like but first we should focus on that Netflix launch yeah

Tim Beiko: yeah that sounds good and I see okay so

I'm looking at your docs now and I think some of the PRS yeah basically the a lot of the red PRS are the same ones uh gijender had up um and we can I think it makes sense to probably take most of the call on Monday to uh to go over this list that you have but uh do you want to discuss the three that you brought up on the agenda for today so first of all was uh 70 38.

Gajinder Singh: so so I'm just putting it okay so what 7038 does is it basically refactors a little bit uh how the

network payload is uh built so it's now first the transaction payload then blobs then commitments then proofs earlier it was transaction payload then commitments then blobs and proofs so it just I mean it feels nice this way and the second thing it also adds clarification that the blobs are flat uh otherwise there was this interpretation that we also had discussion in the Discord that each blob itself is a list of field elements so this PR also also flattens out the blobs and in a big Indian way and then

it just adds some it just clean up some references and add some validation conditions that were missing

Tim Beiko: yeah I see there's been a couple comments on this with any other thoughts from anyone on the call okay next up uh so this is following um or discussion last time following our discussion from last time about uh the pre-copal inputs uh to be encoded as big Indian

yeah any thoughts or

yeah I think in in the content aspects uh that kcg big Indian change has already been merged so okay

Gajinder Singh: this is quite natural then

Tim Beiko: sorry someone else was trying to say something yeah assuming there's no no more issues we can probably merge chat as well and then uh okay this one was to the execution apis to basically add a data

guess use did a gas price to receipts in Ford for transactions

you know

Gajinder Singh: it just has those fields in the RPC response

Tim Beiko: yeah and I guess yeah anyone have strong opinions about this okay so it probably makes sense to include it then I think like client had a comment there saying that we want to wait until uh we effectively have the full set of changes uh for Cancun so that we can merge them all at

once but um that seems to be the only concerns and Roberto's saying that yeah some uh Yale clients already have prototypes for this okay so um I think that's how we had in terms of PRS for today uh and yeah let's let's uh go over uh barnabas's list for devnex 6 in more depth on Monday's call um as well as uh the pr that uh Matt opened which I'm now forgetting what that one was about uh scrolling up

sorry I have way too many tabs up in here okay yeah the data gas used to the header so let's discuss that more thoroughly on Monday as well cool uh okay and then okay last thing effort for four um so we agreed to move it to rlp um that said we had two we had uh basically included the SSD optional EIP in Cancun and we'd also cfied uh six four nine three the SSD transaction signature scheme there were some comments that um there were some comments

um that we should remove those yeah there were some cons that we should remove those uh given we've moved forward 444 to rlp instead um yeah does anyone think we should keep any of the SSD eips um either cfid or included in Cancun okay uh no objection so okay I'll do this after the call I'll take 64.75 out of the included list and I'll remove uh 64.93 from the CFI list anything else on 4844

okay then next up oh yes please go ahead small question uh should we like um again we have empty two Fields uh as well as I remember but we do not want did not want that because of SSC uncertainty in terms of encoding and so on uh but for now we can help it like empty two in a little bit do we need still to move uh prohibit um empty two killed I'm sorry I'm not sure I quite

understood is this about the like contract creation yes

yeah so Banning contract creation uh from block transactions right yeah uh what is the reason could you uh yeah do some words someone who has great motivation to bend this ability I can take a stab

Lightclient: the original reason was partially motivated by the fact that this thing was not well specified in SSE but I think that there's still a good reason to do it and that's that

we have these two op codes for creating contracts and there's not really any particular use case that I'm aware of where we have to have the ability to to create a contract via an Ela and through the hard Forks we've seen that this is one of these frustrating things to test because for every kind of change to the transaction and often for new OP codes new uh functionality of the evm we have to test in the context of both um just normal execution and then always in the context of a knit code both in the create context of it with create op codes and in the context of the create

transaction so I would like to move start moving away from using you know having create Trend create transactions in general and simply rely on just to create functionality within the evm oh I see

a sense as

Tim Beiko: you see also on 444 if not uh okay so Daniel you put together this document because we're

proposing a bunch of opcodes for Cancun and Prague and it's all starting to be a mess and you have a proposal for how we can make it a bit cleaner I'm not sure if you're speaking but you're

okay yes you're admitted now

Tim Beiko: and we see your screen

that's just

Danno Ferrin: yeah so so this is a like like Tim said there was a lot of op codes coming in a lot of space being occupied and moved around um part of it I'd have to say was was the early responsibility of the uh eof because they are occupying um three key opcos the last of the Five series um which so here's a quick overview of the of the

opcode Box we currently have right now um five is what was basically filling up having the storage memory control flow and that's where the initial eof control flow op codes went in so the proposal um starts with with a couple philosophies um one of them is to move all eof only op codes that only makes sense that you have op code containers to a separate block the e-block and that moves the 500s out of the the 5x is out of there and then move everything back to the block where it makes the most sense so that would then move T load and t-store back in the 5c and 5D probably and copy if it passes um into 5e um this does not affect blob hash or Beacon root Beacon root might be out

that's a late breaking change overnight and then some proposed changes in the F Series F series is filling up um there's another proposal for another series of call call Twos um later on in this meeting so is there a space for those reserved space for pay and I guess we need a reserve space for set code AS mentioned earlier in the meeting but the the purpose of this is to get a more sensible packing and grouping of the op codes and um to fill in the space left by eof moving into its own block um so this is what's proposed t-star and T load are currently in and everything else and blood hatches and everything else is is speculative um to be added at some point if it

had added at all

anyone have thoughts questions comments can we assign set code in this meeting um again

Danno Ferrin: until it ships they can move it move away but my thought is it should be in the F series rather than the four series and I think the last F series available is FC so we could we could put that in as as the current location for it

um Alex

Alex Beregszaszi: um yeah regarding the the UF side we

have been discussing you know these op codes in like the last two or three UF breakout calls so I think we're gonna do this uh in any case for UF um and you know I mean that there's no question about that we were really in favor of moving it uh from the U.S side

Tim Beiko: sweet

Charles Cooper: anything um there was a bit of discussion of putting M Copy at Xerox for f which is like slightly before the 0x5 series

but I don't know if that really makes so much sense it was just an idea

Danno Ferrin: so the reason I wouldn't want it in 4f because those are all focused on block data ones stuff that might come in from the environment you know what's what's the different block headers the only reason that push zero got put into 5f is because of some fun math relating to the push series operations otherwise I would have put it somewhere else rather than in 5f so putting um and copy at 4f I don't think makes quite the same sense um I think a better home with it would be um at five the I think the 5e is where it would be at

yeah okay cool

Tim Beiko: is this something we should try and put somewhere better than um the hike MD under your handle yeah I know we have yeah we have something similar for transaction types somewhere

execution so

Danno Ferrin: so that's exactly what I was thinking I wasn't sure if the right place for this was for the execution specs or is it informative EIP so to get the discussion rolling I just did my own hack MD put it into the link and then we can move it in and out and if it's kept

there it should be kept a live document as um proposals become non-viable they should be removed from the list and as they become viable maybe some speculative opco placings but again shipping op codes get priority over discussed

opcodes

Tim Beiko: yeah I think where is uh like client are the transaction types in the execution specs is that where we yeah they're in a folder called lists signature Dash types and there's a readme in there and that also keeps track a tentative signature types

Lightclient: so this is this pretty similar thing um I don't think it would go in the

folder lists I mean maybe but yeah it makes sense in execution specs in general yeah

Tim Beiko: yeah I I kind of like lists because like I think I guess it is a list of

op codes and and the thing is it's not it's a list of like semi-reserve opticals right it's not the spec like once they get merged they become the spec right um right but this is like a tentative list

Lightclient: yeah I mean I think it fits well within the other stuff like having CFI eaps and just having like an idea of proposed changes for Forks this is just a different way of looking at the proposed changes for Forks

yeah

Danno Ferrin: um okay I'll uh make up a PR for

execution specs that includes all this and I'll try and follow the signature types um but are there any objections if I were to open up PRS against uh t-store to move the op codes for Cancun all right I'll do that today too

Tim Beiko: yeah thank you this is a really great talk yeah um a couple more things on the last call we briefly discussed uh we've briefly discussed

um trying to make some decisions on this call about any other eips we might want to include uh in uh Cancun um so a couple I guess uh 4788 has had some updates uh since the last uh discussion and then uh I believe there's a new proposal for revamp call instructions and uh there's a whole bunch of other proposed eip's um so I guess quickly maybe uh Alex uh Stokes do you want to give it a quick overview of the changes to 4788 then Alex barragassi can give a quick overview of the call eips and then we can hear from clients about what they

feel uh might make sense to include in Cancun sure so this kind of continues from AC DC last week the way that 478 was before the current update was that it would add a new OP code uh something like beaconroot and that would basically call out to some storage in the execution State uh where these blockers would be this is like kind of merging two different mechanisms with like some sort of pre-compile like thing and an OP code-like thing so we kind of decided it would just be cleaner to bite this bullet on a staple pre-compile and so that's what the current update does

um yeah basically it's just a pre-compile like we're all familiar with um it happens to have access to execution States and that's where this data is stored this is a bit different from say like how block hash works today where rather than read the execution stage there's this history buffer that just happens to also be there and the idea is that you know in an Ideal World the state transition function for ethereum would be a peer function of the state and not rely on this like other little history thing and this is implications for Baylor's clients and things like that so I think we well at least people who have engaged with us so far I think generally like the staple pre-compiled Direction uh Marius has an implementation in Geth I think for both things but definitely

the staple pre-compile and yeah I think the change has been merged already um so yeah I think that's not too controversial the other big thing was and probably the last question on this was just discussing how we actually went to key these roots so we assume then we have the staple pre-compile and now we basically need like some input data to like you know figure out okay at the slot or maybe this timestamp what was the actual Beacon route yeah so from here there's I mean those are probably the two big contenders is like either using the the El timestamp which is sort of a proxy for slots or

introducing some way to map into the CL SL slots uh while we're writing this thing into the El State and doing that so the catch there is that we don't want to violate like the barriers of abstraction between the EO and cl so it's it's a little tricky yeah I guess maybe I'll just pause there um does anyone have any questions so far okay uh the one thing from here then is maybe if I can just ask Mario's directly um because he had some feedback via the Prototype yeah I can grab it

is Mario still on the call

Marius van der Wijden: yes I'm here so the Prototype is very prototype um and it has it has both the state for pre-compiled and the op code um implemented um in the beginning it was specified as an opcode but I think the an OP code basically the op code like the idea is that this data is going to be in the state because otherwise we would have a separate storage segment that nodes would need to maintain and which would uh complicate the state transition function

basically the state transition function would then be the state the transactions the header chain for the last 128 headers for the block hash op code plus this additional storage field storage segment that keeps the um the beacon rules and so what we decided on is to move this well what Alex proposed was to move this into the state it feels kind of weird to put something from outside into the state but it's I think the best

it gets it needs some getting used to but in the end I think it's it's kind of fun and the um so so uh why we decided against the Prototype or why I was well I am against the not the Proto of the opcode is that this opcode would read storage slot storage slots from a specific address but that would mean we have this kind of address that has some storage slots that is not really a pre-compile and so that it would introduce a new

paradigm so the we have to introduce a new somehow and so I think the best way to do it is to just add a pre-compile that returns this data and now the only open question for me is how are we going to key this data

Alex Stokes: basically yeah so in the Prototype I think you just wrote like the timestamp from the header which at least to me is like half of the problem so the problem with this is that if there's skip slots it's like very unclear to the caller how to like find the actual next route

Marius van der Wijden: why

Alex Stokes: because there would be gaps right so like basically you're saying um you know time stamp let's say t0 I write the root let's say there's like four missed slots and then now there's like some time slam some time stamps and like you know much greater than just 12 seconds um and then if I want to find the block route for the next thing it's just like because the way that it's written is I would read back you know basically zero as the root and then I would not really know what to do I would need to like jump forward some amounts that I just really don't know and then have to like search through the contract basically

but

Marius van der Wijden: so I'm not really sure how this

would be used by contracts um yeah so that I mean yeah that's a good question so like one example would be I have a slot

Alex Stokes: and you know I guess where I'm coming from is I don't know if it's missed or not I just have some slots because like you know I know there's 64 bits and I can just pick one out of that out of that type space so I have some slot and then I want to know what the root is and like that would be the API I would like the thing that you're kind of suggesting is more like I as a caller also need to know kind of ahead of time that like there was already a block there um which you know might be an okay relaxation

Marius van der Wijden: oh oh oh we could even turn it around

um and say that it's it's keyed by Beacon route and the value is is the is the timestamp the caller could say I have this Beacon route what is the timestamp for it if it's only about needing to know that a specific Beacon route was there at some point

Alex Stokes: um right so yeah let's zoom out a bit uh just to respect everyone's time here um has anyone else looked at this and or feel strongly about including this

in in uh Cancun

Marius van der Wijden: oh I don't feel strongly about including

it in Cancun by the way I think it's it's nice and it should be included um but I'm not sure if we should include it in Cancun

Alex Stokes: okay does anyone else have any input because I think we can resolve this like key question one way or another and then from there just a question of do we want to also include it in Cancun um it would help a lot of different applications that people want to use like for example in the chat uh Georgia has called out you know all sorts of things around accessing Beacon State and execution layer um and the other thing is this does kind of tee up other things in future Forks

uh like exits so there's ways in which this like tightens up the staking model that are like really valuable and just change kind of leaves the groundwork for that so in that sense I think the sooner the better just because it unboxes other stuff they want to do

Tim Beiko: and I guess yeah maybe if no one has Strong's opinion strong opinions on this do client teams have strong opinions on if they want to include anything else at all uh or or not for now and if there are things you know that are not

for seven eight eight that they want to include

Andrew Ashikhmin: um we would like to include 5 9 20 pay op code it's a simple usability Improvement

Tim Beiko: anyone else have thoughts proposals

Alex Stokes: I mean it might be helpful just to hear you know the ammo we currently have which is what 4844 t-store and one of the self-destruct things like

do we feel like there's room for another EIP at all uh could we discuss uh M Copy and pay

Tim Beiko: and okay 37 as well which is the BLS okay so I guess we have four minutes yeah maybe if we can do like if anyone has thoughts we can do M Copy pay and then Alex if you want to do uh the calls uh of codes um but yeah let's start with with M Copy uh Charles you have an update on it or do you just want to get the feeling from

people

Charles Cooper: uh there's no update on it I brought it up a couple calls ago and uh I think you said you wanted to give everybody time to review it and I think people have had time to you know review and think about it so uh I guess maybe we should discuss if there's any um reservations I think Marius said you know maybe you know along with kilo and she starts too complicated which I don't my personal feeling is that I don't know about that because you know they're affecting completely different separate regions of the evm but if anybody else has similar or other concerns I think we should discuss those

um did I know so M

Danno Ferrin: Copy is relatively easy it's it's kind of like the return data copy there's a lot of well-worn testing path on that so I want to hear Mary's opinion but for pay um I think we need to discuss it in context of the new call 2 Series and as to why pay is needed if it's just to make things cheaper I think called two will handle it but I don't think we have time on this call to discuss the pros and cons of pay versus call 2.

Charles Cooper: pay is not just for for guests there's a number of high profile re-entrancy attacks involving sending ether um that would be easily prevented if people had a way to transfer either without transferring execution context

Marius van der Wijden: so I think the pay-up code kind of

enables hey I think it's a it's kind of good it's something that we should do um but it warrants a whole new like uh we really need to look at the implications of it basically it enables a new way of a contract touching another one and um so this is usually where like most of the bugs are I don't think we have like I personally don't think we we have enough time in for testing

um this with all its implications it has on the other uh the on the on the other things

Tim Beiko: uh William

William Morriss: regarding the payout code we already know that contracts can uh receive ether in other contexts such as from mining new blocks and from self-destruct so the payout code shouldn't introduce any new security considerations because anything that it allows is already allowed

Marius van der Wijden: it's not about security and considerations on the on the smart

contracts it's it's more about like how is it implemented and um like basically we need to we need to test this up code with every combination of everything ever and this this kind of makes it very complex

Tim Beiko: okay and we're we're already at time um Alex uh Burgess do you want to give a quick up a quick overview of your eips um just so people have the context

Alex Beregszaszi: yeah so

it is called revamped constructions and it was pushing the AIP Reaper only today but the work has been uh and the number is 1769 and but the work on this has actually started in January um during ghetto wise uh where the requirement for UF was brought up to try to eliminate gas observability and we designed the replacement call instructions at the time with that in mind um but then maybe like three UF breakout calls ago we realized that these instructions are actually not dependent on the UF and they could be just introduced in the current evm

um and there are two benefits to to doing so one um if you read the the specification it actually simplifies a number of rules regarding gas and there's some a number of cases where it would be actually much cheaper and better to use this new kind of call instructions instead of the the current ones and so existing Legacy contracts you choose to do so would would benefit uh and the second reason why it would be beneficial is uh if this would be introduced in a different hard Fork than eof then the UF changes would be much smaller because the only change there would be to reject the the current call

instructions and these new proposed call instructions would be already would be already there and then you know what these instructions actually do you know basically they're there's the gas observability uh which is you know one big push we wanted to get rid of um so here we removed the gas limit input and we just rely on the n6364 true we also changed the way the stipend works it is much more simplified there is no output buffer address because return data copying and return

data size can be used instead of that there has been a number of discussions with solidity how it actually uses um and the call instructions and some discussions with wiper and then the the last change is the the return value it actually returns more um it returns success reverting failure and the back when the revert feature was introduced there was a plan to add that status code to the calls but it couldn't have been done at that time in the Legacy call instructions because contracts were depending on on the behavior and introducing that would be would have been a breaking change

I guess I don't really have time to go through everything but there's one more comment I wanted to make and so there's this version of the EIP which is in in draft mode um but as we went through it we realized that there would be another option as well which would mean that these cool instructions uh wouldn't they would check whether the target is an actual contract so it would do an xcode size check and the call would would fail if it's not a contract on the other side um doing so would simplify the roots even further because these call instructions would only be usable to interact with contracts uh what this

would mean is that you know something like a transfer or pay instruction um a separate transfer of pay instruction would be needed in order to to establish where you transfer to eoas or non-executing transfers to to code accounts yeah I think that's that's that's in short and you know ideally something like this um will be included in Cancun and then UF would be much more simplified for a fork afterwards

Tim Beiko: um okay we're already quite past time I

don't know if people have comments on uh yeah under specifically if not I guess what I'd suggest is um clearly it seems like we're probably not in a spot to make like the final decisions about smaller eaps a day and we're not even in a spot where uh 6780 uh and 444 are fully implemented in clients um so I would suggest I don't know if we want to CFI them but it seems like uh M Copy pay this call of codes as well as the existing um as well as the existing blsp compile

and 4788 eips are sort of the ones we're considering so um should we move those three other ones so like 59 20 56 56 and then the call one to CFI and sort of restrict the discussion at those and yeah we can see in the next couple weeks uh how how things progress so anyone object

Alex Stokes: that sounds fine I don't think we should add more and if anything we should probably buy us towards just freezing the current set but right yeah

Tim Beiko: so that's what I'm saying is like we we freeze the current set with those things everything else is de facto sort of excluded obviously there's some

the last minute issue we can always change things but that gives us like three eip's currently in the fork and we'd be up there uh I believe five cfied ones um because we have three now adding three and removing one

Alex Stokes: right and 444 is a big one just yes so we're all aware

Tim Beiko: yes okay we will let them know by client um Sweet let's wrap up here we're already uh over time appreciate everyone uh sticking around and talk to you all on the next one of these

thanks Tom bye

Péter Szilágyi: thank you

Ahmad Bitar: bye

thank you all right thanks bye [Applause]

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.