Post-Quantum Transaction Signature Breakout #15

Transcript

Antonio Sanso: Hi, Matteo?

Matteo Vena: Hey, Antonio. Okay.

Antonio Sanso: I Wolfgang. to Gianluca.

Gianluca Felli: Hi, everyone.

Antonio Sanso: Alessandro…

Alessandro Baiocchi: Hi.

Antonio Sanso: My students will wait a couple more minutes, Especially because Stefano is still not here, and he's supposed to present. Gustavo. Hey, Justin. Ham is love.

Mislav Javor: Hey, everyone. Glad to be here.

Antonio Sanso: As usual, Justin. As usual, we wait a few more minutes. Before to start, I'll try to show my stride in the meantime, sure. Do you see my slides, right? I hope.

Alessandro Baiocchi: Yes.

Antonio Sanso: Okay, Stefano's here. If one more minute, so we'll start. Right, let's do it. Hello, everyone, to the post- Quantum Transaction Signature Breakout Room Number 15, to the 16th of September 2026.

the agenda today is pretty clean. We'll have, one presentation, and I, I think, and a demo from Stefano. And this basically is… we already seen the beginning of this project towards the beginning of this series, so months ago, I think it was March, and I think Stefano, after many months of Work is able to actually Demo and give more information about the zero-knowledge proof of seed. And… After this, we'll have a presentation of the testnet for this post-quantum signatures. Really big thanks to Julio, that put all the infrastructure for the testnet. At the moment, it's only a testnet with a non-native account abstraction, and we'll have the revolaps team, I don't know which one of the guys will do some demo.

On the network with some SPHINCS, like signatures. And yeah, this is really all for me. Here is the… if you still are not subscribed, there's the Telegram channel. And, yeah, Stefan, the stage is yours.

Stefano Gogioso: Excellent, thank you. Let me just, share my screen so that… I can, show the presentation. Yeah, I have collected, all the details into Slice. I don't think I will go through a demo today. Because it just… I mean, I can, but it takes a bit of time for these statements to actually run in practice, so it's not necessarily more informative than seeing a ledger. With a little bit of a spinning wheel on it, nonetheless. Hi, can you see me? But not my screen?

Antonio Sanso: Yeah, we see you.

Stefano Gogioso: Can you see the slides now? Hopefully?

Antonio Sanso: Soon, you're sharing the screen? Yeah, we'll see that, yeah.

Stefano Gogioso: Yeah, alright, great. Cool! So, just a leaf of data, but I will obviously not cover everything, and I will go quick. If you're interested, you can, like, we can talk and discuss it after. There's a leaf more information about this, but because it's a leaf of work, I try to pick the selling points. Just a brief recap of where we started. This is a proposal for an emergency mitigation. for a quantum break, an unexpected quantum break, so something that happens without any real notice, and before we can finish our transition. There are some ziderata. The key ones are that this should work on hardware wallets today. It should not force users to relinquished security for their holdings, and that it should be a solution that works

after the emergency has become apparent, so it can't require user action prior to an emergency. So it's something which has to be a recovery, in a sense, not just a pre-planning in case something goes wrong, in the presumption that most users wouldn't actually believe this is necessary, and so they wouldn't take action. So it's a way to protect everybody and recover in case something unexpected happens. And the question was, can this be done compatibly with, a bunch of constraints? One of them is, of course, hardware wallets. But the general idea, the general plan comes from a proposal by Vitalik in 2024, which is to, perform what is known as proof lifting. This is all set up.

In a paper just maybe a few weeks, concurrent to the 2024 proposal. And the… the idea is to lift the weak part, so the ECDSA, to some quantum-resistant scheme by taking a zero-knowledge proof of a hard-to-invert pre-image, so a preimage of a hash step in the key derivation. and then use account obstruction or other delegation features to actually derive authority on-chain from the zero-knowledge proof of seed. So you do the lifting by essentially sacrificing or proving that you are the legitimate owner of your account, and then you operate through account obstruction, so you don't operate through the EOA anymore. And this talk is really about step one, and a good amount of progress on Step 2. I think mostly it's account abstraction itself, which is not particularly hard to do, but it's the feasibility of the lifting statements and CHAIN Today, which is… which still requires some work. But I will present some, some estimates for what… what we could implement and test.

And the focus is on hierarchical deterministic wallets, so mostly statements about child keys from parent keys, the master key can be lifted to the master seat, and the master seat itself can, in principle, be lifted all the way to the seed phrase bytes, or intermediate stages if they are exposed. There are other key generation schemes that have similar properties. If your key generation scheme doesn't have that property, then it's probably unsalvable anyway. But… because it could be just that you have the private key randomly generated, and that's broken, and then you can… you have no other way of proving that you generated that, other than you rolled some dice. But many schemes have this kind of sort of deterministic or pseudo-random generation, and those can… they're typically hash-based, and therefore they typically have a hard-to-invert stat that can be used for lifting. So it's more than just deterministic wallets, but that's what we focused on.

