All Core Devs - Execution #160

Transcript

foreign [Music] [Applause]

Tim Beiko: hello everyone welcome to

acde uh 160. um I just posted the agenda in the chat I guess the biggest thing we should do today is discuss uh potential VIPs for Cancun and um yeah in the context of 4844 being kind of the main thing we're we're working on um and then on the foil for Forefront I think there's two conversations uh that uh that we want to continue one is just uh the uh the reorgs uh the reorg handle handling for um blob transactions and uh second I know that we have been working on the

last 444 devnet this week so we can kind of share an update on that and how that's going um yeah and I guess maybe to kick it off um so on the Cancun side uh so so far we only had a 4844 which was um which was uh included we had a bunch of other stuff which was previously CFI the bunch of other uh even more other stuff that was proposed and and still not quite cfied um I I compiled a list in these magicians um but maybe they kick it off I'd be curious to hear from just the different client teams like what you all feel is the most important things uh to do in in Cancun

um yeah and we can pick it from there I know I think nethermine was maybe the only one that answered async before so maybe it makes sense to start with never mind and then others can can jump in

Łukasz Rozmej: so uh I think it's more or less what we what we answered on detail magicians call not call sort of thread so definitely uh for eight for four uh definitely we see a need for uh six seven eight zero um what else one one five three we would like to proceed with that because that

was already postponed from Shanghai and this is kind of ready so uh I don't see like much effort to to push it out I don't see a point for it to be delayed uh then in the more maybe uh State uh two five three seven f4788 and 5920 while uh like bigger things like um eof as uh more things around SSD that are not if they are not necessary anything like evm Max I would consider for some some of the next hard Forks

Tim Beiko: got it thank you

Matt Nelson: Tim this is Matt I can pick from the basic side that actually mirrors us pretty much entirely we have very similar thoughts on the list um maybe with the exception of 4788 but other than that it's pretty much the same um same list as provided by

Tim Beiko: and what do you think about 4788 do you think it's more or less important than what other mine said

Matt Nelson: uh it's similar like in terms of you know we think it's very useful but the scope wise you know maybe kind of in the same pocket as maybe rather like weekly support

okay um anyone from guessther Aragon

um ESL forever gone

Andrew Ashikhmin: um it's important to get uh 6780 the self-destruct removal and I think it's unrealistic to deliver uif uh alongside uh 4844 so I would postpone aof to Prague and yes now otherwise I think we can do maybe a couple more smaller

leaves

Tim Beiko: okay and do you have yeah do you have any preferences or just not really Beyond

uh self-destruct in Port four four no

Andrew Ashikhmin: no preferences I can ask the team

members more but I don't think we have strong preferences yet

Tim Beiko: got it um thank you and guests

Péter Szilágyi: yeah so uh as for us I mean we haven't really thought about specifically what AIP is to ship or not ship um personally for me priority is getting 4844 out so anything large is in my opinion unrealistic beside it thing about the UF smaller ones I mean self-destruct for sure and any other smaller stuff I don't necessarily see an issue with that but I kind of feel that 4844 should be the

thing that everybody focuses on and the rest is kind of like good to have nice to have

Tim Beiko: um so it seems just yeah from those four um clearly the self-destruct one is like the second most important or like the second most uh you know mentioned EIP Beyond uh 4844 um and also uh so with six seven eighty we've hired an uh auditing firm to like analyze the impact of it on on the chains so in the next few weeks we should also have some data on like which contracts uh might be affected and whatnot um but I think that's probably one where

it makes sense to you know formally include it um I see Danny and like client you both have your hands up yeah if this is about self-destruct uh please go ahead but otherwise I think this may be one we can wrap up before we kind of dive into the rest okay so I guess does anyone like oppose including uh 6780 so the self-destruct and this version is the one where you allow self-destruct only if it's in the same transaction as like a create call and otherwise you effectively use like the send all um semantics where you just return the funds but don't destroy the contract

Danny Ryan: is this conditional upon the analysis not finding anything that we don't yet know about and if we if it did we would at least open up the conversation

