All Core Devs - Execution #109

Transcript

[Music] foreign [Music] [Music] foreign [Music]

[Music] [Music] [Music] foreign [Music] [Music]

[Applause] foreign [Music] [Applause] [Music] foreign [Music] [Music]

[Music] [Music] foreign [Music] thank you

[Music] [Music] [Music] thank you [Music] foreign [Music] foreign [Music]

foreign [Music] [Music] foreign

[Music] [Music] [Music] foreign [Music] [Music]

[Music] I mean [Music] [Music]

[Applause] [Music] [Applause] [Music] foreign [Music] [Music]

[Music] foreign [Music] foreign

[Music] [Music] [Music] foreign

[Music] [Music] [Music]

[Music] foreign [Music] [Music] foreign

[Music] [Music] [Music] foreign [Music] [Music]

Tim Beiko: number 109 I'll post the agenda in the

zoom chat right now folks want to follow along uh so we have a bunch of different things on the agenda uh high level mostly covering what's happening with Berlin um how we're tracking it on for the London work and then uh both the different like high-level approaches uh for Shanghai um and a bunch of specific heaps so I guess just to get started the first thing is uh burden happen on rink B between the last two calls does anyone have an update for that that seems like everything went pretty smoothly but did anyone wanted to want to share anything foreign

update uh on ring B um and then for people listening the update on mainnet will be happening before the next call so sometimes over the next two weeks I think it's scheduled to happen uh late on the 14th uh and maybe early on the 15th so uh middle of the night for North America and probably during the day of the 15th for uh for some parts of Europe and Asia um Puja the catheters are hosting a viewing party right you want to talk about that a bit

Pooja Ranjan: yeah thank you Jim so the categories are organizing uh countdown party in which

we have invited the EAB artist for the proposals which are getting into Berlin upgrade we have published a announcement below I'm gonna share the link here for details it's open for everyone to join and we hope to watch the um watch the stream

and see the thing live wearing the product now um yeah cool yeah

Tim Beiko: so if people want to join uh I'll be there I think it'll be midnight or two or three in the morning uh West Coast North America anything else on Berlin

okay and yeah if you haven't updated your node uh now is obviously the time to do so uh there's an ethereum Foundation blog post which lists all of the client versions so if you just Google search for that that should be pretty easy to see um yeah so make sure you pick your node sometime in the next two weeks so next on the agenda was London um and there's been like a lot of conversations we had last time around you know what should the scope of London be and and how how kind of skinny versus uh how skinny should we keep it um and I think what's probably most useful to to decide that is getting a feel of where we're actually at with the implementations and what we expect uh

needs to be done uh to property test 1559 so I don't know if uh one of the client teams just wants to give a quick update of where where we're at uh in terms of testing in terms of implementation Readiness for just 1559

yeah I can start uh so we have a small uh multi-client integration this net with uh they do get and determine so uh we have the consensus on the transaction and coding decoding uh using the type transaction and the lots and access list we have to update the transactional

receipt to include the effective gas price for um 1559 transactions uh yeah that's where we are

excuse me I was just curious so this uh guess implementation with 1559 is that I as far as I know there is no such open PR against gal ethereum um if I'm mistaken

Lightclient: we haven't opened it against sclerotherium yet we've been tracking it on our

our teams Branch but we can open it against it if you like uh no whenever you feel ready I was just

curious about it because I I knew that we had an old one which had been closed but I haven't seen any new one um so I really have I have no idea about about anything and in that implementation but it would be interesting to to see it in the open don't take your time okay okay I

Lightclient: yeah I mean I think we can go ahead and open it as a draft it's you know because that we were splitting it into the consensus portion and into all the other uh you know transaction pool that kind of stuff related related politics so we're actually hoping that consensus one first since that's mostly done

is is the one that bill mentioned use

the uh transaction envelopes EIP yes yes and there was some um like theory theorizing that it would be easier to implement if used through using transaction envelopes I'm just curious that like was the case or there was any kind of differences

Lightclient: I didn't personally implement it before and so I it felt pretty natural with transaction types but I also had you know worked on the transaction types even before that

so I I don't know I'm not sure if

I could speak related to it so

I was just curious it's all right if if the 1559 stuff can go into it more deeper I mean those that I can go more deeper on the channels for that

Tim Beiko: and the other thing that came up in uh the chat uh was there just a reference test for 1559 um so I know I think there weren't any I don't know if there were any period And I know specifically there weren't any for the the transactions um does anyone have just an update on that and what would be needed to do over the next few weeks

Gary Schulte: um I'm actually working on reference

tests for 1559 uh right now um I've got a couple of things that I've got to sort out for uh getting them running uh with transaction types against spacesuit and then um after that I'm going to be taking abdel's existing 1559 tests uh and getting them into a reference test form and uh at least start the conversation uh around what those what other reference tests uh use cases might be necessary

so yeah one question about the reference does I'm assuming that test free 1559 has to be blockchain test right not status is that correct

that's correct okay cool cool and again

Tim Beiko: I think this is your first I want to call Gary but Gary is on the base you team he recently joined that's fun to hear a new voice welcome thanks yeah welcome um so sweet so I guess yeah we will definitely make progress on the reference tests over the next two weeks um is there I guess is it too early to try and set up a a YOLO type Network or uh I don't know I guess we already have a test net that's running between the different clients um but should we set up kind of a London

proper uh integration test like we did for Berlin what are people's thoughts on that

yeah I think that would be useful for sorry go ahead are you reversed okay uh yeah I think that would be useful for uh wallet and libraries uh implementers uh but uh we are just waiting to have a full consensus between the three clients so we are very close like as I said only the transaction receipt is missing on get and visual and once we have that we can think about spinning up the yellow London

test

Micah Zoltu: build off of Berlin or is it building

off of some pre Berlin

branch okay uh Thomas you have your hand up

Tim Beiko: yeah I have a bit of a question do we need a new yellow test not because the one that we have is on top of the lane with eip1559 and the receipt changes uh this is my question here so the receipt changes will be caused the change in the um in the hashes of the blocks you don't then we can continue with the same network and just make it more available

it should cause the hash change in the block because of the receipt route

Tomasz Stańczak: yeah I'm just not sure whether the only

change in receipts is in the transport like when sending messages over an fb2p or it's actually in the content receipts changing the receipt

route I think it's actually in the content yeah okay then thanks

Tim Beiko: so then to be clear then that will be kind of a consensus breaking change and we'd be easier to start up when you test that after that is that right yes yes exactly okay so let's do that and I'll put a spec on the eth1 specs repo like we had for the the YOLO networks um given we've already kind of used a lot of the YOLO test Nets and we use that name for people to not think this was burden but it ended up being burden are people fine

with I don't know saying something like London integration test net or I don't know is there a name or we can do like yellow V4 or something like that

that people have a preference yeah we're

Tomasz Stańczak: calling them devnets instead of testnets yeah so you can have distinction

so London does not see one oh go ahead oh I just I

