Constrained Signing

Transcript

So, um when I think about blockchains, I like to think about like three main components and it's going to be like of course the execution layer, the consensus and the data availability layers. So, just uh setting it up. The execution layer where the transaction happens and in the case of Ethereum is where we have the smart contract. For consensus where the block production happens and then we have validators or miners in the case of Bitcoin and other proof of work um uh blockchains. And there's as well these other layers that might be hidden from some blockchains or but we have a data availability sampling. So, with that, where there's the commitment to publish data.

Now, um Um just to give a name to this kind of components like for the for the execution layer like we have the the execution clients so get, besu, nethermind and so on. For the consensus, there's like this uh these clients prism or lighthouse and so on. And for the data availability sampling layer, there is like the rollups or L2 so optimism, arbitrium, scroll and so on.

Um um Well, what do they have this in common uh right now? Well, they're like all based on the on on elliptic curves like the security is the relies on on this elliptic curves. Um just like a note, this actually not really um unique uh from from blockchains but yeah, it it is the state of public key cryptography and the at the moment like the modern digital infrastructures relies on on elliptic curves. Um So, just to give a name of this elliptic curves like for for Ethereum on the execution layer, we have a secp256k1 that the same curve used by other blockchains

and it's it is it is used to to sign so easy DSA signatures. And for content to send us, we need a bit of more fancy structure. So, we need pairings and we have a BLS12-381. So, I'm not going to spend any time this. We all know that there's this algorithm that that completely destroyed elliptic curve discrete log problem. And we have this other uh uh problem on symmetric, but it's a bit less obvious and we we have this great write-up from from from Filippo in case you want to look at, but we are a bit less worried about Grover algorithm than than Shor.

Now, it all starts with a tweet from Justin and this is a tweet from from uh from Justin in the beginning of the year where we we have been already working on post-quantum Ethereum since long. I think Justin was already talking about it in 2018-19, but officially we we announced that we're going to go all all all in in post-quantum in uh in in January this year. And we have this website where we got the information. And uh basically it looks a bit like this. We have again these three layers. So, we have a linear term for consensus, linear for for DAS, and we have these post-quantum transaction signatures initiatives.

And uh today, at least like this this keynote is about execution layer. Um quick note, I host a bi-weekly call every 2 weeks. It's open. Everyone can join. I hope to see you there. We just discussed about the next signature for Ethereum there. Cool. So, we need some new maths. Discrete log is not good anymore. So, we need something new. Historically, there are like five area of cryptography that is resistant to quantum computer. So, we have a hash-based cryptography, we have lattice-based cryptography, we have a code-based cryptography, multivariate, and my favorite one that is of course super supersingular

elliptic curve isogeny. It's the best. The best. So, the things to remember is that it takes time. So, just to recap, in 2016, the NIST started this cryptography standardization process and announced the call for papers and um in 2017, there was a start to be some proposal submissions. There were dozen of those. I still remember like yesterday that the first night Lawrence Penny broke four or five in the same night. Because this is a process where every cryptographer tried to kill each other. So, we start like from a bunch of papers and you start to to to to to select um

to to to actually like find vulnerabilities and like it's happening now for proposals. And um the first round of evaluation started in 2018-19 and second round in 20. And basically like in 2022, the NIST announced the the selection. They don't want to call winners, but I call winners. And yeah, we're still in the phase of implement- implementing some of this. So, let's see the selected um algorithm. There were like three for signatures and one for key encapsulation.

As you see, like for let's say lattice, they did a great job there. We have two signatures, Dilithium and Falcon, that are both based on lattice assumption. And Kyber for is the only selected for key encapsulation and we have Sphinx for um that comes from hash-based cryptography. Cool. For blockchain, at the moment at least, we have the luxury to only need to think about signatures for the moment. So, we need this new uh signature scheme, right? And we need to choose between some candidates, but we want to have we have some desiderata. So, of course we want to our new scheme to be secure in the

post-quantum and the pre-quantum settings. We want to be efficient, so small signatures, fast to sign and verify. The bandwidth and storage to be as low as possible. Simple to implement, and yeah, then lightweight as much as it can be. And no trust setup. Um And we want to be robust. And we don't want to like robust, we don't want to kind of rotate and and going through this uh painful process every couple of years. We want to choose one to actually keep it.

So, this was the situation when we started uh the evaluation back in February. When we started with this uh PQTs um process. And the first thing to notice this. I mean, there's no arrow that is all green. It's a we're really in a pick your poison scenario. Just to give like an example, the if you see for example Falcon, uh it does a green for signature size. I mean, green. I mean, it's still 10 times bigger than the size still 10 times bigger than ECDSA. But for example, for a hardware implementation, we have a yellow. And the reason is basically that um that the the designing part of of Falcon, it use floating points. And now, having floating points on a ledger or