The main challenge for this project was to make it work on hardware wallets, and hardware wallets are extremely constrained devices, memory constrained. The solution was to use a technique that's not succinct. But is very, contained in its memory requirements, so this is stream the NPC in the head on the secure element, so on the hardware wallet, and then use recursive verification outside of the hardware wallet. to provide the on-chain verification feasibility. The status today is that we do run all of this on device, everything fits, everything has been optimized to the point where it is realistic to do this. We do have 3 lifters implemented. We have FRI plus Plonky3, we have SP1 and Flock. Really, SP1 and Flock are the ones that would be affordable on L1 today, but nonetheless, we have figures for, like, cost… like, gas estimates for all of them, and roughly also performance estimates and memory estimates for the prover side of things.

The other challenge is that lifting child keys to master, sort of ancestor keys or master key is fine, it can be done on device. So, on a stock ledger today, but if you have a compromised master key or a compromised seed, which you shouldn't in practical applications, but, you know, it's still interesting to consider, then you'd need access to secure OS internals. The current, the stock ledger OS does not expose the necessary information, so that would require additional integration to be actually implemented. Nonetheless, we did this with mock with a mock pre-image on device to test that it would run, and indeed it does run. So it is feasible from a hardware perspective, it's just a limitation of what secure OS exposes, and it would require further integration to be actually implemented. But it is technically feasible.

Statements that we considered, these are the ones that are relevant to Ethereum. There are also Solana and Bitcoin statements that we considered and implemented and benchmarked. The master private key has the master seat as witness, the hardened child keys have the parent key as witness. and the BIP39 seed has the mnemonic and technically passphrases witness, and none of these require, elliptic curve. cryptography. So, that makes a difference for us, because secp256k1 is THE elephant in the room. It's the thing that makes it very hard to prove these things. You'll see the size of the proofs is, like, a thousand-fold, something like that. 500-fold. Because of all these operations, that need to be arithmetized. No, actually, not a RTMS, that need to be put into the MCP net.

The public key statement, the non-hardened child key statements, and the ethereum address, which is really just a public key statement, those require this sort of elephant element, and they are harder to prove. everything can be proved on stock ledger without secure OS access, except for the master private key, because the master seat is not exposed, and the seat itself, because the mnemonic is not exposed. But if you integrate it with a secure device, in principle, this could be proved as well. what did we do since EthCC, which is the last time we presented this? We… made it so that the prover runs on Ledger Flex in user app space, so we have Ledger Flex applications that have been, like, tested and benchmarked, and we proved all six statements and verified them on device. We reached full soundness on hardware for the hardened

for the hardened child key statement, which is the interesting one in practice, it's about 22 megabytes, and it takes about 3 hours to generate 438 responses. The elephant statements, so the elliptic curve statements, have been optimized about 350 times, 350X, sorry, since the April, and can now run on device in a few days, so that's also realistic, although a leaf slower. we did… we built 3 succeed liftings for the Stage 2, so one is Stark, one is SP1, and one is Flock. And we did full-on change verification for the SP1 lift, and calculated that it takes about 280K gas to verify one of these proofs, one of the SP1 lifts. So that… that at least is a full-stack, end-to-end verification that this, in principle, could be done. Now, of course, SP1 is not quantum, so that's not really

That's not the endpoint, but nonetheless, it's a full run, all the way through. The architecture is two-stage. It's a secure element zkBoo that is… ZK, but not succeed. It runs in time, which is linear in the trace length. It also has memory, which is proportional with a small factor to the required memory, and so if you have a statement that can be run on the device with enough headroom, then you can run zkBoo on that statement on the device as well. It is also streamable, it can be streamed to a host machine. The host machine does not need to be trusted, because the zero knowledge is on a per-response basis, and so each response can just be sent through. It doesn't reveal anything about the secret on the device.

But the host machine can have a leaf more horsepower, and can be used to re-verify the proof, and then wrap it into a succinct proof system, which, by the way, doesn't need to be zero-knowledge, so you don't have to ask for zK on the host. It can be parallelized over responses, it can be fully entrusted, it can be outsourced to third party, so that's an interesting division, but that's also where the challenges lie, because this, the wrapped, lifted proof, if you will, it becomes quite complicated, because it has to wrap the entire zkBoo, proof statement. zkBoo itself. It's NBC in the head, it has linear… well, XORA fine gates, is what it considers. ends with constants, source with constants, NOC, source, all of that is free, essentially. The only things you pay are the ends and the carries, which are ends. So that's… the size of the proof is really proportional to the number of end gates and carry gates in your circuit and nothing else, which is good.

