Ethereum Foundation Core Devs, 1 Apr 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Ethereum Core Devs Meeting #135 [2022-4-1]

Description

https://github.com/ethereum/pm/issues/500

A

B

Okay, good morning, everyone welcome to all core devs uh 135.

B

I posted uh the agenda in the chat already. I think everything is working on the live stream. um So a couple things today, a bunch of updates on the merge, so uh some updates, mostly on the shadow forking.

B

I don't think, there's much on killed itself and then mikael had some stuff about the latest flatted hash conversations we've been having uh then on shanghai, a couple things as well so alex had some updates uh on the withdrawal eip based on the the the call last time, and then there were two other vips: uh the s, transient storage and the removal of self-destruct that were that were brought up in the comments and and then, after all, that uh we have afri here to talk about um some of the issues we've seen on gordy and some potential solutions to them.

B

um I guess to kick us off uh perry. Do you want to maybe give like a high level recap of what happened with shadow 14, where we're at right? Now I saw you you kind of posted another discord this morning as well, but just yeah kind of bring everybody.

C

Up to speed, of course, um so the last since the last acd, our testing efforts have been even focused on shadow.

C

um So what we mean by shadow forking is we take the config of a test net in this case gertie, and then we just modify it to add a ttd and merge four block, so that means up until the ttd we'd be following the canonical quality chain and post ttd.

C

All the notes configured with the modified genesis, json file would fork off into their shadow form. Basically, um but since we've set the merge fork block to be far in the future, we continue importing transactions. So the main idea is that we're able to test um syncing we're able to test actual load block production under load and so on.

C

um We had two attempts so far. The first attempt followed a mainnet distribution, and we found issues in. I think every client especially related to expectations of how quickly timeouts should happen or or how block production logic has to work and so on. um So we had a second uh shadow that happened day before yesterday, and that was a lot more stable. We didn't do mainnet distribution for that one. We did a more equal client distribution.

C

um I think we've only found like one or two minor issues um and they have patches being released so we're attempting a third version again with mainnet distribution. Ttd is supposed to hit on monday and information about the conflict has been shared on the testing channel in the rnd discord and irrespective of how this one goes, we want to already try a a mainnet shadow fork sometime next week and the main idea is just to collect as much information as possible right now, so that we can make an informed decision about about the merge sooner.

D

So one thing one thing where we, where we want to push for the main headshot so uh so quickly, is to collect data on how the clients behave on mainnet, because um we've seen on the goalie shadow fork that, like thinking becomes an issue um like bigger blocks, become an issue.

E

Stuff like this, and so it would be.

D

Really nice to see how clients work post merge on mainnet, so one thing, for example, was that we like we provisioned for the yeah. Sorry, I'm uh I'm uh not at a great place, so one one thing we had uh for the first uh shadow fork is that we provisioned um eight gigabyte nodes and uh because of uh finalization non-finalization.

D

These uh ran over and uh geth, ran out of memory and was killed and and then was killed repeatedly and uh stuff like this is, I think, really important to see on on mainnet state and on main transactions.

C

Yep and we don't really have an expectation on client teams to spin up their own nodes to test in I'm spinning notes on your behalf. um More or less every client team knows whose ssh keys are on which machine it would be great if you guys can have an eye on your nodes um test. Weird sync states start syncing switch els midway through sync, weird things that people might do there.

E

Could people provide a bit of details behind those timeout issues.

D

um Yeah so that them like there are multiple issues there. One was.

D

Apparently, no client has a has a pause between creating a new payload and retrieving the payload, so just updated with it with payload attributes and then get payload.

D

um So all and because gas right now builds blocks uh synchronously in in focus updated, that's not an issue, um but for nethermind, which builds blocks asynchronously every block is empty because they only have 100 milliseconds to to build a block, and there was one issue. The other one was that clients didn't give us enough time to execute the blocks.

D

um So I think some clients did have had a time out of 500 milliseconds for um for new for new payload, a new payload can like we can. We can and we do execute blocks during new payload and so yeah. We we we timed out and, uh and so so some clients weren't able to think or able to follow the chain.

E

uh What was it http or websocket, which communication protocol has been used.

D

I think I I think http, I'm not sure like right now, only nimbus uses a websocket as far as I know, or maybe they also use http.

C

No they're also using web sockets right now.

D

C

And they're the only ones using websocket, everyone else is http.

D

Yes and I'm not sure if we had the same issues for nimbus but uh for the other clients it was.

E

Yeah, I would expect like if it's http, I would expect, like timeouts, set to something some like to speak big number to one minute or whatever, even more than the uh slots uh seconds even more than the seconds per slot friendly. So I.

F

Was gonna ask um would there should we provide some sort of recommendations for timeout um duration? I guess just for a different method. There may be different hammer recommendations and I think it's fairly important that all client kind of uses the same timeout. So we don't see some sort of network asymmetry down the line.

G

Yeah I mean timeouts are fundamentally dangerous, because if there's a timeout I can construct a dos block that can sit right on the border of that timeout. Depending on the machine, then I can split the network, so uh you know on the order of something far beyond dos blocks uh should be the timeout. If there has to be a timeout but yeah, maybe there should be explicit recognition.

A

Do we discuss timeout for uh fortress, updated or for new payload to uh because for purchase updates that we should to have relatively uh small timeout? I think.

G

Why? Because both of them have execution semantics baked in so both of them can have the same uh um right.

H

Right sorry, yeah.

D

All right and then in focus updated. You might have to run re-orgs so.

E

Yeah, I was just going to say the same, so it could be like a rework that is processed synchronously like for, if it's like two or three blocks and poke choice, updated like what marius said, so it should be more. The timeout should be should be enough to process like a few blocks, so I would expect I would even expect that websocket is used. I don't think that websocket is. Has some timeouts like uh like inside of a session.

G

Also your case, though, it might actually be better to have the execution layer signal that it is still working via maybe a call to syncing um a return to syncing rather than hitting the timeout, because then the consensus layer has no idea. What's going on.

E

And I think that since the communication channel was like a trustworthy relationship between cl and dl, I would expect that the match should be relatively high. So it's not like uh el is just kind of fine. It could be really in case of like attacks where every block uh is huge and it takes let's say 20 seconds to execute. I don't know it's just a random number.

E

It would be useful to have enough time to process such big blocks, so the chain will be able to make progress in any case. Otherwise, if if, if each of this block will be timed out, we could have a blindness failure.

F

I think, like um so coming from consensus perspective from prism. What I can say is that most of the issues or most of the edge cases we're seeing now is always regarding time out.

F

I think this is a very tricky area to tactical just before we're shaking time out like the pillow is invalid, but that's not true, because the pedal is not invalided, but it just means that we have to try again later so we discovered a few edges there and it may be important to to basically, like I said, uh define some time of uh values uh across all the methods so make sure everyone's on the same page,.

