Post-Quantum Transaction Signature Breakout #14

Transcript

Antonio Sanso: Alright, so let's start. It's, 301. Welcome, everyone, to the post-quantum Transaction Signature Number 14. It's September 2, 2026. Today, the idea was to talk about hash-based stateless signatures a bit, but we will have some just discover some, new guests that will talk about ML DSA, some optimized contract. And indeed, here, so far. are the two presenters, Nicola, that presents some PQ1 hardware wallet, and then we have Oren with this optimization of MLDSA, if… You didn't, I will invite you to join the Telegram channel. Here is the QR code, and the link for the Telegram. I put in the chat as well the link of Telegram, just in case. It's a… we discuss here mainly things related to the Transaction signature, the post-quantum version, of course.

Before to start with Nicola… Nicola, are you on Nicola already?

Nicola Ceornea: Yes, can you guys hear me?

Antonio Sanso: Yeah, I want a few slides quickly, and then I will give you the stage to you, alright? Oh, I don't…

Nicola Ceornea: Okay, sorry, I don't have any slides, so…

Antonio Sanso: Okay, you will share the screen and do a demo, or…

Nicola Ceornea: I tried to do my best. I've, I've, didn't have too much time to prepare, so if I… I'm going all over the place, that's because it's exactly what I'm doing, so… Okay.

Antonio Sanso: works for me, just, like, a few slides, and then I'll… you share your screen, right?

Nicola Ceornea: Sure, I'll… I have some, like, demo devices I can show.

Antonio Sanso: Perfect. Cool. Let me actually just go with my few slides, and we'll go to you. So, just a little update. Here we have Justin on the call as well. Justin did some update to the strawmap, recently. some relevant for us, I will… introduce, and let's navigate a bit here. So, we are here right now, actually not perfectly there, but we're a few months away. from Ship Glamsterdam. And what is going to be relevant for us in the near future? The first things is from transactions, because as we know, we are gonna really, focusing on, and moving away from EOA, And this will happen in Hegota, it's already kind of CFI'd, so this means it's scheduled.

And then we'll have this gray box here that is not depending of any of the three layers, so it's not, unique for execution or consensus or data-availability layer, so it's there, and there's nothing else that the virtual machine that hopefully is going to be shipped by I-Star. And then, this is, of course, where… what we are working for in these calls, and it's the post-quantum replacement for ECDSA that we call, Lean SPHINCS, as the name says, is a hash-based scheme. And why we've chosen this, Well, as we said, this is not a hash base, but just to make the choice of account abstraction and the skim per se. We… these are our, kind of, three pillars. There are account abstractions, so I said, we… we're gonna say goodbye to EOA, as we know.

The other things that we kind of, choose so far was to not ship any precompiles. The reason is mainly we had bad experience with, cryptography-related precompiles. I'm a bit sad to say that, being actually one of the co-authors of the BLS precompiles, we kind of fought to introduce BLS precompiles for years, then eventually we managed. then no one uses it. And now we have this kind of legacy, especially for the snarkification of EVM, and yeah, it's not easy to have. zkVM and cryptography precompile. So, if we can, we are not gonna ship any cryptography-related precompiles like, the algorithm. Like, no cryptographic algorithm that has precompiles, like, DSA, MLDSA, or Falcon, or even things.

And… and then we as well want to align our… and being homogeneous in our… in our stack, so since we moved to hash-based cryptography for consensus and data-availability, well, all these three pillars will bring us to Lean SPHINCS. Now, Bing has best cryptography, you might wonder, which… hash function we're gonna use, this I stole from Justin, and saying that we… he announced it a few weeks ago, that we are moving away from Poseidon. Mainly, the reason is because we can actually prove, fast enough, thanks to this new system, Called Flock, that is based on Banner Fields, so now we have some really great performance with Blake and Shaw, so we are actually… we don't need any more… too much Poseidon.

