Post-Quantum Transaction Signature Breakout Kickoff

Transcript

Gaudenzio Nethermind: Go then!

Antonio Sanso: Hello, hello. I guarantee you. 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… Cause I have something to present, and… We'll check, please. Okay, let's see… screens, documents, advanced, documents, no. So let's try it. This clip. Okay. Metalized crypto. Okay. So what do you see nowadays?

Gaudenzio Nethermind: Agenda.

Antonio Sanso: See my… okay, but we'll… you will see, like, the slides… move. 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. Thanks a lot for double checking, it just… That, yes, okay. 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.

Hello, everyone. It's, 15… 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. And.

Stefa: Hello, everybody.

Antonio Sanso: Hey, hey.

Matteo Vicari: Hi.

Antonio Sanso: smooth. Hey, hi, Mattel. The agenda is, That's okay. The agenda is on the… on the GitHub issue. 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. And, but yeah, we quickly set the stage, and then we'll have some more, Technical, a more in-depth presentation, and again, everything's in the agenda. We'll start in a couple of minutes, and yeah. Let's see… 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.

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

Renaud Dubois: Hi, everyone.

Antonio Sanso: Hey, I see already some of the presenters joining. I see Renault, I see Stefano, I see Simon. So, will be some people presenting after me, so, looking forward. And one more minute, and we start. Just double checking, are you guys seeing my… my… slide? Like, okay, cool. Let's start. 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. And, yeah. Things might sound, like, already known, but, better like this.

them. Now, let me probably, again, share… Alright, let's do it. So… February the 4th, and let me try at least to get rid of the Presenter, I'll put another… Screen, okay. So, breakout room, kickoff call, and, yeah. 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 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. That before had the name of Burkeleton trees is not anymore the case. 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.

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. In particular, for ACDSA, we have this SECP156K1, 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 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. 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.

if some quantum emergency happens, we'll see a presentation from Stefano actually going deeper in that, on this proof of sets later on. 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… 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. 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.

There's a lattice-based cryptography, there's code-based cryptography, multivariate, and a supersingle elliptical resogenic cryptography. And, yeah, we have some algorithm here. We need to choose, Some that is actually good for us. 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. But then, 2018-19, there was the first round of evaluation, where some algorithms were cut. 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.

Two lattice, one hash-based, so the lithium… Falcon Lattice-based, Sphinx hash-based, and for King Capsillation kyber. Well… We are… at the moment, we… for these calls, we are only discussing about signatures, so these are… Probably some that we're gonna see, because they're standard, so we're not reinventing the wheel. And, want to highlight as well that, at the EF, at least we have started to think about post-quantum since long. 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… a single secret leader election and so on, that went… the cryptograph team has been working on this.

Papers or calls. During the years. 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… 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 Yeah, this is probably, you guys seen as well, this, this, tweet by, by Justin, that, actually, shows that the Twin Foundation, long-term strategy for, for quantum. So, These are, again, the four components, execution, consensus, data availability, and status.

This breakout room is only about execution, so if you're interested about other things, it will be other efforts. On these calls, we mainly focus on post-quantum transaction signatures, so execution layer. 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. 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. 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.

And that's basically… From my side. So, I will happily give the word to Reynold Simon. You tell me… Who of the two? So is your name, I'll make you presenter, so…

Renaud Dubois: Yeah, I will.

Antonio Sanso: here.

Renaud Dubois: 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 Dubois: 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. So at Zkinox, we've been working on Post Contem, Cryptography for blockchain, for the past, for the past 2 years. closed with, with Antonio and, and the EF. implementing, emulation of the two EIPs that, Simon, will introduce. So basically, we, we've wrote, EIP8051, which is MLDSA, it's standardized by NIST, and EIP8052. It's FNDSA, it's Falcon precompiled. 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. Which can be tuned using K1, R1, MLDSA, or FMDSA. It's,

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. And we also, we also specified how to derive, derive key with, PQ, PQ39, so… This is a full stack, 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. 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.

And even for L1, for high-value assets, it's possible, so… Even without, without pre-compile. So why do we need precompiles? We need precompiled because, 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… Simon will detail, the… The gas cost and the complexity of the precompiles. Simon? 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 Dubois: 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. The two first are based on lattice, and the third one is based on hash function. 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. And so here you can see, the answer of the equation, the different, 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.

Smaller signature, smaller public key. Also, in terms of gas costs, so we did the implementation of the verifier in SolidZ. So that, you can… 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… Using ECDSA. If we would have a precompile, we… it would reduce drastically the cost, because we would get something more or less similar to ECDSA for Falcon, and slightly higher for MLDSA, for the lithium. So this is in terms of comparison of size and efficiency, but then there are other aspects that are also important. For example.

