All Core Devs - Execution #132

Transcript

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

[Applause] [Music] foreign [Music] foreign

[Music] [Music] thank you

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

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

[Music] foreign [Music] [Music] foreign

[Music] [Music] [Applause] [Music] foreign to awkward devs number

Tim Beiko: 132.

um let me share the link in the agenda here a couple things today um Wonder was a Gordy issue that and I think it's still ongoing so it's worth addressing that but right after that a couple merge updates um some stuff on Kiln and there was some discussion about changing uh the random versus difficulty uh up code in eip4299 and we have the forks we have the full term kurtosis on a call as well who've been helping with testing for the merge and they'll take a couple minutes to walk through what they've been doing and and see if we can schedule a more uh in-depth testing discussion in the next couple weeks um and then uh some Shanghai stuff uh with some updates on the beacon chain

withdrawals uh and finally there was a comment about uh uh one EIP where uh we would just uh cap the amount of transaction gas to a large integer value um so I guess to get started uh on Gordy does anyone on the call have kind of an update about what's happening

got it thanks

okay yeah I think I

Tim Beiko: I don't know Micah if I if I understood your question correctly but were you asking whether the Netherland operated node was down or whether if we knew that all the affected validators were running the same

clients okay got it right

cool okay that's it though cool um yeah so

Tim Beiko: I guess we'll keep an eye on the operatives chat uh for for updates about this um yeah anyone else have anything to add on this

okay maybe inferior team could uh try it if

you can get in touch with them I think EG is on the guitar channel so maybe that could help them I mean the problem is we we

Péter Szilágyi: have all the signups on the statistics so we know what they are doing but I'm girly designers aren't really reporting so nobody knows who is online who is offline which is on which train to pick up a black box

Tomasz Stańczak: and there's less visibility I mean there's start scheduling that perhaps I don't have access directly to each signer's snapshot otherwise I'll be able

to check like who is on what branch

okay

Tim Beiko: uh there was a streaming problem and YouTube didn't get most of this audio but in short to discuss the Gordy's issue we're still investigating the issue we haven't found it um and we'll post updates in the awkward F chat then I'm sure people will share them on Twitter um apology so that I'll try to make sure that we get uh the zoom recording for

the notes so there's a full transcript even though the video uh misses part of the audio um anything else I'm Gordy okay um so next up uh merge updates um I guess first of all maybe it's sort of uh Perry going over the devnet that we launched um and what the status is there

sure um hey

Parithosh Jayanthi: so yes today we launched a new match.net march.net four it's based off

the Canon V1 specs and we've had almost all the client teams taking part I know that last night a couple more um independently were able to sync up so I think we're almost everyone has an implementation by now I've pasted a link in chat with information on where to join how to join the only tooling that doesn't work right now is Beacon chain because our Fork of Beacon chain relies on Lighthouse and yes David Lighthouse up and running but that should be fixed soon um while the node was while the network was reaching TTD we did have multiple Forks and different consensus layer

nodes did observe different um terminal block hashes even then the network resolved itself as expected and it's finalizing and working fine Michael has just written a tweet with um with what the logic is for it to resolve itself um again to reiterate there was no intervention done um this was this worked exactly as expected

Danny Ryan: did we induce the proof of work working

Parithosh Jayanthi: why do we have that Mario's computer was too fast

that's great awesome

Parithosh Jayanthi: yeah he just randomly started mining at some point and I think he was mining blocks so quickly it wasn't importing

anywhere else

excellent great chance

Tim Beiko: I guess does this give confidence about once we do this on mainnet like how long we want to wait until we consider kind of the merge complete like um because you you mentioned I think in on Twitter it took overall like it you know number of minutes for this process to happen is that like roughly what we'd be expecting on mainnet as well that after a couple minutes the fork Choice gets decided and and we we managed to finalize a block

Danny Ryan: uh in normal conditions I would expect it

even on the order of a slot or a few it sounds like because the the resolution on marius's end because he was mining blocks so fast there might have been portions in the network that were still like importing blocks and that might have been the delay there whereas that would be much more difficult to induce on mainnet

although not not

Parithosh Jayanthi: um two of the forks hit DTD with about like 58 seconds apart and the third Fork was extremely behind so the first two folks resolved themselves within a matter of a slot or two I think um and the thirds Fork was exactly like Danny said the amount of time the

north took pissing out right

and so I

Danny Ryan: mean assuming you have mainnet level participation on some Fork like I and you see finality of a proof of work block then you know so on the order of two epochs it is not only when I'd expect Forks to resolve but also when you know things have gone really well or things are chaotic

uh that's yeah that's really useful

Danny Ryan: um when we had the beacon chain launch we had like we wrote down what we expected to see and what we thought could what some of the bad things that could be

over like the course of the first minute epochs and probably doing that so that when we're watching and when others are watching we can very easily digest what's going on

um great so I guess uh uh yeah we

Tim Beiko: have the first devnet up um we've also basically merged uh both PRS for kiln V2 um I'm curious implementation wise how are clients tracking for for the V2 spec

Danny Ryan: I think I saw taku guess doing the

authentication so at least we have an implementation right

Tim Beiko: right

Marek Moraczyński: we implemented exchange transition and we are progressing with authentication but it is not full already yet

Tim Beiko: got it

yeah and uh basically we're still actually a couple PR's away from uh having uh Kiln uh in our main merge Branch uh and V2 uh all the stuff we we have PR's and we're working on that but we're not there yet got it oh sorry did someone speak up

Andrew Ashikhmin: uh yeah Monica already did yeah

I wanted to tell about Aragon so we are the same as basil we are kind of uh have a few PRS still left on killing V1 and uh V2 is in progress so I think the ETA is about two weeks

thanks that's that's helpful and Marek sorry let's just saved my update about another night so we are uh have exchange

Marek Moraczyński: transition and we are progressing with Authentication

thanks okay so

Tim Beiko: I guess

um it seems like we're probably not going to have V2 across everybody next or maybe we'll have some of them next week um do we think we want another devnet next week uh running V2 uh do we prefer to wait an extra week after that uh to give clients more time or do we you know is having another devnet next week even though there's not everybody and then maybe having like the real kill in in two or three weeks uh yeah curious what what people's references here are

the

Danny Ryan: the authentication PR is written in such a way that you can use the Old Port if you're not ready right I believe so