And, yeah. So, we still don't know which specific hash function is going to be Blake or Shaw, but we know that it is not Poseidon. Now, about… let me spend a few words about, SPHINCS, Solidity SPHINCS. I use this tool from Riva Labs to do a bit of a talk. This is the URL. It's kind of useful, because it is really… To understand how things work. Just a quick recap, the, the red part. 4, so a few times signatures, these red triangles in the, in the… In the lower part, and the blue are XMSS3, and so this is the HyperTree. Now, for people that know how SPHINCS works, there are a lot of toggles, and each toggle is a part of this big tree.

Now, these parameters are related to the official SLH DSA128S, that is Level 1 choice of NIST. And as you see, like, the parameters are kind of… in terms of spatial size, are not great. It's almost 8 kilobytes. And, the other things that we're interested for our use case are the gas that we need to do on verification, the number of hash used to sign, and the signature budget that for, SPHINCS Plus, is about 2-364. Now, NIST, they kind of realized that 2-64 budget is huge, maybe… too big for many use cases, so they did this additional parameter back in April 2026. Just let's see how they look like. Again, they moved this toggle, and as you see, they have one big… so only one XMSS3, but huge.

It's the… the height is 22. And this, with this toggle, they target 2 to 24 signatures, I said, way less than 2 to the 64, and their target was to reduce the signature size, so it went from almost 8KB to almost 4KB, And you say, okay, now this is perfect for blockchain, but actually this is not the case. The main reason is the number of hash that you need for signing, that is astronomically big, indeed, it's 1.45 billion, and this… means that if you actually implement this on Ledger, it will take, I don't know, hours or days, I don't think anyone ever tried, it's huge. So, still not good for, for, hardware. We have as well, Nico did a lot of experiment.

on the various variants of SPHINCS-, and he has this website called sphincsminus.org, where he showed, some experiment. Here, I'm just showing one that is called C12. And it looks like this, and it's targeting 2 to the 14 signatures budget. And, As you can see here, There are, the toggles are, again, different. And, just discussing about why he chose to the 14, well, he analyzed the mainnet, and he noticed that 99.99%, of those sent less than 3,000 transactions per year, so those mean 99% of addresses in the year 2025. So, 2 to 14 is a kind of number that will suit many scenarios.

E was optimizing not for signature size, but for signing cost. Indeed, if you see the… both the actual signing cost and verification hashes, and you see, indeed, like, the signing cost. In number of hashes, it was only 37,000, way less than 1.8 billion. And, this is a comparison between, this, This, variant and the standard one. And, so when he tried this to implement this on a ledger, it's still, even with only 37,200, hashes still take 45… 47.5 seconds on the Ledger Nano S. But recently, we had this new experiment by Riva Labs. I actually tried something on Daniil for the slides, like this video that they shared on Twitter.

And we have the Riva Labs guys as well here on the call, and basically they managed to sign, on a, again, on a Ledger Nano S Plus in 1.5 seconds, and their security budget was 2 to 24 signatures. Now, you might wonder how it's even possible, and there is a combination of few things that hopefully will land on a paper, kind of soon. And basically, like, there is 3 realization that, again, we're not super secret, we just put them together, just, of course, like, it's a nice engineering work. And, yeah, the personalization is that there is a part of SPHINCS that is public and can be computed outside of the security element of the ledger.

And then there is this precomputation on public value happening offline, and ahead of the actual signing operation, and then during signing, there is a kind of grinding. That's basically how it works at a high level. The idea is to formalize and analyze this construction cryptographically and put some more technical paper on the print. And, there is as well some experiment and stay tuned on some non-standard SPHINCS variants. The second bullet is not by Riva Labs, it's by other people in the community. And then, of course, like, as I mentioned before, we are working as a community on Nativeacon abstraction being shipped in Nagota, and the idea is, formally verified the signatures. contracts in lean form.

And that's basically what I have. I didn't look at the chart. Let me actually look into it, if there are questions. Okay, let's see some questions. The CFI now… okay, thanks, thanks, now it's, CFI for… you meant the count abstraction, right? Like, the frame transaction, thanks a lot. Proof of work is back, baby. Well, you mean about the grinding, Florian? Sorry, Justin?

Justin Florentine: I was just joking about the insane number of hashes required for the.