Delithium has been standardized by the NIST with FIPS 204. And for Falcon, it's still in the process, and it takes a lot of time, so we don't have a standard yet. 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… 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. Glyithium has been integrated into different, industrial projects. It has been… done in Paskey, also in Apple. It's in the process, but it's, seems to be more… there are more products integrating DLTM than Falcon. And finally, in terms of zero-knowledge proof, it seems to be easier to…

modify delithium to get something ZK-friendly than for Falcon, where the field of definition is very important for the parameterization of the scheme. So this is for… just for comparing Falcon and Delicium. And now if I need to go into detail on the EIPs. So, the first TIP for Delithium, which is MLDSA, actually, is AT51, 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. And we decided to propose also a second precompile using… which is exactly the same, but replacing this, shake, but by another hash function. 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.

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. So you'll hear about this later with Renault, that will show you how it works. 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 we propose two precompiles, one for the polynomial challenge that is necessary for Falcon, and one for the core algorithm of the verification. So… In Falcon, you have really a separation between the hash and the core verification, which enables you to… to… to instantiate Falcon using another hash function without changing the core verification.

So, using these two schemes. you can get till 1.6 million GAS if you use a catch-a-cash function in the verification. And, we also provided some… some test vectors, generated using the NIST reference implementation. 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. Yeah, that's it, for me. I think, Renault, you can continue.

Renaud Dubois: 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. So, I stack 0.1 Aave here, the user op ran well, it's here, so let's… Let's have a look on EterScan, but if you scan this, we shall be able to see at this user up. Of course… Okay, I'm not on Sepoliard. Simple later scan. 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. 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.

And, yeah, so here is… here is the transaction. So, basically, this is, this is the… the staking, the rest is, the cost, for… for… for the bundler, so… So yeah, you… you have everything to… to run. 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. But, Nico actually probably is gonna show the long-term plan for, like, an abstraction, and part of it was already presented last week. at the ACDE. So…

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

Antonio Sanso: Right.

Renaud Dubois: 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. Pissing off, but not, phones are not at risk, but to be totally clean, and totally…

Antonio Sanso: Right.

Renaud Dubois: We need this native, 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. 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 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.

Nicolas Consigny: I think…

Antonio Sanso: I should've…

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

Antonio Sanso: Okay, perfect.

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

Renaud Dubois: I stopped sharing, I stopped sharing.

Antonio Sanso: Okay. Great.

Nicolas Consigny: it's…

Renaud Dubois: Okay, the mic to Nico now.

Nicolas Consigny: Alright, so yeah, thanks for… thanks for having me, So I work at the time of foundation. I've been doing a lot of account abstraction stuff over the last few years. It's kind of a full circle moment for me, because I started my career 10 years ago in a crypto analysis company. Selling, post-quantum transition to… Banks and, and, different, high, security companies, so it's glad to see that this transition is coming to Ethereum. So… 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. 4237 is, a near sea, so it's, A standard that is not in protocol.

So it is a great standard, but it comes with a lot of drawback, because it's not natively in the protocol. 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… 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. So these are the reasons, motivating, native account abstraction. 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. So it's very sad that we have these very cool smart contract properties, but we don't apply them to wallets natively.

So finally, this is what native AA is trying to solve. And so very recently, we had a new, proposal, which is, 8141, And it's called the Frame Transaction Proposal. So what it is, it's simply a new transaction type, so the type is 0X6, yeah, if I'm not mistaken, yeah, 06. And it, replaces the current, ECDSA signature model with a flexible frame system where you have a validation frame, an execution frame. And, a default, frame, a verified frame. And basically, you can iterate through these, frames, and… each frame is approved or reverted. If a frame is reverted, the entire transaction is going to be It's gonna… it's gonna be reverted. 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.

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… execution, frame, then it's more problematic, because you're actually, Spending money to do it. And so what DSLOs is, 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… to match the transaction that you want to have. So this is very nice, because this is flexible, it doesn't enshrine any scheme. You could use… the Solidity verifier that ZKnox has been working on. The problem would be that the cost of this verifier is super high, so this is why we have the pre-compiled proposals.

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… 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 Account address, so you're directly executing your call yourself. So yeah, I invite you to dig the proposal if you're interested, but to focus on the… 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… Or to…

Nicolas 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…

Nicolas Consigny: That's a good question. You mean the URC itself will, yeah, continue to exist? it will continue to exist and to work. Obviously, you would have a easier time just switching to the full native AA, but the existing 4337 infra and wallet would continue working. Obviously, there would be some… native migration path, I assume? Like most of the 4337, wallets, I assume, would, 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.

