Post-Quantum Interop Call #18

Transcript

So, look like some interop was achieved over the weekend, which is very cool. Exciting to hear. Maybe we could start off with uh client updates and get a little update on where we're at with things. Um, yeah, Zam team, you want to start? Yeah, hi Will. Thanks uh for giving the mic. Uh so yes uh we interop over the weekend. So we re qine and lantern right so we all all were able to achieve devnet one I'm not sure whether the ones that uh that we pushed on top

of that for example ssz signatures and uh changing a bit of format for uh uh for the valid data manifest so for uh so basically hash sig uh cli uh so apart from that uh I think uh all the clients are on the same page and uh we can basically plan on a long running DevNet maybe this week and we can start working for DevNet 2. >> Awesome. Thanks. Uh Re >> Yeah. So uh the past week was mostly

about definite one um interrop. So congratulations everyone um all the teams for for achieving that. Um I personally like the the 247 like fixing the the devet one issues basically like across all time zones. So that was fun. Um and apart from that u we also the past week we full fully integrated the fork choice um test vectors. um they're all passing without having to do any like um fix to the logic. So uh that's great. Um we are going to be doing uh the integration for the state transition um test vectors um coming up next. Um I'm also personally trying to scale up the validators on a single machine and

see how many how many validators we can we can actually uh afford. um see how like the the PQ signatures are are actually taking up the like CPU and and memory and other hardware resources. Uh but obviously like I'm not testing the networking because it's a single machine. Um which um it's an open question right now. But yeah, that's that's update for from for me. >> Thanks. Um Lantern. >> Yep. Hi everyone. Thanks Phil. Um so yeah um this week uh submitted the PR to lean quick start for adding lantern into the client mix. Um based on my local

testing um like the chain was able to finalize and justify uh when trying to interrupt with other clients for dem. Um so I really appreciate the Zam team for merging that. Um, I did notice that uh when when you basically run lantern uh for like 5 or 10 minutes uh sometimes it will just end up disconnecting uh with uh Ze. Um so I'm just basically trying to investigate why that is happening. Uh but connections seems uh stable with the other clients. Um and uh I guess um at the moment uh when you run lean quick start it will basically clone

the repo and then as well as the git sub modules and then build a docker image. So uh I'm just basically uh trying to uh set up a workflow where it builds a docker image uh that can run on multiple platforms um uh rather than having to clone the repo every time. But um yeah, I'm basically just investigating these uh small little um like small little uh cleanups uh to add. Um but yep, and as well as I'll be uh looking at adding support for DevNet 2 specs um as a next step. Um but yep, that's my update.

Thanks. >> Thanks, Mayor. Uh clean Yep. Uh hey everyone. Uh yeah I think as uh yeah most of uh yeah as was reported yeah we achieved the interrop with others uh during the past week. Uh um besides that uh yeah once we achieved this uh also started doing some additional work for example like uh yeah we also looked here is kind of from networking perspective like uh how many nodes we can support in our network uh and for that purpose we a little bit

updated also clean so that we because it's it's kind of very uh it's a bit inconvenient with existing signatures to kind of generate with thousand signatures for example. So we just uh created a mode in clean where we can basically use fake signatures not real ones but still other than that they are the net one uh compatible uh from the structure perspective from the well from everything else. Um so yeah basically and after that yeah we started doing some digging uh in shadow uh we were able to kind of spin up a network of 128 nodes. The simulation is a bit slow. Um

uh yeah just writing some small Python scripts to kind of just create some CDF graphics like how block propagation is working, vote propagation is working and uh yeah everything like that. Um yes uh besides that the editor there was some not very noticeable but significant work from uh yeah docker uh image perspective. So yeah, we kind of a bit uh simplified the process so that it's actually even able to uh create uh uh all the images just using uh yeah uh GitHub just default free GitHub runners.

Um so yeah uh and yeah I believe that's all. Yeah, maybe I missed something. So yeah, that's all from our >> Great. Thanks, Camille. Um, anyone from Lighthouse looking around Lighthouse or Grand? Okay. Um, cool. That might be it for client updates.

I I see there's a a number of discussion topics in the comments uh below. Uh I know that there's sort of a focus maybe on metrics. We've got two open uh PRs waiting to be merged. I believe u lean metrics PR six and seven. Um maybe we could talk about those right now. I don't know Katcha or O I believe you added these comments. >> Uh yes. Hello everyone. Uh so I'm happy that metrics are in progress and in work and uh the clients started to use the dashboard. So here is uh where we need to discuss how we are going to follow um