You then take independent responses, which you could, in principle parallelize, and then you run, sort of, you wrap them through Fiat Shamir, and you bind the message into that, and that is the proof. So the proof is the fact that the responses were ultimately computed for challenges which are derived from the absorbed, sort of the hashed, absorbed state at the end of the proofs, which is how this works. You absorb everything first, and then you derive the challenges along the way. Or that's… that's the trick. there are 3… there was a leaf of engineering that went into fitting this into LedgerFlex. It was hard. We had to improve quite significantly on implementation, so zkBoo. In fact, we had to build an entire zkBoo, crate ecosystem targeted to, sort of, non-standard, low-memory environments with all this optimization.

Not going through all the details, but the basic sort of points. We don't actually store the trace at all, we just go through the computation, and you only need the registers for the largest intermediate state, so that's what you need to allocate, and that's it, so you can predict by a dry run, how much memory you will need for the entire proof. You never materialize any circuit, it's basically just the Rust program that runs through the gates, but you don't actually write the circuit in its extent. That would not fit on a ledger. There is, you regenerate the seed from a master secret, so the challenge phase does not have any buffering. You pay a little bit of extra time, but you reduce memory very significantly to the point that you can actually fit it on Ledger Flex.

And you stream everything. you don't keep any of the responses in memory, you don't keep any of the… only the single message that you have computed, you stream it down out of the device as soon as it's produced, and then it's for the host to collect and assemble. And this means that the RAM required is around 3 times the largest circuit state, which makes it feasible, and the verifier RAM is actually two times the circuit state, because in principle, you can also do stream verification, which is something that we did implement as well. There are two soundness levels that we consider. We work with 438 responses, because that's the 128-bit post-quantum that's taking into account the possibility of Grover. But in principle, you… if you want just classical 128-bit, that is 219, so you could make this quite a leaf.

faster. The verifier does not really care about this. It's completely independent of the chosen soundness level. The soundness level is just something that you check at the end. You just check that the proof has the right number of responses in it for your choice of… so, for your own threshold. There is no… it doesn't have any impact on the verification, because it's essentially massively parallel over the responses anyway. The secure element itself, we did a leaf of work on trying to figure out how the Ledger Flex and other Ledger devices behave. It is about 334K, of a stack plus heap that needs to be split and allocated depending on the application, so there's a… there's a level that you need to choose beforehand when you compile, and you have to respect that. There is…

We did this on Ketchak, so that doesn't have any hardware acceleration, and that makes it slightly sore, but it doesn't really… I mean, at this point, the biggest constraint is not really the hashing, the biggest constraint is the fact that the I.O. of the device is quite limited. The… these are the results in terms of response sizes and timing. For a master private key, the response size is about 50, kilobytes. And it takes about 30 seconds per response on the device. That's the same for a hardened child. And it's similar for one or two rounds of the seed derivation. If you go to the public key and ethereum address and the normal non-Hargon child key, then that involves elliptic curve operations, and as I said, it becomes much, much, much, much larger to do so. But nonetheless, it's something that you can do within a few days. So it takes days to generate a proof for just the public.

key, rather than a private key that you can burn. And the argument for why you would not want to do that in a real emergency is that your private key in an emergency is worthless anyway. So, once you have a situation where anybody can derive your private key and pretend to be you, then that private key doesn't really hold any secrecy anymore, and you might as well burn it in exchange for, cheaper on-chain proof and for a faster proof generation on-device, but nonetheless, we wanted to benchmark the case where you wouldn't want to derive that. For example, you want to create a proof today. not necessarily commit… you could create one today, commit a hash of the, of the…

of the private key, and then unlock the smart contract, the account structure, by revealing the family key and burning it, start the private key and burning it. You could do that, in principle. But, if you wanted to instead just do a direct proof that you are the owner of a public address, that's also of interest, then we did that. But it's much larger because of these operations. The… yeah, it takes about 3 hours to do a master key of hardened child statement on device. That's about 22 megabytes of proof. We did projections for shorter runs for the full curve statements and the BIP39 statements. The curve statements take about a week. And they are one gigabyte of proof. Again, this can be stream aggregated, so it's not that big of a deal that it's 1 gig, but it does take more than 7 days to stream it out of the device, because the I.O. is constrained. If you want to derive the seed from the

