leanSPHINCS for developers: how to build on Post-Quantum Ethereum

Transcript

[music] [music] talk for this track today about LIN Sphinx and how to build postquantum Ethereum and we have two great presenters directly from Rome. >> We try to be great. >> Welcome Mateo and Alessandra. >> Thanks. This is my first talk to the defcon. I'm little shaky about this. I am at Vigari. He is Allesandro Bay. We are both researcher on project 11.

Project 11 is a company mainly focus on research postquantum uh signature and also build um system of custody. So a little disclaimer before we start. uh this is uh to be a hand hands-on workshop but in in the age of EI we don't develop much uh code we just uh our LM to build to us so what we need for this workshop is a coden agent and maybe if you don't have install node for uh run and compile what code we have before going directly into uh hands-on workshop what we try to explain a little

bit more about things and why is important and why we use this. So first of all uh or you a lot of go to other speech on the defcon now um the uh the postquantum world is arrive and Ethereum plan also to do the upgrade of the postquantum in 2028. So why this important? The PQ can easily break from a public key of HDSR uh um and retrive the private key. So we need to upgrade our system. The most important part to upgrade is also the consensus and the user account. And

[snorts] we see something about oh we can do this also today. So there is a on there is a lot of u um senator scheme in uh postession world mainly a bas on latis isogeny and more the most important for us is ashbase ethereum plan to use ashbase in the next upgrade for many reason the reason are really simple ash function are really simple and simple to understand and to use and also to operate and also you have to think about Now HDSA rely also this on ash function. So it's something that use in our blockchain today and also the scheme that we use are really

uh good understand and they have a really proof of time. They has known for many years now and they work pretty well but there is some uh constraints we have to care about. So what is ashbenor and what family and are and all they work? We can derive two different ashbas type stateful and stateless. The most important of the stateful ashbas signature is winter's one time signature that can be used only one time and then when you try to reuse uh you can be uh forgery the key for this message. So you can use only one. So if you have to use a state you have to be really careful

about use this kind of senior then there is the force the forest of random subject this few time can be used like the name say few time so they don't uh lose all the security in one shot when you sign but they uh the gra deg grace grfully to okay this not work and then there is themsize is a mer tree and OTS signature for create some uh some stateful signature stateless senator are real different one of the most important stateless signature is sphinx plus there is also standardized by the and is stateless in

the sense that a very huge budget of sign so we don't care about keeping the state and it can be say it's stateless Oh, it work and what is the main um characteristic about the senior? They use an hyper tree or was plus signature what we explained before [snorts] and uh a lot of for instance on the bottom of the tree. So the budget of this kind of signature are really complicated is this monstrous mathematical formula but was important to understand we can just uh change some parameter for a better or

different resource in depends on our use case. So what is mean linfx? We know and we use in many area like encryption uh sending data and see if the senior of some messages valid sphinx plus but sphinx plus is a really huge budget 2 to64 senator and in digital asset world we don't arrive never on this limit because if you are just to pay the gas for this kind of senator is really hard and also the problem the uh senator of sphinx plus are really huge and also uh the the gas to verify it is on chain is really um prohibitive. So we

need better solution. The better solution is uh linfings. So what we can do for uh arrive to this kind of signature we can just uh change the parameter for example now I try to open a parameter explorer we develop to explain better or this parameter um [clears throat] okay uh this parameter um change uh the senior budget the senior type so Wing pocket.

So uh for example we have the winter parameter. The winter parameter is a parameter that uh um is important for the one time senior like the name winter parameter. If we make this parameter bigger what happen the senior size reduce. But when we reduce the senior size increment the winter parameter what happen? We have a really uh jump on the senior cost and the gas verification. So uh increment is a lot is not possible. One of the uh the possible parameter for linfings or winter parameter is four because is really balanced and also have less verification cost. This is