Tim Beiko: I guess it's worth highlighting there was another proposal for self-destruct that was slightly different so I think um aksik put that one together which was you you do like a sort of fake self-destruct where you actually hide the storage and data but you don't uh you don't delete it from the from the state yeah and so yeah that would be another path forward

it seems like people don't prefer it as much right now but um yeah I guess I'm curious yeah from Klein teams does anyone have an opinion on like Danny's question like if we find what would be the thing that we we would find that would like you know potentially make this a show stopper

Danny Ryan: um I know I see I don't know William it's hard for me to say I just I just kind of make a commitment to like revisit the report on this call just and that seems like the point of doing the report you know one is to give information Community the ones get the other information to us so I just want to like if we move forward with it right now to make a commitment to looking at

the report together

Tim Beiko: yeah I think we definitely definitely would at least um and I guess the question is do people want to make this commitment prior to the report being out or I think it's going to take probably like uh I think it was like three four weeks so like you know say like a month from now is when we would probably know um the people prefer to wait a month from now before making that making that decision

Lightclient: I think it makes sense to make the decision now if everybody is okay with it and then revisit it after the report happens

Tim Beiko: does anyone disagree with that I Know

Dan grad William you both have your hands up so if this is related to

self-destruct um peace

Dankrad Feist: I mean I I just want to say like it's very hard to believe that the report will find nothing like I think like we're very likely going to find some contract somewhere that somehow will be broken uh the question is like do we make a judgment call or like um yeah killing that contract because we believe either it's like so low in value there it doesn't matter or that uh that the owner can like do something else and rescue their funds and and all that like

um basically yeah like I mean it's just like it's it's very likely that we'll find something I will say if we do start building something now and we see a chance that like even even the discussions might not even go towards like we can't do it but it might just be delayed because like we need to talk to a lot of people uh then like we should probably design it in such a way that we can shift without without that implementation I feel like it should be largely

orthogonal to foreign

Tim Beiko: got it thanks uh like client Sir William

did you want to add anything to that

yes uh so we're neutering self-destruct because of the unbounded scope of removing all of account storage the problem gets worse in our vertical trees because vertical trees are flat but vertical trees don't actually prevent code changes uh so if self-destruct is modified I wish to retain the ability of accounts to retain uh to change their code and also improve the way it's done I've interacted with three different upgrade patterns in my career I wrote some of the earliest contracts to upgrade with delegate call and I've written an account ownership system to facilitate self-destructive grades uh my proposal is set code to preserve that ability if we have to remove it from self-destruct so that is if we're not

doing uh access proposal that would just change the nuts to the account and use that as a marker um uh so set code uh improves on the self-destruct upgrade pattern uh by uh chain uh allowing a way to create clear storage or not clear storage when we change the accounts so uh it's we don't want to be able to uh clear storage because that's unbounded so it just simply makes a way to change code uh in a safe way uh it's it's as safe as all the other current upgrade patterns uh and it should be a simple change to add on to any self-destruct removal

Tim Beiko: so this set code just to make sure I understand

you can change the code at the account but not the storage correct and this means you can like have a contract who's like semantic you know changes its semantics but keeps the previous storage right

yeah

yes that's correct and uh this is the period of the current self-destructive period pattern because these self-destruct upgrade pattern requires two separate transactions because the self-destruct doesn't happen until the very end of the transaction whereas set code can happen immediately this can allow uh this is more secure than self-destruct upgrade because there's no downtime where the contract is empty uh so you could use it for example for a token upgrade thank you

Tim Beiko: got it thanks uh Democrat Andrew I saw you both got your hands up was it related to this

Dankrad Feist: I don't understand why why we need this can can all this be implemented using proxies why do we need another methods I don't understand that

uh I can answer that uh the main improvements upon being able to replace code in place is that there's no execution overhead uh delegate call is still useful because you can use it to bypass the account code size limit so if you need a contract or an account with a hundred thousand uh bytes by code of implementation you can just spread it

