Post Quantum Transaction Signatures #001

|2026-02-04| Agenda: #1889| canonical JSON

Transcript

Gaudenzio Nethermind:Go then!

Antonio Sanso:Hello, hello. I guarantee you.

Antonio Sanso:Can you hear me?

Gaudenzio Nethermind:Yes, I can hear you very well.

Antonio Sanso:I think the call is recorded, and not sure it's gonna be on YouTube yet.

Gaudenzio Nethermind:No worries.

Antonio Sanso:It's still literally, I was just, trying to check. Actually, do you mind if we do a check with you about the presentation? Let's see…

Antonio Sanso:Cause I have something to present, and… We'll check, please.

Antonio Sanso:Okay, let's see… screens, documents, advanced, documents, no.

Antonio Sanso:So let's try it.

Antonio Sanso:This clip.

Antonio Sanso:Okay.

Antonio Sanso:Metalized crypto.

Antonio Sanso:Okay.

Antonio Sanso:So what do you see nowadays?

Gaudenzio Nethermind:Agenda.

Antonio Sanso:See my… okay, but we'll… you will see, like, the slides… move.

Antonio Sanso:Yes, I see the slide, but only… yeah, it's… Presenter mode, or…

Gaudenzio Nethermind:Yes, presentation mode. Full screen to me.

Antonio Sanso:Full screen, okay, perfect.

Antonio Sanso:Thanks a lot for double checking, it just… That, yes, okay.

Antonio Sanso:Okay, stop sharing.

Gaudenzio Nethermind:Great. I'm gonna grab a coffee. Catch you later, Antonio.

Antonio Sanso:Sure, sure, we're still at 5 minutes, thanks a lot for helping me.

Gaudenzio Nethermind:Of course, good luck, mon ami, goodbye.

Antonio Sanso:Thank you, thank you.

Antonio Sanso:Hello, everyone. It's, 15…

Antonio Sanso:UTC… I guess we'll give a few minutes if someone else is joining a bit late. Let's give them a couple of minutes.

Antonio Sanso:And.

Stefa:Hello, everybody.

Antonio Sanso:Hey, hey.

matteo vicari:Hi.

Antonio Sanso:smooth.

Antonio Sanso:Hey, hi, Mattel. The agenda is,

Antonio Sanso:That's okay. The agenda is on the… on the GitHub issue.

Antonio Sanso:But, yeah. I will start with a quick presentation in a couple of minutes to set the stage. Many of you might know already what I'm saying there.

Antonio Sanso:And, but yeah, we quickly set the stage, and then we'll have some more,

Antonio Sanso:Technical, a more in-depth presentation, and again, everything's in the agenda.

Antonio Sanso:We'll start in a couple of minutes, and yeah.

Antonio Sanso:Let's see…

Antonio Sanso:For people who are joining now, we are just waiting a couple of minutes to give the chance for people to join. It's the first call, so some things might be a bit rusty.

Antonio Sanso:But, yeah, I'm sure… It's gonna be fine.

Renaud-ZKNOX:Hi, everyone.

Antonio Sanso:Hey, I see already some of the presenters joining. I see Renault, I see Stefano, I see Simon.

Antonio Sanso:So, will be some people presenting after me, so, looking forward.

Antonio Sanso:And one more minute, and we start.

Antonio Sanso:Just double checking, are you guys seeing my… my…

Antonio Sanso:slide? Like, okay, cool. Let's start.

Antonio Sanso:So, someone thinks on this presentation might be obvious from the beginning, but again, the first call of the post-quantum transaction signature is the kickoff call, so just setting the stage quickly.

Antonio Sanso:And, yeah.

Antonio Sanso:Things might sound, like, already known, but, better like this.

Antonio Sanso:them.

Antonio Sanso:Now, let me probably, again, share… Alright, let's do it. So…

Antonio Sanso:February the 4th, and let me try at least to get rid of the Presenter, I'll put another…

Antonio Sanso:Screen, okay.

Antonio Sanso:So, breakout room, kickoff call, and, yeah.

Antonio Sanso:So, I've done this presentation a bit bigger in the past, but I cut some of the parts here. But again, like, once at the stage, and

Antonio Sanso:I always like to break Ethereum in four micro components. There's the execution layer, the consensus, the data availability sampling layer, and the status theorem.

Antonio Sanso:That before had the name of Burkeleton trees is not anymore the case.

Antonio Sanso:But yeah, so what these things have in common, well, the execution layer, of course, like, to, to have a signature on a transaction signature, you have BCDSA. For consensus, we use BLS signatures.

Antonio Sanso:For data sampling, we use KCG commitment, and for standard Ethereum, we used to have this solution based on Peders and Commitment, and basically, like, what they have in common, that all they use elliptical.

Antonio Sanso:In particular, for ACDSA, we have this SECP156K1,

Antonio Sanso:for consensus and KC Commitment BLS, and, for Vertical 3, we used to have this proposal that used Bandersnatch. And, well, we all know that, with, there's this, algorithm, by Shor, 1994, that breaks completely, this, initially was, was designed to, to break

Antonio Sanso:factorization of a big component number, and, yeah, and then it was adapted to break as well this could log on final field and elliptic curve, so we need to start from scratch.

Antonio Sanso:So the first things that, that, on this topic was actually introduced by, by, by Vitalik, where, where he actually, showed what it is, mine to do.

Antonio Sanso:if some quantum emergency happens, we'll see a presentation from Stefano actually going deeper in that, on this proof of sets later on.

Antonio Sanso:And, in this post, actually, we're discussing this, proof of seed that it can be post-quantum, and the fact that, actually, the atrium address, if you, if you never spend any, any, any ether, you're kind of…

Antonio Sanso:help save, because you are not exposing your public key, because the address is the Chetri or Kedjak, actually, Kedjak, no, Chetri, of, of, the public, of the public address, of the public key that, that is not exposed directly.

Antonio Sanso:So, again, we did some, some new mathematics that is resistant to quantum cryptography, so to quantum computers, and we basically have, like, this, like, 5-6 macro areas. There's hash-based cryptography.

Antonio Sanso:There's a lattice-based cryptography, there's code-based cryptography, multivariate, and a supersingle elliptical resogenic cryptography.

Antonio Sanso:And, yeah, we have some algorithm here. We need to choose,

Antonio Sanso:Some that is actually good for us.

Antonio Sanso:Now, the message that, that I want to pass here is, like, it really takes time. If we see what happens in the Web 2, well, there was this announcement and a call for proposal by NIST in 2016, then there was this proposal submission that started in 2017. Many got immediately broken, even some the nights of the… when the proposal submission happened.

Antonio Sanso:But then, 2018-19, there was the first round of evaluation, where some algorithms were cut.

Antonio Sanso:2019-20, the second round, and the candidates were standardized, so the selection of the candidate to standardize was in 2022, and the implementation started since 2017 is still going on, so really, it takes time. Which one are the winners? Well, for signatures, there are three, basically, winners.

Antonio Sanso:Two lattice, one hash-based, so the lithium…

Antonio Sanso:Falcon Lattice-based, Sphinx hash-based, and for King Capsillation kyber. Well…

Antonio Sanso:We are… at the moment, we… for these calls, we are only discussing about signatures, so these are…

Antonio Sanso:Probably some that we're gonna see, because they're standard, so we're not reinventing the wheel.

Antonio Sanso:And, want to highlight as well that, at the EF, at least we have started to think about post-quantum since long.

Antonio Sanso:So already had the… there's this, Justin Drake talk in 2019, where it was, depicting how Ethereum 3, could look with quantum security. But then we had a series of paper on, synchronized mold signatures using lattice, or…

Antonio Sanso:a single secret leader election and so on, that went… the cryptograph team has been working on this.

Antonio Sanso:Papers or calls.

Antonio Sanso:During the years.

Antonio Sanso:Well, then, like, in 2024, we have seen a bit of, quantum accelerations. There are the… you probably remember, there's been this article, pointing in, the research from Google, from Microsoft, and, yeah, so…

Antonio Sanso:we really need to actually… we've seen two things. The quantum computing is accelerating, it takes time to select algorithm and deploy, so we really need to do something, and

Antonio Sanso:Yeah, this is probably, you guys seen as well, this, this, tweet by, by Justin, that, actually, shows that the Twin Foundation,