important also later on we see in the aggregation. Then other parameter are really important are D and H1. This parameter normally in the literature are just one parameter is H. But for sake of simplicity and also for understand better what do these parameters to the sintor we can image d like the number of layer of the tree and also h the uh size of this tree. For example, if we increment D little or more or for example [snorts] we have more signature budget because we have the senator budget is the combination also for D and H and also

then we see later on also depends on the for size. But this is important because you for example in increment D you have another uh uh what to validate in the part and you increment the size of the signature and also the verification gas. So we can tweak on this parameter for a better signature depends on our use case. For example also we can change the parameter of the fors. The fors are the actual stuff that we use to sign uh and make it bigger give us the possibility to reuse some fors more time. We see later on what is mean. So

we try to go back to the presentation. Okay. So other stuff we can do for change the structure of this signature is changing also the uh senator scam itself like we can change the one time senator using was plus c there is a variant of one time senator that use compression and grinding or force plus c we can explain this because it's a lot stuff so and also what we can do we can create a naical structure of the iber

Okay. And for example, what uh in sphinx art we can see they tree three for example in this case it's not even we it's hard to see because it's white. Okay. But the first layer is 10. The second layer is eight and the third layer is another eight. So we we have a different um age but the tree have different structure but we can change stuff and we see if something work better for our use case. So presentation the other

the other component is really important to this kind of senator is also the use of account abstraction because for example now in Ethereum we can just say okay we just sign a transaction using listings no we can't do this but what we can do is create a smart contract wallet Many you don't know account abstraction in this room. Oh then later on we can talk about this but >> [snorts] >> uh what is important we can define some function inside our smart contract wallet and change the way we sign the transaction. We also have an implementation um wallet that we use for demo is called nice try and you can uh see the link there or just go to the

rewatch the this presentation and see it work. Then we have another upgrade also in the near future in agota we have native account abraction. So what is means native accountraction? uh the use of the frame transaction. There is AP 8141 that change the uh the way we send transaction to the network and introduce the idea or frame. The frame can be used for change a lot of the structure of our transaction. The most important frame for us is the verify frame. The verify frame allow us to change the um the the signature that is verified for a transaction. And then there is other

frames like the sender frame that carry on the intents of the user. So uh with this we can uh also have native transaction. The problem with account attraction is for send a transaction to the network we have to pass to a bundler. The bundler for send transaction rely also on the HDSA. So it's not secure. The bundler can be attacked by a quantum computer and let the people to be like a spam attack. The transaction can arrive to the chain because the transport can be attacked. With native account abstraction, we don't have this because we send directly the transaction with the sphinx signature inside. So it's

much better. So in a we see a huge upgrade for the postquantum security of the system. Okay, now I let Aleandro talk a little more or we produce the key and we sign the transaction on Lyn Spinks. Okay, [clears throat] so thanks Matt. Hi everyone and as Mattel said later we will have the hands on session but before we get to that it's actually really important that we know what we're going to build and so how the signing of the transaction will work.

[clears throat] So in sphinx plus or in sphinx um it's good to keep in mind that the the for the user for example the the the seat phrase can stay the same uh you use the same the same passphrase you have the same words h what changes is that you derive different secrets with a different algorithm and then the public key of course is derived in a different way you build all these three that you've seen earlier in the tool and the root of the top three is the public key And the address you see on chain can actually have stayed the not stay the same but have the same way of derivation because you just need to take this a slice of the hash of the public key.

What changes is how you derive the public key. And also it's important to notice that of all of the three that you've seen earlier, you only need to build the top three to do the key generation. So it's actually uh lighter work than building a full signature. And you can actually even cache the tree to make future signature uh future signatures lighter. So this is key generation. And then it's also important to know how the signature is verified for sphinx. And when a signature is produced uh it contains some of the secrets under in the fourth layer you see here. So these secrets are what is getting revealed during the signature and then if you want to verify