the same JSON file because um when clients have different graphana versions um we may have some differences between uh the dashboards. uh even small uh versions like um for example 0.1 or 0 may give u differences in the JSON file because graphana often changes a little bit something you know it it's not an issue for me to um to merge uh these PRs uh just to inform you that it might happen uh and you will

see you can see small differences. Probably we can agree on one graphana version uh and update our versions for consistency. Currently uh we may discuss in the chat or here. Um this is regarding um the dashboard itself. I would like to know who uh from which clients already use Graphana dashboard um and JSON file and which are not yet. So I know that dream actively uses it. Maybe any other clients.

Uh if not that's okay. Just uh join us. feel free to join us as well. So um there is an open PR about the new metrics signatures. Uh I don't know if I know what's here. So probably we can discuss do we need a signature by size and to hear other opinions um on the dashboard. Yeah, I I can I can uh give an overview about the number six. Um so it's pretty straightforward. Um so we are only signing attestation right now. Um and the metrics I proposed there is just basically measure the the attestation

signing time and attestation verification time. Um yeah so just just bringing this forward um I guess like it's it's straightforward. So unless there is any red flags, any comments, then I'll I'll yeah I I propose merging this the PR. Um and regarding the block size, yeah, like I think Camille already mentioned that like the signature size is is fixed. So I think we don't need to measure the the size exactly. But um there remains like the question about like the throughput especially like with with like um compression.

um maybe we want to measure that but I I'm not so sure if that's actually out of scope of the like the the metrics that we are forming right now because that's that's at the maybe that's at the the networking layer rather than like the application. So I'm not sure I'm not so sure what's what how to measure that and and yeah the tools that we need to use. Uh so regarding the uh PR6 uh for me it looks good if we are not going to add any other metrics uh we can merge it um if there are no any other additions to it. Uh regarding the throughput um it's kind of a networking layer. Um what we can do now we can try to measure the

gossip sub messages uh like byte size of gossip sub messages inbound and outbound uh but we need to take into consideration duplicated uh messages as well. Um probably gender you know about it a lot. Yeah, I think it's a good idea to start I think it's a good idea to start measuring u gossup sizes basically increment them and that will definitely give us the bandwidth consumption uh in the graphana if you do the rate of that so I think it's a good idea so we should do that apart from from that we should start

integrating uh eth panda ops uh uh tool I mean which basically sort of observes and collects all the metrics that at what time did that all of the nodes in the uh in the network they got the block and what was so all these kind of you know global network level metrics so I think we can start looking at at that because now it's the time basically we need to uh observe what is happening on network level and then optimize accordingly >> you mean z right uh I can connect with Barnabas and uh yeah ask how to do that better

because probably for this uh they need um I guess like um running nodes like on the on the permanent basis. So they need to run the nodes. So not only locally but >> so basically I think they would just have it. So they would have a collector or you know whatever is there collecting and processing engine as a service most likely and we can sort of deploy it and uh then all the nodes uh I mean uh I can also focus on anible integration so that we can start distributing the nodes truly in quick start and uh uh and basically not run not just run it

locally and start having an idea of how the network uh will start looking like and while we are doing that we can uh also start the Zato instance which can uh uh collect the data from all of the nodes and push it into the data pipeline. So yeah uh we should start looking at that and in the meantime we can also so there is already uh anible PR uh I just need to uh finalize it. I have taken uh I have had quite uh three four uh in uh uh three four uh reviews for it. But uh I need to sort of uh finalize my review and sort of merge it. But I think we are

at a point where we can start looking and start distributing the nodes on the network and start observing metrics networkwide. And uh I'm going to add the PR with metrics flag uh because uh currently I added uh manually. So I correct uh the command which launches every client because some clients have this metric flat specifically. Uh so this is how I see the clients. uh ju just a quick question about to be gender. Uh so if pand ops team should use link quick start right for running the nodes

>> I think we need to sort of depend on eth panda ops basically this is something we can ourselves do it uh because I don't think they have time as well so we we can take their help in integrating it uh but when we are sort of doing interrupts we can ourselves uh u you uh run the infrastructure we just need uh machines which we can procure from them and uh at some point where things are stable so that we don't waste their time then basically we can start offloading things to them because at this point I think uh they would get frustrated if uh there are issues that are coming up and we are not at that point where we can