so in in that case I mean I would I would suggest we begin to call it V2 we'll put on the pressure to have these two done and if you're communicating on an authenticated port you know you get there soon um but I think given that there's a handful of mutations and that are complete and many of them work in progress I think calling it V2 at this point is probably a good call I also personally think even if client teams aren't involved which they probably should be uh doing some weekly builds just to kind of get a feel for it and continue practicing the transition like a call

uh Andrew someone should add

Andrew Ashikhmin: uh yeah um I have a question about the ports I think there was a discussion on Discord whether there should be a single port for the engine API or tool Port so we should have some kind of transitionary period so I I'm not certain the spec thing says that there should be two ports but then on Discord kind of it was agreed that should there be only one maybe we can do two ports in in during the transition and then disable the non-authentic authenticate authenticated what what do people think I think

Micah Zoltu: uh someone correct me is wrong

here but I think there's two separate discussions one is there's the unauthenticated port an authenticated report before the merge the unauthenticated port should be removed in every client need to make sure that happens uh separately there's a discussion of whether there should be a separate port for HTTP versus w websockets and that that one would remain either one quarter two ports through the

merch

Danny Ryan: yeah so on the former I'd say the fact that there are two ports allows us to continue to do interop testing for the next month even if people don't have authentication but that the non-authenticated port for the engine API I I would say should be deprecated prior to the main net releases I'd say must not should I can go with must as well Martin

um yeah so

Martin Holst Swende: I think the the uh whether to have one or two course for for HTTP versus well circuit I know for our for guests it was quite a hassle to to have it all work on on one porch if all clients for all El clients can handle that and that's great I think we should just do that uh some El clients have problems with that that I think we should keep them separate

Micah Zoltu: am I correct in the understanding that the problem was is that back in 2016 or whatever one gets was written originally the libraries didn't support it seamlessly but they now do so in go it's relatively easy these days

Mikhail Kalinin: I can't say exactly what the problems were back then uh Felix and Renee fixed it eventually so um we are not a targeting like this removing this board uh out in unauthenticated for it for the Kilns back so it may be the version two may be released with what we have current thing is back I think it works yeah I think we like get enough of the feedback on that that we can just release the V2 version um

on Monday Tuesday and then uh have a devnet whenever I think it's reasonable to have with this new version of the next week

Tim Beiko: that seems reasonable maybe the one thing I would say is if we can add something in the merge Readiness checklist about confirming that we've removed the unauthenticated ports before ideally like the public test Nets or the average uh it's not Kiln but like the guardian without that that's probably worth uh yeah making sure we don't forget

yeah yeah good thanks I'll do this thanks was

Tim Beiko: there anything else on the Kiln

specs that people wanted to discuss um aside from the 43.99 random upgrade thing we'll do that next but just if there's anything else before that

Mikhail Kalinin: um there will be minor updates to the stack but they can be done after V2 is released this is the strict subset of eth methods um instead of broad support of name of entire eth namespace and some minor removing these exchange transition settings one of the statements from um probably from this from the certification of the style it's a bit that's a bit misleading so it's but it's

it's not it's unsubstantial so got it it will be done

and

Danny Ryan: and to be clear the Restriction of a subset of each methods is going to just be the set that people are using um so you know that that shouldn't break any functionality right

Mikhail yeah

Mikhail Kalinin: yeah right exactly okay so and on the outside it just doesn't need to you know I I think it doesn't fit any engineering because it may be just entire evening space and we just want this to be restricted in the spec on the spec level not necessarily on the um yeah client's level layer level got it

anything else on the Kiln specs

Micah Zoltu: just a minor correction there it may require some engineering for clients because the ideally we want the chosen API endpoints the in the eighth name space that are going to be migrated over to the engine API we want to make sure they're well specified and so because there is not consistency between clients some clients may have to adjust some things in order to make them actually expect compliant

Mikhail Kalinin: um but how do we want to um to specify this methods uh do we have like uh I don't know one place where this maps are specified and we'll just say that in order to to be compliant with the spec you should implement this that's as it's described in this

document you have something like that

so we

Micah Zoltu: we do have the Json RPC spec document it is not complete and it doesn't it basically is the lowest common denominator at the moment um which means like if three different things return or three different clients return three different things the spec currently says your result will be one of these three things like you know this may be you know maybe it'll be zero maybe it'll be empty array or whatever um I do recommend we you know for the methods that we Port over we make sure we have much tighter specs um before we go live for this methods

Danny Ryan: yeah I agreed I think any any methods

that service in there are subject to we should all put put some final set of eyes and see if there's any ambiguities there

Mikhail Kalinin: yeah okay so I was just you saying that no engineer is required on the assumption that these methods that that I used are more or less unified and have the same schematics and parameters across the client

implementations

Tim Beiko: um one other I guess Json RPC uh comment or question is um I know we had discussed like adding the finalized uh kind of status to to a lot of the blocks related queries um I'm curious if any clients have

implemented that and if not what's the like Milestone by which we you know what do we want to gate based on that yeah I guess first is anyone has anyone implemented kind of the finalized Json

RPC endpoint you don't have implemented it yet and I think that's doesn't have it so yeah is that

Danny Ryan: is that an additional bull on a block or is that an additional endpoint where you can ask of a block of finalized

Tim Beiko: it's a Boolean flag so that if you return a block uh basically you you you can like get the last finalized one

um and and I think this was also uh I ideally you would also want to have the unsafe tag so this is like uh yeah um yeah

Danny Ryan: and we're working hard on um that safe unsafe algorithm to be specified and should make a decision on if and how to surface this

okay sooner or later

Tim Beiko: yeah and I think we would definitely don't need this for for kiln um but we probably want it once we Fork the public test Nets um to make sure that like you know

infrastructure providers and whatnot they're able to rely on these um yeah so that's yeah that's right what if non the non-consensus changes I think that's probably the biggest in a way um even though it's not a huge yeah yeah

Danny Ryan: additionally I think we need to make sure we write about and communicate well about confirmations and finality in this new context

yeah cool uh anything

Tim Beiko: else on kill their

respects if not um Mikhail do you want to summarize the summary about uh the random versus difficulty up code and and the changes you you're considering

Mikhail Kalinin: yeah sure um I'll try to be short and clear um okay so uh currency current proposal is to rename the help code to a difficulty upgrade to rent them um and it has some issues with this naming with this particular name because random is a bit abstract and the context and we and on the the random name we use the exact

