Post-Quantum Interop Call #29

Transcript

Will Corcoran: Okay, good morning all. Welcome to PQ Interrupt number 29. Let's jump in with Client Updates, Zoom team.

Gajinder Singh: Hello, Will. Hello, everyone. So, one second.

Will Corcoran: And I guess maybe I'll add, it sounds like we've got… Debnet 3 shipped. We've got a lot of discussion going on about DevNet 5, and DevNet 4. Somewhere in between there.

Gajinder Singh: Yep, so I'm back, yeah. Thanks, Will. Yeah, so DevNet 3, work is almost, you know, we are sort of wrapping it up on our end, in the sense that we were trying to simplify DevNet3 PR, figure out the issues. And, we have merged the DevNet3 PR into our main codebase. There are some follow-up PRs that are gonna come in, and we will… we are also aiming to upstream if there are changes that we need to upstream in the spec from our perspective, so that things are simplified at the spec level as well. And, for DemNet4, Anshal already, put up a PR, and, DevNet 5 discussions, I think we will do… In the later half of the call.

Apart from that, yeah, so we have been running, DevNet3 runs with other clients, and trying to figure out which ones are compatible, and which one have issues, and also trying to bring Lean Quick Start up to the mark. So this is, sort of our update.

Will Corcoran: Great. Thanks, Gajinder. Rheem team.

Shariq Naiyer: We, on the DevNet 3 front, yeah, we, we're now… we've started running, we've started running against other clients on, on the long-running DevNets. However, in all our testing, we were testing, starting the clients before Genesis. But, I've seen in some of the logs that Katya was running the client after Genesis, and something was going wrong in sync. So that was something we were focusing on fixing, and Katya has raised some other issues, Involving, involving invalid blocks, block state routes at higher slots. That's something we'll investigate further today. As for… as for DevNet 4, we have implemented, we have implemented the part of the spec that, we have split out, the feature flags for DevNet 3 and DevNet 4, we have retired DevNet 2, and, so now you can run DevNet 3, and you can run DevNet 4 on Rheem, and but for DevNet 4, I think,

I think Lean Multisig does not have the current API, does not use, LeanSigs bindings. For the current API, so I think that's something we'll be waiting on before we can… we can move forward with DevNet 4. But apart from that, structurally, we have implemented parts of the DevNet 4 PR, that… that could have been implemented, and… and yeah, we're gonna further continue testing on DevNet, DevNet 3, and working on DevNet 4. That's it.

Will Corcoran: Hey, Shariq. Clean. Kamil, good to see you back.

Kamil Salakhiev: Yeah, good to be back. Yeah, I'll have just some brief update on… about myself, and then pass the word to Ruslan, as he is more aware. Yeah, I'll be kind of stepping down as CEO from Quadrivium, I'll be joining Ethereum Foundation soon. I will still continue working on many, many stuff, including Lodestar Consensus, but yeah, the team will be mostly working still advising sometimes clean and working with it. But other than that, yeah, from now on, I think… Ruslan is a better person to… Talk about clean, so yeah. Ruslan?

Ruslan Tushov: Hello? Thanks. So… As for clean, we made two branches, DevNet 2 and DevNet 3. Recently, we added to… DevNet3 branch. And the car image, checkpoint sync. But currently, there are some problems. Not yet investigated, like. clean, for some reason, doesn't accept new blocks after restarting or after checkpointing, so we're still investigating that. And, DevNet4, we didn't start implementing it yet. Thank you.

Will Corcoran: Thanks, Russell. Lantern.

Mihir Faujdar: Yep, thanks, Phil. Bye, everyone. So yeah, since last week, just been focused on, fixing bugs in the engine. Especially if it, encounters a fork block in the head. it would basically replay all the blocks from Genesis and get stuck in this loop, but that has been fixed, Been running a, like, a long-running demo on a remote server. With, Clean and Eat Lambda, and for DevNet3, and it's been looking a lot stable. It's been able to finalize for more than 20,000 slots. Basically, we'll be testing with more clients, as more updates get pushed out. And as well as, just some improvements in logs, like, easier tracking for, if you're running the client, you can, like, see the commit hash.

To see which version is running. And for DevNet4, we'll be able to start work on it once the PR is merged into the lean spec. And yep, that's our update. Thanks.

Will Corcoran: Prysm here. East Lambda.