across multiple contracts to delegate call um but if you need to uh replace an accounts code itself uh then this keeps that functionality uh the benefit of having no execution overhead is critical and without it uh many uh users might prefer in order to save on the gas to migrate all of their tokens for example to make a new account and transfer all their token ownership and identity to new accounts that's not great for example if you're a DEX and you want to change your code and you don't want the gas overhead of needing to call into another contract

Dankrad Feist: yeah I understand the the overhead

argument but I mean functionally I don't know like we should think more about the overheads if that can be mitigated but there there are like there there are there are many possible future advantages from having the invariant that currently doesn't exist but could exist in the future of the software deactivation that in the same at the same address you'll always have the same code or no code so I like you you should weigh that against the benefit of and

Tim Beiko: I feel like uh having I think X6 not current self-destruct proposal but the one prior to this

effectively had the same semantics if if I remember incorrectly and we so basically what it would do is it would allow you to recreate the contract uh at that address but it wouldn't change the storage in the meantime and the challenge with that so people were concerned about like their kind of attack risk where you know you deploy a smart contract and then you know people use it in a way and you sort of change it and you can keep the existing storage and you know um potentially change the entire functionality of the contract so I don't know I'm yeah I'm curious uh if

yeah how others feel about that because it sort of feels like a discussion we we had a few months ago unless I'm Mr remembering the issue

Andrew Ashikhmin: I think uh from Aragon's perspective we'd like to avoid the version of so destruct removal where we have multiple versions because we already have those scenario and we call them incarnations and they complicate the code quite a lot so unless we absolutely have to uh I would prefer a simpler solution like in my mind

six seven and eight zero is is a good compromise between Simplicity and like limited backwards compatibility so maybe we can wait until the report arrives and uh like then we can reconsider but we can tentatively agree that we are including some variant of self-destruct removal like six seven eight zero and if in the meantime other people come with the like a different different tip then we can revisit this it's kind of it's it's uh mostly independent from the orthogonal to 4844 so we can revisit it pretty much

independently

Tim Beiko: okay and I guess this match is sort of what like client was saying but basically we would sort of include um six seven eight zero um as we get the report we can analyze the impact see if there's a significant change that's worth making to the spec or not um but you know make basically make that commitment today and you know potentially change the actual uh semantics of the EIP if uh if we see something but um high level from like a you know quote-unquote design point of view this is like all the client teams are on

board with um with making this change does that make sense

Andrew Ashikhmin: yes to me yeah

Tim Beiko: any okay any I guess last chance uh yes

so code mutability uh doesn't impact the error immutability it doesn't impact the user space much because code uh can still basically be modified via proxy uh but uh what are the advantages of it uh as on the Aragon side so you said that it complicated your implementation uh

how is that uh when the state uh root and all uh should still function

Andrew Ashikhmin: uh well it just we have this extra parameter incarnations or besides some account uh address we always carry this Incarnation and we have to for instance um kind of have to make sure that in case of a reorg that uh we should arrive at like all different different nodes to arrive at the same Incarnation or like account code version because uh otherwise he even becomes part of the state then you might have

Divergent State and so on so it's all it's all doable and feasible it just it's just an extra complication and the question is uh uh whether this extra complexity worth it but I think if if there is another like are you saying I might have missed the point is are you saying that there is already an alternative if that solves uh that is is a better alternative for like we you or you are you talking about a new Heap that you have in mind

so account code can already change on reord because of create and create two so when those are reordered the account

code also changes

Andrew Ashikhmin: uh yeah but with uh with with uh self-destruct removed we won't have that

I'm referencing specifically set code is a way to maintain code mutability

Andrew Ashikhmin: and is it is it possible like is it an imp already or is it a new

feature a new idea it's eip6913

Tim Beiko: so I guess

clearly like I don't think most people on the client teams are super familiar with this um maybe what I would suggest for this is that we move forward with 67.80 um in like a month when we have the report obviously we're gonna have to reassess that I think that also gives time to people to read this 6913 and we could you know make that decision sort of at the same time like you know whether we want to change 6780 based on the report whether we want to add 6913 alongside it um but it feels like all the teams are like pretty shrunky in