it you you re in the signature you have the secrets and some other nodes you need to rebuild the path and during verification you actually rebuild all this path and get to the public key and if the public key you get matches the users then the transaction is valid [snorts] and the structure of the verifier of lin sphinx is actually very similar to the verifier that's specified in fips 200 105 which is the specification for sphinx plus actually SLHDSA from NIST and the structure is actually very similar. The only difference is that if you go ahead and make some changes to the structure of string plus for example you make asymmetrical trees or you change the OTS you use so use what's plus C as Mel mentioned earlier you need

to change the verifier as well of course and then there is the production of the signal which actually is [snorts] the part that probably matters the most for for someone who wants to build an application on this string with link strings [snorts] and producing a signature with strings plus or strings is actually much more work than what now we do with ACDSA [snorts] and in particular if you work to use the standard standardized parameter by NIST you have [snorts] to do a lot of work you have huge signatures uh a lot of signing hashes and verification gas is very high and the goal of lin sphinx is making that manageable basically by lowering the budget you see you have now

this is one of the set par the parameter set that may be used for link these things but you get the idea. You have a lower signal size and a good number of signing ashes while the verification gas is actually way lower. This actually includes the call data gas proxy verification which is if >> I ask what's the signature >> oh okay if that wasn't clear earlier let's I think it's fine here um the signature budget means how many signatures you can produce with that key before security degrades so it's just a number and in the specified scheme by NIST you have 2364 which is an enormous number. No one

ever will need 2364 signatures on chain. It's it is that way because of course when specifying a cryptographic standard they are really careful and for other use cases you may need it. But on on chain this is this is unrealistic. It never happens. So a budget like 10 million signatures is more than enough for anyone to use unless you have very specific use cases. But that's another part. And just if if you can if we can go to the end of presentation if you can keep it. Thank you. Sorry. And just because maybe if we have we going on maybe we explain it. So um as I was saying the a lot of that gas is actually called data because the

signal size that big cost around 100k gas or almost data. So to better understand this how sphinx um signing works we built another tool to visualize things. Uh >> this is my cat actually as things. So here okay you see there is the tree. This is a toy version of a sphinx signature. It's a very small tree only three layers and each each tree is only uh has only four leaves. And what we see on the other side instead is a deck of cards. Let's say each card is represents a fourstance. So you have all these leads each signs over a fourstance and all of these cards each one is a forance

and they will sign the message. So let's say I want to sign a message. I [snorts] want to send one ETH to Ellis. Of course in the real transaction the message is all of the user intent. So you have the cool data of the transaction and you sign. What happens is based on the message one random slot is get is being selected and after it's selected you basically need to provide the secrets from the slot and the path and the material needed to recover all the path and as you see now this slot has degraded what does it mean it means that part of this from that force have been revealed now if I want to sign another message let's say do that again

there is we the the scheme is going to select another slot. It it could be the same but usually it's not because it's a rand it's a basically random selection based on the message and [snorts and clears throat] that's not now degraded. If I sign again the same message actually this is a nice very nice feature since it's exactly the same message the same slot gets selected and no new secrets are revealed because the same secrets are revealed so it's just the same signature nothing new happens so this doesn't even count the signal budget now what happens if I uh accidentally uh change the message so this is a new message new secrets but I get I hit the same slot this can happen and now this force has been used twice in this

example example let's say this happens again and yeah okay now this lock assigned three times and for the values we used in this tool in this story parameters this is too much now this fox has become unforgeable and the signal is no longer safe so this is what happens when you when you go much over the sign of budget which is safe for things plus this is the reason this this budget is huge if you actually were to sign two to the let's say 25 times with this budget, your signature may actually become insecure. But since this budget is so high, you can do go stateless. Don't remember how many times how many times you've signed and that's fine. [snorts] And okay, so um signing with links

actually is pretty doable on all consumer laptops which are commonly available. It goes under one second. You have to do a lot of hashes, but GPUs are really good at that. you there it's not an issue but there are um other devices constraint devices where this is an issue so for example if you were to use hardware wallets like ledger or any hardware wallets usually it takes upwards of 20 seconds to produce a single signature and if you were to use MPC which is multiarty computation um this is very bad like you may may even need minutes to produce a single signature and because hashes do not go well with NPC And there are some techniques the you

