All Core Devs - Execution #178

Transcript

[Music] [Applause] pleas

time J

Lightclient: cool thanks a lot hey everyone welcome

to all Court devs 178 uh first all court devs of 2024 Happy New Year's everybody hope you guys had a good holidays first thing on the agenda is denune updates I know that this wasn't listed on the agenda but I just want to check if anything happened over the holidays I know devet 12 has been up is there anything around that that people want to talk about before we talk about timelines

Parithosh Jayanthi: don't think we tried any specific tests over the holidays so um we were just keeping notes up and if a client team has something updated we

just updated

Lightclient: right on okay with that um Marius wants an update from Prism Marius what exactly are you looking for here

Marius van der Wijden: I don't know uh last time I don't think anyone from Prism was there and since prism was the one client that was kind of delaying stuff it would be really nice to know how they are progressing and if they think everything is uh is fine now or if they need more

time

Terence Tsao: yeah I can give a brief upate so also also like uh next week we'll do a Gord release but this will be a pre-release meaning that I we wouldn't recommend you um using S relas from net and separately will also have a m release so right now we're be couple because right now like uh we wouldn't recommend our um latest block future to be um to to to be part of the maina release so I think we're come so so basically I think we're okay with the Gordy timeline but I think like we're too early to setting the sodia and the host key one uh having them one week apart is like kind of crazy because it's

definitely harder to change like if something gy goes wrong because then you have to do a very like immediate client release to change the data again so we would not recommend setting the house key and the support for day right now

Lightclient: okay that yeah that kind of leads us into the next topic point but I just want to confirm with everyone that we are good with the girly date that we agreed on in the last allore devs which is Jan 17 632 UTC meaning clients would want to release sometime next week is that still what we're expecting to do

I think gu is fine with

that lotar is good with it

Sean Anderson: uh so for Lighthouse we've got all the NB changes done and merged um I'm not positive we'll be able to Rel next week because we've also got a lot of networking changes that we're still testing um but if not I think we could do a pre-release similar to

prism

um yeah uh for Tech we planning to release Monday or Tuesday next week

uh Bas

Justin Florentine: is here we're going to be releasing end of this week we just had to put out the for

for cashes

Lightclient: okay great uh yeah it sounds like

we are all in agreement on that uh Fork time I don't have the epoch right in front of me but it's out there so on to the next two test nuts AO and heski we last meeting discussed some days and there was some agreement but now it sounds like there's a little bit less confidence in those specific days ttim went ahead and came up with EPO on those days to to try and agree on but it's yeah I mean it sounds like we're not 100% confident on what what days we want to do those Forks are so maybe we start with sapoia sapoia is scheduled for January

30th that's almost two weeks after the girly hard Fork is that the day that we still feel okay with I mean obviously we can't foresee the future if something actually falls apart on girly then we we'll have to rethink that but in the optimistic case is that uh date that we can just go ahead and and lock in

pus

Potuz: yeah so I I feel that it'll be much safer since there seems to be sort of like an interest in in shipping the actual main net as soon as possible it seems to me that it'll be healthier if we don't schedule the next test Nets and

we schedule them very soon after girly if everything goes fine but sort of like having the back of our head if everything goes fine it's going to is going to be around these dates but try not to commit to dates now because things might not really go fine with girl early and going back from that is a problem like adding a new release with the the right ebok with no changes is easy but removing a release and fixing bugs is a problem and it takes much longer than than a couple of weeks

Lightclient: yeah I I mean my understanding is that you probably wouldn't release until the week

before but what how do other client teams feel about that timeline or what pus is saying

Marius van der Wijden: so I I generally feel feel feel pretty good about the timeline um I don't I don't really get what this would like bring us to not say right now that this is going to be the date um the like clients can put out the release uh shortly before that anyway so the only thing that this would like and if if something goes wrong then like it's it's we have to break anyway so um we or we

have to push the break pull the break uh anyway uh so um like if if this late in the process something something goes very wrong then we will have to delay anyway so I I don't see a point in uh not setting the dates now and um and just like have every client um release on their schedule however they like

good jender

Lightclient: you're unmuted did you have something you want to

say

yeah no I basically am muted through my uh Hardware mic

so okay I see all good

Lightclient: um yeah uh pus is saying if we set the dates now and something goes wrong we will definitely need to re-release on the rush uh yeah I I I think that Perry is right here Marius is saying that we don't necessarily have to release like we're not going to release next week with all of the forks the test net Fork schedules I think the idea is that we would release them as we gain confidence in

the roll out is that not something that clients feel like they're able to do so if we do move forward with Jan 17 girly and then Jan 30 sapoia that means we'd have about one weekish to see if the roll out and girly is working as expected and if it is we can go ahead and do that release you know seven to five days before the sapoia fork and allow people at that time to upgrade their clients do clients agree or disagree with that timeline

Sean Anderson: um I think the timeline makes

sense and we could say like January 30 is like a tentative date um and then after see how girlyy goes and we're setting the date

photus

Potuz: so these numbers are we release curly we test for a week or so then we make a release I guess without soaking just adding the fork for for sepolia and that gives teams to update their sepolia validators for just one week so it seems to me that that this this schedule will just remove the soaking of clients which presumably is

fine if everything goes perfect because there presumably won't be changes uh but if there's any changes then teams are not going to be able to soak them

Parithosh Jayanthi: well I guess if there's changes we wouldn't F on that date right because nothing has been released

Potuz: oh there's regular changes that don't need to be urgent or anything but the thing is that whatever whatever we release for Gurley we are going to have to take the same release candidate for for seola and not uh not make a new release cut their new release from the developed Branch or main branch or whatever Branch you're using that continue to advance because those

changes are not going to be tested

Parithosh Jayanthi: I'd make the case that we have to test those changes in the subsequent test net otherwise we make a release for main net and the main net changes haven't been tested anywhere

Potuz: and that's my point that we're going to be shipping some something without soaking

Parithosh Jayanthi: but isn't that always the issue I mean every Fork we have shipped with changes that were tested at the last

Potuz: that has never been an issue we always have had at least one week to soak before cutting a release for the next test net or the next

main net

Lightclient: is the proposal not to have a week to soak though like I'm saying you don't

need to create your release until around the 24th of January that's would be one week after the the 17th hard Fork