Pablo Deymo: Hello. We were working on Lambda 3, As you mentioned, we merged 73 branch domain, so we deprecated FNA2. We have debug… we have been debugging, fixing issues. We found, during non-finalizing runs, particularly our, around memory. We hit some out-of-memory errors when the chain doesn't finalize for a while. So we are working on this, on making a… I mean, a boundary memory there. Also, we, correctly, we fixed some metric computation of the link that float. And we stop subscribing to aggregation subnets when we are not actually aggregating. That's where we added some, we made some, cleanup.

General… turn on boarding up. And, we added cross-plane XMSS compatibility tests, with, RIM. So we'll, we'll be working with, DevNet 4, spec, and fixing this, OOM. In the runs. Thank you.

Will Corcoran: Thanks, Pablo. Game team.

Shaaibu Suleiman: Yeah, thanks, Will. Yeah, hello, Ron. Yeah, so we've, completed most of the work, for DevNet, 2. Basically, the integration. for lean multi-sync, for signature aggregation, and also, the checkpoint, sync. For clients, basically, for clients that are out of sync, they're actually syncing properly. With Check Point Sync. We also tested, Gene, standalone, on its own, and also did, tested it, using the multi-client, interop, just a local instance, of that, with LeanQuick Start, on our own ends. And, at the moment, justification and finalization is pretty, pretty coming up, well. We have just, one PL that needs to be, reviewed, and then,

We also, we round up, most of the work we are doing, on DevNet 2. And we are also looking forward to implement, a persistent… more of a persistent storage, because for now we are using an e-memory storage, for most of the things we are doing, so we're looking forward to, implement, a persistent storage, in DevNet 2. We are considering, 2DBs, basically, BoltDB, or, PebbleDB, but then we are going to be finalizing that, and then wrapping that up. So, before… before this week runs out, we should be done… With DevNet 2, and see how we can, move forward, to DevNet, DevNet 3. So yeah, basically that's it, from our end, at Gene, yeah. Thank you.

Will Corcoran: Excellent, thank you. I don't believe anyone from Lighthouse, Grandine, Nimbus are on the call. less… It's all for client updates. Okay, great. Maybe we should move on to Spec Talk? Anshul, in the comments, I believe Gadjinder thought you might have an update on the DevNets4 spec? Pure.

Anshal Shukla: Sorry, I couldn't hear you properly, but I think it is related to DevNet 4PR that I have raised on this spec, right?

Will Corcoran: Yeah, yeah, just curious if there's anything blocking you on that. I know it's in… Up for review.

Anshal Shukla: Yeah, it is up for review, and, like, Gajinder has already posted a few comments that I, that I plan to solve today, and update that PR, so, yeah, I'll do that today, and, ask for a re-review on the channel itself. Once that is done, then I'll address the test cases that are failing. Right now, I have only made the changes on the functional side of things. Once, like, the draft PR gets approved regarding the more core changes, then I'll address the Other issues that are there.

Will Corcoran: Thank you. Anything else regarding DevNet4 specifications or research?

Shariq: Yeah, so I have a quick question, and, like, maybe Ansham can answer this. From my understanding, Email usually makes us, like, a branch where we're using LeanSig encoding instead of… the XMSS encoding in Bertisec. I wonder if this branch has been created and I haven't seen it, or… or we're still waiting on that.

Anshal Shukla: So… That branch hasn't been created, and, like, there are plans to not create that branch altogether. Like, we had this discussion in the last week's call where we were planning to basically, move to ZK-friendly encoding based on, a recent, research paper I believe Benedict has written. I am, not completely sure about the status on LeanSig side of things, and how it is being planned to, Being modified on the… Lean VM eventually, maybe Tomas can, elaborate upon that.

T. Wambsgans: It's not really yet on Linuxec, it's not really yet either on LeanSeq, so sorry about that, it's a work in progress. There's just too many things to do, but… I hope it will be done in not too long, but honestly, there is just too much to be done, and I cannot promise you anything right now. I'm sorry.

Shariq: Yeah, yeah, 100%. I'm not rushing anyone, I was just like, I just didn't want to be in a position where I didn't know that there's a branch, so I'm glad to know that there is no branch here.

T. Wambsgans: I cannot guarantee you that it will be done in the next week, but I can guarantee you that when it's done, you will be noticed.

Shariq: Thank you, thank you, Amir.