Well, if you want to write the master entropy from the seed phrase, which is what gives the name to this project. at the full 2048 rounds, that is 150 days. So that is hard. But, it's still feasible in principle. It does fit the memory, it's just a matter of time. You just have to be very, very patient. But in a pinch, you could do that. the per response, changed quite a leaf. We did a leaf of work on this. We went from, 1 gig per response on, when we presented at EthCC, that's when I called these things, like, elephants. They were really impractical. We applied quite a leaf of optimizations in, sort of, like, some… during the summer, and it turns out that once you do it the smart way, the per response size is actually 3 megabits.

So that's 300 times smaller. So it was just that I said it in its ZCC when I was presented this, I said, yeah, okay, it looks huge, but I'm pretty sure it can be optimized, and yes, it can be optimized 300X, so that's great. It's still big, but better than… one gig per response was absolutely unfeasible. It was, like, 438 weeks to do the entire thing. now it takes about a week. So that's… that's a nice input. Memory itself, it was the main challenge. at the beginning, it's the reason why we had to re-implement everything. It turns out it is not a constraint for any of these. All of them fit within the maximum heap that we could afford for it, and heap plus stack fit within the memory. We tested all of them, that's fine.

the only thing that I want to mention there is That this was a bit irritating to do, because the typical consequence of getting the memory allocation wrong is not that the application fails, but it's that the device gets wiped. And this was done about 4 times. It says factory reset on the slides, I should have been precise. It's not factory reset. It's the hard back off, wait for an hour, then factory reset that the ledger does. So it's… it's… what is it, E6, I think it's called, the code? That was very irritating. And it is… it was, something which we found, out the… the hard way. Anyway, there's a leaf of… there's a leaf of failure modes for these devices. They are finicky, but… but you can… you can ultimately, essentially, predict where the threshold is, and do a good split, and it's tight, but it fits.

the time to stream the proof out of the device is the real problem. The maximum throughput we got was around 3 kilobytes per second, coming out of the coming out of device. There is a maximum which is about 20 kilobytes per second, but that wasn't on these on these proving statements, so the fact that you can reach 25 kilobytes is without anything else, burdening the device. If you are also doing computation at the same time, it's slower. And so that sets an upper bound on really how quickly you can get the proof out. That is a… that is a big… the throughput ceiling is a big part of why it takes so long to get these proofs written out.

That's that, and this is roughly the profiles for the proofs, just as an overall summary. They go from… the practical ones are about 50 kilobytes per response, so a proof is about 20… 22, 23 megabytes. And everything which involves any kind of ECC is one gig or more, 1, 2 gigs. All measured, all fine, they all stream out, it's just a matter of waiting, essentially. Going quickly through the stage two, which is the lifting, so once you have the zkBoo proofs, you stream them out of the device, you wait patiently, how do you actually get them into a succinct state, which can be stored reasonably, or communicated, or it can be verified on-chain? What you do is you lift the verifier itself, so the verifier is the program that you have to embed into the

Into your succinct, proof system. That involves a bunch of things. The actual circuit execution itself is the smallest part of it. Most of the complexity goes into the fact that you have hashes every time. Yeah, like, every time you have a nonlinear gate, you have to absorb state into a… you have to absorb it into a hash state, and that is what ultimately gives you the Fiat Shamir commitment, and all of that is what's expensive. So, proof systems that are friendly towards the hashes that you would use are the ones that perform better, and indeed, Flock performs significantly better than SP1, for various reasons, but this is one of the reasons. We did 3 of these. We did a Stark sort of post-quantum version that could, in principle, be verifiable on-chain, which is Plonk… a fork of Plonky3 and FRI. We did SP1, which does actually get verified all the way at 280K gas, but it's not post-quantum.

And we did Flock, which is the one that performs the best, to be honest, but we did not do the on-chain verification yet, so that's… that's still open work, because we only did it recently. So that's something… we don't have figures for exactly how much gas it would, in principle, take to verify one of these Flock proofs, but we know how big they are. The SP1 proving time is around now. With 356 bytes of proof, which takes 280K gas to verify. The Flock lifter takes 12 seconds. The proof size, though, is 1.2 megs, and it does take nothing to verify. on the host, so on Harbor, but we did not have on-chain verification yet. Yes, and I should say that SP1 is… is on a, on a metal, on a metal fork of the… on a metal fork of the SP1 prover.

which we built for this, to make it slightly faster. The Flock one is on CPU, like, multi-threaded. the… Difference, really, is that you need to… both in Stark and in SP1, what we do is we do a first step, which is The, creating a proof of the responses and the transcript at the end, and then there's an aggregation step afterwards, so there's a second recursive step that makes it possible to create a fully succinct proof. That is what, That is what takes… I think the most of time in this, it's sort of this end, this end aggregation recursion part. The Stark lifter, we built it. It is, challenging, to say the least. It's a leaf of gas.