Lightclient: had a proposal which you can we can shoot me down pretty quick if that's what we want but I I wanted a different name than YOLO as well and so I thought we could name them after geological fault lines since we're kind of looking for faults and consensus clients and that gives us a pretty large sample set of

games

Tim Beiko: okay and from the chat there's also yolanden and London integration test net which is lit

Sam Wilson: um so we yeah so I like uh I like the fault lines but lit is also pretty good and goes well with London so

Martin Holst Swende: I personally don't I don't care about the names that we can go with whatever but I think maybe we shouldn't tie too hard to London unless we are absolutely certain about the scope of London because yeah the idea is like the only one yellow two is that we can um explore whatever features we want in them and then they go into the whatever

berliness and maybe they don't it's not if we call it like London the first version that's not um we've kind of stethoscope for London

Tim Beiko: um yeah and it's harder to take things out

I guess um yeah and we did take stuff out previously so that kind of there that did happen where we tested stuff took it out might put it back in or not

Tim Beiko: okay that's a really good point uh so I guess in that case default lines is probably the best uh kind of neutral thing where it doesn't associate the London um yeah uh like if you want to propose something either in the chat here or in the awkward devs getter um I can use

that and put together a respect uh on the if One specs repo sounds good sweet um anything else on uh I guess the work that's been done on London so far okay um so I guess the next big Topic in uh it's kind of a bb1 is uh the idea of the scope for Shanghai and the merge so we briefly touched on that last call um but basically there's been more and more conversations in the community

about whether uh the Ethan clients should focus directly on the merge uh right after London and similarly the two clients right after the Altair uh upgrade which is going to happen also this summer um and and uh you know they're starting to have merge calls and specs and there's the rayonism hackathon where a bunch of Ethan and two teams will work together on on building prototypes for this um but then on the other hand there's also a pretty long list of Eeps that people uh have been working on and would like to see on mainnet um it's unclear how much of those we can actually add in London um so obviously if we focus on the merge

and London is is very small and scoped and those Eeps will have to wait for a while before they they are deployed on mainnet um so I'm curious I don't know the people have General thoughts about this I know it's a very vague and open question um yeah people have their hands up

uh so I think and Scar you were first um yeah so uh just I wanted to just

Ansgar Dietrichs: to say that from my perspective at least it seems like Community sentiments mostly seems to favor like merch as soon as possible and so I would say that because the first first kind of like decision for my kind of like perspective would be just to say that's like after London uh

independent of like how how big London will be let's focus on the merge and so whatever doesn't make it into one and just basically people will have to wait and then like in a sentence I would say let's then try and um basically include as much of these kind of uh as many of these features into London as we can but but definitely like I always have the fallback of keeping it kind of like Slimmer if we run out of time or something but I think the most important thing should be um focus on the merch after London independent of how much we end up fitting into

there uh Thomas I think you were second

Tomasz Stańczak: yeah I think that if the community were given an information that they kind of

also put in kip1559 delay at stake if they're choosing 40 40 heavier in London then maybe it will change like the the kind of sentiment that we see with the community so that's why I was pushing for the as quickly as possible well defined and slim London um and then discussing what comes next and comparing the uh whether we can run in parallel the IPS and and the merge or the merge happens first or the aps first so I think we also know a lot more after the Ryan is in May it will be much easier to take some decisions

than as well uh Nika I think

sex cannot work on the merge and uh we missed we missed the part we missed the first part of your sentence sorry about that

Micah Zoltu: are we operating under the assumption that one or more of the dev teams is only capable of doing one of either Feature work or the merge at once that accurate like we know we can't all just work have like the teams aren't big enough to have the merge being worked on as well as future

working on Parallel is that correct well it sorts highlighted oh go ahead yeah

so I would say about happily depends many of the suggested eats are kind of tiny and the actual implementations would sit on the three basically so in those cases I don't see it as a problem uh certain something something a bit or do you like it in his mind um yeah in those cases it becomes more of a resource problem yeah but not always not in general

Micah Zoltu: we have some mechanism of identifying which of the desired features for post London fall into the the camp of we

could probably work on this in parallel or we just have to kind of go through them one time and identify that

house I said sorry

Martin Holst Swende: I think the question is more like which which are the ones that takes the most uh work and the thing is it's two things here is the implementation work and the kind of uh larger work of figuring out so what are the the what are the edge cases here what are the quirks what test cases do we need to cover what are the possible faults that someone can possibly do while implementing this and how do we ensure that those faults aren't present etc etc which is probably more work than actually implementing it but both of

those things are easier if the change is the one-liner obviously yeah I guess in the case our case

spaces yeah they are James

um I was just wondering if there's anything that's kind of close enough to be thinking about even being part of the next YOLO part of London or any of the eifs that close

Sam Wilson: I mean I think I think 3074 is is pretty close we have a testament already up with our own implementation

so Els has

Micah Zoltu: been done for like nine months

Tomasz Stańczak: yeah that's what I was gonna say yeah we have the BLS code base fee will be a one-liner I mean not one liner but a few lines of code and testing should be very easy as well um the portion removal of refunds may require a bit more conversation but I think it's well defined and actually not that hard to implement um I'm not sure about everything else 3074 might be interesting but we'll see this might be more work I guess but it bases on the things on to 7 18 so 2017 opened a lot of opportunities for us

uh and Alexei your head's been up for a while

um yeah so I I think I've

kind of expressed this uh previously and I do understand that people want to be super optimistic about these things like oh you can do this we can do that but the my current feeling is that yes we should do everything um we should do London we should also start doing merge and we should also do tons of VIPs but yes it is the resource drain as Martin said and yes we do have to already I I do already have to send people to work on the on the merge and now I have to find out you know who's going to do the

London and then and then what happens next is that we it will basically completely cut me off from even looking at the aips that are proposed and so we will get to the situation which is kind of a bit reminding of the 2315 where we were so busy we couldn't look at anything and then something was going on in the Oracle all Court have calls and then well gosh we we've spotted something last minute I mean yes that was my impression that we're trying to be in super optimistic and just try to pile things in but as as I understand that not every development team is is the

same and they're not on the same kind of ah so for example we're still we're still essentially refactoring we're still trying to finish things and yeah we are slowing down because we have to do a lot of new features uh but I'm not complaining but I'm saying that please don't be because basically all this work has to start right now even though the merger will plan for Shanghai but the work already has to start right now that as far as I understand it's not like we can wait till whatever June to to work on us so yeah that's what I want to say

Tomasz Stańczak: I think we're in this good place that's uh mostly like London code for plan for July is practically ready and tested uh

I don't know if you've ever been in such a great place before uh on such a big change and as for the As for the merge as I say we'll have a lot of vision after after May but looking at the first call it looks very promising on being quite smooth transition a bit of research and there'll be so many people involved um I mean yeah obviously I don't want to say this I'm not Steve reasonable concerns I think Alexa you have also a good way of thinking about things that uh they may be maybe it was better to be a bit more cautious here and there but yeah from our perspective in the mind I think that we are very very