T. Wambsgans: Visual.

Gajinder Singh: But as per my understanding of what Angel said, there is a branch, right?

T. Wambsgans: There is no branch. There is, no, because… I… because I would need to do first a PR in NSIG, and then to implement the changes in the multisig, and so it's… it remains to be done. But when it will be done, it will be noticed, as soon as it's done.

Will Corcoran: Awesome. Thanks, Emil. Anything regarding… DevNet 4. I know there's some open discussion about .NET5, but… Closed loop on 4 before we move forward.

Anshal Shukla: So the PR is up, and I'll be making the changes, but, nothing apart from that.

Will Corcoran: Okay, great. And then the…

Gajinder Singh: Also, Billy teams have not… Also, if other teams have not reviewed the PR, please take a look.

Will Corcoran: Yeah, and if you could also take a look at the, the high-level design doc, or, specification doc in the PM repo for DevNet 4. I believe that PR's… In the comments, and also open.

Shariq: Yeah, a quick note on the PM… when you brought up the PM repo. I made a PR to tag the latest branch for DevNet 3. I don't think it has been merged yet, but I think… I think that should be merged so anyone is not misled.

Will Corcoran: Perfect.

Gajinder Singh: So, what… until… what path from the commands? Do we have subnet as hard-coded as 1 in our DevNet 3 spec? I was under impression that we will be testing out multiple subnets. DevNet 3.

Anshal Shukla: No, we have it hard-coded as one. Also, I have already, commented out this in the spec PR itself, but, in DevNet4, while I'm recursively aggregating the signatures, I am not, sticking up to the subnet specifics, although that is not the case right now, but even if, like, I receive multiple signatures from different, multiple aggregated payloads from different aggregated subnet. I am, not… I am basically aggregating them recursively and not sticking to that. I'll only be aggregating to, A particular set of subnets in… as an aggregator.

Gajinder Singh: Yeah, that is fine, because that is how we want it. If you get an aggregated payload from any of the subnets, you can aggregate it, because as an aggregator, you can self-choose yourself to basically aggregate any subnet. So that is just to sort of manage traffic and say that, okay, this is the subnet that, That validators will be publishing. So, can we un-hardcode the subnet one? Because I don't understand why have we hard-coded as one? Maybe just for the sake of… the spec client, or the Python client, I mean, if that is the case, then… It can be moved to… moved to config and, sort of remove the hard coding.

Parthasarathy Ramanujam: Yeah, sure. We can…

Anshal Shukla: Do we want to raise it… raise it on this lean spec as well? I… yeah, Pate, you can continue. I think you have a.

Parthasarathy Ramanujam: No, no, my only concern is modification to lean quick start to support to multiple subnets. For now, DevNet3 PR on Lean Quick Start assumes you have a single subnet, otherwise we'd have to I mean, spin up more machines in order to support, multiple devnets. So if we decide to support, or rather test with multiple subnets, I'd have to make some changes there and bring up more machines.

Gajinder Singh: Yeah, so once we are, through, single subnet testing, then that is the next step. And, These need to be made to Lean Quick Start, for that matter. And if the subnet count is, It's… is hard-coded, basically it needs to be moved to the chain config. I think this is something that we already implemented in Zim like that, but maybe it is not upstreamed. So I guess Anshul is going to put up a PR for this?

Anshal Shukla: Sure, I'll do PR on a spec as well, but if we plan to do a DevNet testing with multiple subnets, we'll have to increase the number of validators as well. Right now, we have very minimal machines. If we have, like. 2 or 3 subnets, we'll have to ensure that we have, like, enough machines on each subnet so that the aggregation can work properly.

Gajinder Singh: Yeah, that is the plan, and last time also, I think I mentioned that we should have the document in which we should say that, okay, we tested 400, then maybe bump it up. 200, 500, whatever. So, yes, we need to bump up the validators, because we have been testing with minimal validators, and it's time right now To actually get closer and closer To what things would be. in Maynat.

Kamil Salakhiev: Yeah, Kamil. Yeah, I just want to say that I was contacted by Dave, who is kind of leading all the P2P efforts. He said he has opportunity to ask some universities in the US to Allocate, like, 600 machines, or any kind of experience that use Libby2P, So, yeah, just saying that… Yeah, we might consider to work with them to kind of spin up larger networks. If anyone is interested, yeah, can help to coordinate.