implementation of this random um Machinery which is the Rendell currently um and of course this random up code this new random up code after the merge um Returns the right of this output that is much less possible than what what's returned by difficulty in the proof of work but anyway it's biasable and this Rendell for this rendale Machinery um using their Dell Machinery under the hood of random has some security implications using the um uh the random mix from the exactly

previous um previous block from the exact previous slot also has uh some other security implications and uh if we want to like secure random in the future so we will probably need a bit different semantics of this method we will probably need this instruction to accept slot number um and uh yeah so here we have the conflict so we we need we have this random opcode uh that doesn't accept any parameter and uh to have like a more secure random in the

future we will have uh to have another random opcode that will accept uh slot number as a parameter and uh yeah that's that's why the question

uh parameter

Mikhail Kalinin: um that's because you want uh your you want your application to use exact uh the random mix from exact slots uh to be less um to give proposers less influence power in some circumstances in the case if we use a vdf it's uh if you if we use video from a certain slot

which is not that far from the current moment um and yeah the the this is uh this is all about the future compatibility um so so yeah we we just need this slot number for some reasons and and yeah that's why um this sort of thought is to uh use the different name and Alex basically made a good suggestion so let's just use the name uh name the thing exactly what it is uh this is the last rendero uh the Randall has uh

and we can just explain the trend that has its own uh he has a visibility property uh using the last run down or pre previous Rendell uh also adds more um security implications and so forth so that's like um that's uh that's the approach I think we should take just wondering what people think about it um on the naming

Micah Zoltu: one thing to add to that is this discussion is really just about naming so it's um but the the idea here is is what we name it

is most likely what solidity is going to name the off code and that's most likely what documentation and tutorials and other gonna name it and what we want is we want to make it clear to users that this is not a good source of Randomness you should not be using this to run a lottery on chain or something like that in the future we do want to add some things that will enable those features but uh previous rendow or what whatever is not a good solution for that it is better than difficulty so it's you know iteratively better but it's still bad and so naming it just random is very likely to result in people thinking oh you've got a random number generator that is secure we can use that and that is very much not the case

Danny Ryan: the intention here was to when you have when you can

essentially give you the best Randomness and Harden it over time with other techniques so uh is the intention now to if you had a vdf to have two op codes and to have one that is Randall and one that is random or vdf random or you know what do you do or do you call it we could rename it and rename it again

yeah so yeah

Mikhail Kalinin: we could use like prev Randell we and one day we have vdfs we can and we agree that like that's true Randomness we can either use random or vdf or no yeah we could either rename it or we can introduce a separated code uh if we if

it will need to be introduced

Danny Ryan: I do think that if we do Harden this and intend to harden it we should make it clear that that's if Randomness is hardened that this op code will harden it so that applications know that if in the future there's better Randomness they get it by default here or we need to make it clear that we wouldn't because both of them yeah you might design

Mikhail Kalinin: that right then and uh one of the ways to make it hardened uh one of the like requirements is it it might not be the case but it might be the case that we will need this extra parameter so what we'll do in this case um it's not that clear so we can't have

two of those called random uh one with parameter one without it

Micah Zoltu: is there a one minute description of um the PDF solution that convinces me that it will actually be securely random

Danny Ryan: you have to not listen to the apps but you yes assume I believe in videos you type in the input of Randall into a vdf the vdf is revealed later the assumption is that an attacker cannot when they're deciding to reveal or not reveal have computed the the vbf the output of PDF um yes

and you have them revealed in the future

PDF base

Micah Zoltu: random Works in general I'm curious how you would get that all into One op code

no I I was just going to say then naively like there are many different constructions you can do with the vdf so like the idea that you would have a vdf output per slot is probably not correct you'd probably have one per per Epoch just because of the way I mean you may or may not so as I as I verbally explore the notion of just hot swapping this um you know the semantics are likely different because the the granularity is maybe not on a slot basis

Micah Zoltu: even it was on a slot basis it feels like if you're designing an application to utilize that you need to have two steps basically a vdf gives you a commit reveal where the reveal is guaranteed and but you need to do a two-step process it's not a one step just read the random generator

I

Danny Ryan: I didn't follow that I mean the commit reveal is on the beacon chain level uh and so the beacon chain would have these Rando these these vdf reveals essentially um and so if you had it on a cloud basis you could feed them into this random op code in the same way

Micah Zoltu: um right but like the at the moment we don't know the distance that you need to declare like you're you're like you're

making a bet or whatever you need to bet and then wait a certain amount of time that is longer than the fastest someone could compute a PDF right and so we don't know what that number is and so we can't start advising people on using randow and so you really can't build an app today that uses rendow that will then seamlessly switch to using the hardened vdf version in the future because like the design of those apps

Danny Ryan: yeah yeah I know I and as I as I think about it the like naive swap has a number of edge cases to Think Through I would be fine calling it pre-rand out or something like that I do think that it is important to continue forward with the inserting of this value into the difficulty parameter because almost

every um yeah every application of difficulty is bad Randomness and this is if we put a zero in there it likely breaks things yeah sure

I

Mikhail Kalinin: I just wanted to add that if we even add currently we add this Randall with the aesthetic sepsis slots as parameter it may also um increase the security for a bit so it's not only about PDFs right so this this is like the solution to support Legacy applications that utilizes difficulty at the source

of Randomness and yes the initial intentions and thanks any for the explanation was to harden it um over the time yeah but it's it has some some it might have some issues might might some issues with this

Tim Beiko: and if we do Harden it we can always rename it and I know that it's not like trivial to do but it's also not impossible given that we're literally doing it right now um yeah yeah yeah yeah that's in the spirit of like ideally moving forward on this um does anyone object prevrendo um and yeah Danny uh this is good uh I

mean I mean if if people will start thinking about what's Rendell is they will go to this pack and read about it and read security implications uh if they see uh random so it's pretty clear that no security implications needs to be readathon no no um like definition of this Machinery will need to be learned so it's just random that's also good uh in terms of you know introducing some term that is that requires some additional digging into the specs and also considering that vdfs are not happening soon uh the remainment shouldn't be like uh shouldn't induce huge complexity

okay uh we're up to one final in the pick in the chat uh do we use it underscore or not historically it seems that up codes do not have an underscore um I don't know if it breaks anything but to be on the safe side

I wouldn't put underscores on it I have no preference okay so prev Randall it is without an underscore and if

Micah Zoltu: someone has strong opinions otherwise feel free to talk to Mikhail and me in Discord

Tim Beiko: and can we like time box that like so that we basically it would be good if

like early next week when we have the Kiln V2 spec we have this merged and