can do pruning or we developed these techniques called sphinx G which allow you to recover subsecond signing on constraint devices. And the the the main thing you have to keep in mind when thinking of these techniques is that you need to keep the signature exactly the same as it as if it was produced by a regular sphinx plus signer because you the verifier does not need to distinguish between a signal produced with sphinx g or sphinx only normal sphinx. And if we want to go back here, we actually have no it's not that one. We have a variant here to to understand better things G. We think it's it's cool to see. So the idea here is just um you premp compute a lot of the material. You

don't do it live. So what happens is if I want to sign now I cannot. I need to do some premputation. Um now I have built a slot but I don't have a message yet. I don't have a message for the slot. I can pre compute more than once. And then when I want to sign, I come with a message. I say send ETH to Ellis and then assign. Instead of building a slot, I am actually like um grinding the message until I select one of the uh slots that I had premputed. I reveal secrets of of that slot. And this is subsecond on any device because the the point is you don't you don't need hashing there. And yeah that's the idea behind sphinx g. So [snorts]

going back to link things um what will happen in the near very near future is aggregation. uh we've seen that signature is quite huge but to like to work around that um there has been a lot of work that has been done is being carried on to aggregate this unfortunately the it's not easy like it is with BLS signature which natively aggregate but [snorts] the the way it's being done is using snarks that's basically wrap around the signatures and say these are valid and the good news for builders is that you don't have to see that uh this works at a mele you you just send your transaction in the same way you would to a verifier.

You just send it in the man poolool and then this gets taken care of in the man poolool. So if you want to build and test your applications um we actually are contributing to a test neti with foundation cryptographer Antono and and also with the contributions of team teams from ethics and other mind and this test net runs on frame transactions and link skinks and actually aggregation too. So you're welcome to come to the Sugi develop develop your applications deploy your contracts and also of course tell us if something breaks something

doesn't work for you because we need this feedback to to improve it. And now we can actually take some questions if you have it and then we'll move on to the this practical hands-on where we'll build uh your first postquantum signatures with frame transactions on this. >> If you have questions, please either type them in on the app or raise your hand so we can run a mic to you. >> Okay, I see. Can I start? Can I start? Okay. Okay. Okay. So I see someone asked once once that you change the initial parameters can you still say that lin sphinx is n standard no the answer is no. uh you can say it's

it's sphinx like it comes from sphinx plus from the design that was standardized but again a lot of stuff that is on ethereum even today is not standard is uh basically custom stuff even uh kekak is not >> no because the standardized version 3 but keak is not standard >> but also for a security perspective we don't care about the standard I can say but we care about the security proof and changing The parameter don't alter the security proof of things. It is important because if we want keep uh secure our signature we have to rely on security proof and these are really formalized in two papers really important paper one and u so is not the

standard but uh it's something that we can say is close enough to standard. >> Okay. So actually I thought some something before answering the next question which we'll get to. Uh let's start on this because we'll see why. Um so here we have the Q code which basically points to this link. I put it here if you also want to type it. And if you want to follow along I will do it with you. Um what we what we're going to do is this points to a repository we've set up and as we were mentioning earlier in 2026 since we have limited time um a coding agent will do the coding for us

we just need to know what are we building and now we know it. So we're going to basically um do what do all we need to do to sign a transaction on the lin sphinx and print transactions. And here you have the this read me. Take a look if you want and basically the the idea is now you uh I full screen. >> Okay. >> You open your favorite your favorite coding agent and you can clone the repo. Just give it a link. Do you know this is on your side and I will just tell it to look at the content of the repo which contains all of the context uh which is relevant for this task. And