basically hand it off to someone else to just run it. Should we just pin uh varnabus in in the PQ interrupt chat and discuss this topic or maybe in the discord just for everyone to see >> what what what exactly is the issue that uh we want to discuss Zato integration or to running uh the devet as well >> those both like running is the most most important Sure. >> Right. Uh okay. So we can ask him, we can start involving him. I think he was already involved from the beginning. So

he has a good amount of context. >> Uh we just need to bring him up to speed and but before that we need to make sure that our infrastructure is stable. uh because for example you know uh not all so I tried running all the clients and as Mahir mentioned that there was a connection disconnection issue so we need to sort of cover up with that also we need to come to a point where basically we are able to restart the clients and uh uh that is while while the network is running so basically we need to get into a long network running mode from a devet mode uh where basically each time we have an issue we

restart it to recheck it. So so we need to come to that point and uh once we are at that point I think that is a point where we can start involving Barnabas but we can uh we can start to keep him in loop as of now. So yeah I'll drop him the message regarding about the issues. >> Uh that makes sense. Uh Camille want to add something? Yeah, just when you were discussing networking metrics, uh I believe the simplest thing that we can do is uh just simply using something like node exporter to just simply check uh well things like how many uh uh incoming or outcoming bytes coming and uh incoming yeah basically from from and to uh the

node. Um that way we don't need to uh even create any metrics uh because this would be uh yeah to add met things like I don't know count uh like things like duplicate in gossip sub or how many bytes we consume per topic in gossip sub we would need to we might even need to make some changes on the liptop level um yeah which is probably okay but yeah I'm not aware of any efforts of kind of creating any unified matrix on the PTP level uh so the yeah so just what I'm saying is the

simplest thing is just use node exporter that way we don't even need to introduce any metric on our client level yeah we can just do this uh yeah using some external tool um effects >> we can we can start from this uh just from my experience with working with CL teams uh anyway everyone needs these bandwidth measuring uh throughput measuring uh so probably we'll come to it later because uh it's like a bottleneck always so and they want to observe it um we can start from from your solution thank you another metric I would like to

quickly discuss is just the validators count. So my original idea was uh to know how many validators attached to every node running and um yesterday we discuss it with rim team uh because they did like uh the whole number of validators and for me it looks like it makes sense to have both because currently for example we don't have lantern on the dashboard so the total number of validators is kind of incorrect.

So we may have both. We may see the total number and uh the number for every node. Uh how do you think what are your thoughts on this? >> Yep. From from our side uh we do actually implement um all the lean metrics that are um in the main branch of lean metrics repo. Uh we um I think like I guess uh we just need more testing done to make sure those values are correctly incrementing. Um and I do believe like we have a valid count uh metric as well in that. Um but yeah we from our side we just need more testing

done uh to make sure those values are currently reflected. >> Yeah. >> Yeah, that sounds great. But uh anyways like it means that um we will lose validators if any other unknown let's say unknown client will join. Uh so we we shouldn't rely only uh on the nodes like validators attached to nodes which we know. So the total number of validators I guess also is a good metric to have.

So total number of validators is part of uh configuration and Genesis state as of now we don't have deposits and withdrawals. So it is going to be a fixed number doesn't matter whether you know a new >> client joins in or not. So as such uh I mean it's fixed but we can add it. I mean it's sort of [snorts] no-brainer as well. So >> so probably >> completeness of dashboard we can just add it. >> Yeah. So probably I will just keep it in mind. So whenever we will have withdrawals and uh etc on the deposit side so probably we will just update this part. Right.

>> Right. uh but any deposit and withdrawal mechanism is going to come very very late when basically we are going to get hard fork ready and basically say that we want to rebase on u beacon consensus and then hard fork because till that point uh I mean unless uh it is uh we want to we want to test some feature in lean consensus uh I don't think that basically you know uh deposits and withdrawals is something that we will focus on. >> Mhm.

>> But that might change depending upon what kind of feature we want to test test on lean consensus. >> Uh is this metric currently important on this uh on this level? Because uh what I can see with this metric is just how many I don't know nodes clients. It's just easy to monitor u how many clients I have on the dashboard. So we can add uh I mean it's a no-brainer. So we can add total count which is basically just picking from state and posting it uh to the Prometheus and uh we can also add attach