Antonio Sanso:long-term strategy for, for quantum. So,

Antonio Sanso:These are, again, the four components, execution, consensus, data availability, and status.

Antonio Sanso:This breakout room is only about execution, so if you're interested about other things, it will be other efforts.

Antonio Sanso:On these calls, we mainly focus on post-quantum transaction signatures, so execution layer.

Antonio Sanso:And that's basically the introduction from my side. The agenda for today, after me, we have Reno and Simon that are showing a couple of EIPs that have already been done in the last year.

Antonio Sanso:Then we have Nico showing some new account abstractions that looks to be a really strong pillar for post-quantum transaction signatures on Ethereum. Then we have Fabrizio or Stefan, I think it's Stefan, into presenting zero-knowledge proof of seeds.

Antonio Sanso:And, finally, we have Dano presenting Cryptographic agility, and this will have time to have some discussion, some minutes of room after all this presentation.

Antonio Sanso:And that's basically… From my side.

Antonio Sanso:So, I will happily give the word to Reynold Simon. You tell me… Who of the two?

Antonio Sanso:So is your name, I'll make you presenter, so…

Renaud-ZKNOX:Yeah, I will.

Antonio Sanso:here.

Renaud-ZKNOX:I will share my screen. Can you see it?

Antonio Sanso:Sure. Actually, yes.

Simon - ZKNOX:Great. Can you also hear me, or…

Antonio Sanso:Yeah, yeah.

Simon - ZKNOX:Okay, cool.

Renaud-ZKNOX:Yeah, great. So, thanks, Antonio, for launching this bracket room, and for having us. We are glad this initiative exists, and I think it's really needed.

Renaud-ZKNOX:So at Zkinox, we've been working on Post Contem,

Renaud-ZKNOX:Cryptography for blockchain, for the past, for the past 2 years.

Renaud-ZKNOX:closed with, with Antonio and, and the EF.

Renaud-ZKNOX:implementing, emulation of the two EIPs that, Simon, will introduce. So basically, we, we've wrote,

Renaud-ZKNOX:EIP8051, which is MLDSA, it's standardized by NIST, and EIP8052. It's FNDSA, it's Falcon precompiled.

Renaud-ZKNOX:So everything is, working, it's deployed, we employed, we integrated it into an e-breed and agile, verifier, so it's a 4337, acquence.

Renaud-ZKNOX:Which can be tuned using K1, R1, MLDSA, or FMDSA. It's,

Renaud-ZKNOX:Yeah, so it's, it's deployed, we have, implemented the signers, so basically MLDSA work on ledger hardware signers. We have only, hot wallet, signer for Falcon, because of constraints, and Simon will talk about this.

Renaud-ZKNOX:And we also, we also specified how to derive, derive key with, PQ,

Renaud-ZKNOX:PQ39, so… This is a full stack,

Renaud-ZKNOX:So… so it's… it's working, it's working today. Looking at the cost that we have, so Gui is really cheap right now, so even in… in L1, it's, it can be used to protect high-value assets. For instance, we… we implemented for the demo.

Renaud-ZKNOX:yield into IvePool. So, we have, like, with the cost we have today, it's, like, $2 for a single transaction, so it's totally, doable, over L2.

Renaud-ZKNOX:And even for L1, for high-value assets, it's possible, so…

Renaud-ZKNOX:Even without, without pre-compile.

Renaud-ZKNOX:So why do we need precompiles? We need precompiled because,

Renaud-ZKNOX:If we want it to be comparable with, and have some sub-dollar, some dollar cost, yeah, we will need to switch to precompiles, and…

Renaud-ZKNOX:Simon will detail, the… The gas cost and the complexity of the precompiles.

Renaud-ZKNOX:Simon?

Renaud-ZKNOX:Simon?

Antonio Sanso:Renault, quickly, like, there is some question on the chat. There's, like…

Simon - ZKNOX:Can you hear me.

Antonio Sanso:Yeah, we hear you. Quickly, like, I read this… I don't know if you see, Renault, the question on the chat.

Renaud-ZKNOX:I will…

Antonio Sanso:Good to meet you It's about the… what are the key sites? Okay, perfect, perfect, Simon.

Simon - ZKNOX:I'm gonna talk about this now, yes.

Antonio Sanso:Perfect.

Simon - ZKNOX:So, just to give a quick summary of the different options of, signatures, so as Antonio said, there is basically 3 winners of the NIST standardization, Delicium, Falcon, and Sphinx.

Simon - ZKNOX:The two first are based on lattice, and the third one is based on hash function.

Simon - ZKNOX:And, the big issue with the third one is that it produces large signatures, and it's a problem in the context of Ethereum, because we want a small footprint on chain. So we decided to look at Delithium and Falcon, the two first ones.

Simon - ZKNOX:And so here you can see, the answer of the equation, the different,

Simon - ZKNOX:public key and signature size, so if you just look at the first two or three lines, you see that Falcon seems to be much better in terms of size.

Simon - ZKNOX:Smaller signature, smaller public key. Also, in terms of gas costs, so we did the implementation of the verifier in SolidZ.

Simon - ZKNOX:So that, you can…

Simon - ZKNOX:we can estimate the cost in terms of gas. So, $4 million for Falcon, and 13 million for Delithium, which is much larger than what we have with ECDSA, because it's only a few thousand of gas in…

Simon - ZKNOX:Using ECDSA.

Simon - ZKNOX:If we would have a precompile, we… it would reduce drastically the cost, because we would get something

Simon - ZKNOX:more or less similar to ECDSA for Falcon, and slightly higher for MLDSA, for the lithium.

Simon - ZKNOX:So this is in terms of comparison of size and efficiency, but then there are other aspects that are also important. For example.

Simon - ZKNOX:Delithium has been standardized by the NIST with FIPS 204.

Simon - ZKNOX:And for Falcon, it's still in the process, and it takes a lot of time, so we don't have a standard yet.

Simon - ZKNOX:In terms of implementation, it's quite tricky to implement Delithium… to implement Falcon, sorry. Delicium is much easier, and that's why we did an implementation even in hardware, while for…

Simon - ZKNOX:For Falcon, we didn't investigate the hardware implementation, also because it uses a lot of RAM, so we focused on delytium in terms of hardware.

Simon - ZKNOX:Glyithium has been integrated into different, industrial projects. It has been…

Simon - ZKNOX:done in Paskey, also in Apple. It's in the process, but it's, seems to be more…

Simon - ZKNOX:there are more products integrating DLTM than Falcon. And finally, in terms of zero-knowledge proof, it seems to be easier to…

Simon - ZKNOX:modify delithium to get something ZK-friendly than for Falcon, where the field of definition is very important for the parameterization of the scheme.

Simon - ZKNOX:So this is for… just for comparing Falcon and Delicium. And now if I need to go into detail on the EIPs.

Simon - ZKNOX:So, the first TIP for Delithium, which is MLDSA, actually, is AT51,

Simon - ZKNOX:We provide… we decided to propose two precompiles, one for the NIST-compliant version of Delithium, MLDSA, that uses a shake as a hash function.

Simon - ZKNOX:And we decided to propose also a second precompile using… which is exactly the same, but replacing this, shake, but by another hash function.

Simon - ZKNOX:Because, KShack is available on… in the precompile, so it, reduces the gas cost. So using this, change of hash function, we can reach till 8 million gas costs.

Simon - ZKNOX:We provide some test vector, and we integrated this into a hybrid account, where you can create an account, sign a transaction, using both ECDSA and MLDSA.

Simon - ZKNOX:So you'll hear about this later with Renault, that will show you how it works.

Simon - ZKNOX:So this is for the first EIP that we propose, and the second EIP is AT52, so the next one. And here we propose something slightly different, where

Simon - ZKNOX:we propose two precompiles, one for the polynomial challenge that is necessary for Falcon, and one for the core algorithm of the verification.

Simon - ZKNOX:So… In Falcon, you have really a separation between the hash and the core verification, which enables you to…

Simon - ZKNOX:to… to instantiate Falcon using another hash function without changing the core verification.

Simon - ZKNOX:So, using these two schemes.

Simon - ZKNOX:you can get till 1.6 million GAS if you use a catch-a-cash function in the verification.