any hardware um uh uh apparatus is kind of not easy to implement. And that's the other have there's really no no green everywhere. Like for example, for Dilithium, the keys is uh 2,420 bytes. So, again, it's bigger than uh than Falcon. And well, mean, let alone Sphinx for now, right? Okay, let's zoom only on the on the signature size. And as you see, like on the ECDSA, we're using 64 bytes, and the smallest uh signature that is post-quantum is Falcon is already 10 times bigger. And uh up to 120 times bigger for for Sphinx. Like, yeah.

That's basically it. Um so, we need some idea. And the first thing that we realize is that uh what really actually matters is not the signature size per se, but actually if we can aggregate the signatures, we can impact less the the we can actually compress the the the the block and putting all the aggregated signatures in the block. And well, at this point, the the signature size per se, the single one, matters way less. And you see, everything is green now.

I mean, I'm joking, but I mean, let's see actually how. Um for signature size. Okay, the the signature size still we still don't know because there is this process that started the last week. Thanks to the people actually involved, Nico, Emil, Justin. And basically, there's this um this this competition now, where where try to look for the for the best version of more exotic of of of Sphinx. And there's this this this happening right now, and I think the moment we start from I don't know, 7K, we're ready to 5.4K. I mean, let's see how where it goes.

Um in the case of aggregation, we have again Lin VM, and we're probably going to hear more about it during in these days. And in the case of uh threshold signatures, there are these these new papers by by by Dan Boneh et al., Prone, there's Rivest Labs are going to talk about it today. There is Silence Labs, I think we have a talk uh, after hours. And uh, there's still still some yellow, but uh Okay, not too bad. You already heard about the this strum up initiatives. Let's actually zoom in quickly about the things we're interested today. Um, we're here, namely like we're launching Glamsterdam, uh, in a few weeks.

So, that's where we are at the moment. The first things that is interested for us, uh, for for the signatures is friend transaction that is nothing else that, uh, native account abstraction that will happen in Agota. And, uh, this initiative will hopefully ship, uh, in I star. Where we have Lin VM and, uh, this, uh, Lin Sphinx, uh, aggregation. There's a say as well a specification AP A288. Now, just to recap, uh, the the choice, we are moving full on account abstraction. Goodbye, EOA.

Uh, the other choice was to not have precompiles. Because historically we don't we never a lot of success with, uh, cryptographic precompiles. And, if we think about the DKVM, having a precompiles is, uh, with lattice, for example, it's not ideal. And, we want to homogenize a bit to the the tool we use in, uh, in the in the protocol. So, having having everything in the same, um, on the same engine that is a hash base. So, Lin Sphinx is the the right candidate. Cool.

So, here we are, uh, it is clear that we are using, uh, our strategy is based on the hash based signatures. Now, when we think about hash based signatures, there are like two families, stateless and stateful. For consensus, um, makes a lot of sense to stay on stateful but for, um, for like execution, uh, the natural choice is to go through a, a version of Sphinx. Not Sphinx as we know, because we're going through Sigolf, but a version of Sphinx. Um, for people that are not familiar with Sphinx, is just doing a quick recap. Um, there is actually this really nice visualizer of of all the families of Sphinx that is by

Rivest Labs, in case you want to to play with it. But this what I'm showing here is, um, is the official Sphinx. Um, Now, if you if you ever played with Sphinx, you know that there are a bunch of numbers and you can play with it. Um, Sphinx is is nothing else that a huge hyper tree and is consistent of, um, Examine signatures and Winternitz signatures and the very bottom, the the the the the red here, there are a few times in signatures or force. And you can play with this parameter there a lot. This is only a subset and, um, probably one important one here to to to to give a look at is the So, we I call it stateless, but it actually doesn't exist stateless signals.

There are like a maximum lifetime that for the standardized version of Sphinx is 2 to the 64. I mean, it's huge, but there's this budget. And this is our kind of the number. I mean, as you see the the standard version of of Sphinx is the 7.8 kilobytes, but this not the only things we are interested. There are like for at least for the blockchain words, for example, the number of hash you need to sign is really important. And for the for the version of of of the standardized version of Sphinx, you are signing in order to sign, you need 2 to 2.1 million, um, hashes.

Now, the Sphinx actually, sorry, NIST actually realized that you have other scenarios where using 2 to the 64, um, signatures doesn't make any sense. There are way too many. So, they thought, okay, maybe we can reduce the budget of the lifetime of of signatures and having a a small a signature size and they came with this with this version of of Sphinx. And you see like the shape now is totally different. You have one big hyper tree. Actually, let me put this as well. You have the first hyper tree there the XMSS is one. Before there were many. So you have one and this really big height.

And what does it actually buys? Well, you see now that the signature size is well, it's 3.8 kilobytes. Now, this is still not good for blockchain. Why? If you see here the signing cost the number of hashes you need to sign now is like 1.45 billions. If you really try to do this on the hardware, I didn't try it but I will suspect it take maybe one day to sign. Uh yeah, not not ideal for the blockchain world.

Um so again, you can play with these numbers and with this with this parameter this is what Nico did uh few months ago. He called this initiative Sphinx minus. There's a really nice post on it research and here I'm showing you just one of his toys example or it's not a toy actually, it was a real proposal and it's a C12. And the city here is yet another shape of it, right? So it has like a more XMSS and it was optimizing and finding a right trade-off between the size, the number of sig hash you need to sign, the number of hash you need to verify and actually came out with did as well a bit of a search and

