All Core Devs - Testing #82

Transcript

Justin Traglia: Good morning, sir.

Barnabas Busa: Hmm…

Justin Traglia: Will you be, able to give an update? Or sorry, the DevNet status updates?

Barnabas Busa: Whoa. It's dead.

Justin Traglia: Well, there's also bal-devnet-7, right?

Barnabas Busa: That would be Stephan.

Justin Traglia: Oh, okay. I'll ask Stefan to give that one, and then I'll ask you to talk about how dead Deadman 5 is.

Barnabas Busa: Sure.

Justin Traglia: Good morning, everyone. Let's, give a few more minutes, and then we'll get started.

Good morning. Just a few minutes, and then we'll get started.

Justin Florentine: Good morning, test tours!

Justin Traglia: Good morning. Alright, I guess we can probably get started. I'll be helping out with ACDT today, so… yeah. Alright, welcome everyone to ACD82… ACD2… sorry, 82. There's a lot on the agenda, so let's just get right into it. Stefan, are you available to give an update on bal-devnet-7?

Stefan Starflinger: Yeah, sure. So, the benchmarking efforts are mostly underway for bal-devnet-7. The network itself has been running pretty stable, and it's deploying new versions continuously, and it's still stable, which is great. And I think for the benchmarking effort, Maria has a more concrete update with new numbers, but it's looking pretty good. From what she showed earlier.

Justin Traglia: Should we talk about that now or later?

Stefan Starflinger: Is Maria here?

Justin Traglia: That's a good question. No, it doesn't appear to be, so let's talk about that later. Thank you. Okay, Barnabas, would you like to give an update on Glamsterdam devnet-5 and its, dead state?

Barnabas Busa: Yeah, so we launched .NET 5 a couple of days ago, and it's been struggling quite badly again. There are different bugs that have been found. Recently, every single client seemed to have a few bugs here and there. I think, the main root cause of the, lots of forking was still not, It's still not very clear to us why it has happened, why we have so many different forms, and Why we don't have, like, a clear split between one or two specific clients? It's still a work in progress. We were considering of possibly doing a quick relaunch under DevNet 6, but I think most of the efforts are going into possibly trying to recover DevNet 5, and if I think we cannot do it by the end of today, then tomorrow we should relaunch.

We're the same spec.

Justin Traglia: Okay. I think I heard from Terrence. That, Prysm is having a syncing issue? Is that something that can be resolved, Terrence, or someone from Prysm?

Terence Tsao: We don't have, the ability to sync from finalized checkpoint, so probably not just from our end, but if other clients can support it, then we can… if today we can have majority, on it. without Prysm, that will also help as well. Or, if anything, you can also rotate the Prysm Validator key to some other clans, if they can handle it, and yeah, Potus, did I say something wrong here?

Potuz: No, no, no, you're absolutely right.

Terence Tsao: Yeah, yeah, yeah. So basically, yeah, so basically, yeah, that's it.

Justin Traglia: Okay. Potus, what do you want to say?

Potuz: Yeah, so I don't… I don't really see any reason to… to recover DevNet 5. If we want to understand what went wrong, that's… that's an effort that is useful. Recovering in a way that we didn't understand and we didn't learn anything, it's just useless to me. I've tried to look into the Prysm notes, and as far as I can tell, I can't find anything that is Prysm-specific. We definitely are isolated, and we ran out of peers, and then peers are not serving now anymore. payloads and blocks, and the reason why we got isolated is, is the tricky one, that it's not clear. We seem to be downscoring peers for serving as garbage when we went into sync, but that doesn't explain why we went into sync originally.

Barnabas Busa: One thing that's a bit… sorry, one thing that's a bit different, compared to previous DevNets is that we've basically migrated all of our backend stack from DigitalOcean, multiple regions, into Hetzner, just a couple of regions. And we didn't have, by default, enabled the P2P co-location whitelist flag in Prysm. So… I would be curious if maybe, Prysm was, like, downscoring because of all the peers that were coming from the same co-location… location.

Potuz: Yeah, so that… that… that does happen, that… that definitely helps, but still. It's not clear to me why we went into syncing. Like, why we stopped receiving, objects from over gossip. But definitely, yeah, so… so the collocation is now we… we are downscoring because of that. But we're also downscoring because we're getting inconsistent. I saw a lot of debug messages of getting inconsistent payloads from blocks. So people are still serving by range request in an incorrect manner, as far as PRISM is concerned. It might be that we… our code is wrong, and it's incorrectly marking those as inconsistent, but that's… That's what our log says, that we're downscoring peers for sending us inconsistent payloads with blocks.