Simon - ZKNOX:And, we also provided some… some test vectors, generated using the NIST reference implementation.

Simon - ZKNOX:And we are still integrating this into a 4337 account, so that you can choose if you want to use Delithium or Falcon for your hybrid account.

Simon - ZKNOX:Yeah, that's it, for me.

Simon - ZKNOX:I think, Renault, you can continue.

Renaud-ZKNOX:Yeah, so, last slide, is about a demo. So, we just dropped the link, to the app, so everyone can launch, launch it. So, basically, while Simon was speaking, I was, staking in Jave.

Renaud-ZKNOX:So, I stack 0.1 Aave here, the user op ran well, it's here, so let's…

Renaud-ZKNOX:Let's have a look on EterScan, but if you scan this, we shall be able to see at this user up.

Renaud-ZKNOX:Of course… Okay, I'm not on Sepoliard.

Renaud-ZKNOX:Simple later scan.

Renaud-ZKNOX:So, basically, what this means? This means that, we don't have to change the protocol, only the front has to integrate the 43, 37 actions. So, basically, for execution layer.

Renaud-ZKNOX:problem is solved, except starting deploying the account, we are still relying on dumb bundlers and EOS, and I guess that's, next evolution of how we'll, we'll solve this.

Renaud-ZKNOX:And, yeah, so here is… here is the transaction.

Renaud-ZKNOX:So, basically, this is, this is the… the staking, the rest is, the cost, for… for… for the bundler, so…

Renaud-ZKNOX:So yeah, you… you have everything to… to run.

Renaud-ZKNOX:To run the demonstration, yourself.

Antonio Sanso:This is… this is beautiful right now. I think, like, that this will give really a segue for what Nico will show next, because basically, like, I think you are doing this demo using non-Native account abstractions.

Antonio Sanso:But, Nico actually probably is gonna show the long-term plan for, like, an abstraction, and part of it was already presented last week.

Antonio Sanso:at the ACDE.

Antonio Sanso:So…

Renaud-ZKNOX:Yeah, that's really what we need, to have something native, so we don't have this.

Antonio Sanso:Right.

Renaud-ZKNOX:Kind of. So today, actually, it's not a big risk, it's more DDoS, because you can front-run the deployment. So I guess, as long as you don't send value, it's just, like.

Renaud-ZKNOX:Pissing off, but not, phones are not at risk, but to be totally clean, and totally…

Antonio Sanso:Right.

Renaud-ZKNOX:We need this native,

Renaud-ZKNOX:This is really the missing point, to have the native AA, and we would gladly integrate our demonstration into this native AI when there is the possibility to do so.

Antonio Sanso:Perfect. Thanks a lot, Renault and Simon, for this beautiful presentation and demo. It was really, really nice of this in action, actually. And I think this is, again, a perfect segue for the next stuff, that is Nico. And yeah, there is a lot of questions in the chat.

Antonio Sanso:But I think, like, if there is one thing that is fixed, then we know that it's gonna stay, so we don't have clarity which algorithm we're gonna deploy, which AP it's gonna be, but I think all we agree here that account abstraction is the fundament, is the basis

Antonio Sanso:For anything we're gonna choose. And, that's, that's, Nico. If you're here, feel free to share the screen. And, I don't know, Reno, probably you need to stop sharing the screen. Thanks a lot.

Nico Consigny:I think…

Antonio Sanso:I should've…

Nico Consigny:Yeah, I think it's okay, I… I won't be, sharing the screen, I would just be,

Antonio Sanso:Okay, perfect.

Nico Consigny:a small… Oh my gosh, no.

Renaud-ZKNOX:I stopped sharing, I stopped sharing.

Antonio Sanso:Okay. Great.

Nico Consigny:it's…

Renaud-ZKNOX:Okay, the mic to Nico now.

Nico Consigny:Alright, so yeah, thanks for… thanks for having me,

Nico Consigny:So I work at the time of foundation. I've been doing a lot of account abstraction stuff over the last few years.

Nico Consigny:It's kind of a full circle moment for me, because I started my career 10 years ago in a crypto analysis company.

Nico Consigny:Selling, post-quantum transition to…

Nico Consigny:Banks and, and, different,

Nico Consigny:high, security companies, so it's glad to see that this transition is coming to Ethereum.

Nico Consigny:So…

Nico Consigny:Account abstraction. We have been doing a lot of different account abstraction stuff on Ethereum over the last few years. The one that is compatible with post-quantum cryptography is 43.27.

Nico Consigny:4237 is, a near sea, so it's,

Nico Consigny:A standard that is not in protocol.

Nico Consigny:So it is a great standard, but it comes with a lot of drawback, because it's not natively in the protocol.

Nico Consigny:So it has a gas cost overhead. It is, slower than a native transaction, because you have to, to go through some, bundle, an entry point, so…

Nico Consigny:there is a lot of complexity around this. The main complexity also comes from gas management, because when you do this, you have to manage a lot of gas parameters.

Nico Consigny:So these are the reasons, motivating, native account abstraction.

Nico Consigny:So native account abstraction was envisioned from the very start of Ethereum. It is basically the cool thing that you can do with a smart contract is to have arbitrary logic.

Nico Consigny:So it's very sad that we have these very cool smart contract properties, but we don't apply them to wallets natively.

Nico Consigny:So finally, this is what native AA is trying to solve.

Nico Consigny:And so very recently, we had a new, proposal, which is, 8141,

Nico Consigny:And it's called the Frame Transaction Proposal.

Nico Consigny:So what it is, it's simply a new transaction type, so the type is 0X6, yeah, if I'm not mistaken, yeah, 06.

Nico Consigny:And it, replaces the current,

Nico Consigny:ECDSA signature model with a flexible frame system where you have a validation frame, an execution frame.

Nico Consigny:And, a default, frame, a verified frame.

Nico Consigny:And basically, you can iterate through these, frames, and…

Nico Consigny:each frame is approved or reverted. If a frame is reverted, the entire transaction is going to be

Nico Consigny:It's gonna… it's gonna be reverted.

Nico Consigny:So during the verification frame, you are actually not spending gas. It's like a read-only function, so it's like a status call.

Nico Consigny:So if your transaction reverts during, the verify phase, it's… it's actually not that bad. You're not losing money. If it reverts during the…

Nico Consigny:execution, frame, then it's more problematic, because you're actually, Spending money to do it.

Nico Consigny:And so what DSLOs is,

Nico Consigny:You have a transaction payload that is going to be hashed, and the signature is going to be outside of this payload, so you can have an arbitrary signature that you like to match the…

Nico Consigny:to match the transaction that you want to have. So this is very nice, because this is flexible, it doesn't enshrine any scheme.

Nico Consigny:You could use… the Solidity verifier that ZKnox has been working on.

Nico Consigny:The problem would be that the cost of this verifier is super high, so this is why we have the pre-compiled proposals.

Nico Consigny:So this is, like, to give you a rough summary. If you want to dig more into the EIP, I invite you to read the specification. But basically, this is free frame. You have the default, mode, which is a call…

Nico Consigny:to the entry point to either deploy a contract or to have someone to pay for the transaction, you have the verify frame, which is the verification of the signature, and you have the sender frame, which executes the user call with the

Nico Consigny:Account address, so you're directly executing your call yourself.

Nico Consigny:So yeah, I invite you to dig the proposal if you're interested, but to focus on the…

Nico Consigny:on the cryptography, what it enables is some crypto agility, so Dano will be talking a little bit more about this. So yeah, it enables…

Antonio Sanso:Yeah, thanks a lot. Just, like, there are a couple of questions on the chat, I don't know if you see that. Thanks a lot for this, the introduction of this new EIP. It's actually really interesting, I was really happy to see this last week. And the first one, actually, quickly want to address it, we'll go back to Renault. Is this actually KIL7701, or is this, like, an…

Antonio Sanso:Or to…

Nico Consigny:It actually is, built on top of the 7701 proposal, so it's like, yeah, it replaces 7701 entirely.

Antonio Sanso:And Renault is asking what happens to the old 4337 thingy? It continues to stay, or…

Nico Consigny:That's a good question. You mean the URC itself will, yeah, continue to exist?

Nico Consigny:it will continue to exist and to work. Obviously, you would have a easier time just switching to the full native AA, but