D

Yeah, um I think yeah we should we should uh defend us uh async and not not to them. Now. One thing, one thing that I like, maybe I didn't hammer this point home home hard enough because perry wrote it just wrote me about it. uh Basically, the the time that the consent, all the consensus layer, clients currently wait between they between when they ask us to construct a payload and when they fetch the payload from us, is too short.

D

And so if we were to switch payload construction to async, which is something that we want to do in geth, every block would be empty and so.

G

That right so essentially they're supposed to be making this call something like four seconds or more before, because they know that they're going to be a proposer and instead they're.

I

Making it like.

D

G

In rapid succession, yes, so.

D

So they they send us the payload attributes. uh We we create, like we start creating the payload, and then they already send us uh the get payload, and this is like 100 milliseconds uh apart and in these 100 milliseconds. We cannot create any blocks and I think this is going to be it's an issue. Yeah.

G

I mean the intention.

D

G

Is certainly to have on the order of like a third of a slot, if not more of lead time and that's just that's.

G

Consistency should be doing that if they're trying to have anything profitable coming out of it, um yes, but we can make a clearer recommendation, I mean it should be as soon as you have as soon as you know, the four choices of the prior slot and you know, you're the you're, the composer of the next slide.

A

But I think I noticed it uh some time ago and I reported it and I think only tackle uh doing it in correct way. uh Yeah.

G

Sorry that was in the correct way or incorrect.

A

Incorrect way tackle is correct, sorry got it got it.

F

Chris some had that uh fixed. We actually just began cashing the pillow id the slop higher. When the hedge changes. um I can um give you a new image to try yeah.

J

Danny you said, a third of a slot is the minimum. Why is that shouldn't? You always know about one slot or more in advance.

G

uh Yeah, you should, I mean the you just you get progressively more information during a slot about attestations, um so.

J

G

J

But you should know like if your slot is coming up like as soon as the previous slot shows up, I feel like you should be able to start building the block like you. Don't maybe that.

G

J

Building on the wrong thing, but you should be really.

G

Agreed so as soon as you see that block you should begin the process you might during that slot abort and provide.

J

A different head with.

G

A different one um so say, for example, at slot in there's the the proposer slot in actually makes two conflicting blocks and they're going to get slash, but there's actually two conflicting blocks out there, and maybe uh what I see is the head initially and I begin my build process on actually switches because of the weight of attestations throughout that slot. You know so, then there are these edge cases where you might switch, but you're right as soon as you get the information.

G

Even if it's low confidence, you should probably begin the build process, and only if you fork choice update you could change the build process. uh If you, if you in these edge cases,.

J

Are any of those edge cases non-slashable.

G

Yes, it's deep enough yeah if it was a deep enough fork, well, yeah a late block potentially or a deep enough fork where the shuffling is diverged, um then I might all of a sudden resolve that I want to switch forks halfway through.

E

C

E

Also, another comment related to timeouts or a question: uh is this possible to process multiple payloads at the time on the old side, just curious how it's currently implemented in the clients.

E

Yeah like, for example, one payload takes quite a lot of time to be executed, and then another new payload is coming. Will the first one be processed in parallel with the second one.

D

uh Yes, so that's um no! It like it won't because we we have vlogs.

K

Sorry were they both based on the same state.

E

Yeah, probably both on the same same state like they're, just sister blocks,.

K

And theoretically, we could uh do them in paradise. I don't know if we do marius probably knows not better. No.

D

Because we have, we have locks on the on the blockchain data structure, so we cannot like it depends on what you mean with uh with uh like uh execute them. So we cannot. We cannot like execute the transactions.

D

We can, for example, verify like verify the block, header and stuff like this, and this is all done in parallel, but we cannot insert them into the blockchain in parallel.

L

Similar in the mind, we run validations, etc. In parallel, that's fine but actual execution, not because we have a concept of canonical state which is being modified.

E

And this is how it works today on the main edge right.

L

E

Okay thanks, I suggest we continue this conversation and discord.

B

Yeah, I think that makes sense. um We can use the interrupt channel uh to do that.

B

Anything else on on timeouts.

B

Okay, uh next up uh mikhail you had. uh Basically, there was a conversation on discord this week around the latest valid hash. um I shared the discord link in the agenda and you put together kind of a summary explaining your thoughts about it. You want to maybe just take a minute or two and and share your thoughts, and um you can share your screen also, if you want, with with the document.

E

Let me share my screen.

E

Okay, do you see it.

E

ah Yes, okay cool, so yeah um we've been a bit touched, this late latest valid hash and apparently it's it has some complexity and supporting it. So I've just put down some notes on that some initial thoughts on how this could be implemented and when it's important uh so tldrs here we have two cases. uh Basically um that should be considered during implementing this requirement.

E

First one is important and, to my opinion, it's when the payload realization happens synchronously. So it's like when you submit the new payload and it's responded. It appears to be invalid. uh This is the easy case right. So here, latest valid hash is also the print hash and it might seem that this latest valid hash parameter is redundant in this case. But if we take a look at factories updated which has the same parameters in response.

E

We can conclude that this would be important in the case if there is the optimization of short-range rewards done by some clients, for example, aragon that has been discussed previously on discord that this optimization like when you really work, and the new fork is like only two or three blocks.

E

It could be the case when, like the first block is invalid in this fork and what you do is uh respond with invalid and in this case, latest valid hash will point to the first block in this work, and this is important because we need cl, need to invalidate uh all uh all the blocks uh that uh starting from this, uh like first invalid block, so that that's this is where it should be like implemented.

E

It should be straightforward, because uh el client has all the information uh and it re it just sends it back to cl.

E

um So the other part is when yell is sinking and it makes an invalid box somewhere in the middle of the chain. It's it has been syncing with, and the el is syncing with this chain because uh consistently a client said that this chain is canonical and fed all the required information to el to start syncing.

E

So in this case, implementation would be a bit trickier. There is there need to be a cache that will store the tip of the chain that the l nodes, that the l observes the tip of invalid chain and this type of invalid change should be accompanied with the latest valid hash printer.

E

um So that's the kind of cache required here uh and this this check is pretty simple. um So every new payload, if, if its parent hits this invalid tip hash, so it equals to invalid t hash. So the uh in this case, having this information uh ill client just may respond correctly to this to to this request, um yeah we we should not account, for.

E

I think that we should not account for the case when the some payload is missed, and the re and el can't just build the chain uh like to understand that this payload uh p1, for example, uh is linked to the invalid chain, because uh for some reason, cld didn't send the all required information to build this link and that's it. So I think that this these two two steps would be enough for implementing it uh in the asynchronous, without validation case um also yeah.