Justin Traglia: Do you know which peers you're downscoring? Is it a particular client, or…

Potuz: Oh, yeah, we… I can probably look that up, but Terrence might correct me. We had a bug in which We would recognize that there were inconsistent payloads with blocks, and then we were downscoring the incorrect peer.

Terence Tsao: Yeah, we also have a bug that if we change our view between empty and full in the middle of a slot, we will produce an inconsistent payload with respect to withdraw, and that bug was facing in our main branch, we just never put that into the DevNet 5 branch.

Justin Traglia: Barnabas, I have a question. Could we keep DevNet 5 for, like, another 48 hours to allow clients to debug, and then… at the same time, launch Glamsterdam devnet-6 today. Huh. Is that an option?

Barnabas Busa: That is definitely an option. I'm just curious whether there would be value in doing that.

Justin Traglia: Okay, Nico.

Nico Flaig: So, just from my debugging, it seems like even if I force loads down the same branch as Nimbus. There are stream negotiation issues, so I'm not even receiving the data. And, I took fork choice dumps, and it looks like we are completely unaware that these branches exist. So the node just keeps building on its own branch. And then there's a second issue, which is I… most of the ELs are now optimistic, so we cannot produce blocks anymore, and we do not attest. So, while I think we could maybe recover CLs, I'm not sure about ELs.

Justin Traglia: Enrico?

Enrico Del Fante: I just skipped the first 5 minutes. I just want to share that we have some, things to look into and fix, and probably… it seems like we are not the only one, so… I'm in the camp of maybe not launching DevNet 6 that early, at least wait a couple of days to allow us to fix things and have a better fixes in the clients before launching. That's my gut feeling, so maybe leave the DevNet 5 alive, if it makes sense, for… for some testing, but wait a little bit before launching DevNet 6.

Justin Traglia: Yeah, and to be clear, you're against doing them at the same time? Or sorry, like… keeping DevNet5 up for 48 hours.

Enrico Del Fante: I'm not against… I'm not against… I don't know what we can get from it, if this is the state we can recover, so maybe it's just a waste of time for us to try to revive that. So, but I'm… I'm… I don't feel strongly about this.

Justin Traglia: Okay. Barnabus, with this in mind, what are you thinking? I think you're the one to make the final call.

Barnabas Busa: What about other clients? What would you guys prefer?

Potuz: I think it's better for us as well to delay one or two days. We have a few PRs that could be good to review.

Justin Traglia: Is there anyone here from Lighthouse?

Daniel Knopik: Yeah, I think the internal opinion was also to wait a few days.

Justin Traglia: Okay.

Barnabas Busa: Yep. Let's aim to do, like, a relaunch in Wednesday then.

Justin Traglia: Codiffs?

Potuz: Yeah, one of the bugs that seems to be a bug, I don't know where is the bug, I don't know if it's Prysm, if it's Nimbus, if it's on the propagation, but it'd be nice to either automate it, or… or… or get a feeling as to whether clients are monitoring this, but we seem to not be getting some payloads from Nimbus. This has happened ever since Pectra. So these are payloads that are produced by Nimbus, and somehow they don't, they don't get to reach Prysm on time, and we only request them by RPC later. I have no explanation for this. It has nothing to do with the direct connection, Prysm limbus, even if we severe that connection.

Payloads should propagate over gossip? And we are, gossiping fine, we are getting payloads from everyone, but then suddenly, from… once and again, there's a payload that is produced by Nimbus that doesn't reach Prysm. So, it'd be nice to try to understand this bug, or even to see if other clients are monitoring and seeing something similar on their end.

Justin Traglia: There we go.

Enrico Del Fante: A bug that we had noticed on our site, is that… If the… nimbus, in that case, tries to reorg a payload that we've imported. We do not… we do not essentially, disseminate payloads that build on empty for the root… for the big unblock route that we've seen before. So we were rejecting those, and even downscoring peers, when we saw…

Potuz: Oh, that could be part of the explanation.

Enrico Del Fante: So, if is that case, so if the… if the payload you are not seeing are empty payloads, so building on empty. But the full version was around. That's where we introduce this, and we reject, and maybe dissemination goes down, and you don't get it on time. But you should double-check if that's the case.