Nico Consigny:the existing 4337 infra and wallet would continue working.

Nico Consigny:Obviously, there would be some… native migration path, I assume?

Nico Consigny:Like most of the 4337, wallets, I assume, would,

Nico Consigny:offer you to upgrade to a native AA account. I mean, that just makes sense for… Yeah, I mean…

Antonio Sanso:Yeah. What I will expect, like, this will fly, I will expect, like, a transition phase, but then you don't have really motivation to stay on the legacy system, and we'll expect that after a while, people will just go to the native solution.

Nico Consigny:Yep.

Antonio Sanso:Right.

Nico Consigny:Exactly.

Antonio Sanso:Cool. Thanks a lot, Nico, and again, probably this is not gonna be the last time we talk about account abstraction in these, breakout rooms.

Antonio Sanso:again, for me, like, the CAN abstraction is really, like, the base where we ship on, and probably we may need some kind of way to integrate properly, with the canned abstraction, so all the AIP that will come out of this, this work.

Antonio Sanso:We'll need to be, counter abstraction aware, somehow.

Nico Consigny:Absolutely, and just to… one last word on the roadmap, so we have the native AI on the roadmap, then we would have a, let's say, a selection phase of different schemes, or different precompiles.

Nico Consigny:That would come right after.

Nico Consigny:And then, later down the road, we would have to discuss how to aggregate the signatures on the execution layer, because as we said, they're way bigger than regular transactions, so if this becomes the default type, it would be nice to aggregate them so we don't take a 10.

Antonio Sanso:Right.

Nico Consigny:slow down.

Antonio Sanso:All right, let me tell you something on this. This is, like, of course, it's the call number one, but for call number two, we'll have already, some presentation on the topic. We have someone presenting about,

Antonio Sanso:aggregation of Wisconsin signatures is a tough, problem, unfortunately, because we don't have, like, a BLS…

Antonio Sanso:style post-quantum schemes, but yeah, that's, welcome in the post-quantum world, where we have everything is, a bit uglier.

Antonio Sanso:Anyway, I think next is, I don't know if it's Fabrizio or Stefano presenting? I think Stefano, right?

Stefa:Yup.

Antonio Sanso:Cool. Stefan, I don't know if you want to share yours. Thanks a lot again, Nico, for this, and

Antonio Sanso:Like, let's go with the next presenter, Stefano.

Stefa:Excellent.

Stefa:So let me just share the slides. I have some slides just as a…

Stefa:There's a talk, can you see them?

Antonio Sanso:Yep.

Stefa:Don't see myself anymore, but yep. Alright, yeah, excellent. So, a brief, brief presentation about our…

Stefa:a proposal we've been working on, with, Fabrizio, some other collaborators, and now recently also Antonio, on, a slightly different

Stefa:approach to quantum mitigation, less patch, less a solution to the problem, so post-quantum signature adoption and implementation, and more, mitigation

Stefa:for unforeseen emergencies, is what you could describe what Vitalik described in 2024 as a graceful emergency fallback. So, something which can be done today.

Stefa:Or in the next, like, few weeks or a couple of months, well before quantum threats become realistic, but which would secure Ethereum in case of an unexpected quantum breakthrough. So, what happens if we are wrong about the timeline in quantum technology? I am myself from a quantum computing background. I know most of the people who work in some of the

Stefa:major manufacturers.

Stefa:And some of them are, like, more advanced on timeline than they might publicly disclose. And so I think we need… we believe we need a mitigation strategy that can work in the event of an emergency, can deploy fast enough, or in fact can be already deployed.

Stefa:In order to avoid, sort of, an ecosystem crash before protocol-level post-quantum EIPs can deploy, because these are more complicated, they require, changes at the protocol level, the timeline is not quite as, quite as nimble, and at the same time, I think

Stefa:We don't want to be in a situation where we make a hasty decision of the definitive cryptographic primitive we want to adopt for post-quantum signatures.

Stefa:Because there might be a minor tail risk that something will happen earlier than expected. So, there should be a way to buy us time to make the right decision, but at the same time to have a fallback in case something unexpected happened. And so these…

Stefa:is the… this was sort of the guiding principle for our work, for the work we're doing. We want to have a user space mitigation solution, a shorter mitigation solution, so something which can be deployed now and ultimately will become unnecessary when a more permanent solution is deployed. It should

Stefa:cover the majority, if not totality, of hardware wallets and software wallets, so we want almost all users to be covered. It should occur entirely on-chain, should be at Layer 1, there shouldn't be hard forks, new transaction types, trust intermediaries, none of that. It should be, like, a pure Layer 1 solution, no modification required to the apps that need to adopt it, and most importantly.

Stefa:contrary to many other mitigation strategies, no user action required, because we believe that this is likely to be a black swan or tail event. It's hard to convince users that they should change the way they use the chain today.

Stefa:but we still deploy something which protects them regardless. And so these are… I mean, these are the Zirata, of course, and we can see how far we can get with what we have.

Stefa:The proposal we came up with, and this is still work in progress, so of course, any questions, all questions welcome, is to implement something, on the lines of the, of Vitalik's 2024 proposal, and then, this is based on our SATAD,

Stefa:proof-lifting, ideas, we lift the, current quantum weak schemes, so East DSA, to quantum resistance schemes.

Stefa:via ZK proof of some pyramid for some step in the key generation process that is hard to invert with quantum computers. So, for example, cryptographic hashing is believed to be impossible to invert with quantum computers.

Stefa:Practically impossible, of course. And so that is the target for our… for the first step of our work, which is what we could call proof of seed, is what we're talking about today.

Stefa:And the second step in the work is to say, oh, okay, Ethereum, specifically Ethereum, because the proof of seed works for pretty much every chain, really. It's a Bitcoin-compatible thing, it's a Solana-compatible thing, but Ethereum has a kind of abstraction.

Stefa:and the delegation features that have already been accepted into the protocol and are widely used and widely supported. And so we can use that proof of seed to provide ways for users to, with one click, switch from a weak account to a resisted account.

Stefa:At the time of the emergency, even though their key at that time might already be broken.

Stefa:And so, in that way, we protect everybody without previous action. So today, I'm going to focus briefly on our progress on the first step, so practically achieving proof of seed, which was an interesting challenge.

Stefa:We focused mostly on BIP32 derivation, so hierarchical deterministic wallets.

Stefa:by the point that many, many other key generation schemes involve hashing at some point, and so similar techniques could be applicable, it's just they're not as standardized as BIP32.

Stefa:In BIP32, there are multiple BIP32 and BIP39 mnemonics. There are multiple opportunities for post-quantum lifting. If you have a child key with some non-exposed parent or ancestor key, for example, a master key that has not been exposed.

Stefa:then you can do this lifting to the ancestor. You can say, I know the ancestor key from which this child key was derived, and that's protected, because it cannot be inverted. If you have an exposed master key, which has been raised as a point of contention for some of these approaches, well, you can actually list it to the master seed, and there are ordinarily no reasons that the master seed would have been exposed, unless it has been compromised.

Stefa:In which case, for BIP32, it sort of ends there, you've lost the master seed, and that's it. But if you have a BIP39 master seed derivation from mnemonic, then there are 2048 more hashing steps in between. And you can just go to the previous one. Typically, those hashing steps, the outcomes of those hashing steps are not stored in the hardware wallets, or within the wallets in general.

Stefa:And so it's unlikely that those intermediate steps, or do you… Original mnemonic have been exposed.

Stefa:And those intermediate steps, like the last one, for example, can be used as the witness to lift the master seed, and even recover from compromised master seed, which is pretty useful. There are some challenges to make things interesting, because otherwise, where's the fun? Proof generation for…

Stefa:succinct techniques is typically memory-intensive, and one of the biggest constraints for secure elements, which are the… one of the most common ways of implementing, like, hardware-secure wallets, is that they have really, really tight memory constraints. We're talking a few dozen kilobytes at best.

Stefa:If we talk heap space, it's maybe less than 10 kilobytes. So, unlikely that any of the succinct techniques could be easily implemented. There are several challenges there. Of course, I'm happy to be contradicted, and I'm happy to be told that there are some nice techniques that can be made to fit, but the ones that we could think of wouldn't fit.