like yeah yeah I'd say

Micah Zoltu: if you have strong opinions contact someone like within the next 24 hours

Danny Ryan: yeah I think I would I would assume almost anyone with a strong opinion and then has touched this at all is probably right here

okay

Tim Beiko: let's go yeah that's definitely make this final uh when we release the V2 specs for kiln pretty next week

Mikhail Kalinin: yeah sounds great

cool

um anything

Tim Beiko: else on this okay uh next up we have a gallon from kurtosis um their team have been working on doing like simulation testing for the merge uh they've been working closely with all of the the client teams um do you want to take a couple minutes to walk you through basically what you've been doing so far um and like how clients can can use what you've built

Galen Marchetti: yeah absolutely uh thanks Tim hey everyone we have been working with um with Pari and uh a bunch of the folks on the client Dev teams we our product pertosis it allows you to spin up

multi-client test Nets locally uh so kurtosis we have a layer on top of Docker and that layer encodes all the logic you need to tie the things together in a configurable way um we actually have Kevin on the line as well he's been doing a lot of the deep engineering work for this and can like dive into all the details um but the way it kind of works is you you when you run kurtosis on your own laptop you can run a local network that goes from proof of work to proof of stake with the clients that you want to have and we have some reservability tools in there you can debug uh you know when things go wrong with your particular client or connections between your

client and other clients and you can do that all in a fast iteration Loop so you have more chances to see what's going wrong um rather than you know only waiting for the next merge net when that moment happens uh and I'll pass it over to cabin for a little bit more details on that

hey votes

Kevin Today: Yeah so basically kurtosis is a tool uh actually I can just share my screen really quick

Tim Beiko: sure yeah

really good yes okay you guys seen this

Danny Ryan: yes

Kevin Today: cool cool so kratosis is a tools apply uh just uh Cloud it gets installed by a

Homebrew or whatever and the idea behind it is that you have these things called enclaves which are sort of like isolated environments where you can spin up a bunch of different services and shut them down and manipulate them and then under the covers that actually ends up as a Docker sub Network where we spin up a bunch of containers inside of the docker sub Network so you can think of it like a little Walled Garden for whatever you want so on top of kurtosis we have built what we call a cryptosis module and this is a Docker image this guy right here that runs a contained set of logic which in this case is spin up in ethereum uh ethereum Network first a el Network and Then followed by a CL Network and add a whole bunch of tools

and do like bits of validation like making sure the El nodes are mining and the CL nodes are are producing blocks and everything is is working in gravy so I actually took the time to pre-run this um before this just because it takes a little while to wait for like uh Mining and everything to go on um but you can run this locally on your machine and basically what will happen is that ketosis will go ahead and do all the Machinery necessary to create one of those enclaves um right uh here so I've created this eth2 enclave and then I fed in a bunch of parameters so every module can take in parameters you can kind of think it like a function and this will allow you to configure the actual Network that's getting started inside of kratosis so

specifically that allows you to configure the local net that is getting created so uh once that gets fed in kurtosis is going to do a whole bunch of work and you can see everything that's going on right here we're basically generating the uh El Genesis data right here where I'm going ahead and adding the one El client which in this case was Geth which comes from the specification right here uh we're waiting for guests to get going I actually um I I set a couple debugging Flags here to make this a little bit faster you'll see where that'll come in in just a second and then we we get the CL client which is going to get connected uh to the get instance and then we get some we get some debugging tools on top of this to make sure that uh to make sure our

network is is working so the first of which is forkmon so there's a fortnight instance which is uh started and connected to the network so we can see that our one techno node is right here we can see how slots are progressing we can see which

uh we're still seeing here thank you let

Kevin Today: me go ahead and change that how about now yes cool yeah so basically the module will return output just like a function you'll get back a bunch of output on Json format and then you know I can just go to this forkman URL and this is forkmon right here so

technically what this is is this is a forkmont instance that is running inside of a kurtosis Enclave which means inside of a Docker network with cryptosis orchestrating all the necessary different parts and then it is exposed to your machine on a port so you can see that I've got this ephemeral Port up here at the top and then that allows you to see how the network is going and then of course if you had a bunch of different nodes and you'd see everything going through and we also have grafana we just added this so we're checking out a couple bugs with this um so if I go to grafana we're actually going to see no data here which is one of the bugs we're trying to track down right here but if you start the network right away you'll see the beacon head slot uh creeping up and then you'll see

uh the pure count for each of the notes we think that basically there's a retention thing that we we have to fix because it seems to drop data like about a couple minutes after the network starts but uh once we fix that bug then you're gonna also have grafana showing up inside of here and you can basically do a bunch of manipulations with the kratosis network as you work with it so we have if we do princesses Enclave inspect and then the ethereum network you can see a bunch of information about the ethereum network that's inside of kurtosis uh oh one thing I forgot to mention is we actually spin up a transaction spammer thank you Marius that will constantly be sending transactions to the network just to make

sure the Network's actually doing work and then you'll see a bunch of these other services here like the CL client the El client Workman Etc and then the local Port bindings on your machine if you wanted to connect to them and make requests to them as well as manipulate them you know you can see like the discovery ports and everything like that going on and um yeah I think that's that's most of it we have a couple um I have a couple debugging tools like you can shell into a service by grabbing The Enclave ID and then like if you want to get into this guy then we could of course have a shell into the service to start messing around with it just like just like with Docker you can do grab

logs of services as they continue um and then the last thing is you can also uh dump the uh the enclaves logs and container inspect output to um to your file system which is very useful for debugging so we've seen like as people are uh debugging and find issues inside of their kurtosis Network um one you can give the Repro by just saying hey my commands my parameters that I started the module with are these which will allow say uh like if a client Dev was having a problem they could give to another client that they could be like hey you know these are the parameters I started pertussis with this is how you Repro the problem and then uh these are the logs in the container

inspect output of everything that is going on inside of the cryptosis enclave so yeah it's kind of like a a super lightning speed overview of kurtosis and the kurtosis module that we built any questions any thoughts

um can we have like some predefined scenarios like like two miners or minus separate to two different forks and you know to just test these transition stuff like a simple example of it

Kevin Today: you mean like a scenario oh yeah yeah so basically um the so so kurtosis actually has an API so