Potuz: right but if you can't after one week from girly you cut your release candidate then so that means on the 24th to actually release it you need to have it soak in a few days and that means that there's no time to actually test for to I mean to deploy for the people that are actually running validators so so you mean I think the two weeks is just too close that's what I'm pointing

so you

Marius van der Wijden: so you mean we would need three weeks between each test match basically in order to have your process

Potuz: well I don't really mind the last two holeski and and and Gurley I'm sorry heski and seia but I think we do need three weeks after gurly because Gurley might go wrong

Marius van der Wijden: yeah I don't like when we we always only had two weeks between test nuts and then three weeks three or four weeks to main net so I don't know like I I I see your point um I don't I'm not sure if I agree though

it

Lightclient: it feels a little bit like the

you know most client teams seem okay with two weeks uh I I know prism feels kind of strongly about going with something slightly longer I don't know if how strongly people have on their feelings for this

Potuz: we don't really feel very very strongly about this uh if girly goes fine we're fine with releasing the same deploying the same release this is not something that I'm willing to die in a on a on a hill and also I'm not really sure if prism feels like this I myself I'm not comfortable with the de with it dates that were set

understood Oscar

Ansgar Dietrichs: yeah I just wanted to briefly say

that this seems like basically more general question right that we should figure out for future folks as well and maybe maybe for the future we could try and and kind of have a more specified roll out plan for folks that we can discuss and agree upon not right before we have a fall coming up because I think now it's the unfortunate situation have to make that decision today um but but I think I would agree with marus in principle that we we we should be hesitant with kind of keep extending the times between kind of first test Network and Main net launch just because usually that's in a way like a that time anyway in terms of feature um work because we already have

everything ready to go and and we can't really work on the next work either yet so so yeah so I think if we there's the desire to have a more kind of drawn out process that's something we should probably then um discuss some like like like you know when when we have time and not not right before hard

F

Lightclient: yeah I mean it would be nice to come up with a consistent Fork pattern I think also part of it is we wanted to ship this in the the fall of last year so now we're really trying to make make it happen and I think we're picking a little bit more aggressive timelines than had we had

this conversation been happening in like October I think we would have been a little bit more okay with stretching things out but you know yeah we we we want to get this Fork shipped Perry in the chat has proposed or kind of reposed what we accept what we had already talked about which is the for or 17th of January 4 early 30th of January optimistically fork or sorry is that still you're saying release in the week of the 29th with the expectation of optimistic Target 30th

Parithosh Jayanthi: yeah but I think that's way too close so if we're going with that timeline we would go with the assumption

that Saia is being delayed by at least a week or two cuz if we are shipping G on the 17th and we need at least a week to analyze stuff then 25th is the ear earliest where we can say Okay gly has went has gone well or has not gone well um let's assume it did go well then we can commit to making a release on the week of the 29th which means we've already passed the 30th deadline for

Soria

Marius van der Wijden: so what what I would what I would really like to prevent is for us to have to go to another alore def to confirm the dates I think like allod devs is uh it's usually on a Thursday uh yeah now and um so afterwards we cannot cut a release

because it's it's like uh the weekend already um so the next the next like possible day to to cut the release is like the next Monday um so what what I would prefer if we would say okay these are the dates if everything goes right we everyone will cut a release in the week of uh on the all codv call and um on the on on the 25th and not have this that like and then we can discuss on all CV if actually something really really bad came up um and then we can we can still stop it but I would I would just really like like I would hate to go onto

another all Cod of call just to say okay sapoia is go now and now we have another two weeks to wait um until we can can actually do

superon

Parithosh Jayanthi: yeah but coming to prot's point that would basically mean from the 17th till let's say even if we do stuff over the weekend the 21st that gives us about a 4 to 5 day timeline with the weekend where we have to find everything that's realistically wrong with

gly

Marius van der Wijden: no we we we can we have all the time to to to discuss and and to find find stuff like we can always just say

Parithosh Jayanthi: we can always M start making releases right oh

but yeah okay I guess we have to switch to asnc then

Marius van der Wijden: yeah we can always say okay this is just uh like we will deprecate this release or we will just say we will remove the fog date or push the for date or whatever I like if this is if this is before mayet release I'm I would also be more hesitant to say okay we can just like move the main at release in the last in the last two days before before it chips but um for for test Nets I don't I don't really I don't think it's too bad

G

Guillaume Ballet: uh yeah I mean would it be possible to

just agree on two sets of releases uh two sets of of dates those that happen if everything goes well and if uh if something goes wrong you iMed immediately make the release like you don't have to go through a CD you just say something happen on girly so the protocol is we move to the other set of dates you just make the new release and that's it no need to discuss um discuss dates again on ACD and do the delay that that Marius was um talking about

Lightclient: I just think that if something goes wrong it's hard to be able to just unilaterally say this is the next date that we should do like we're we're probably just going to have to discuss

and depending on what we're wrong to yeah mean as onar saying we need to figure out how much time it's going to take to fix how much time we need to continue reviewing so I think coming up with an optimistic date for assuming things continue to go correctly we ship the forks on these dates as like what we're trying to do and if something goes wrong then I kind of think we have to revisit the conversation a bit

Guillaume Ballet: yeah I meant more like if something goes uh wrong like yeah there's a couple bug fixes that are quite light but yeah of course if there's a major bug that gets un covered then all bets are sorry all bets are off of course okay yeah I mean okay just trying to avoid the the the bike shading

a bit like uh it's it's fine by me honestly I don't care if it's an extra week if we just push we just add an extra week between gley and the next the next test net uh but yeah if if it can save some some discussion and uh I would rather do this and uh and hope

Lightclient: yeah uh it it's sounding a little bit like client teams are wavering a bit on the genan 30 dates am I understanding this correctly are people kind of also open now to maybe having that one week later or fiveish days later so that

would be early that would either be late in that week of the 29th February 1 maybe or early in the week of February 5th so February 67 that would be for the sapoia or do we just want to move with the January 30th Mario says January 30th okay

basic is fine with 30 of2 we don't we're good to go I I'm just I'm a little more compelled by the side of our conversation that happening uh in the

chat but we can maybe put a agenda item on for that

Sean Anderson: uh yeah Dan brought it up it's related to like the um blob uh expiration so like do we want to wait long enough to observe blobs expiring and the implications of that on a test net before working the next

test net

Justin Florentine: um I think can I add a little something to the question Matt I think we also want to I think apps and l2s might want to go through that as well

Lightclient: yeah I mean does any client team feel strongly that that we need to see this happen before moving to the next