Stefa:What we can do is we can use some slightly older techniques that are not succinct, such as MPC and NAT,

Stefa:Use those to do the proving on element, use stream proofs, which are incredibly memory-lite. You can make them have a footprint that is within a tiny, tiny constant of the footprint of the original algorithm you're trying to prove, so it should fit. It's like 2 kilobytes, 1.5 kilobytes, it's really nothing.

Stefa:And then what you do is, this is the step that extracts the secret from the secure element. And at that point, the secret can be sent to anybody. Like, any machine, untrusted or trusted, paid or unpaid, can do the next step, which is the recursive verification. So you take this and use stark recursive verification to produce a succinct proof.

Stefa:of the statement, I know a proof.

Stefa:that there was a pre-image to this hashing step, and then that's the one that is used for on-chain verification, and on-chain verification for that is reasonably cheap, especially if we approve VIPs for the number theoretic transform.

Stefa:The other minor challenge, I mean, minor in the sense that it is, it's more of a political problem than a technical one, is that lifting child keys to non-exposed ancestor keys, and in particular to a non-exposed master key, is something we can do in user app space for these devices. Typically, the master key is available, and therefore even just make an app.

Stefa:That has access to the master key and uses it to lift.

Stefa:The problem is that if we have exposed master keys, or even compromised seats, which are typically unrecoverable, we would need access to secure OS internals for this to work.

Stefa:Two possible solutions, depending on the risk appetite, I guess. One is integrating the MPC in the head primitives directly in the secure OS. They're actually quite flexible, and they allow you to do a lot of interesting things, so that might be something which could be done, or could be useful.

Stefa:Over alternative, some limited exposure of either the master seed or the pre-image to the final hashing step in the BIP39 derivation.

Stefa:I am aware that these are things that make

Stefa:people's skin cryptograph versus skin itch, but, I mean, we're talking about extreme measures, and so it could be possible that this would be a solution.

Stefa:We are continuing to work on this. We should have a concrete implementation with the demonstrator out soon on our repositories.

Stefa:In the next, like, couple of weeks, we want to, like, push this step hard, we want to have a full demonstrator ready by each CCC for this. The account abstraction part is the next one.

Stefa:And I imagine that, given our passion for account obstruction in this breakout room, I'm sure that we will have more opportunities in the future to talk about it.

Antonio Sanso:Great. Thanks a lot, Stefano. Two things here. I see that Fabrizio, thanks a lot, answered already a lot of questions that were made on the chat. Thanks a lot.

Stefa:I didn't even see. I was so focused on chatting, or talking.

Antonio Sanso:Yeah, yeah, no, this is good, I mean, you were working pair. And, there are things, like, that, Renault in the chat, I knew about that, but here he's actually saying as well. They have been working on kind of, similar topics, at least for the derivation of BIP39, and I think, really, here, it will be really nice to, to, to have, like.

Antonio Sanso:there's a great synergy here, and I think we should try to collaborate on this, because the work are actually really compatible, and they're really… I'm really happy to see this actually happening. Thanks a lot for the presentation. I know that Dano has a really hard and tight schedule, so Dano, I think that,

Antonio Sanso:You can go ahead with your… with your talk, and then maybe we come back to discuss about something more. But I know that you have to go, right, Dano? So you're really into the presentation right now. Exactly.

Danno Ferrin - Tectonic.xyz:Can I get the screen?

Antonio Sanso:Yeah, Steven. Thanks a lot, Tegan, Stephan, for presenting, that was really insightful.

Danno Ferrin - Tectonic.xyz:Alright.

Danno Ferrin - Tectonic.xyz:So, the topic I've been asked to speak about is something that I think is really important to this whole transaction signature migration format, is a concept called cryptographic agility.

Danno Ferrin - Tectonic.xyz:Let me get that on the right screen…

Danno Ferrin - Tectonic.xyz:So, cryptographic agility, as a short discussion, what he means here is the ability, if we can add or remove cryptographic algorithms without requiring major changes to Ethereum.

Danno Ferrin - Tectonic.xyz:And on the bottom is a very rigorous, formal definition that NIST uses when they do their discussions about cryptographic agility.

Danno Ferrin - Tectonic.xyz:And the reason that I put that down there is to note that the problems that we're facing with cryptographic agility are not unique to Ethereum. There are lots of systems out there that need to migrate from lift-to-curve and RSA signatures to much more robust

Danno Ferrin - Tectonic.xyz:much different post-quantum signature algorithms, and they're having problems migrating this. So, if the protocol or the piece of software integrated cryptographic agility, it wouldn't be that much of a problem.

Danno Ferrin - Tectonic.xyz:So, to demonstrate that, I'm gonna talk about our current Ethereum transactions, which I don't consider to be cryptographically agile.

Danno Ferrin - Tectonic.xyz:So what we see here right now is what's called the signature form of a transaction. It's the… the 9 items that are used to do, in this case, a 1559 transaction. So you take your signing device, whether it's a hardware wallet or your software wallet.

Danno Ferrin - Tectonic.xyz:And you calculate 3 specific values from a very specific ECDSA algorithm, the V, the R, and the S. And the V even has different numbers that you would use in different contexts.

Danno Ferrin - Tectonic.xyz:And then you take these, and you smash them together into one transaction, with the V, the R, and the S in values. So the very format that is expected over the wire has written into it a specific algorithm, and not only that, specific links and specific contextual meanings.

Danno Ferrin - Tectonic.xyz:So if we want to do something like, use Edwards, which would have a different construction, where you need to provide a public key and a signature.

Danno Ferrin - Tectonic.xyz:we would have to go through and change the final form of this, or if it's a public… in this case, post-quantums, you also have to provide, typically, the public key and the signature. We would have to change the format of the output transaction, have it different between ECDSA and,

Danno Ferrin - Tectonic.xyz:whatever alternate signature algorithm might be out there. They could not live together at the same time, they would have to have separate parsing paths. So this next slide, represents kind of what the solution that other people have gone with, gone through. This is kind of what,

Danno Ferrin - Tectonic.xyz:Hedera does, even though they use Edwards, the same with Cosmos, and this is something Off-chain Labs had proposed during the blob, during the merge, before the blobs, before blobs-based became less problematic.

Danno Ferrin - Tectonic.xyz:And the idea here is you take the signature form, and you do make it part of the canatical form of the transaction, and you take the signatures, and you make it a separate piece of data that you could

Danno Ferrin - Tectonic.xyz:snap together like the Lego brick, or pull out, and you wrap it together in an outer container.

Danno Ferrin - Tectonic.xyz:So the advantage of a more agile format like this is if you want to change the signature to something like Falcon, the only thing you have to change is the signature component. You don't need to change any part of the transaction, and you can just unsnap that LEGO and snap that other LEGO back in.

Danno Ferrin - Tectonic.xyz:And you can just very easily change into larger key sizes, like MLDSA, it's so big it doesn't fit on the screen. And that's how big these keys are. So you take the signature, and you just replace it there, and you don't have to change any of the logic that you're doing.

Danno Ferrin - Tectonic.xyz:with your signature form, you keep that signature form. You don't have to change any of the payload structure for how you're transmitting the transaction over the network, you just change the signature data, and the meaning of the signature data, and the protocol, and in the algorithms. And if you don't understand the signature data, you can still process this transaction and move it around to a limited extent.

Danno Ferrin - Tectonic.xyz:Now, one of the things this opens up that I heard mention in earlier discussions, it kind of goes in, is we can do wacky, fun things now that we have cryptographic agility.

Danno Ferrin - Tectonic.xyz:Like, we could no longer ship around these MLDSA signatures, we could put it in some ZK blob proof, and we could instead just put a stub there that says, this represents this address, and we rely on the ZK blob to say, here's the authentication. We let someone somewhere else deal with this.

Danno Ferrin - Tectonic.xyz:the way we aggregate these signatures together. Now, the way Off-Chain Labs originally proposed this was that this ZK proof would actually be a less aggregated signature.

Danno Ferrin - Tectonic.xyz:But, of course, we can't do that because we need to be post-quantum. But it's the same concept. You can aggregate the signatures, and if you make those signatures easily severable from the transaction body, it becomes much, much more simple to do that.

Danno Ferrin - Tectonic.xyz:So I wrote these slides, before the frame transaction came up. So here's the…

