Post-Quantum Transaction Signature Breakout #6

Transcript

Antonio Sanso: Hello, everyone. I'm Mattel. Hi, Salus.

Matteo Vicari: Hi, Antonio. How are you?

Antonio Sanso: All good, thanks. Alessandro.

Saulius Grigaitis: Hello.

Antonio Sanso: Someone. I'm a tail iconor.

Conor Deegan: Finally.

Matteo Vena: Hey, Antonio. Hi, everyone.

Antonio Sanso: As usual, we'll get a few more minutes. For people to join. Today, the presenter is Julio, so I just chat to him, it will be… Coming soon. Hi, George, hi, Nick, I Benedict, A, Mia.

Yannick Seurin: You know.

George Kadianakis: Hello.

Miha Stopar: Hi, guys.

Antonio Sanso: Nope.

Benedikt Wagner: Lou.

Antonio Sanso: Hi, Julia. Okay, I think we're ready to start. As usual, I will have a quick presentation, and then I'll give you the stage to the presenter. Let me share it. Can I see my presentation, I hope? Right?

Alessandro Baiocchi: Yep.

Antonio Sanso: Welcome in, postconement transaction signature number 6. Just a quick recap of the… of the previous, last one, special edition was in Cannes, where we had some hardware support. Presentation 2 in particular. Today, the topic is Test Net Zero, done by Julio, while they will present. It's a work done, Mr. Testnet. And, quick… two quick updates. One bad, one good. So… The bad one is that frame transaction, or any native AA is not anymore a headliner for Hegota. This, yeah, this happened last Thursday. There are… there were a lot of discussion, but this eventually was a decision. This doesn't mean that frame transaction or native background abstraction is not in a photo, it's just not a headliner.

So, we'll have less visibility, potentially. And another… this is instead of good news, and we had some additional parameters set for limited signature use case for Sphinx, so… This means that the signature can be used way less times, I think about 2 to the 20th, or something like this, to the 16th. I didn't read it completely yet. NIST is open for suggestion, if you have any, of course, go directly to the NIST forum. And… but this is a really good news, and we've been playing with this, especially Nico, Emil, other people at Connor, as a nice tool. I've seen Conor on the call. If you want to spend a few words later, Connor, you would be more than welcome. This is a really good…

Things for us, basically. So about the agenda said there's Julia presenting Daisugi, and Testnet, and some work you have done there, some implementation indeed. Here, a reminder of the web as well, the Telegram channel. Probably, I will add in the future a QR code so you can scan, and but if you want to join, it's this one. And, yeah, I'll give the stage to Juliet. And Conor, I've seen you here. If you want to spend a few words about… This good news, you're more than welcome. To take the stage later. So, Julio, it's your time to shine.

Giulio Rebuffo: Okay, can everyone hear me?

Antonio Sanso: Why don't you?

Giulio Rebuffo: Okay, yeah. So… I need to… so I will share my screen just to give… just to show people what I did, first. I think that's, the first good step. So, can you see this? Wait a second. Yes, Julie?

Antonio Sanso: We see that.

Giulio Rebuffo: Okay, great. So, okay, so, first of all, I would just give an… before going into it, I just want to give an explainer of what I did. So. A month ago, when the proposal for Post Quantum was NTT, and it was kind of… when it was NTT, which means the LEGO-like approach, where, like, you have many pre-compass, and you can build your own personal signature scheme, I basically decided to implement it in a live client, it in a live client, in a live devnet. So that's essentially what this is. It… what I built is that… is essentially, you have, like, a devnet, where you have an Ethereum node, in this case it's an Erigon node, that implements, basically.

entity precompiles, and direct precompiles. So it shows, like, kind of the difference between, you know. direct signature verification as a precompile on its own, and then you've got, basically, the legal-like approach, where you have many entity precompiles, and you basically can build your own signature scheme with these precompiles, and with those, I built for 7702 contracts. essentially, I built, basically, the Falcon contracts for… for direct and entity, and then I built the Dilithium one, so MLBSA. And then the fifth thing I did is that, during CANS, actually a bit before CANS, this idea of ephemeral signatures came out, so I also added an ephemeral ACDSA, but this is not a consensus change, it's just a smart contract. It uses SCDSA like all… like before, and so this is essentially what I built.

In a nutshell, that's essentially all there is to it. I will just now just show people this. I mean, by the way, you can… if you go on daizugi.fyi, you can try this yourself. So, it's… you can test this. So, yeah, you can select what wallet you want. In this case, I'm just gonna use the Falcon 5120TPRA compile. You say you generate a key pair, you deploy the wallet, Hopefully it works. Huh? It's… Okay. I don't know… okay, it worked, okay, thank God. And then, yeah, so it's fancy with one if, and then let's say we want to do a swap, right? This is just a sample contract, it's nothing. too crazy, so we say we just swap with you for this mock USD, right? So, you wait a little bit, and

