Post-Quantum Transaction Signature Breakout #13

Transcript

Antonio Sanso: Hey, everyone.

T. Wambsgans: Hi.

Matteo Vicari: Hi.

Antonio Sanso: As usual, I am gonna test my slides, and… Let's see if they work… Hi. Hello? I hope you see them, right? Is that just a PDF?

T. Wambsgans: Yes.

Antonio Sanso: Okay, great. So, usually we start a couple of minutes after. 3, so… let's… we have a couple of minutes to… To wait. There you go, tip. Hello.

Matteo Vena: Hey, everyone.

Antonio Sanso: Nope. As you said, we're waiting a couple of minutes for the… Late joiners. We start at 302. Just double checking the presenters here. or not… Mira, are you already joining? Pinging her, just in case she forgot. I don't think so, because, I was in touch with her a few minutes ago.

Mira Belenkiy: Here.

Antonio Sanso: Hey, Mira.

Mira Belenkiy: Hi, thank you so much.

Antonio Sanso: No worries. We are starting, in many cases, like, a couple of minutes late, so you're not late, by the way. It's just 3 o'clock, we start just a couple of minutes to accommodate late, arrival. But we are almost there. Alright, let's do it. Welcome, everyone, to the Break Post Quantum Transaction Signature Breakout Rooms number 13. Today is August 19, 2026. Quick… I have just a few slides, two slides, as usual. Here, like, are the recap of the previous calls.

Today we will see a bit of, It's a bit of a mix, but, We're probably looking at some hash-based stateless signatures at scales at Circo. Mira already told me that she will show some elliptical stuff as well. I guess she shared in the channel. And we have only one presenter today, that is Mira Belenki from Circo. I will give soon the stage to her. Just remember, everyone, if you're not, subscribed to the Telegram channel. Here's the QR code, or the link. And I'm actually really looking forward to this presentation. Mira's been in the… he's a cryptographer, being on the space for a long time, so plenty of experience. And now, as far as I understood, he's working at Circo and experimenting with post-quantum signatures. So, Mira stage is yours. You can share your screen, and looking forward to your presentation.

Mira Belenkiy: Thank you. I'm gonna just, send a share request.

Antonio Sanso: I accept it, so I expect this to work.

Mira Belenkiy: If… okay, alright. Let's see, let's the greatest… This, this… Is sharing… is this working?

Antonio Sanso: Not yet?

Mira Belenkiy: Not yet. Okay, let's see, sorry, I… we usually don't use Zoom. Let me just try this.

T. Wambsgans: It works for me.

Mira Belenkiy: Oh, it works for you, okay. All right, so hi, my name is Mira, I'm a cryptographer, at Circle Research. Though today's talk is not going to be very technical, it's more about just our use cases and how we're thinking about the post-quantum transition, specifically for the transaction signatures. And just to give an overview of who we are at Circle, we kind of have a unique position in the ecosystem in that we're kind of doing a little bit of everything. We have our own blockchain ARCO, which is going to go into mainnet in September. So, we, one of our goals is to be EVM compatible. So we're very closely following Ethereum and all the decisions that you guys are making. But at the same time, we can move a little bit faster, and if we know that you… there's gonna be… Ethereum's gonna do a decision which we could implement a little bit faster. At the same time, we are also a stablecoin issuer, that's how most people know us.

So we are on 30 different blockchains, so for us, interoperability and supporting every single blockchain is a big, criteria, and very important. And we are very much at the mercy of every single blockchain and all the decisions that they're making. Although Ethereum for us is probably the most important one, because we have $50 billion worth of USDC on Ethereum alone. Then… and finally, we are a enterprise service provider. We have a payment network, we're doing nanopayments, X402, so we have to also deal with all the issues that anyone who basically has an app on Ethereum has to deal with. And so, given all that, my… our biggest worry at Circle is not so much picking the very best post-quantum transition… transaction signature, it's…