Potuz: But I think Teku wasn't even live when this happened, so…

Enrico Del Fante: Okay. Okay.

Justin Traglia: Okay, thanks, guys. I think the decision was to relaunch DevNet… Glamsterdam devnet-6 on, like, Wednesday, right, Barnabus?

Barnabas Busa: Yeah, hopefully all the fix is gonna end up then in the client team's, picture branches.

Justin Traglia: Yep. Okay, let's move on to the next, section. El spec updates. I added a, A link to the test release tracker for DevNet 6. I'll share that here. And I forgot to share the link to the agenda, sorry about that. That's here. Is there someone from the ELSpec team that would like to talk about this more, or anything new? Alright. I guess not yet, just the Yale teams, please. Oh, Mario?

Mario Vega: I mean, there's not been that much update. What I can update is that we're trying to merge 837 still into our main development branch, so that's been a lot of work being done there. We're very close, and after that. I'm no for sure, we have already branches for 7, 9, and 7, And 2780, and 838, so basically the work this week's gonna be… Rebasing does on top of ADT7, branch after that one is merged. But yeah, it's… basically everything is, like, internal, refactoring and so on, so nothing that impacts other clients and teams, yeah.

Justin Traglia: Thank you. Okay, Jokan?

Jochem Brouwer: Yes, maybe one question, because I think in the current tests, there are no 8037 tests being released. Is that right, Mario?

Mario Vega: To which, releaser are you referring to?

Jochem Brouwer: DevNet… well, okay, I can say the latest, but that doesn't really help you, of course. The latest glimpse at DevNet release… Let me see… So, test spell 7.2.0.0.

Mario Vega: Oh, interesting. There should definitely be some 80% tests there. I can take a look. Maybe, maybe there's something inconsistent there, but…

Jochem Brouwer: Let me retake. Okay.

Mario Vega: Yeah, I can explain a little bit. So, A27, it is indeed merged into Devon 7, so the work that we're doing this week is basically just trying to refactor and rework into the Forks Amsterdam branch, right? So, but the tests for 837 already exists, and they should be in Baldwin 7. Releases, yeah.

Jochem Brouwer: Alright, then, maybe, maybe I didn't look good enough. Yeah, okay, thanks.

Justin Traglia: Maria? You're unmuted, but I can't hear you. Yep, no worries. We'll give you a few seconds.

Maria Silva: Hello, hello, can you hear me now?

Justin Traglia: Yep, can you hear just fine.

Maria Silva: Okay, sorry, apologies for that. So, I'm… sorry, I'm a bit confused on this test release tracker for Glamsterdam devnet-6. Are we adding new EIPs on Glamsterdam devnet-6, or was it only for DevNet 7?

Barnabas Busa: It's gonna be shifting, so now it's gonna be DevNet 7, because we're just gonna do a quick relaunch of the same spec as DevNet 5.

Maria Silva: Okay, so… so these new… release, that, Justine shared will be for Glamsterdam DevNet 7, which includes already the new EIPs, is this correct?

Mario Vega: Yeah, that's my understanding, too. Yep.

Barnabas Busa: Yep.

Maria Silva: Okay, okay, thank you.

Justin Traglia: Okay, thanks for the, thanks for the updates, guys. From the CL side, not a lot to mention. I'll call out that there is a new V5 Alpha 2 release for Beacon APIs, and there is a new consensus specs Alpha 10 release, which just includes a fixed test case, but that's still the target for DevNet 5 and DevNet 6. Does anyone else have any CL spec questions? Before we, get started with the other discussions? Okay. Alright, the first discussion item is about 76… or sorry, 7768, stable containers, led by Etan.

Etan Kissling: Yeah, he's a football.

Justin Traglia: Where's yours?

Etan Kissling: Yeah, it's actually 7688, I think there is a typo there. Oh, gosh.

Justin Traglia: Sorry.

Etan Kissling: No worries, no worries. Like, that's the one that's currently blocking the 200 megawa tests, because when there are too many deposits, they can… overflow the 8,192. SSZ limit on number of deposit requests in a block, so, back then. We found that just getting rid of these static limits is the cleanest way for forward compatibility. But at the same time, the EIP is not something that you can just do, like, in an hour or two, so it currently is only implemented fully by Nimbus and Lodestar, while… Teku, Prysm, and Lighthouse. are working on it for several weeks now, but, like, on the side, and I feel that if we keep deferring it to the next, next definet, that it never gets the attention that it needs, so… ideally, we could just get it, into, like, the DevNet 8, I guess, now that we are off by 1.