E

These are this is the option uh it's it's not that complicated, but uh it's anyway complexity and the the other question that is important. uh What what would happen if we do not support uh latest valid hash, uh or we know we do not support like uh sending this information to cl while el is thinking. So what may happen is just cl will not know uh that this chain, that it follows, uh is invalid and will still keep following it and pull from the network if it's available in any place of the network.

E

Probably in this case a node is under eclipse attack and this being fed with invalid chain. uh Ndl will just uh like assume that the l just see the invalid block and drops the entire chain and cl doesn't know about it anything and keeps sending uh new blocks from this invalid chain. They all started syncing again, and this going over and over.

E

So in this case, what will happen is just either cl will observe the valid chain and rework to it. Just because all other validators will have a switch to the valid chain and it can be seen from the attestation justifications and final finalization updates.

E

Either this happens or a user will see that node is not progressing and we'll have to do a manual intervention. um So, okay, so two out out comes from this. This lattice valid hash is really valuable thing for this first case, and this must be implemented.

E

uh This one is like optional. I would say uh to my observation so, but people may have other opinions on that.

D

So sorry I don't like, should we only cache one invalid tip hash, or should we cash all of the inventive cash questions.

E

I would say that you should uh have probably l review cash like for a few entries so and just catch them and drop the most latest, one that were was added to this cache. It's like uh yeah. This this case is only uh actually at at one point in time. There will be only one invalid chain that matters, because uh el only syncs with the canonical chain and if uh canonical chain is invalid, then it matters uh otherwise yeah. So there is only one chain: yale is synced with.

E

This is the assumption, and this was also discussed previously, so basically yeah. Probably there could be two chain. uh A reward happens that might make sense to store in this cache two three five but propanol should like be on on every chain that new payload is sent for.

E

Because yeah, because in this while sinking, uh what only matters is the canonical chain, uh while this is synchronous, payload validation, there is, the response is immediate and all the information is available to to make a response. According to the spec.

K

So um two things so uh I mean you know I wouldn't say that this will most likely happen during an ecliptic attack uh most likely. The el has some data, corruption in the database or in bad ram or something.

K

But I don't really get this first bullet point. So we're fed a new payload. We should return the parent hash. How do we know that the parent has the most recent valid? What if we don't have parent.

E

uh Because if it's yeah right, if it's in chronos uh yeah, yeah you're right yeah, fair question, because uh if you don't have a parent, you would respond with uh sinking right. So it's it falls to the second case, not to the first one synchronous, like validation, happens. Only when you have all the information available and the current block is known, and obviously it's valid in this case, like the assumption, is that this block is valid.

K

Okay, so so it won't cannot have so if we're that new payload block thousand- and we say no, this is invalid and then you say: okay, here's, the new block 1001..

K

Should we just okay I'll just have to go. Think then.

E

uh Yes, you will have to think if cly consists on on sending a a child of invalid payload. So it must be something bad with cl, because it it got rid of a response that the parent is involved.

K

So marius we will never restart the sync after we're synced right, we haven't changed that.

G

I think he means more, like reverse header sync like if you got a block, and you want to find not not like genesis. Sync.

D

If we don't have a the parent to some block, then we will start thinking.

G

So it's like, as in trying to fill in the gaps of the parents, to find its roots in the chain you know about. Yes,.

G

All right so martin in your example the if the consensus layer sends the next block in it forgot that you already said something was invalid. um So this does you know this could happen theoretically like if the consensus has a failure or the consensus layer turned off and then turned back on or something like that. But we do need to handle the case where it does try to insert something that is.

A

Only switch consensus.

H

Databases right.

J

Or just a simple race condition.

M

uh Not only invalid, uh so if the el returns sinking but then, while syncing it it discovers an invalid block, but uh because the engine api is, it has already replied syncing on the engine api, the consensus layer doesn't know yet that the block is invalid. It only got syncing for that block. Then it starts building on that new chain and sends new and new blocks to the eo.

M

So for every for arigon, it's currently a problem that mikhail has described. We don't have this cache. We have to implement it because you see the problem we reply to syncing and only after that we discovered that some blocks were invalid.

M

K

Yeah, I think we did something similar like we put them to some future queue complete american and, at some point, we're going to execute that future queue and might notice that one of them was that.

E

So I've heard that nethermine's stores, like a few, uh the most recent invalid block hashes, but this uh this neither the invalid t cash nor the latest valid hash.

E

It's like she's, the uh the invalid child of the latest, valid uh block. So.

L

Yes, for never mind, so we were thinking about it and our potential potential fix for that is to keep invalid blocks in our block tree and just mark them as invalid uh to have like the whole thing, and just when something is finalized, we can prune the invalids ones from the tree to like not keep garbage there.

E

Yeah, and so you can just query um the database right so when you insert the new payload into the block, you may check this right that the parent is valid. Oh and.

L

Yeah we could we could. We could go to like the whole ancestors right, train.

E

Right but uh yeah, this sounds like uh an attack vector I mean if someone.

E

If this chain is, you know uh pretty long and you you should always uh hit. You should make like multiple database reads to to just traverse this chain to find out the latest valid hash.

L

Yes, that's a potential problem.

E

A

Yeah but cache is not enough, because if we restart our node, it will be in let's state again, so we can't just store it in memory cache. I think.

G

You could recompute the cache essentially in that if you get some block deep into an invalid chain, you recursively walk back and then you'll see. Oh, this is invalid and then you can have the cash again yeah, but storing it is fine too, but it would be recomputed if the consensus player was continuing to pound information in that branch.

E

Yeah once again, I do not think that it's super important. It would be really nice to have this supported during sinking danny. What do you think on it.

G

I um I think it's very difficult to construct realities where these full any number of um are like induced load on any number of large amounts of clients. um So you know I want to kind of minimize complexity, but also not leave this as a glaring hole. I don't know that's not much of an answer yeah. I need to think about it.

G

E

We may just probably think.

G

More about it and and discuss yeah, I mean the problem, the problem when, when you say anytime, you make a claim that this is only a problem.

G

This can only become a problem when a node is sinking, um then the attack vector becomes. Can I induce a lot of nodes to sync and thus make this a problem? um You know the answer to that? Hopefully should be no, but, like you know a bug. If I can find a bug that can induce lots of nodes to sync, then I can maybe exploit you know an edge case in this that we didn't want to deal with yeah.

J

The worst failures are always compounding failures. Where you have you know, one thing goes wrong and then something else powers on top like those are the ones you gotta pray.

G

