All Core Devs - Consensus #181

Transcript

Parithosh Jayanthi: Hello, everyone.

Let's give people another minute to join, and then we can start.

Okay, let's get started. So the first item on the agenda is DevNet updates. Do we have Barnabas on the call to talk about DevNet 5 as well as DevNet 6?

Barnabas Busa: Yeah. So Glamsterdam, Definite 5 has been running for a few days now. It's been 3 weeks now. So it's been quite stable for quite a long time. We have a few clients that seem to be struggling to range sync. I think Lighthouse had a range syncing bug and Prysm had a peering bug. The prism peering box seems to be resolved on .NET 5 for now. And Lighthouse still wasn't able to sync up to head. Other than that, everyone else is up to head, and That's why we decided to move on with .NET 6, which just launched a couple of hours ago. And we're going to go into the Gloas Fork in about 40 minutes. So the scope of this DevNet is on the spec sheet.

We're here. We have added pretty much all the remaining EIPs, except the stable container one for the sale side.

Parithosh Jayanthi: Nice, so this is all of the EL as well as CL EIPs in this DevNet except for stable containers.

Barnabas Busa: Yes, that's correct. And, currently we have 3 executioner clients, which are Besu, ethrex and get. For DevNet 6, and for DevNet 5, I think we have all the clients. So as soon as your client is ready to be onboarded, please let us know, and then we can add you to it. On the CR side, we have all but, current team.

Parithosh Jayanthi: Is there specific tests that you're looking to do over the next day, or what's the general plan?

Barnabas Busa: So the most important one now is that we're going to be doing some slashing just before the fork. hoping that those validators will not get scheduled for the following epochs. That is also one of the EIPs that we included in the previous DevNet already. Yeah, so there are 3 special editors for now, and we're going to be doing a lot more just before the fork.

Parithosh Jayanthi: Awesome. That's great news. Okay, so that was the next point on the agenda, so test slashed, validators pre-fork, so yeah, Padam's already mentioned that we've taken care of that, so we should be able to see this. The next item on the agenda is, a potential spec bug that Michael's brought up? I'm just gonna link it here. Has anyone had a chance to look at the specific bug yet? Okay, yeah. Terrence says it's valid.

Justin Traglia: I mean, I have looked at it. I'm pretty sure it's valid. I'm just waking up, though. I can review more later.

Parithosh Jayanthi: Yeah, of course. So I'd assume there's gonna be a patch for this, and then a spec release, and then we can target the next DevNet on the spec release. Yeah, we'll fix it for DevNet 7, basically.

Justin Traglia: Yep.

Parithosh Jayanthi: Sounds good. Anything else relating to DevNets?

Etan Kissling: Well, on Monday, you wanted to… have a no-go or go decision on 7688 today. So, I'm not sure whether…

Parithosh Jayanthi: Yes, I have that in the agenda slightly after, but yeah, I will be back to you.

Etan Kissling: Okay, I didn't see it in the agenda otherwise, so, okay.

Parithosh Jayanthi: I might not have updated the latest one. Sorry. Yes, I will be bringing it up in the agenda later today. The next item on the agenda was relating to the builder API, removing submit builder, submit beacon block. This was from Bharat. Do we have any updates for this? Have client teams had a chance to look at it? Okay, Okay, I guess the default is to keep it if there's no, push for removal from Nico. On a similar note, has anyone started working on circuit breakers? Do we want to have a push for standardization, or keeping it as is, and if clients implement it, they do, otherwise they don't?

Terrence says they haven't spoken or thought about circuit breakers yet. Do we have other client teams, and… Have they looked at circuit breakers on their codebase? Or are we launching DevNet 6 right now with no circuit breakers?

Barnabas Busa: I think this is a consensus. Like, like, we don't, we don't need to agree on this. I think, Every client could come up with whatever strategy they think is best, and that's good.

Parithosh Jayanthi: Yep.

Barnabas Busa: Good photography.

Parithosh Jayanthi: That's fine. But do clients have the code base for some strategy today?

Barnabas Busa: I think there's a bunch of topics that have been discussed, especially during the interop. But yeah, I don't think any client… would have implemented this already, and I'm not sure if this is gonna be… need to be ready for mainnet. Before we roll out.

Parithosh Jayanthi: Sorry, you're suggesting we go to mainnet without circuit breakers?

Barnabas Busa: Yeah, I mean, I don't think we need all clients to have circuit breakers.