a very important thing that it contains is actually the verifier code because the one way that we found is really helpful for uh uh writing this kind of things is let's say you want to build on a chain uh and sign with a certain signature. This is going to be verified by this verifier that's deployed on chain. And so you want your signer to be compliant with the verifier that's going to verify the signature. So of course then you need to check that you're not doing something wrong. don't vape coded but the this is a workshop you get idea [snorts] uh the this deliverifier is a good starting point to understand the the yeah the standard you need to use to build a proper signature

if you want to go back to questions we have some time because so okay can so uh can these things be combined with ML cam for secure do multi-device authentication and end to end message. >> Yeah. So, uh for authentication, yeah, for sure you can just uh depends on your use case. If you are to land on chain, I suggest to use lynx. But if you are not landing on chain uh you can just use the standard N because you depends on the number of message and the use case you want to use [snorts] and you can just combinate for ML cam is something nice to say about this for now there is only

one postquantum I know M um cam that is postquantum is based on latis is ML cam ashbase can allow us to have cam postquantum because it's really hard to do is impossible really uh to do uh encryption uh with ashbased signature. Okay. And another question is any key derivation algorithms like B32 for each DSA? Yeah, you can rely on the same um derivation path you use in your wallet B 44 B 42 is not important depends on you.

Uh the idea is uh the derivation part is still the same for sphinx sphinx plus for whatever you want because you have imag um a secret that we use to generate our uh data for the uh design. I don't know if there is other question I also like to add on this uh you can use any derivation path you want. the the the important part is that for example these beeps they they use hashing at some point. So that's the reason they're secure. If you had like let's say a derivation tree that only relies on secure of course that's not secure anymore. But the reason we can the user experience stays the same for now is

because all of these derivation paths that we use they are quantum safe. So if you if you are if you know the seed you you can derive keys with it and that's they can you cannot go back to the seed. Okay. So, I don't know if there is any more questions any case. So what happens when when Ethereum adopt Lyn Sphinx? Will user need to transfer

tokens from ECC derived accounts to new sphinx accounts? And what about deployed smart contracts? Do they need to be deployed? Okay. So if you have um let's say only the S network scheme changes and you have an EA uh that now signs with has a private key. Uh yeah, you will need to move that funds. But um if for smart contracts that's not the case because smart contracts >> smart contracts don't the the case of smart contract is really different because you don't don't derive the um public key of a smart contract.

You use the data you send to the smart contract to derby uh the address. So it's different really the smart contract have a private key but is impossible to find to see is the idea. So if you have a smart contract you don't need to redeploy nothing but for example if you have a multisync wallet and uh you use some address that rely on to sign on uh on this uh multisig wallet. This multi bullet can be attacked because it can be attacked the uh the signature that uh control this smart contract this multisig. This is important also when you think the there is a lot of defy

protocol that have some privilege with some address to change parameter and also do stuff inside the on the tool. So also they are the first ones that have to uh transide to this postquantum security because in for example if I have uh the the right to mint um west DC on Ethereum this is really bad for uh for for all the chain. Okay so in the meantime clo has produced something. So this is uh what we asked him. So it's a basic interface that lets you uh set up a seed randomize it rather [snorts] and then this derives an

address. Now this address is derived from the public key of sphinx. So the the way we were seeing it here uh now let's use this one. [snorts] So what what happened is we derived the secret from that uh the secrets from those things from that uh that seed phrase. We built the first the first three and the public key of that has been hashed and a slice has been taken to derive Ethereum like address then there [snorts] is the this fet of dugi this is already existing we just go on there put uh as you've seen put the address and request test at yak and then there is just this button that allows you to basically

build your first transaction so you build the frames you sign them so now if you click This is a simple send. This is going to build the frames uh computed digest for the transaction. The signature as you see is 6,000 bytes as we've seen earlier for this parameter set and the send is done. So now you can open it and this is when it loads and on the explorer you see this is a frame transaction using link. So plus quantum frame transaction uh being aggregated too but >> no no no this is not this is without aggregation so and verified on chain by the verifier you've seen earlier and if