and you've got… essentially, you can do the swap. And if you go in the Explorer, you can see exactly, what precompiles were used, right? So in this case, it's NTT, so you have, like, in this case, you have… the precompiles needed for, for the legal-like approach. There are actually more than the EAP, the original entity EIP, which is now scrapped, I know, add, because, because, because, because those were not enough to make it actually cheap. I mean, you needed the shake. then you need something for the LP norm. And, yeah, so this is essentially, Essentially, in a nutshell, what it is. It's just kind of… you connect to a chain, and that implements is pre-compass, and you can play with this, right?

Now, now, the reason why So… so this… first of all, this kind of made me kind of form some opinion also on, say, entity, because entity kind of requires a specific precompile per any signature state I tried that is not used by any other, so I don't think it really works, but I know it's been scrapped, from what I heard, so it doesn't really matter. But, yeah, and if we want to… okay, this is Explorer, let's not go into it yet. And yeah, so this is, for example, for NTT, for Falcon 52512NT, right? And let's say that… and now, just to show again the ephemera HGSA, because it's a new one, and it's the one that is currently being tested and… or considered.

So essentially what this is, is that you, generate, with, with, BIPS44, fit phrase a bunch of… a bunch of signers, and then you just rotate through the signers, and so, essentially, the logic would be that this is post-quantum, because you don't show… your signature and your public are exposed only for a certain amount of time, like 12 seconds, or however they stay in the mempool, and so this is quantum safe if quantum computers are not fast enough, right? This is kind of the… the thing behind them, and yeah, I'm just gonna show, kind of, how they work, just very quickly. But I think this is… I mean, this is… pretty straightforward, I think, right? So, if you do… let's do the same thing pretty quickly.

Just give me… just give it a second. And yeah, and then here you can see that this is an ephemeral CDSA. And, this is it. Like, there is… this is just a smart contract. It's not part of the artwork. I just wanted to show this because it's a new thing that we had it. Anyways, A few things, about… just a few things about direct compiles versus NTTs, that direct PRAC compiles are much lower in gas, especially lithium. This is because of, if anything, because of the EVM and the fact that you need to… the memory requirements for for the refume, when you do the signature, is something like 30 kilobytes, so if you do it straight in the VM, you have to do… you have to maintain the 30 kilobyte yourself, you need to expand the memory, and then do… and then do a copy from… then also the copy from the signature to the call data… from the call data to the…

to… to the memory, so in order to call the precompile, so… so, NTTR also much… takes much, much more gas. It's not a lot in Falcon, but it's a lot in Dilithium, where it's, like, 100,000 gas difference for that one specifically. And yeah, so this is a, this is a real node, so all of these pre-compiles are already implemented in a node in your network. As you can see, they work. And yeah, so this is pretty much… this is pretty much what I've been doing, right? And let me just get out of here, and yeah, so this was pretty quickly what I've been doing, and… yeah. That's pretty much it. I was actually told that this presentation was to last only 15 minutes, if I'm not mistaken.

Antonio Sanso: Yeah, sure. Yeah, Julia. I would like to share a few questions for you, like, at least two. Do you want to share any lesson learned? I mean, any, any, anything.

Giulio Rebuffo: Yeah, my lesson learned is that… my lesson learned is that don't go for entity. I mean, this is just my opinion, but my lesson learned would be that, any attempt to… when it comes to, at least to post-quantum signature, from what I've been able to experiment with, I couldn't really find a level of abstraction that kind of fits every signature on my roster. Right? Like, the way I would do it is that I would think, okay, you want to create maybe a framework that is abstract enough to the point where you can define your custom signature schemes, right? So, essentially, what you do is that you just look at the operations of each verification algorithm, and you just try to find out common pieces.

Unfortunately, it seems that between Falcon and delithium, there is always at least a piece in both sets that that just doesn't intersect. So you end up with precompiles that only work because of a signature verification scheme and are not used anywhere else. So that means that, essentially, abstract… when it comes to post-quantum, I don't think that… and this is just my opinion, of course, maybe I'm wrong, but I don't think that over-abstructing really works. to be honest, I don't… I think it's kind of like… I think it's just not one of those things where, unfortunately, you can over-abstruct too much, right? So that's kind of… so that's… that's kind of it. Unless you want… yeah…

Yeah, it doesn't make any sense at the end of the day, because if you have to implement one precompile because DVTU needs it, and Falcon doesn't, then you might as well just do the direct precompile. The abstract approach doesn't work. That's kind of my lesson learned, if I have…