Parithosh Jayanthi: Sure, but at least we need a majority of them to have it. Otherwise, the chain would be in a broken state.

Barnabas Busa: Well, we could have multiple bids coming in, so… I'm not so sure about that anymore.

Parithosh Jayanthi: Okay. Yeah, Terrence?

Terence Tsao: Speaking from Prysm, we're using the same circuit breaker we have today for MAV boost. We just apply that, which is a simple one. You basically look at how many blocks are missed, like, in a row or in an epoch. I believe it was, like, two blocks in a row, three blocks in a row, and it's more than four minutes in per epoch, then what default… the next proposal will use the local block building. So it's the same as today, but this may be Prysm specific.

Parithosh Jayanthi: Yeah, I think having the circuit breaker that you have today working with EPBS is perfectly fine. We don't need to standardize it, but not having a circuit breaker at all feels extremely fragile. Yeah, Enrico?

Enrico Del Fante: Can you hear me? S.

Parithosh Jayanthi: Yes, we can hear you.

Enrico Del Fante: Can you hear me?

Terence Tsao: Yeah, okay.

Parithosh Jayanthi: I agree.

Enrico Del Fante: Okay, sorry. So I talking about because the the previous circuit breaker were based on beacon blocks. So now you at least you you have your updated to to count for For missing payloads? Or you're still…

Terence Tsao: Yeah, no, no, no. So yeah, I'm incorrect in a way that we're still using consensus blocks, which is a little bit off, right? And we need to add that using the payload status as well.

Enrico Del Fante: I mean, we should… there is no circuit breaker if the… if the beacon chain chain is… is working fine.

Terence Tsao: Yeah, which is our implementation, it's more like a bug, rather than…

Enrico Del Fante: Exactly. So we should do something. So the default, so the pre-gloss circuit breaker. Doesn't really work,

Terence Tsao: Exactly. So I will apply that which I assume it's a few lines of code hopefully to do that.

Parithosh Jayanthi: That makes sense.

Barnabas Busa: So we'll actually take a look at the payload as well. We're just gonna keep it to the weekend block.

Terence Tsao: We have to look at the payload. That's the right way to do it.

Enrico Del Fante: Because I believe you should not even consider the Beacon Block, because nowadays the Beacon Block should not be affected by By the payload and all the machinery around it at all. So. Circuit breaker for beacon blocks goes away, and now we just have… payloads reasoning.

Parithosh Jayanthi: Yep, that makes sense. This is something I would propose we should test in the future, but yeah, I agree with Dustin's theme there as well. It's not as fragile as it was before. The next item on the agenda, just to mention, the State Builder API for Glamsterdam has been merged, I've seen that there's some amount of work being done on the Builder API recently. Does someone want to speak to that? have all the clients implemented it, and we're testing it to the full scale on DevNet 6, or what's the plan? Yeah, Terrence?

Terence Tsao: Yeah, we have an implementation, it's not merged into the DevNet branch yet, but Barnabas and I have been testing. The latest progress is that, like, we got, like, multiplexing working, meaning that the closest to support, different builders, more than one builders, with their unique URL, then we're able to sign it and send the auths over, and the builders are happy, they're able to verify the authorization, and then we choose the highest bid. That's the latest progress, but… I think I need to work on getting those features merged into our main branch. such that we can use it for the next DevNet. But at least the Kurtosis has support, and the builder has support, so client can start testing.

Parithosh Jayanthi: Awesome. I would assume we have it as an explicit target for the next fork so that we're also slowly reaching feature completeness, but that makes sense. Next item on the agenda was Beacon API PR. This is Gloas Proposal Preferences API. Do we have James for the status, or have client teams had a look at it and left reviews?

james: Yep, just still waiting. Waiting on more reviews. Prysm has already implemented all the… items in that PR, but… Yeah, looking… looking for review and hopefully approval.

Parithosh Jayanthi: Cool. Would clients be able to provide approvals so that latest by ACDT we merge this in? Okay, thank you. Has any client had a look at, pre-activation validator statuses and deposit in queue for post-Electra or Fulu deposit pipeline? There's another API change. Okay,

Barnabas Busa: To change this?

Parithosh Jayanthi: It was brought up in the agenda. I'm not 100% sure. Okay, maybe it was the wrong link, sorry. I can… Okay, got it. I will try and figure out what happened with the wrong link. In the meantime, the next point on the agenda was extending the peers API with peer scoring and disconnect reasons. Do we have any suggestions or things to merge? Nico, I think you were reviewing the PR. Is there any open topics there, or is it just waiting on clients to approve it?