ecosystem fragmentation, where if we are on 30 different blockchains, it's very easy to imagine how each blockchain could end up with its own signature. Between picking the actual signature scheme at the parameter set, and then choosing a hash function, it, the possibilities are endless, and we could have 30 signatures on 3 different blockchains to support. And this becomes a problem because we need dev tools, our customers need to have access to wallets, we need hardware wallets for cold storage custody, we need multisig, and… if the ecosystem fragments too much, support is going to be very uneven and limited to some of the blockchains. And even with Ethereum, we're concerned that if Ethereum chooses something unusual, we're not going to get HSM support right away.

And so then, to kind of get into what… how we, basically operate our wallets, the model is pretty simple. We have a hot wallet and we have cold… cold wallets. No surprise there. Our hot wallets sign 30,000 to 70,000 transactions per day, and we have distributed systems where multiple Our systems share the same wallet, so for us, any sort of stateful wallet becomes an issue, because now we have a distributed system share… having to coordinate state. And this is… gets into why we're also worried about the SLH-DSA parameter set, because… With 30,000 to 70,000 transactions being signed a day. some of the parameters that would require us to rotate keys once or twice a day, and at least for now, we've always treated key rotation as a very high-risk operation, which requires cold storage, K of N signatures, very, very hands-on monitoring of every single time we do rotate a key.

And so turning this into a standard daily operation completely reworks how we think about security and is not something we necessarily want to do. So ideally, for us, something more like SLH-DSA, which is stateless and would not require us to rotate keys unless we need to for our own operational reasons, would be much, much better. We're obviously also concerned about low gas fees, so SLH-DSA with 200K gas fee is not ideal. I saw that there was actually a proposal to also support MLDSA, and I can't tell you how it will land if we have to choose between the two. Oh, one consideration we have is that even though we do have these tens of thousands of transactions being signed a day, we do have the option of batching some of them, and that gives us a way to amortize some of the costs of a big part of our…

Transactions are the 3,009 gasless transactions, so you could easily just create a giant batch and have only one signature over the entire batch. So that is actually how we are more likely to try to save on gas versus doing some of the other 4s plus z parameter sets. All right, so, you were warned, I'm going to be talking a little bit about elliptic curves, and this kind of goes into the transition. So, one of the big worries we have, which I'm seeing… not seeing being addressed as much, is that there's a lot of deployed smart contracts out there which use EC Recover, and we need a do something about them, because WahCircle, for example, we made sure that all our smart contracts are upgradable, and we could just upgrade that functionality away. For a lot of other contracts, they don't have that option, and so…

we would ideally like to see blockchains like Ethereum, do some… something to secure those and let them transition without having to change their code. I saw proposals to disable EC Recover, something that Circle is considering for ARK. is actually a hotfix, which will basically turn ECU recover into a post-quantum signature. So… EC Recover takes, 65 bytes ECDSA signature, and one thing we've looked at is to reinterpret how we think about it. So right now, V, is… is… a UINT8, that gives… which in practice is only 0, 1, 27, and 28 are actually used, in terms of values, which gives us a possibility to use V as a version number, which tells us how to interpret EC Recover.

And… that, lets us change how we literally treat it. And so then that gives us the remaining bytes, the 64 bytes, for the R and the S to interpret it as pointers. a pointer to find the actual public key, and a pointer to find the signature in a lookup table. And as a result, we maintain the ABI, but we maintain the, the contracts, while let them start accepting post-quantum signatures, potentially looking at either a lookup table and some dedicated, smart contract, or even inside a frame transaction. So, I'm sorry, this is kind of a short presentation, this is… but this is what I wanted to share. I'm happy to answer any questions about either how we're thinking about post-quantum signatures in general, or ECU recover.

Antonio Sanso: Right, I have actually a lot of questions, if you don't mind. All this use case you presented here, especially in the previous slides, right? This one, are for the stablecoin, or are for, like… you said that you have, like, at least 3 products, right? Is this…

Mira Belenkiy: So…

Antonio Sanso: Mainly this for the USDC, or is it for other… things.

Mira Belenkiy: So… we, I don't believe we mint 30,000 times per day. I believe this is mostly for our payment products. But we're doing payments using our stablecoins for the most part.

Antonio Sanso: Do you know the name of this payment product, or…

Mira Belenkiy: I don't have it off the top of my head. I know we have Circle Payment Network is our big product. And then we also have Circle Mint, but once again, I don't think Circle Mint is responsible for most of this.