the kurtosis engine is just doing whatever you tell it to so I start the service stop the service repartition the network dump these logs Etc and modules are just packages of of instructions to their ketosis API so you could actually wrap the module in uh basically whatever you want so um maybe an easy example of this is like showing how we use our internal tests at cryptosis so I I use this CLI right this um this module uh ply here like this this module exec command in order to start this module with certain parameters right you know I just pump this Json file in but if you wanted like if you wanted to test a very specific scenario you could even just write like a go test here and then

hook up to the cryptosis engine and say hey like create me an enclave and then in this particular case you'd say execute the module to do uh whatever scenario you want actually and then that would be your uh your predefined scenario you could even run it as a unit test you could put it inside a CI does that kind of answer the question or am I missing

yeah yeah yeah yeah cool cool

Micah Zoltu: sorry if I missed this at the beginning does this support all eight clients never mind

guess ASU taku prism Etc uh so we do have eight clients I just want to make sure that they're the ones you're thinking of so we have um we have another mind we have guests we have bazoo uh we have lodestar Nimbus Lighthouse uh taku and um prism those ones you're thinking of

Micah Zoltu: I was thinking of Aragon in that list as well but uh but answer my question

no yeah we don't have Aragon right now

Tim Beiko: I guess would it be useful for trying teams to have to book like a sort of breakout room to go into this in more detail and cover potentially like some more complex scenarios um I had like one plus one in the chat but I'm curious like Beyond Basu would other teams be interested in this

um yeah I'm feeling at least a couple of the consensus there would want to as

well okay um yeah one last question is it like an ash an alternative to five words something complementary yeah yeah we did

Kevin Today: I would say we're definitely complementary to Hive so the ketosis focuses a lot on uh spinning up the network like the full Network um via Docker containers rather than doing these specific like the the mocks and making sure that um you're like really getting kind of the low level uh you can do that with kurtosis but it's like you'd have to hand craft doesn't have the tool set that Hive does to like do the um I think I have as like a network

Jitter um test if I'm not mistaken so kurtosis is more about like hey you have the full Network and what do you want to do with the full Network

oh yeah yeah it looks like you get it so it does it's like it's system testing versus hype is integration testing or this kind of expression let's see cool thank you yeah to the

Kevin Today: uh to the breakout session um we're totally happy to uh you know give folks onboarding and we can do that I mean even if folks want to do that after this meeting we can do it I schedule a date in the future as well if

that works better I'm totally happy to give a rundown and dive a little bit deeper and all the different things that you can do with

just um yeah I mean if

Tim Beiko: usually we get people to show up if we if we scheduled it um I'm actually away next week but um I don't know if maybe like one week from now like basically Friday at the same time as this call would make sense uh if I don't know if Danny or someone else can can just host it but we know that like client teams can generally attend this

this time slot that works for our side

yeah sounds good we can get some things sorry go ahead I'm just gonna say it'll

Kevin Today: be great to meet all y'all as well because I uh you've probably seen me on your discipline a new briefs on Discord and I've probably been asking all y'all different questions uh about how your client works as we've been uh setting it up in kurtosis so great to meet you in person

yeah um cool

Tim Beiko: I'll create a GitHub event a GitHub issue uh with uh just the information for the session um and I'll try to post a note also in the consensus lyrical agenda so that people that's the day before so at least we can tell that the cl teams that if they want to join uh I it's basically the day after their

bi-weekly call

perfect sounds good sweet any other thoughts questions on kurtosis okay um yeah thanks thanks out

Kevin Today: guys for coming on um and obviously for for doing all this work to help with testing the merge um next uh so Shanghai stuff uh Alex and Danny have put together an EIP to expose the beacon State Route in the evm and have uh I guess pre-eip or idea about how to use that uh to enable Beacon chain withdrawals um the video if you want to take a few

minutes to walk through kind of the current EIP and how that kind of sets the stage for for withdrawals

Alex Stokes: yeah I can do that cool so yeah at a high level uh this is for Beacon chain withdrawals and there's yeah at least two high level pieces the first one is exposing the beacon State Route uh we can kind of walk through this EIP um I might even just share my screen in a second and just kind of go through the EIP step by step um the second bit is just yeah exposing well using the stator then to consume withdrawals in some way and uh you know we can share our thoughts on what we're thinking there uh after so yeah let me share my screen and we'll

just walk through the EIP e okay can everyone see it yep so 4788 uh this EIP basically takes like the sort of simplest approach to this um several of you have already given really good feedback and I think that we're going to uh probably deviate a bit from the approach here but we could just walk clear briefly and uh even still there'll

be questions and things I'm sure someone will want to weigh in on so to get started uh yeah there's some constants that aren't uh super important you know we'll come to them as we go through this uh there's two sort of components to the CIP the first one is uh supplying the you can stay root in each execution block and you know coming into that some in some way then there's the second bit which is changing the evm so we'll start with the first bit which is putting in the block the CIP suggests to essentially put it into the omer's part of the block that essentially is is you know enforced with the merge Fork to be empty and we're just not going to use it uh you also then commit to this via the

omers hash like we do today um and then that is how you get into the block from there uh essentially with every block that you have you then have to say Okay I'm going to write this to a special storage address that we Define this EIP has this keyed by block number and uh if we just skip ahead a little bit there's uh comments by vitalik and others to basically say okay we should key this by slot number at this point I'm I'm pretty uh set on this being the better path and I'm currently working on being the EIP to to index it that way there there is some more complication this way because if there are skip slots in the beacon chain you may then have sort of an unbounded amount of work to

do to write all the state routes that have been missing from the last execution block to this one but um yeah I think there's ways around that and ultimately we don't expect too many skip slots on Main net so it should be okay um let's see I think the first thing I can ask is does anyone have any comments about uh committing to it in the block so via the omers the omers hash there's a comment either on the pr on these magicians about um using Emma's hash in this way does anyone want to discuss that right now

Danny Ryan: well I do want to say that um if you do fill in for missing slots I think we can block all of a sudden makes much more

sense than

Beacon State Route

Alex Stokes: um yeah so right yeah exactly yeah so there's also that point too so yeah this is also I wanted to discuss this is there's like a bunch of little decisions um since the state route we would also use the block route um there's some overhead there because in my opinion you mainly want to get to the state um and so then to get from the blocker to the state route it adds a couple hashes but not the end of the world

Micah Zoltu: so I can just lay out my argument for why I kind of weakly disagree with the way that Omar's hash is being used uh the it's being used that way it's basically always a list of one if I understand correctly and the reason for