the nodes attached to data. So both of these these things are pretty straightforward and sort of no-brainer and uh we can just add it. >> Okay. Okay, thanks. We'll we'll add a PR for this. Um, yeah, I guess that's that's it from the metric site. If anyone wants to add something, uh, my comments to Zim team are in the Zoom chat. So, please take a look into it. And >> thanks, Kaja.

>> Yeah. So uh if you're >> if you're referring about the latest comment that you messaged in the channel, I think uh the code has moved beyond that and uh basically we can talk over there I guess and resolve it. >> Uh it's just uh I I checked the uh today's pool. Uh yeah, I will double check but yeah, I pulled today so it's it's still there. So, okay, let's just discuss it in the chat in the Zoom chat.

>> Great. Um, we've got a discussion topic focused on DevNet 2 and DevNet 3. I want to queue up. Before we do that, is there anything that people want to say uh I guess in retro or in terms of like finalizing DevNet one efforts? And thanks again O for creating that high level design doc. I'm now linking I'm going to try to track all these in this ongoing issue. So that's very helpful.

Just want to add that we still need to run it long enough when once basically Mir and Zim connection issues are figured out so that we can run all the clients maybe for a day and see everything is going good and then basically close out this issue in the meantime we already can start working on net 2. >> Awesome. Thankser. Um, when do you anticipate that will be able to take place?

>> Uh, so I'll basically have to touch the touch back with Mahir on this and uh let's try this week I guess. >> Yep. Um, and also I think uh I I would expect that if it takes longer it wouldn't be a blocker because like the connections are stable with ream uh and clean. So um but yeah, I'm just trying the best to investigate it. It's most likely an issue on the quick side. Um like the quick connection it ends up the clients basically send up ping frames.

So, one of the streams probably just um does like stops sending a ping frame and then the connection times out. So, yeah. Um I should probably reach out uh in a day or two. Um yep. >> Yeah. I I think uh uh so basically the devet was progressing with all the clients because as Mahir mentioned basically even with uh culin and ze not talking the network was going on fine uh justification and finalization was also happening so that way network wise it was good uh I'm not sure whether we have tracked or block

met uh block metric and that is something that we should start tracking when such a condition is happening and uh maybe you know if all the blocks are being processed by everyone. Great. Um so Colby I'm going to drop your comment there. I think this would be worth moving on to. So basically um suggesting that DevNet 2 single layer PQ signature aggregation and DevNet 3 recursive signature aggregation feel blocked uh based on some research uh

that's still ongoing. you had some maybe we could like sanity check that uh idea, see what we can do to get it unblocked. And then you had some ideas for other features that could be uh I guess uh focused on in incremental in between uh devets. Is there anything that you want to say about the comment to kind of tee up this conversation? >> Uh sure. Uh I can say some quick. So uh I think uh single layer like PQ signature aggregation and uh recursive PQ signature aggregation. I guess we're relying on if I believe like the lean VM is ready or not. I'm not sure if it's

ready or not. But if it isn't ready and if there's like still some like research or like breakthroughs we need to do. Uh I think there's still a lot of work we need to do to make like lean clients like production ready. Uh, I guess like there's definitely going to be like some features from the beacon chain which are I would argue like we need regardless if we wanted to move to the lean chain. And one of those I guess some of those would be like um uh having a devet with like real EL clients uh running over the engine API potentially like supporting blobs. I

believe that would be required to like upgrade to lean. Uh and then just a few other ones which would pro probably be like fun if we have time or potentially re can just like do it on its own depending on like who's interested is like ZKifying the STF for the lean chain. uh just doing some like research with that and seeing if like we could interrupt with that with other clients and then possibly start working on our syncing logic. Currently all clients uh who implemented lean our current strategy is to just run all the nodes at once. I believe QEN has syncing logic

but other than that I'm not sure what other clients do. Uh but yeah uh yeah uh >> yeah so there is a PR in Zim for syncing uh through block by root uh so we might get it soon but uh we also need uh syncing from block uh block by range uh to basically you know go a full throttle syncing but I guess it's not not necessary if we sort of always make sure that we use checkpoint sync from the last finalized uh then syncing by block by root is just fine enough and to constrain our scope