Antonio Sanso: Okay.

Giulio Rebuffo: Which is just me.

Antonio Sanso: I see a question here. Before the question, I want to ask for little features. Any chance you can add a link with the… with the… that shows as well… I mean, I've seen that you have… once you do a transaction, you can see the transaction, so you have the… this, Eterscan somehow, or whatever you call it. I mean…

Giulio Rebuffo: Yeah, you can see it in the Explorer.

Antonio Sanso: Yeah, I mean, can you add a link to the Explorer somehow? Yeah, it's not… it's on the homepage, I mean. So it's amazing.

Giulio Rebuffo: You don't… you mean?

Antonio Sanso: Yeah, the homepage, yeah, you can say explore somehow.

Giulio Rebuffo: Oh, yeah, yeah.

Antonio Sanso: I can't This will be useful if you can do this. Little, little request, Julie, if you don't.

Giulio Rebuffo: I will just add them in the chat too, just so that people want to look at them, but I will add Explorer.

Antonio Sanso: Okay, and I see a question here from Candid, and say, may I also have the repo? URL, if they are open source, and I don't know if it's open source.

Giulio Rebuffo: Well, I actually, I think part of it is definitely open source. I don't… remember… I don't know if I… I think Erigon is also… Erigon part is also an open source. I… But I will just show this. So, this is kind of, like, just my experience. Okay, so I shared it in chat. this repository is just basically all of my experiments. There is actually much more stuff, because I just died out from experiments, so you might find some… some weird stuff. But here you can… but, like, if you go to the Redmi, you can see all the precompulse implemented. And yeah, that's pretty much it. You can, you can, you can take a look. I think that's public.

Antonio Sanso: All right. And I see a question from Simon that is asking if this, the cost that you showed, is the cost without the cold data.

Giulio Rebuffo: Yeah, the cost… okay, so the cost on the page is the raw EVM execution. Right, it's neither, like, it's kind of like… so, the cost, the actual gas cost, let me just show you, actually. Let me just go back to this. Let me just show you from the Explorer. So, the cost… this cost here is… sorry, this cost here is the plane, execution, essentially. I think, actually, I got incorrect for the lithium. But, essentially for… it's not really that an eye. I… it's wrong for the RITM, I think for the team, I also put the cold data, but for Falcom, for example. The cold data is, like, 28,000 Gas, and the execution is, like, 5,000 or 6,000. I don't remember specifically, or… but I also probably didn't price them really well. I think… I think that someone told me they should be priced 2X more for Falcon, but the gist is that the…

the gist is that, let me go here. Let me just show you this. The gist is that, right, like, most of the… most of the gas is spent on the cold data. Here is a bit higher, because it was the first time the smart contract was called, but let me find maybe a better one. Actually, no, I probably… probably shouldn't, but yeah, you get the gist, right? The execution is not high, it's everything around it that is expensive, right? It's actually… it's not actually that expensive from a computational perspective to do this… this optical… Yeah, this is…

Antonio Sanso: It's typical with lattice. Alright, if there are no other questions, I thank Julia for showing this. There it is. Is there any work to standardize speakable? There are different paths, different algorithms, and I think it will be interesting to have. Is there a mechanism? Oli, you want to talk rather than type, just by any chance?

Oleg Lodygensky: Yes, sorry, yes, both pages. My point is that there are different solutions that are emerging, there are different, let's say, ERC, ERP, different implementation, different library and algorithm, and I wonder if there is a work to standardize all that so that an endpoint could publish its feature, for example, the available algorithm and all that sort of thing, and also. if there is a work to standardize the IPS, that any, let's say, PQC provider solution could be accessible easily.

Antonio Sanso: Let me take this, Julie, if you don't mind.

Giulio Rebuffo: Yeah, yeah, this is not a question for us.

Antonio Sanso: Yeah. I think we're a bit too early there. I mean, at the moment, like, you know, we started this effort kind of recently. I don't think we are still at that position to standardize. So far, we've been exploring different solutions. I will expect that in a few months, some of the, let's say, the more stable candidates will emerge, and then we can start this kind of discussion on standardized. What I really hope is that we will really have a form of native abstraction. Again, it's not… It's a parallel discussion, but in my opinion, if we will have some kind of, sort of more stable, not even abstraction, also the UI part of the wallet will be way more,

Clar… clear. But this is a good point, Oleg, but I think we have to wait a bit for that.

Oleg Lodygensky: Okay, no problem. Thank you.