Gajinder Singh: So, I guess we can coordinate with them over this.

Kamil Salakhiev: And get us the… Yeah, I'll talk to him.

Will Corcoran: Yeah, if you could put me in contact, that'd be great. Wonderful. Any other DevNet 4 items?

Anshal Shukla: Just that the PM, I have raised a high-level design on PM repo, that design is outdated, I'll be updating that as well, so if somebody refers to that design and compare it with the specs, there's a certain mismatch that I didn't preempt while writing that doc, I'll update the doc as well.

Will Corcoran: Awesome. Thanks, Anshul. DevNet 5 spec spec. I see Gajinder, you dropped a lengthy note in the DevNet 5 chat today. I don't know if… Do you want to start off third?

Gajinder Singh: Yeah, so basically, we propose that in DevNetify. So right now, what we do is, we don't sign over the block when the proposal signs over. It only signs over… Proposal written, and that is sort of… I mean… Not ideal, so we would want to sign over the block, as well as proposal attestation, and… use, multiple messages, in… so aggregate, signatures with multiple messages. And the way, sort of I… I think it can happen is that So… so block and proposer attestation, so block… block… block message and proposer attestation, they are both signed by the proposer, for the same index, so… we have the restriction of one-time signatures, but since this is not being propagated to the network, it is not really an issue. So we recursively aggregate, these two signatures in one,

In one signature, in one proof signature, which is then transmitted, and that… I'm hoping will not, jeopardize one-time signature scheme. And then, using the interfaces that Emil provided, we can basically, make sure that, when we are… we can independently, validate signature, proposal attestration against the signature, as well as Independently validate, block. against this signature. So if we can do that, then what can be done is that this signature can be recursively aggregated With other XMSS signatures, which has the same message data as… the proposer attestation message. So… so this is… This is what came to my mind. If we can do this, then…

probably this is something that we can do in DevNet 5, and this would also solve the problem that we are not signing the block as of now.

T. Wambsgans: Is it correct that you, initiation, the proposer should sign two messages at the same slot, at the same, sorry, sorry, two different messages at the same slot? And so, and the idea that you have is, that if it's inside an aggregated proof, and if, and it's an important if, the snack is a ZK snack, like, true ZK, in some sense. You mean that nobody can have the information of the two signatures, and so it cannot… like, it would remain safe because it's, like, a ZK snack? And just to be clear, currently, it's not ZK, in the sense that it's only 6 cent, but not ZK. Is it correct?

Gajinder Singh: Yeah, so this is what my proposal was, but, so… but you are saying that currently the proof is not ZK, it's only successful?

T. Wambsgans: beep. Currently, it's not CK, so currently it would be insecure, but it doesn't mean that it would not be CK in the future. And there are some other use cases where ZK is valuable. And so, it's… potentially, it's a bit risky. Probably Benedict, who is raising his hands, has some thought about it.

Will Corcoran: You know what I mean? Yeah.

Benedikt Wagner: Yeah, so I think, adding ZK just for this feature sounds like a massive overkill. I don't think we should add this just because of this feature. It would be maybe… More useful to think of the two messages that the proposer needs to sign as one message. And then just do one signature over them, right? I mean, you can sign arbitrarily long messages, so you can sign two messages as long as you treat them as one message and sign them.

Gajinder Singh: Yeah, but would that basically give me the ability to validate against, let's say, you know, one of the messages independently, or to aggregate them just using one of the messages, right? So… So, what I'm… what… so once we have this combined, proofs, the signature for block, as well as, proposal attestation. So, I just want this signature that could be aggregated with other XMSS signatures. From other validators.

Benedikt Wagner: So, strictly speaking. what we thought about all the time was a multi-signature scheme, where everyone signs the same message. Now you would say that this one party signs a different message, but because we are using Snarks, we can Equally, well, just… just do that, right? So, you can… if you design the relation that is proven in LeanVM correctly, then you can also aggregate signatures for different messages. And I think this is a much… more useful change to LeanVM than adding ZK just for that. especially that… I'm not even sure that ZK is sufficient for this construction to be… to work.

T. Wambsgans: a question, Among the two messages that you want to sign at the same slot with the same key, is there a dependency? In the sense, does the second message depend on the signature of the first message, or not?

Gajinder Singh: Can you… Tell it again?