confident about the set of changes of even looking at all of those VIPs we've already tried of some of those we already have implementation for two three nine five eight two nine three five uh we have London ready and we have started to look at merge and it seems to be uh not a great um not a great effort from the perspective of different clients more like research

analysis perspectives yeah cool uh Marcelo I see your end is up for the first time yeah sure thank you

I wanted to support what is what Alexis is saying regarding resources and open ethereum where right now we're very tight

resources were still doing the implementation of 50 1559 so we would we would rather not rush on some new stuff

got it and scar

Ansgar Dietrichs: yes I um had a question mainly for client developers um I think Martin was saying earlier that like for the kind of test Nets before London um we shouldn't kind of constrain ourselves to like having the exact AAP set for for London so I'm just wondering how much like like how feasible would it be to basically go

ahead with all earpiece that are ready and that we would kind of ideally want to see on my net it's just kind of like create these fully packed test Nets in the beginning and then just kind of like iteratively kick out those that we feel like I just turn out not to be quite ready and then just basically shrink our way down instead of like shrinking down now and and then just going with a small set

so like yeah that would be my question uh Thomas yeah

Tomasz Stańczak: I personally think it's a great idea to create this like yellow like castlet with all of the Caps that we have listed uh on the agenda today uh it'll be great to see it and literally suggest that this is Shanghai or Cancun or don't even name it like

just if they're all behaving fantastically then maybe only then we can talk about them in London but I think it's quite late to really change anything London and I would prefer to keep it sling but definitely if it has super well then we can say oh it's totally fine to go uh in parallel with the merge because we will literally see how the work is progressing if it's progressing slowly then it's a very clear suggestion that actually we are focused on the merge and she takes our uh brain power to think about it to research it and we would have the visibility of really what the resource strain is there

Tim Beiko: so I guess trying to to aggregate all of

this feedback um you know clearly some client teams are are a bit more resource constrained than others um at the same time there are like a lot of proposals that can add a lot of value that are not uh you know that that we we might want to do does it make sense to like maybe grow the network so say like let's start with yolo or you know whatever we're calling it uh I think it was aloof um so like the first devnet to have just 1559 and then maybe if that's up and running smoothly we add a few more Apes on the second version and then we add a few more Eeps on the third version um and and try to get a list you know of

if that are easy to add or ready to add um yeah Martin I see your hand is up

yeah

Martin Holst Swende: uh so I was just I didn't really understand that idea about having all the Eves in the first test and then iteratively removing them because I just think it will basically no clients would go in the first test maybe one client but uh therefore it makes more sense to me to start with the limited set and grow it because um um other all the guys who wants to join don't have to implement everything from scratch uh from the get-go I mean uh but there was another thing I want to

mention also now whether we're talking about work that that clients need to do and I just like to remind all the clients that at some point uh death will switch over to fully is 66 uh I mean we're not gonna yeah we we would like everyone to uh join us on 86 so we can drop support for only six to six um yeah and I I hope I was just hoping that that work is also getting some some um yeah getting done and

so yeah it's just one more thing that I wanted to do I just wanted to remind everyone about

it yeah that's a good point the Eeps are kind of the the tip of the iceberg um and then life science

Lightclient: I just wanted to to say you know if we do these at test that's where we start out with you know mini Eeps and then kind of call it back down My worry is is that you know the eaves that go into the test that really need to go through some process and be agreed on like what it does to some degree some like reasonable degree because exactly like Martin said if if we just today cut the meeting off right now and start implementing each

that are on the list some of these Eeps are probably things that are immediately going to get shot down when we discuss them or you know immediately if people are going to want to push them back to later hard force and so that's just a lot of work that's going to go into implementing and maintaining the force uh for the eaves that you know there's really no no why today so I would like to see you know the Eeps that go into the test and at least be cons like considered for inclusion or some sort of stage where the core devs at least feel on and principle that they eat makes sense and they're willing to put into a hardcore if you know it's implemented properly and there's nothing that comes up during the integration I think what's up in the community in the coming months

Tim Beiko: yeah I think that makes sense and you know uh James has like a final comment get to you James before we move on but I think one way to uh to have a better feel for that is to take some time now to go over the list and um yeah get people's feelings about the various things there um yeah James your hand is up

yeah

I was just for something realistically to get into London it would need to be on like a devnet in the next six to eight weeks probably or less so having like round one of the devnets be 1559 plus maybe whatever if there's something easy to add and then round two be as what we can fit in actual Dev by

resources wise because a bunch of them seem like you could just throw them in and it would take like two weeks to get most of them done um and then kind of start from there as deciding if it should go into London or not or if it should go into Shanghai maybe just like go through and start packaging what what we think could be packaged

yeah so I

Tim Beiko: I agree that generally makes sense like the time it takes to implement and and how ready they are will be a big factor um so yeah maybe we do have like a pretty long list and I know a bunch of people are on the call to kind of give an updates or discuss their uh EIP so

maybe it's worth taking a few minutes to go over the list and then coming back at the end to see you know how people feel about uh yeah the

the different ones under scope and with the ad easy ones yeah maybe that's like a two sentence okay

Tim Beiko: so I guess yeah I I listed them on the agenda I guess in order of like uh how much people have signaled roughly that they'd like this to be potentially in London or shortly after um but this is like a very subjective list

um yeah I was gonna say the first question we get triage it is would would this fit in

like the next step that scope of work

Tim Beiko: yeah yeah I think that's probably the simplest um so the first one is 3403 um so this is uh the partial removal of refunds uh the kind of updated eat by vitalik um I see William you have your hand up yes

William Morriss: so I view 3403 as the net negative uh first The Proposal removes any incentive to clear State except for in the same transactions case uh one smart Contracting engineers build around such

incentives we'll see more State load approving less than infinite will be phased out in the ux selling all of your tokens the most interface will leave one unit behind storage arrays will be cleared by setting the field size to 1 rather than zero and leaving all entries dirty uh because it would be foolish to clear them but these are only a few of the design implications the proposed The Proposal also sacrifices current elasticity which Smooths gas price by stirring Peak congestion 1559 does not provide sufficient elasticity because Peak congestion lasts hours not minutes by sacrificing refund elasticity concurrently with one five five nine we should expect a net increase in volatility that would counteract the

anticipated improvements and signature time gas price estimation while the motivations for the proposals cite brief for experience is possibly dangerous I believe them to be the top feature of 1559 Grocers don't raise their prices during peak hours they hire part-time workers so their customers don't complain and flee to other stores the long-term costs of potential Forex blocks are amortized during periods of lower congestion but all nodes should be able to verify the consecutive Forex blocks smoothly also they would be able to sync the blockchain in any reasonable time frame or else they wouldn't be able to Sir um as proof that the network can handle Forex today I present binance smart chain which sets a higher gas limit of 30 million every three seconds approximately 11 times the current