Antonio Sanso: Thanks, Leo, for the question. And I was actually wondering, I see you, Conor, there. I hope you… I don't… you don't mind if I call you directly, Conor. Is there any chance you want to share something about this new NIST? thing, and I know, I think you have done some work related, some kind of tooling. If you want to comment on it.

Conor Deegan: Yeah, of course.

Giulio Rebuffo: Oh, sorry, go ahead. Yeah, I just want to say if you want me to, to keep down the… the screen I'm sharing.

Antonio Sanso: I think we've wrapped the topic, unless there are more questions. So let's give the… let's give the stage to… Thanks a lot, Julia, it was really useful. Thanks a lot for whatever you've been doing the last weeks. Thanks a lot.

Conor Deegan: Yeah, happy to… happy to kind of comment on this. This is a bit off the cuff, so I haven't prepared anything, but I can just move on through it.

Antonio Sanso: No, indeed, sorry, I just sent this, like, a few minutes ago that you had as well, at all.

Conor Deegan: No, no.

Antonio Sanso: I found really useful, and actually, I found these things really timely. I knew that NIST was working on something like this, but I didn't know it was already around the corner, so this.

Conor Deegan: I mean.

Antonio Sanso: Does it work?

Conor Deegan: I was a little bit lucky that I think I put this live a day before the NIST announcement. Yeah, we've known it was coming for a while, but we didn't have the exact date. But maybe just to give a bit of context for those who haven't seen it, so NIST put out a request for comments on… Effectively, SLHTSA, which is the hash-based signature scheme for post-quantum, but with a much smaller size, so much less signatures. 2 to the 24 signatures, which is considerably less than the 2 to the 64 standard they have now. This has lots of different benefits, but the, you know, most notable benefit is going to be performance and signature size. So, like, we can see here that

You know, we're now with the most, you know, the smallest parameter set getting down as close to, you know, 3,000. 4,000 bytes, which is getting comparable to things like MLDSA, which is fantastic. The constraint here is you can only do a maximum of 2 to the 24 signatures. That is still wildly huge for most, you know, of Ethereum's use cases. I think arguably most use cases in general. So this has effectively been coming for a while now. They've been a little bit slow to do it. I mean, this document's very clear that, you know, you really have to know what you're doing if you're gonna implement a signature scheme that has an upper limit of 2 to 24. But for something like, you know, I think most… most chains, you know, Ethereum specifically, this is well within reason.

This is very exciting. I think there's two things I'd still love to see from NIST that, you know, I'd push them on, is we could probably get even more aggressive here and bring it down further. I think still 2 to the 24 is quite big. Rotation of keys is so easy for Ethereum these days that we could probably see if we could make this even smaller and more conservative, or sorry, more aggressive. And the other, the other kind of big question is, at the moment, it's standardized with two hash function instantiations, SHA2 and Shake. Obviously, we'd love to see maybe more of a crypto-agile hash function approach, where there's kind of… it allows you to swap in different hash functions, but remain, within the standard. That's not something that's… that's been raised a couple of times for NIST. It's not something I've seen them

really interested in. But the goal there would be something like, you know, Ketchak or, you know, more of a ZK-friendly hash function could go inside the SLHTSA. But that's… that's a bit further away. Right now, all they're doing is saying, hey, we'll give you 2 to the 24. And then very quickly, I guess. about a day before it came out, I just put this tool to live, which is a tool I've been using internally for a while and decided just to make it public. It's very much so a research tool, don't use this for anything important. But it's pretty simple. What it allows you to do is just spin up one of these SLHTSA trees of any size with one line of code. So it's a pretty helpful tool. I mean, it does lots more than that, and, you know, I can send a link into the chat now in a second, but I guess the most interesting part is probably this.

With one line of code, you can effectively input all the parameters you want, and it'll just spit out an SLHDSA instance of exactly that size. So if you look at these parameters, the N, H, D, W, blah blah blah, they're exactly these parameters here. So you effectively say, hey, I want to just test this new SLHDSA24, And you can just use this tool, so rather than waiting for someone to, you know, go and write perfect code, you can just spin it up yourself and then have a… have an algorithm that you can sign, verify key gen. if someone's interested in making this more performant, there's a ton of things I haven't done to make this a sleek, you know, things like caching, to actually get a proper performant instance. Right now, it's more just to be able to have an instance that you can run all the cryptographic operations with.

But yeah, that's pretty much it. As I say, I think there's still maybe some work to do here. I think we can make this even more aggressive from NIST. I'd love to see it go a bit smaller and maybe become more crypto-agile, but… It's certainly better than the 2 to the 64 we had until… until last week.

