Will Corcoran:Okay, good morning all. Welcome to PQ Interrupt number 29.
Transcript
Will Corcoran: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.
Will Corcoran:We've got a lot of discussion going on about DevNet 5, and DevNet 4.
Will Corcoran:Somewhere in between there.
Gajinder Singh:Yep, so I'm back, yeah. Thanks, Will.
Gajinder Singh: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.
Gajinder Singh: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.
Gajinder Singh:And, for DemNet4, Anshal already, put up a PR, and,
Gajinder Singh:DevNet 5 discussions, I think we will do…
Gajinder Singh:In the later half of the call.
Gajinder Singh: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.
Gajinder Singh: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.
Shariq Naiyer: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,
Shariq Naiyer:Involving, involving invalid blocks, block state routes at higher slots.
Shariq Naiyer: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,
Shariq Naiyer:I think Lean Multisig does not have the current API, does not use, LeanSigs bindings.
Shariq Naiyer: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.
Shariq Naiyer:That's it.
Will Corcoran:Hey, Shariq.
Will Corcoran:Clean.
Will Corcoran: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
Kamil Salakhiev:Ethereum Foundation soon. I will still continue working on many, many stuff, including Lodestar Consensus, but yeah, the team will be mostly working
Kamil Salakhiev:still advising sometimes clean and working with it. But other than that, yeah, from now on, I think…
Kamil Salakhiev:Ruslan is a better person to…
Kamil Salakhiev:Talk about clean, so yeah. Ruslan?
Ruslan Tushov (qlean):Hello? Thanks.
Ruslan Tushov (qlean):So… As for clean, we made two branches, DevNet 2 and DevNet 3.
Ruslan Tushov (qlean):Recently, we added to… DevNet3 branch.
Ruslan Tushov (qlean):And the car image, checkpoint sync.
Ruslan Tushov (qlean):But currently, there are some problems.
Ruslan Tushov (qlean):Not yet investigated, like.
Ruslan Tushov (qlean):clean, for some reason, doesn't accept new blocks after restarting or after checkpointing, so we're still investigating that.
Ruslan Tushov (qlean):And, DevNet4, we didn't start implementing it yet.
Ruslan Tushov (qlean):Thank you.
Will Corcoran:Thanks, Russell.
Will Corcoran:Lantern.
Mihir Faujdar:Yep, thanks, Phil. Bye, everyone.
Mihir Faujdar:So yeah, since last week, just been focused on, fixing bugs in the engine.
Mihir Faujdar:Especially if it, encounters a fork block in the head.
Mihir Faujdar:it would basically replay all the blocks from Genesis and get stuck in this loop, but that has been fixed,
Mihir Faujdar:Been running a, like, a long-running demo on a remote server.
Mihir Faujdar: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.
Mihir Faujdar: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.
Mihir Faujdar: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.
Mihir Faujdar:And yep, that's our update. Thanks.
Will Corcoran:Prysm here.
Will Corcoran:East Lambda.
Pablo Deymo | Lambda:Hello.
Pablo Deymo | Lambda:We were working on Lambda 3,
Pablo Deymo | Lambda: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.
Pablo Deymo | Lambda:We hit some out-of-memory errors when the chain doesn't finalize for a while.
Pablo Deymo | Lambda:So we are working on this, on making a…
Pablo Deymo | Lambda:I mean, a boundary memory there.
Pablo Deymo | Lambda:Also, we, correctly, we fixed some metric computation of the link that float.
Pablo Deymo | Lambda:And we stop subscribing to aggregation subnets when we are not actually aggregating.
Pablo Deymo | Lambda:That's where we added some, we made some, cleanup.
Pablo Deymo | Lambda:General… turn on boarding up.
Pablo Deymo | Lambda:And, we added cross-plane XMSS compatibility tests, with, RIM.
Pablo Deymo | Lambda:So we'll, we'll be working with, DevNet 4, spec, and fixing this, OOM.
Pablo Deymo | Lambda:In the runs.
Pablo Deymo | Lambda:Thank you.
Will Corcoran:Thanks, Pablo.
Will Corcoran:Game team.
Shaaibu Suleiman:Yeah, thanks, Will. Yeah, hello, Ron.
Shaaibu Suleiman:Yeah, so we've, completed most of the work, for DevNet, 2. Basically, the integration.
Shaaibu Suleiman:for lean multi-sync, for signature aggregation, and also, the checkpoint, sync.
Shaaibu Suleiman:For clients, basically, for clients that are out of sync, they're actually syncing properly.
Shaaibu Suleiman:With Check Point Sync.
Shaaibu Suleiman:We also tested, Gene, standalone, on its own, and also did,
Shaaibu Suleiman:tested it, using the multi-client, interop, just a local instance, of that, with LeanQuick Start, on our own ends.
Shaaibu Suleiman:And, at the moment, justification and finalization is pretty, pretty coming up, well.
Shaaibu Suleiman:We have just, one PL that needs to be, reviewed, and then,
Shaaibu Suleiman:We also, we round up, most of the work we are doing, on DevNet 2.
Shaaibu Suleiman:And we are also looking forward to implement, a persistent… more of a persistent storage, because for now we are using
Shaaibu Suleiman: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
Shaaibu Suleiman:wrapping that up. So, before… before this week runs out, we should be done…
Shaaibu Suleiman: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.
Shaaibu Suleiman:Thank you.
Will Corcoran:Excellent, thank you.
Will Corcoran:I don't believe anyone from Lighthouse, Grandine, Nimbus are on the call.
Will Corcoran:less… It's all for client updates.
Will Corcoran:Okay, great. Maybe we should move on to Spec Talk?
Will Corcoran:Anshul, in the comments, I believe Gadjinder thought you might have an update on the DevNets4 spec?
Will Corcoran:Pure.
Anshal: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: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.
Anshal: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
Anshal:Other issues that are there.
Will Corcoran:Thank you.
Will Corcoran: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…
Shariq: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: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
Anshal: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,
Anshal: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…
T. Wambsgans: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…
T. Wambsgans: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.
Will Corcoran:I know there's some open discussion about .NET5, but…
Will Corcoran:Closed loop on 4 before we move forward.
Anshal: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,
Will Corcoran:specification doc in the PM repo for DevNet 4.
Will Corcoran: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?
Gajinder Singh:I was under impression that we will be testing out multiple subnets.
Gajinder Singh:DevNet 3.
Anshal: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,
Anshal: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
Anshal:different aggregated subnet. I am, not… I am basically aggregating them recursively and not sticking to that. I'll only be aggregating to,
Anshal: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
Gajinder Singh: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,
Gajinder Singh:That validators will be publishing.
Gajinder Singh: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…
Gajinder Singh:the spec client, or the Python client, I mean, if that is the case, then…
Gajinder Singh:It can be moved to… moved to config and, sort of remove the hard coding.
Parthasarathy Ramanujam:Yeah, sure. We can…
Anshal: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
Parthasarathy Ramanujam: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,
Gajinder Singh:These need to be made to Lean Quick Start, for that matter.
Gajinder Singh:And if the subnet count is,
Gajinder Singh:It's… is hard-coded, basically it needs to be moved to the chain config.
Gajinder Singh:I think this is something that we already implemented in Zim like that, but maybe it is not upstreamed.
Gajinder Singh:So I guess Anshul is going to put up a PR for this?
Anshal: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.
Anshal: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.
Gajinder Singh:200, 500, whatever.
Gajinder Singh:So, yes, we need to bump up the validators, because we have been testing with minimal validators, and it's time right now
Gajinder Singh:To actually get closer and closer
Gajinder Singh:To what things would be.
Gajinder Singh:in Maynat.
Kamil Salakhiev:Yeah, Kamil.
Kamil Salakhiev:Yeah, I just want to say that I was contacted by Dave, who is kind of leading all the P2P efforts.
Kamil Salakhiev:He said he has opportunity to ask some universities in the US to
Kamil Salakhiev:Allocate, like, 600 machines,
Kamil Salakhiev:or any kind of experience that use Libby2P, So, yeah, just saying that…
Kamil Salakhiev: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.
Will Corcoran:Wonderful.
Will Corcoran:Any other DevNet 4 items?
Anshal: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.
Will Corcoran:DevNet 5 spec spec. I see Gajinder, you dropped a lengthy note in the DevNet 5 chat today. I don't know if…
Will Corcoran: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…
Gajinder Singh:Proposal written, and that is sort of… I mean…
Gajinder Singh:Not ideal, so we would want to sign over the block, as well as proposal attestation, and… use,
Gajinder Singh:multiple messages, in… so aggregate, signatures with multiple messages. And the way, sort of I… I think it can happen is that
Gajinder Singh: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…
Gajinder Singh: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,
Gajinder Singh:In one signature, in one proof signature, which is then transmitted, and that…
Gajinder Singh:I'm hoping will not, jeopardize one-time signature scheme. And then, using the interfaces
Gajinder Singh: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
Gajinder Singh:Independently validate, block.
Gajinder Singh:against this signature. So if we can do that, then what can be done is that this signature can be recursively aggregated
Gajinder Singh:With other XMSS signatures, which has the same message data as…
Gajinder Singh:the proposer attestation message. So… so this is…
Gajinder Singh:This is what came to my mind. If we can do this, then…
Gajinder Singh: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?
T. Wambsgans: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.
T. Wambsgans: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.
T. Wambsgans: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.
T. Wambsgans: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:Yeah, so I think, adding ZK just for this feature sounds like a massive overkill.
benedikt:I don't think we should add this just because of this feature. It would be maybe…
benedikt:More useful to think of the two messages that the proposer needs to sign as one message.
benedikt: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
Gajinder Singh:just using one of the messages, right? So…
Gajinder Singh:So, what I'm… what… so once we have this combined, proofs, the signature for block, as well as,
Gajinder Singh:proposal attestation. So, I just want this signature that could be aggregated with other XMSS signatures.
Gajinder Singh:From other validators.
benedikt:So, strictly speaking.
benedikt: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
benedikt:Equally, well, just… just do that, right?
benedikt:So, you can…
benedikt:if you design the relation that is proven in LeanVM correctly, then you can also aggregate signatures for different messages.
benedikt:And I think this is a much…
benedikt:more useful change to LeanVM than adding ZK just for that.
benedikt:especially that… I'm not even sure that ZK is sufficient for this construction to be… to work.
T. Wambsgans:a question,
T. Wambsgans: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.
Gajinder Singh:So, there is that dependency, because first you construct the block, import it in the fork choice, and then you, create, your…
Gajinder Singh:Your proposal attestation, whose head is basically the new block that you added.
Gajinder Singh: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…
Gajinder Singh:We just create the block, import it in the fork choice, and then create a proposal attestation on top of it.
Gajinder Singh: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…
T. Wambsgans: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?
Gajinder Singh: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.
Gajinder Singh:So… so it is… it is not… it is not the attestation for this block. It is basically to be consumed and packed
Gajinder Singh:for the future, for whoever is doing a block production downstream. So, in that sense,
Gajinder Singh:It is not possible, what you're saying.
T. Wambsgans:Okay, I see.
T. Wambsgans:Okay.
T. Wambsgans: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: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,
benedikt:Then we create a virtual lifetime of 2L,
benedikt: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.
benedikt:So… you would just, you know, in slot I, you consume…
benedikt: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: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.
Gajinder Singh:Either a separate key for proposing and testing, or basically, you know, double the lifetimes and sort of index them out.
Gajinder Singh: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
T. Wambsgans: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.
T. Wambsgans:Like, you, you, you, you continue the one that's the children.
benedikt:aggregation kills you, right? Because the one-time key will be somehow lost in the aggregate, right?
benedikt:So if you aggregate the signature that contains the new one-time key.
benedikt: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:Yes, and how do you make sure that everyone sees this one-time key?
benedikt:Because not everyone sees your signature, so…
benedikt: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
Gajinder Singh:Other signatures. Obviously, they will see the key, so they will have to pack it somehow.
Gajinder Singh:In the signed, in the proof itself, right?
Gajinder Singh:So that…
benedikt:Maybe it works, I'm not saying it doesn't work, it's just a bit…
benedikt: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:Yeah, yeah, I mean, you can…
benedikt: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: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.
T. Wambsgans: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:Yeah, yeah, it would be… same… yeah, I agree with that. It's,
benedikt:So what was the problem, again, of taking this… these two messages that you…
benedikt: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: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.
Gajinder Singh:Because next proposer is the one who will be aggregating this with the other aggregates. So… so the question is that if…
Gajinder Singh: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
Gajinder Singh:in the final, aggregated signature, can you drop message 1? If it can drop, basically, what can happen is that
Gajinder Singh: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: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:Yeah, but for the parties who want to verify that Message 1 is part of it, they need to
benedikt:treated as a statement, so you would have two different relations that you prove, so you need two different stocks.
benedikt:So what… what about the following? So this goes back to Emil's suggestion.
benedikt: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.
benedikt:You use that one-time key to sign.
benedikt:And so essentially, what I'm saying is just use a completely different, scheme, signature scheme for proposer signing.
benedikt: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
benedikt:And because there's only one proposal per block, it's fine that you include a new
benedikt: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.
Gajinder Singh:with a different… proposer key.
Gajinder Singh:And, sort of, in the final, final signature that I make, with proposal attestation, I somehow… included.
benedikt: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?
benedikt:We use a very naive, completely independent, stateful hash-based signature scheme, where when you sign.
benedikt:You also publish a public key that you use for the next signature.
benedikt: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: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.
benedikt:That's why we don't want to use this chain-based scheme.
benedikt:So, yeah.
Thomas Coratger:I don't know, it's not the preference.
benedikt: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.
Thomas Coratger:Yeah, exactly. And you update this again.
benedikt: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,
Gajinder Singh:We… since our devnets are short-term, we can just use index 1, so old and even index of the key.
Gajinder Singh:And in the meantime, we can figure this out,
Gajinder Singh:how to do it, because this suggestion, I think, is workable for sure.
Gajinder Singh:that we have… Proposer signature, that is being updated. Proposer key that is being updated all the time.
Gajinder Singh:And…
benedikt:I mean, you can also…
benedikt: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…
benedikt:16 times signature, and then you only need to update your proposer key.
benedikt: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.
benedikt: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:Yes, exactly, and I guess individual validators could pick different, completely independent lifetimes for the proposal key.
benedikt: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.
Gajinder Singh:And finalize this while we are specging out DevNet and implementing DevNet 4.
Gajinder Singh:All the input.
Gajinder Singh: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.
T. Wambsgans: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.
Gajinder Singh:So there were 16 forks that happened, right? And,
Gajinder Singh:Or 17 forks. And on the 17th fork, basically.
Gajinder Singh:You could not enroll your new key.
Gajinder Singh:But… Now your lifetime is sort of over.
Gajinder Singh: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,
Gajinder Singh:With respect to separate keys, or basically audio one. But we still will need message 1 and message 2,
Gajinder Singh: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…
T. Wambsgans: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?
Justin Drake: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
Gajinder Singh: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…
Gajinder Singh:need message 1, message 2, because… If proposer…
Gajinder Singh:At a station is signed independently, basically, then…
Gajinder Singh:It can just be aggregated in the normal way.
T. Wambsgans:Beautiful. Perfect.
T. Wambsgans: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.
Will Corcoran:metrics, observability? Any… Updates that you'd like to… or…
Will Corcoran:Topics you'd like to table this week?
Katya:Yes, hello, everyone. So currently, today, I'm trying to keep the DevNet alive.
Katya: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.
Katya:So I will replace them back, so…
Katya: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,
Katya: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…
Katya:I made some fixes about Checkpoint Sync, and still struggling to make it… to keep it live.
Katya: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
Katya:memory.
Katya: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.
Katya:as well.
Katya:Thank you. If… if this devot, won't recover, I will restart it again.
Katya:Thank you.
Will Corcoran:Thanks, Katya.
Will Corcoran:Any other open discussion topics?
Will Corcoran:If not, I have one.
Will Corcoran:Which is just to… Talk about the schedule for…
Will Corcoran:Cam, this came up, or it was shared yesterday.
Will Corcoran:So…
Will Corcoran: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…
Will Corcoran:Proceed that on Saturday with,
Will Corcoran:a, beast mode day, this is…
Will Corcoran:primarily focus on TK VMs, L1 TK VMs, ETH proofs, Things of that nature.
Will Corcoran: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
Will Corcoran:Requests for many more people than 80, so it's first come, first serve.
Will Corcoran:You gotta do that with these things, otherwise you end up with empty seats, because people sign up and they don't show up.
Will Corcoran:So that being said.
Will Corcoran:really trying to put an emphasis on open forum discussions. We thought that that was really, really beneficial out of Beam Day last year.
Will Corcoran: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,
Will Corcoran: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.
Will Corcoran:With… so… That aside, with Fort Mode.
Will Corcoran:Really, you know, we're gonna start off
Will Corcoran:Justin giving a high-level, introduction, and then Toma talking about the new team, LeanCL,
Will Corcoran:Antonio Santo talking about cryptographic functions, and then Emil doing a deep dive into LeanVM.
Will Corcoran: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
Will Corcoran:perhaps, like, what the 6 months between Cannes and Cambridge will look like, so…
Will Corcoran: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…
Will Corcoran:Raul, the team lead for the networking team, will be presenting ETH P2P.
Will Corcoran: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
Will Corcoran:Cable, open forum discussion, like last year, and end with 90 minutes of a lot of debate and discussion.
Will Corcoran:Talking about… each of… hopefully each of the CL teams that are there, talking about lessons learned.
Will Corcoran:Trying to bring… You know, topics of conversation that we've heard from the consensus researchers, networking researchers.
Will Corcoran:To hopefully align on a roadmap or scope items that we want to build into.
Will Corcoran:the next several DevNets, from that point on.
Will Corcoran:So that's… my little presentation, but yeah, any… any thoughts? Otherwise… We'll leave it there.
Will Corcoran:Excellent.
Will Corcoran:Look forward to seeing you all soon.
Will Corcoran:Spring is… Finally starting to…
Will Corcoran:Hop around the corner here in New York City. It's been a brittle winter. Really looking forward to camp.
Will Corcoran:Alright, have a good day. Talk soon, everyone.
Gajinder Singh:He was…
Mihir Faujdar:Bye. Thanks, everyone. Bye.
Thomas Coratger:Thanks, buddy.
Chat Logs
00:48:08
read.ai meeting notes:Kai added read.ai meeting notes to the meeting.
Read provides AI generated meeting summaries to make meetings more effective and efficient. View our Privacy Policy at https://www.read.ai/pp
Type "read stop" to disable, or "opt out" to delete meeting data.
00:49:18
Bubbles Notetaker:Hi 👋 I'm recording this meeting and taking notes for Tamaghna Choudhuri.
After the call, you'll get an AI summary and action items by email.
Try Bubbles for free🔥 — Turn on automatic meeting note-taking:
https://bubbl.es/notetaker
Remove me from this meeting ➡️:
https://bubbl.es/remove-notetaker?t=PmD5nh62scAaSk2rew9pbxQnUf4HfkVjN
00:49:26
Gajinder Singh:gm gm
00:49:48
Will Corcoran:morning all. we will start in 2min
00:52:57
Will Corcoran:Devnet-4 pr: https://github.com/leanEthereum/leanSpec/pull/426
00:54:12
Will Corcoran:Also: https://github.com/leanEthereum/pm/pull/71
00:54:51
Gajinder Singh:Anshal will be able to update on that
00:55:43
Will Corcoran:Congrats, Kamil
00:57:37
Parthasarathy Ramanujam:The checkpoint sync issue seem to be consistent across all clients. It appears to be working now on zeam. But, we will need further tests to ensure this fix is stable. @Katya should we create a common issue to monitor this?
00:58:23
Will Corcoran:Replying to "Also: https://github..."
Is there anything blocking the devnet-4 spec / pm PRs?
00:58:53
Gajinder Singh:Replying to "Also: https://github..."
@Anshal
01:02:38
Gajinder Singh:also for spec, readiness for leanmultisig for recusiveness
01:05:20
Shariq:Amazing 👍
01:05:47
Parthasarathy Ramanujam:Are we going to retain a single subnet for devnet4 as well?
01:06:19
Gajinder Singh:Replying to "Are we going to reta..."
we will have multiple subnets even for devnet3 testing
01:06:34
Parthasarathy Ramanujam:Replying to "Are we going to reta..."
Devnet3 spec hardcodes the subnet as 1
01:06:41
Will Corcoran:Bag it. Tag it
01:11:52
unnawut:I think subnet_id is currently this, it’s dynamic but num_committees need to be bumped up
https://github.com/leanEthereum/leanSpec/blob/44f896af5f43f71cdafaa993b61b4f4aa99681c0/src/lean_spec/subspecs/containers/validator.py#L31-L40
01:11:55
Mercy Boma Naps-Nkari:It should be code lab with utah
01:12:29
Gajinder Singh:Replying to "I think subnet_id is..."
cool
01:18:34
Mega | Lambda:Why do we want the proposer to both sign the block and the proposer attestation?
01:24:14
Mihir Faujdar:If the proposer signs over the block, could that be treated as a proposer attestation?
01:25:34
Gajinder Singh:Replying to "If the proposer sign..."
hw can next proposer aggregate it?
01:28:02
Kamil Salakhiev:curious how this works with bls today, will check later
01:28:36
Will Corcoran:Replying to "If the proposer sign..."
So, the goal is to have a single proof/signature that can be used to both:
a) verify the block
b) and to aggregate proposer attestations cleanly with other attestations in the network
?
01:29:27
unnawut:Replying to "curious how this wor..."
BLS can sign multiple messages and produce separate signatures at any time, not subject to one time sig constraint
01:29:33
Parthasarathy Ramanujam:Replying to "curious how this wor..."
The issue is due to OTS
01:30:51
Kamil Salakhiev:Replying to "curious how this wor..."
yes, but does proposer sign the same message that attesters sign today?
01:31:05
Kamil Salakhiev:Replying to "curious how this wor..."
if so, we should try to do the same
01:32:05
Parthasarathy Ramanujam:These proposer keys are distributed via p2p?
01:42:22
unnawut:Btw. Separate keys = good first step towards proposer-attester separation too? :S
01:44:24
Gajinder Singh:Replying to "Btw. Separate keys =..."
good food for thought!
Summary
15 highlights
· 3 action itemsExperimental
Summary
15 highlights · 3 action itemsExperimentaldevnet 3 status
devnet 4 progress
devnet 5 design
- DevNet-5 proposal: sign both block and proposer attestation using recursive aggregation00:21:55
- Security concern: current proofs are succinct but not zero-knowledge00:24:10
- Alternative: aggregate signatures with different messages per party using Snarks00:30:52
- Consensus: use separate keys for proposer/attester; simplest secure approach00:37:21