test net my two sense is that we're going to see it happen on the test Nets before main net and that's really the big thing that we want to see but um carries Char perspectives

Sean Anderson: um yeah I kind of also think it's not really worth waiting between each test net that long but it might be justification for waiting longer between the last test net and

mayet

Lightclient: okay so you're saying you might want to see on heski the blobs expire before moving to main not or any

test net

Sean Anderson: definitely any test net um yeah I'm

not sure it would really make a difference with holki but with like between test Nets I mean but yeah yeah

Potuz: most probably sepolia right uh I think most teams have deployed either Gurley or sepolia not that much in heski and since the is supposed to be the stable one I'd expect that we should main it after we tested availability and expiry on

seola

Lightclient: yeah that that makes sense to me um let's keep that in mind when we were thinking about Dom main at Fork date but we're yeah not out of the woods yet uh T proposed a Epoch for the sapoia

fork we kind of agreed January 30th begrudgingly can we just get a thumbs up on the epoch that was in the pr uh 13268 that's okay for everyone that's 2251 UTC on the 30th I see a thumbs from Basu and gu I'll assume the silence is agreement from the other clients okay soola we have some agreement on January 30th on that Epoch heski the proposed date is the 7th

of February I'm guessing people want to push that back one week is anyone in favor of doing that or would rather keep with the more aggressive timeline of giving one week between seole and heski WTH is okay with the week one week is good fantastic all right well let's uh stick with the 7th of February then the

epoch that Tim proposed is 29696 that's 1134 UTC on Feb 7 any last comments on the fork scheduling or should we just put that into a box and put a bow on it and ship releases great that's

awesome uh any last Denon questions or comments before we open up the next fork for discussion cool

Marius van der Wijden: so the next agenda item is the Prague Electra hard fork pectra and in the agenda we have a link to these magicians for which is a bunch of proposals that people would like to see in the next

execution layer hard Fork I don't know how you guys would like to go through this but I think it might be useful to answer the question of what is our vision for the next hard fork in the first place before we just rattle off 10 or 20 EP proposals so I know that there's been a lot of discussion about should we do veral in this next fork or should we have a smaller fork with some of these eips that that people are really requesting right now do any client teams have a perspective on a a smaller evm Fork this this year

or do teams feel that we should really lean into verle and make that the main priority and not ship another Fork until verle is ready so my my personal sorry oh Mario sorry go ahead my my personal opinion is that we should uh focus on verle and uh not sh anything between in between um because just the just the scheduling and the discussions will take up so much time because everyone like if we start opening this kind of worms then everyone will start uh lobbying and

pushing for the eips to go through um two small car carats with this uh one is that um I would like to have a like get a more concrete overview of the progress of verle and yeah second thing that I think we should also take into consideration is what's happening on the consensus layer um I went through all the eaps that were proposed and there are some that I would like to see on the execution layer eventually but there are none that I would say this is high priority super urgent but I think there might be some on the

consensus layer so um I think it's important for the consensus Slayer folks to um to to discuss whether it would make sense for them to have a hard fork with um those changes um and if that can be done without involvement of the uh El or whether it needs involvement of the El and we would need to do a a joint hard fog anyway and then I would be okay with um having a smaller hard for so highest priority is veral definitely and we should push for it um but with these two

caveat understood thanks marus uh Lucas

Łukasz Rozmej: so uh my experience tells me that uh state redesigns are extremely hard and they take extremely long time so for example uh G delivering flat layout took few years we are working on our flat layout for over a year and it will take at least another half a year to deliver it or at least few months to deliver it properly so um while I think veral is great and it's doing great progress I think if we just focus on veral uh it

would uh it would take at least a year for an next hard for and even more uh so my proposition would be to potentially focus on some smaller hard Fork while each team would uh commit to veral and assign appropriate uh resources appropriate uh Workforce brain power how however you want to call it to to this topic so we can have similar situations as with withdrawals and 4844 that we are working in the background on it and like working really really uh in a concrete deliberate way um yeah so that's that's in my opinion

uh minimizes risk of uh just stalling for over a year while having the greatest potential to move veral as quick as possible

Lightclient: thanks Lucas um yeah I I one of my concerns and I'm curious here about what how teams view this is that it's going to be difficult to have a small fork and keep a lot of band team bandwidth towards veral that's my guess uh as people are commenting I would like to hear your perspectives on that uh but I also just wanted to mention that this

isn't necessarily something we're going to decide today uh we're really just starting the discussion so don't feel like we're going to make the decision now all K you had your hand up

Guillaume Ballet: uh yeah so trying to unpack stuff that has been said so yes uh updates there are updates being provided uh there's veral info if you want to know a bit about the current state and also Josh is Josh Rudolph is making uh regular updates on Twitter uh so if you want uh something to to help you decide there's U there's a yeah there are some resources and also we agreed with Tim that we would make uh another like the

third I think by now uh presentation about the current state of recal but that will be um there will be either end of January or start of February I don't remember um so there's that uh but when it comes to to the question proper uh yeah I also think there's no such thing as as a small Fork I mean if we could for example uh commit to only do the BLS precompile for example I think that'd be fine because this has already been considered for a fork in the past so it should be ready enough um but otherwise uh I mean yeah otherwise don't fool

yourself that will not be a a small Fork um and we still have the problem that all that data needs to be translated so the more we the more we wait the worse it gets uh so I would uh I would caution against uh scheduling uh a olive for in between there's there needs to be a lot of attention and that also addresses what wuk has said uh yes there's a lot of clients have to have to redesign their database I mean gu is still working on some on some back in things that will affect the way veral is implemented so it it is a pretty heavy Fork it needs it needs a lot of attention from client

teams this being said I think every client team except maybe re and even them I think are looking into it uh so everybody's looking into it everybody's uh working on it so um I am I wouldn't expect any surprises um in in in this respect I think everybody knows what's coming everybody realizes that this is the the thing they need to work on um so I don't really uh I don't really have any worries about about the the timeline proper assuming everybody takes the takes the fork seriously and uh and starts investing more resources in it

makes sense thanks toas

Tomasz Stańczak: that being ambitious at this state is stage is better and being cautious later might be fine which means take a big lead verle for for the next Fork but also be ambitious more and include things that are very important for staking will be important for the network there are things like uh s02 uh 37251 uh just will be very much welcome uh and support all our efforts for uh handling reaking liquid staking and any regulatory issues around uh operators validators also I would say pick one