for example, in this case as you can see the lifetime of the scheme is 2 to the 14. So you can sign up to 2 to the 14 times. That looks like not a lot, but actually look on the all the history of at least in this case the the the the history of 2025 transaction in the Ethereum mainnet and you actually see that 99.9999% of um of those they sent fewer than 3,000 transaction in that year. So, 2014 is more than enough for this situation.

Now, these are again the the numbers the the the signature size was 6.5 KB, so kind of big, but if you see the the signing number of hash for signing was only let's say. And what does it actually means? In this way you can actually show feasibility of signing with the hardware ledger in this case with the with Sphinx. Again, still 45 47.5 seconds.

Not ideal, but at least we went from many hours or a day to to seconds. Good. Can we do better? And I say yes and thanks like again, there was this this this work by by the guys from River Labs that now is project 11. And they will talk about it later more, but they actually showed that how to sign on on probably the cheapest device of the ledgers the Nano S Plus in only 1.5 seconds. How do you do that?

Well, full fledged details we're going to probably publish on Monday, not this Monday, one Monday on the print. This is the the work in progress paper. Um I will just give some uh hints on how this work and then like Matteo and Alessandro give more details. The ingredients of achieving this is basically um three. Basically like uh there is they realize I mean was pretty clear but I mean they they made explicit the fact that um there are some parts of things that uh they're public then they can actually uh leave uh outside the secure element of the

of of ledger of any hardware device. And thanks to this you can as well doing uh some pre-computation. And at the very end you can actually use some kind of from of grinding to to actually uh complete the the the circle. Um now before to show more idea of it uh let's actually see more or less how um the pseudo code of of Sphinx works. You don't really need to to look at this. The only things I ask you to to keep an eye of is this R.

Now this uh this this value of R is uh computed for uh Sphinx um when you receive the message. You receive the message then you do this uh PRF you get this R and then this R is used to like derive the and choose the the let's say the the leaf of the hyper tree. And then like when you verify the the R is a parameter of the input of the verification. If you look at this uh new version of uh Sphinx with precompute that's called Sphinx G G stands for grinding you will notice the first things is that you might notice is that the verification is the same. There is nothing else. I mean there is no the the standard verification algorithm.

The signing is actually changing a bit. Again keep an eye of that R. How this R is now computed is in this case is one uh pseudo code but actually you can split the the signing in two part and as you see the R does not depend anymore from the message and actually, let me go here. And this actually is the high-level idea of Sphinx G full-fledged. And what you actually do is this. You let's say you precompute in this case, B is equal 16, but you can actually vary this number. You can precompute six random force instances without thinking about the message. You precompute and you

store it. And when you are receiving the message, you are retrofitting one one buckets doing some grinding. Again, I'm not going to spend a lot of time into this because Matan Nelson will show it with the demo as well. But I want to highlight few features of it. And the the first thing is like the security model we choose is that the hardware element is secure, but the as you know, when you use the ledger, you're actually using a software part. And we And in our security model, the software part can be malicious. So, we take this in mind. While the hardware we is again,

is a full secure element. And the what that are things to actually keep in mind is that secrets never leave the the secure elements. So, the all the information that will go to the to the software are all the public information. And there is kind of proves that the the computation done by the software part, it was done honestly. Again, more details in the next part of the presentation. I just want to close this with the some path forward.

All I've been talking right now is including the the aggregation part is live on our testnet. The sugy.fyi. You can actually play with it. There is a a wallet and and you can do signing with the post quantum signal that is aggregated. Great. Uh we are working on this paper with Professor Bonet, Michel Blockstream from Blockstream, Alessandro and Matteo not not this Matteo but the other Matteo from uh from Riva Labs and myself again.

Hopefully in few weeks we'll we're going to have the paper. There's still some some stuff that is not ready but I'm confident we're going to close the gaps. There's this this outer research experiment with the sig.gov. I'm really looking forward the outcome of it. Uh we're going to ship native account abstraction so frame transaction in Hegota. And of course everything's going to be formalized in Lean 4. And if you have some question, I don't know maybe now or maybe at the very end because now there is the second part of the keynote.

I don't know if it's better to answer the question now or later. Probably at the end will make sense. Yeah, we'll do we'll do everything at the end. I'll let the stage now to Matteo and Alessandro. Thanks a lot. >> So I'm Matteo as you can see from the agenda. Um it's signed as a CEO of Riva Labs. That was our startup but now Riva Labs is part of Project 11. So this is why you might be confused by the agenda. And my co-presenter today is going to be my colleague Alessandro. What we're going to talk about is constraint signing.

We believe this is a very interesting topic because as Antonio said, basically Ethereum is moving into a new signature. But what that means in the in the real world is that there is a bunch of different ways to produce a signature on Ethereum. We often think about simple hot wallets and how they sign. But there is an entire industry. We are talking tens of billions of dollars and so there's people signing with different type of devices. Now, as as Antonio already mentioned, there is a we are talking hash-based signature schemes here.