Antonio Sanso: Okay, okay, okay, right. And there's a… I will say that the main drawback is key generation, caching the intermediate nodes in the Merkle tree. Okay, for which variant, this is… this comment? I think the… I read this, I will say that the main drawback is for keygen. Which of the variant? Okay, we'll move to the next one. It's Simon. The main cost in a ledger implementation is the key generation. What is… okay. I will… Simon, I will let you know the… the next time the numbers of key generation, alright? I didn't have… I don't have numbers at the moment. But you're correct. Key generation is the one, further access to take. In consideration, But… Yeah.

So, with this in mind, I will move to, the first presenter is Nicola. stage is yours. You can share the screen, I guess you need to ask.

Nicola Ceornea: If I need it, I will say it. Thanks. I already requested, I mean. Yeah, so… Let me know when, I can start.

Antonio Sanso: You can. Stage is yours.

Nicola Ceornea: Okay. Okay, thanks. So, firstly, thank you, everyone for having us here. So my name is Nicola, and I'm the CTO of Freedom Factory, and we are building something called the PQ1, play on board of post- Quantum 1. And basically, so originally, we were, building, NCR maintaining this device called Legion1, and we were already working with, account-obstracted wallets. And on April of this year, we started, you know, of course, we were watching the news cycle, etc, and we were very interested about all the news that were going around, okay, Google making huge triads on… optimize the specific, ways to crack, ECDSA signatures, and it was like… and we were thinking, hey, wouldn't it be nice if, with our…

cons of section, that we have on Ethereum if, we can somehow already do something to, you know, not use ECDSA anymore. And, long story short, we got in touch with Nico, and he showed us his, SPHINCS Minus. Project that he worked on, and after some deliberation, we were thinking, hey, this could actually work, and So we started the prototyping, like, hardware wallets that used SPHINCS Minus, specifically C10. And, we went with, initially… let me see if I have it here… yes, this board. It's called the STM42U585, and it's just our Cortex-M43. And we also decided to pursue an approach similar to, let's say, Trezor, where they have a true secure element system, and through a system on STM called Trust Zone, you can essentially gate off a part of the chip.

So you have, like, this non-secure world, a secure word, and so what you can do, with this is, you can take the keys… so we split the keys in two, in XOR configuration, in one on the OPTIGA Trust M, and the other called the, NXPSE050, and then we get to recombined in, the, secure trusted environment, and then we use this to, do signatures on the device. And, so with our chip, with our silicon that we are using right now, we were able to achieve, like, a complete on-silicon signature time of 1.1 seconds, more or less, and onCold, something like 3 seconds, partly because the STM42 has, SHA-256 accelerator, which is very helpful. And, On top of it, we were also doing, other couple of things, which maybe are not super related to POSQ Quantum, but, you know, clear signing, with ERC 77730.

which we are a huge fan, and I'm also very thankful for the project which has been set up on GitHub, which we are also taking advantage of to… as inspiration. And, we very, a couple of days ago, we got, actually, the first, real hardware, so EVT device, and I really wanted to show you guys a demo, but sadly, we were not supplied the screen, and there is a funny story about how they use a very specific connector for the screen, so… It's really been very, very hard for me to, break out this display, and I was actually able to bitbang a couple of pins to show sunscreen, but I have not soldered anything. Didn't have much time, sadly, and so, I think it's going to,

Take a lot of time to set this up and show it to you, but that's, basically the very small gist of what we're doing, and all our code is, currently open source. It's still very, very, very work in progress. Like, the provisioning of the secure elements is not complete. Actually, I also have a… whoops, this one. This red chip is the OPTIGA Trust M, and I already bricked free of those, so that's the reason why we are not provisioning them right now. But, also, you know, there's, the, first stage bootloader, which we're also trying to get done, and, what that would allow is, basically we're going to ship them unprovisioned, in the sense that the firmware is there, but the silicon is not, like, burned, so, like, the option bites. So you can still check for yourself, okay, is this, like, the legitimate firmware running on it? And then the user has the chance to,