Antonio Sanso:Right.

Danno Ferrin - Tectonic.xyz:None of them in the same color. Go ahead.

Antonio Sanso:Sorry, Daniel, this was actually my exact question, how this integrates with the frame. We'll tell now how it integrates with the frame, or…

Danno Ferrin - Tectonic.xyz:I haven't had much time to speak about it, but it doesn't… I don't think it works terribly well, as you'll see. So here's the, the current, frame transaction. You have the frames in the middle, you have the signature here, and you basically, instead of the DK, you have the EVM over there.

Danno Ferrin - Tectonic.xyz:So, I mean, we can just, you know, change the signature, put different values in, and again, the hash-based signature, same problem, doesn't fit on the screen. But you can change these signatures, but one of the things we lose about this is the easily unsnap and snappability of the handling of it. You have to put the signature deep into the transaction.

Danno Ferrin - Tectonic.xyz:So I think, you know, that the frame-based transaction, we could possibly rework some of it and look and see how we can get the snappability there.

Danno Ferrin - Tectonic.xyz:That's actually kind of a separate part from that, from the notion of the cryptographic utility that I really want to make.

Danno Ferrin - Tectonic.xyz:And that is…

Danno Ferrin - Tectonic.xyz:For cryptographic agility, that probably means we're gonna have to support multiple algorithms at the same time.

Danno Ferrin - Tectonic.xyz:We're not just gonna… it's not like the consensus layer. We can say, okay, today we're BLS, tomorrow we're Christmas signatures. It's… it's not gonna be a one… a one-shot thing. There's gonna be time where we're gonna have to support ECDSA and whatever post-quantum signatures we support.

Danno Ferrin - Tectonic.xyz:Similarly, it means that with cryptographic agility, we can add and remove these signatures at separate times. We could add MLDSA next week, we could add SNDSA and the fork after that.

Danno Ferrin - Tectonic.xyz:We can take ETDSA out in 2030, or 2035, and leave the other signatures in place. If there is a break on Lattice, we can remove all the Lattice signatures and tell everyone they have to rely on hash-based signatures.

Danno Ferrin - Tectonic.xyz:Cryptographic agility provides us the ability to respond to the changing nature of cryptography without having to completely rewrite our transaction signature protocols.

Danno Ferrin - Tectonic.xyz:In our transaction formatting things, the collateral damage that's going to happen by changing a signature that is unnecessary if we do a little bit of forward design to make sure that we can handle these signatures independently.

Danno Ferrin - Tectonic.xyz:So, in summary, it just means that CA means that we're no longer tied to a specific algorithm, and then we can swap them. And I listed here some of the examples that we're looking for in the future. These are the currently standardized ones, and these are ones that are coming up in the next round. Isogyny, symmetric, multivariate.

Danno Ferrin - Tectonic.xyz:Hash base, codebase. So there's all sorts of things out there. It's a really open space. We don't know which one of these is going to get the nod. And I put rainbow on here, because that was part of the first… it was a multivariate in the first series, and really late in the process, there was a crack on the algorithm.

Danno Ferrin - Tectonic.xyz:It was compromised with classical computers. So that just emphasizes why we need to be able to, for these new cryptography, be able to add and remove them with a minimum of effort and pain.

Danno Ferrin - Tectonic.xyz:So, that's what I have to say about cryptographic agility. However we do it, it's something that we need to keep in mind as a design principle for these signatures to make sure that we don't have to have another big, long series of breakout rooms again when whatever we pick happens to get cracked.

Antonio Sanso:Thanks a lot, Daniel. A quick question, like, is there any chance for you to integrate and talk with the frame transaction people? Because this looks really relevant to that, so…

Danno Ferrin - Tectonic.xyz:Nope.

Danno Ferrin - Tectonic.xyz:I just learned about it last Thursday, and we're currently in our East Denver, death march, so I haven't had time to poke my head out a bunch of anything.

Danno Ferrin - Tectonic.xyz:I've got a…

Antonio Sanso:Does that mean you have to do.

Danno Ferrin - Tectonic.xyz:But yes, I think I should talk with them, and I should get involved. I just… I learned about it a week ago, and I haven't had much time to integrate.

Antonio Sanso:Sure, totally, but from my perspective, I wouldn't see two different efforts separate. I will see, like, one effort, and the idea you got on this, integrating that effort, I mean, will be the way to go, in my opinion, right?

Danno Ferrin - Tectonic.xyz:Yep, and yeah, there's, there's other things.

Danno Ferrin - Tectonic.xyz:floating in the process that we need to let, finish before I can really talk too much about what we're doing, so…

Antonio Sanso:Okay, cool, cool. So, this ended up the presentation before to, like, having some discussion on… in general. I would like to say a few more words. So, this was call number one. In two weeks, we have call number two.

Antonio Sanso:And, we didn't… we had some topic that we didn't fit in today's, present, hour, and I see some people already here that, probably will be… make sense to present next week, or next week, sorry. And one thing that we missed completely is the multi… sorry, that,

Antonio Sanso:multi-signatures, and I see Jay on the call, and this is a really important topic, so we want to actually present, preserve the fact that, you have threshold… threshold scheme present, for,

Antonio Sanso:So we don't lose these capabilities, and we… again, we already said that we want to see, as well, the aggregatable signatures, but again, one hour was not enough to cover all these topics, so today we start like this.

Antonio Sanso:And, right, this was really…

Antonio Sanso:good first call, we, we touched.

Antonio Sanso:Grasp on several topics.

Antonio Sanso:If there's someone who wants to say something, on… on the question on the chat that was not answered anywhere, this will be a right moment. We'll have 10 minutes.

Antonio Sanso:I checked the chart, many questions were answered.

Antonio Sanso:But I don't know if someone… some… is anyone that asked a question that was not answered in the chat who wants to repeat here?

Fab:If, if I may address very quickly,

Fab:I've seen a lot of questions in the chat about, you know, especially apps that need to be updated and stuff like that. Our main concern at the moment is not with developers. We very much trust that, you know, as soon as the Ethereum's general direction is clear and there is a path.

Fab:developers will migrate proactively. Same goes for validators, node operators, everyone that is part of these infrastructure, you know, institutions. The real problem here is

Fab:with average Joe, you know, like, the normal kind of user that doesn't…

Fab:follow developments too closely, and that basically, you know, we cannot expect to proactively migrate. This is the main thing that we want to, solve with this ZK-based patch.

Fab:Everything else, we are total confident that, you know, the ecosystem will adapt and will follow whatever guidelines are established. They… it always did, so why should I do it this time?

Antonio Sanso:I do agree, and again, like, I just want to say something that at least is a… I kind of changed mind in the last year on this cryptographic agility. I mean, in the past, I was actually on the mind that we will have, at least, from the beginning, one single signature being deployed post-quantum for,

Antonio Sanso:For the transaction signals, but, I think, like, that…

Antonio Sanso:what will happen is that we probably, likely, we are going to try to have multiple EIPs and let people choose their own poisons, because of poison we're talking about here, compared to elliptical curve size, everything is a poison here. So, I'm happy that, for example, Renault already showed today that exact… it's already possible today to do a transaction using the lithium.

Antonio Sanso:With about $10.

Antonio Sanso:And, yeah, so let's see how it goes. Better, probably, because, I mean, if we put an EIP, the better and solidity. Dano, I see your… I see your hand.

Danno Ferrin - Tectonic.xyz:Yeah, so one of the things to consider when you're talking about multiple signatures is they all have different trade-offs, and different users might want different things. Some people are going to be absolutely obsessed with NAFC compliance, and some people are more concerned about staying away from lattices, because they think there's a break that's going to come on.

Danno Ferrin - Tectonic.xyz:Some want stuff that's gonna be able to be signed by a hardware wallet, and some are gonna be fine with a walled-off machine. These are some of the things that

Danno Ferrin - Tectonic.xyz:you know, I don't think there's any one signature that's going to satisfy literally everyone, and these are some pretty hard requirements.

Antonio Sanso:Yeah, that's why, again, I said, pick your poison, because I agree totally with you, I mean, then we'll have the user pick their own thing.