T. Wambsgans: let's say you want to sign two messages with the same key as the same slot, is there a dependency between the two? Thus, the second message that you want to sign depends on the signature of the first message.

Gajinder Singh: So, there is a dependency in the sense that a proposal attestation is based upon the newly constructed block. So, there is that dependency, because first you construct the block, import it in the fork choice, and then you, create, your… Your proposal attestation, whose head is basically the new block that you added. So in that sense, yes, there is a dependency… dependency.

T. Wambsgans: So, if I understand correctly, it's kind of… I am the block proposer, I propose a block, I sign it, and then later I will vote for my own block. Is it the same here?

Gajinder Singh: Yeah, so currently we don't sign the block, because we only signed the proposal attestation, so the signing of the block is not there, but… We just create the block, import it in the fork choice, and then create a proposal attestation on top of it. So, proposal attestation is dependent upon the block, but not on the signed block.

T. Wambsgans: Yeah, okay, I think I understand the use case, and is it possible to… kind of, maybe say that if I'm the block proposer, I don't need to attest to my own block, I attest by default, or it's not possible.

Gajinder Singh: So if… so… so attestation, when you are packing, proposal attestation, that is not the attestation that can be consumed in this slot. It is, like, the feature attestation you are packing. What you are doing, for example, what generally happens? in consensus is that the block is block proposer proposes a block, and then everybody consumes it, imports it in the fork choice, and then that estration round starts, which is basically the testations that get packed in the next block. So… so it is… it is not… it is not the attestation for this block. It is basically to be consumed and packed for the future, for whoever is doing a block production downstream. So, in that sense,

It is not possible, what you're saying.

T. Wambsgans: Okay, I see. Okay. And can we skip the… I don't know, can we say that the ballot proposer doesn't vote for the second vote? I don't know.

Benedikt Wagner: I mean, okay, so there's another solution that I want to just… to introduce. I'm not sure if it's the best solution, but we should think about it, and that is if we say we have a lifetime of L, Then we create a virtual lifetime of 2L, So we have twice as many, on-time signatures, and we take the even on-time signatures for attestations, and the odd ones for being a proposer. So… you would just, you know, in slot I, you consume… one-time signature 2i and 2I plus 1, and you only consume 2i plus 1 if you are a proposer.

Gajinder Singh: And if we are already at true to the…

Benedikt Wagner: 32 maximum lifetime, then it's… I guess it's probably fine to just have an effective lifetime of 2 to the 31 by using this sort of even hot split.

T. Wambsgans: But…

Gajinder Singh: So this was something that was also originally proposed, that, you know, we have, basically. Either a separate key for proposing and testing, or basically, you know, double the lifetimes and sort of index them out. That way, but then we decided that, okay, you know, we would… we could use… so LeanVM would allow us just to pack it and somehow be able to aggregate it later on.

T. Wambsgans: I think it would work. The only drawback, I guess, is the time it would 2X the key gen time for the same effective lifetime. Couldn't we also have a solution where When you sign the blog that you propose, like, the first time you sign as a blog proposal, you attach some kind of… another one-time signature, a new, like, a fresh one, you attach it to your blog and use this new one-time signature to sign the second message, something like this. Like, you, you, you, you continue the one that's the children.

Benedikt Wagner: aggregation kills you, right? Because the one-time key will be somehow lost in the aggregate, right? So if you aggregate the signature that contains the new one-time key. How can you… retrieved this one-time P.

T. Wambsgans: Like, you, what you sign includes a public key of a one-time signature.

Benedikt Wagner: Yes, and how do you make sure that everyone sees this one-time key? Because not everyone sees your signature, so… They only see aggregate signatures, right?

T. Wambsgans: You have to include it in the block. Like, the… the one-time public key is included in the block.

Gajinder Singh: Yeah, but what Benedict is saying, that once, basically, you know, downstream block proposer, he will try to aggregate this attestation signature with other Other signatures. Obviously, they will see the key, so they will have to pack it somehow. In the signed, in the proof itself, right? So that…

Benedikt Wagner: Maybe it works, I'm not saying it doesn't work, it's just a bit… Sounds complex to make it work, but yeah.

Thomas Coratger: But let me know if I am wrong, but Benedict, in your first proposal, you didn't propose to double the lifetime. You just say that, given the high lifetime that we have of, like, a couple hundred of years, we just do the stuff that you proposed with the tool.