Nico Flaig: So I haven't looked at it from the implementation, but if people are fine with how the spec looks, I think we can probably merge it. The only open question was if we want to add the extra data field. But, yeah, I think we anyway keep the V1, so we are just extending that, so I think it's fine as is, probably.

Parithosh Jayanthi: Yeah, it sounds like extend with optional might be the easiest way to go.

Barnabas Busa: Could we also aim to merge this in them by acdt. If nobody has any opposition.

Nico Flaig: I think it would be best if someone from Techco could maybe approve it. Seems like they are the only ones that looked at implementing it, so…

Enrico Del Fante: I believe Paul will…

Barnabas Busa: Yeah, I will have a text with both.

Parithosh Jayanthi: Okay, thank you. Any other open API slash builder-related changes for Glamsterdam? James posted, here, James, do you want to speak for that one?

james: Yeah, this is the new proposer path. Pr? For APIs, so it's introducing the Get Block V4. And submit block offered Glamsterdam. I already gave a thumbs up on this one. There is a separate topic regarding one of the query parameters, which is the builder boost factor. Potuz has already raised an issue on the… on the repo. I think that's gonna be a bigger… discussion, and I don't think this… that discussion should block this PR, which at least should satisfy the self-building paths. So this includes both the Stateless and stateful paths for,

For proposing blocks in… in glass. So, I think we just need… More people from other teams to… either approve it or give any last comments. The author of the PR Shane mentioned that he is getting married, so he is out of office until July 4th. So we will have to take over if we want any… changes before that. Or just do it in separate PRs.

Parithosh Jayanthi: Would, clients be able to leave a review by ACDT? And then we can get that merged async. But yeah, I agree, I think this is something we should test earlier rather than later. And then we can talk about inclusion for the next subnet, I guess. Yeah, it feels like there's a lot of Beacon API PRs, it would be nice if we can clean this up for… over the next days. Yeah, and the message from PK is that we should probably monitor the endpoints that are already in use. There's also a simplify payload attributes event, That, that's been linked here from Etan, and yeah, I'm… probably the same instructions as before. I think it would be good to…

have people review this, and hopefully by ACDT, we get it merged in, and we can schedule all of these for DevNet 7. Especially if they're breaking changes. Okay, anything else for API or builder-related topics? Okay, let's move on to EIPs. So for Glamsterdam, the first one is EIP 7688. The floor is yours, Ethan.

Etan Kissling: Yes, on Monday, we had ACDT, and… We wanted to decide whether to include or not include. 7, 6, 8, 18, 2. the scope, like SFI or DFI, And there was this plan to do this go-no-go decision today. And I guess it would be good if every client team could Just, provide their views, and… How far they are with the implementation. So, yeah.

Parithosh Jayanthi: Yeah, so SFI would have to wait until it's the DevNet, but we can make a decision if it's DFI or not DFI, essentially.

Etan Kissling: Oh.

Parithosh Jayanthi: And then talk about including it in the next DevNet. But for that one, it would be extremely important to get client team voices. Have teams looked into implementations? I'm just going to go, step by step. So, yeah, Cayman from Lodestar says they have an implementation. Nimbus has an implementation. Grandine doesn't, Lighthouse does, Teku and Prysm. What about you guys?

Enrico Del Fante: We are working on it. It's not completed can be like Poc. POC, like, implemented soon, but it will require a little bit more… work. to… To improve. Cause I got some some some. that's around. What happens? on the transitions when we need to. translate attestations on, on, on, when, when, when things, when, when fork, when fork activates and need to also double check all the potential performance regressions. So yeah, it's It's on the way.

Parithosh Jayanthi: Do you think it's a sizable lift for DevNet 7, or do you feel like it's in the scope of possibility? Like, are you starting fresh, or is this a working…

Enrico Del Fante: No, yeah.

Parithosh Jayanthi: Something you just need some time to refine.

Enrico Del Fante: Yeah, it needs to be complete. It's not starting fresh because we had a previous implementation on the very early… prototypes for previous version of this of the EIP. But the point is that this very last version of the EIP introduces the progressiveness in various other places, and even in places where we were not very prepared to change the type there. So the radius blast Plus inteco side is pretty. Yeah, touches places where we were not touching previously.

Parithosh Jayanthi: Okay, and has this already been taken into account in the other implementations? lighthouse or Prysm, for example? Have you guys already… Is the implementation mostly there, or… Where are you guys at with it?