ethereum capacity my death node which runs on an older low end processor it's 70 Mega gas per second in Berlin so I would still be able to sync Finance smart chain if all of their blocks were 4X in the previous meeting we agreed to table 3403 if Forex wasn't a security concern there have been better ideas floated in the Discord such as separate markets for computation gas and storage growth a less fresh solution might do more good than harm and we could free up Plunge in engineering for more bandwidth for more important work such as the base

of the op code

Tim Beiko: thanks I guess yeah Martin you have your hand up but one comment from the chat uh William if you have a copy of you know

your remarks uh that people can read async they think that would be valuable

uh but yeah

Martin Holst Swende: yeah I won't answer all of that uh but I do want to say that yeah I can spin up and test it on on a Raspberry Pi which can do 10x or the ethereum blue uh from a clean State program uh we're not going against that state however uh but that wasn't really what I wanted to say what I wanted to talk about was the changes that have been made on 3403 since last call we did change we eat a little bit so that the refund

um now makes it better to send the execution setting the zero back to zero then if you use the um to one to one so it added uses zero one zero pattern and resetting um something else I want to mention is that the implementation the full implementation of this in global ethereum is very small let's link from the Eep um the possible coordinate cases and edge cases from this I think are fairly limited and are easy to test within like if you basically just executing some

source and it's more or less tested the tool the full coverage of the heat so I don't think it is a large burden on testing and the last thing I want to mention is that something that we're seeing a lot is that miners are at times of low capacity they're using the refunds as a battery and they fill the immense gas opens various times um into their blocks because it's free for them and at later points in other people's books so they can get extra money when people use their main Grassroots

uh and this battery yeah so our the ethereum state is being used as a battery uh to get more money from in a block and I see This is highly problematic for State growth and the sinking and estate right yeah that's something that really think it's important to get rid of as much as possible

that's all I have to say thanks uh vitalik uh yeah yeah

Vitalik Buterin: I also just wanted to add that I do think that it's worth taking

these uh the four experience risk seriously in part because it's likely that poster or very possible in um but the miners are going to vote the castle it up just because fees are extremely high and uh 2929 does mitigate some of the risks of doing that though they're still the state the the state size issue that'll realistically end up getting handled after the merge and so like basically it's not just the possibility of 50 million guess what potentially a possibility of a higher than 50 billion gas blocks and the user like the user experience benefits of opening up more gas-based are very significant and they're probably just in

terms of raw magnitude much more significance than the inconvenience specific refunds works a lot less well uh so just for that reason that would be a kind of wary of saying you know oh we can handle current blocks in 300 milliseconds and so we could have we could handle things therefore for them bigger just fine

huh Martin did you have another comment on that or did is your hand still left oh sorry

Tim Beiko: um I guess yeah before we make any decisions about you know what moves into test Nets and devnets and whatnot uh it probably makes sense to just go over the entire list so we have a feel for you

know what are the different proposals um does anyone else have any final comments on 3403 before we move on to the next

deep

William Morriss: yes uh I think that uh the Forex uh Sprints would be very brief in scope and most nodes that are able to process it specifically the miners would be fine and even if a Raspberry Pi was left behind they would be able to catch up in the meantime um and the the reason that Forex should be fine in the long term is that sync time is the primary uh motivation I think for setting Target gas limit

got it

Tim Beiko: thanks um so next on the list was the basically opcode uh we've talked about this a few times um I don't think anybody had any concerns about it or the concerns that were there uh I think were addressed by by vitalik in in the issue itself uh does anyone have any thoughts comments about it

it's uh it's as close to literal One Winery Ed he doesn't like me to get uh so I don't know to me it just feels low cost anyone else

um yeah I'll probably go online okay okay

Tim Beiko: so yeah let's go back to it at the end uh next up uh eip374 uh yeah so this is the first time I think or maybe second we discussed it on the call but I know there's been a lot of change on Veep so it's probably worth taking a minute or two to just give some background on what it is and the changes that have been made

Sam Wilson: so a quick summary of 3074. um it's coming out of sponsored transactions but it actually has a lot of uses besides that um it increases QR codes off and off call uh so awesome let's see you uh take a signed uh message that's specially constructed and it sets a context

variable that stores the recovery address from that signature and then we have the off call off code that when you when you use it it works like a normal call except it sets the uh caller address to the recovered address from the previous signature and this lets you do things like sponsor other people's transactions um do an erc20 or a proven transfer in a single transaction um it has a really a lot of really nice like UI kind of improvements um for users that we want to bring to ethereum

is this something that someone could well I like we could have community members testing what it would be like to

interact if it was on like a YOLO net like some stuff you sort of need more state or some stuff is more tools and integration testing

Sam Wilson: so um you could interact with this um today it's a little tricky because wallets don't generally let you sign arbitrary messages but we haven't tested up already um if anybody wants to play with it and uh yeah you can absolutely start using it right now and writing special contracts that use it

I think it is um worthwhile noting that this Erp um well maybe a little bit contentious uh here for foreign I think a lot of these um well the

developers and and services like influence on would be very interested in kind of like already um experimenting with it once once it is in in it has that so I would expect like some prototype kind of support for it too much very quickly as part of the testing stage already yeah we actually

Sam Wilson: had a community call I think it was last week and we had a ton of interest and lots of people were interested in uh using it so

foreign Thomas

Tomasz Stańczak: yes sir I wanted to ask about security consideration so like is it introducing any risk that people behave similarly to

allowing unlimited spending on the erc20 tokens you think yeah people will be

yeah okay yeah excuse me

Sam Wilson: there are a lot of like significant um security kind of considerations is that things you at least have to be aware of so we have this concept of like an invoker contract and I'm just going to provide it now because we're going to talk about it a lot uh so an invoke a contract is the contract which contains the auth and the off call instructions um so these these kind of invoker contracts are going to be um like if you if you sign a message to one of these invoker contracts you're basically delegating control of your eoa so you're saying I'm authorizing this invoker to act on my behalf so these kind of invoker contracts are going to

have to be um you know fairly well audited users are going to have to trust them and it's probably only going to be a handful of these well audited vetted contracts that exist um but yeah so it's it's kind of like giving away it's delegating control of your

your ear um like

Ansgar Dietrichs: just just for context they're like we were out of the initial conversations that we had with a couple of budget bullets like notices uh a rainbow wallet um um yeah ATX people from Iran and so on yeah I think most people at least right now would anticipate that there would be like like one or a handful of esc's um for like a specific implementation

fundable contract and then those wallets would only even expose the functionality to sign for like these exact implementations um to kind of like um remove exactly this kind of risk factor for the users

oh

sorry guys so I I just wanted to say because I we had this conversation on the on a Discord but I suppose it wasn't mentioned here uh I'm not going to be fighting it all the time because it's going to be very exhausting for me to do that but I just wanted to remind that I had a serious objections to this EIT and this is because it says Thomas mentioned the security considerations and I think it's it's the uh it does change the the