Oh yeah. Thank you, Justin. Um and we started our work actually from uh stateful schemes. They work very well for uh the consensus layer, but maybe they are not ideal for the execution layer. And so then we started focusing our efforts more towards SPHINCS+ and what you can do with the variations of SPHINCS+. I think it's very important to understand that the variations and the type of work we are discussing uh doesn't work if you take the pure SPHINCS+ big parameter sets with a 2 to the 64 potential signatures, but obviously nobody hopefully is going to do billions of

signatures um on a device or or or on a lifetime needed, and that would be very impractical even if you just look at the gas cost. So, all the work is based on smaller SPHINCS and SPHINCS-like signatures, and the budget we are looking at is usually in the range of 2 to the 20 to 2 to the 24 signatures. For the MPC, we are experimenting with higher signature budgets. For hardware wallets, it's uh it's difficult, but definitely not going to the 2 to the 64. That would be absolutely impractical. When we say constrained hardware, uh obviously there is a spectrum.

There's threshold signatures. For those who are not familiar in enterprise um use cases, they are extremely uh common, and the major one of the major benefits of signing with an MPC and Ethereum transaction or a crypto transaction in general is that you can have full privacy. So, you will don't see on chain like on a multi-sig who is participating, what is the threshold, and so on. Uh then there's hardware signers, also commonly called hardware wallets, that most people are at this point have, although they are not having a very good year this year.

Um and then there's others, other hardware limitations. For instance, latency. Like I can have an MPC setup and one machine is in the US, one machine is in Japan. I also have to that if I'm doing a lot of hashes. So, we need engineering solutions to make this work. And as mentioned in the previous part of the keynote by Antonio, this is um we are using this variant of SPHINCS that we call It's true that the official name SPHINCS+ means SPHINCS grinding, but in reality G is Gori, the cat of one of the authors, Matteo, my former co-founder at Rivet Labs. So, yeah, that is the actual story.

And as you could see, there's these three main ingredients. Now, precompute. Precompute is the most important one and is also one that could be applied to other schemes. So, maybe something that is going to come out in the future from the outer research competition or something else. But the idea is that you can prepare some of the signature material you are going to need, and specifically for four forest, so few time signatures, you can prepare the pre-images and the trees, and then some hyper tree materials from the SPHINCS that that we have seen before with Antonio, and store it. And by doing that, you do what we call a slot. Now, later on,

especially if we do questions, sometimes we're going to say that you use a forest and that we prepare a forest, but actually what we prepare is a slot, and so there is extra material like the path and and the trees. And you don't have a specific limitation for the number of slots that you can prepare. For example, as we we will see on hardware signers, sometimes we prepare 16 slots, but we have to be careful because hardware signers have a very small memory and so there is only as much material you can store. In MPC, if you're using big servers, for example, you can store as many slots as you want, basically.

Um and the difference is that in SPHINCS+ slots are computed lazily, we say, meaning you just compute it when you're doing the signature itself. And on a hot wallet, that is perfectly fine in Ethereum uh even today. But with constrained hardware, you cannot do that and otherwise you would have to wait too much time for the signature to be produced and so we precompute some of the slots. Now, what that means is that we have these uh in the spectrum of stateful and and stateless signatures, we believe SPHINCS-G stands right behind SPHINCS+ because you have this operational um

let's say that the slots are only relevant for your operations. Like it's a speed up. It's not part of the security of the scheme. So if I have prepared 16 slots and then all the 16 slots are deleted, there's no security risk. What happens is that you have to re-precompute the slots. So effectively, you are not losing security. You can just move to another laptop, another device, another setup and there is no security risk involved. So that is a much easier trade-off to accept if you're a manufacturer of a hardware wallet or doing custody at a certain level.

So no uh issue on state loss in there. And obviously, there's this uh separation that we do. Um so we call private hashes hashes that are dependent on a secret and public hashes hashes that take just public material as input. And this is not relevant again with hot wallets. If you have a MacBook or anything, you can just do a SPHINCS+ signature very fast today on a hot wallet. But with hardware limitation, this is very important because every speed up we can have in terms of how many hashes we have to do a signature time is going to be is going to make all the difference in the world in signing time.

And then there's grinding. Um Antonio already explained what grinding is and then with Alessandro we're going to look more into how we use it in the context of MPC. But basically, we have to make sure that at signature time we select one of the slots we precomputed. So, if we precomputed 16, the signature has to be produced with one of those 16 slots. Otherwise, there's no speed up. Now, this is an interesting aspect of Sphinx G. Sphinx G is verified by a standard Sphinx plus verifier. So, that means technically speaking, if we had to ship a a Sphinx plus verifier on Ethereum today, including with aggregation, then you would have the freedom to send Sphinx plus transactions from a hot wallet if you wish to or if