Antonio Sanso: All right. I see a question in the chat from Gotti. So, regarding the 5 times 6, 30 potential signature variations. Is there a way to modularize this into 5 plus 6 variation? And they say it's still a lot, but, yeah.

Mira Belenkiy: Yeah, I mean, this is not something that we want to happen, but, I… basically, I just did a mental exercise. I said, okay, what are the most popular… signatures for post-quantum, and you have SLHDSA, MLDSA, Falcon, if it ever comes to be. Honestly, for MLDSA, you have… I see 44 and 65 being proposed. I saw faced. Ethereum is looking at force plus C for different parameter sets, so… Easily, you could get 5 popular…

Antonio Sanso: No, no, I understand the concern. A question is, like, are you already… did you already start to play with SLH-DSA, or with SLHDSA, or just at the moment is, like, in the wish list, and you're still, like, at the design phase?

Mira Belenkiy: We are definitely in design phase. We have, we've released an ARC SLH DSA using SHA-2. As a precompile, just to make it available in testnet, and it's going to be in mainnet. We… since for us, interoperability, especially interoperability with Ethereum, is a very high priority, we don't want to make any decisions, and like I said, for us. Performance is not nearly as important as interoperability.

Antonio Sanso: Right. And ARC is the… is the first product, like, the… your… your net?

Mira Belenkiy: That's our first blockchain, yes.

Antonio Sanso: But is it an L2, or it's, like, an L1?

Mira Belenkiy: It's an L1.

Antonio Sanso: And is it internal? And, I mean, this problem I ignore. Is it an internal blockchain, or something used… Oh, so good.

Mira Belenkiy: So we have a public testnet right now that anyone could play with. It's gonna go… main net is gonna go live in mid-September.

Antonio Sanso: Hmm. And it's, like, it's, like, competitors to Tempo, for example, or why… why Circle wants to have this arc?

Mira Belenkiy: So, that's a very good question. What I'm hearing from the business team is we want to control our own destiny, which is as… which is obviously a little bit vague. But I think, realistically, it's a competitor to Tempo and Stripe.

Antonio Sanso: Okay, makes sense, makes sense. And do you, do you… sorry for all this question, but actually, you know, having someone like you that, has some kind of unfield experience is really good. For Arc, you have, for example, hardware support? Like, let's say, like, Ledger, or… because at the moment, like, the main concern Is to find the right balance between Signing time and verification time, and the pain part at the moment is really, like, let's say, hardware wallets, because it's really slow, unless you are… Adopting a kind of… fancy… architecture of SLH-DSA, let's say. Let's say the normal SLH-DSA is pretty slow.

Mira Belenkiy: Right, we're less concerned about signing than we are about, ease of use. So, hardware wallets are primarily for us for cold storage. I actually… I don't think we used hardware wallets for our hot… for our hot wallets.

Antonio Sanso: I mean, being ARC.

Mira Belenkiy: Right, so… So, with ARC, we're… we… ARC itself is not signing. Right now, so, okay, within ARC itself for Consensus, for example, we use BLS. We are not planning to transition BLS until very, very close to the deadline, simply because we don't quite have to know what's the best solution, and we don't see this as a priority.

Antonio Sanso: No, no, I mean, I agree with that. I mean, as you probably see here as well, this is, like, the execution Transaction Signature call, so we are really not concerned too much about consensus in this call.

Mira Belenkiy: Right, right, right.

Antonio Sanso: I was really, like, the transaction of Arc, literally, like, if you are experimenting with Ledger.

Mira Belenkiy: So we are right now not experimenting at all with performance of post-quantum signatures. Because as I said, for us, that is literally the lowest concern. We really want to care about more interoperability than we do about performance.

Antonio Sanso: All right. Let's see, I have some questions in the chat. Okay, yeah, I mean, T… I don't know the name, T. Wam… Wamgans says that… okay, yeah, he's emphasizing the fact that, at least for Ethereum, the… for Consensus, we are using XMSS. It's still, like, of course, hash-based, but it's stateful. So, and for Consensus, actually, it's not a problem being stateful, because… Yeah, I mean, you cannot, in any case, sign the same slot twice, so…