So that people have enough time, and also so that people have, Like, a clear way to prioritize it, so that we can eventually get it in, so it doesn't become perpetually stale. Yeah, definite numbers are imaginary with the relaunches and so on. I'm not sure about framing of stable containers to block higher gas limits, it's more… Yes, it's the constant capping that is blocking us, There was an idea of just bumping the constants, but that has, like, the downsides For the decentralized staking pools, like Lido or Rocket Pool, that they have to keep… doing security, council… Updates? Whenever these random things change. There are also a couple other cleanups that it unlocks, like, we have the legacy deposit syncing mechanism from

like, pre-Electra, I think, that we cannot remove, because it… We cannot remove fields in the middle today without affecting Merkalization and so on. So yeah, it's definitely the cleanest way to solve that problem. does not max length affect… like, the only thing that 7688 does is it changes the way how the hashes work. It doesn't change serialization, it doesn't change, network formats, it doesn't change database stuff. But yeah, maximum length. would affect Mercolization, and also this 7688 also does it, but only once, and that's the key. We can change it in the future, the cap, without… annoying the users anymore. But yeah, that's it from me.

Justin Traglia: Thank you, Ethan. I know my opinion is that we should wait to merge it until the DevNet is somewhat stable with just the EPBS. How are other clients feeling? Enrico?

Enrico Del Fante: Yeah, I have the same feeling, feels like we… We are struggling getting a definite that is… Stable enough to add the new stuff. So, internally, we were discussing this, and, I believe that this could… Could be a little bit distracting, while we should focus 100% of having EPBS implementation… really stable. But I definitely feel the… the good thing of this EIP, and we have this sideline implementation that we need to update. But I'm a little bit hesitant to jump into the revival of that implementation, because there are so many things to… check and fix on the PBS side.

Justin Traglia: Yep. How do other clients feel? Thank you, Amika.

Eitan Seri-Levi: Yeah, and, in my opinion, I think we would want a more stable devinet, before we would think about adding, something like stable containers on top. Still something that I think the Lighthouse team wants to add, but I think we need to solve some of the EPBS problems first.

Justin Traglia: Thanks. One question is, how do we define stable? Like, maybe… If the DevNet stays up without, Loss of finality for, like, a week or something, or… what do others think? Did you have more than 30 minutes? Oh my god.

Enrico Del Fante: Yeah, at least a weekend, being up with finalization, and… Will be enough.

Justin Traglia: Okay. Yep, somewhere between a weekend and a week. We can play it by ear, but I mean… I suppose it could go in… possibly go into DevNet 7 or DevNet 8, depending on how the numbers work out, but yeah. Etan, any last comments on this before moving on to the next discussion item?

Etan Kissling: It's one of these EIPs that either works completely or it doesn't. There is Kurtosis and static consensus vectors. If someone wants to take a stab, they don't have to actually wait for a devnet. But yeah, I agree that, prioritizing EPBS stability makes sense.

Justin Traglia: Great, thank you. Moving on to the next section, Tony wants to talk some about the options we have for deploying a deterministic factory. He has a slide to share, I'm gonna share it for him. Tony, the stage is yours.

Toni Wahrstätter: Awesome, thank you very much. I will also post a link to the slide in the chat if someone wants to follow along. Perfect. Yeah, so this is just to give you a quick summary of what has been going on so far. So this is about EAP7997, one of the remaining EAPs. We are thinking of putting on… on a dev flat, but haven't yet. And the question here is basically… there are three options, like, laid out in this slide. So option one is basically we do 7997 as is, which means we take a precompile address, or an address from the precompiled range, 0x12, and deploy, the state-of-the-art factory there. So this is what EFP7997 is proposing.

This means, existing dApps will probably not move over, because they have already mostly used Arachnid. To deploy their contracts, or create X and so on. But as… as we move on, new chains could then use this new contract that we put on this address. The second option, which is my favorite, to be honest, is… also the simplest. We basically say we take Arrakneed, which is the most commonly used, pre-deployer, it's still used these days, together with, Ratex, for example, those are the most popular ones. And we would just enshrine it into the Genesis file. This is what we do for definets going… And moving on, so this is the… exactly the same. Basically, we will deploy DevNets with that contract already being deployed, and the reason we had to do this on devnet was because 8037 increased the state gas prices, and