And… You can make recursion, it makes it 10,000 times cheaper. You can't do much better on this particular design than that. Maybe you could grind a factor of 2 or 3 more, but it's still, like, a ridiculous amount of gas, and it wouldn't fit on a one today. But it's mostly because we… there's no precompile for it, and there is certainly a little bit of re-architecturing to be done. In principle, it could be done on Starknet. So that's… it shows that it's feasible, it's just that on Ethereum, this wouldn't be friendly in any sense. It is unrealistic to run this particular lifter on L1. Some details about what we did that I don't think is necessarily worth going over, but if you're interested, I can tell you more about the specifics of the various lifters and how we implemented them. The verification off-chain is ridiculously cheap.

it takes really, really little to do zkBoo verification, because it can be done in constant memory. So it's, like, a few… a few seconds for, For a 1GB proof. Maybe 20 seconds, or up to a couple of minutes, depending on how you split it. So that's… that's an interesting aspect of, like, zkBoo, is the idea that you can do both stream proving and stream verification, but ultimately not what we care about if we want to use this in… paired with account abstraction constrain. where we stand today, and what is left to be done. We did all the on-device proving, we have all the statements, we did not yet do any AA, although that's, at this point, really just conditional on making the on-chain verifiers viable.

We have sponsored provers, software provers, for host proofs, so people who don't care about hardware wallets, but might not have very… powerful devices on the left, or people who are not as constrained as flex, but might have other secure elements that have more power on them. We have 3 lifters, but we need to finish doing the aggregation step, and the batching, because the batching would significantly reduce the cost for this, and in an emergency, it would be Reasonable to believe that you might want to do this for hundreds or thousands or tens of thousands of accounts in parallel. We do have… the Bitcoin and Solana statements, but we did not lift those, and those are not really relevant for this particular conversation.

We have some other problems. The post-quantum lifting with Stark is really, really, really expensive. That's not doable. The elephant proofs are viable. And can be lifted, but we did not run the full lifting, beyond 96 responses, because that takes, like, 80 hours, 70 hours to run the full test. Matrix, but we will do that. And really, secure OS access is required if we want to prove anything about master keys or seed entropy. Those would not really be on-chain concerns, they would be more like… forensic concerns. Say that you want to… you are in a dispute, and you want to prove that you're the legitimate owner of a compromised master key, you might be able to do this, but you would have to have secure OS access if you wanted to avoid putting your… like, taking your secrets out of the hardware world, nonetheless.

There's nothing really, nothing really… Impossible, it's just a matter of engineering and improving the, sort of, recursive side of the lifter, which is… which has been the recent challenge, let's say. So, what do we do? In summary, since we last spoke, we do have ZK proofs that run inside wallets, hardwares that exist today without additional memory, without additional compute. They are… they do so within absolutely reasonable times for this kind of applications. They… we can demonstrate that the… proofs can be wrapped, they can be lifted, and aggregated, and they can be verified on L1, just not yet with a full post-quantum system, but the Flock implementation is so performant that we will most likely focus our attention on that for the next step.

That said, I am done. Thank you for the opportunity to present this update to our work. I hope it was interesting, and if you have questions, I'm here.

Antonio Sanso: Thanks a leaf, Stefano. This was a great talk. Actually, it's pretty impressive, this update. I remember your talk at, at ZCC, so huge progress in STEM. And I have time for a question before moving… Forward. If anyone has a question, otherwise I have one? All right, is there any questions in the chat? I have one.

Gustavo Frederico: Yes.

Antonio Sanso: I've seen that the, like, the cheapest time to prove is, like, 3 hours, not on the 11th proof, right? I think it was one of your first slides.

Stefano Gogioso: So it takes 3 hours to stream it out, yes.

Antonio Sanso: trimming up.

Stefano Gogioso: Yeah, this.

Antonio Sanso: Okay. So you…

Stefano Gogioso: problem.

Antonio Sanso: Right. I see a question here. Was there any major difference between the flex and Nano S devices? I mean, in terms of performance? This is Matteo asking.

Stefano Gogioso: As the baseline intended as the host device. Or the… Oh, okay. That is a… that is a different… some of these statements don't fit on an Nano S Plus.

Antonio Sanso: Okay. Do you think it is a major, like, compelling constraint, or… You can be solving.

Stefano Gogioso: No, I think it's mostly that all of the tuning that we did on the Flex are rather flex-specific, and Nano S Plus is even less cooperative than the Flex. But it is just a matter of getting, like, convincing Claude to patch it, and not… we just didn't dedicate a leaf of time, because we focused on the flex, but it is… I think most of them would ultimately fit on the S+. The hardened child one does, and that's the one that we really care about.