Kasey Kirkham: Prysm… PRISM, has a… We've updated our code generator, so we're generating, localization code that passes, ETON's, spec test fixtures. And, like Teku, you know, we had to deal with, all of the fields, that are becoming progressive lists in different places, so that took a little bit of, more changes on the, on the code generator. But, there's some other nuances, like the, what to do with attestations of the transition. That's something that, that we have flagged as well to figure out. And, so there are details to work out, but, we have, you know, kind of the hardest part of the implementation, figured out, so we feel good about it.

Parithosh Jayanthi: Okay, that sounds… Like, it's promising then, So… could we get a go-no-go from our clients? Would you guys be ready to spend the time to schedule this for DevNet 7, or would you feel like it's too big a lift, there's other priorities, or there's… builder-related work that needs to be done instead for DevNet 7. Could we go client by client? The when is DevNet 7 is an open question, of course. It depends on DevNet 6 stability, but let's try and target 2 to 3 weeks so that we can slowly start hitting production-level code and then, scheduling testnets. Nimbus says they're okay. What about the other plans? Lodestar, yes. Okay. Casey, would that be a yes from Prysm, or is that a maybe?

Kasey Kirkham: Yeah, I would say, I would say it's a, it's a, it's a weak.

Parithosh Jayanthi: Okay, yeah.

Enrico Del Fante: Yeah, the same for us. I mean, the amount of work that needs to be done on the API side and the builder flow on the TECO side is still pretty big. So, this adds up on… on the current… Workload and yeah.

Parithosh Jayanthi: Okay.

Enrico Del Fante: Well, it's not a no, but it's a… is a yes, or hopefully.

Kasey Kirkham: I do also want to throw in that I think this is somewhat unique, in terms of our, you know, DevNet, Merge philosophy that we've had in the past, where it would be easy to pull this out at the last minute, it's like not interacting with other things in the fork. So I feel okay about, you know, saying, like, let's go for it, and then if we get to DevNet 7, and we have other things we need to test, and we need to pull this, you know, as long as we have another DevNet, to test it, It it seems not too risky.

Enrico Del Fante: Well, I'd push back into the easy rollback of it, because when you have to deal with all the type changes inside the code, then… Start removing everything. So it's pretty invasive in certain areas, at least for for us.

Kasey Kirkham: Okay, yeah, that's fair. That's, yeah, that's very.

Parithosh Jayanthi: Okay, it seems like we're at an even split. We have three clients that say yes, three that are maybe. That to me sounds like there's no one that's a strong no, so we wouldn't DFI this today. And, we should probably target it for DevNet 7, and then if it feels like it's too big a lift for DevNet 7, or it feels like there's a lot of other bugs that have been showing up on DevNet 6, then we can revisit the decision and then DFI it, later on. Does that sound like a fair outcome? So, stable state, everything goes well, it goes in the next devnet. If it feels like it's too big a lift, if it feels like we're finding a lot of other bugs, in that case, we, we don't include it in DevNet 7

Okay, anything else for progressive containers, or are we, all aligned on the topic?

Etan Kissling: No, it's good. Just have to set the expectation that it's included, like in Devnet 7, right?

Parithosh Jayanthi: Yes, I mean, unless something drastically breaks in DevNet 6 and we need to change the spec by a big amount, yes, we should sprint towards it on DevNet 7.

Etan Kissling: Yeah, thanks a lot.

Parithosh Jayanthi: Okay, the next EIP to discuss is EIP-8080. We had signaled intent to DFI this EIP. Is there any reason to not DFI it? Have clients got some more time to look into it and want to revisit the decision? The main reason for DFI was that in the past, it seemed like it was a lot of implementation complexity. Okay, then we will move EIP-8080 to DFI.

But… Sorry, Dima, do you want to say something about the EIP before we go ahead?

Dima Gusakov: Yeah, sure. I'm absolutely not aware of how complex the implementation is. At a glance, it looks like it shouldn't be complex, but the devil is in the detail, always. In general, I want to say that this concern with The ability to utilize consolidation queue for faster exits when the exit queue is clogged. is a pretty meaningful problem on the application layer for staking providers, because How does how to properly frame that? Mmm. A few providers… have all have previously indicated that they are using it, even though This is not an intended behavior, but like Aetherfy recently, when they were closing their solo staker program.