properties of the signature in ethereum not only for the users of this particular Rip but for everybody so and although you can argue that it's not significant and it could be you know it's the same on the same level as the batch transactions but and nevertheless it is introducing something which hasn't existed before in terms of security so the security of signing something for smart contracts does change with the CIP and I actually wanted to compare it well jokingly that's not only semi-jokingly you might have seen the pseudo op code being proposed as a first up April joke and I actually did look at it at this

pseudo Aid and it does have a similarity with this one of course it doesn't allow you to do sudo for you know without any restrictions but the Restriction that this AIP is is actually the setting setting up on Sudo is that there has to exist a certain signature that authorizes the pseudo but once the signature exists it basically authorizes in any number of transactions so that is my main objections and of course you can still push through it and it's very well uh kind of needed but you cannot you this thing needs to be decided so explicitly decided whether we actually as ethereum users only users are going

to accept this extra security uh relaxation

Sam Wilson: so I think the specific complaint that you're or concern that you're raising is that we're changing the property of signatures from being able to perform a single action to being able to perform many actions so as an example like right now you can make a signature that empties all of your eth or all of your ERC like a single eoc20 but with eip-3074 you can make a single signature that empties your entire account and takes all of your erc20s and that's kind of I think what you're saying

is your concern

uh yes correctly so this wasn't possible before before this AP but it will be possible after the CIP so just give one signature and it will empty

everything that you've got from all the tokens

Sam Wilson: right so I think I think this is similar to giving away your private key would be the equivalent like non-eip 3074 analogy for this but I think eip374 is a lot safer than giving away your private key

because don't give away their private key right now right

exactly

Sam Wilson: exactly right because it's not safe but we want to be able to enable the use case and where your private key does but do it in a safe way and that's what eip374 does we say we're giving your you know delegating control of your eoa to a particular contract which can be vetted and it can be verified like right now

people might want to give away their airways but they can't because it's not trustless we're enabling that kind of a use case in a trustless way

Ansgar Dietrichs: I think it's also like important again to know that um wallets we've already come um I think we've been a couple of like five different major worlds I think something on the other piece I mean they all intend to just basically lock down um functionality design um over 3074 messages completely so basically like not allow not explosive at all and then only selectively introduce that back in for like specific uh escs that again that are like well um audit or something I mean it's also important again to note that like a part of this authorization

um scheme that that the people provides is that you can sign over specific data so it's so the this is my contract can um and is expected in general to have restrictions about what it can what it can actually do right so so in like as long as it's not a malicious again attack where you just sign arbitrary like a like a um like a attacker provided payload basically but again expose their functionality if you sign specific message to one of these well-designed invokers then they would include like a restriction that the signature is only ever valid for one time um transaction that has Reaper protection all of that integrated in the contract

yes okay you don't need to convince me right now but I just wanted to make for

a record that I did object against it and you can't say later on that nobody

objective that's it yeah

Martin Holst Swende: so what I want to say I wanted to say basically exactly what Alexis said including um including the things that yeah this is basically the real pseudo of code and I I totally get that this is very useful Sudo is useful and a lot of things are very useful but I think that I I may be wrong I think that the people who are interested in this and who are pushing this they see the usefulness of it and they're all the developers and and

advanced level there to um aggregate there's a transactions or whatever I think maybe that it has not been thoroughly invested from a secured perspective on the application layer and later on and I think that monsters is introduced there may be new attack vectors that come to light and get discovered uh side effects of this and I think that it's too early to think about having it even if it's like even if it were simple to implement on the platform there I'm not sure I'm

not fully convinced that all the the downsides from the ux perspective and the whatever implementation on the on on layer 2 uh has been fully brought to life and I think this needs more time that's my so I'm I'm with Alexi on this at the moment

uh James you had a comment and then metallic yeah

I just was uh wondering if I'm understanding this right that the security considerations uh as far as like client developers and client implementations isn't so much in the client itself but

it's that it's pushing security that it's pushing a lot of security stuff to the application layer that hasn't really existed before and that's like where the big security question is there any of the underlying security things that bother people for like fine developers I mean client development side of it or like dot sectors or stuff like that

yeah

Martin Holst Swende: I don't think this is a Nelson Victor kind of thing I I mean I think we can handle the consensus changes as well yeah what worries me is the user because the sharp edges for users

Lightclient: have you had a chance to to look at the threat model document we wrote on 3074.

because that kind of was produced

out of unfortunate Alexa

Martin Holst Swende: right no I I would have liked to really dive into it uh and spend a lot of time on it and I think that would be needed um but I am from it um and I guess that's one reason why I think is premature um that makes sense and I I mean I suspect a lot of people would need to sit down with this and read up and really think about it hard for a number of days um and I'm not sure enough people have done

it that's my concern

yeah but basically sorry for what's new but I think it took

me about four iterations of basically trying to understand what it does and then the guys explaining me what it is and I like okay I was wrong like four times about what this EIP actually does so I think just to give in a glance is not cut it you actually have to spend a lot of time uh to look at it to understand it so that's why you know if we only have a few people who looked at it I think it might just Overlook something

yeah

Sam Wilson: like the implementation is pretty simple but like grasping why it's why it's safe takes a few reads through

for

sure and then it goes It goes back to my comment in the beginning of this call is that you essentially when all these

things are piling up on us you know you've got to prepare for London you've got to prepare for Shanghai go to review these things I remember when I was actually looking at this IP I literally spent the entire day trying to to actually even just look at this money I wanted to do it but you can see that it does drain um a lot of uh energy and time from from the core

devs

Martin Holst Swende: and so the topic has been raised sometimes about Security reviews normally when we're changing something in the platform we as client developers we can kind of get the center yeah we we kind of know what we're doing the Disney World code uh I think we can handle it with something like with like this which

touches the application layer might be actually makes make more sense to to hand it offers on March or may not handed off but to hire some smart contract Auditors that really know the application layer and the ux stuff and have them I think that would be a good step

every system to mention

Ansgar Dietrichs: that briefly like um again because I I think they're generally agree with all these these points raised just like on the topic of many people would have to look at it I think it's maybe not kind of like obvious in the way we present it but like I I think we've been relatively active in kind of reaching other people

it's been mostly focused more on the wallet application side because again that's where it's more relevant but that like a lot of teams have been looking into it already in a I would say fell fairly um detailed uh level for example also like the um consensus diligence team uh has been fairly involved in the process as well um and so on again just in the combination of like uh that there are a lot of applications that would really um like to have something like this in the protocol um that we are uncertain when the next teacher folk will be I think all of these are no reasons at all to make kind of compromise on the security side all I'm I propose at this point was like if it makes any sense at all so maybe at

least move forward with it with it into the deaf and it pays just because you already have the implementations ready basically no effort at all and then just see if people like by the time we have to make the final decisions like get in a position where they are comfortable enough having looked at it enough and all of this and if not then like fine then can just move forward to the next iteration for Shanghai or whatever next you talk will be um I personally like I mean of course we are like we're biased here but like because we have to spend a lot of time with again non-protocol developer people looking at this I I think there's a very decent chance that people would be convinced being secure by the time the decision has been made so I would personally