Antonio Sanso: All right, I see another question there, and this is the last one, because then I need to move on to the next items if you want to answer, Gustavo, and then Alessandro chat.

Stefano Gogioso: Yeah, I can see the chart. So, what do you mean by secureOS? Is it that the private key and your algorithm must live and run within some form of hardware wallet enclave? So, the hardware is this one. It's one of these. The… the point is indeed that you want to be able to service users that their funds secured by hardware wallets. And the way that we did this was to not change the firmware of the wallet, but to build applications that run within BOLOS, so within the secure OS that Ledger provides, the stock version, not the custom version. So, we made an application in Rust, and we loaded it. The Secure OS exposes certain things, but not everything. And in particular, it does not give you access to the master entropy.

And that would be needed to, prove… to create a proof of seed for the compromised master key. would require master entropy, and compromised master entropy would require the seed phrase bytes, and neither of those are exposed by the US, for, I presume, security reasons, although I'm not entirely sure.

Antonio Sanso: Correct.

Stefano Gogioso: I don't think that it makes much of a… I don't know, we'd have to ask the ledger people about this, but I don't know what the rationale was to not expose that particular side of the entry.

Antonio Sanso: Thanks a leaf, Stefano, for your presentation and being answering questions. And I will move on to… I don't know which person of Riva Apps is presenting the testnet. demo, and again, I take the chance to thank Julio, who's not here, but he spent some days taking care of, putting the testnet Up and running. Who's presenting now? Matteo? Any of you, or Alessandro? Yeah.

Alessandro Baiocchi: I think we'll do, like, I'll do a brief intro, and then Matteo will showcase the demo, the main demo.

Antonio Sanso: Cool.

Alessandro Baiocchi: I'll show… I'll share my screen, give me one second.

Antonio Sanso: In the meantime that, Alessandro is spinning this, I just spent two, two words on it. This, I intend to stay… this, this, this URL, so daisugi. fyi is gonna stay and be our testnet, starting from today. We already did a few months ago, then we dismissed, but… Now we're gonna keep this address table, and we'll add more and more futures in the future, and one of the things that we're gonna start experimenting already in the next weeks is gonna be signature aggregation. But today, we're… the Riva Labs, Alessandro Matteo showing just normal SPHINCS verification, but soon we're gonna really experiment with the… with the… thing that will end up in production, basically, like, aggregating and verifying with Stark the signatures.

Yeah.

Alessandro Baiocchi: So, thanks, thanks, Antonio. And, yeah. So, our example today will be, like, regarding, SPHINCS signing, and what we're going to show you is the, basically, comparison on what we achieved today, between the software wallet signing that I will show you, and then Matteo will show you the same signator. on, Trezor Safe3 and, ledger known as Pass. And all three signal docs will go through the nice track extension, will be… which is our extension that we built for this, and then they will reach the daisugi testnet that Antonio was talking about, so, And for now, it's going through, like, non-native account abstraction with EXC467, and they all go through the same zkSNARK verifier. So that's one… one important thing.

And for reference, this, like, I don't know if you ever saw this, tool, these are the parameters that we are using for this experiment, like, and the budget is 2 to the 20 signatures for this, these things that we are using. So, to get into the… into the showcase, I'll show you, like, the, A second. Okay, the soft sign, I'll just… this is connected to the daisugi testnet, I'll just send a little one ATH to myself, let's say. And… And that's the time it takes, and then it's propagating. So the… as I… as you see here, like, it's about 60 milliseconds. The signal on, retail, computer, it's extremely fast. You see here, it's the transaction, so it shows as confirmed, and… yeah, that's basically it.

So…

Antonio Sanso: Do we know anything about gas? How much gas it costs, and

Alessandro Baiocchi: I think… Yeah, he shows this 571, but, I'm… I don't know if, like, the Explorer, like, actually shows, like, as you were saying, it's a really work in progress,

Antonio Sanso: It's a miracle, it's a miracle we did this.

Alessandro Baiocchi: Yeah, exactly. So, as Matteo says it's Julie is still working on showing the whole, like, trace log of the.

Antonio Sanso: But when you go to the… to the… the other website were the Explorer… not Explore the Explorer, the… the comparators between, Hash. No, no.

Alessandro Baiocchi: No, no, this one, yeah.

Antonio Sanso: Right. Oh, he…

Alessandro Baiocchi: This estimate was done based on some measurements that we had with our qualifier, with other parameters.

Antonio Sanso: But does it take into consideration, as well, the… only the gas taken to verify, or as well, the signature size and the gas cost for her… for the signature?