Yeah, burn the fuses, or, like, the oxytes, so that it locks Into, like, production mode. And, this first boot, first stage bootloader allows us to, make a portion of the, flash, read-only, so we can do a fun thing where on each boot cycle, you… the firmware actually gets… gets hashed. And it's shown on the screen as, eight words, and you can compare them to, you know, publicly released words by us to see if you're actually running, like, a genuine firmware. And, A little bit more trivia if, the reason why we choose this specific set of chips, meaning the STM plus the two secure elements, is that, by our understanding, those have not been able to be, you know, fault-injected, or, like, crazy acts happened on them, so we feel pretty secure about them.

And, of course, as always, we rest on the shoulders on giants, like, Trezor, where we took some inspiration with the firmware. Thankfully, they also have a big portion of theirs open-sourced, which we are really appreciative. Every day we learn. from, The big, people of, Ethereum and None, and, yeah, so… that's Kadar.

Antonio Sanso: Thanks a lot for showing what you have so far. I see that it's really a work in progress, and I hope you guys are… any of you will be back once you have more shiny things to show. So far, it's been useful, what you showed. I'm not dismissing that. I'm just looking forward as a user for a demo. Do you know.

Nicola Ceornea: Yes.

Antonio Sanso: Like, the, the target, like, signing time, or… or what, what, what, how long… do you have some forecast, or some, some prediction of how much is gonna… take to sign. This is… any of the variants you have in mind.

Nicola Ceornea: Yes, as I said before, so we… in our testing with C10, we were able to do a signature on the silicon in about 1.5 seconds, and on cold boot, so with the key derivation on top, like, the first time, it's probably going to be something like 3 seconds.

Antonio Sanso: Alright, and… which hash function?

Nicola Ceornea: So we're all using SPHINCS Minus, so, You know, the one that you discussed before.

Antonio Sanso: Yeah, but I mean, with, like, a chateau, black, chatere, you know, which is…

Nicola Ceornea: Oh, it's so true, it's so true.

Antonio Sanso: Me too. Okay. I actually take the chance to answer Simon, I think, still in the call. The key gen, actually, for SPHINCS, is not taking too long. I've just seen some, some, like, numbers that has been shared by Blockstream in the couple weeks ago, and for Ledger, Nano, for example, takes 15 seconds. So, I think for Key Genesis, it's kind of fine.

Nicola Ceornea: Yeah, of course, it depends on…

Antonio Sanso: That's true.

Nicola Ceornea: Consider… yeah.

Antonio Sanso: I mean, no, not signing. I mean, KinGen, I mean, me as a user, I mean, if the King Gen takes under 20 seconds, it's… I mean, it's fine. The first time I set up the device, like, I unbox, I plug in, I put my… get the SID phrase, and… Having, like, I don't know, 15, 20 seconds? to, like, keygen once, I don't think it's a bad experience, no? It's okay.

Nicola Ceornea: No, probably not.

Antonio Sanso: I mean, signing is another story. If it takes every single time I sign… Yes, of course. But for keygen, I… I don't think it's a big issue.

Nicola Ceornea: Yeah, so first, I think somebody asks, signature, budget, it's, $65… like, I'm running it up, like, $65,000 per, Per slot, so each slot has 65,000.

Antonio Sanso: If it's… if it is to the 14, it's 2… sorry, if it is C12, it's 2 to the 14, Matteo, like the signal badge, 2 to the 14, the… the one I… You said it's the same on my slides, right? C12 is to the 14, and Web Nico and the coal, so it's 2 to 14. Cool. Really nice. Right. Any question for Nicola once he's here? I have one, actually. When do you think people will have this device on hands, more or less?

Nicola Ceornea: We are planning for, this year, Q4, and, also for the people that would like to test it right now, all our code is open source. If you get this board, so the STM585, the IOTA 2 board, you can actually run it right now. So it's, I think the, the border, it's, something like 50 bucks, and with the two secure elements, you're probably going to, like, something around $100, but those are evaluation boards, so you have… you account for the price of those. But, yeah, all our code is completely open source, and you can then.

Antonio Sanso: That's…

Nicola Ceornea: today.

Antonio Sanso: I think you're targeting, like, for ACD abstraction, not native right now, right? So you, you will, you're, like, you, you heavily use ACD abstraction, correct?

Nicola Ceornea: Exactly, it's, we are using a modified version of the base smart account.