Arachnid, which was deployed using Nick's method, wouldn't fit into the transaction anymore, because it had a transaction gas limit of 100K, and this was too low. So, the simplest option, option two would be we just put it into the Genesis file. For mainnet, during the fork, nothing changes, because we already have it there. The contract is also deployed to almost all the chains, and all the chains are, these days, they are aware of not picking a crazy gas schedule, such that they can't deploy ArcNet, and otherwise they would just put the contract into their Genesis file. So this is nothing that affects Ethereum today, or existing L2s, because they already had to deal with this. This is more future…

A future problem. And the last option, which was an option that Jochen brought up in the Discord, was we take the 7997 contract, we deploy it already today, which means we get it onto a random address, and then we enshrine that random address in the Genesis file. It's also not… It's… the nice thing about option 2 and 3 is that they don't need any manual intervention during the fork. Because, of course, 7997 is, like. A state transition, which means during the fork, we have to artificially put the new precompile address plus its code into the block web access list, which is, of course, doable, but just, increases the complexity of 7997 a bit. So, yeah, my… Preferred option would… would be, to be honest. We just…

do, the enshrine arachnid, which would mean we have a no-op for that EIP. The only thing we do is we say arachnid is put into every Genesis file. And yeah, I would love to hear other people discussing it. I see Franco is also on the call, who is the original author of this EP, so I would also love to hear his take, or Jocham's take, and in general, the take of client teams.

Jochem Brouwer: Yeah, I… I will quickly chime in on this. So, I think that we should either do two or three. I think two is the, since this is, like, the canonical, create two-factory context already, this is also a little bit simpler. The only downside to this is these minor quirks, but I feel that these are, the 20 byte return value is a tooling problem, it can be fixed on the tooling side. The only thing that's not very nice is that the referred data, if your contract deployment fails, then a vector's contract does not forward the referred data, which might… there might be use cases where this is a problem, but I don't… I don't know. But I would actually, like, even if we would only do option 2, I would still create option 3, and also deploy this one on mainnet, because we should do this before glamp system, because, well, of course, this in Glamsterdam is going to cost a lot of more gas, to deploy it, yeah. But let's do two, I see.

Justin Traglia: Oh, yeah.

Mario Vega: Yeah, so my main concern… I love also option 2. The only concern I have that we should, like, probably, research if it's, it is actually a problem. The Arachnid deploy transaction is a synthetic transaction that contains a hard-coded gas limit. So, I… I just have… I thought I remember someone saying that this gas limit is no longer enough after 837. So, I'm not sure about this, so we should, like, see how… How it affects us or other chains that have not deployed this.

Toni Wahrstätter: So this is exactly the problem, how I stumbled across this. I wanted to deploy Arachnid on DevNet 7, and because of 8037, we already exceeded the 100K gas limit that the transaction has attached, and we cannot change it because it was created through Nick's method. So… going… moving forward from Amsterdam, one cannot deploy, the original Arachnid anymore, because the gas limit is just not high enough. So, for definites, what we do is now we enshrine it through the Genesis file. So, for example, with the next DEFNet we launch. The contract will be automatically there from the beginning. And you can just use it. And this is… this kind of mirrors what we have on… if we're on mainnet, where after the Glamsterdam fork, the Arachnid contract will also just be there.

So, yeah. It very much depends also on the gas schedule of those other chains, because this is one of the things where L2s are, yeah, leverage their freedom and change gas prices, so many L2s have already stumbled across this problem. that they couldn't deploy Arachnid, for example, and had to change the gas schedule, or had to also enshrine it into the Genesis file. And by us doing it on mainnet, we basically lay out this guarantee that every chain that wants to stay Etherum compatible, at least. from their Genesis, they will also have Arachnid deployed, to its, known address.

Justin Traglia: I'm sorry, before we continue, would you guys be interested in, doing a breakout room for this, like, right now? So, splitting out into an EL and a CL breakout room?

Toni Wahrstätter: I'm not sure if it's needed. I would love to hear from client teams. Maybe they already have an opinion, otherwise I'm open to it. But maybe we can find a quick, decision on that one.