Antonio Sanso:And again, like, this is already, again, possible today. If you want to pay $10 for a postcardo transaction, you can, thanks to the work done by DKNOX, it's already possible right now. So, this is amazing, if you ask me. This is really the beauty and the power of, like, an abstraction.

Antonio Sanso:And if Nico is as well here, I want to ask him about… he mentioned to me privately that there is, as well as some EIP that is,

Antonio Sanso:That will be, will actually… you will be able to revoke your elliptical

Antonio Sanso:Private key, right, Nico? Something like this.

Antonio Sanso:Yeah, exactly.

Nico Consigny:Yeah, actually it's fun that you mention it, because I'm…

Nico Consigny:opening a PR right now to update this.

Antonio Sanso:Oh, okay, okay. You want to describe quickly?

Nico Consigny:So, what it would do, basically,

Nico Consigny:To put it simply, it would add a flag, to the… to the wallet, to the address, and this flag would indicate that the address is in a deactivate state.

Nico Consigny:So it would be an additional byte at the end.

Nico Consigny:And the way it would work is you would have a time lock, you would have a delay, basically, to revoke your cancellation. So it's… for now, we're saying 7 days, so… 7 days, so for… during this period, you can either cancel

Nico Consigny:your request to deactivate your EOA, and if you get to the full 7 days, then your, EOA, ECDSA key would be deactivated forever.

Nico Consigny:So this is, like, just the IP to deactivate the…

Nico Consigny:the EOA key, but we would also need an EIP to modify the EC Recover precompile, because unfortunately, you have,

Nico Consigny:a permit, and you have some option protocols that are using EC Recover to move funds, and in the case of a post-quantum attacker, the post-quantum attacker could actually sign a message with your ECDSA key.

Nico Consigny:So there is the CIP incoming, this is,

Nico Consigny:EIP7851, and there will be an additional EIP, to… to change the EC Recover precompile.

Antonio Sanso:Right. I think this will be really good to be seen in one of the next calls.

Antonio Sanso:We are almost at time. I think for today, we… it was a really packed call. I hope to have a more…

Antonio Sanso:a lean call next time with less packed agenda, so we can go a bit deeper.

Antonio Sanso:I will try to collect synergies that I've seen today, and connect a few of you privately, for example, ZKnox and Nethermind. I think that you guys are working on…

Antonio Sanso:similar things. I see as well, Dano, I will invite you again to collaborate with the account abstraction people on different transactions.

Antonio Sanso:And, again, we just started, I'm sure that this is gonna be a really fun ride for many of us. The more, the better.

Antonio Sanso:And, I think that's, that's… that's it for today. Unless someone else has a question.

Antonio Sanso:I will give you back 2 minutes of your life.

Antonio Sanso:All right, cool. Thanks a lot again, to all the presenters and the people that attended today's call. See you in two weeks!

Antonio Sanso:Bye-bye.

Simon - ZKNOX:But…

Danno Ferrin - Tectonic.xyz:Thanks. Don't forget to like and subscribe.

Antonio Sanso:Exactly.

Chat Logs

Parthasarathy Ramanujam:What are the key sizes and signatures sizes?

Renaud-ZKNOX:Our slides: https://github.com/ZKNoxHQ/Communications/tree/main/pqts-breakout Running the demo: https://visionary-nougat-217eaa.netlify.app/

Mike:You are aiming for LVL1 security guarantees for Lattices. How confident are you with LVL one (128 classical), I heard comments that it is likely that the parameters will need adjustments in the future. Should not we have a security gap to account for attack improvements?

Sergey Shemyakov | L2BEAT:How did you determine the precompile gas cost? And how does native implementations of Dilithium and Falcon compares with native ECDSA in terms of performance?

frangio:does the on chain cost for precompiles include the calldata cost of signatures?

Renaud-ZKNOX:A Pimlico key ot paste if you don't have one: pim_Y8VztkEto45P6yzNiEt5Tx Our very secret key if you are lazy: 0x0000000000000000000000000000000000000000000000000000000000000001 to paste both in prequantum and postquantum private keys (seed) (no need to connext extension once you have an ac ount).

Parthasarathy Ramanujam:Is there a need to change the hashing algorithm (from keccak to poseidon2?) when we choose either of these signature schemes?

Renaud-ZKNOX:precompile gas cost is a rule of thumb looking at CPU cycles (SUPERCOP) compared to ecdsa

Antonio Sanso:Replying to "Is there a need to c..." This is something to discuss

Benedikt Wagner:Replying to "Is there a need to c..." Assuming you are referring to the hash inside the signature scheme: If you modify it, it is a different scheme and no longer the standardized one. At the same time, you may gain some advantages wrt L1-zkEVMs or aggregation of these signatures (which we don’t do for ECDSA, but may be interesting for large PQ signatures)

Renaud-ZKNOX:falcon propose this separation of hash directly in the precompile, we did a FALZKON in Cairo, replacing keccak by a more zk friendly function (blake2s has its AIR)

Parthasarathy Ramanujam:Replying to "Is there a need to c..." Apologies, I was referring to the hashing to arrive at the account address corresponding to the new keys.

Renaud-ZKNOX:We also specified a zk friendly version of DILITHIUM over M31

Benedikt Wagner:Replying to "Is there a need to c..." Ah. That one seems mostly independent to me

Antonio Sanso:Replying to "You are aiming for L..." Dilithium has already a specification that is official

Danno Ferrin - Tectonic.xyz:Replying to "You are aiming for L..." Shoudn’t we wait for FN-DSA instead of integrating Falcon? It will be Keccak/Sha3 all over again.

Simon - ZKNOX:We also instantiated a ZK version of Dilithium for BabyBear, KoalaBear.

Mike:Replying to "You are aiming for L..." https://blog.cloudflare.com/pq-2025/#ml-kem-768-and-x25519 Discusses how they choose to use a higher level security (level 3) but aim is just to get 128 bits classical

Renaud-ZKNOX:What will happen to the current 4337 ecosystem (bundlers, etc), still working the same ?

Parthasarathy Ramanujam:Two questions: First, 8141, is still compatible with 7701, isn’t it? And second, Can you pls elaborate on the migration paths that is being considered? We have EOA, delegated EOA, 4337 smart accounts and several non 4337 smart accounts.

David Nugent:Is there supposed to be slides? We can’t see them

Antonio Sanso:Replying to "Is there supposed to..." No slide for this specific contribution

Renaud-ZKNOX:aggregation for CL ? or EL ?

Antonio Sanso:Replying to "aggregation for CL ?..." EL

Benedikt Wagner:Replying to "aggregation for CL ?..." I think this was referring to EL

Renaud-ZKNOX:A réagi à "I think this was r..." avec 👍

Danno Ferrin - Tectonic.xyz:Replying to "How did you determin..." falcon is much faster for verificaiton, dilitium a little faster for verification Signing times are where the performance issues are

Danno Ferrin - Tectonic.xyz:Replying to "How did you determin..." Sig/key size are the biggger impact

Simon - ZKNOX:Replying to "does the on chain ..." No

Danno Ferrin - Tectonic.xyz:Replying to "does the on chain co..." It can. There is the cost of memory expansion and the CALLDATA carrier cost that would be part of it too.

Jay || Silence Laboratories:Is there link to these slides as well?

Fab:Replying to "Is there link to the..." We'll provide it as soon as the presentation is over

Renaud-ZKNOX:Would you use the proof of seed for migration, or as a signature scheme itself (use a PQ proving scheme and some nonce and binding with the message) ?

Fab:Replying to "Would you use the pr..." The latter

Fab:Replying to "Would you use the pr..." Migration requires user input and we believe many users will be laggards when it comes to this sort of stuff, unfortunately...

Renaud-ZKNOX:Répondre à "Would you use the ..." Totally agree, consensus solving is hard in term of conception easy in term of migration. execution layer is the opposite. We have a working solution today, but convincing users and protocols will take years.

Fab:Replying to "Would you use the pr..." Indeed!

Benedikt Wagner:For the proof of seed and the variants you mentioned right now, does the verifier need to know which variant is used, i.e., which part in the chain was exposed and which was not?

Renaud-ZKNOX:Répondre à "Would you use the ..." We need this red button as a parachute. We don't want to use it, but you of course prefer to be seated with a proper one just in case.

Fab:Replying to "For the proof of see..." We need to settle on a specific circuit, so I'd say yes