you have any compliance requirement, regulatory requirements, which exist again in enterprise custody. And you can also send Sphinx G transactions from your constrained hardware devices like a hardware signer like a ledger, Trezor, or or whatever, or an MPC setup, and they would pass through the same Sphinx plus verifier. This is very relevant because it would give you the maximum privacy possible. Like, I cannot go on chain and say, "Okay, this signature was verified by this custom verifier, so it has to belong to this cluster of clients." It's specifically every signature is the same. You cannot see anything and we would have one single verifier. So, this is very good. Obviously, this is not the

only way to benefit from the speed ups that we are working on, but this is uh part of our vision and we believe it could be beneficial for the network. And also, if you look at the future with this type of setup, as new next generation devices come to market that might have better hardware or hardware acceleration for certain hashing operations, then you could move even more devices through a standard SPHINCS+ signature process and leave all their hardware still fully supported with SPHINCS-G and again all passing through one standard verifier.

SPHINCS-G, as I mentioned before, has some limitations. You cannot just do it on a 2 to the 64 signature budgets or very large SPHINCS. Um but within a parameter set that we are working on, we believe it's much beyond what is reasonable to expect in terms of a real-life use scenario for an Ethereum signature. Also, if you think a hardware wallet and you imagine yourself being there signing, I don't know, 500,000 times, you are actually pressing those buttons eight times times 500 uh thousand times. So, probably the device would break before you end up at 50% of the signature budget.

Uh grinding time, that's important, is proportional to how many slots you precomputed. So, if you precompute a lot of slots, you will have faster grinding. If you precompute fewer slots or if you are left with fewer slots already precomputed from a previous precompute session, then your grinding is going to be a bit slower. Um we consider it at the moment impractical with the 4 + C compression optimization um and other grindings that are done before the grinding that then we do at at signature time. There There's some There are some ways around this, but in general, again, with 4 + C you are already outside of this territory of using a standard SPHINCS+ verifier. So, it's a bit different.

And then there's some considerations to be made on the precompute UX because obviously this is a new type of user interaction with the device and the system. We didn't have precompute before and actually there is a workshop later on after after the talk after the next talk we have a workshop and it's interesting to hear opinions on on this. But basically for from early data, you can imagine the precompute UX on a ledger device and an old ledger device actually to be like seven six minutes more or less and then you can sign 16 times without additional precompute if you want. But then the idea would be that this precompute is either done with a

you can you can invest more time at the beginning when you set up the device or you can do some top up top ups in the in the meaning in the sense that you generate more slots as you go. Uh on an MPC setup this is completely customizable. Like you can have your machines running at night where nobody's operating and prepare operations for the next I don't know six months, 12 months because without a memory limitation of the hardware signer, you have much more flexibility. Um the Sphinx parameter tools that you probably saw in Antonio's presentation is something that we have online and soon we are going to have an even better version on the project 11 website. But it allows you to play with this Sphinx signature and model your own

um your own version and then if you want to share it with other researchers you just go up here into the share, copy the link and the link is going to carry forward the parameters that you selected. So you can use it to play with with Sphinx plus parameters and see what's the maybe you find a parameter set that is ideal. Now this quick video shows the signature process happening on a Ledger Nano S Plus which is the cheapest model in Ledger's lineup and is probably the best seller device in in its category so it's very relevant. As you can see this is just a signature process so once you approve the address, the amount and everything. The signature

takes milliseconds. Um the range is 200 to 500 milliseconds to produce one signature because you already done your precompute, and so you can have extremely fast signatures. Um in in MPC, it's the same. The signature is extremely fast, assuming you have available slots. Now, there's some security steps, but this is this is more the territory of a commercial implementation of a hardware device that you have to do to ensure that the software that is assisting you is preserving the security properties of the system, but this can even this can be made extremely fast. And obviously, manufacturers have hardware controls that we didn't have when we created this

demo that runs through custom software. So, there is definitely hope that even if it's not 500 milliseconds, a properly integrated version of this could complete the the process the entire process including security in a few seconds on this old uh device. Which we believe it's still extremely good. Um We are going to go through a quick demo. Should be already here. Yeah, of MPC signatures. Now, what what you can see over here is a bit of a demo environment where we have different type of MPCs already developed and running on on on servers.

Now, the servers that you see here, these are three servers because this is a two out of three MPC setup. Um and they are all running they're all in Germany, the three servers, so latency is very low. It's not a factor in the demonstration. Uh the one I'm looking at right now is for for four signatures, so it's a stateful MPC environment. And the other one where we are actually going to do a transaction is the SphinxG uh, environment. Over here, I have already pre-computed 33 slots. To pre-compute one slot with these very, very cheap, uh, low-end servers, it only takes a couple of minutes, and I could just run a program and say, "Pre-compute me all the slots I will need this year

according to my estimated signature requirements." And then I have my slots there. But obviously, as you could see from the previous control panel, there is a lot of like I I could even let the servers just pre-computer random amount of slots for whatever uh, my needs are. And then from the wallet interface, I can actually produce a signature that right now works on Ethereum Sepolia. So at the moment, I'm selecting two signing nodes because again, this is a two out of three setup. I enter an amount of Sepolia ETH that hopefully we still have in this wallet, select an address, and shoot a transaction.