Build against marius, um I mean they. Essentially they have these branches that, because of the way fortress updated, can return an insert payload can return syncing syncing, syncing syncing. They have these branches that uh once the execution layer does finish syncing, uh you know they need to resolve these as invalid or not, and if not, they just have these branches that they just don't. They can never really know if or valid or not. um If this cannot be resolved, I mean the edge case is really I have I inserted a branch it has n blocks.

G

Now you tell me the the nth block is invalid. What about the the n minus one blocks before I don't know, um and then I don't know what to do with them is the that's the problem. So it's.

B

G

K

I get it no thanks.

E

Yep so um need to think more about edge cases for the sinking part of it, but for the when the parent block and state are known and it can be, and this information can be easily derived. I think it's must to be implemented.

E

um Yeah I like, I, don't think it's just a must. Yeah, that's bad.

B

Martin, your hand is still up.

K

Sorry, okay, always.

G

Yeah I mean just quick on this at this point. We should find a solution that works. I think very much. I would prefer to not change the structure of this response and just figure out the most correct way and complexity minimizing way to utilize the value that is there.

E

Yeah and moreover, we need this structure to be preserved for this first part, so it's it should be, it must be in place. It will not change. Yeah yeah this this question for how to implement the second part, I'm still.

G

Kind of open, yeah and I mean additionally, I think we need to figure out a way to induce and test these edge cases on in some sort of environment, because it's hard to actually run into these naturally, on some of these edge cases, naturally, on chain.

E

um And this cache, I don't think it should be persisted actually, so it should. It would be enough if yell has restarted, and this cache has gone.

E

Then then yeah, then the situation will likely repeat sent the el will be able to respond correctly.

A

After restart yeah.

E

Yeah yeah right yeah yeah yeah right, so it.

A

Will we can't remove uh invite blocks from block 3? I'm not sure how f is working right now, but we are uh on mainnet. We are removing inviting blocks from block 3.

E

I think you can remove blocks from block 3 if, if you do this on on my net, currently only information need is basically these two values so.

E

In cash, so you don't need to store invalid blocks for this purpose to serve this latest valid hash correctly. I don't think so.

A

Okay, I will think about it more.

B

And I guess yeah we can use the interop channel to discuss this as well and hopefully have something. I guess by like the consensus layer call next week, which yeah which we're happy with.

B

um Anything else on this.

B

Okay, um oh andrew sorry, go ahead. Yeah.

M

um Yeah, so I would like to say that um in aragon we probably most definitely will need to implement something like this, because it's a problem- and I would like to have um tests in in hive or somewhere for these this kind of scenarios um and also on how things with the merch are in aragon. I would say currently our implementation is- uh uh is alpha quality and uh before um switching um public testness.

M

I would like aragon to reach uh beta quality and um we need to fix the tests in hive implement this at kh case and quite a few things to finish and also start um start preparing a release. So I would say it will take us roughly a month to reach like to move from alpha to beta and yeah from from aragon's. From my point of view, I would like quite a bit of time before before, switching public testnets to profile stake right.

B

um That was going to be the next thing I bring up uh just want to make sure there's nothing left on the on the latest valid hash. But then I can kind of share my my thoughts about that and how we're tracking.

B

Okay uh yeah, so so, basically, uh I guess you know everyone's aware. The difficulty bomb is set to to uh to happen. um It's probably it's gonna start being felt around june and and kind of slowly ramp up from there um tj rush and and others. uh Somebody else has like a dune analytics dashboards and vitalik has a script which estimates it and basically, roughly around, like the end of july, is when you start getting blocks, which would um which would exceed like 17 seconds, which seems pretty long, and it's hard to all.

B

These are estimates it's really hard to to estimate how quickly the bomb goes off once it actually starts starts uh having a bigger impact on the overall hash rates, it's probably even harder to estimate now, because if the merge is the next upgrade, people might start selling their miners and so take all these. You know they took like a grand assault, um but basically I think if, if we want to avoid uh pushing back the bomb, what you what you'd want is ideally not reach like 17 second block times and people can.

B

You know, disagree on the number feels like 14 15 might not be too too terrible, um and a few calls ago, vitalik had this idea where, uh if anyways we are gonna, um we are gonna, put out a release uh with sort of a fake fork block uh in order to like disconnect nodes uh who who haven't upgraded from the merge, so just changing the fork id and we could do kind of a mini bomb push back, um but that only buys us a couple of weeks because it means that, like we need to make sure that um you know by the time the pushback happens on main net, the bomb is still manageable.

B

So all this to say, um if we want to like aim for that sweet spot of like we, we we upgrade and run through the merge kind of before we hit like 17 or more second block times um working backward. If you want to have you know reasonable time for like a main net announcement and then reasonable time for test nets, um we probably need to make. Oh, I guess we we need to make a call about like the test net fork blocks about a month.

B

From now so like two, not necessarily the next awkward devs but the one after um I think, if we're in the spot, like like late april, we're like we're not ready to say you know, the fork is gonna happen on test nets. In like a couple weeks, um then I I I think we probably want to consider like a longer bomb delay um and how long is something we can.

B

You know we can discuss, but that's, I think, that's roughly, where we're at right now, where, if we, if, if like in a month, basically four weeks from today, we're comfortable saying we're gonna fork the test nets in another like three to four weeks, um I think we're in a good spot to only need probably like a sort of mini bomb delay um which we can include with the merge release.

B

If, if in a four weeks, basically we're not confident about moving to test nets, then I think it makes sense to just delay the bomb uh a bit more independently and then and then you know for that's when we're when we're confident and the client releases, and obviously you know stuff, like shadow 14 main net. uh Next week will give us a lot of data about you know how how many more issues do we find um and and yeah?

B

I guess just general client readiness for to implement uh all the stuff we just we just discussed um yeah. So that's roughly my my point of view, I'm curious. If anybody else have high thoughts.

G

That all sounds like a reasonable approach to the timeline.

B

Your hand is up.

A

I think it is goodbye to observe that, but uh one comment from my uh site is that I think that we should run the test net public testnet for a longer time, the time the first test that should be- I don't know one month or something uh not like uh a week after, uh let's run the first test and a week after the first test that we are, we are running second test, and that is my opinion. Of course, not don't know what you are thinking about. It.

B

Is that to see basically, what happens exactly exactly.

A

So, for example, park road and observe it, for I don't know months or something and then for the next test. That is my opinion.

J

That's one month after the ttd, or is that one month from like when we launched the new clients.

B

You would extinct after the merge.

A

Yeah after the merge so after td, I think that is my personal opinion.

B

I I guess the counter argument I can see to that is we get like rapidly diminishing amounts of information like if the fork actually works? That's like a lot of de-risking and then, if you know it's it's still up for an hour after that's that's great and then, if it's still up for like a week after that's really good, I I yeah. I guess I maybe I'm wrong here.

B