you want to explore you can look around see the gas that is being used and all of the frames the gas rely also because we deploy the smart contract wallet for this specific uh uh contract and this is the the first transaction the the next transaction cost uh really less and I don't know if you have any question we can answer and >> there's a question of the two to the time 24 budget and if it ever is going to run out. >> Yeah. Okay. So I assume 2024 is a lot but if there will be a protocol level way to rotate your key once you hit your signing budget.

Okay. So yeah 22 24 is is u around 16 million. So million million. So when you like it's very unlikely that you run into into this issue because as a as a let's say user normal user of Ethereum you won't ever get to sign even close to a million transactions even like let's say you use a hardware wallet probably the buttons were out before you you can you can even get close to that but [snorts] uh okay but the to address the question If you were to get close to the budget, let's say the budget is lower or let's say you have some weird use case because

you get also not let's not forget that two 24 signatures means a lot a lot of gas that you need to pay. >> That was my question. Do you want to ask Claude behind you how much gas you end up paying if it's a simple transaction that only sends >> a transfer to someone else and this is the only gas you have is for the signature itself. >> Yeah. Another uh something that we do we have account abstraction now we have a native account abstraction in Egotan but uh all these um thing that rely on account abstraction so what we can do is just add another signer on on top of our smart contract and when we are close to the budget or we just want move on to another sign method we can add a simple

transaction that say okay this is my new uh key we use to sign but also So we can image a future where maybe the parameter as different to to the 30 but we we'll see. This is some parameter we like because uh they have a really um they have short sign and also the verification cost is uh not so big so big. The varation cost is important also in aggregation because when you do the aggregation also you have to verify in the aggregation with the snark the transaction. So what is important if the aggregation cost is really huge the aggregation becomes lower. So have a

parameter that allow us to verify more transaction together it's something can help our future uh uh system that aggregate the transaction. So um >> yeah also I think it's in like let's say for some reason you actually get to that point you are probably a user that that to the point of using two 24 signatures you are most likely a user that like is sophisticated user that has a very special use case and a lot of huge um players today like they they actually already do key rotation. is a normal hygiene practice you do every once in a while. You just rotate your keys and and yeah [snorts] and so you could actually

easily do that here if you were to uh ever have a use case that is uh you can you may fear runs out of signatures. So [snorts] in in with the current cost of gas let's in the sugi it's zero because it's test net but with the current cost of gas in mainet I think yeah with this with an optimistic u estimate is about about 1.5 million of gas >> most likely are going to run out of your ETH budget before you run out from your signing budget. Yeah.

No. Okay. >> It's important uh this talk I think because all you see sphinx is not something really crazy to understand. It's really simple to use and also to understand what is really difficult to sphinx is theistic behind and the proof of security of this kind of senior. This is the part that have a paper really big and really complex with a lot of um lot of stuff inside. So if a user or a developer can can use this senator really easy because to understand there is some really less concept that is important. We can also go more deeply in the fors on the watts but

this is all the magic behind. So also is simple if um for example we want to use latis base it's more harder to understand and to use because they rely on complex math. Uh so there something why we prefer to use ashbased signature for Ethereum also Ethereum chose this. >> Sure. Go ahead. >> Do you need the mic? I don't need >> I think football. >> Can you talk a little bit more about the implications of uh aggregation just because you can't do BLS does that imply any sort of like centralization um on the aggregation layer?

>> Uh so this is is a really interesting question. uh on uh execution layer now we have BLS signature but we don't use to aggregate there is a really I think nothing no one use BLS to aggregate transaction on execution layer the aggregation is really important use BLS on the consensus layer on the consensus layer u is not really a problem about uh some I can A there is a talk um that speak about more of this but the idea is every uh some validator bunch together they the submission and then send to the

next level. So you can do a regressive aggregation and this is uh the central is work really well with the centralized way. The aggregation on execution layer is a little diff different but also this this is under uh development. Now there is some um some AP they talk about this for example there is a lot of approach that approach we use this more simple on the issuki there is one aggregator that aggregate all the transaction in the man poolool and say okay we send the aggregation on on chain and we verify this is uh uh something that uh create a new uh user that is the aggregator on the mool but if we do also in the