Now, the signature actually already happened, so a lot of the machinery that you see is just going on chain on Sepolia, which is not the fastest network, but again, in this instance specifically, the signature was produced in 500 milliseconds. Eventually, this transaction will will land on Sepolia, and obviously, by looking at the transaction, you will not see any threshold or multiple participants because this is an MPC transaction. What is important to know is that at this stage, we were still using a custom verifier, so we built a custom verifier, and thanks to account abstraction, we were using it to verify our own Sphinx G transaction. But now, as we will see on

the Daisugi testnet, we can actually do it, and there's aggregation in there, so it's a much more, let's say, advanced process. So the transaction is actually there, uh, now included on Sepolia, and you can customize this MPC setup in a variety of ways. You can make the signature a bit slower, faster. You can have a single inventory of slots prepared for your lifetime of signatures. You can do it once. You can do it periodically. It gives the user maximum flexibility. And then on the Daisugi testnet, um as Antonio mentioned, this is an effort to to have a testnet environment where

we see how this future is going to play is going to look like. So, you sign with a post-quantum Sphinx-like transaction. We have signature aggregation that is very very early stage, but it's like following EIP 8288. There are some clients team like Nether Nethermind and EthHub already contributing to this environment. We are spinning up more nodes and it's interesting. Now, the people at Cambridge will forgive me for installing a wallet on this laptop and sending Chrome into developer mode.

Oops. Now, what we are about to see is a transaction on the Daisugi testnet. The wallet that you see is a is called Nice Try wallet. It's something we developed ourselves, not because you need a special wallet or you because you will need a special wallet for these transactions, just because there wasn't a single browser extension with full support of account abstraction, native account abstraction meaning EIP 81, 41 frame transactions, and everything that we needed. So, we created Nice Try.

You can install it freely. It's fully open source from nicetry. uh XYZ. And at the moment, the wallet, if you go and try our demo and install the browser extension, this runs on the Daisugi testnet already. Now, if you go and do a transaction on this environment, and again, we can do it with hardware signers, we can do it with MPCs, we can do it with hot wallets. Actually, I need an address for this. So, we are going to send a transaction to ourselves.

Basically, what we are working on at the moment is aggregation. Now, the issue is a very fast testnet. But what you will see is that this Sphinx G Sphinx-like transaction costed 25,000 gas units. Um tests that we did before this aggregation optimization were in the realm of 250,000 gas units. And with the Sphinx variants and Sphinx parameters without aggregation, you end up right over there 200,000 nearly. Now, we are talking 25,000, but there is again, there is a lot of room for improving this forward.

And if we want to just look at the number like the cost of the current transaction verification, this is just 7,000 gas units. So, this is I think pretty uh pretty impressive progress for Ethereum on this um on this environment. And we we would like all the possible feedback on the Daisuiji testnet and our Stry wallet. So, if you happen to have some time, please try do a transaction. There is a website as Antonio mentioned, daisuji.fyi, where you have a faucet and you have a link to install the wallet and even instructions if you want to connect your own custom wallet or whatever. Hopefully soon other wallets will join the effort.

And now I will leave it to Alessandro, my colleague, to explain more about how we actually use Sphinx G in in threshold signatures. Thank you. >> [applause] >> Okay. So, hello everyone. Yeah, as Matteo was saying and Antonio, they explained like things G the scheme and now I'll go a bit deeper on how we use it in MPC. It's actually very simple. I assume like most of you are familiar with Shamir secret sharing but just to to to be 100% sure of that.

Um we use simple Shamir secret sharing in our base MPC design. And that what that means is when you need to share a secret, you basically share between parties evaluation of polynomial. And the degree of the polynomial is what decides how many parties are needed to basically reconstruct the secret. So, if you need to share between if you need to if you want to have three parties to reconstruct the secret, you just need to share a second degree polynomial and with three points you can reconstruct the whole polynomial. So, um with that being said, you can like if you want to share for example in

as Matteo was saying in the stateful MPC design with the force, what you need to do is to share every secret in a force state in a force signature. Secrets are just what you're seeing labeled as the green squares which are the preimages of the force of the leaves. And you share each of those preimage with Shamir secret sharing and when then when a signature is needed, you just reconstruct ask the parties to give you the shares of the the preimages that you need to open to sign. So, all of the hashes that you see on top of the preimages which are the leaves and and the rest of the tree can be done beforehand

and only the the leaves are actually MPC hashes because they start from the the preimages which are shared. And all the the rest of the trees can be done like outside MPC because once the leaf is computed, you you can tell it to anyone because to reconstruct the preimage you would need to to invert the hash. So, you cannot do that. And the same goes for XMSS. If you want to for example for consensus to do uh use stateful schemes and use an XMSS with MPC, this a bit worse because the whole chains of the Watts signatures need to be done in MPC because they need to be kept secret. And then once you're out of that, all the rest of the tree is