that is important the ap's rationale is that it's the smallest change um because we don't change the layout of the block I'm curious for client uh consent sorry execution layer client devs is it actually significantly easier to not turn that into just a hash rather than an array of one like an rlp array of single item um if it's not actually easier in any extra client then I would prefer to do the right thing which is just include a hash there not an array of one item

Alex Stokes: there is one other bit there which is just if there's other things we'd want to change in the block moving forward then like having this flexibility with

this list of omers uh lets us do that rather than having just like you know Umar sash becomes the blocker or stay root and then that's that

yeah if it is

Micah Zoltu: it significantly easier to add items to this list versus just adding items to the the block itself like is there a meaningful difference there like I feel like in both cases you're changing the shape of the block right

Danny Ryan: are you changing the shape of the block I mean a list is a list

Micah Zoltu: uh yes but I believe the list is right so I mean what one could like I

mean this is a bit of a pedantic argument one could argue that the block is just a list of values like in a fixed order and you know whether we put an item you know in the middle or at the end doesn't really matter and again this is I'm curious from execution layer client devs perspective is this actually easier or would it be just as easy to have single

so

Péter Szilágyi: what do you mean putting a value in the middle is the same as the end so there's no rlp doesn't contain field names and it doesn't contain schema so you cannot just put anything in the middle

right so

Micah Zoltu: I guess the question is in the future so let's say we we use the Omar's like proposed here so it's going to be

an ROP list of items and at the moment that we'll have one item and then later we've got something we want to add to the execution block header is it easier to add it to that rlp list of things that we currently call omers or is it just as easy to just put another item on the end of the block like are those equally difficult

Péter Szilágyi: I would say putting it at the end at the end of The Block is significantly simpler because you can just extend the block so you can just interpret that hey there's one more item we know what the type is ETC in the overs well currently is a hash what happens if you want to put 33 bytes well you cannot because it's typed that every item is 32 bytes so the type kind of restricts you as to

what you can put in there

a field instead of messing with this almost item from

Martin Holst Swende: from the client perspective uh it's also the fact that if we add it as an extra item in the header then the raw data makes it distinguishable what type it is if we just without any further context if we just put it as a hash where there previously were hashes it will not be distinguishable from the previous step um from other perspectives though if I

mean we've talked about earlier that if for example a header is verified on chain and then if there are such cases then that will break if we modify the structure of a header and I think that has been like a governing Port previously I don't know if we could care about that

Micah Zoltu: my feeling on that is that eventually I suspect eventually we're going to have to break that you know pseudo-promise that people think was made um I think there is value and delaying how long it is until we break that promise or lack of Promise whatever or that uh

assumption uh but I do think that we're gonna eventually have to break it

Danny Ryan: this is the Assumption of the shape of the letter hasn't won't change

Micah Zoltu: yeah like so far the shape of the header is I think never changed right

where did where did base B go oh

Micah Zoltu: actually you're right we did just break that didn't we okay yeah I'm okay to change the Blockhead or straight then

Danny Ryan: I was actually operating on assumption too and then I realized that it basically changed it

right 100 confirmed yes and the baseball is just offended to the end

Péter Szilágyi: so that's the thing as long as you're

defending stuff you it's easy anything in the middle it gets super nice

Tim Beiko: right so we could live with the empty homers

Fields Forever and just a pen stuff and it's a bit nasty

well the empty almost feels such it's essentially one bite right right yeah yeah and

Danny Ryan: we could take over the omers hash because that's an option other than a pinned yeah but that isn't

a you know an abusive semantics and my name is one issue yeah also domer's

Micah Zoltu: hash does take 32 bytes so that would be nice to not have that just be wasted

Mikhail Kalinin: yeah it does

Danny Ryan: compress well oh wait it's not a zero it emerge isn't

it

no it's not to

Mikhail Kalinin: it's like the hash of the empty list

right [Music] yeah so my vote

Micah Zoltu: my vote then is to use the omers hash for this for the beacon State Route like use that position in the block header for almost for Beacon state route or uh Beacon blocker and just leave the omers and empty rlp list maybe at some point in the future if we need a list of things we can use the omers for that I agree barring you know an engineering reason not to

if we use a mustache then we should draw bombers at all I mean if we use Omar's dashboard we can

state or we can block route then we should drop this Commerce list from the beginning sorry from the execution block body or or should I

Tim Beiko: drop you mean put a zero rather than the rlp encoded empty list or by dropjiming change the block format

Micah Zoltu: this is what Peter was getting at is that changing the shape of existing things is much more dangerous than just adding things on the end or replacing things with similarly shaped stuff so having an RL empty list is one byte so it's not too bad and uh it's someone who's currently like reading through and parsing what they know um doesn't get hurt by that like they'll just find an empty list which is already the case in many blocks whereas if we

change that to like zero or something then someone who's parsing it now is expecting an empty list and they're getting zero which doesn't make sense in their parser crashes or breaks or whatever and so I think we should keep keep owners there maybe we rename it to unused or whatever omer's hash would become the beacon state route or beacon block route um in terms of naming and that's the position that that would go in

Alex Stokes: yeah I think what Micah said sounds good just after hearing all the feedback uh does anyone disagree with that

Péter Szilágyi: uh can I have a weird question

Tim Beiko: yes

let me just I

Péter Szilágyi: I'm curious I just want to

check at it okay the uncle's homers where are they stored I mean they're not part of the header and there is no notion of a block rot format there's no such thing it's not like that sense for random block

you mean where this sword right now

Péter Szilágyi: no I mean I know so I'm curious what where within the context of the CIP so it says that omers are stored in the block body but it's not that's not a consensus thing so you have the block headers which has a consensus format you have the owners which is just headers a list of headers

and you have the transactions which is the transactions but there's no these are completely these are three things stored for Less separately

aren't they

Micah Zoltu: yeah you're just saying like the way this is worded doesn't quite align with a current state of the world

Danny Ryan: yeah that's a mistake

Péter Szilágyi: So when you say you want to replace homers with some other content owners are kind of dangling things so it's it's not a field somewhere that you just

replace or reinterpret yeah so

Micah Zoltu: we're just putting a hash into the block header somewhere yeah nothing

else is going in what's that

Péter Szilágyi: yeah I was just saying that that is the warmer's hash so this for example it's actually the middle of the screen there's a number one uh entry set the value of former fields in the block there's no Commerce Fields because there's no clock there's no notion of

blocking methods oh I think that

Micah Zoltu: I think that means in the block header because the block header does have an rlp list of um header hashes right or