Fab:Replying to "Would you use the pr..." This is 100% our point. We're developing this stuff with the hope of never having to use it. Basically having wasted our time will be the best outcome lol

Benedikt Wagner:Replying to "For the proof of see..." Ok, but it could be that different users exposed different intermediate keys, right? How do you know which one to pick?

Renaud-ZKNOX:If user use a proper BIP39 derivation, which is the case of most wallets and hardware, they are covered

Fab:Replying to "For the proof of see..." This is a very important topic and I'd defer it to discussion time afterwards

Renaud-ZKNOX:That is also having this in mind we specified proper derivation path for the PQ keys. We are compatible with this solution.

Renaud-ZKNOX:Would gladly sync here

Ooia oo - OKX:Institutions typically don't use seed phrases for wallets storing the bulk of their funds though

Fab:Replying to "Institutions typical..." I hear you but institutions are also much more proactive, and will likely migrate as soon as they can

Renaud-ZKNOX:Having partial solution is better than no solution. Sorry for them if they chose to deviate from standards

Danno Ferrin - Tectonic.xyz:My slides on Cryptographic Agility: https://docs.google.com/presentation/d/1bP-4kwKojabAnv_FSmfbzIl0pQs_PP8YLBgjrwLKzw0/edit?usp=sharing

Renaud-ZKNOX:And institutions will be easier to convince than single users.

Renaud-ZKNOX:Because they will have experts to warn them internally.

Stefa:Replying to "That is also having ..." Yeah, I was very excited to see this mentioned on your slides! Let's set a meeting up to get things going.

Mahdi Sedaghat | Soundness:Proof of seed works much better with EdDSA over RFC 8032. You can check the details here: https://fc26.ifca.ai/preproceedings/190.pdf

Renaud-ZKNOX:Actually, if you use hardened path, the proof of seed described works fine

Renaud-ZKNOX:Eddsa is better for non hardened.

Parthasarathy Ramanujam:Does proof of seed work with a compromised 7702 delegated account as well? Most of them have a sweeper in place atm.

Renaud-ZKNOX:here is a description of how the proof of seed applies: https://github.com/ZKNoxHQ/PQBIP39

Renaud-ZKNOX:(quantum safe eoa migration part)

Mahdi Sedaghat | Soundness:Replying to "Actually, if you use..." Actually, if you use hardened path, the proof of seed described works fine True but I am not sure if this has been the regime for a good range of accounts specially for the custodians and HSM-managed accounts.

Renaud-ZKNOX:Our derived path and how it is managed in most wallet is compatible with the circuit

Renaud-ZKNOX:Répondre à "Does proof of seed..." we need seed deactivation quick

Renaud-ZKNOX:Répondre à "Does proof of seed..." i mean, eao deactivation

Renaud-ZKNOX:Répondre à "Does proof of seed..." https://ethereum-magicians.org/t/eip-7851-deactivate-reactivate-a-delegated-eoas-key/22344

Stefa:It's a really broad technique, it works with pretty much every key-derivation step which involves at least one cryptographic hashing step between master seed and master key. BIP-32 and ECDSA are an interesting special case, but they are very much a special case.

Renaud-ZKNOX:A réagi à "It's a really broa..." avec 👍

Parthasarathy Ramanujam:But wouldn’t apps need to change their signature schemes to support this as well?

Renaud-ZKNOX:no

Renaud-ZKNOX:we prove it with the Aave integration, no change in the contract

Renaud-ZKNOX:this is aave sepolia contract we interact with

Fab:The beauty of AA!

Parthasarathy Ramanujam:Aren’t there several apps that still rely on ecrecover. It took us a lot of work to convince them to support EIP1271

Fab:If you mean "a smart contract with some on-chain custom cryptographic logic" tho, then you are right. But that's a compeltely different can of worms and I don't think we can do much about it anyway

Stefa:No change necessary on user wallets other than installing the proof of seed app, that was a fixed point in our development process.

Renaud-ZKNOX:yes, some Dapp still use msg.sender and need to be updated

Stefa:As for apps, they would need AA support or delegation features, yes. Some of them don't, and those would need change.

Nico Consigny:I will open a group Danno

Renaud-ZKNOX:actually some needs to update, like safe

Renaud-ZKNOX:https://pqbeat.xyz/protocols/

Fab:Indeed. But again, I wouldn't stress too much over this. The only apps becoming insecure in this case are the apps that are dead (team walked away). Actively maintained apps will probably migrate in time anyway.

Fab:Again, it's not the devs that worry me...

Renaud-ZKNOX:Yeah, agreed, convincing users will be easier than big Dapps

Renaud-ZKNOX:i meant harder

Fab:I was like "wait wat?" lol

Parthasarathy Ramanujam:Convincing users to migrate is the most difficult. Both 4337 and 7702 have shown that

Stefa:They don't need to do anything. I forgot to mention in the call: the 4337 accounts can be safely opened FOR the users by sponsors, and they deterministically derive from the EOA address.

Danno Ferrin - Tectonic.xyz:We do need to worry about developers, wallets, and HW wallets, before we settle on a set of sigs. Their input is a concern we need to think about once we have a general path.

Renaud-ZKNOX:Actually native AA, or disabling eoa in 7702 is required to have a clean deployment without front running

Parthasarathy Ramanujam:Replying to "They don't need to d..." I cofounded an AA company that provides AA infra on several chains. We provide it for Ethereum Foundation as well. But our biggest challenge in the past 3 years is convincing users to migrate to an AA account. That is the reason for my question.

Renaud-ZKNOX:bye thx antonio

Summary

22 highlights · 2 action itemsExperimental

post quantum context

Four Ethereum components rely on elliptic curves: execution, consensus, DAS, state00:09:07
NIST standardization took 2016-2022; implementation still ongoing since 201700:12:08
NIST winners: ML-DSA, Falcon (lattice-based), Sphincs+ (hash-based) for signatures00:13:18
Quantum computing acceleration in 2024 from Google, Microsoft requires action now00:14:30

precompile proposals

EIP-8051: ML-DSA precompile, NIST-compliant and Keccak variant, 8M gas target00:17:04
EIP-8052: Falcon precompile, 1.6M gas using Keccak, smaller signatures than ML-DSA00:24:07
ML-DSA standardized (FIPS 204); Falcon standardization still in progress00:20:42
ML-DSA easier to implement, works on hardware wallets; Falcon RAM-intensive00:22:50

account abstraction integration

Demo: ML-DSA transactions working today via 4337 at ~$2 cost on L100:26:53
4337 deployment vulnerable to front-running; native AA needed for full security00:28:54
EIP-8141: Frame transactions enable native AA with flexible signature validation00:31:41
Frame transactions: verification frame (no gas), execution frame (gas charged)00:36:19

proof of seed emergency mitigation

Proof of seed: graceful emergency fallback requiring no prior user action00:39:04
ZK proof lifts ECDSA to quantum-resistant by proving knowledge of seed00:42:28
BIP-32/BIP-39: Multiple lifting opportunities from child key to master seed00:44:37
MPC-in-the-Head proofs fit secure element memory constraints (2KB footprint)00:45:52

cryptographic agility

Crypto agility: add/remove algorithms without major protocol changes00:49:22
Current transactions not crypto-agile: V,R,S values encode specific ECDSA algorithm00:51:03
Agile design: separate signature from transaction payload, easily swap algorithms00:52:20
Support multiple PQ schemes simultaneously; add/remove independently over time00:56:19

organizational

Breakout room scope: execution layer only (transactions); other layers separate efforts00:15:03
Next call in 2 weeks: multi-signatures, aggregatable signatures, additional topics01:04:21

Decisions

Support multiple PQ signature schemes simultaneously; users choose based on requirements01:00:58
Account abstraction is the foundational layer for all PQ transaction work00:46:26

Action Items

Danno, Nico, frame transaction team: Integrate cryptographic agility principles with EIP-8141 frame transaction design00:57:10
Renaud, Stefano, Fabrizio: Collaborate on BIP-39 proof of seed implementation between ZKnox and NeverLocal teams00:49:22

Targets

EthCC - Full proof of seed demonstrator with concrete implementation00:47:18
February 18, 2026 - Next PQTS breakout call covering multi-sig and aggregation01:04:21