favor of you know moving forward with self-destruct removal um and we we probably don't have enough information to go like beyond that um yeah today so I guess yeah if anyone who posted that's like making including 6780 we revisit the report uh or Revisited sorry in a month with the report um in the meantime we can also uh look at 6913 and kind of go from there um okay and mayors has a basically comments that says the uh to do the same thing um so cool let's do that I'll update the spec

um after this call but 67.80 is included um and just for the people implemented be mindful that you know potentially there'll be changes to this spec based on the um based on the findings of the analysis and you know people's like readings of stuff like 69 13 in the next few weeks um yeah thanks William for uh sharing your perspective as well uh light client and Charles you both have your hand up and you have them for a while oh and now Danny as well

any of you have

Lightclient: yeah I guess yeah I just wanted to say something before we got into the to this discussion about

self-destruct on like the general uh CFI eip's for Cancun and I would like to look like very seriously at these SSD eaps because I don't want to get into a situation where we do whatever the like like absolute fastest thing is for 4844 with the intention of changing it and just like a fork later or two forks later so I do think it's important to try and figure out like what is the minimal amount of uh work that can be done so that it's kind of like future compatible with this as a sea world since that's what we've been talking about doing for a couple years now um versus like just shipping something in rlp or

hockey and then

Tim Beiko: yeah um I think it probably makes sense to

chat about now chat about that now actually because if we have basically 444 it's already pretty big um self-destruct is sort of some medium-sized EIP and if we do need to make some SSD changes it's probably good to be on the same page about what those are before we decide about doing anything else yeah I see I don't know you and you can both have your hands up do either of you want to you know share your thoughts on on that then you know what's the either minimal or optimal set of changes we should do as part of Cancun um especially given 444 is the main thing you have to upgrade

Andrew Ashikhmin: um so

the two eipes that should definitely be looked into are six four nine three and six four seven five and the first of them six four nine three that one he finds how signatures should be computed so that they cannot conflict with other chains um that may use rlp for the same transaction type and the other one 6475 it's a quite a small one it just defines how we want to represent optional values because 4844 has an optional to like for the destination of the transaction

um right now they don't exist anywhere and we should just decide should they be like the unions are today or should they be more compact or something else the rest how those trees inside the block are structured with trials receipts and transactions that we can also do later doesn't really matter for 4844 compatible like data 6493 is compatible with both the normalized transaction approach and the SSC Union approach so that one like those three they they are not necessary for Cancun we can do them later without downside

Tim Beiko: um Andrew I see you have your head up

Andrew Ashikhmin: uh yeah so a question about four six four seven five as is the optional so um if I understand if we adopt if we implement it in Cancun that affects uh 4844 right because 4844 has some optional Rapids and the two address is optional right in the SSD transactions

Etan Kissling: yes exactly I mean right now they are defined as to use the union type there but semantically what they should be are optionals it could be that they are

serialized the same that we wanted um but it could also be that there is like a minor change so at the very least we need to align and switch over to the new representation at the same time for a definite and so that we stay

Andrew Ashikhmin: and does anyone have a view on whether we will need Union and SSG going forward because if we don't then I guess it makes sense to just have this more limited uh solution for for optional

Etan Kissling: right now we don't use them there are some designs that may use them in the future but um regardless of that the

optional is a more restricted type because it can only be none or some right but the union is a more complex type so for example in the Nimbus implementation those two are very different code paths um but sure it could also be that we just encode the optional as a special case of the Union so it's just a syntactic sure to make it clear to the reader what this meant right now 6475 is not compatible with the Union because it doesn't emit the selector

um it uses the length instead if it's empty it's a none otherwise it's a sum but the union also for the serialization I think it's a bit under specified because it doesn't Define how to serialize the non-value so yeah unions are not used today but if it if if we need them we need to also decide how we want them to look

Dankrad Feist: of course uh sorry I think it is specified I think it's just

selector equals zero it's the done value um okay so as zero and then nothing else I guess yes