execution layer Recursive aggregation we don't have this part. So we we will see the aggregation is something under development. So it's something we need to investigate more. So there is not a answer now. >> Yeah. >> But it might be a recursive one similar to >> Yeah. Yeah. Yeah. >> Yeah. If if I may add like the main difference when there be recursive aggregation is that uh BLS like natively aggregate with their structure. So it's very nice aggregation, very clean and [snorts] instead linings or hashbased in general don't have the structure that lets you uh do operations to aggregate them. So the way you do is the way you

do this is you build a snark that says you build you actually build a proof that says uh this transaction is authorized and then you can do a proof of proofs and so in the end you get with one large proofs one large proof that says all of these transactions have valid signatures. So what you do on the gradator side is you verify the signature you say okay this transaction is valid and you build that proof and then you take proofs and build in the recursive approach like in the Dugi approach you don't have these multiple steps the aggregator just verifies all of the transactions and build one proof for all of them and in the recursive

approach instead multiple aggregators can um verify each some transactions they they build the proof of those transactions and then someone can come and aggregate the proofs themselves until there is only one proof of the block and all of the transactions in the block refer to that proof and say I'm in that proof and the [snorts] proof says them they are valid and that gets verified on chain. So going a little bit about this the the the aggregation like using these proofs uh maybe on the numbers then you can correct me but it's not always uh worth it let's say so if a single signature

we've seen that signatures are big the trade-off is you you trade the fact that you use this proof which is bigger than the signature to verify more than one transaction. So if you have let's say two transactions most likely you the the proof is bigger than the two signatures combined and that's not the case for BLS. BLS just one one aggregated signature is just as big as one signature and here instead the point is um this the snark is bigger than one signature but is small enough that if you have let's say 20 no maybe less maybe more. Okay. So if you have in the range of 30 40 transactions then the snark is smaller than the the signatures

combined. >> On ethereum we have a lot of transactions. So it's not a problem in our test net is a problem because when you use aggregation we just maybe use one uh one transaction to aggregate. So it's something uh stupid to do but is a part uh through uh this postquantum materium. Any more questions in the room? Raise your hand or post on app.

Is there any thought about pre-ompiles? I remember a while back that was like a thing to optimize um common operations and if this were to become sort of part of the >> protocol. Yeah, the the pre-ompile as more relevant to other scheme like for example um the lithium or falcon on Ethereum. Now for example for doing this we have a pre-ompile we have the pre-ompile for cash. So we already uh rely on pre-ompile um and also the pre-ompile you you can imagage can

be the aggregation part. The aggregation can become like the pre-ompile for this kind of scheme. Uh there is not a good reason to put a pre-ompile just for swings. It's better to put a pre-ompile for the aggregation part because the aggregation is the main part is validate offchain. is valid from the node. If [clears throat] some node when we send the the aggregation proof say okay this aggregation is not valid because you can verify the aggregation you just [snorts] it's like you propagate a block that has wrong transaction inside. Uh so all this part is doing offchain is doing from the node. So in some in some sense you can image this is the uh pre-ompile that

enable these kind of signals. I see there are two more questions. I think one is uh okay. So it's um who will do the signal aggregation the builder the proposal. This talk is not about the aggregation events uh it do on the meool side. So uh are in the man poolool this part is built and is validate uh to the node and the validators of the the the blocks and also we are working on with nethermind to figure out a better approach for this but we are we are working on it

>> and then I see also is things ready for production use or does it require further security audits? Um there is some um lean uh proof that are [snorts] produced from materium and uh you can see also this link proof on the uh lin uh swing art. >> Yes. >> Yeah. And all these u parameter are link proof. So there is a lot of security about this. And also or I say we we just uh change some part of the things that not rely on um I don't know for example other uh other [snorts] uh new um one