Benedikt Wagner: Yeah, yeah, I mean, you can… Yeah, yeah, you can either say we double the lifetime, or we take the lifetime that we have right now, and we halve the effective lifetime.

Thomas Coratger: Yeah, because I think that with 2 to the power 32, it is, like, 500 years…

Benedikt Wagner: Yeah.

Thomas Coratger: Yeah, 500 years, something like that, you just divide by 2 is 250, yeah, that is… this is also okay.

T. Wambsgans: I think the clearing the bottleneck would not be the total lifetime that… because it's effectively a lot. The domain button would be the region that would become two times slower for the same effective period, since you need to generate two keys per slot.

Benedikt Wagner: Yeah, yeah, it would be… same… yeah, I agree with that. It's, So what was the problem, again, of taking this… these two messages that you… And then treating them as one message.

T. Wambsgans: The problem is that the second message has a logical dependency with the first message. You need to include the signature of the first in what you sign in the second.

Benedikt Wagner: Okay.

T. Wambsgans: There… there is also an exaceration, but… if the… If the… the… Awesome.

Gajinder Singh: So, if, for example, you know, downstream, when you are… when the next proposer is sort of aggregating the signatures, it… it can also provide the message hash for the block, right? So, while trying to aggregate it. Because next proposer is the one who will be aggregating this with the other aggregates. So… so the question is that if… message, so let's say message 1 is block, and message 2 was proposal attestation, or it can be other way around. And when you're aggregating with the other aggregated signatures, or XMSS signatures, which are same of message 2. So, question is, in the in the final, aggregated signature, can you drop message 1? If it can drop, basically, what can happen is that

the final aggregated signature can be verified independent of message 1, which was the blocked message. So if this can happen, then there is no problem.

T. Wambsgans: I don't think that…

Benedikt Wagner: That works. Like, this would essentially say you verify a SNARC without having the full statement.

Gajinder Singh: But can't message one be treated as a witness itself? I mean, when you're trying to aggregate it, so…

Benedikt Wagner: Yeah, but for the parties who want to verify that Message 1 is part of it, they need to treated as a statement, so you would have two different relations that you prove, so you need two different stocks. So what… what about the following? So this goes back to Emil's suggestion. When you are a proposer, when you sign, you include, a new one-time key, and then when you are a proposer the next time. You use that one-time key to sign. And so essentially, what I'm saying is just use a completely different, scheme, signature scheme for proposer signing. Then for attestations, for attestations, we use XMSS, and for proposal signing, we use this very naive chaining of one-time signatures, and you can always

And because there's only one proposal per block, it's fine that you include a new next public key for the next time I will be a proposer.

T. Wambsgans: I want just to.

Gajinder Singh: So, maybe…

T. Wambsgans: Sorry, please, please, please.

Gajinder Singh: So what you… what… I think that could work. So what you're saying is that, so when… so I… when I create a blog, I basically sign it. with a different… proposer key. And, sort of, in the final, final signature that I make, with proposal attestation, I somehow… included.

Benedikt Wagner: No, I'm saying that, forget about the two things. Let's say we've resolved attestation signatures using XFSS, now forget about that. How do we do supposer signatures? We use a very naive, completely independent, stateful hash-based signature scheme, where when you sign. You also publish a public key that you use for the next signature. So, when I want to verify a proposer signature, I check when has this party been proposer last time, and there I look up the public key.

Gajinder Singh: Yeah, so basically public keys get updated in the state.

Benedikt Wagner: Yeah, whenever you sign as a proposer, you update your public key, essentially. But this is not the same public key as your XMSS public key for attestations, because you'd need to do attestations much more often. That's why we don't want to use this chain-based scheme. So, yeah.

Thomas Coratger: I don't know, it's not the preference.

Benedikt Wagner: Perfect solution, it's a weird solution, but… It's one solution.

Thomas Coratger: In this case, this means that you have two keys registered by… per validator. Yeah, exactly. And you update this again.

Benedikt Wagner: One of them is updated all the time. One of them is updated whenever you are a proposal, essentially.

Thomas Coratger: Okay.

Gajinder Singh: Yeah, this could make sense. I mean, so, I think what we can do right now for DevNet5 is that, We… since our devnets are short-term, we can just use index 1, so old and even index of the key. And in the meantime, we can figure this out, how to do it, because this suggestion, I think, is workable for sure. that we have… Proposer signature, that is being updated. Proposer key that is being updated all the time. And…