model for the account abstraction support uh so go for all of this and take advantage of the team's capacity in the year where we have to show that we handle our uh biggest challenges if veral end up showing to the teams that there's more and more difficulties piling up by March then maybe will just ask this question once again and say okay veral drops but then we stay with a pretty good set of other eips that we include

Lightclient: yeah I mean I guess one concern of having the ability to constantly open

this debate you know you can never permanently close it but if this is really an 18 to 24mth project that we're committing ourselves because this is something that we believe is important to do for the network if we're just have that in the back of our mind you know we could just take a break and spend 6 12 months shipping another Fork I think I think Mo it'll be difficult to motivate client teams to motivate people to stay focused on this for the longer Hall so I would be worried about opening these debates these debates back up but I think coming to a coming to a conclusive decision is going to be challenging

onar

Ansgar Dietrichs: yeah I just wanted to say I in my

mind basically given that verle is an e outside only change um it makes a lot of sense to at least kind of basically when we think about the next set of Cl um changes um that we don't commit to um combining both of them and basically have that be the next book and I think in the chat also a lot of people have the same sentiment so that we basically at least have we we plan them as independent forks and if ver goes really quick then we just combine them and ship them at the same time but if verco like six months from now ver is still nowhere near ready then we could just start to roll out the kind of the next seal side um for and then as part of that I personally but I'm not sure if that is majority kind of consensus I personally

would very strongly also want us to not pre-commit to verle being definitely the next thing on the Y side um if we basically think of it like a separate c and a separate e for then I think we should at least be open that say in six months if ver still looks very far out that we say okay hey we um we the the the set of Cl features we actually add a few small El side features and make it a proper hard for but I think basically thinking of them as like a separate El and cl um workflow for the next for I think that's very productive

Lightclient: yeah that's that's a I think that's pretty fair I do think that we need to have confidence at least today and or not as just day but we need to make a

decision and move towards that and if in 6 months we have to revisit it we have to revisit it but I don't think that we should sit in some halfway halfway out points and say you know this is kind of what we're working on but maybe we'll do something different like to ship a veral we're going to have to have a lot of uh a lot of focus and attention from client teams which isn't going to come unless we say this is what we're doing Andrew

Andrew Ashikhmin: um yeah um I'd like to say that I totally support vco and I think for Aragon it's the easiest because we've already transitioned to the flat uh data model uh but I kind of think because some other clients might like um what

what Lookers said that some other clients might need time to Red redesign the data models and I'm thinking that a smaller more isolated Fork before vco makes sense tactically because if you consider things like like eof or the BLS precompile it might be a kind of a complicated change say EF but it is an isolated change so you need maybe one or two people looking deeply into it but it doesn't touch like the entire code base right so you you can say only have a couple people implementing say eof provided that the spec is ready so yeah

to my to my mind EF or BLS precompile makes sense as a tactical walk

Lightclient: uh so just to confirm you your perspective is it's better to ship the smaller fork and kind of in parallel also have the isolated the people working on veral continue and ramp up on

veral

Andrew Ashikhmin: uh right yeah yeah yeah so absolutely we we should like veral should be our main focus and I mean if we decide that that vle will be in in in in the next Fork I I'm fine with it like for Aragon it's doesn't is relatively easy but I'm just

saying if we decide that vle will will happens slightly later then maybe we can like CL client teams can can allocate one or two people to work on more isolated things but V yeah V should be the main focus

got it guom you're back up

Guillaume Ballet: uh yeah I I mostly agree with what Andrew and others before him said U I'm perfectly fine with the uh yeah giving priority to veral and if it turns out it takes longer than than expected we we come up with a with a temporary well not

temporary but a a a smaller fork in between that that's uh that's totally fine uh one thing I wanted to add because I think there might be a misunderstanding Vero is uh is on the scale of the merge if not uh if not worse in terms of complexity so um so yeah you cannot really ship anything at the same time on the El side but I had the discussion with Tim in Istanbul and we were talking about pushing Das at the same time so uh when I say at the same time uh it's actually in the same release but not necessarily activated at the same time so it's not like we're holding everything back for vertical we only holding uh e um back for like all

other e changes back for for veral um so that's the first first point when it comes to e that's uh yeah I mean I've supported do I mean I still support it I think it does change a lot more than than Andrew seems to seems to think all over the code base and uh it does uh increase the complexity of veral itself unless we could somehow convert every single contract out there to e then it actually makes things simpler uh but I would not I would not consider eof you know small enough to to uh to to make it into a fork that

goes before

before verle got it uh pus

Potuz: yeah I just wanted to reply to mariio and nard that made some points about like decoupling C forks from El forks and while this sounds like interesting in theory in practice uh it's it's kind of useless at least in this case from the list of changes that you see for the coming Fork there's only one minor change that is in the original list in the first list on this that is purely CL which is removing an attestation index uh a committee index

from from the ad station and all the other changes uh even those that look like they will be only CL like increasing the max CB they depend on other changes that are from the L so I think pure CL Forks are not going to happen happen at least I I don't Envision them happening not this year not the next year we don't have enough proposals that are purely CL so we all we we will always need changes from the El in whatever CL Fork uh we we propose having said so I do agree with Andrew that uh since this for an Anar mentioned this uh ver is purely El so if we are committing to Burl in 18 months we're

going to have CL teams that can work in parallel in whatever changes are majorly CL and there are some changes that are that require small components from the El it wouldn't be nice to since veral would just delay those El changes it wouldn't be nice to delay those Forks that would be mainly CL so I think we can ship smallish Forks on the El side that are mainly CL in the timeline that you're working on

on Bur

Lightclient: yeah that seems reasonable uh just very quickly do any El just disagree with that sentiment from podas or or does that seem

fair

Georgios Konstantopoulos: so what's the one liner

Lightclient: yeah I mean the Das is a good example it's you know the El is checking the The Blob G The Blob gas limit but adding that to a fork a bit more than one line but still

Rel is

Potuz: one like triggerable exits is something that is

main

Lightclient: that's not really a simple change for the execution layer though

onar

Ansgar Dietrichs: yeah I mean I just was B going to plus one list and say that I think basically clearly it doesn't make sense