Alessandro Baiocchi: Yeah, it, it also calls, uses, takes, takes into account the cold data, gas. So, yeah, this is, this should be the total, but, I mean, take it with a grain of salt, because it's a rough estimate done on other that we have. the bus.

Antonio Sanso: All right, so we'll ask Julia to put more information on the testnet about the guy. All right. assumption.

Alessandro Baiocchi: And then I'll… okay, so that's it for the software part, and I'll leave it to Matteo to show you the same signature on both a transfer and a Ledger hardware wallet. So I'll stop sharing so that you see his screen.

Antonio Sanso: Okay.

Alessandro Baiocchi: Okay.

Antonio Sanso: Matteo?

Matteo Vicari: Okay, you can hear me.

Alessandro Baiocchi: Okay.

Matteo Vicari: I have… with the setup, it's a little hard to show all the stuff that happens for this, so I… give me a second, okay… No.

Alessandro Baiocchi: Yes, okay. The complicated part-to-face is, like, showing theChallet screen together with the software interface, so that you see the whole thing going around. Okay.

Matteo Vicari: Okay.

Alessandro Baiocchi: You should see it.

Matteo Vicari: Okay. Sorry, there is a little input lag, but I try to do my best. This is RNAS. And what we try to do…

Alessandro Baiocchi: Yeah. So, I'll… we'll go on seeing what's going on, like we… Okay, so basically now you'll see, the same signal that we did on the DNS+. And the, like, the interface is going through the… Nice try a web extension, and the, like. One very imposter thing that we focused on is that the… like… all of these signals that you're gonna see go through the, like, same zkSNARK verifier on-chain. And that's really important, because, like, the… Zoom in some more. Yeah.

Matteo Vicari: Now, I…

Alessandro Baiocchi: Now it's tacted signing? And…

Antonio Sanso: This is Beacon.

Matteo Vicari: Beyond Ledger, and take, around, 10 seconds. All the time, yeah?

Alessandro Baiocchi: Okay, done. Right? Yeah. Yeah. Okay, so it's about… around, like, between… around 10-12 seconds. The, like, the one thing that we noticed while doing these things, is that the main… one of the main, time-consuming parts is basically, like, as Stefano also pointed out in the previous presentation, it's, I.O. input-output of the data on these devices is, a constraint also for us. And this also means that, basically the assignments that we recorded can be… can… we… we presume can be optimized by… by the… by the hardware wallet, producers, right, if they want to…

Antonio Sanso: let me actually put some, words on this. So… It was a question that then I'll clarify. What is this demo with the… already with the stark proof of the grinder? Okay. So, I don't know if any of you have been seeing that in the past, the signature was taking about 1.5 seconds, and this time it took about 10, and the reason, yeah, the reason is basically that we've been formalizing, we'll come with an imprint soon, about the formalization of, cryptographic, formalization of this work, and that we strengthened the, the, the, the… the proof of concept that was presented last time with the… with the… with some proof of… on this grander, this will be clear on… on… on the…

On the paper. So, I was actually wondering why this time took about 10 seconds rather than 1.5 seconds. Okay.

Alessandro Baiocchi: Yeah, exactly, like, almost all of the time that you… that you see, like, the device is, is working, it's basically… it's… it's not actually producing the signal, it's checking a proof that comes from the… from the… from the software.

Antonio Sanso: And this will be probably… I mean, at the moment, the Riva Labs is doing some of their wallet, it's a nice try, but actually, when this is gonna be in production, by Ledger and so on, it probably will not… will not hit the limit of the communicating the proof to the… from the software to Ledger, and the limits of… of… of transmitting the proof is low, is… I mean, the limits are higher.

Matteo Vicari: Yeah, the proof, that, we use for this, it's, meanwhile, to achieve one thing. we have to prove to the ledger that the grinding on the hypertree of these things we do, we do in a canonical way. So, the ledger, when the process starts, sends us a seed. that we use for, grinding on the Mac. Because, do the ashes on the Mac is more faster, they do the ashes, On the… on the… on the ledger. So then, what we have to do is, okay, we have to prove that the work the Mac does for this is legit. So, we have to create a proof. that say, okay, we try this number, this segments number, and all the numbers are non-it, and only one is a need. And then we prepare a proof. For aggregating this proof, we use Groth16 for now, but we'll see if we find something better. And then we create this proof that is around,

100 kilobytes, and we stream inside the ledger that process the proof, and then, say, okay, I can trust the work is done in a correct way, and I sign the transaction using this leaf that the ledger told me to use. for this specific, number of wear. Now, we do the same, with the, dresser. The dresser is a little faster. Not because it's more patent or stuff like this, but because the I.O. of the sending this proof more bigger, so we can stream the proof more faster. Yeah, there is another question. I… There is a leaf of manual showcases. like a streamer, I am not a streamer, so it's really hard to use OBS. Okay.