I feel like that, like from one week to one month, we probably get less information than we do from like nothing to a week, um but if that's wrong yeah happy to understand why um andrew.

M

Well, one valuable bit of information is after, like a week after the merger two weeks couple weeks when you start to think a new note from scratch. What is the performance of this thing? That's something I! I would be curious to test.

B

Got it uh mirrors.

D

uh Yeah like this is something we we should already be testing right now uh on the shadow fox. um uh I think we don't like we shouldn't wait another month to start testing stuff like thinking from scratch. I I tested that on gas yesterday already and it kind of works. It's painful, of course, because thinking a full test net from one of the big test nights, probably from scratch, is already painful um but yeah.

D

So my my my opinion is that we should have two to three weeks for between the first between the first and the second test, maybe maybe only a week after polio, because I don't think that there's much activity on the polio, but for like a bigger test net, we should have uh for the first bigger test that we should have like three weeks.

D

Yeah three weeks, I think, is a good good thing and after afterwards the other testament should be in more rapid succession, maybe every week, maybe every two weeks, but we should like we. In my opinion, we shouldn't wait for every big test net test net for a month. That would just like delay things.

A

Yeah, just not to release uh all tests in one client's release that is so not in one release. uh I set tdd for every test. That is my opinion.

D

Yeah yeah, I like, I, don't think we can. We can could even plan that that's that seems like something that would would be very hard to plan, because we have so varying uh gtds on the testnets.

D

Tds on the testnets yeah.

B

Will it maybe make sense so like we have basically gordy robston and sepolia that are going through the merge um you mentioned, you know, gordy and robson are probably the ones we want to see, live or like.

B

We want to have like the longest data for so like, maybe there's something where, like you can start with gourley and then two weeks after you do sepolia or gordia robson, whatever like whichever one of the big ones, um and then you do sepolia, maybe like two weeks after because you kind of expect that if you know you shouldn't like learn that many new things on sepolia assuming the the previous one went well and then two weeks after that which is like four weeks from the original you have, you have the second big test net and then um and then, if you, if you do that, um then by the time we like choose magnet blocks like once, we once we've seen that.

B

Second, you know test that be live for for another couple weeks and we're confident that it's stable, then you kind of choose the maintenance blocks and and move there, um but maybe.

B

Yeah maybe like using this, this test net, uh like the septolia test net, which is like lower stakes in the middle, allows us to have like more time on under two other one which have more activity. Basically.

B

Okay, I guess yeah, we can continue kind of the test net ordering uh conversation async as well, but um I guess people generally seem to agree. We want like more than one week between each of the test net like we did for like london and probably more on the order of like two to four weeks and depending on the type of test that does that generally make sense.

B

Okay, um cool and.

J

B

Yeah I'll I'll look at like what that would look like from a scheduled perspective and and and we can chat about it on on the next call and uh yeah what uh yeah, when we would need basically to make a call if we wanted uh to- uh or I guess, yeah when when we when would we need to delay the bomb basically uh based on when we choose the test nets.

B

Anything else on this.

L

uh I have a question um especially to the gaff guys, but maybe also to other clients.

L

Did you ten testing around pruning? uh How do you avoid? Do you like uh track, would finalize and uh allow pruning only the things that are finalized or how is it working for you.

D

Like you mean pruning the chain away that is lower than finally for.

L

Example, pruning the block tree or something like that.

D

K

Well, we are the ancient so currently at the point, 30 000 block back in history. We only store the canonical chains and we move it over from our live database and put it in a not a live database, and when we do that we only store one of them for each.

J

J

Do you have any plan on switching over to using finalize instead of 30 000 bucks, or do you plan on sticking with 30 000 blocks forever.

K

I can't say really: no, no.

D

I I think we committed ourselves to not doing that like again back in in the summer, because we think, if something breaks and if we were to uh break the finalization, then we should be able to, and we want to be ready for that. We hope that it's never going to happen. But if it's going to happen, then we should at least support.

G

It right that's that length of time like if something goes wrong. We can fix it between this and that.

J

And how long are three thousand blocks.

B

About two weeks.

K

But it's not really, I mean the amount of the we already have 15 million bucks in the old I mean it doesn't really matter if we have if we move 20 000 more there or not um from a data perspective.

K

The big game was moving out: 50 million blocks from the live database and moving in sharing up another twenty thousand really.

G

And there might be other optimizations that are valuable there. You know but they're. I agree, they're, probably marginal compared to the big move.

G

You know database versus memory and that kind of stuff has finality.

D

uh Also, we only store so bad blocks are not stored in the block tree and we only store 10 of them so for for, like investigation.

G

10 for each bad chain, depth or just 10 period.

K

J

And presumably you only have one bad block per chain right.

K

uh Yeah, presumably um I mean improve the work. Well, I mean in our the way we uh we would only store a bad group of work block if the work is valid, we wouldn't just if someone sends us some random junk. We wouldn't have done so if the work is great and uh in a post proof mistake. Well, I'm not sure I guess anything.

G

K

G

Yeah, well, that's been pre-validated validated with respect to the signature so similar, but the.

G

You you say you keep you keep the stuff not going an archive or not in the freezer, whatever for 30 000 blocks that you can repair things, that things go wrong, but if you're only storing the first block on an invalid chain, an invalid chain could in fact be a consensus split chain. But how does that actually help you recover.

K

Sorry, I didn't understand the question.

G

uh Honestly, we should probably move on I'm sorry.

B

B

Anything else on just the test nets generally or the merge.

B

Okay, uh so next up uh shanghai. um First, we had uh alex with with some uh updates on eip4895, and then we had some other potential cfi eips so alex you want to go ahead and share the list.

N

Yeah, let me just share my screen to get the eip.

N

K

Oh wait: I'm having some issues.

N

uh Okay, there's, I don't think I'm gonna do that right now, that's okay! um So I can.

B

Just talk through it yeah I can share your document. Let me pull it up, but go ahead and.

N

B

N

Yeah yeah I mean so. Basically, um we've talked through the process of withdrawals over you know a couple awkward devs now uh just to remind everyone where we've gotten is that uh essentially you'll have withdrawals uh happening on the consensus layer if you actually just want to go to the render eip that works as well, but either way so you have the consensus layer, um managing withdrawals, they're dequeued in some way piped into the execution layer.

N

We decided to have these be represented in the execution layer as these new type of system level operations, and essentially it just says, here's an address and an amount, and you should just credit the address.

N

The questions that we had open last time are basically essentially syntax like how do we want to uh you know, sort of structure, the block and the header and different things, and so yeah thanks tim. This is just what I want to show now, if you scroll down just a little bit further, uh there's a block rlp here where essentially all I did was say: okay, this is going to be appended right after everything else, and this is like.

N