for so that we can focus on the things that matter so I would not want to get distracted uh by other stuff uh for devnet 2 I think uh lean vm non-recursive signature uh proof proofing and verification was ready I'm not sure can somebody just correct me over I think uh you're right it's quite ready. Um the person like you should talk to for everything related to LINV VM is definitely Emil.

But uh yeah from my side that is ready. You can if you have a doubt also what you can check is on the LIN multic repo you have a performance benchmark on both like a Linux and MacBook Pro computers so that you can see approximately what's are the performances at the day you you look so that you can check um approximately if this is the odd of magnitude that you you want to achieve but I think that yeah this is really right now if we don't talk about recursive aggregation.

Yeah. >> Oh, uh >> that's really cool. I wasn't aware. >> So I guess we could speedun DevNet 2 then. >> Yeah, let me >> let me send the link. So >> so Anchul from our team has already started working for it. Uh and basically has created a Python uh binding so that we can start using lean VM in the lean specs and the idea is for DevNet 2 since there is no recurs no recussion uh proving verification. So uh what what it really means is that uh only the attestations from uh uh that are

basically propagated in the network as uh validated attestations they will be they can be packed again they can be packed in a block. Uh so basically you can't repack that aggregated signature if I understand that there is no recussion. Uh so with regard to that basically what it means is that you we will not importations in a block which is not really a problem because uh all of the clients on every slot they are voting and uh latest votes would most likely be updated in our given healthy network and uh so we can just uh we can just use the network uh attestations to uh construct new block. So with regard

to that I think uh we can do devet 2 and uh we'll basically put for a spec on the same where we can discuss [snorts] on the yeah on the yeah I I agree on the on the bindings and what you are mentioning uh like to be honest in the long run I I don't quite like the the binding approach uh because this will put a mess in the Python spec making things even more difficult for example to formally verify to test properly. Um the fact also to have the lin VM spec in

a very light way in Python could be very helpful for people to understand as an educational tool also for people to make fusing between the library in Python and the library in Rust to do cross testing to have a light version of the linvm. So in the future I think that we will have to spec uh in Python directly. There is no shortcut for that but in the short term I agree that uh yeah if needed we can use a binding but I am never a big fan of binding stuff good news on signature aggregation is

that u emil has made a very significant stride on performance so hashing is now extremely extremely fast as I said [snorts] a few weeks ago and now um aggregation of XMSSS is also extremely fast so we're I believe over our target of a thousand signatures per second uh on a laptop CPU um and I expect it to just keep on improving over the the weeks to come and recursion we also have some very good numbers I believe it was 120 milliseconds uh for um the work part which is just a subset of the recursion. Uh but overall it

looks like uh we will reach the performance targets that we set ourselves. And part of that is because uh there's just been some some new kind of uh lowhanging optimizations that were found in the proof system. And part of it um due to the fact that we have this much more clean and modular way of handling pre-ompiles and uh uh we have a slightly different set of pre-ompiles now.

>> Excellent. So Colby hearing all that does that sort of alleviate the original concerns or or feeling that maybe DevNet 2 would be blocked? Uh yeah, I believe so. Thank you guys for all the context. >> No, it's great. Um any other I know we've maybe kind of jumped uh around a little bit on the agenda schedule, but any other specreated updates this week or open PRs that uh you're hoping to get some comment or feedback on?

Sorry, you mentioned the spec. I I didn't hurt. >> Oh, I was just uh giving a another call for see if you had any discussion discussion topics that you wanted to table that are related to spec updates or if there's any PRs that you're looking for feedback on to if you're blocked on anything. >> I can give like a quick update on the spec. Um I last week uh we merged into the lin repo the SSD serialization um of of the signature object. So the secret key the public key and the signature itself. So that now you can just use TLDDR you can just use two

bytes and from bytes to serialize this serialize and it is directly in the proper SSD format. Um so that is one new uh another one is that I adapted all this into into the linspec so that we remove the legacy code about um doing strange serialization stuff so that now we directly use SSE and we remove that. So the spec in Python is fully compliant with the lin repo. So that was a nice uh simplification.

Also, I just merged this morning this PR about the test vector stuff um in order to reduce the time of the test vector because before um at the beginning of the test vector process either when you run a single test or if you run like tens of test you have the you had the key generation stuff. So a bunch of key generated even if it is like a small config you had to regenerate each time the keys. So if you run locally 10 times the test then you will have 10 times key generation and that was a bit uh of a nightmare because we don't have to do that. So I just created a small script