Dankrad Feist: yeah

um so just one idea would be um like if we if we really like we just keep our options open here we just like we can simply Implement if nobody is using Union at the moment then we can implement the um optional as you specified it um with the intention that if we do introduce uh unions later that we make them a superset of the optional

Andrew Ashikhmin: okay so the difference then would be um I guess the 6475 would need an update then just to allow for a future extension for multiple cases but the none value for example that one could be

reduced to just the empty like the zero there doesn't provide any value but the sum would have a leading one right that would be the

minimal

Dankrad Feist: uh potentially yes I mean theoretically you could even what not necessarily right you could also say if there is are only the two options like none or something then you also don't need to need to add the one right

Andrew Ashikhmin: that's true yeah if it's a none and another option

Dankrad Feist: uh I guess you have to guarantee that yeah then you need well I guess you need to do a special case that uh the second part is non-zero length

I don't know if that's always guaranteed maybe that's always guaranteed there's something to think through but it might be possible to make uh make the union restrict superset of what you specified already

Andrew Ashikhmin: yeah another issue is when you update this spec to uh like when there is a fork that adds another case to the union and you go from from two to three that you can no longer parse the old values with like um yeah that is a good point actually

Dankrad Feist: yes that might be an advantage of adding the one because then it means uh that you can more easily upgrade

existing SSC Fields but additional additional options right

Andrew Ashikhmin: yes exactly so I will um update 6475 them to have the one in the sum case um and non-case I keep empty and then also change the existing uses to to use this time

Tim Beiko: and so if we if we make those updates the 6475 are we like fully happy with this with the state of it like should we

considered should we included you know pending those modifications

Andrew Ashikhmin: I think so

Tim Beiko: okay so does anyone disagree with that

Andrew Ashikhmin: and also I think we will need to update the foreign 6475 right for for the optional to address

yeah

Tim Beiko: yes I'm sure there's at least half if not all of the 444 authors on this call so

if one of them can make that PR um once we have the 6475 uh once we have the 6475 uh change is done that would be great okay so um so that's for 64.75 and then uh there's uh six four nine three so the signature scheme is this I guess this is something we also have to include sir I'm trying to read the comments um

yeah yeah so I guess okay so yeah so anyone opposed to six four at six four nine three so the signature scheme for SSD transactions

Lightclient: does this secret the two concepts of transaction ID versus transaction hash or is this only attached to signatures

Andrew Ashikhmin: uh it also includes the concept for transaction ID

Lightclient: yeah it's been a while since I've looked into this but I remember being pretty against referring to transaction transactions by this transaction ID

concept and it being different than the transaction hash

Andrew Ashikhmin: I mean it's the same like it's just not a ketchup but instead a hash tree root right

you know the

one disadvantage is it involves now bringing in the mercurialization aspects of ecstasy into the execution layer whereas right now we don't have that minor thing but right

Lightclient: but I think we need that eventually

Tim Beiko: well I guess maybe this is like a dumb question but if the 4844 transaction type is an SSD transaction

I guess its signature scheme is defined as part of 4844 or

yeah it is right now right now you see serialization with the prefix type got it sorry I can't hear saying something yeah sorry cut you off no I'm just thinking

Tim Beiko: okay so I think I I'm sorry I think I I sort of misunderstood here um I thought this was also sort of a requirement to get uh to get sorted now due to 444 but it sort of seems like it isn't

Lightclient: so we can move forward I mean we have implementation so 444 right now but yeah

I think doing things the right way is is best and we don't really have the concept of hashing and S to Z serialized value I think that's kind of weird and so that's why we're talking about having the hash tree roots but once we start having the hash tree where we start having to have these other questions about okay how do we um you know have the signature scheme safe

Andrew Ashikhmin: and also for the sixth photo for uh if we go with the SSE based transaction try later then that one would have key advantage that those hashes and IDs um match if we do it the right way from the get-go

um if it's the normalized approach it doesn't matter to be honest because the hash is a is a separate Leaf anyway in the tree so yeah there's that slight Advantage as well