Similarly, in the header, you have uh a root for all withdrawals that is again opened to the end. So I think that was the main open question and I just wanted to get feedback on that point. um Otherwise everything else should be about the same.

O

G

You're, muted martin, if you're talking.

K

Sorry um I got a phone call in the middle. uh I didn't notice. That was my parent. Yes, I was wondering if we need a protocol update for.

N

This, like devp yeah right, so we will want to update that as well.

K

uh Yeah the the ease protocol update rather than b2b yeah.

N

Right yeah, so I was going to make a pr essentially to that repo to reflect those changes, but also wanted to get sort of. You know consistent on this. First.

M

So one small comment, uh I think, uh just just for precision the withdrawal shouldn't be an rop. The withdrawal should be specified as a list because then like the rlp rlp should be applied at the end, like everything is a list or a buy like a byte array in rlp, and um then you apply rop at the end. That's it it's it's a technical small comment.

N

I think that's how it was written, or did you mean something else.

M

uh I think in in you, you define withdrawals as uh as an rop of a list, but then kind of because rop is a string representation, but we had a similar, somewhat similar problem with type transactions when you additionally wrap rop as a byte array of things like that. So.

M

Currently like, for instance, trunk transactions in in block bodies, transactions are defined as list and then, when you serialize block body as an rlp, then you serialize transactions as an rlp. But if you define withdrawals already as rop, it means that they are a string instead of a lister kind of you. You additionally wrap a list into as rop byte array right. I want to avoid this additional wrapping.

M

N

I see what you mean now and uh yeah. I can update the ip for that.

B

Martin is your hand's still up? First.

K

J

And uh we already agreed last week that we're not going to use the um ohmer sash, we're going to add a new thing on the end. Is that correct.

B

N

That's my understanding yeah, because it's simple just to add stuff to the ends, and we don't have questions of this is reinterpreted as a new thing. A realist work with that work. All that.

B

Any other comments, aside from the rlp issue,.

K

C

K

What are the withdrawals? They have an index now, there's another amount. What is the use.

G

Oh, it was initially put in there actually to disambiguate. You know, if you're following logs and to make it useful because, theoretically, with partial draws, you could have a collision there where you get the same withdrawal twice, um but this might actually have negligible value um and we can consider removing it, um especially with the with the push method um very open. I.

N

Think it'll still be helpful for tracking it. You know like, if you're like a block explorer and want to track them right, because you can still have two withdrawals are the same, so it does differentiate them, but isn't.

K

The is there a difference between the explicit index inside the withdrawal itself and the index in the list of withdrawals.

G

No, I mean if you were tracking all withdrawals ever then there would be a one-to-one mapping from the consensus layer in the execution layer, uh but they are dequeued from the consensus layer. So they're not tracked in a list forever, um but if you were tracking them you can map them one to one with no problem.

I

G

No, I mean like couldn't the execution.

K

G

Index of all withdrawals, not the index within a single block.

G

All right, which could potentially be valuable, it is not probably critical for it to be in there.

J

That seems useful to me if the cost isn't terribly high.

K

Yeah yeah, you should probably specify what type they are. There are integer or.

J

Yeah, it's like the under the system, level, operation, colon withdrawal, subsection of the specification- and it has a one two three book uh list that has the types.

B

Okay, anything else on the withdrawals.

G

Yeah slight client there is, um we can link to it here.

B

Okay, um so next up, uh we had moody uh with an update uh on eip 1153, uh and I know there was already like a lot of comments in in the agenda about this um moody. Do you kind of want to summarize kind of where things are at.

P

Yeah, hey everyone, it's ready for muni, swap um yeah.

P

So uh right now, I think my goal ideally for this call, which might be a little bit lofty, is just to get this eip to cfi for shanghai and and that's not to say that, like I want people to commit to like putting it into shanghai, I just think we need to get it to a point where we can fund and do the work for potentially a future um hard fork, um and I think cfi will help a lot with that uh and just in terms of like signaling, that from client developers that like it, is actually a good and useful change, um and so from the from the last call.

P

When I talked about this eip, there were a few follow-ups which I can talk about. um If, if that sounds good to you, guys.

B

Yeah, if you yeah, I guess yeah. If you can give us kind of the updates in the last time, and then we can have the cfi discussion and whatnot yeah.

P

Yeah so so, last time there were a few follow-ups. uh First was like the impact that the eip would have. The second was a concern about um the linear memory expansion costs, which we've elaborated a bit on the eip, and the third was uh is this: like the best version of the feature, the best api for some kind of uh persistent memory across call contacts, and so just I'll go I'll start with the first one about impact.

P

So uh I mentioned the issues a bunch of developers from different teams that are all interested in seeing this feature implemented. um We we estimated in the thread just for v2. You know, swap v2 reentrancy a lock alone and just for uh just for the storage load operation being saved, uh it's order of billions of gas just for unit swap v2 um and then also uh in terms of like how much load there is on nodes.

P

It would we estimate trillions of read operations from disk and, and you can read some additional context of the thread in addition like it, it allows us to do new, smart contract designs with future versions of protocols.

P

We develop that weren't possible before, for example, this ability to like you know, do a lock across multiple pools and do things uh between all the pools without doing any rc20 transfers and in some cases the gas savings are drastic um when you don't have to transfer erc20s or call into erc20s in case in certain cases, um and so there's a lot of context to that in the thread, um including some gas estimates we did for for different prototypes.

P

um So so that's a little bit about the impact. The second one is the memory expansion cost. um So the amount of memory you can allocate is on issue, but martin brought up uh an issue about the journaling costs which isn't really fully included or like not fully uh analyzing. The eip. I think a simple solution to the journaling cost is just limiting the number of keys that can be stored in the map per address and- and I can update the eip to do that.

P

I think a thousand keys is is just fine, 10, 24 keys um or double that, or some order, magnitude or order of a thousand keys is fine, um and then there was a lot of conversation about like. Is this the best version of the feature?

P

I think uh one one alternative was um um was making a persistent memory, op code, uh which is by address and works more similarly to memory. um I think we we've had a lot of conversation. I've talked to like charles from viper.

P

um He was asking about a different api where a t store and t-load were by address, but still backed by a map in the client, and so you could write to any uh 32 byte word any offset, um but but that one was a little bit uh obfuscating for for the silhouette developers and the compiler developers. um So I I think, like this, this t-store t-load interface is, I think it's uh probably the best version uh just because um the language support is the easiest to add it's very similar to s4 and s load.

P

So uh so it's like it's easy to think about and there's also already sort of a concept of transient storage in the uvm which works through s store and s load. um It's just not very well supported because of the refund cap and the fact that you have to use refunds and then it also has to load from storage.

P