Benedikt Wagner: I mean, you can also… You can also mix the two things, right? This… this chain-based signature that I described, like, you don't need to do a one-time signature, let's say you do a… 16 times signature, and then you only need to update your proposer key. every 16th time you have been a proposer, right? So you can use a… essentially, you can use a very short lifetime XMSS for being a proposer, and then you use a long lifetime XMSS for being a tester. And this means that you just need to take care that when you are a proposer. And your lifetime of being proposer runs out, you need to… Update your keys.

Gajinder Singh: So, so this is sort of like an epoch treatment, but on the level of an individual validator, right?

Benedikt Wagner: Yes, exactly, and I guess individual validators could pick different, completely independent lifetimes for the proposal key. I… I'm not sure, this makes it a bit more complicated again, but yeah.

Gajinder Singh: So, for the simplicity for the next DevNet, why don't we then generate two keys, right, and just enroll them directly in the straight, at the Genesis? I mean, I don't see an issue in that for… as of now.

T. Wambsgans: It seems that the cleanest approach, if you don't care about key gen, it's probably the simplest way to do it is.

Gajinder Singh: Alright, so we'll keep thinking on this a bit more and sort of figure this out. And finalize this while we are specging out DevNet and implementing DevNet 4. All the input. Easily what?

T. Wambsgans: any guarantee on… for instance, some guarantee, like, you cannot be a proposer, two times, in a row, like, in, 16 blocks, like, there… the proposer, like, if you take 16 blocks, there cannot be two times the same proposer. It doesn't work if there are less than 16 proposers, but I don't know.

Gajinder Singh: So, one… one very problematic thing that can happen is that, let's say. So there were 16 forks that happened, right? And, Or 17 forks. And on the 17th fork, basically. You could not enroll your new key. But… Now your lifetime is sort of over. I mean, this is an extreme case, but this is something that could happen, and we'll be…

T. Wambsgans: Yeah. Okay. So, back to the show, okay.

Gajinder Singh: So, what we can do for now is maybe spec out DevNet 5 with respect to, With respect to separate keys, or basically audio one. But we still will need message 1 and message 2, Aggregation, because… Or we might even not need it here, because we'll have It's just published.

T. Wambsgans: In any case, this part is really easy with LinVM, so if you can write down the API, it will be really easy to make it implemented very thinly.

Gajinder Singh: So, when we… when we are going live, I mean, when we'll go, for example, live in Elstra Hot Fork, so do we… will… will we go with ZK or not?

T. Wambsgans: I believe we should not assume ZK right now. Even though there are other use cases of VINVM that will need ZK, so potentially, there will be ZK by default, but I would not assume ZK to… Build the consensus layer, in some sense.

Justin Drake: Is the idea… sorry, I was a bit distracted… is the idea that you have, basically, a Ziggy-style signature? with a proof of knowledge of a pre-image in ZK. Is that the idea?

T. Wambsgans: I believe the idea was to use two times a… there was a use case where you need to sign.

Justin Drake: Right.

T. Wambsgans: two times with the same XMSS, at the same slot, two message difference, and it should work… at least it makes sense that it could work with.

Justin Drake: Always true.

T. Wambsgans: It's… It's not, like, yeah?

Justin Drake: I mean, one issue with using a SNOC for signing is that it's unfriendly to weak devices.

T. Wambsgans: Correct.

Justin Drake: And I'm… yeah.

T. Wambsgans: Correct.

Gajinder Singh: So we should not be assuming security, because of the SNARC, it is basically coming from the underlying scheme.

T. Wambsgans: Yeah, and if we do it, it also exposes on, like, the site channel attacks that were, in some sense, not an issue with XMSS would become an issue, this time, probably.

Gajinder Singh: So, I think for now, maybe we can spec it, with two keys, or with… or even, and if we do that, we might not even… need message 1, message 2, because… If proposer… At a station is signed independently, basically, then… It can just be aggregated in the normal way.

T. Wambsgans: Beautiful. Perfect. And potentially, KeyGen will be so fast with CMT or other software optimizations that it will not be a problem to have this tool X overlap, because if it makes the overall protocol simpler, you can probably spend a few more minutes at KeyGen, in some sense.