Tim Beiko: so I guess maybe um maybe a good Next Step here is we have the 4844 call on Monday um is it possible to buy Monday like by that call have the changes done in 64.75 and 4844 so that people can like look at that prior to Monday and kind of discuss 64.93 in the context of 4844 and

basically you know aligning those two on that call Monday um okay I see Monday's a holiday uh whoever Ethan is um is there anyone else who you think can join and like make the case for uh the

EAP

Andrew Ashikhmin: I mean it's mostly for review right

six four six four ninety three right yeah like uh do we have to do the review during the

call work would we just oh no no

Tim Beiko: so I guess yeah and we we definitely shouldn't make a decision about including it or not in the 4844 call but I think it's yeah if people want to review it and we can have it you know first conversation about it in the Monday call at least yeah if people have questions or you know thoughts during the review um we can address some of them there but I it doesn't feel like people have enough context to make a decision about this today okay

okay so let's do that so that's uh so we include 64.75 um and and uh if you can do the changes uh before Monday that would be amazing we also need to do the changes on eip4844 to kind of reflect that and we can bring it up on the call on Monday if people want to discuss it more and two weeks from now we can uh we can hopefully make a final decision on on this call okay uh any other thoughts concerns about SSD um then yes you had your hand up for

like a really long time is it just accidentally up

Danny Ryan: oh sorry me yeah yeah um I just wanted in the opening when we were kind of getting signal from client teams I just wanted to say that 478 which is cross layer has the support from the consensus layer teams um you know see it as a moderately high priority to open up trustless pool designs and the barrier to entry to make pools in the execution layer um and that people are willing to get it in obviously it's cross layer so it takes

two to tango so I just want to make sure that information was surfaced here

Tim Beiko: got it thanks um yeah I think it might make sense to actually cover this one and uh the BLS pre-compile mix because we've talked about them quite a lot uh over the past I mean years in the case of BLS um and at least months in the case of 4788 yeah I guess I'd be curious to hear from like the El client teams uh it seemed like most teams had appetite for like you know maybe if one or two smaller eips Beyond 4844 self-destructed now uh some of these SSD changes

but would you know I guess four seven eight eight at BLS or um I know 1153 is another one that came up a lot like um yeah how do people think about prioritizing between those uh potentially smaller eips and is there something I guess that people feel is like a must-have or you know quite important to have I'd stop short of saying oh I'm sorry I should raise my hand oh no go for it I'd stop short of saying that we think 1153 is a must-have but we're basically remains pretty strong in favor of it and does that mean you would prioritize

it over like 47.88

or 30 times it's mostly testing over there the same is not true

Tim Beiko: uh and then Marek has a comment uh also said I guess 1153 would land slightly higher for them uh like client has the comment I guess from the get side saying 4788 with lamp uh slightly above them I don't know if anyone from Aragon has like strong opinions

Andrew

Andrew Ashikhmin: um yeah I think um we would uh do a five nine five nine twenty it's uh a simple uh your usability improvement um yeah

Tim Beiko: this is a spot where like we have yeah 4788 2537 and 1153 are sort of the three I'd say that are like medium they're like some client teams feel at least so much strongly about I don't know that we have to make a

decision about those today but I'm curious if like are are people potentially comfortable with saying like that's uh all the scope like we'll consider for Cancun and maybe what we could do is like literally remove everything else from CFI that's not those uh three so 11 53 25 37 47.98 as we start as we start kind of working on uh the devnet and like implementing uh the rest of the eaps we can kind of revisit those three but yeah and I see yeah so I and yeah I guess let's just start

there like would people be fine for now like restricting this cfis to those three and that means basically removing all the eof stuff which I think was the only other stuff that was cfied okay and then yeah so there's a couple comments in the chat about like some other tiny up codes like maybe we can add those in the future as well but at least I think we can remove um remove the eof stuff um yeah keep those three uh so 1153 25 37 we're already cf5 we can cf5 47 88 um and then potentially if they're small things or you know other editions that