to have the distinction of like literally SE side only and E side only changes like probably still have a client release on the other side as well but um that basically we use it as a shelling fence right so the problem is always with forks once we open them up at all then everyone wants to get in so if we have the shelling P of saying hey this is a CL for so you can only get in if your EIP is like 90% on the SE side and if you need like one constant change or one small thing here then at least we can talk about it you know but uh basically I think just having the shelling fence of a of a clear theme of a focus super super important

R oops um

Tomas

Tomasz Stańczak: I agree with the Insight that uh those changes related to staking uh the ones that have CL will be driven very much by the project management structure on the uh on the consensus calls while the execution layer clients may have the vericle as the main driver because on the testing side verle trees will be the ones that will cause the most of the headache to testers on the execution layer for the consensus layer testing everything that is like um execution layer triggerable exits it might be feeling slightly complex to implement on the execution layer but I don't think it will create the same level of

interdependencies between the ch changes uh that are in the execution layer uh you'll test them very much independently and then there'll be a bit more burden testing of consensus layer uh that's a different thing if you if you want to do both verod trees and stay account abstraction support but I think that you should still opt for both because if Rec Tre indeed ends up being a 18 months project I think the account obstruction will be something that will uh that will happily shap with within the next 6 to 12 months

Ric

hi guys uh so uh basically I can confirm what Andrew said that uh that from the Epsilon team the EF uh EF specification is ready and we've been discussing it a lot with the clients and uh and language teams so so basically I would support the eof to be introduced uh or start being introducing already as soon as possible uh of course workers are very important but um but not sure if we can say that that the specification of the workers are as ready as EF already is so uh so and I wouldn't say that the t is s such a big change uh especially uh for the ex for

the execution client and uh I I think it's uh it's a matter of just understanding what what really what really is happening there and it's not it's and it's very separated as also and you mentioned so I would support EF and of course in the meantime just finishing specification of the

verles

Guillaume Ballet: uh what specifications are not ready in veral exactly

uh not not I'm I'm not that

I'm just asking if we can say that that uh that specification of the verle trees are are are ready so this is just a question not sure if if it can be say about this uh it can be safe for verles

but for sure for E it is ready

Guillaume Ballet: I mean I would say they as ready as they are for eof IE everything uh every like when it will end uh into the the backlog or of every team out there uh it will be up for discussions again uh so uh can you say any of them are ready no but I I don't see the veral specification being less ready than

okay if you say so um as I said I just just a question here for you

let's let's

Lightclient: let's not get too Sidetrack down the Readiness uh Road um I would do want

to kind on bring bring it back to that original question sort of been keeping track of what client teams have been saying but I wanted to hear I don't know if I've specifically heard Basu or ejs uh do you guys have a preference on on what to move forward with with next again like we're not making this decision now it's just trying to collect this information so we can mull over it for the next couple weeks

Justin Florentine: yeah let me Weighing on Bas right now so we we're making progress on both fronts you know we're looking at what comes next the with the whole driver and passengers plan and I think we agree that e is definitely not a passenger however um we've got a lot of progress on eof um for quite some time actually

um so I mean I would be very comfortable personally with EOS being the driver for the next one as we work on veral because we are making a ton of progress on Burl as well and I don't see any of our teams remaining capacity being diminished by having to support eof during the you know 18 months that we're forecasting out required for verl um not a strong opinion um and you know a bit of a sunk cost fallacy at work I'll admit um but that really seems for us kind of the ideal way to go

yeah from from my side I focus on the

fle

Lightclient: okay got it um great so most teams seem to be

leaning towards veral right now uh W seems to be the the most uh feature leaning team and nethermind and Basu also leaning a little bit with features but you know pretty much everyone is okay with making veral the the next big priority I again like I don't think it's it's the call to make this decision like I think we're going to spit another couple calls debating it but I I did want to give some time to people who wanted to talk about their proposals for Prague if not veral because I know some people have joined the call to discuss that and just to add color to the whole discussion of like what are we missing

out if we choose to go veral for the next 18 months uh but before we move over that is there any last comments or questions uh with respect to uh veral as the main priority in the next work

Łukasz Rozmej: like I said I in my opinion it's a very risky move to just focus on verle but that's my understanding

uh I oh sorry Sor one second I uh georgius

Lightclient: did I say that reth was signaling support I thought I said that

you guys were leaning towards a feature Fork

Georgios Konstantopoulos: oh my maybe maybe I miss but wanted to clarify for avoidance of confusion

yeah okay thanks uh yeah sorry yeah

Guillaume Ballet: uh sorry for jumping out of uh out of order um no I just wanted to understand why wuk was saying it's risky like long I can understand but why why do you mean what do you mean by risky

Łukasz Rozmej: okay so in order to have just touching the state uh takes tremendous amount of work and testing every time uh I've seen that

happening and while verer is already like progressing I still think that um maybe for example go implementation is closer to being production ready uh but for example never mind implementation while quite quite future reach at the moment it's very unoptimized and uh also for example depends on the transition for us depends on delivering uh flat layout properly which we haven't delivered yet so there are multiple risk there for never mind okay thanks and optimization for example uh for the

maths uh we have uh some problem there for example if we use uh the existing libraries which are for fast and optimized um we have a problem of interoperability the cost that um because uh actually accumulates quite a lot and if we try to implement it in C native C we were having issues with getting good performance so um there's a question what to do unanswered question and what to do with that I'm not sure if bezu for example doesn't have similar problem would be great to hear about

it

Gary Schulte: yeah yeah K is leading and only dust are working uh pretty heavily on the veral implementation but we're we're outside of the jvm for veral we're uh using jni and the rust libraries for that

Łukasz Rozmej: okay so Hall three will be outside of jvm

Gary Schulte: no just like the IPA multipoint uh and and any of the uh uh you know cryptographic uh implementations are in jni

okay

Łukasz Rozmej: okay and you don't have any problems for performance with that

Gary Schulte: um we yet to fully join the test net right now uh so we'll have better

numbers on it as uh as we get join the the test net but I I don't think we've noticed uh you like showstopping performance issues yet

Łukasz Rozmej: okay testnet is quite small so not at least I think it is I'm not sure if it will scale to main net levels without proper main net testing like importing the whole main net into verle it's uh really hard to say if the performance is there in my opinion

Gary Schulte: yeah that's fair has have we have other clients has has gu tried to import uh main net into the

vertical implementation and go

Guillaume Ballet: uh yes sorry if the question was gu yes we we tried and uh I'm currently working on the shadow Fork to make it uh more reproducible more more frequently um so yeah the performance of go is uh is is uh fine um but yeah other other clients will need to will discover that when they try to do the same thing yeah