that is attached to the Python spec and via this script we can regenerate some private key public key so keep pair for any number of validation validators let us say four or six or 10 and so at the beginning of the test uh what we are just doing is that we are just looking at the JSON file and just dializ sorry the key pairs so that we avoid completely the call to the key generation making like the test vector like two times faster. I still have some stuff to optimize because this is still a bit slow but uh yeah this was a a nice stuff to gain uh on testing time and uh

yeah that was mainly hit for the spec. Uh yeah, also as I mentioned on the LIN um consensus on the LIN call channel on Telegram, we have a bunch of work about fast finality and everything around this in the ADF. And so I would love to see in 2026 how this is possible to integrate some of this work into the the Python spec and being able maybe to run some DevNet with that. So it is not clear for now what will be the final design adopted by the consensus team at the EF. There are a bunch of research by theoretician guys. Uh but yeah that will

be also an avenue of work uh to integrate like some clean and future algorithm into the lin as well. Yeah. Excellent. Um, any other specreated or research discussion topics? Any other blockers that people want to discuss to be able to get the longunning DevNet one this week? and start

preparing for DevNet 2. Is there possible to um create a highle document for DevNet 2? >> Uh yeah, sure. I can I can propose one. That'd be great. Thanks. >> Okay. Um >> I may ask maybe there are some open questions at least from my side but

maybe some people have some ideas like if we be introducing the aggregation in DevNet 2. I think there are questions like whether we going to have like a single aggregator or multiple aggregators. Then if there are multiple aggregators like there will be questions like at which point they should aggregate uh I mean whether they should wait some particular certain number of signatures or a certain kind of time uh during the slot uh when they should start aggregating. Uh yeah, I'm not sure if someone already was thinking about this or this is still kind of like an open

question like number of number of aggregators that we're going to have. I believe there was like ideas in the past that we're going to have like 10% of all nodes uh being aggregators. On the other side, in existing Ethereum, we can have like something like three Uh or for simplicity, we just want to start with a single aggregator. Um yeah, if someone have any ideas, yeah, maybe we could discuss at some point.

>> Yeah. So for devet I was thinking that uh the block proposer will be the aggregator and uh then we can basically open up uh open it up to bring in aggregator role as such and have more aggregators. Uh I think if we have more aggregators then uh we basically need recursion at that point but even without regression we can basically pack multiple signatures like we do right now. So depending upon uh whether lean VM is ready at that point when we bring in more aggregators we can decide for of one final aggregated signature or multiple aggregated signatures. But yes I I think once we are definite to u interrupt when once we achieve definite

to interrupt then we can start uh to bring in the aggregator role. If it is a block proposer who is and he is the aggregator uh is he creates an aggregation kind of like in the beginning of the slot or before the beginning of the slot because if it is the beginning of the slot uh according the latest according to latest number if if we have for example something like I don't know the aggregation rate of thousand signature thousand signature per second then we will spend like first second first entire second just do aggregation uh whereas kind of at the at the end of

the first second we should already kind of create votes. So uh we kind of have the first second to uh propagate the block uh so we shouldn't be spending time for aggregation that the proposer should be doing this before the slot I believe I believe >> right uh so basically the uh the reason proposer will do aggregation in devet 2 is basically the scope will be limited and uh it basically you will so there is a single point where aggregation will happen and things will be pretty straightforward uh in that sense uh to change the spec or

to verify everything is going on finding the but yes as as basically we'll try to go beyond 100 nodes then basically we'll start seeing the performance issue that you have mentioned and that is when we should be bringing out the aggregator also so block proposer Aggregation is just like a step in to the next thing which is where we have these aggregator rules. So maybe DevNet 2.5 or Devet 3 we can have Devet 3 with the aggregator roles and have uh uh specialized aggregators over there.

>> Yeah. Okay. I think yeah we can discuss this once we have either any kind of draft of the specification like uh who and when actually aggregates Um, any other remaining discussion topics?

Okay, good call everyone. Um, look forward to seeing the long running dayong DevNet one here shortly and I'll see you again next Wednesday. >> Thanks. Well, >> thank you. Bye. >> Thanks. >> Thank you. >> Thanks everyone. right here. >> All right.