come up we can we can decide those and I know I guess Charles you've had your hand up for a while to talk about one of those small things um so if you want to go ahead we can do that in good context to people uh sure uh this is actually my first ACD call so I don't know what the Yeah protocol is but so I don't want to derail everything but well first off I think that 1153 and 15 and 20 are quite useful um if you've already talked about this so I wanted to bring up uh M Copy eip5656 which is is quite useful uh from a compiler perspective it would you know enable us

to reduce byte code quite a lot and it it also just makes sense to have it you know it's called Data copy there's code copy there's even xcode copy but there's no mem copy and um I don't think there's any contention about the spec or it's like usefulness uh there's a even opened up pull request on death to implement it um so and it seemed quite straightforward so I I just don't see that there would be any problem with it yeah it would be super useful thank you so I guess we can uh yeah we can have that in the list and we can

potentially or we you know have people look at it and potentially CFI it um in another call when uh folks have had time to review it generally we tried to not like CFI something on the first time it's been presented just so people can have some time to to kind of digest it before um but and I saw you posted in the each magician's thread so people can review it there Andrew Daniel I see you both have your hand up

all right

Andrew Ashikhmin: so uh I just think uh that because we've been Stefan 1153 for quite a while and we moved it from Shanghai to

Cancun and so on and it seems to be a small Heap that uh people are mostly in favor of I think it would be fair to include it because otherwise we just yeah who have been it's been a lot of uh uh it's been a lot of opportunity for people to look at it and we yeah we generally agree that it makes sense so why not and small enough I guess

Tim Beiko: yeah does anyone have objections to that it's true it's been discussed for a long time I know there were some people were sort of opposed from like a design perspective but uh it seems like most client teams

are in favor now yeah does anyone have an objection or okay so I guess so we okay so that means we include 1153 in Shanghai alongside 444 and eof and I'm sorry no 444 and uh the self-destruct and as well SSD changes and the

the potential trade-off there is like the two other ones that people uh mentioned earlier so the 4788 um those would be sort of CFI but not included for now does that make sense to people um so we can move 1153 as well um to included um Dano I see you have your hand up

Danno Ferrin: yeah so um I am in support of moving eof out of Cancun one of the things that's going to

give us time is more time to get some some core deep questions right um we're still working on questions around whether or not gas observability should be in and um about you know how create should be handling and a couple of other issues and pulling it out of Cancun solves a lot of the time pressure um so we can we can focus on getting a ride instead of getting it ready for uh Q3 shipment so as much as it hurts I think it's the right decision

and go

Ansgar Dietrichs: yeah I would generally mirror that sentiment I would just want to say because I think it's always helpful to step at least like some paragraph

expectations for the longer term roadmap I personally would prefer if we could at least then afterwards aim to have product be like an UF focused uh fork and hopefully come relatively soon after Cancun instead of them basically shooting for combining it under with Virgo and that would be like I don't know nine months after something that seems like because if we keep trying to combine it with another big ticket item I think it just will keep slipping because it's too big to to basically be the the second phase in a box I think at some point we just have to then say okay it'll get it on its own fork and because most of the limitations will be ready at that point it will just be a quick

walk

Tim Beiko: yeah so I I think it does make sense that you

know think about this way I don't want us to commit strongly to something today when we're not even like we don't even have implementations for uh for Cancun um but yeah it does seem that uh yeah it does seem that like eof and vertical trees are like the two potential next big things eof is potentially uh smaller and farther along and it would almost be sort of like we did with the merge and withdrawals where you have the big fork with 4844 and then the small fork with eof so yeah we can definitely discuss that I think as as like we have a clear picture for Cancun that's probably the highest level decision to make

um so that we can get teams to work out in parallel um and Lucas you have to be care I'm not saying UF is small I'm saying though that if you had you know the merge and withdrawals the merge was much bigger than patrols um even though withdrawals were not trivial and it feels like we're in a similar spot with like 44 for an eof where 444 is like much bigger um and obviously sort of can't quite be combined practically with uh with eof um but yeah eof is also big and you know can maybe be a smaller it's a smaller big thing for an export basically yeah uh great oh Greg here on mute