prefer to at least move forward to that stage but but if of course people are already like convinced that there's no chance that it will make it in then I think there's no reason why I should um be part of

the deafness uh vitalik and Thomas yeah do you want to have your commenting no

Vitalik Buterin: so I just wanted to say that I think in the long term the ability for a single transaction to send air to so it would trigger an arbitrary number of operations is going to happen just because I think in the long run we want to move uh people to using smart contract well what's my default whether that happens

um you know through um yeah it's like esp2938 type I came with abstraction or through some flash flood sting or uh or something else um yeah and so but we can't rely on this idea that you know you can only do one operation or per thing that you sign as a long-term security property but I do see the like kind of the rationale for not doing this too quickly I think one thing that could be helped that might be helpful is for kind of people who are um skeptical about this about the security issues to at least kind of fake through and maybe write up a documents about what their specific concerns are just so we have uh and move

toward having an understanding of what the issues are on paper because it we are going to have to come up with so ways of addressing them regardless

uh Thomas

Tomasz Stańczak: yeah I think I just feel that this uh intuition that Martin was mentioning is important here so we were asked not only about the security of this party karaoke but also to answer uh which of the cips can be very lightly included in devnets without thinking that there are very heavy ones I think this one is heavy because it requires a lot of organization of uh talking to the application layer developers to wallets

uh uh wallet creators and so on so maybe arranging some calls that would be specifically dedicated to this EIP similarly as we did with you if you want 559 um I think a lot a lot of thinking and I'm here on the Alexis side as well and it's the one that may drain a bit more uh time from us to to analyze properly to read to think of it

okay that's definitely something just oh go ahead I

Lightclient: I do just want to mention that that we did have a community call about a week ago with several world over teams and we've talked with like on the order of you know probably two dozen people or teams specifically about this and I

would feel I do feel like the number of people who have gone in depth on the CIP is probably greater than 15. so that may not be being communicated very well because we don't post about it on all Cortes but we have done pretty substantial Outreach to application Developers and you know it's we can't like force core developers to review this sort of stuff but I and I feel like we're kind of at a point where we're really happy with where the Eve is it provides a lot of value and it's kind of down to the point where it needs to be reviewed by core developers and you know I don't know how long that would take it that's a day or multiple days but I think that you know it that's really the main work

that needs to be done on this EP because we have the resources to continue pursuing it you know to London or Shanghai whatever the next feature for is it's just a matter of hitting some sort of you know tentative green light this makes sense to put into a protocol and then you know teams have already committed resources to help you know any client changes need to be done or develop things on top of it

Sam Wilson: like uh for example the inferior transactions uh team has already written an example invoker that they could use with this like there's already people that are like chomping at the bit for

the CIP

Tim Beiko: so I guess clearly you know like it seems like there's value in getting

obviously client devs to look into this more but I'm kind of mindful of the comments about you know there's a ton of stuff that people need to look at um does it make sense to go over the other Apes right now and um if you know at the end we decide this is something we do want to look at sooner rather than later um we can organize something like a breakout room or whatnot but I'm a bit cautious of like deciding to organize one right now if it just leads to like client devs not prioritizing it and you know then there's not a ton of value uh or it just you know doesn't move the

Eep forward much um one thing

um that I I think we have we could probably have I would do a lot better if we have later party or trailer bits or whatever or take a look at the eat and make make an actual report security report from you user perspective um that I think we can do that from the from the foundation okay yeah we can probably put together rfpe on that soon um and we can Circle back with your team well on like yeah that sounds good just hang us um cool okay

Tim Beiko: so let's have that as the next

step and then Thomas you have a comment in the chat about looking at it and implementing it and giving your perspective so if you want to do that as well that's obviously very very valuable

um vitalik you still have your hand up is that do you have a final comment or did you just forget to lower it uh no sorry I was I forgot about it no worries okay

Tim Beiko: uh next up on our list is 2537 um so I think there's two things uh actually here so uh Kelly is on the call to give an update on the actual pre-compile and Paul is on the call to give an update about evm 384 uh so Kelly if you want to go ahead first

Kelly Olson: yeah sure um so I mean I think the the brief update on eip2537 is that uh you

know it's largely in the same state it was uh you know about six months ago there's been some minor repricings uh to the to the pre-compile but other than that uh you know basically no changes and so really when I what I wanted to chat about uh in the call today is just sort of you know what additional information is needed by uh the core developers um or you know if any you know in terms of moving this forward to eligible for inclusion uh one other note I will make is that I did uh put a report out into the awkward chat uh yesterday that gives some comparison versus EDM 384 uh that Paul's done a lot of great work on so I would

just note that you know I don't think that this is necessarily an either or type scenario between uh two five three seven versus dbm 384 but you know that they both have uh their own merits and I think the question is how best to support dlf-12381 uh natively in in ethereum

so I have a question sure

Martin Holst Swende: you mentioned uh pricing updates and I'm that makes me curious uh because the the current pricing model was found to be pretty good I think

[Music] um and conservative but good and safe so I'm just curious how the changes

Kelly Olson: sure yeah I mean from what I recall they were they were relatively minor So like um you know a point Edition went from 600 to 500. uh everything is still even with the new pricing is over 25 uh million gas per second um with this new pricing so those these are some changes that I'd seen Alex had made uh who originally authored the EIP maybe a couple weeks ago but they were relatively modest uh changes and it still seems like it's well within the safe boundary

uh James you have your hand up yeah

James Prestwich: um as far as I know the pricing adjustments are related to actual

improvements in the implementations being used um and as a side note you know uh 25 37 and 25 39 are scheduled to activate on cello uh sometime towards the end of this month um so we're we're taking those uh mainnet

Kelly Olson: great yeah yeah maybe one other thing to add into addition to that uh one of the other developments with eip2537 is that um a library has been created built off of last which is the library used by each two clients uh has undergone an audit and is undergoing formal verification um so while this isn't what's implemented in the ethereum one clients today uh it is now a new Option uh you

know for something that you know maybe has some higher Assurance properties uh and I guess you know to James's point this library is on average about uh 2X or more faster across every operation um versus the one that's implemented today so from a gas perspective you know longer term I think there's an opportunity to reduce it even further um but in the short term you know right when you said the amount that it was faster oh sorry it's about it's about 2x across the board uh two of X Plus uh so this is an option you know if there were concerns about gas pricing you know certainly uh this could be used as well

uh Paul you have your hand up

yeah um EDM 384

was mentioned in the issue uh the the agenda item issue uh link from this agenda item and I just wanted to share good news about evm 384 there were a bunch of breakthroughs in the past few months it is now we're within one to three x of uh pretty compatibles and gas cost MMC 2x for common cases and I have the back that shares some evidence you can reproduce so again one to three x slow down with evm384 and 2x for common

crypto systems that's it uh Thomas um yeah so

Tomasz Stańczak: we have it implemented so