Mira Belenkiy: For Consensus, we agree that we're not as worried about stateful versus un-stateful. It's the hot wallets, which are, you know, 70,000 transactions a day. We don't want to deal with state there.

Antonio Sanso: Okay. And, I see a question for Mahdi. Can you share more details on your batching technique? Is this batching done during the authentication phase? If so, how does it impact transaction latency? Any concrete numbers?

Mira Belenkiy: So I don't have any concrete numbers for you. So the way batching works is, we use, 3009 transfer with authorization transactions, and so… Basically, you just… Have multiple of those in one transaction.

Antonio Sanso: Alright, alright. And actually, I have a question of… if you go to the last slide on this recover. Actually, this sounds a neat idea. I must admit that I didn't think about it before. Is still a proposed hotfix, again, in the design phase, or you actually try to implement having this lookup table somewhere?

Mira Belenkiy: So this is a very design phase. We have, basically a foundry prototype where you deploy a model, contract, which will kind of be the registration contract of all the public keys and their actual addresses. We designed this before frame Transactions came out. I… actually, one of my plans is to go back and see how do we… how would we work this with frame transactions?

Antonio Sanso: How it will work exactly? Like, I understood that there's the version, so you can, like I said, I mean, they pick you, and then, like…

Mira Belenkiy: Okay, absolutely. So, the way it would work is, as I said, the first design that we came up with is you have basically a dedicated smart contract, which is a registry of… The, public keys and the, the Ethereum addresses associated with those public keys, and… So what you would do is… You would first register, that, you know, bef- before the… the Quantum, transition, that this address now has this public key, and then, before you could do with ECDSA in the beginning, later you could register with Post Quantum, but eventually you have a smart contract which stores all, address public keys matches. So then the R value is literally just, we have 32 bytes, but you could interpret it as just 20, basically as a lookup into this dedicated smart contract to say where… what is the pub… what is the public key.

And so you, for the signature verification, and then once, EC Recover is supposed to return the actual address, that same lookup table will tell you what's the address. So that's step one. Step two is the signature. Now, before frame transactions came along, the only two options which kind of came to mind of how to make the signature work is to either, once again, you have to pre-register your signature inside the table, so you… First, upload your signature, and then it has to be looked up during EC Recover. Now that we have framed transactions, they could actually be part of the transaction that is looked up inside the transaction.

Antonio Sanso: Makes sense. Actually, it's a neat idea. I actually invite you guys to create a more formal document with that. Like an EIP, potentially. It's really nice.

Mira Belenkiy: Huh, thank you.

Antonio Sanso: I must admit it, it's really nice idea.

Mira Belenkiy: Thanks, Anno. One of my to-do lists is to make an EIP with this and make it work with frame transactions.

Antonio Sanso: Right. I still am not super convinced about the public key part, and I'll tell you why, but maybe it can be worked as well with frame Transaction, because, for example, what happens If you're… I mean, this requires sort of, this big contract where the public here is… is present, like, there are corner… I can already see some corner cases where the public is not existing, I don't know. But, I mean, the idea to have this… let's say, keep the same ABI, but reuse it for post-quantum without changing the… the interface is really neat, I have to admit it. So, looking forward.

Mira Belenkiy: Absolutely.

Antonio Sanso: There's a question here on the chat to say, we are using 8373 that we created for PQ anchored key binding. If that helps, we got it running. Okay, so someone already is using 8373.

Mira Belenkiy: Okay, I would love to get in touch, I will put my email into the chat, let me do that. Aye, just reach out to me.

Antonio Sanso: Got it, yeah, yeah, actually, yeah, this, this is, this is, this is true, and, like, now that I think loud, I think… I see Matteo as well, bickering into the call, and I think, like, in any case, with many account abstraction solutions, you kind of have your You kind of have your, public key. into the contract, but it's always, like, you know, it's not a single big contract, like, any smart contract will ship their public key, so I struggle to visualize this.