Antonio Sanso: Okay, and is your verification contract, like, audited or formally verified?

Nicola Ceornea: is still, we are auditing, so we're in the process of getting it audited by Trail of Bits.

Antonio Sanso: Any chance you can aim to formal verification within Lean, instead?

Nicola Ceornea: We are, so I'm testing something, So, we are testing… so there are a couple of things that we're doing. There is a… for Rust, so our firmware is written in Rust, there is a stack called… so a couple of tools called Ainas and Sharon, I hope I'm stating it correctly, that you can use to basically translate the Rust code into Lean code. And, we are also, doing some experiments with AI-generated, of course, not audited right now, but, we're trying to do this first and see how far we can do that.

Antonio Sanso: Nico. I see your hands.

Nico: Yeah. Thank you for the presentation. Amazing project, love it. I saw that you did a… some work with easy crypts, if I remember correctly, to… Give some formal verification of the… of the SPHINCS.

Nicola Ceornea: Yes, yes, I'm… Yes, we are doing some, is Ecrypt as well, in the same fashion as we do in Ling, so, most of it is, so currently, like, we are, we are testing with, like, AI approach first, and, then, we'll see how we can, you know. Test all this stuff.

Nico: Okay. Yeah, this is great. Keep us up to date if you… if you manage to get some proof with either, Is it ripped or lean? Yeah.

Nicola Ceornea: Yes, I'm… I'm really interested in pursuing this, it's, it takes a lot of time to do, like, each individual run, so every time, like, I want to run the stack, it's, like, one hour, just for it to compile, so, it's moving slowly, but, I think we are seeing some progress.

Antonio Sanso: And are you going to be at DEFCON this year? Any of you?

Nicola Ceornea: In Mumbai, I assume?

Antonio Sanso: Yeah.

Nicola Ceornea: The plans are to attend, yes.

Antonio Sanso: Okay. I can't remember who proposed me, I think maybe even Matteo from Riva, he said that it would be nice to have, like, a kind of room dedicated to Post Quantum, so if we're gonna… if we manage to organize a room where people can showcase stuff. And, I think it's a nice idea. And so, if you're attending, and you can bring some of your device, and…

Nicola Ceornea: Oh, of course, yeah, for sure. I have… I have so many, like, dev boards, like, that I got, from, from our, distributors, and, I'm… I'll gladly demo around and, and, you know, just show it. I think we're also going to, talk about, so, like, So, we also applied to be speakers, for, Open-arter and stuff, so we will be talking about that too.

Antonio Sanso: Alright. This is, again, Becky comment from Simon. So, Simon, are you okay with the timing I gave you, like, 14 to 20 seconds? Actually, less, less than 14 seconds. The word was 14 seconds for Kijen. Are you okay? Because I see your new comment on the chat. I assume yes. If we don't have any more questions about SPHINCS, or SPHINCS Minus, or C12, or any question for the demo of Riva, we are moving.

Nico: Oops.

Antonio Sanso: So.

Nico: I have one small question. Sure. Yeah, just more of a comment for Nicola. If you manage to get, devices ready by DEF CON, We will have a special hardware booths, where you can, inspect hardware devices. And we are going to bring some big machines so that people can check that their hardware is exactly what is.

Nicola Ceornea: That's…

Nico: to me.

Nicola Ceornea: That's awesome. Actually, I don't want to drag it too long, but, there is, so Ledger Dungeon, you probably guys know it, they have, like, this thing going on, which we… I got produced, and, so we're going to do, like, fault injections, on, on the boards with this. Plus, I also got, like, this, to do, like, voltage glitching and stuff like this. So I'm, we're trying, I'm trying, I'm trying my best.

Nico: Amazing. If you can bring some device, this, like, it would be a very, very nice move to do.

Nicola Ceornea: Yes, we will actually have, like… almost complete devices by next week, so the 15th of September, sorry, like, with all the enclosure and most likely the final revision of the hardware, so we're going to move to that, and I'm sure we will have plenty of devices to bring with.

Antonio Sanso: Alright, I second this comment from Simon, that, Simon, why… why do you think that you need GetGen every time you sign? I am a bit confused. You can speak, because you don't want to write.