Antonio Sanso: You know, we had Nick and a call as well, and they were presenting their hardware solution, I mean, you were presenting as well two weeks ago, and I was wondering, like, you… do you think that with less key, sorry, less, less, less signature available, the signature Time will be definitely less, or it will be identical? I mean, it's clear that the size is smaller. What about the time of signing on a ledger, or on the hardware? Will it be affected, or this is something that is not affected?

Conor Deegan: Is Nicholas here?

Antonio Sanso: No, it's not. Adam. Okay.

Conor Deegan: I'm stealing some messages I saw, so this isn't my work. I believe the signing time goes up quite considerably, but a lot of this as well, and I haven't done a lot of research into this, especially on the constrained devices. They do allow us to do some level of caching, and they speak about caching in this document. I think it's just here somewhere? Yeah, to improve signing performance. I haven't looked into this too much, but I believe there is some optimizations you can do to improve signing performance, but right now, it does… it does impact signing time, there's no doubt about it. So we do get you know, smaller schemes, but it's going to be harder on the constrained devices. That's where I think even further aggressive reductions in total signature amount is going to be helpful. And then the best thing for Ethereum would be some sort of crypto-agile hash function, so we could use a precompile. But I haven't… I will throw my hands up and say I'm stealing some of that work.

Antonio Sanso: Again, I'm not worried about the verification at the moment. I mean, I will, but I mean, the question was more about, like, timing. time of signing on a constrained device. Maybe… yeah, Nick, do you know if this is something that can be… or do you think it's faster? With this kind of new variant, or it's the same?

Yannick Seurin: I need that. I think, yeah, again, you can play on a lot of parameters, but… You can either save on the signature size, or save on the number of hashes for signing. But saving on the… on both, it's… It's pretty tricky. So, if you… you could use this number of… this upper bound of the number of signatures, like, 224, with the same size as before, like, more like 7 or 8 kilobytes. and improve on the signing time. But improving on both sides, it's not… it's not really possible, so you have to… Yeah, you have to choose which, which parameters you want to optimize.

Antonio Sanso: Oh, yeah. Physically drill it off.

Conor Deegan: Yannick is… and, maybe not appropriate for this call, but just a… I know KeyGen as well, with some of that caching could be helpful, but is that something that, on the constrained devices, is done regularly, or is it done pretty much once and then, stored? Or is it… is that KeyGen operation something that also needs to be considered on constrained devices?

Yannick Seurin: Yes, you need to take this into account, but from my understanding, it's less a problem, key generation, I think.

Conor Deegan: Okay.

Yannick Seurin: It's interesting.

Conor Deegan: Right, thank you.

Antonio Sanso: Right, just as, like, a comment for people that are not seeing the chat. Julia, yeah, I know the signing time is not important, but if it goes in order of minutes, like Simon said, I mean, it's actually important, right? Because that's actually the case right now.

Conor Deegan: I think right now it's… it is in the order of, like, yeah, upwards of 60 seconds. So I think it becomes important pretty quickly.

Antonio Sanso: Even more, I think, more than 60 seconds, Conradi and Kettle. Last time I said it was more than that. But yeah, I mean…

Yannick Seurin: 6 months.

Antonio Sanso: Yeah, yeah, exactly. and what about generation, you guys were saying? It takes minutes as well, or… Which one is the ballpark of key generation?

Yannick Seurin: Mmm…

Antonio Sanso: And if you have some insights of the timing of generate the key, the public key, of course.

Yannick Seurin: I don't have it in mine, I can try to find it.

Antonio Sanso: Yeah, this would be nice to know. But it's definitely not seconds, right? It goes, like, literally on… And of course, like, even the key generation… Conor, I remember your paper and your talks of two weeks ago. this was working nicely with Lattice, right, to implement that VIP, but this with hash will not be any chance, right, to keep this…

Conor Deegan: It's not a… it's not an option, yeah, yeah, yeah. So, we'll… we'll have to come up with maybe… maybe something a bit more smart there. But, like, there's no, kind of, 32, easy solution with just hash assumptions. You need to introduce another assumption in order to have the public key derivation path. So you'll need the private key material to generate further public key and addresses. Unless you introduce a different hardness assumption, but I think with just hashes, it's not possible.

Antonio Sanso: But it's something you can actually live without? I mean, I know BIP32 and 39 are really nice, but can you live without this kind of… I think that the.

Conor Deegan: The two big issues for that is… well, so obviously, at the moment, it's nice that I don't have to have private key material to generate further receiving addresses. I can just do that on demand from a public key only. That's, I don't think, as much of an issue for most users, but for large institutions where they Absolutely do not want to have their private key material on, you know, hot infrastructure to generate further receiving addresses, and they need to generate receiving addresses on demand. But they want to keep their private keys, obviously, as far away from that infrastructure as possible. That's going to be a bit of a security vector, because that's not… that's currently baked into the security analysis of how they can generate these receiving addresses on demand. And they almost generate receiving addresses, you know, per customer at times.