almost header headers and then almost I'm not in the header or only almost hash but not today no as you're saying as you're saying yeah I I follow now sorry

um I

Danny Ryan: I'm not sure I follow the omer's list is in the block somewhere correct

hashes in the block so how do you that would be the blood body contains in

Martin Holst Swende: two lists a list of transactions and the list of headers

Danny Ryan: okay okay so yeah but but you can put anything in that list correct

but it's not

Péter Szilágyi: um so the block money is not a consensus struck it's just defined as something on the East network but you could Define it

in arbitrary different ways un understood

Danny Ryan: understood you could still take over that and utilize it for something else if especially if you're committing to it in the in the hash in the

head why

Martin Holst Swende: why do you need to have that's something on the side

Danny Ryan: I'm not I didn't do anymore the idea was if there's this place that has a commitment in the header and we might want to grow the things that we want to shove in there this is a place that could be used

Micah Zoltu: but I'm not claiming anymore that that's a good place to be used yeah if I understand Peters and Martin's argument here this is basically just another argument saying we should put it

in the omer's hash because it will let us drop um the network traffic of omers entirely like we just simply don't need to do that traffic like pass that around at all and so we

can simplified Network layer but even now you don't do it so there's no if there's no bombers then you don't transfer anything good not even an empty list no we I mean

Martin Holst Swende: we shortcut we see that there's an empty list but only require a network about it

absolutely interesting okay if you do the full thing uh no actually no gas doesn't require so again just

Péter Szilágyi: checks it on the piano the viewers hashes the hash of the empty

list or the empty whatever charm or country then we don't request it so Gap doesn't do any network traffics the only only thing that costs for death is one byte per block in the database storing the empty Commerce list but again that would be a lot more painful to reinterpret and hack around

than to just extend this differently yeah but

Martin Holst Swende: so if we wanted to suddenly support swap the actual current header list which we call the

the Homeland to some other kind of struct that would be a big pain in the earth downloader um right Peter

Péter Szilágyi: yes with a different type that's very problematic so you're saying that we should something anywhere any change so you can change stuff as long as it's kind of keeps the same shape the same number of bytes you can reinterpret Fields but once you change the type of the field everything goes to I mean it just blows up and in general

so if

that one

Micah Zoltu: so if we put the beacon State Route in the omer's hash field of the header is that going to cause a whole bunch of problems um because you're now going to see that that is not the hash of the empty list and then you're going to try to query for omers or something or is that relatively easy to have a change that happens

Péter Szilágyi: it's time to hard for us I can just say that okay it's hard for Block about block number X the almost hash is interpreted differently that's fine

Micah Zoltu: okay

Péter Szilágyi: it's just uh in general yeah things every single Library code that people have written might be might

get screwing because so for example one really nice example is that in Click I reinterpreted a couple of the fields for example I reinterpreted the minor fields to mean some signer voting thing and I don't know five years passed or how much and people are still saying that oh why is the minor field one zero how can I get the minor so it's even five minutes down the line it's it's causing problems and okay obviously click is relatively minor compared to main activity stuff but uh [Music] during interpreting something different as long as we can just add it's

definitely better if we feel we must leave the almost hash is consuming too much which I agree we could maybe just add a specification change to to allow that field to be zero

like to and it should be interrupted to zero and the same way as if it were just the empty hash or the hash

Micah Zoltu: I feel like that would cause more problems than

but what is

Martin Holst Swende: trying to send the omers on the side instead of just putting them in there I mean

that stay true I mean

Micah Zoltu: it sounds like that's the direction we're heading yeah we're going

to put them in the header

Danny Ryan: definitely very convinced that the abuse of the omers list does not bias anything except complexity

yeah uh so so that's why I was saying so Peter uh would you would you

Micah Zoltu: do you believe that the complexity of replacing the omers the future complexity and you know problems down the road of replacing the omer's hash with the beacon State Route is worth the cost of having those 32 bytes extra sitting there doing nothing

Péter Szilágyi: in my opinion reinterpreting the Homer's cache is a

huge pain in the ass it's definitely not worth it and if we think that that 32 bytes wasted is a problem then we can just allow it almost touch to be tempting because that that way extending fixing the code to consider the empty owners are the same thing as the hash of the empty thing is very simple so if we want to optimize out those study device that can be done much more simply without reinterpreting the most Dash and for the state route I just

be considered just dump it as an extra built around the existing fields yeah so my

Micah Zoltu: I'm going to push back a little bit

there my my experience with like decoding a block header is the opposite fits having a thing that's 32 bytes in that spot would be relatively easy change whereas making it so what was previously a fixed length field is now not a fixed length field and significant complexity um this is partially because like the way I was doing block header decoding because I only needed like two values from the header is I would just like skip you know forward you know this many bytes into the header and then read the thing that was at that location and so if we're starting to change the length of items in the header it moves things around a lot

there's also yeah

Martin Holst Swende: so you can skip by bites you know during an RRP instead of

unless a very specific circumstances normally you have to skip by you know by index so you go to the next item next item in the

list

Micah Zoltu: yeah so for after the fixed length so if I remember correct it's been a while I'll step up to the header but remember correctly the first like n items are fixed length then you have some variables

Martin Holst Swende: well the kind of want to fix length one uh they kind of are uh but they don't have to be because if the header were to be extremely extremely large then the initial length of the header would be more would be consumed yeah so so yes in practice you're right you can pick up the couple of first Fields statically an absolute addressing

but it's not like the robust way to do it

Micah Zoltu: the first few bites to get that length field off because that is dynamic and then I would fix length jump from there uh some distance in and then I would like you know read some read the length of the next one and then skip that many ahead read the last the next one yeah and once I got back to some static Fields again I could jump

yeah big blocks away to do it which has worked uh but it's not the robust way to do it

Micah Zoltu: uh yes but the hacky way to do it is what you do in solidity because you have gas

yeah oh that's true yeah

Alex Stokes: okay so I think we want to jump to the

next topic uh but just before that it sounds like what I'm hearing is that we went to append the state route to the header as a new field and leave the owners alone

Micah Zoltu: I would like to discuss that more but it can be out of this call um but yes another option sounds like or either replace the omers hash with the beacon State Road or append the estate route to the end um I would like a little more discussion and I'd like to but I don't want to consume this call

right

Tim Beiko: any other comments on that

I guess

Danny Ryan: um I don't know uh Danny or Alex I can get a click on this one the um for a while