Łukasz Rozmej: so my point is there is still a lot of unknowns uh so if we commit to something we might just not deliver it for a long

time here and uh I would still commit to it but probably uh like with 4844 we committed to smaller Fork first and doing this in the background for some time so that's still my recommendation

Lightclient: okay you're so you're still recommending feature fork with high prioritization of verle in parallel

yes

Łukasz Rozmej: yes that's my recommendation because uh vericle will take a long time either way so if we don't prioritize vericle we won't deliver it in the next for for example but if we do and we takes a long time we don't deliver anything for that time which is also

B yeah gam

Guillaume Ballet: uh yeah just to give a tiny bit of push back I I totally understand the the position of ukash is is reasonable this being said uh you know a lot of the development that has been done in G um is being readapted to other clients so for example bisu has been catching up really fast ejs has been catching up really fast uh Nimbus I'm not so sure but it seems to me that they are catching up fast so it's not going to be as um as slow as it has been for guest because a lot of the questions have been solved uh by uh by us so um yeah I mean it it will take time for sure I'm still

not uh convinced it will take 18 months but otherwise yeah I mean w cash is right if if it does take a lot of uh a lot of time uh there should be there should be members of of each team working on the on the Fe feature Fork

Lightclient: I think we can probably uh close the discussion on veral for this call we have so many more calls and time to discuss it and I think it will come up again in the next call in the next couple weeks if you guys

guys could spend a little bit of time discussing internally um okay Jamie did you have something you want to say great uh yeah if you guys could spend some time discussing internally uh what your team stance on verl is I think that's going to be useful for the next couple calls

Otis

Potuz: yeah not related to Perle but something that came up last for uh was that when The ethereum Magicians uh post went up uh BLS pre compile was something that everyone said I want this in this Fork I want this in this fork and then it never happened and when we asked on

ACD Channel why this didn't happen the reply was essentially well just inertia and I feel if you go and read that because it's not always the same set of crowd that write on the magician for Forum than would come here and voice their opinion on these meetings if you go and read this chat now on the E Maan forums you're going to see that 7,002 is the most voted one and where people in the community are asking for it so I wouldn't want to have the same situation as with the BLS pre comp in the next Fork because of the same reason

Lightclient: understood I mean that's a good segue we've got some time

left I think we should give people the platform to discuss the proposals for Prague if those people happen to be here uh and yeah hopefully try to convey like how much demand there is for these things from the community so I think maybe the best way to do it is just to go down the list of proposals in the youth magicians thread and if there's a person on the call who feels that they can spend 30 seconds to two minutes um summarizing and um trying to create some momentum behind it that that could be

useful so the first one is 2537 does is anyone on the call here who wants to try to motivate a 2537 um e in the next feature Fork

Alex Stokes: yeah I can um I think this is pretty well accepted I think everyone here so it's adding BLS arithmetic um this is a curve we use on the consisted player so it unlocks a lot of staking use cases inside the evm making staking poles more trustless uh it also helps a lot with Z knowledge cryptography so if any of these snark applications want to use this curve in evm it unlocks them

and then also that directly extends to uh ZK RPS as well so yeah this one should definitely go in my opinion and would unlock many many many use cases

Lightclient: in the interest of time I think we can just go to the next ones unless someone has a very critical or strong feeling against the proposal that might be useful for authors or people interested in the EIP going in to spend some time addressing that feedback so any strong feelings against

one quick

Marius van der Wijden: one quick thing um I think this proposes eight new pre- compiles or six

new pre- compiles um and most of them are not really useful for for staking related stuff I think only the um the verification basically the verification is useful for that um but most of the others are useful for L2 stuff as far as I understood it but it would be really nice if we could get a document outling the need for every one of those why why should we not just add one but should we why should we add like all of this five or eight or whatever

PR

Lightclient: sure um next on the list is

e anyone on the call want to make the case for

EF I

Justin Florentine: I'd like to just reiterate From bassy's perspective that you know we're looking at this that it's it's very close to done we're eager to ship it and a lot of Works been spent on it but I don't have any additional Community perspective on the interest or need for it that I could bring

thanks ancar

Ansgar Dietrichs: yeah I just wanted to briefly uh say I don't myself a super strong opinion but I did talk in Istanbul for example with some um members of the of

the solidity team and they were expressing pretty strong um opinions in favor of um UF I'm not sure if that was represented of the entire team but I think there's a little bit of risk that UF might be another one of these features say if we think back to 3074 from two years ago where I think a lot of the Community was really excited about it but because that excitement didn't quite get to ACD and never moved forward um and I think EF might be in a somewhat similar spot where there's a lot of more application side um teams and people that actually or like say in this case on the language on the program language side that would actually really like it and that that those are just the kind of people that don't usually come to ACD so maybe there there could be

some value in Outreach um to try and get them on the call

Lightclient: yeah that's fair I also talked with with the solidity team in thisle and can Echo that sentiment does anyone have any very strong negative reaction to eof or feel like eof is not something that we should

be putting into a fork okay so next up is 7,02 the alleged number one voted EIP for the next hard Fork does anybody want to motivate a case for shipping

7,002 toas

Tomasz Stańczak: yeah we felt we felt 70002 we cannot really claim fully non-custodial staking in ethereum which means that any professional node operators have to use a bit of a trig uh to support withdrawals uh which means that you always have the the risk and griefing of the uh Capital provider who is taking not being able to uh to draw without collaboration with the node operator so the solution nowadays is maybe it's not really bad in a sense that the present transactions are are

offered uh but 7,02 is is the way to go and not only this it also opens a lot of um lot of potential very important features related to uh safer reaking uh like more Alliance uh like I mean like better represented actual uh Security on the network versus security borrowed and a few other things super important

Lightclient: yeah that's a nice summary of it um any strong pieces of feedback or negative thoughts on 7002 okay next on the list is veral but I

think we've already discussed veral quite a bit so let's just go to the next one um this is a CL only one 7549 move committee index outside attestation uh yeah pus do you want to motivate it

that

Potuz: that should definitely be in it's it's a very very simple change we can do it on the CL side it's it's trivial to implement and it'll save a lot of aggregation time uh it can help on like trustless Bridges or Z proven the z z Bridges uh it's it's something that it should definitely be in whatever Fork we do next