Simon Masson: Can you hear me?

Antonio Sanso: Yeah, yeah. Yeah, you say the keygen every time you sign into the keygen. This is stateless…

Simon Masson: just because it… in hardware implementation, usually it's like this, you don't implement… you don't store the secret key and public key in the ledger, you derive it at every signing step. At least it's how we do it in ECDSA, or… even for MLDSA signature. You don't want to store the key completely on the ledger, but maybe there are some… some architecture where you could do that, I don't know.

Antonio Sanso: Yeah, I don't think we need GetGen every, every, every time you sign. I… Right. But, yeah, good…

T. Wambsgans: I think you.

Nico: You can use the cash, yep.

T. Wambsgans: Yeah.

Antonio Sanso: Right, exactly, yeah. But I… and I understand at least why you said that. Okay, got it. Again, if no more questions, we move to Oren, and, thanks again, Nicola, for the… for the nice demo.

Nicola Ceornea: Thanks for having me, I appreciate it.

Antonio Sanso: First. So, next is Oren for Fireblocks, and we changed a bit of theme here. And, we go back to Lattice somehow. And, showing some, optimization. of, MLDSA, and, Oren stages yours.

Oren: Yes, just wanted to, very quickly share, what we did recently. We tried to get, MLDSA on the EVM, optimized as much as we can to see if we can lower the 8 million gas that, it, cost, and, turns out that there was a lot of optimization that was possible, so… We… we did get it down from 8 to 1.2 million guests to verify one, fully FIPS-compliant MLDSA44 signature. I want to mention that this is when the key was already registered. Before that, the registration is basically expanding the key and saving it in the blockchain that costs around 4 million gas. Which is the same as what we're comparing against. Basically, it wasn't just one thing that, reduced it, it was just optimizing each and every single thing, and, and, and,

Doing that, Some of the… some of the main things that… we got to, to optimize was the quadratic memory of the EVM. We optimized to use a small, scratch memory instead of expanding everything. To, memory, so… that saved a lot of gas. Also, doing computations and operations on four elements at once, because EVM is 256-bit. And instead of… And yeah, so these and many more optimizations, made it work. I want to stress that it hasn't been, audited, it's a research code, but we did what we can to, run it against the full test suite, the widget proof. Plus others, some fuzzing, some form of verification on what we could. So… take it with a grain of salt, and…

the… the contract is open source. Unfortunately, I didn't get to publish it yet. It's gonna be published at this address today or tomorrow. And, yeah, that's, that's it.

Antonio Sanso: call me impressed. So let… let me tell you one thing. It's the first time I've seen Like, any… of the Laptist contract, there were, I think, over 20 millions of gas. So, it's… it's kind of remarkable. There is, again, Simon, I don't know if Reno is on the call, but Simon is, is Daniil on the call, and I think, Simon, you work as well on the Dilithium part of Solid, right, somehow? Yes.

Simon Masson: Yes, it's impressive.

Antonio Sanso: It is, right, this is crazy. So what's the main trick, Karim? Can you show again the back of the table? before… this, so let's see… So, I think only the shake, per se, is a great achievement. Like, going from 3 million to $0.4 million for shake is… wow. And so, what was the main trick to cut all this gas? This is crazy.

Oren: On a high level, honestly, the trick was Running it in an auto-research mode with Fable for a week straight. And, like, if we're talking, about the technical part, then it was a lot of, a lot of, like, rewriting things in assembly, doing… Like… Yeah, like I said, the memory expansion is just almost 2 million saved there by itself across all the lanes, and many of the computations When you write it in Yul or in EVM, we're also… Could… could have been, like, very much optimized if you… if you write them, trying not to shuffle memory, and to, Squeezed, like, 4 lanes of computation into one operation. And also in terms of encoding and decoding the key, basically not doing that, but directly copying it from memory. So, just, like, kind of, like, shaving a bit and a bit and a bit by that,

Nothing… nothing like, crazy, that we haven't heard before in EVM guest golfing and optimization.

Antonio Sanso: Do you think it's the floor now, or is there still room for improvement?