I am unmuted

I'd like to reiterate just that we commit to getting eof in at some point the basic functionality is the same as eip615 which I proposed in 2016. so we've been discussing this for seven years is is just time well I think I've got yeah I think I've got to work I've been wanting I forgot work I've been wanting to do on the VM for seven years that I can't do until this is in

Tim Beiko: yeah I mean I think look all the client teams are pretty on board with eof be

too big to be included alongside Cancun I think the strongest like commitment we can make is to have it be the main thing for the next Fork um but even that is probably not something we can like 100 agree to today and there's some comments in the chat to that effect okay so I think we covered pretty much all the like proposed eips maybe to just recap um sort of where we landed so 444 is

obviously part of uh included for for Cancun uh 6780 this is a self-destruct removal EIP we also agreed to include this review it um in a month or so when we have the impact analysis out and in the meantime we can also look at the set code EIP which was 6913 uh and then we agreed to include 64 75 which is the SSD optional type there's still some changes that need to be made to that Ethan we'll do them in the next couple days and we'll we'll update 4844 to reflect those changes as lastly we agreed to include 1153 alongside that

um so this would be kind of the current scope for Cancun two things we've well 2735 the BLS was already CFI and it stays as it is 4788 we also CFI and then we remove all the eof eips from cfied and that's basically oh yeah we should CFI this in your church scheme as well uh 64.93 but we didn't agree to it uh quite yet does that make sense to people cool and yeah so on Monday's call we can

uh on Monday's call we can chat about the 64.93 uh EIP as well a bit more and then two weeks from now we can we can bring it back up here

so okay so there were two more things on the agenda um first was uh also related to 4844 uh the conversation around like the blob ryorgs and the new payloads back I know at Peter and Danny we sort of discussed this on the CL call last week um I don't know if there's any updates from either review or yeah I don't I don't have an update

Danny Ryan: I

know Peter wanted to spend a bit more time thinking about it I know maybe everyone else who hadn't thought about it that much I want to spend some time thinking about it so there's anything we can obviously talk about now we can talk about four four call um it's a break from change the engine API if we go down that route so we need to figure it out sooner rather later

Tim Beiko: uh Peter any thoughts from Iran uh you're off mute but we can't hear you like these I can't

so um oh now we

can

Péter Szilágyi: so essentially what I was saying is that um I was working on 4844 but not this specific part so I don't really have any update

um anyways

Tim Beiko: Okay so see we can keep chatting about this on the Discord as well as it comes up but it's just something we should be aware of yeah that basically uh yeah we need to agree on a design for and then uh last thing we had on the agenda uh so devnet5 uh there's been a lot of work on this this week I don't know if anyone wants to give a quick

update to kind of share where things are at

Barnabas Busa: sure I can do that uh so basically identify uh we had the dry run starting last Friday and then we had the actual launch yes the titanium UTC we are running this uh with the 1000 validators uh we have three working clients Lighthouse closer on prism and we have tooling is coming online now and you

don't have a block scan blob blob scanner uh working just yet but hopefully it should come online by the end of the week I mean we currently don't do any fuzzling but I'm open for it and uh probably the timeline for this is I know a week or two maybe more that I would like to see more clients getting onboarded thanks do you also have the internet Force still running for this uh and we would like to shut it off hopefully end of the week if there's no opposition for that

doesn't

Tim Beiko: seem to be so we can yeah go ahead and shut it down um yeah thanks for sharing the update anyone else have thoughts questions

Barnabas Busa: I also linked in the chat the effects that you will do to do if you want to participate

Tim Beiko: nice thank you so yeah I guess that's it um anything else people wanted to chat about today okay well if not then I guess uh yeah for the next call um figuring out this

SSD stuff and um yeah if there's any other I guess small eips that people want to discuss this is probably like the beginning of the end for them to be considered um yeah so please add them on the eat magicians thread um so we can uh yes we can keep track of them but yeah thanks everyone we'll talk to you all soon thank you thank you thank you

bye Jesus

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