Lightclient: and is this a CL only change or is it

Potuz: it's only a CL thing

it's just a bug in the design we include a number uh in an attestation that pre since it's signed it prevents to aggregate different attestations with different of these numbers which is the committee index of the attester this removes this committee index outside of the attestation so that you can actually aggregate different committees uh signatures

Lightclient: got it um yeah we'll we'll leave that one to be more deeply discussed on the CL call so next is EIP 3074 is anyone on the call who wants to motivate a case for 3074 and a fork

Ahmad Bitar: um I can talk about it um so basically 3074 uh introduces two op codes um one will authorize the smart contract to act on the behalf of the uh externally owned account the second will uh uh call uh other contracts from this uh invoker contract and when it it will be like a delegate call but for the eoa that authorized the the invoker smart contract to do his bidding um the idea behind this uh EIP is to improve the user

experience so for example patching transaction would be become uh way easier to do even for EAS uh it will also pave the way for uh EIP 5000 and3 which will basically allow us to uh convert eoa accounts into uh smart contract enabling more account abstraction adoption um and also uh it will remove some of the bad design decisions like an erc20 uh the for example approve and

then uh uh the action um so yeah that that's basically uh my summary over it

Lightclient: thanks ammed Tomas you have your hand up

Tomasz Stańczak: yeah I feel that uh some ins Shin support for the accountant construction or uh like more smart accounts whether it's 3074 or something much simpler like 75 F3 or anything else really that's proposed one of those would be good to have as a Target to deliver and at the same time maybe one thing that we didn't discuss but but

Solutions like these plle trees are still very much bounc to ethereum L1 being seen mostly as a uh High transaction through it uh user oriented layer and not the uh on the scaling versus Alt so the question is whether uh what if all those changes we want to show that we jumping on one what should be the change direction all to um but still I think that's having all the implementations of the clients for those changes and the direction and research will be extremely important even at some point

only be bubbled up to to thanks toas

Andrew uh yeah I think uh there was an objection from our team against 3074 because it opens security kind of worms uh it kind of the there is a change in security assumptions and user assigns something that is lasting forever and can do arbitary things that the user like is not aware he's signing for so permissions are not revocable things like that uh I can look de deeper into it but and I haven't looked into the EIP for a while but I think there are big big security questions for IT against it thanks Andrew

onar

Ansgar Dietrichs: yeah so um of course was one of the the yep I mean I do I I'm happy that it has a second kind of win behind it now but I do I have some consense at least that we want to voice spe specifically kind of in the context of layer one um I think with kind of now Layer Two is being much more mature it seems if if there is demand for something like this it would be a much better Canada to try out in the l two context first uh via the I process um specifically I mean 3074 was always more designed as a stop Gap in between kind of EAS that we have today and like the glory is actual C obstruct in future with with smart contact wallets that that we'll hopefully get to in the future and I think we are much closer to that future

now so it's there's less reason for that and I would caution that I think a lot of people that are now supporting the EIP are somewhat unaware of the complexities that it brings with it so specifically the IP requires this kind of concept of invokers and all the functionality would have to be standardized by invoker so there have to be like one standard invoker for bundling one standard invoker for I don't know like um uh time inv validated transactions all these kind of things um and that will take a lot long time to actually get these standards right and while in principle they could be comp forward compatible with things like smart contct wallets and everything that would require like a very strong big

change to the way SMS work so basically instead of having their own bundle functionality they would have to go through the invoker for bundling and everything so I think basically before we were to even consider this for minute we should basically get all the takes we should we should basically have commitments from Smart contact wall implementers that they would actually also want to use this invoker design we would have to actually see invoker implementations already proposed as erc's we would have to see um tooling support for like say EAS jar and these people specifically for some of these invokers I think otherwise it's just basically really naive because we would ship this feature and then not have anything that could actually use it for the next two years afterwards

Lightclient: thanks hcar uh let's go ahead and move

on to the next because we're only halfway through uh so the next proposed one is 3068 precompile for BN 256 hash to curve algorithms is anyone here who wants to support that go once twice all right on to the next one EIP 6110 Supply validator deposits on chain anyone want to motivate the case for that

EAP

Justin Florentine: hey this is Justin B to um I like

the a up a little bit of P that again we have an implementation

Lightclient: thanks Justin yeah it is mostly a CLE Mars did you want to say something

Marius van der Wijden: yes I can I can kind of motivate it um right now uh basically um CLS need to listen to El receipts for finding out who deposited and this means we need to keep all of the uh receipts um for these events for the deposit contract um what this would enable us to do would be to um also

like uh lessen or lower the requirements for keeping historical receipts so stuff like 4444 is kind of dependent on this um because uh otherwise we cannot really um uh with good conscience remove the receipts from post mer from yeah from post merge uh ethereum only um we we can only remove the receipts from um from Genesis up to um the the start of the beacon chain otherwise we would least uh lose those deposit U uh those deposit events so yeah I'm

I'm in favor of this

thanks Marius um po is I think D

Potuz: line has his hand up and he's most probably going to say the same as me

okay dine

dapplion: yeah one of the biggest points is that we will get rid of very bad security assumptions that we had because this this is basically a bridge um now an honest online note would not be convinced to process fake deposits even if there is an aders majority and that's kind of the one of the last about things that we have Prem merge

yre H

this

Potuz: yeah just a quick comment is that uh the fork itself so the change is not so bad but the fork itself is a problem with the CIP so uh we it would depend a lot on what kind of fork we're looking at if we're doing this on the on the verge uh I wouldn't add this e at the same Fork

Lightclient: got it uh next EAP on the list is 6913 set code instruction is anyone here who wants to make a case for that EIP

Marius van der Wijden: um I can make a case against it I

don't think it's a it's feasible um having like changing this the code of a of a smart contract is not great um we have one way to do it with create two and self-destruct uh this is not anymore um H but yeah so this has a lot of implications that would need to be tested for example setting code within a contract that just got set code code so doing set code in a loop or doing set code with cursively um it doesn't play well with

um basically anything it doesn't play well with verle it doesn't play well with yeah a lot of other proposals so I don't think it's a good

Lightclient: thanks Marius uh we are running a little low on time so if we can keep the comments pretty uh pretty short

Tomas

Tomasz Stańczak: I second this against set code

Lightclient: thanks next up is increase code size limit to 2 to the two uh sorry 2 to the 16 anyone want to make a quick argument for or against

thas