because this was one of the questions of how quickly we can uh we can use it so we haven't implemented based on the previous libraries which means we're lost we would have to rewire it but there shouldn't be too much of a problem um I think what I would love to hear is the and the list of use cases who exactly will be using it because that's uh slightly similar to 315 I believe that uh the only concern of mine is that there are like uh two or three people pushing for it for some reason which I just not fully understand it's like what is the reason what exactly are the use cases why it was so important for cello uh and I believe there might be some

fantastic cases because I just compare it to 384 and I wonder is it great to push this one because it seems that it is needed as we have one year already when we talk about it and people keep asking for it so there is some expectations from the community that it will be there

so yeah yeah I can

Kelly Olson: I can maybe speak to that briefly um so I mean I think you know one of the largest use cases which is you know will take a a while to materialize is the support of uh ethereum two signatures right and being able to use uh data from ethereum too and I think that was one of the you know at least original motivations uh as we had looked at sort of um sharding ethereum 2 prior to the

merge so I think that was an original motivation uh the second one I would say is interoperability um So currently Z cash filecoin pesos algorand Gia and Harmony uh as other blockchains all support or use the BLS 12381 curb in in some way um and and by and large the main use cases there are sort of new cryptographic capabilities um so things like aggregated signatures and threshold signatures uh as well as you know there has been some desire to uh for those that are doing ZK Roll-Ups to move to a higher level security curve though I you know certainly I think that's going to be something that is is going to follow you know after it gets

implemented right I mean I don't think that there's a uh most of these ZK roller projects are sort of commercially driven projects and they're using what's available today which is the the VM curves um but I do think there is a desire uh to to move to a higher level security curve at some point

yeah sounds very convincing

Vitalik Buterin: um one comments I would add is that the E2 related motivation does continue to apply despite the accelerated ritual because in order to have a roll up that verifies uh or that works off of data in Eastview charts you need to be able to verify that it has even in a single short law actually equals through a

piece of data that it's going to be and to do that you need to be able to do hippos law of 381 faster linear accommodation inside the

eem

Tim Beiko: and I guess just to come back to the original question that Kelly you ask is like what core devs want to see you know to move this forward uh I think Mika you had done you know some work there a while back of investigating uh I I recall there was a conversation about you know what happens if there's a consensus failure how do we deal with that um is that still kind of the main blocker um to including this like what library do we use what do we do if there's a

Divergence between different client implementations and

whatnot all right

Micah Zoltu: was that directed at me or you just including my name and the question

Tim Beiko: so I know you I think you were one of the last at least you were the person I think who summarized all those conversations um if you have the latest you know summary of where we're at that would be useful but if anybody else has it but also good

yeah sure so my

Micah Zoltu: my impression of the previous conversations was just that the main concern from the core devs is that they do not have on staff cryptography experts and so if a at 5am in the middle of the night wherever the courthouse live um there's a consensus failure they

don't have expertise to step in and rapidly fix it and you have to call out to third parties and get a hold of them and this is a complicates thing so it's uh changes the risk parameters for the core devs um the issue I have with that particular argument and this is why I'd like to come up with a solution is that eventually we are going to include New cryptographic Primitives like ALS because of stuff like E2 and so if we need to solve that problem eventually and the longer we put it off I think the harder it becomes because right now we there are some techniques we could use to address the problem short term such as like we put it in as a pre-compile and we just assert to everybody out there that if this feels consists failure the Quick Fix is to disable the

pre-compile and then we'll get the chain back up and running um once like the merge happens we need BLS to like do real things we can't turn it off anymore as we lose that ability the longer we wait and so the more they scan down the road I think the harder it will be home for us to um to take some easy paths to kind of testing the waters with

Els if

Kelly Olson: that makes sense yeah I think those are our great points Mike I guess you know just have on you know part of some of the work that we've been trying to do over the past couple months is um you know to make the last option just you know as it does have a slightly higher Assurance level and and wouldn't be compatible you know consensus bugs and all with with ethereum too

um you know I think you know maybe another thing to that point is that there is a wide group now of developers that has at least experienced with the library um obviously you know cryptographic you know pairing based crypto cryptographic expertise is you know a limited resource but I do think that there's a number of E2 developers who are you know quite familiar with the the internals of blast as well that can hopefully you know mitigate some of those risks

okay and James you have your hand up

James Hancock: I was just typing this out in the chat but I was wondering if the BLS is something that we needed that would be best to do before the merge if we did it

at the merge would it have a like extra security considerations or could we just say let's do it after and it doesn't matter kind of a thing

Dankrad Feist: I think it's not critical for the merge I think it's best to do it after and it would be good to have it before

shouting

James Hancock: so probably not during the merge but either in a feature Fort before or after

Danny Ryan: I think there's a little appetite to do any modifications to the evm at the same time of plopping the consensus just from like a separation of concerns and security

I mean one question I would have is is is it eligible for London pre-merge given that it's implemented in already of the clients and it's been run on two yellow test Nets already foreign I mean I mean in in general we should just do both eventually when they're ready yeah

I just want to mention for evm3 if I'm in touch with cryptographers who

will use it for various reasons and also evm 384 is useful for deprecating for example deprecating the BN pre-compile so it has a lot of applications independently um so I think that's a nice way to put it uh James is just to do both but I don't know what the client of uh wants

Thomas you have your hand up

Tomasz Stańczak: I just wanted to defense lean London once again so yeah I think I think that the the Shanghai in parallel is the merge would be a great place where I would fully support it to be included to to 537 um as for London I would love to see

just cop1559 there and the difficulty

one

Tim Beiko: got it um just yet because we because we're more EIP 's before we make any decisions for like the devnets and and whatnot um hopefully we can go a bit quicker these three last ones seem a bit smaller um 23 27 begin data I don't think the person who actually wanted this is on the call today so does anyone feel strongly or have any comments about it worst case we can move it back to another call

I'd

Greg Colvin: I'd like to support it um yeah Martin's not here uh Griffiths uh Christian brought it up for the agenda uh the only possible issue I

thought and uh and Martin uh spend they might be able to speak to this is whether we're concerned about existing contracts uh possibly counting on invalid op codes to stop themselves I think is the issue would that would that be correct Martin

Martin Holst Swende: uh I can't say I don't really recall so I think this begin date uh is not doing [Music]

um I think it's maybe not sufficient and it could be done differently and better and I know that problem access and a few more are working on yeah proposal which would supersede the begin writers and the loan proposal uh yeah I'm yeah I don't know what else to say I'm I'm not a fan of the beginning date uh proposal as I've mentioned before

Greg Colvin: I'm a fan of some such functionality um to not have to squeeze data into unreachable sections of code

Tim Beiko: um so I guess yeah just to keep it short uh you know because we're close to time purely there's not like strong consensus and there's still this active discussions on this yeah okay so I yeah I think we can move on to the next

one okay

Greg Colvin: I'll just I'll jump ahead and save time actually this uh 384 um access um supersedingness with an encapsulation format several other things are all evm changes so I've just uh reopened a magicians group on that we have the evm channel on Discord and I just encourage us to uh come together there some and