And… and having to have the private key and memory for that for… is gonna be… is gonna be a security concern.

Antonio Sanso: Alright, so key generation… 50 seconds. Thanks, Yannick, for sharing. So, wow, it takes less to generate… yeah, this is counterintuitive a bit, right? That the key generation is actually faster than signing. Yeah, this is what it is. Yeah, it's interesting.

Conor Deegan: Great.

Antonio Sanso: Yeah. Anyway, this is, this is something… That is evolving. With the… This increase with the 224. Sam, you said that this is increasing with the 224. Yeah. Anyway, another question I will… I have for, I don't know, for people here, you know, this is the things that have been some kind of opinionated things that formed, that somebody did format in the last weeks. seeing people, thanks a lot for everyone that I met at in Cannes, that was really useful. And basically, like, my ideal take at the moment is, of course, like. For the long run, to go with the Lind Sphinx. But for the short term, the idea that I have, or, like, the consensus, probably, I hope, will be formed, will be around to use ephemeral keys for, like, transactions that are

are not too cost… so, I mean, they don't protect too much money, so, like, I don't know, cents, dollars, value transactions, like ephemeral keys, and something like that lithium for transactions that are actually worth… More than a few dollars. And without precompiles, because, yeah, another lesson learned over the last years is, like, precompiles are a kind of different beast. But in order to do that, probably the only direction that I consider safe is having solidity contracts that are formally verified. And, yeah. We need… we need to do that. And, in order… in order to… to be safe, I wouldn't go with the random… with the random, Solid contract. I was wondering if anyone in the… in the… in the… from the participants has some experience about

Formally verified solid contract. This will be a useful information. Otherwise, I'll need to figure out, Who embeds some of the next calls? And is that… is anyone… is anyone, like, has any comment about what I said about the strategy? Any sort of disagreement or agreement? Of course, I see many people that are biased, like Matteo, that… Okay, Adrian Krub. Okay, I will send an email. Is it… Oleg, someone do you know? Personally? Open Zeppelin, okay. Morail. Sir Torah. Sertora is… is… This is another company, Mattel? Okay.

Thomas Coratger: Maybe, Antonio, can you explain why we want this dual design? Why it is not sufficient to have ephemeral key for everything until 2029, for example?

Antonio Sanso: Right. I mean… It's… the problem, like, I really like, I'm a big fan of the ephemeral kiss… teachers. the problem is, like, it feels a bit like cheating, somehow, because it's not really post-quant, right? I mean. there's been some development in the quantum computer world. We've seen, the announcement from Justin on the paper eco outer with Dumbone and Google DeepMind. And yeah, at the moment, it's not taking minutes, it's taking… it's not taking seconds, it's taking minutes. But we, as well, we know that, attacks, they only get better, so I will expect that this quantum algorithm that… to solve ECDLP will be faster and faster. And, so, yeah, probably we can live a few years, but how many years we can live with that, you know.

it sounds like a risk, so I would be probably… I'm not saying we cannot live, but maybe for transactions that are really… Important? maybe not staying with that paradigma and using some really post-quantum algorithm, like Dalitium. Might be a good idea. I hope it answers your question, Thomas. As he looks…

Conor Deegan: There's a question, maybe, Antonio, too, about that. You said that lithium, is that… is that something you're… More interested in than… Like, one of the more aggressive, smaller hash-based, even if the hash-based is seamless.

Antonio Sanso: No, no, I'm… even… I mean, at the moment, it's anything that will work with a ledger, to be fair. Yeah, yeah.

Conor Deegan: Gotcha.

Antonio Sanso: So, the only round trip so far that I've seen working, that use a ledger and being verified on-chain completely, that I've seen is the one of Simon, that is here on the… and, you know, like, he showed in a couple of times already, last time in Cannes. that you can actually do a full round trip with the, with the lithium, and the message you sign is actually in clear. So you sign… you know what you sign? Simon, I don't know if you want to comment on your demo. I mean, I think you've already done a demo. What's the demo that you did here, the same that you did in Cannes? Or you didn't have the code when you presented here?

Let's see if you're answering the chat. All right. I see some question on… we're pretty interesting… That's it. Almico. Hi, Nico. Do you have some comments about the new NIST announcement? Is something that you've been playing with?