done outside of MPC. And once again, when you need to sign you just need to reveal the shares of the secrets that you need to include in the signature. And this is the um basically what allows us to to have very fast signing because when you when you build the Sphinx sign the the Sphinx signature, you do not do do not need to hash anything that's secret. You just need to basically reveal the first preimages that are selected in the selected slot.

So, the grinding comes in allowing us to precompute only a small part of the of the slots. As you've seen like 16 slots are precomputed and then instead of choosing one randomly, we choose one of that we already have. And with the with this grinding, once you choose a slot that is in memory, we just need to to reveal preimages. And they and this basically removes the need for hash MPC uh that is really slow. So, um at this point, yeah.

This is the what allows to what allows us to yeah, to do what we've seen in the demo which is a very fast signature, and uh not so fast precompute, but still bearable. And yeah, it's very simple, and like, of course, uh this will need security proofs. We are working on this, as Antonio said. Uh the first paper about the Sphinx-G scheme is in progress. Will will be will come out Monday. I I know how. And and yeah, and and then, of course, as I was like briefly mentioning, this design uh we're using uses like very simple MPC uh Shamir secret sharing, and only works in uh honest majority threat

model. And we are working on like uh some variants that will will cover uh basically any threshold uh combination that you may want in your MPC. And I mean, that's it. If you have questions like regarding the whole talk, we we're here. >> [applause] >> Thank Thanks for this [clears throat] amazing presentation.

Uh first question, cuz I didn't get it from the talks. Uh so, uh what's the signature budget? So, 500 K K signatures? >> Well, we >> For or at least for one of one for one of the configurations you have in mind. This is question one. Uh question two is I didn't get the size. And question three will be uh if I got correctly in the secret sharing that uh only for the slots to be precomputed, the secret sharing sharing is done on the fly.

>> All right. I I will answer the first two. Basically, like, what we show on Sphinx-G, we believe that is orthogonal to what will happen to sig.gov. So, the the final version of the parameters, I hope is coming from sig.gov. That is this outer research things that is run by Nico and Emil. Uh and and basically like this we hope is going to be orthogonal. So, the the final the final parameter will come from that competition. Look, that that's that's my bet. My bet is that is not going to be too much important the single signature size because we aggregate. So, the the proof so the the the proof of aggregate signature is

constant. So, yeah, it doesn't matter too much if it's 1 kilobyte more or less the the single signature. Yeah, yeah. I mean, the No, I will I will say I will say like I hope that we go around 4-5 K. That's my That's my hope. And there's the third question, I guess. >> Also, for the third question, what is computed like the the secrets are shared is when you like push the pre-compute button, you need to pre-compute one slot. And so, the like all the secrets that are needed for that slot are generated and shared like are shared between parties. So, for example, if you need one slot, you need all the fork sleeves all the fork per images for that fork and the watch chains for the

upper path. You share those between parties and they save those and this one slot. And these are kept until a signature is needed. And so, when you sign with that slot, you reveal some secrets and then you delete it from memory. >> Uh so, from the protocol level, so you prepare for something for future signatures. Uh and now all of the nodes have already the the secrets combined and then how do you how do you assure that uh now comes the signature maybe

now people disagree uh on signing it? >> Oh, sorry. And then when you um when you need to sign, you uh you reveal the secrets. The way you put you do the like hashes on top of the secrets, that's Yeah, okay, that's the costly part because you need to do hashing and hash MPC. That's a lot of communication >> Okay, okay, that I missed because I was thinking how can you precompute it? You have to >> the the precompute is is costly because it contains hash MPCs. So, you this the the uh they're slow. The like the

one big point that we realized is that only the hashes directly on top of secrets are hash MPC because then the next ones can be done publicly. But those are still hash MPC hashes. >> Of course. >> Yeah, I had a question that I think you kind of answered. The So the grinding is done on top of the MPC, but you can do just the MPC without any grinding, right? So, you could just do this with like any shape of uh things and and just do the MPC on top. Yeah.

>> Yeah, the like the main blocker for doing MPC without grinding is that as I was mentioning, when you need to compute the slot, you need to do MPC hashes starting from secrets. So, and at that point this this is really slow. So, uh if you didn't have that precomputed, MPC would be like would be slow. You need communication rounds so a lot of communication around depending on the hash function. So, um yeah, that's >> Thanks. >> Uh I've got a question. Uh, have you So, anytime you add something on the side or something, um, like grinding, you open side channel risk. Um, have you guys considered that with the sort of

pre-compiling or pre-computing? >> Um, not really because at the moment what we are showcasing is like the scheme. So, this is the logic to do it. There's a lot of different security assumptions both on the hardware side side and the MPC that belong to the implementation phase. Like, you you have to do it commercially, then you have to protect for a set of things. And also not every threshold signature deployment is the same because it depends what kind of machines you're going to use for your nodes, if they're online or offline, where they are located, and so like uh other security protection measures including communication