Justin Traglia: Okay.

Francisco Giordano: Yeah, it doesn't sound controversial from what I hear, so if anyone is against it, it would be great to hear. Personally, as the EIP author, I also support option 2, I had actually considered withdrawing the EIP in favor of something like Option 2, but I think it would be very important to make it As easy as possible for new chains. to get that contract, on their chain, in the Genesis file, or however. Regarding the quirks… Yeah, I agree, they're not big issues, and it's also important to remember that As long as there is one… create two factory, guaranteed to be there. You can always deploy further, better ones. That can then themselves be guaranteed to be on every chain at the same address. So I would expect, like, this is just…

A core, simple protocol contract, sort of, and then… The better ones are built on top of it. But yes, I, I support option 2. And… yeah, hope we can do it. It's a very important application layer problem, this one.

Justin Traglia: Mario?

Mario Vega: I also support option 2. The thing is that maybe we should leave 7997, and the reasoning… is that, we have to make this… I mean, making it enshrined means that we have to at least have an EIP for it, so maybe modifying 7997 is an option? To make, I'm just seeing it from the angle of, for example, the specs. We have the system contracts, and they all refer to an EIP, so maybe it would be nice to have this enshrined contract also refer to an EIP.

Toni Wahrstätter: Right? Yeah, we have both, actually. I'm fine with both, too. So we have, actually, an EAP drafted, which we can just swap out, or we change 7997. The new ERP would be very simple. It would just say, okay, Arachnid, this is the bytecode, it will be deployed to the original arrakNet address, and on mainnet, it would be a NOAA, basically. So I'm fine with, whatever solution. I can… I can, async, double-check with you, Mario, and with Frangio, and then we can… can see what is the… Best way forward, though.

Justin Traglia: Before you go, Lucas, I think we need to decide whether or not to, like, do a breakout. chat or, timebox this. I think we need to move on to other.

Toni Wahrstätter: Yeah, it feels like if the CL side has to discuss a lot of swing stuff anyway, let's do a breakout.

Justin Traglia: Okay. I'm on board with that. Are others on board? I can't view the chat.

Barnabas Busa: Is there any other topic that would concern both the EL and CL devs?

Justin Traglia: Potentially. I'd like to very quickly mention that ACDC this week will be at 11 a.m. UTC, which is 3 hours earlier than before, and I guess there's the SSZ Engine API discussion. Marius?

Marius van der Wijden: Yes, exactly. The SSZ Engine API discussion is something that concerns both. I'm currently implementing it in Geth. I… know that Erigon also has started an implementation, if I remember correctly. There's a few changes I would like to make, a few minor changes that I would like to make to the specs. But they should be, yeah, very easy to implement. What… what can you check comments? The comments on the… on the EAP, yes, we can discuss there. On the PR, we can discuss there. from the CL side, we also have an intern starting at the… at the Ethereum Foundation who will implement it, In… most likely in Nimbus?

And maybe something else, but we would like to… yes? Tamakna?

Justin Traglia: the market.

Marius van der Wijden: Yeah. Yeah. And, so maybe, one other CL client would be really nice to also look into this. So if we have a CL client already volunteering, that would be nice.

Justin Traglia: I believe he was planning to work with Prysm and Nimbus. On the scale side. Okay, thank you, Marius. Any… anything else from anyone before we start? the breakouts.

Nico Flaig: And maybe just quickly mention I linked the EIP Still in pull request, but this would require us to have an execution or a different deposit contract. So I guess this concerns the EL a bit, but in general, I think it's pretty simple besides that from the EL side, as it's just the typical wiring in the execution requests we need to do. So besides the contract, it's mostly CR side.

Justin Traglia: Thank you. And then… sorry, who wants to lead the EL portion breakout? Maybe Tony or Mario?

Toni Wahrstätter: Yeah, if it's only about deployments, then I'm happy to do so. I don't have context on any other topic, yeah?

Maria Silva: And I can lead the 8037 topics, which triggered the other two.

Justin Traglia: Okay, great. Alright, Perry, can you… Yeah, we're gonna have a consensus one, POTUS. I'll… I'll leave that.

Parithosh Jayanthi: Yeah. One second… Okay, it should be available, if you're not able to see it, let me know and I can manually assign it.

Justin Traglia: Thank you, Perry. See you all next week.

Marius van der Wijden: What?

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