Nicolas Consigny: Hello, yes? I've been looking into it. It's… it's quite interesting that they reduced the signature target. But it's still quite impractical for a hardware signer. So, like, in the context of a ledger device, we're, from what I can measure. We are around 1,000 or 2,000 k-check per second. And, the new… Parameters give a few million. K-check for, the signing, so it's not really tractable on a hardware wallet, at least from what I can measure. So yeah, it's a… it's a good progress in the right direction, but it's still… not exactly the use case that we want for blockchain wallets, this last… I'm talking about this last, NIST publication about a smaller version of SLHDSA, yeah.

Antonio Sanso: Do you have anything juicer for the short term than that? Is, is your, is your, parameters that you've been playing with is better than this one from NIST?

Nicolas Consigny: Yes. So, in the next few days, I will be publishing a small research, post on parameters that are friendly to the EVM. And yes, to answer your question directly, I… I have a slightly smaller verification cost than the one that just… that has been published, but also I have, like, a hundred or… Between 100 and 1000X. A reduction on the signing time, so this makes it… More hardware-friendly and more adapted to To… to the EVM constraints.

Antonio Sanso: I'm really looking forward. Do you consider, like, you know, since the NIST is kind of open for comments, are you planning to give this back to NIST, like, comment with your parameters?

Nicolas Consigny: Yes, actually, we're sending… there is a NIST workshop tomorrow, I think, in New York, or… yeah, I think it's tomorrow in New York, and we're… We have two Ethereum Foundation representatives that will be asking a bunch of questions. But anyway, my parameters are out of the NIST, FIPS, description, because we are using Kitcheck to instantiate the function, so… I mean, whatever we're doing is already quite far. From the standard itself, so… Yep. I don't expect NIST to move, into a different… Hash function, so… But yeah, it would be interesting, maybe, if they can give some guidance on how to substitute the hash function, even if it's not really standardized.

Antonio Sanso: Alright, looking forward, by the way, your post, your… I don't know if it's gonna be any print or blog post or whatever. And if you feel like, once it's public, to come back and present, I know you've been already doing, but happy to see updates and upgrades on your work. This is really exciting. Okay, let's see a bit of the chat. So Matteo… so, Matteo, have been a pretty interesting update coming? Okay, yes, Matteo… Matteo, You're already in the agenda for two… in two weeks, so looking forward to your presentation as well. It's okay, two weeks, right? I think…

Matteo Vicari: It's perfect.

Antonio Sanso: Okay, perfect. So, Julio, essentially, if someone makes a transaction that hangs in the example that it can happen with high immigration. I had the things bending for 3 days, okay? See, Julio, valid comment, but yeah, maybe with FOCIL and stuff like this, but it's a valid comment. So, Gotti, I'm also concerned about the femoral case. plus censorship. Yeah, got it. To answer your question, maybe with the FOCIL, it's something that, FOCIL helps preventing your attack, or your concern?

Gottfried Herold: And not, I mean, yes, in some sense, yes, but for that, I mean, you would have to actually use FOCIL for everything, which I don't envision would happen. I mean, same as what Julio basically wrote, that if, sort of, the transaction hangs too long in the mempool, it's not clear how much security FM royalties really afford, unless we have a really tight underground on that. It's just, yeah, some kind of ugliness of this kind of solution.

Antonio Sanso: Right. You understood as well that the fact that I will feel encouraging these kind of things for transactions that are not valuable million dollars, like, really for stuff that you can afford to, like, you know, normal small transaction that is not the end of the world if something happens. Okay, Simon, Andrew here. The link is here. Okay, so the things you presented here, the thing you presented, Simon, the things you presented in Cannes is different. Will you be okay to present a full round trip of Dalitium in one of the future calls? So, it would be really nice to see and have people… Again, so far, again, you guys know that I'm a big fan of Falcon in the context of blockchain. The problem there is really, like, we don't have…

the full round trip that a person will use, for Ethereum, so… Signing with the hardware wallet, and even stuff like multi-signers. So, I think that for Falcon, at the moment, the chance to see Falcon used by by Ethereum is fading in favor of the lithium, even if it's the… The keys is bigger, and the gas cost is bigger, but at least you will have a nice experience with the lithium. So, Alexandro… no, Alexander. Differentarchy settings, we still need to publish the public case map in advance, no, but… Your seeds will… Okay, yeah. Alexander, I hope that Matteo answered your doubts. It's mostly the same, we show the ledger integration. Okay. Okay, Simon, so basically muscle the same, just the ledger part.

All right. Nick, a quick question for you, if you don't mind. You said that you intend to formally verify your verification, the contract. Is it correct?