channels, the way nodes talk to each other, the way they store materials, and if the input that they receive from another node actually happens from through the internet or through a physical device that gets connected and is connected belongs to the implementation. >> J- just like kind of to be clear, uh, there's no intention of me that we can do it for for them to implement this uh software of the Ledger. Eventually, we hope the Ledger will implement this and they are kind of specialist of doing side channel attacks and so on. So, we are our ambition not to be delivering new wallet or a new apparatus like physical and new companies, but we hope that Ledger will implement it.

>> Just just a quick uh rush in here. Uh, grinding parameter itself is public, so where why should grinding somehow affect us reveal something about the secret? >> Yeah. No, that's valid consideration. In fact, the the reason why grinding like is a a speed up for MPC also is that like maybe to select the right slot that you have precomputed, you need to do even 10 million hashes, but they're really fast because they're not MPC hashes. They don't they don't start from secrets. You can do that on any machine and yeah, they it's just once you have the starting point for the grinding, it's they're all public

hashes, let's say. Yes. Yeah. >> Yeah, we we have the like to have like as well Iris one of the outer of things, so I'm curious to to have your opinion. >> Yeah, um I haven't kept up, honestly. Um but there are a bunch of papers that um attempt to improve on things like um things plus C, things alpha, um verifiable obtained random subsets as a improvement on fours, I think. Um so have you looked at all of the permutations and which are actually sensible to improve it to a theory?

>> Yeah, I mean sig dot golf is as well using all the tool and even more than that, but some are not compatible. I have to admit it. If there are grinding like it's things dot the things called things dot P is it worse the grind P is is some some of this version are not compatible with this, but yeah, we're looking this and especially the the the the sig dot golf stuff. >> Yeah, I also guess it depends what you want to do with a verifier because again a lot of these was done in a way that we could preserve the standard things plus verifier. If you go and change the verifier, then you can afford more of these uh variations or speed ups.

>> I have two questions if I may. Um first question, what is the proportion of public hash computation compared to the overall uh computations? And second question, which hash functions do you consider as building block for Sphinx Sphinx-G? >> So sorry, the first question was what's the proportion like between pre-computation Well, how much is the pre-computation with respect to the total >> Yes, exactly. >> Yeah, okay. Well, for example like in in in the MPC setup, but almost everything is pre-computation because then when you need to sign, you just need to evaluate the shares to get back

the secrets and assemble the signature. All of the hashes are done on pre-computation. Like basically, if you need to do I don't know like 100K hashes to produce to produce one slot, this is all pre-computation and then signature is just revealing secrets and assembling the signature. Everything is like ready and pre-computed. And yeah, the second question >> Yeah, for for the hash, I can tell you not Poseidon. >> [laughter] >> Which hash I think is still still to be decided.

But it will be one of the SHA-2 or Blake or SHA-3 What what not Poseidon. >> As a side note, we have a couple people here from Ledger in the room. So that was the question from Sandra, I believe. Laurent also from from Ledger. Go ahead. >> Just just just a small question. We also saw some interesting other optimization like tree pruning for for Sphinx. How compatible is is your scheme with with those kind of optimizations? >> I'll I'll give you that. >> Which optimization was it, sorry? Tree pruning of the typically of the of the Sphinx of the Sphinx tree so that you can actually uh uh optimize key generation by reducing

the lifetime of the of the signature of the of the signing key. >> Um it's like we we don't have an answer for that. We are looking into different ways and things that have been >> It's compatible. >> discussed, but yeah. >> It's compatible. >> It's compatible. >> Yeah, yeah. >> Yeah, yeah. >> Yeah, yeah. Basically, what you do during keygen is that you only keygen a subset of the tree, and then when you grind, you can just grind on that subset. So, that >> But it doesn't impact the grinding. >> Not if you modify it in the proper Yeah. >> Yeah, exactly. But if you don't change the verifier, I don't think you can do that uh

>> Yeah. >> Uh okay. Yeah. >> Yeah. And also, like if you're willing to change the verifier even slightly, like adding some some second randomizer or something like that, of course you can you can integrate those efficiently. Yeah.

>> So, for the MPC setting, So, so suppose some of the signers are malicious, and they try to get you to kind of reveal secrets that you shouldn't have revealed yet. Is how are you preventing attacks like that using ZK proofs or um to constrain the other signers to to follow the protocol? >> Well, okay. I think this is all still out of working progress, but uh one thing I could say right now is um Sphinx Sphinx plus or all these schemes have a very like over dimension signal budget all of this variance. So, what happens is let's say

one one of the nodes is trying to trick the other nodes and reveals a bad share. So, that is signal to What happens is that the the signal will not verify, of course, because his share is false and he gets us access to the other two shares. But that like that counts as a burnt signature in the signature budget. >> Right. >> It's just it is it is just eroding the signature budget but since like you can sign millions of signatures that's still like it's not a actual threat it's like you have it's like you have actually signed.

That's the >> But that means that you effectively lose part of the advantage of it being stateless because each signer has to keep track of which slots have been burnt is that right? >> Well let's take this discussion offline. Thank you so much for the fantastic talk. >> [applause]