Nicolas Consigny: Yep.

Antonio Sanso: Right.

Nicolas 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. 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. We'll need to be, counter abstraction aware, somehow.

Nicolas 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. That would come right after. 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.

Nicolas 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, aggregation of Wisconsin signatures is a tough, problem, unfortunately, because we don't have, like, a BLS… style post-quantum schemes, but yeah, that's, welcome in the post-quantum world, where we have everything is, a bit uglier. 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 Like, let's go with the next presenter, Stefano.

Stefa: Excellent. So let me just share the slides. I have some slides just as a… 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… a proposal we've been working on, with, Fabrizio, some other collaborators, and now recently also Antonio, on, a slightly different approach to quantum mitigation, less patch, less a solution to the problem, so post-quantum signature adoption and implementation, and more, mitigation 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. 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

major manufacturers. 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. 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 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. 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…

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 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. 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.

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. 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, proof-lifting, ideas, we lift the, current quantum weak schemes, so East DSA, to quantum resistance schemes. 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.

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. 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. 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.

At the time of the emergency, even though their key at that time might already be broken. 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. We focused mostly on BIP32 derivation, so hierarchical deterministic wallets. 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. 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.

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. 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.

And so it's unlikely that those intermediate steps, or do you… Original mnemonic have been exposed. 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… 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. 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.

What we can do is we can use some slightly older techniques that are not succinct, such as MPC and NAT, 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. 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.

of the statement, I know a proof. 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. 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. That has access to the master key and uses it to lift.

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. 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. Over alternative, some limited exposure of either the master seed or the pre-image to the final hashing step in the BIP39 derivation. I am aware that these are things that make 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.

We are continuing to work on this. We should have a concrete implementation with the demonstrator out soon on our repositories. 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. 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. 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, 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: Can I get the screen?

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

Danno Ferrin: Alright. 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. Let me get that on the right screen… 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. And on the bottom is a very rigorous, formal definition that NIST uses when they do their discussions about cryptographic agility. 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

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. So, to demonstrate that, I'm gonna talk about our current Ethereum transactions, which I don't consider to be cryptographically agile. 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. 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.

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. 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. 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,

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, 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. 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

snap together like the Lego brick, or pull out, and you wrap it together in an outer container. 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. 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.

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. 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. 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.

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. 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. So I wrote these slides, before the frame transaction came up. So here's the…

Antonio Sanso: Right.

Danno Ferrin: 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: 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. 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. 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.

That's actually kind of a separate part from that, from the notion of the cryptographic utility that I really want to make. And that is… For cryptographic agility, that probably means we're gonna have to support multiple algorithms at the same time. 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. 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.

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. Cryptographic agility provides us the ability to respond to the changing nature of cryptography without having to completely rewrite our transaction signature protocols. 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. 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.

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. 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. 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: Nope. 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. I've got a…

Antonio Sanso: Does that mean you have to do.

Danno Ferrin: 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: Yep, and yeah, there's, there's other things. 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. 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, 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,

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. And, right, this was really… good first call, we, we touched. Grasp on several topics. 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. I checked the chart, many questions were answered. 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, 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. 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 with average Joe, you know, like, the normal kind of user that doesn't… 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.

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, For the transaction signals, but, I think, like, that… 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.

With about $10. 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: 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. 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 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. 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. 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, That will be, will actually… you will be able to revoke your elliptical

Private key, right, Nico? Something like this. Yeah, exactly.

Nicolas Consigny: Yeah, actually it's fun that you mention it, because I'm… opening a PR right now to update this.

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

Nicolas Consigny: So, what it would do, basically, 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. So it would be an additional byte at the end. 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 your request to deactivate your EOA, and if you get to the full 7 days, then your, EOA, ECDSA key would be deactivated forever. So this is, like, just the IP to deactivate the…

the EOA key, but we would also need an EIP to modify the EC Recover precompile, because unfortunately, you have, 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. So there is the CIP incoming, this is, 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. We are almost at time. I think for today, we… it was a really packed call. I hope to have a more… a lean call next time with less packed agenda, so we can go a bit deeper. 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… similar things. I see as well, Dano, I will invite you again to collaborate with the account abstraction people on different transactions. 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.

And, I think that's, that's… that's it for today. Unless someone else has a question. I will give you back 2 minutes of your life. All right, cool. Thanks a lot again, to all the presenters and the people that attended today's call. See you in two weeks! Bye-bye.

Simon - ZKNOX: But…

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

Antonio Sanso: Exactly.

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