time or new few time signature the same security proof these things have are can apply directly to the u the links so it's really easy to say okay it's secure it's production ready I think we like a community ethereum or just the alore tab I don't know someone have to say okay this is the parameter of this things and that we use this parameter for bit all this future of the postquantum for now there is a lot of proposal about the parameter and we have to find the best the the best one parameter for for sphinx Yeah, if I may add something on this. I

think as Mat was saying the main the main like debate at the moment is not whether it's secure let's say because as long as you don't know do huge modifications to the tree there should there shouldn't be concerns uh if you just change the parameters and the the issue there is like is selecting the the right parameter set is a very important choice for um like for performance but it's not only about 20% performance bump is is more about uh will hardware wallets be able to sign will in in in useful time will MPC setup be able to sign will users have sufficient signal of lifetime like these

are the questions that need to be addressed when selecting a parameter what's >> we can for sure say about listings they will use kakak for the ash base the ash function that we use and we rely on shortly yeah okay How about this question about could lyn think complement mlm in quantum safe end to end messaging protocol? We yeah I think we answered that at the beginning but >> yeah the idea is if you have to uh broadcast uh the I don't know the authentication on chain links is perfect but maybe if you just need to broadcast

transaction I don't know to messaging app I don't know what you build so uh you can just straight away use things plus from NA and have a really big budget because I what I know in messages app maybe we we you need a really big budget for sign transaction on chain is better to have a less budget so depends on the use case uh in generic approach you can find all these tool to project 11 research I don't know all but most and u you can play around you can uh also try to figure out uh the best uh um the best parameter for your your use

case. So >> and also you can share >> you can also share them at some point if you like if you are playing with it. If you at some point find a parameter set that you think has some value you can share here and uh the link will include your parameter uh choice. So if you want to tweet about it I don't know uh that's that's every effort that contributes to to this matter is a is a valid effort. Then there's the question uh what interoperability challenges arise when integrating lin things into existing applications.

>> Difficult question uh I I think the most difficult interoperability is um the gossip protocol and the meool for process all these transaction because now the senor that we send to the mool are really small. So if we increase a lot the senator size in the man poolool uh this can be a problem you have image is also with the aggregation the senator is not going on chain but there are propagating to the man poolool but I think is easy to figure out a way to uh uh have a better manpool that can handle all these uh senator Nice that can be applied in terms of

>> uh is yeah it's different on the consensus layer they don't use lin they use lin xms is a different way to sign they use a stateful scheme they use a stateful scheme because the block are subsequential so easy to keep the state because you rely on the uh the chain for sign the transaction. So it's different is diff uh is different from the use case of uh sphinx plus lin sphinx on the on usually layer.

>> Yeah. much more >> I think yes but that is not my >> and I see >> I have a >> no you should go ahead the security assumption one >> or do you want to discuss about the security assumptions lyn thinks rely on >> so basically as we were saying uh like lyn thinks what does link things matter what does l things mean is like basically adapting SH plus to to Ethereum needs. So if you just change parameters, the security assumptions are the same one that are described in SH plus uh papers security proofs and then

if you go ahead and do some more uh reckless changes then it depends on what you do. Like for example, if you change the the one time signature, you need to to prove that the one time signature is is secure. you add that security assumption and but again if you are just changing the parameters numbers that's fine like the you don't change the security assumption by changing that. >> All right then my bonus question what does the 11 come from or what does it stand for in project 11?

>> We are new on project 11 but is the 11 hour before the hand I think. >> Okay. uh >> an 11 hour >> solution >> refers to the clock. Yeah. >> Yeah. >> Yeah. So uh now is a time that we have to do some changes in our uh security system with the post the quantum computer and also with the super mathematical intelligence AI we need some issue and I don't know where we go but the idea is we try to build something that last and links is something can last a lot because they rely on a simple and wellproof uh cryptographic proof. So it's something

really important >> and if you want to contribute on this 11th hour then please use the test net and deploy your contracts and apps there and see that if everything works. >> Absolutely. See you on the sub.