Nicolas Consigny: Yes, so formally verified, as in… I am trying to, get a… a lean implementation of, the contract. So this is, using the Verity project, where you can get your lean codes to compile to… down to the EVM bytecode. But this is just, like, the contract. It's not, like, a cryptographic security proof. Of the… of the scheme? So yeah, and ideally, I would like to do both. And… If I'm not mistaken, I think, I'm… I found some nice, projects from… Yannick Soren from Ledger, who has a library to do, actually, the… Verification of, cryptographic, security schemes. So…

Yannick Seurin: Yeah, it's very basic at the moment.

Antonio Sanso: Okay.

Yannick Seurin: That's more for experimenting with LIN and what you can prove about cryptographic results in LIN. And it's very basic, but there are other, like, VCIO, there are other libraries to, to prove, cryptographic results in MIN. If you're interested, I can… Send the links in the, in the chat.

Nicolas Consigny: Yes, I would love to.

Antonio Sanso: Same.

Nicolas Consigny: Actually, I'm not doing very complex things, so even your basic library could be enough for me.

Antonio Sanso: Before you join, actually, the reason I asked, because you joined, I was advocating for the fact that since we are not using precompiles, and we're gonna use, probably, again, probably. solidity for verification of post-quantum algorithm. For me, it's really important that we have, this, verification to be formally verified, or as much audited as possible, but formally verified… formally verified will be the, like, the best… case scenario. And, I think… I think given the fact that you are doing for your own verification, I think you agree, right?

Nicolas Consigny: Yeah. Yeah, it's super important.

Antonio Sanso: I see Gotti here, only using formula keys for a regular transaction, what matters in the value of the account? Yeah, yeah, yeah, sure. Yeah, yeah, yeah, Gotti, I agree, I mean, I meant, the value of the account, and so… so you, you will use this, like, for…

Gottfried Herold: Yeah, I just wanted to clarify this, because it's sort of a… for use from a UX point of view, it's sort of… it's important to distinguish these two things.

Antonio Sanso: Yeah, and again, like, to be fair, what I will try to do as well in the next weeks is to try to clarify, because, I mean, it's true we need to choose, Introduce, like, the next algorithm, and so on, but… what is not clear to me is a proper UX. Again, the fact that I can't abstraction, has been, not accepted to be in Negota, so I had to learn is the bad news for us. And having a proper UX for post-quantum signal, in my opinion, is as important as choosing the next algorithm. Otherwise, there will be not a lot of chance to have adoption. Is any of the participants working more into the UX thingy, rather than the cryptography?

in order… because I'm looking for someone… presenting or doing some work into the UX space for Post Quantum. And, I've been inviting people to think about UX first as well, because it's, again, it's… we want to have a flow that makes sense. We don't want, like, to make this hard to use, otherwise there's no chance we're gonna see any adoption.

pbark: Hi, Antonio. I've kind of been focusing on UX, because I've released my free test wallet. But the way I've designed it, so it's on Sepolio, but I've integrated QR codes for sharing addresses, and I'll do that as well for sharing transactions. Because I think that's important for user experience, is just avoiding Pretty much anything technical, including, having to write out addresses. You're muted if you're trying to talk.

Antonio Sanso: Oh, sorry. I said, yeah, again, like, ideally, everything will happen inside the wallet, so everything will happen inside MetaMask or inside Ledger without, like, having back and forth between, I don't know. pages or copying something manually. I mean, this should be as… as lean as possible, in terms of UX, and… but we cannot do this without the help of the people involved into the wallet, so we probably will need Some people from, MetaMask joining, this calls Rabbit, likely we have people from Ledger joining already, but we need more people from wallets, collaborating, otherwise we'll… I don't see this… this… this flying. Again, if account abstraction will be integrated into the protocol, and wallet will integrate Nativeacant abstraction, then we'll have it for free. But that's why I'm so keen to have Nativeacant abstraction.

Anyway… I don't have much more else for today. Thanks again, Nick, for sharing. the… Approach basics are… didn't work and decrypt. Okay. Let's open this link inside with the knife. Completing the Chamber of Emperorial Party Signature and their security. Alright, and I know about this paper. Yeah, Nick, thanks a lot. I was saying, unless you don't have some comments, I will… I closed the call 10 minutes before today. Next, in 2 weeks, we have a more packed agenda. So, do we have at least two presentations, and less time to discuss. Today was more… more discussion, and yeah, if no one else has any other comment, we're gonna see you in two weeks, and, thanks a lot for joining.

And, yep. I don't see anything else in the chat, so it means that you are fine to close 10 minutes before. And see you in 2 weeks. Thanks a lot. Thanks a lot for everyone for attending and participating.

Thomas Coratger: By the way.

Conor Deegan: Bye. Thanks so much.

Miha Stopar: Thank you. Bye-bye.

Yannick Seurin: Right.

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