Tomasz Stańczak: we understand properly it shouldn't be done without verle done first

Lightclient: that's currently my understanding all right next up uh this is C only one we're going to skip it

next up after that is 7377 migration transaction is there anyone here who wants to make a case for that EIP

Gary Schulte: sure okay since I put that on the thread um I think that uh 7377 is a a pretty elegant way to to migrate eoas uh

on the road map for uh account abstraction um it's uh seems easy to reason about doesn't have a lot of uh of baggage it doesn't seem to have the same kind of security risks that o and O code have um it seems to me like it's a it's a a light touch uh fix for getting towards account abstraction

Lightclient: thanks for that Gary um sorry I'm just starting to go a little bit faster so we could get through there's just about three or four more and we wanted to give some time for onar to mention something about the rips

so next after that is uh EIP 44 is bound historical data this is something that's

been brought up again and again I just want to see if anybody wants to make a quick motivating case for making that a priority soon all right there's some people in the chat saying it's useful but we can discuss it more offline uh we've got a canful of things happening from the CL GitHub issue that are pretty related to execution layer is anyone wanting to make a case for ssz ification of the transactions

receipts I think SS ification

Marius van der Wijden: will add a lot of computational overhead because you need to do a lot of hashes um for transactions right now you only need to do one to get the transaction hash uh with SSC you need I don't know like a lot and um so every transaction processing will will get a lot worse so I I don't think it's very realistic right now

Lightclient: got it okay that's from the list we've completed it um dragon all right that's the list there's

a couple other ones two more that I wanted to bring up

uh does anyone sorry sorry can you hear me now I was muted yeah I can hear you yeah just yeah

Dragan Rakita: um I just wanted to give a little bit more support for UF in general it's not just one a is group of aips from like static jumps to limited faps to a lot of like small things that improve VF in good way so yeah I just want to say few words on that

nothingmore

Lightclient: thanks for that does anyone want to make a motivating case for 7212 the R1 precompile on

mayet

Gary Schulte: um I haven't looked super closely

into this but it seems like that's going to enable a lot of U account abstraction use cases secure on claves mobile devices things like that it seems like for for user experience that's something that we we want to get out there it's a as as a pre-compile goes I I don't want to keep harping on OB Bas who has an implementation for this but uh we have an R1 implementation already uh so it would be not terribly difficult to get that out there

Lightclient: yep and then last uh sorry go ahead Ben

uh could

Ben Adams: I just mentioned something on the code size limit uh one of the issues with that is um I mean it's quite at 24K I don't know if I'd go all the way up to 64k but you know maybe 32 but it

does lead to developers making very strange contracts in order to get around it you got the diamond proxy and all sorts of various hoops and you people end up deploying multiple contracts when you know they've just gone over that limit and and it becomes a lot more complex with delegate calls Etc so it's is quite a ux problem

Lightclient: thanks Ben uh last one that I wanted to give someone a chance to mention was the EIP 7553 draft separated payer transaction toos I think you wanted to discuss that

one

Tomasz Stańczak: yeah so this is the EIP that goes like the the simplest possible route to to allow to separate the signature that is responsible for covering the Gas payment and the signature that is authorizing execution on behalf of the account uh this is alternative to any of the other proposals related to the account abstraction like or smart wallet like accounts uh which means that if we go with something like 3074 and 7553 doesn't really make that much more sense uh but 7553 was proposed by me because uh in Asar because

the there's really much much simpler change it does still require wallet modifications perhaps if you see this back uh it doesn't try to be very generic it doesn't try to solve many problems it solve something that is very often mentioned as 80 or 90% of the reason for introducing any account abstraction is just to allow for payment for gas uh from another account by some kind of pay Master uh so 755 we just pass this nothing more and uh when you think about later it just opens also a very nice route for replacing uh the actual signature that is being used for

the authorization so you can leave the uh the standard signatures we used to for for gas payments making sure that our transaction pool is still safe safe then we don't have to risk invalidating the transaction pool uh but we can change later the signatures responsible for uh for the authorization for execution which means that we can start creating some kind of account abstraction by a smart contracts if that signature is dependent on the contract execution because you already have promis to pay for that and inv validated for that uh in transaction to so that's 7553

Lightclient: thanks toas um we're at time

Charles do you have a quick comment on

EAP

Charles Cooper: uh I actually wanted to um advocate for the payop code um EIP what is this 15920 um which was briefly considered for Cancun um and wasn't rejected it was uh postponed for um I guess uh uh it's an evm change and I guess evm changes that touch State can be a little complicated to implement so I want to re bring it up for uh inclusion in Prague

Lightclient: all right guys we're at time uh

onar did want to mention this EIP 7587 reserving the addresses uh 0x10 through 0x1 FF address range for RI pre- compiles onc do you you want to take a second to discuss that

Ansgar Dietrichs: yeah I think K's also on the call he would be better to talk about it

Lightclient: oh sorry go ahead Carl

yeah

Carl Beekhuizen: yeah sure um 7587 as discussed on the uh last ACD call the idea is to uh reserve a set of pre-compile addresses for the rip process so we can start deploying pre- compiles um like the R1 curve as you're discussing earlier here um but in a way

that we can ensure no conflicts between l1s and l2s um the EIP is exactly as we discussed uh last time which is basically just reserving the second 256 uh addresses for the rip process the question I have is about um assuming everyone's okay with this how do we go ahead about formalizing this um it's an informational EIP but like can something like this be included in Forks or um yeah how basically how do we turn it from this is something we're discussing and is nice into something that is uh we agree to abide by it or not moving

forward I don't if anyone has any strong ideas on that

Lightclient: it doesn't necessarily seem like something that needs to be quote unquote scheduled it seems like we can just reserve it uh we can talk I'll find like where to where to have that list but maybe something like the execution specs after the EAP is accepted uh but does anyone against reserving that address range for RPS or have a comment on it okay let's say this is the uh

introduction of that Eep and then we'll Circle back to it in two weeks and try to confirm that and go ahead move forward with it if you guys have any questions or comments about that in the meantime just go ahead and post on that eth magicians form for the precompile reservation EP and I think we can go ahead and close it out thanks so much for everybody being on their best behavior for The Substitute Teacher Tim will be back again in two weeks for Al cordos 179 and we'll again talk about verl and all of our Eeps that we would like to see in the next Fork happy New Year talk to you all

later

happy new year new year thank you bye h

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