um So, like there's, there's already this concept in the evm, that's supported with slo nestor, so it kind of makes sense to implement it via t-store and t-load um and then finally, mappings and dynamic arrays are really heavily used in the use cases. We have and they're not supported today with memory and solidity, so it would be extra work to get developers to start using it and for it to be available in the language um and then yeah.

P

There was one more comment about uh the fact that this is like um sort of just like a gas. Optimization doesn't revolutionize anything. um I think it.

P

I think it opens up new smart contract patterns that will quickly become canonical, um and so, in my opinion, it does have a bit more impact than is clear to see like via you know, gas estimates, or um I think it has a lot of potential to like improve the developer ux for interacting with you know, you know swap contracts, for example, um but it's hard to express that without sharing too much.

B

Right thanks thanks a lot for for the update. um I know mark martin and you had like a long kind of back and forth on on the agenda comments and and uh andrew also. I brought up earlier like the idea um that uh something like say, deactivating self-destruct could be higher priority than this for shanghai. um So I guess just to kind of take a step back here like with in shanghai. We already have uh a handful of small eips. I don't have the full list.

B

um We already have this withdrawal eip and um oh eof was the other big one. So we have eof this withdrawal eip. That's cfi, a couple of other small changes like the warm coinbase, uh the push, zero op code and whatnot, and um I think, on on the previous calls, we discussed a bunch of uh potential uh solutions to lower uh the the cost for layer twos and none of those are officially cfi yet, but there's like some progress on them, um so I guess yeah I'd just be curious to hear from clients in general.

B

Like do you think we can add anything more scfi for shanghai now. uh Would you want to wait until we we've we're a bit farther in the implementation to decide that um are there things that you think we should potentially like earmark now um yeah, I'm just curious how how people generally think about that and andrew? You have your end up.

M

um Yeah, I concur with martin, I think uh shanghai is already big enough and uh if 1153 is, is, is also big, uh I personally uh or or the I have checked with the uh aragon's team members and uh the uh our how we see it the priorities the following.

M

So if uh 4758 deactivate self-destruct, is uh uh a great uh candidate for shanghai inclusion, because it's a simplification and it also paves the the way for the ryoko tree, so our preference would be to include 4758 into shanghai as to uh 1153, I would say we can see fight for cancun and also, I think, uh because shanghai is already big. I would uh cf 48 44 shot blob transactions for cancun as well.

B

Got it thanks? uh Micah, you have your hands up.

J

I just wanted to comment that I'm ambivalent on shanghai or not shanghai, but I do think there's significant value in um core devs, giving signals as to whether this is something that we are likely to include in. You know some near future hard fork. You know, I think we all agree. This is kind of a neat useful thing, but is this something where we can say? Yes, you know uh moody go tell the swap team and other app developers that you should spend money and time.

J

um You know developing this further and working with soliloquy team and working with client devs to implement this, or should we tell them, you know we're, probably not gonna get around this anytime soon. I wouldn't recommend spending money and time on further developments. For now.

I

I just want to say that moody's question, I think what he started with was uh whether this could be moved to cfi, not necessarily whether it should be included in shanghai.

I

I think that's, ideally what he'd like and the union swap team is interested in it, but uh I think he's just talking about cfi and I don't know if it's right to say uh you know this should only be like the what andrew just brought up like this should be removed from shanghai, which it already isn't being included um in in favor of uh removing self-destruct. I don't know if that's the right way to think about this right.

B

I guess the one thing I'm just cautious about is um we haven't implemented like anything, that's in the cfi list yet so like. If we had already like three quarters of it implemented, I think it would be like a different conversation where it's easier to say like okay, let's try to potentially add this as well and then, if uh you know, if, if it's working as expected and like it's, you know it's, it's there's no issues with it.

B

Then we we can move forward, but the fact that it's like there's already like six and yeah at least six things that like are not implemented. I yeah. I I'm just a bit cautious that, like we, we we get. You know to after the merge and we have a list of then 10 things we need to implement and we're basically back in the same the same spot. um Yeah.

P

So sorry, I should give an update on the status like in terms of the development work we've done. We've uh we've actually implemented, it's incomplete, we've implemented it in the ethereum jsvm and it's been merged um and that's how we've been doing the testing is against. uh You know hard hat with that: ethereum, jsvm um and and yeah. I agree: there's a ton of testing um yeah uh and we've written some of the evm by code tests, but like of course, we have to write um right. Okay, yeah.

B

So yeah, sorry, sorry I I guess I was more responding to accident, but like yeah they're, I it's good that, like it's obviously implemented in in one client and that it works and- and I think that's that's like really valuable. But it's there is a difference between that and like it's being implemented across like the four clients and you know, we've tested it and it works, and and we've had like a devnet running at it like yeah and but we don't have a good, a good word to discern between those two things.

B

I guess I'm curious: if does any client team like feel strongly that this should be made cfi for shanghai now um yeah, it's probably a good place to start.

B

P

Can I can I ask what about like for cancun? It sounded like one-person signal support, but cfi in general. I think just means that we can spend, spend the time and resources to to basically build on top of it, as well as like. Do the work ourselves um for writing those tests and implementing clients.

K

So I I think that a lot of clients- I'm not just going to think that I mean- are going to agree that it is a useful feature and it's very nice to have, and if they ask is like would we be open to at some point in the future?

K

You know- including this uh I I mean- I would say yes, but if you're, if like cfi, is some kind of stamp that this is now slated for inclusion and maybe not in shanghai, but definitely cancun or whatever comes next and then I will be hesitant to like say so right now.

K

But on the other end I mean.

J

K

Sure, maybe sometime I don't know exactly what they ask. You yeah.

B

I think I think the challenge is we, you know like shanghai. Realistically, you know is going to be at the earliest end of this year. Probably you know sometime early next year.

B

It's all depends on there's a bunch of things but like so so, if you're talking about cancun, you're talking about the fork after that, it's like you're talking at the earliest more than a year from now, like you know, say next summer, like 2023 and the challenge is the priorities might change between them right?

B

So it's like, I think, even if, if we had like strong consensus on this, call that like eip 1153 is, is like the most kind of important thing to do after shanghai, um it's kind of hard to make a commitment that that'll still be true in a year um yeah, and I guess we can yeah collect science. We can time box this in, like maybe two more minutes.

P

So I'm not I'm not sure. I understand what like cfi means like just based on the naming. It sounds like it's uh like consider for inclusion, not necessarily inclusion, so in.

B

Practice, yeah and in the past what we've done is like we've tried to implement all the cfi eips and if there were like issues that came up during like the multiple client implementations, we would you know, remove them, as we've had happen, would say like the bls eip, where we implemented it, we still weren't confident with it. But there was like this this implication of like. If we implement it, then it's all good. The default path would be for it to go to mainnet.