Gajinder Singh: Maybe we still do it to bring the signature size down for the block. So, yes, I mean, yes, we'll see, we'll iterate on it.

Will Corcoran: Excellent. Any other… spec research-related conversations pertaining to DevNet 5. metrics, observability? Any… Updates that you'd like to… or… Topics you'd like to table this week?

Katya Riazantseva: Yes, hello, everyone. So currently, today, I'm trying to keep the DevNet alive. It's running with these 6 nodes, so I replaced them temporarily for ETHLambda and Grandin Pro for Clean, so whatever the images from those two teams will be ready. So I will replace them back, so… The big win of today is that the DevNet stalled at around 500 slot with finalization, but then it could recover, so I restarted some nodes, with JPE, checkpoint sync, and, so currently I'm struggling again with recovering it. So it could, recover from stalling at 500 slot to 2,500, so now I'm…

I made some fixes about Checkpoint Sync, and still struggling to make it… to keep it live. So the issues, with the clients I share in the tool channel, like, Ikambda, you know, what you investigate, so whenever, we lose finality, so just, you use a lot of memory. And also, I'm asking for DevNet 3 metrics, at least who is aggregator, to know, like, or which subnet, because we are moving forward and going to increase the number of nodes, so this is important. Whenever your client is ready for metric 3, please ping me in the channel, I will update the dashboard so we can observe that. as well. Thank you. If… if this devot, won't recover, I will restart it again.

Thank you.

Will Corcoran: Thanks, Katya. Any other open discussion topics? If not, I have one. Which is just to… Talk about the schedule for… Cam, this came up, or it was shared yesterday. So… Most of our focus will be on Fort Mode, obviously, as a group. This is the event, the day that will be analogous to Beam Day last year. We're gonna… Proceed that on Saturday with, a, beast mode day, this is… primarily focus on TK VMs, L1 TK VMs, ETH proofs, Things of that nature. native roll-ups. So, yeah, really, the spirit behind the scheduling, they're both in the same venue. It's a rather small venue, only 80 people. We have a lot of interest. We're… we're in… we're, approving

Requests for many more people than 80, so it's first come, first serve. You gotta do that with these things, otherwise you end up with empty seats, because people sign up and they don't show up. So that being said. really trying to put an emphasis on open forum discussions. We thought that that was really, really beneficial out of Beam Day last year. The… the E3 is a little bit more presentation-focused. You've got a lot of teams that, you know, actual ZKVM teams that want to give their… their updates, but then there will be a lot of debate around, And open discussion around the security sprint, and, sort of weighing canonical guests versus guest diversity, tied in with formal verification. And then the road to mandatory proofs.

With… so… That aside, with Fort Mode. Really, you know, we're gonna start off Justin giving a high-level, introduction, and then Toma talking about the new team, LeanCL, Antonio Santo talking about cryptographic functions, and then Emil doing a deep dive into LeanVM. We're gonna have a presentation from Nico talking about PQ signatures, but on the execution side. And then the afternoon, really, this is, I think, a great opportunity to, like, start to think about perhaps, like, what the 6 months between Cannes and Cambridge will look like, so… Starting off getting some really great presentations from Jan from the Protocol Consensus team, talking about fast finality and in-game finality, so there's a lot of in-flight research right now that will be presented there. And then same thing with the P2P layer, so…

Raul, the team lead for the networking team, will be presenting ETH P2P. I believe for the first time. And then, another talk from Tama about lean spec, one from Katya talking about metrics and observability. And then, really, we are gonna reset the whole room into, like, kind of a round Cable, open forum discussion, like last year, and end with 90 minutes of a lot of debate and discussion. Talking about… each of… hopefully each of the CL teams that are there, talking about lessons learned. Trying to bring… You know, topics of conversation that we've heard from the consensus researchers, networking researchers. To hopefully align on a roadmap or scope items that we want to build into.

the next several DevNets, from that point on. So that's… my little presentation, but yeah, any… any thoughts? Otherwise… We'll leave it there. Excellent. Look forward to seeing you all soon. Spring is… Finally starting to… Hop around the corner here in New York City. It's been a brittle winter. Really looking forward to camp. Alright, have a good day. Talk soon, everyone.

Gajinder Singh: He was…

Mihir Faujdar: Bye. Thanks, everyone. Bye.

Thomas Coratger: Thanks, buddy.

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