discuss these evm changes together so they can appear as sort of one coordinates coordinated set of changes whenever they do appear and not just be a scatter shot set of VIPs and certainly that's not London and probably not Shanghai as it's going

but uh that makes sense yeah thanks

Tim Beiko: I posted the link to that each magician's thread in the chat here for people who want to

to contribute Mr

um respond to Greg I agree I think Christian called for a conference in EDM improvements conference or something where we can all get together so I think this is aligned multiple questions that

bring the subroutines uh uh discussion recently so I think it's a good idea to for us to all come together I just want to say I think there's too many moving parts right now uh with the merge with 1559 all of these things like you said so I think that it's nothing is so urgent that it has to be done immediately um but but yes I agree that we should all come together and I'll I'll have some sort of content or meetings about future of evm and evm

improvements thank you yeah thanks

Tim Beiko: yeah lots of things we would like to have conferences for right now um unfortunately we can't uh next up I think this was a pretty small leap 2667 at 2677 sorry this is limiting the size

of minute code I think Martin you were the author on this

yes yes

Martin Holst Swende: I was um it limits Society in the code because code is already Limited um yeah so currently someone can execute one megabyte of encode which is not really a problem it has happened the many client which controls in chain can obviously handle it however there might might be situations in the future where we want to do more work and I'm thinking of things like yeah where we want to validate more things about the the execution um and not only do the complex

validation maybe we wanted to do other kinds of validations um whenever we want to implement that it would be nice to have a guarantee that you know we will never do this on a piece of code which is larger than 48k so if your implementation can do whatever kind of validation is needed within a certain amount of time for 48k data then you're going to be fine and we're not going to have a new case of service attacks with someone exploits these valuations on one two megabytes malicious initial data and that's about it implementation wise

it's small there are attaches three points create creative and transaction create and these semantics of erroring in these cases are not new

that's about it

Vitalik Buterin: um one kind of longer some points on code so when we have code multiplication and so we'll be able to have um witnesses that only touch the part of the code that a particular transaction executes one side effect of this is that it would theoretically be possible to allow create to create much larger

contracts because each transaction will only still be able to access a small portion of that code because of gas restrictions um do we anticipate but do we anticipate any kind of secondary risks of that like do we like do we anticipate there being any kind of fundamental risks of code that gets created um going up to say half a megabyte even taking into account the degree it operates that would still have to pay attention for that

Martin Holst Swende: uh I would say no because if we even if we execute on arbitrary large code if that code is miracleized then we don't have to load

entire code into normal installation because immortalization will already provide us with that information however if if we have the init code I mean it's still useful at that point to have a limited

income right agree because you have to deal linear time pre-processing like and whatever the merkeling is accurate processing and that's fine if you charge 200 cash for it but for an input we don't um yeah it seems fine

Martin Holst Swende: and the I think the main security concern here is that uh yeah where the whether that limit is high enough that we don't break anything

um that is something which is kind of easy to check um I am not wrong so I don't know if anyone else responsible either

I have played around with some cash thrashing attacks with evm code and they do increase so you know if you have a large byte code and you can make each like a lot of maybe perhaps Johnson on each one uh causes a some sort of a cap level miss or something there is a Slowdown I don't know how big it is I got up to 2x slowdown maybe people can do worse as a byte code size grows uh so it's this sort of cache Hardware you know you have to understand how the hardware works um I don't know what the limit is but I think we should talk about it I'm

willing to prototype or extend my prototypes the larger you know longer bike code sizes and things like that

oh

Martin Holst Swende: I wasn't really referring to attacks U.S and large unit codes I think we I mean I know the worst case the notorious case for guests and I think all client developers without implement the jumpers houses that is what what is it you know foreign I was more thinking if there are existing concrete large contracts where the inner tone is more than 48k because they they encode deploys not only one but once you know two or three

contracts at one at the same time and we would ask uh destroy them for this kind of change uh that's what I mean not that we haven't really investigation I will be prudent to do that

okay

Tim Beiko: I just we only have a minute I guess we're gonna go over by a few minutes if that's uh not too bad um Thomas uh yeah sorry I asked about 29 35 in in the chat uh I don't think we can get in depth into it now but do you have any quick comments you want to make or things that people should look at

or consider yeah sure

yeah sure

Tomasz Stańczak: so uh we have the initial implementation of the 935 and uh we'll focus on adding the uh test uh test cases for race that can be used by other clients to test implementation so 2935 uh introduces lots of opportunities for the status clients and synchronizations of stateless clients but also uh interesting use cases for uh the centralized Finance applications where you can do some checks on the past State and make settlements based on that um yeah that's it and I would like to propose it to the devnets alongside the other

offers

okay yeah a

quick question of implementation like is that like a a weak kind of thing a four-week a complexity just a hand waving number

Tomasz Stańczak: it took me three hours but uh I think you properly analyze it around it it may take maybe a day or two

okay cool okay

Tim Beiko: and then the last one we had on the list was discussing uh the difficulty bomb so we all agreed to put it in we never agreed how far to push back the bomb um I feel like that's a better conversation to have once we've agreed uh whether Shanghai is the merge or not um and have a better view for London does anyone have any kind of urgent comment about the difficulty bomb

nope okay if not I think yeah uh if people can stay for a minute or two uh the last thing that would be useful to figure out is what do we want to do for the different devnets um just being mindful of you know how frequently you're cutting out oh am I am I still cutting out here oh sorry I'm cutting out cool so for the devnets you know a lot of people have mentioned there's already a lot of things we're working on I would propose that the first devnet be maybe only 1559 and that we start to tentatively add stuff for like a second one the people have any thoughts on that

makes sense

okay so uh and I forgot maybe just maybe the base the base via code possibly I was gonna

Micah Zoltu: say basically as well that one feels like I don't see any reason to not throw basically in there it's just so simple

Tim Beiko: anyone disagree with that base the op code in 1559 I'm okay with included so let's do that um let's add the base shield code to the to the devnet um do we want to discuss I know already over time what we would potentially put into a second devnet or do we just want to wait and see how this one goes and how that conversation in two weeks

two weeks

I put something in chat but I can just put it in the Discord

so the devnet okay yeah

Tim Beiko: I see your your comment okay so let's yeah let's maybe wait another two weeks anyways there's still some work to do on 1559 to resolve the spec uh so it's not like we're setting up the devnet tomorrow uh but I'll put us I'll put a specification for the devnet up uh probably early next week but just at a high level will include um 1559 and the base sheop code in this first version and we'll use I forget what the name was but the name that like client proposed uh earlier on in the call

and that was it any final comments thoughts

okay well thanks everybody and happy Easter to whoever is celebrating thank you cheers [Music] foreign

[Music] [Music] foreign [Music] [Music]

foreign [Music] [Music] [Applause] foreign [Music] [Applause] [Music]

[Music] [Music] thank you [Music] foreign [Music] [Music]

[Music] foreign [Music] [Music] [Music]

thank you [Music] foreign [Music] [Music]

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