K

So yeah, I kind of see cfi as some kind of almost promise from the client corridors, that if you do the work with us and and you help us with the tests and everything, then we will put in the work from our side to get the stuff merged and to you know that there's this we have, we have approved it and now, if everything goes well, we're gonna gonna, do the work together to actually get it out there.

B

Yeah yeah, I'm I'm sorry to cut the shirt just to leave some time for the gory conversation. I do think like marius commented like we probably don't, have the consensus to move this see the cfi today, um and I think maybe one thing we should discuss on the next call is just like generally: when do we want to start like?

B

Do we want to maybe hold off in accepting new stuff for cfi until we're a bit farther ahead with shanghai implementations, and we have a better view, um but I I think we can probably discuss just like shanghai cfi at a higher level uh on the next call, um and if there is no time to discuss that on the next call, then it probably means by default we're not ready to add new stuff because we're still dealing with the stuff that's uh happening right now, um but yeah just to make sure we we can cover the gordy thing um afrid.

B

You want to give a quick rundown.

O

Yes, thank you very much. um I know 90 minute calls are draining, so I will keep it short. um There is this um kind of issue with some speculation on girly testnet and um I kind of feel responsibility to encounter these speculations, and um I personally believe that the girly testnet is still having a lot of significance. uh Initially with east ii or consensus layer. Testing uh now was merged testing um pratas depending on gurley, and um I believe, as opposed to like older test nets such as ring b and robson.

O

That might be duplicated soon. um Gurley should be around for another couple of years, at least um after the merge, and I would love to drastically inflate the available supply of gurley tesla tokens to first of all uh um avoid further speculation on any non-zero value of early test tokens, but also to provide um application developers, but also consensus layer testing engineers with necessary resources to conduct testing. um My uh I used to have a huge um stock of girl lisa.

O

This is coming to an end soon, and I know the timing is not very fortunate right now, because we are going all in merch this year, but I would like to propose uh to inflate the girly test. Testnet supply. I have written an initial proposal. I called it a girly eip1 because I don't think testnet specific stuff necessarily needs to go through the eip process or to bind so much more resources.

O

So um I proposed to uh pre-fund uh an externally owned account with uh 92 quintillion ether on the girly testnet um to uh to keep it short. Martin said that we should not do this. uh I think peter commented somewhere that we should not do a network specific or tesla specific force. um Eventually, martin proposed uh that we, instead of forever hard coding one key, I hold uh that we could just um have a more generic approach by pre-funding all active validator balances by a certain amount.

O

So I created girly eip2, um it's linked in the agenda under the first comment and again, if anyone wants to take a look, I I just want to have general notion from the coordinates from the oil collapse. If this is something feasible and we should consider it- and I would really appreciate if we could do something like this on the girly test net and no- we should not um so it was- has been proposed to do something with block reward.

O

But I believe we should keep it really simple, because if we uh modify the click block reward, then we will play around with consensus engine, and this would might this might drain too much resources from core developers. That is not really necessary, so it should be like a one-off thing. I believe.

B

So just yeah, because we're we're very close to time- and I think that does anyone have like an objection to generally addressing this like and and- and you know whether we do it through like a one balance increase or all validator increase like like just at a high level. It's anybody opposed to just the idea of like increasing the supply, to make sure that the the test nets value, the testnet, coin's value, kind of stays, basically, zero.

J

All right, I don't think we should do it for that reason, but the other reason I do think is very reasonable, like giving money to people that need girly youth to test things, issues.

B

So, to be clear, I think the amounts, though, that like afri proposed, are like so high that it basically drops to the valley yeah.

J

If that's that, if that's, if that's a side effect, I I have no care, I just don't like. If the only reason was to stop people from trading early youth for eth, I would not be in support of this at all. You definitely need a better reason than that.

B

That is the the main reason today.

D

So micah the the issue with increasing the block reward is that we don't have any block reward on goalie. So the the the proposer block, the miner is always set to zero and we don't have the private key for the zero address. Unfortunately,.

B

And so one thing, okay, so I guess the other thing I we might be able to get rapid consensus on is um basically is this something we want to do before the merger, after um I suspect doing it before the merge, would like delay things, but I'm just curious from client teams like how it you know, assuming we go ahead with some version of this proposal. The simplest from like a client developer perspective um in terms of timing, how the people feel about this.

K

So um the disapproval authority that the the coordination of the network itself is pretty easy. It's like four or five notes that need to be updated, but then you have the other infrastructure um and the the cl test. That's that rely on the gurley and all those I mean getting the test that itself to upgrade with the cedars. That's pretty easy, but getting all the other uh infrastructure and cll into integrations upgrade as well might be a bit more tricky and would be the thing that causes a bit of delay as well and operational issues.

B

So, okay, clearly there's and there's some comments in the chats with like different uh different thoughts. um What's the best way to continue this conversation async over the next two weeks, afree and and then we can- we can cover this um a bit earlier on on the next call.

O

I personally would appreciate if people could spend some time on the girly testnet repository to just leave a comment. I personally believe that this is something because it's only addressing a test that it can be totally uh solved. Asynchronously also there is this idea of so I turned ideas just to wrap. This up are creating a new test, and obviously um was the downside of losing all the existing infrastructure um there might be. A compromise in in in between these uh ideas is to have a regenesis. So basically we said girly genesis.

O

um This is also something that could be interesting by retaining the name, the the infrastructure, but having a new guinesses, basically starting from scratch. This is also something we can discuss and um I will invite everyone to the early test repository to discuss these ideas and eventually come to the conclusion.

B

Cool, thank you and yeah. Apologies that we, we didn't have a ton of time to dive into this um last up uh live client. If you want to give a less than one minute update on 48.44, and this is also something we can queue up for a longer discussion on the next call. If, if needed,.

Q

Sure yeah, just a really quick update, um we're continuing to work towards getting some sort of stable devnet running. We have george working on a tool to submit data blobs that actually commits to the blobs with the kcg commitment, vitalik wrote a really nice faq for the eep, which I'll I linked above but I'll link again here and then proto is going to start working again on the integrations next week.

Q

So um you know, I think my next acd it's pretty likely we'll have some sort of local sort of devnet available for people interested in using and then maybe after acd. After that, we'll have more of a like longer running devnet um available. I think we're gonna onboard some more people onto this over the next couple weeks as well, so we'll just keep posting updates in acd and in the other, relevant discord channels.

B

Cool. Thank you very much. um Anyone else have any quick things before we wrap up.

B

Okay, uh thanks everybody. I appreciate everyone sticking around a couple extra minutes at the end.

K

Have a nice weekend bye.

E

See you thanks.

I

E

I

E

I

I

I

H

H

H

H