we were thinking that the path to do withdrawals was first of all you have this uh route to consume proofs against from uh withdrawals of community accumulator and you would consume withdrawal receipts to get the eth back on the execution layer um this would involve a pre-compile in our thoughts and would involve um a stateful pre-compile because you need you know something like a bit field to say you've consumed receipts so they can't be consumed before um and given that there are not stateful pre-compiles right now and given that there is an option an opportunity to pull uh some of the development and verification and testing work out of client team development um we're much more interested in

pursuing a withdrawal contract um the withdrawal contract being able to call this op code from that we've been discussing about the uh the beacon block reader Beacon State Route taking a Merkle branch and taking a withdrawal receipt that consume that you know you prove and then consume the receipt and it stores in its storage whether it's been consumed or not this would be one function withdrawal and has one interesting complexity to discuss uh ultimately it needs to in the execution layer be able to send eth that was uh previously deposited and uh issued on the beacon chain this would be a this is a

requisite for a pre-compiled version of it as well uh but it looks a little bit more funny coming from a contract there's two options one the special contract the special function can essentially pull from zero and send eth that is validated as in these withdrawal seats the other would be to at a hard Fork dump seemingly infinite eth into uh this contract I think that is the most simple version but then you have some accounting issues because you have this contract that has you know 10 to the 30th youth in it um I do I I think that we can we're going to put something together and we can discuss this a bit more Micah um I think

there is massive gain to put this in a contract I think it has a nice symmetry with the deposit contract and it means that it can be totally parallelized with all of the infinite things that we want to do with in in the coming couple of hard Forks because it is an independent step they can write the contract Senator said they can verify the contract and send it to set they can audit and test it um but anyway let's talk about it soon

Mikhail Kalinin: um one small thing yeah it does mean that the user will have to submit the transaction to get their friends withdrawal right

Danny Ryan: sorry what was the question

um the

Mikhail Kalinin: user will need to submit the

transaction regular transaction yeah to to get the

offense with your own

Danny Ryan: yes and um that is kind of a requisite you know you have Push versus pull debate here but because people have uh smart contracts that can are expected to receive eth um I think it is most best to be able to do that in a normal contract that has a normal transaction that has to consume gas but let's uh let's move on I would say and we'll put a firmer proposal together very soon

so it and yeah thanks for sharing and

um Alex uh you wanted to discuss eip4803 which limits the transaction gas to um to two to the 63 minus one yeah yeah

Alex Beregszaszi: so this is uh similar to another EIP we had discussed half a year ago uh setting unlimited announce um and on that all could have um also kind of agreed to uh do multiple smaller eips for other fields um because initially we had um quite large EIT 1985 which tried to set advance to every single field in the

transaction and also to a lot of uh it's fractions in EDM instead of that we pulled out smaller changes so the nodes limit was won from last year and this one is only concerned about the gas limits filled in the transaction and this proposed limit of uh two to the 63 minus one um can be applied retroactively because [Music] um uh due to how the adjustment field is validated currently there never has been a possibility to have arbitrary large limits um so this doesn't need an actual

hardboard um there's one added benefit well okay the main benefit is that of course this field is now 64-bits calculations are much nicer and in fact most of the clients already do this implicitly and the reason we proposed Six Degrees of course to 64 is to have a space for assignment AKA this number can be maintained as a sign number and checking whether something run out of gas is a simple check against is it is the the limit less than zero um an added benefit next to this is we could actually get rid of the call

depth limit um there's an explanation uh why on the discussion URL um but lastly there's also a proposal today did not do two to the 63 but whether to the 31 because in that case this number could be that the customer could be a regular number in JavaScript as well

um so

Micah Zoltu: I think that's that's essentially I believe the 2-31 also gives us some benefit um with regards to stack depth doesn't it wasn't there something brought up by

the celebrity

Alex Beregszaszi: yeah I I need to run the calculations again but we run it with 63. um I mean with the the 100th gas minimum cost for any call I think even the 21 has the same effect on the call that but I'm not entirely sure

okay uh Andrew yeah I think uh well Aragon and I think Geth already implement the hip 4803 so uh that would be a codification of a de facto practice foreign I guess yeah

Tim Beiko: do any client teams have an objection with this

okay does it make sense to do like last time to just uh move it to like last call and then check in a couple weeks um oh it's still a draft so I can see the movie the review before then move it the last call but then um check in a couple calls um what if if clienties have implemented it then move it the final um and we can also add it to this spec I think uh Alex you actually added um the other EIP that we use to cap uh sorry what was the other one um I'm lucky on the number uh anyway sorry yeah I forgot but we we did cap something else uh recently and and kind of retroactively uh applied it from

Genesis and I think you added that to the execution specs Alex so I think we should probably at this at the same place and move it to review and then move it to final when uh we we have uh teams that have implemented it

Alex Beregszaszi: um in in these specs actually um it wasn't just a nonce I mean in the execution specs people but they check against um uh eoa

Tim Beiko: oh right

Alex Beregszaszi: yes yes yes yes that's that also is a similar case um now I think this this 63 bits that is already implemented practically in every every client um but I guess Micah if you want to

fight for the 31 bits then yeah you you have to pick it up

Micah Zoltu: I was going to ask if anyone is strongly against 31 um bits if not I can just debate with Alex out of band and we will just choose whichever one the two of us agree to

uh I am

Andrew Ashikhmin: against it because it's already implemented as 33 bits so why re-implement it

currently in Geth and Aragon it's 64 bits or 63 but -1 So currently it's the maximum is as in the Eep it's 2 to the 63-1 both in guess and Aragon so I'd I would rather leave it as is

cool

Tim Beiko: um we're at time um but I saw that Gordy is back up I don't know if Thomas you have any quick comments you wanted to share or anyone else about Gordy

sorry I was searching

Tomasz Stańczak: the window it was minimized um the for now I can celebrate his back up I see that uh element node key was the first one signing after the break so I'm just need to confirm with Manic and Montage whether it was the note that

we are rethinking or we just move the key to somewhere else while the other validators are coming back as well and we'll uh we'll just recompost more time we have already scheduled uh Monday call to check off the alerting and the knob be here

cool thanks

Tim Beiko: for sharing anything else anyone wanted to cover before we go cool thank you very much everyone and I see you in two weeks

thanks everyone thank you bye-bye [Music]

foreign [Music] [Music] [Music] foreign

[Music] foreign [Music] [Music]

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

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

[Music] [Music] [Music] [Music] [Music]

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

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