They were using consolidations to exit their solo validators by simply consolidating all of them to one thing. I think before being acquired by Maven, Peer2 made a big announcement that they are even selling it as a product feature. Which is, in general. Like, it's not great that we have this duality where you have two ways of effectively exiting the stake, when one of these ways is Definitely not meant. to be, done this way, so… like, if there is a chance that we can include this EIP, that would close a very unfortunate gap that we have in the… Consolidation specification and what is more important is that. There will be no chances again of, Some players,

Like having an unfair disadvantage compared to the others because the simple thing here is that, if you are building a… like, a reasonable DeFi application without a multi-sig controlling it. You… to utilize this feature, you need to have a specific implementation for that. While non protocols like professional operators or just shady protocols that are managed by multisig have an unfair advantage of being able to use that. And in my opinion, it's not the, like, the best situation when we are giving an unfair advantage to those using not the best security practices and protocol building practices.

Parithosh Jayanthi: Yep, I think the intent and motivation for the EIP are, are clear. I don't think anyone was even particularly against the EIP. Most of the pushback was purely around, implementation complexity, as well as Glamsterdam already being a massive, fork, where even today we just added another big feature to it. So I think the pushback was mostly around implementation complexity and time. However, that being said, since there's no fundamental reason why anyone's opposing this, and it is a gap that's worth, plugging in the future, we still have the Hegota non-headliner window open. So I'd suggest that the authors re-propose for Hegota, and then this is something we can still solve in the future.

Greg K | Lido: So I will be just curious to listen from someone what is the implementation complexity because, you know, I was involved in finding this kind of bug in the specs of a consensus layer and it seems that TCAP is just updating one function. So it's not really a big change in my opinion. So, I was just wondering, like, did the… during… testing or implementation, like, corner cases appeared, or, like, how did this, complexity arise as a factor here?

Parithosh Jayanthi: I have to check which, I think we have to check the forecast transcript to see which, which… ACD, we spoke about this, probably the two ACDs in the past. Do any client teams have specifics that we can bring up today? Okay, I think we might have to just dig up the transcript and then get back to you on that, Greg. Is that okay? Okay. Thank you. The next item on the agenda was, EIP8045, exit slash validators from proposing. So… I think the open agenda item was,

There was a PRISM PR, and if we can SFI this EIP now. Do we have voters on the agenda? At least my notes say that… You were waiting on something there.

Terence Tsao: I thought this was already in the DevNet?

Barnabas Busa: Yeah, this is already indefinite.

Parithosh Jayanthi: Okay, so it was just about moving into SFI status. Okay, got it.

Dima Gusakov: Technically speaking, it is worth waiting for the actual fork to happen on DevNet and then to see that it works.

Parithosh Jayanthi: Yes.

Barnabas Busa: Or even the.

Parithosh Jayanthi: Totally.

Barnabas Busa: It's not on demo text. This was already included in the previous demo.

Parithosh Jayanthi: Okay, got it. Sounds like I just had some stale information. Do we have an update on, A2A2 builder execution requests?

Barnabas Busa: It's… Gonna be tested on 11.6. in 8 min.

Marius van der Wijden: I can give an update if there's no one else from the guest team here. Yes, please. So… One thing that is broken with this is the mechanism. Same as the other contracts, but this one is a bit more severe. What Felix now implemented is a new version that updates the fee every time someone is added to the queue. Not on, on every block. That means that… These might be a bit higher, but we don't have this this case where we where you can enqueue a lot of validators. into the, a lot of builders into the queue or the execute. And then the. The fee is updated into infinity. So, yeah. A new version of the contract should be.

Out already, And that one is strictly better than what we have right now. And the old version is being tested on Well, definitely 6. Which is good, so we can test the workflow, we can see if all the plumbing is correct, and then… For definite 7, we should probably update the contract. Yeah. Otherwise, what we also want to do is have internal reviews and external reviews. For the contract, because… This change is not big, but it does update the logic of the conflict. Yep, I think that's 482, 82.

Parithosh Jayanthi: Awesome. Thank you. Yeah, Nico.

Nico Flaig: Yeah, just one more update, which also relates to updating the contracts, so it would be indefinite 7, which is we might wanna tweak the values we currently use for deposits. It's currently 32, the target, and… 256 is the max, and I think we should reduce that to 8 and 64. That would allow us to further reduce the withdrawability delay for builders. So currently it's, I think, set at 8,192 epochs. And we can… with 80 to 82, we can safely reduce that again to at least 64, what we had previously. But I think we can further reduce this, if we adjust the contract constants to, like, 8 epochs or even lower, because there's no DOS risk anymore. So this would, make the UX for builders a lot better.