Mira Belenkiy: So, one option is, like, right now, in this… if you look at the slide I'm showing you, we have R and S, which are basically bytes 32, both of them, so we have 64 bytes to play with. Instead of interpreting it as two ad… Two indexes, you could actually Split it up into 20, 20, and 20. So 120 basically tells you the address of where to look, what contract to look in, or where frame transaction to look into. The next, 20 tells you, okay, an index into a table of Get that public key, and the next one is the index of get the signature.

Antonio Sanso: Okay,

Mira Belenkiy: And with the V giving us, you know, 255 possible version numbers, that leaves us room for interpretation.

Antonio Sanso: Right. Well, I… yeah, yeah, I mean, I'm just probably… when I say it, like, I probably will… will… can play better in my mind, but it's… again, the idea per se is super nice. I just want to see an instantiation of it and how it works.

Mira Belenkiy: Of course.

Antonio Sanso: Alright.

Mira Belenkiy: That's a very good point, that part of it is to identify the signature scheme, though Depending how you structure the actual lookup table you look into, you could actually… have the signature scheme version in the table and not in the V.

Gottfried Herold: Yeah, true, true.

Antonio Sanso: Alright. Yeah, Cool. I don't have much more, to be fair, unless I want to ask a more question. It's been vacation time in Europe, so, has been pretty… With some pretty long, some weeks that, nothing… not much happening. I just want to, raise a little point about next Thursday is gonna be All Core DevsE. And, at the previous… so, last Thursday, someone… was, proposing some EIP, precompile for Lattice. Now, of course, like. during these calls, we kind of… it seems like, kind of, we move it away from… from Lattice and going towards hash-based signatures. This doesn't mean anything, because the Ethereum governance is… is driven by All Core DevsE. So I will have a, hopefully, a presentation next Thursday at All Core Devs, if they give me the space, and I will just do a quick recap.

of 13 instances of post-quantum transaction signatures, and at least bringing the point that we kind of move it away from Lattice and from precompile. if anyone feels like joining the calls, it's next Thursday, and it's, again, it's a big All Core DevsE, so it's not only about post-quantum, and it's about what to include in Hegota. And again, last week someone, put forward, some lab tests precompile for Seda, and, No, no, no, no, it's gonna be real next week, not tomorrow. Next week. So, in a day's… I was just answering Lattice Lover in the chat. So, Lattice Lover, you're probably being for pro, having this, this, precompile in Ethereum. Again, personally, I… I'm More towards, hash-based signature at the moment, so… and again, precompiles, historically, crypto precompiles, crypto precompiles didn't play well with Ethereum. We didn't have a… we didn't have a great success with Blake or with BLS. We did a lot of work, and this has been… never been, really used too much.

So, he's gonna… it creates a lot of legacy and dead code, somehow, that we need to maintain. And even if we think about zkVM in the future. having this precompiled, I don't know how we'll play. Again, I'll just… Report back of, these 13 calls, and the fact that we actually… seems that we moved away from Lattice, but we don't have any power. It's All Core Devs at the end, AllCoreDev deciding what to include in Hegota and whatnot. Again, if you want to join next Thursday. it's good. I think it's gonna be an escort. Otherwise, we're gonna see in 2 weeks. Is anyone wants to bring any other topic for today? Otherwise, I just wrapped the call itself an hour before.

Okay. Yeah, yeah, I knew Lattice lover, so of course you support Lattice. Good. Anyway, thanks again, Mira, for the really… for your time, for the nice presentation. I've seen at least two or three ideas in this, presentation that I liked a lot. I cannot guarantee I'm not gonna steal some of those. And… joking. And thanks again, Mira.

Mira Belenkiy: Honestly, feel free to steal, and actually, if anyone wants to work on any of these, reach out. At Circle Research, we are actually more about collaborating versus, you know, building our own little fenced garden of this is our work.

Antonio Sanso: This is beautiful. A quick question. Are you gonna be at, in, any of you is gonna be in India, at the DEF CON? Anyone from Circle?

Mira Belenkiy: I don't know. I'm gonna be at the Boston Blockchain Week coming up in September. I don't know about DEF CON in India.

Antonio Sanso: Okay, perfect. Thanks a lot, everyone, and I'll see you in two weeks, or next week at ICD. Take care.

T. Wambsgans: Bye.

Antonio Sanso: Bye.

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