Oren: I… I… I think there's… always room for improvement, but I would say… I would bet you could maybe shave no more than 10%. below this. So I stopped when I… when I… when it looked like it… the returns were diminishing.

Antonio Sanso: And, with the current gas, do you have an estimation of the cost of verification?

Oren: What do you mean with the current,

Antonio Sanso: Yes, cost. How much will… how much will be now, more or less, the $1.23 million in dollars? Yes.

Oren: Yes, and there's also, like, yeah, so, as I mentioned, the key registration, like, which is a one-time per key, is 4 million. It's basically, we're doing, the expansion of the key, which is the first part of the verification off-chain, and then just storing that as is. That's, also the current, if the Dilithium did that, so we're just copying the same tactic. But it is a trade-off of space, if we're talking about, storing, like, 20 kilobytes of Key material on-chain for each wallet. That's, that's… Something to think about. And, if we were to do that, like, the… instead of storing it one time, 4 million, then that would be, like, another 8 million just to expand the key, so… so it is a very good optimization and very…

innovative. from, From the zkNox team.

Antonio Sanso: Is anyone knowing on the audience how much dollars will be, at the moment, 1 to 23 millions, more or less, in dollars? A couple of dollars?

Oren: It's sense. Well, the gas price in Mainnet is changing all the time, but when I, when I looked, it was… it was less than a dollar.

Antonio Sanso: Fair. Cool. Again, I'm impressed. Definitely. 22 cents, wow. This is amazing. This is amazing. Yeah.

Oren: Thank you.

Antonio Sanso: Thanks a lot for presenting. This is a… this is resulting. Alright.

Justin Florentine: Real quick, can I tag on to that? You mentioned that Fable was used in, auto mode over research. Did you track the token budget for it, just out of curiosity? Like, what are we looking at for a spend here?

Oren: I did not track it, that's a really interesting question. I'd like to thank Fireblocks that sponsored all of that token cost. I imagine that it was not cheap, but I'll get back to you on that one.

Antonio Sanso: Right.

Justin Florentine: Just out of curiosity, I'd love to be able to say, like, you know, this amount of AI money could save users that amount of cost over time. It'd be a great, compelling story.

Oren: Yeah, that's a good one. Anyway, dude.

Antonio Sanso: Justin, since you're here, this is, I think, is a really great story against I mean, nothing else, but I mean, someone proposed, just proposed a precompile for the Dilithium to be added on Hegota. I think that this actually proved the fact that We really don't need precompiles, I mean, it's really, like, something affordable without precompiles. Even someone wants to use a… it's clear we are moving towards hash-based cryptography, but even if someone in the future wants to use a traction and ethereum and, I don't know, threshold… so… thresholdizing it for… for the distributed key, we don't need precompiles, thanks to optimization like this. So, good, really, thoughts for next ACD, when we are going to discuss the precompile for delegating.

I think.

Oren: Yeah, I, also that there was, a proposal for a NTT precompile that, would help that and other censure schemes that use it, and that, like, according to the proposal, it reduced the gas cost from, like, 8 to around 5.7 million, so, I just want to mention that, because you said precompile, and about the question by Simon, if I have the gas cost for a full verification, including the expansion of the key. So, it, like, I didn't spend time trying to optimize the expansion of the key, but I would say that From, like, a naive experiment, it costs around 9 million gas to do the expansion. But I also want to, mention that Like, we're talking about the expanded key is 20 kilobytes, and the public key that is compressed is around 2 kilobytes, so in terms of bandwidth and cold data costs, that should also be taken into account of how many of these can fit in a blog.

Antonio Sanso: Cool, so… Thanks again for presenting, Oren, and if there's no any more questions, I'll give you 15 minutes back of your life. And, wrap it. All right. It looks like this is a wrap. Thanks again for the presenters today, and I'll see you all in two weeks. Right?

Justin Drake: Thanks, Antonio.

Antonio Sanso: Thanks. Bye.

Gianluca Felli: Bye-bye.

Alessandro Baiocchi: Thanks, Sue, bye.

Stefano: Graci, Antonio.

Antonio Sanso: Nope.

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