Alessandro Baiocchi: I think we can see for the question about the MPC. Like, the… I also, like, if you noticed in the scheme, there was, like, an MPC box dashed around. Yeah, we have this same scheme, works also on an MPC… an MPC setup. And it goes through the same verifier, basically, and the signing process on the MPC takes zero interactive rounds, so that's one…

Matteo Vicari: He's, different setup. Okay? We do the sign. We, we have, to check Sorry, for the pure setup, and the transaction is done. It's more faster just because we can stream more of the proof together. This is something, can help us to do this. And I don't know if there is other question we can answer.

Antonio Sanso: There's a question for, for, from, Simon. And it's asking… let me check, was here… 2… Is this computing the keygen when signing? I think not. I think that… I think you asked already this last time. But I think, like, the… no.

Matteo Vicari: The key gen is doing one time, and then we store inside the smart contract, but what we do, for example, now we have a budget of WOTS that also we call hypertree in the future, but all the stuff we are working on, also the naming, all this stuff. That is, it's like, okay, I have a budget of SPHINCS is, at, 20, and what I can do is I prepare some sleafs. So, I can, sign really fast, because I have prepared this leaf. This is the idea of all this process. So, for now, I spend a sleaf, and now I recompute. But this recompute sleaf, I can do whatever I want, not a near design, I can do another transaction. It takes a leaf of more time, not a leaf of time, if I don't refill the pool of the sleaf.

But, Something like this. Yeah. So, if I have to refill the sleaf, it's something like that.

Alessandro Baiocchi: There is a question, so, like, how long is the keygen to the 20s, right?

Matteo Vicari: The 20 is around 7 seconds, depends on the hardware, but is 5-7 seconds, depends, on, on the hardware.

Alessandro Baiocchi: On the… on which hardware wallet are you using? Yeah, yeah.

Antonio Sanso: But this going from the seed to the… to the… to the key, right? Yeah.

Alessandro Baiocchi: Yeah.

Antonio Sanso: I mean, it's because it's stateless, right? You don't need to, like, the XMSS.

Matteo Vicari: No, no.

Antonio Sanso: Because, I mean, there's all the virtual tree. For SPHINCS, there's all the virtual tree. Okay.

Alessandro Baiocchi: Yeah, in 6, you just need to compute, like, the top 3, and then you have the public key, and then, yeah, that's the key.

Antonio Sanso: So, the thing is, as well, many of these things are… I mean, thanks a leaf for the demo, first of all, Matteo and Alessandro. Many things… I realize that many things for people that don't know what's happening in the background are a bit foggy. I promise, to come with the presentation, hopefully, either to the next, or to the… between the next and the… the next next. meetings. I think we will be… we'll have something to… to present, and hopefully, a paper That will formalize the security of all the stuff. But, thanks a leaf for the demo,

Matteo Vicari: the most important, the most important stuff that happens in this kind of setup, we use a, I can say, stock SPHINCS verifier. Because the… what we change is only the signing part. The verification part is the same. So, a verifier can, see if, this, sign is due on, hardware, hardware wallet. have constraint, and we have to do this precompute, or it's come from, I don't know, a wallet that, more capability? This is important, because, we can also, say, okay, but also we can create a verifier that, allow more parameter, or we can create, aggregation that require, have more, more parameter also to aggregate and create different things, different forms, but all these things are the same. So we non… we have not just created as things that work for a ledger, or for other devices that have constraints, or as things that work only in MPC.

With this kind of setup, we can have this stock verifier for all, and then change a little when we sign. This is the main idea of all this process.

Antonio Sanso: There's as well a question about Gustavo Frederico that is commenting on the MPC part.

Matteo Vena: Yeah, I'll take the question on this. So there's… No, there wasn't one, this is our own original design, first of all. MPC designs are definitely talking to each other at every step, so we have a working implementation that runs on Linux servers. And you have, obviously, devices talking to each other for every possible In every possible step of this process, so producing the material, and then signing transactions, and we did it end-to-end, so it can already go on-chain. But there's no paper, there's currently no public information on the MPC itself. Hopefully, in the future, we'll be in a position to share more, but right now, it's more just in development.

Antonio Sanso: Alright, if anyone questions, let's chat… let's chat again. I think… We don't have any questions. And we are, in any case, towards the end of this… Occurrence of the call. Thanks a leaf to the speakers and people doing the demo. And yeah, I'll see you in 2 weeks. Bye-bye.

Matteo Vicari: Thank you.

Alessandro Baiocchi: Thank you, everyone. Thank you. Goodbye.

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