As they can more quickly withdraw their money if they need to. So potentially they can stake more ETH that way and compete more on high value bids and use trustless payments. So that would be the main argument to do this.

Parithosh Jayanthi: Thank you. Would a combination of Nico, Marius, or potentially the authors let us know when it's in the final state? Because we would still have to organize an audit for the final contract. That can happen in parallel, of course, but still, it would be useful to have a… Have a signal that it's in the final state. We can just add it to the agenda on every ACD and ACDT to check in, so that we get it now. 3-day cadence, and know when everything's final.

Nico Flaig: Yeah, I would probably defer this to Felix or Matt to talk about when the contracts are in the final state. Maybe they are already. The change from my side would only be adjusting two constants, basically, which should be minimum.

Parithosh Jayanthi: Yes, but we'd still want to wait until everything's final, including the constants, before we send it out for the audit.

Nico Flaig: Oh yeah, I think that one definitely, yeah.

Parithosh Jayanthi: Okay, thank you. Yeah, Marius.

Marius van der Wijden: No, I just wanted to say happy to check in with. of my guest team members on the status end. We can go ahead with the conference, and when we I guess it depends which for the orders.

Parithosh Jayanthi: Okay, perfect. Any other Amsterdam-related topics?

Barnabas Busa: Do we want to do the dynamic? Size or no on the contract. Dynamic queuing that Piki raised. Maybe 2 weeks ago? Regarding A2A2.

pk910: probably would make sense if we are not sure, about the, DQ rate. Like, we are still guessing if 265, 56, or 64, or whatever. That's why we could change it after the 4… after the 5… Future fork without, doing a irregular, set change on the contract. Because when we hardcode it and deploy it, you can't change your contract anymore.

Parithosh Jayanthi: Is this captured as a comment, or a PR to the EIP, or somewhere that people can discuss this? Okay, if not, then maybe you could open up PR so people have the exact changes in mind, PK?

pk910: Yep.

Parithosh Jayanthi: Okay, yeah, and comment from Marius was that it sounds a bit predictive. Cool. Any other, EIP discussions for Glamsterdam, or Glamsterdam topics in general. Anything clients are having trouble with, or want to… Flag today. Okay, perfect. Let's move on to Hegota then. There's only one point on the agenda, it's that we still have our Hegota non-headliner window open. For now, we're still looking for when the last date would be before the window closes, but for now, it's open, and I just wanted to announce that.

Any other Hegota-related topics? We still have some time or so, if there's anything FOCIL-related, or… anything else that client teams have been working on, for Hegota, then we can discuss that now. Okay, Justin mentioned that Lucille needs some… Lucid needs some CL oversight.

Justin Florentine: Yeah, can I do a plug real quick, since we got some time?

Parithosh Jayanthi: Sure, you have the next few minutes.

Justin Florentine: Real quick, Lucid is ongoing. I'm working on execution layer specs for it, but I don't know what goes into good CL-level specs. So if anybody is interested, we could use some advice and some guidance on how to not embarrass ourselves. when opening, you know, CL specs, changes to the, changes to the Python stuff, etc. So, if this is something you can help us out with, if you can take a look at what we're doing, and tell us that we're crazy, or give us a little bit of guidance, that would be super appreciated. Reach out to me or anybody else involved with encrypting the mempool. Thank you for coming to my TED Talk. Love you all. Bye.

Justin Traglia: I can help you with that. Either way, I'll reach out.

Justin Florentine: Justin Power. Thank you, bud.

Parithosh Jayanthi: Thank you. If there's no other topic, then I do want to mention that we're currently having our vote for what the Glamsterdam mascot should be, so please remember to drop your vote. And that being said, that's it for ECD 181. See you guys in two weeks. Sorry, Lauren?

Loring: Yes, I posted this on the GitHub issue, but a quick announcement. Shutter and the Encrypt the Mempool Coalition are offering a 3 ETH bounty. for feedback on the draft EIPs 8105, that's Universal Enshrined Encrypted Mempools, and EIP 8184, Lucid. So if you have feedback, please share your feedback and submit the claim before July 30th. The link is in the GitHub issue. Thank you.

Parithosh Jayanthi: Yeah. Yeah, thank you. I do wanna echo Marius's sentiment, usually we don't use ACD to talk about bounties, but yeah, please have a look at the EIPs available. Thanks everyone for coming, and see you in two weeks.

Marius van der Wijden: You're right.

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