Post-Quantum Transaction Signature Breakout #3

Transcript

Antonio Sanso: Hello?

Guys, can I ask you if you can see my slide?

yhl125: Yes, I can build a slide.

Antonio Sanso: You say it's, like, one slide, like, in presenter mode, or, like, Or is it more than one?

yhl125: It is present remote.

Antonio Sanso: So, I mean, you see one slide, or two, or two slides?

yhl125: One slide.

Antonio Sanso: Okay, so one big win, right?

yhl125: Yeah.

Antonio Sanso: Okay, thanks for checking, Issa.

Fab: Hello, everyone.

Antonio Sanso: Hello, we just wait. It's a bit early, wait a few more minutes. Hi, everyone so far. It's just, 4 o'clock now, as is custom. I'll wait 2 more minutes. To accommodate someone just a few minutes late.

And then it will start.

Right? Hi, everyone. Welcome to the third call. The post-quantum transaction signatures. I… Hope you'll see my slides, and… Let's start. If I manage to. Move this from my screen. Right. Do you see my slides, right? I think, like, yes. So, this third call, we had two calls so far. The first one was on, about lattice solution. The second one was about hash-based solution. Today, we have a special

topic, but it's an NTT and non-per-compile. We'll have a kind of abstraction in the next call, and hopefully hardware support. And two goals. So, probably some of you seen this already. There's been this tweet by Justin Drake. Presenting this, long-term straw map org. the dislike, shows a bit of, idea for a potential Ethereum futures. Of course, this call, we're not gonna focus On all these boxes. And we probably are more interested about this… part. Specifically, like, native account abstraction that we don't focus, but we leverage it. And the really part… the meaty part for us is really… This NTT precompile. Or more than one. So, there was as well a tweet from Vitalik that, talks about a concept of non-peer compiled, and it's, like, more operation, not just NTT.

So, I'd really like to, kind of try to launched this meme of Daisugi, and in my mind, we will have the NTT precompiles being there, down, and hopefully people will build on top of it. different signature schemes that are post-quantum or stark, because both starts and latte solutions, they have in common the fact that they heavily used polynomial rings, so operation on planet fields needs to be really efficient. The agenda for today is pretty lean, on purpose, because the first two calls, we set the stage, and so we had a lot of presentations. In the future, I will expect to have Some presentation, but mostly open discussions. And, the presentation of today is, I think, already in Advanced Renault, or Simon, I think Renault is a good percent.

That will show, this NTT precompile that, ZKnox So, Simon and Renaud are ready. I presented, tried to launch last year, but now there's a revival. And with this, without further ado, I've passed the… the word Renault. I've seen you around before, Renault. I think you're still here.

Renaud Dubois: Yep, yep, I am, so…

Antonio Sanso: Let me stop presenting, and…

Renaud Dubois: Yeah, let me share my screen. You… you have to shut your…

Antonio Sanso: Yeah, yeah, I'll try, I'm trying.

Renaud Dubois: sharing, so I can launch mine.

Antonio Sanso: I have some issue with my mouth today, I don't know why. One second, I don't know what happened to my mouse. Alright, she'll be fine now.

Renaud Dubois: Yep, yep, yep, let's meet… Can you see it?

Antonio Sanso: Perfect, yep.

Renaud Dubois: Okay. Yeah, so… so this is a… this is an EIP we… we tried to… to launch last year as, Antonio… Antonio said, we, we implemented it. So I'm gonna present it. Actually, we were a bit surprised, to see the precompile appear, In Justin, in a Justin tweet, last week, because we… We actually didn't get too much eco on this one, but, yeah, so there was a sus mention for the straw map. Not sure if Justin was intending here to directly target this precompile, or maybe it's related to another thing that Vitalik tweeted also last week. Which is a numpy, NUMPI precompile, which, I will also…

Give some, insights, during, this, presentation. So, starting with, with this, so, at first, yeah, the, the topic was a bit less hot, when we, when we first, wrote this, this spray compile, we have two things in mind. So, of course, the post-contum threat. Which is a very hot topic right now. So, okay, we, we talked, about it, during the previous, previous sessions. the two EIPs that are, that have been proposed, EIP8051 for Delitium and 8052 for Falcon. And both share one common, core operation, which is a polynomial multiplication, in a ring, and this is, this can be efficiently computed, with NTT. So… So this is, this is the core of,

of this precompile. And it also happens that this NTT is also used in the stock, verification, so I'm not sure if, for instance, Starknet is still, is still, doing the L1 verification with the Stark directly on N1, or wrapping it in a KZG, but, the, this NTT we are pre-compiled could also, speed up, this part, so, to allow, fast third verification of a ZK prover, even if… I guess that will… all the work that have been done since, we should, or we could have some… pre-compile for the ZKVerify itself. So I guess that, the other topic is a passcan to demonstrate. So, if we… The position of this precompile, so we have very specific, EIPs for the LTM and Falcom. Of course, they are optimal in terms of gas costs, because when you implement a precompile, this means that for the clients, for instance, gas, rest.

to call the precompiled, it means that there is a switch of context, which comes with a price. So, of course, having a monolithic implementation provides better gas costs, but, of course, it's also more rigid, and if the choice has to be replaced, this means that you have to write a brand new EIP while having the NTT precompiled. You have some universal primitive for all lattice-based candidates, and more than this, because polynomial multiplication is not limited to… To, to, to verifying a signature. It does not include the ash, so as we presented for Falcons, if you have an EVM, equivalent, where you replace the hash2Plane function by, EVM compatible. You have something that is

gas-efficient, otherwise you have to implement CHECK, and this is very expensive. Actually, when we implement the NIST versions of Delithium and Falcon. The ash is the most expensive part, so we will need a sheck precompile. We're also working on this. So this is, this is here in the middle that, we have the NTT precompile, and another thing that has been introduced, by Vitalix recently is a NUMP precompile, we will, call it the NumPy precompile. Which introduce, vectorized operation, for small, 32-bit, integral. And so this has a maximum generality, many applications, so it's not limited to lattices, it could also speed up matricial products, big integrals, implementation, poseden. This means that, for instance, even if you want to implement large, larger elliptic curve computation.

I knew there were some, some initiatives that were actually very, very, optimized, but still, to have a CDCAS384, it's like… 10 million guys, so this will also benefit, from this. But, as it is not monolithic, this means that you will have Many, many other bit manipulation, hashing, for the world primitive. So, to address a specific, primitive, you have something that is less efficient. Okay, so back to EIP7885, so it introduced four opcodes in the precompiles, so we have the NTT forward and, inverse. And, the multiplication and addition of, vectorized tap, types, which are VECMILMOD and VECAD, VecAddMod, so…

this polynomial multiplication, the NTT compared to the naive, naive approach as a complexity of n log m. And in our implementation, the fields that we covered are, of course, the NIST primitives, but also the… the ash fields, that are for sites for stocks, so Baby Beer, God Deluxe, I think we have Koala, and the stock curve. So, benchmarking this, we have… Something… So, the reference Solidity Falcon is 1.5 million gas. Implementing it using the, the NTT precompiled, we were able to lower this cost to, 400, Okay, guys.

So, this is a… this is a huge improvement. I think this is close to twice, the strengths minus, that, were presented last, last time. But the… the call data size, is, yeah, very small. Very small compared to the huge, I don't remember what was the size, the size is, obtained by the… Sphinx minus proposition, but, like, yeah, I think 20K kilobytes, something, something like this. So, we have this decrease, but, the remaining bottleneck is, yeah, the ash function. So, while we… we could have something that… that could be to KGAS, who is, the companion IP. So… yup, yup, yep, so…

Yeah, I guess I already talked about the advantage of the specific compared to the more generic, more generic approach. Yeah, and so this NumPy, so that's a promising parallel track, we started to work on. So it's a NumPy-like frequency for the EVM, so it's introducing vectorized modular arithmetic for those who have followed, their proposition, which was kind of… abandon, with the… with the deaths of, EOF, which was EVM max. So, EVM Max was a powerful, but very complex precompiled. I think the problem with EVM Max, it was introducing too much things at a time, and was too… Too complex, while, what NumPy is, is just, vectorization And the input of the precompile is the size of the vectorization and the operation. The operation being either addition, multiplication, with or without modular reduction.

So… So, yeah, we, we just started, we just started this work. So… NumPy would provide maximal, algorithmic, agility. But, at the expense of higher gas costs, because, we would have more data manipulation between the different stages of the NTT. So… To conclude, EIP7885, it's a single precompile that enables a post-consume signature verification and speedup of stark verifiers. Providing some cryptographic agility, so there are still some constants, Around, tights to which, which is, prime field, we are working on. Yeah, and so right now, we began, we began some benchmarks, on targets.

Yeah, so… So, not, not sure. The proposition is on the, the table, we… We kind of, put it on pause, last year, but if… if the interest is back, maybe we can… revive, and work a little more on this one. So, I don't know, Antonio, if you have more insights about the trauma.

Antonio Sanso: I have a bunch of questions, if, I mean, if someone has a question, can post on the chat or tell, but I have at least 3 questions, if you don't mind. Until today, I didn't… I didn't understand… I mean, I was not aware, or, like, maybe I'm not correctly. Is the NTT and the NumPy… no, the NumPy precompile. in… opposition. I mean, it's one or the other, or they can work together.

Renaud Dubois: I guess they can work together, but as the SADA functions, the more candidates you have, the less… probability you have for each of them to be accepted, so I'm not sure that we should push all of them, but instead, maybe… Choose a… a champion. So this NVM Pi, we have… Yeah, we have promising, first, first results. But it needs to be incorporated in the world scheme to see what are the final, final gas costs we obtain, for… compared to… To a monolithic NTT. But I don't think it's a good idea to push all of them at once.

Antonio Sanso: But can it, I mean, can it be one that includes both an MP and an NTT, or, like, really cannot stay together?

Renaud Dubois: No, I mean… I mean, MPs really… is really something that is a kind of trade-off. Before, we have the risk VM, because I think this is, This is the endgamer, right? It provides many, many potential speedups for values, values implementations. That's what is really interesting. And it happens that, NTT is, is one of them, so… bets… Yeah, so they are not… they are not antagonists. They are not antagonists at all. Okay.

Antonio Sanso: And…

Renaud Dubois: I mean, the, the, the, the ACDE… .

Antonio Sanso: Oh, yeah. I'm well aware of it.

Renaud Dubois: the way it works, I don't think that if we… Okay, pushing a single, cryptographic, precompile is already hard. They don't like it, because it's hard to evaluate. It's… it has… yeah, looking at what happened with BLS, you know, one of the rare incidents. that happened was in divergence between clients with BLS, so since then. I guess at core there, they are really scared when you want to introduce a new cryptographic precompiled, so… I would mainly say that that's the main reason not a technical reason, or the fact that there are antagonists, but the fact that, okay, pushing too many, computational, pre-compile for the same fork, I guess…

Antonio Sanso: No, but I mean, it will be still one with many opcodes. I mean, you have on your… on this NTT, there were four opcodes. How many opcodes you will see more in the NumPy one?

Renaud Dubois: Only one.

Antonio Sanso: Only one.

Renaud Dubois: Yep.

Antonio Sanso: Because I was under the impression, I see Vitalik here, actually, I was under the impression that the NumPy one will be having, as well, plus, or more.

Renaud Dubois: Yep, yep, but… It's, It's a parameter inside the precompile, so… yeah, you could say that it's kind of cheating. But actually, it's really, if you see how, vectorized, op-code works, it's like…

Antonio Sanso: It's, like, flexible, I mean, the input is… okay.

Renaud Dubois: Yeah, I mean, it's like changing the… having one parameter would be the operation. Is it multiplication, addition, or subtraction? And then it's vectorized on all the cells. That are the input and output of, of the precompile. So it's a bit less complex than, than. than, EVM Max, of course, bets. Yeah, but still, still a… still a complex one.

Antonio Sanso: Alright, and the last question, then I will have two questions in the chat, I see as well, is… I've seen that you were supporting, like, five, six primes on your proposal. Will it be totally out of question to have, like, the prime being… Generic.

Renaud Dubois: No, but.

Antonio Sanso: This means that in the cold data, you would have to provide the power of,

Renaud Dubois: of a generator as lookup tables, because if you… if you have to compute, the power, to… to recompute on the fly, then you lose all the interest of, of the precompile.

Antonio Sanso: Makes sense.

Renaud Dubois: It's like… it's like when you perform a Montgomery multiplication, you provide the Montgomery constants, and if you don't, you lose interest of Montgomery multiplication, because computing, the constants. Imply some inversion.

Antonio Sanso: make a lot of sense. So it will be really about, like… I think, like, choosing, like, the standard primes plus 3 or 4, I mean, will be enough. Now, I see a bunch of questions here, and we can go in order, and Gotti, you will be the first one, if you want to repeat by voice, or I can read, I don't know.

Gottfried Herold: Yeah, I mean, that was just a question. I mean, you partially answered it. To what extent, actually, you utilize the fact that you have hardwired primes in your precompiles. You know, so it, I mean, it just has a bit of a different, sort of API, depending on whether you can have arbitrary primes, a special set of primes, and with pre-computed tables, and so on was just a question. To what extent this sort of matters here.

Renaud Dubois: Yep. Yeah, yeah, so for the NTT precompiled, It's really hardwire… the hardwiring, is, really important, because you have to pre-compile, pre-compute all those, power of P. So these are a large, lookup table. For the NumPy, precompile, it's, really small, because here it's, it's only a barrett, barrett multiplication. So I don't know if you see how Barrett multiplication works, but here the, the constant is very fast. Yeah, I know. So it's really fast amortized, so… and we think that, so there was discussion, should we provide the Montgomery constant and, implement the, the, the vectorized multiplication as Montgomery? And no, we, we think that, Barrett, So Barrett is, like, 30%, more expensive than, than Montgomery, but if you look at the fact that, the precompile also provides some… Perform, the butterfly.

So the gather-scatter, layer. So this is, amortized, so Barrett, Barrett compared to Montgomery, when you have to, to have this, linear permutation layer, is very… very close to Montgomery. So, using Barrett, Barrett multiplication, it's very fast to first, compute the approximation, of Barrett, Barrett constants, and then, proceed with the full, With the full, yeah, bar rate multiplication, or… and also for, For modular, modular addition, it's faster to, to use Barrett, than, conditional, yeah, the conditional, modular production, which is just a subtraction for, for addition, subtraction. If it's clear.

Antonio Sanso: Makes a lot of sense. I see as well a question from Stefa. I don't know if you want to go by boss, I didn't read the questions. You want Steffa?

Stefano Gogioso: Sorry, it's… yeah, Stefano, this is Windows being silly and cutting.

Antonio Sanso: Okay, awesome.

Stefano Gogioso: All right. But I think Dano can go first, because that seems a bit more… a bit closer a question to what we're discussing now.

Antonio Sanso: Dana, you want to go?

Danno Ferrin: Sure. I wanted to know how the precompiler has been done dealing with multiple bit widths of the encoding. I didn't see any specification of strides or anything, and…

Renaud Dubois: The percentile definition.

Danno Ferrin: And, like, the keys of the Lithium and Falcon, they don't fit into 8-bit buckets. You know, we've got 3-bit, 4-bit, 10-bit, 14, 20-bit, and they go back and forth between the different bits all the time. Are you going to expect people to decompress their keys and bit align them before they submit them? Or will you be taking the canonical keys and be able to use those within the precompiler, or will we have to massage them with EVM?

Renaud Dubois: No, here, it means that this is a bit manipulation that would have to be performed. I think that the decompression, because we had this same problem when we implemented our Falcon in full solidity, and I think that, the overall cost for decompression was something like $150K. So, yeah, that's expensive, and also the question is, should it be performed, at the contract layer? Or, because actually, for… for the, for the signer. The signer could be the one, performing the, the decompression. And actually, actually, what is, very annoying is to have the, the 14, the 14 bits, representation, instead of 16. Because it implies a lot of bitwise manipulation. But, yeah, the…

the decompression could be… could be done wallet side, because it's just an encoding, right? So, there is no secret handling, The way you represent, the function to verify can be specified, either at signing level or at, verifying level.

Danno Ferrin: So, what we're undoing is what the designers of the… of the particular algorithms we're designing for, which was smaller key size and smaller signature size, specifically for blockchain solutions. So now we're asking end users to undo that, and use a much more expanded form of the key and the signature, on the blockchain and increasing our carriage costs.

Renaud Dubois: Yeah, I mean… I mean, if either we have a fully NIST-compliant precompile, and this is more, the specific EIP 8051, 8052, which can just straightforward push NIST-compliant verification. Or you will have to… to have something that is more custom, and here, I would say you're, The contract, developer, will… Yeah, we'll have the freedom to decide where the complexity of encoding is handled.

Danno Ferrin: So, yeah, this, I guess, is probably a subject for next week's as well, but the odds of getting custom hardware for custom bit widths for NIST algorithms, I think, is pretty low. The further we drift from NIST and our recommendations, the harder it's going to be, to get better hardware wallets, to get better adoption from, institutions. I mean, if we're just doing cypherpunk freedom, great.

Renaud Dubois: Yeah, but…

Danno Ferrin: But that's limiting our market adaptability.

Renaud Dubois: if I can add a word here, you can have an adaptator, which can be in software between the hardware signer, because, I mean, an encoding is something that can just be handled by the companion wallet. I mean, this is a public, A public, computation. So, you are not able to forge on forge, so…

Danno Ferrin: That can be done on social.

Renaud Dubois: Where over, over, over the, hardware signer.

Danno Ferrin: Right, and that adds friction for non-users, like auditors, who need to verify it as well. I'm just concerned the more friction we put on. The more difficult it's gonna be for institutions to adopt this.

Antonio Sanso: But, correct me if I'm wrong, guys. I mean, as long as I understood, like, we have this NTT precompile that is as generic as possible, so people writing contract will be able to use different pieces of LEGO, in this case it would be Entity and shake. to… to do, like, if… to do whatever, right? I mean, because we have as well, like, an abstraction, so they will be able to do, like. Falcon, or Dilithium that is standard, or… or less standard, depending on what they really kind of decide to do it. And of course, like.

Danno Ferrin: there's still missing pieces, like Falcon would still need the shape precompile.

Antonio Sanso: Yes, yes, indeed, like, I will go to this other piece of question for Renault. I was really impressed by the 2000 GAS, if you have the check precompile. This is really impressive. Like, I mean, if really, like… Shake is as well common between… the Litimate Falcon. If we really have the combo NTT shake, this, like… With 2,000 gas, it's really like… As competitive as… as the current signature scape. Right.

Renaud Dubois: Yeah, but I… not at all, because EC Recover is 3K, and actually, EIP851, AT52, so this 200K doesn't include the call data, right? So, if we… if we leave apart, the… the data cost. So here, it's a rule of thumb of the sizes. Actually, verifying a Falcon signature, or a Delithium signature, it just, benchmarking DLTM and Falcon compared to a CDSA, and actually, it's… it's… it's really close.

Antonio Sanso: Yeah, I mean, delegate maybe have to…

Renaud Dubois: We have something that is the data cost plus, plus 3K, or… and actually, the computational part will be negligible, compared to the core data. A bit like, what Consini, presented us last time. All the costs lie on the… on the… Large, data size we have to handle.

Antonio Sanso: So, assuming you have Shake and Tdprecompile, how much will it cost to verify a file, can you say? With bulk precompiles.

Renaud Dubois: No, no, that's what I said, around 200K.

Antonio Sanso: Okay. And where's the other cost come from?

Renaud Dubois: So what?

Antonio Sanso: I mean, where are the other causes coming from? Like, assuming you have, instead, entities, shake, and Numpy, how much you can cut?

Renaud Dubois: Now, I mean, numpy will not cut. NUMP will be a larger cost than NTT, but NUMP is very agile. With, with NUMP, you, you can speed up Poseidon, you can speed up, NTT, you can speed up, big integers. Begin togetherless computation, if you want to have some I don't know, yeah, larger elliptic curve, and so on and so on. So, an MP… NIMP is not… Yeah, it's… It's a very, yeah, it's a useful tool that will be used for, I guess, any cryptographic algorithm that is not a precompile would benefit from NumPy.

Antonio Sanso: Right. So, but you're saying that under $200K is kind of impossible to go?

Renaud Dubois: Sorry?

Antonio Sanso: under… with these two pieces, under $200K is impossible to go.

Renaud Dubois: Or you… if you don't, if you don't, implement a specific precompile, of course.

Antonio Sanso: Yeah, yeah, yeah, I mean, I'm in the…

Renaud Dubois: The 18052, would be far cheaper.

Antonio Sanso: Sure, sure, I mean, what I'm saying, like, with, like, going with the route of NTTP precompile and shake to undercase the baseline.

Renaud Dubois: Yeah.

Antonio Sanso: Right. Alright.

Danno Ferrin: So, my concern is that, anything with EVM cost exceeds the data carriage cost. I'm concerned it's not gonna be terribly… Economically viable. I mean, for all of these post-quantum signatures, data carriage cost is going to be 5 to 10x what it is for an ECDSA signature. That's unavoidable. But if there's ways to avoid making computation greater than the daily carriage costs. I think those should be considered strongly, and that, in this case, would be a direct NIST precompile, but just my opinion.

Antonio Sanso: So, Daniel, your… your point is, like, you're… you don't like this… NTT per compile check combo, you will go directly with the NIST per compile, that's what you're saying?

Danno Ferrin: Yeah, strictly for economic reasons, yeah, there's no way that we can get, you know, hundreds of signatures in a block if each signature costs $200K to solve.

Antonio Sanso: Right, right. It would be really interesting to… To at least have a proof of concept and see where the costs come from. If there's some other low-hanging fruit that we can cut. I'm talking about NTT plus shake approach.

Danno Ferrin: Right, right, and that's for computation, that's probably worth looking into. But I think, you know, for all these signatures. The elephant in the room is that data carriage costs are gonna go up 5, 10, 20x, and that's… there's no signatures that we're not facing that.

Antonio Sanso: us, sorry.

Danno Ferrin: the cost of the data in the blockchain. The signatures are going to be, like, 500 to 2,000K, and that's on the low end. Bites. And…

Antonio Sanso: It's not avoidable, I mean, we know about that, right?

Danno Ferrin: Unless we're gonna do ski sign.

Antonio Sanso: No, no. I mean, I come from misogynist, I'm telling you, no, we're not going to ski side. It's too early, it's too early.

Danno Ferrin: Right, and unless we're ready to talk about signature aggregation with new lattice folds or whatever is being cooked up in the Ethereum Foundation, you know, those are the sort of things that we need to look at in addition.

Antonio Sanso: Lattice forward.

Danno Ferrin: Those abbreviennies.

Antonio Sanso: will not help here, let his fold, for signature segregation, will be something more like Labrador that might.

Danno Ferrin: Right, right. But those are the solutions that, for very large N, We might want to look at.

Antonio Sanso: Yeah, we'll have something in the next days that covers that, so just hold tight for a few more days.

Renaud Dubois: Yeah, I think we need, we need, native, account abstraction for lattice-based candidates. To avoid, to have this, transmission of the public key, which… which is the main problem.

Danno Ferrin: Probably key is about the same size as a signature, sometimes smaller. The signatures are pig.

Renaud Dubois: Yeah, I mean, Falcon Signature, if you don't have to transmit, the public key is, 6… 666 bytes, good number. Yeah, so… That's not that.

Antonio Sanso: But the other question is, Renault, of this 200K, assuming you don't transmit the public key. How much down do you go?

Renaud Dubois: No, here, here, the problem will be the bit manipulation, because you… You will have to go on and forth between, the different precompiles, so… Actually. You can't get that much lower.

Antonio Sanso: It will be, you know, personally, and I'm not sure if there's something you will, or… you can provide. I will be really happy to see the… this… where these 200K are spent, how much are spent in cold data, how much are spent in each operation, will be… Would be really interesting from my perspective, too. To understand. Because 200Ks, yeah, it's… it's got something, right?

Renaud Dubois: Yeah, yeah. To… but this is work, though. To be honest, we are more focusing on the NumP precompile right now. Because we have been asked to. And also, I think it's interesting to have a generic tool, so this is something else. But yeah, that would be interesting, right?

Antonio Sanso: Is there… is there… is there anyone… I mean, it would be interesting to, like, to have anyone helping you with the NTT per compiler. I mean, at the moment, it's you and Simon. If someone else will join the effort, you will be accommodating. I'm talking about the existing NTT one.

Renaud Dubois: Yeah, yeah. Yeah, but, I think it would be interesting to understand what Justine was, aiming. Because I'm not sure… actually, I kind of… share, Dano conclusion about the NTT precompiled. So, even if I'm the co-author, This is not the horse I will bet on right now.

Antonio Sanso: Right. And do you think that the NumPy way will produce… assume you have NumPy and Shake, you will have a cheaper gas cost?

Renaud Dubois: No, it will be higher, but once again, NumPy is very versatile. it's not limited to, to just, even if you remove all Lattice's candidates, because, for instance, when EVM Max, started, it was absolutely not to implement, Lattice candidates. So, it's more the high, genericity of, of NumPy, rather than having a lower gas cost. So maybe having something in the middle is not that interesting. Either we go full specific with a NIST candidate. And honestly, I would push MLDSS 6065 right now, because I think this is a Web2 way. or you push something that is not limited to lattices. NumPy is not just Pascantum, it's, it's, Yeah, when you, when you…

When you implement something, and for instance, in the modern architectures, you have vectorized operation, in a… Be it in AVX2 or, vectorized arm restrictions, and they did not, do it for… for Pascantum. They did it because, Parallelism is the way to go. With modern computations.

Antonio Sanso: It would be at least interesting, and maybe this is something you're… would be more interesting, given what you've been saying so far, to provide some data, at least how much will be… assuming you have shake, and assuming you have this NumPy precompile.

Renaud Dubois: Nope.

Antonio Sanso: how much you have, right? I agree with what you said, but if this combo is gonna be, like, I don't know, 1 million, call me out, you know? If this combo is $300K, okay, I buy what you say. Because, like, okay, so you have more flexibility, and the cost to pay is not… so much more than when I pay with NTT, for example, so…

Renaud Dubois: Yeah. Give us some weeks, and we will provide the answer. We are on this topic right now.

Antonio Sanso: Okay, well, thank you. This will be real interesting to understand, and .

Renaud Dubois: And we will provide the answer shortly.

Antonio Sanso: And Shake, you already implemented as well?

Renaud Dubois: Shaq, there is nothing to do to implement Shaq. You take some C library, you put it as a guess for a new precompile, and…

Antonio Sanso: Yeah.

Renaud Dubois: You ask it to close, and you have your precompiled in 15 minutes.

Antonio Sanso: No, but I mean, like, I was wondering where you can… took your data from, with the shade. That means that you already, kind of.

Renaud Dubois: Yeah, no, the thing is not the check cost, because it's… a check is like K-check. There is no diff… quasi no difference between check and K-check, only some constants, so you can say that the cost of check should be the cost of K-check at the end.

Antonio Sanso: Okay, so you took the baseline from that. Okay, makes sense.

Renaud Dubois: No. I'm not. The thing is, in Falcon, you have many, yeah, you have some kind of PRNG that is using check, but it's not DI check. And this is all the data manipulation that you have to do around it. That creates the cost.

Antonio Sanso: Right. I know, Stefano, if you want to go with your question now. It was probably more about aligning with what we are discussing now with the…

Stefano Gogioso: Yeah, I mean, I'm not sure it's so much a question as a list of longer-term derata, but I… when I envisage what would benefit the… the Ethereum ecosystem more broadly in terms of SIMed operations, vectorization, tensorization, and so on. I do think of cryptography, of course. There is all the number of theoretic primitives, Stark, post-quantum. they all benefit from it. But there's a lot of use cases. One of them was suggested also in the… in the chat. A lot of… finance applications make large use of vectorized primitives, but not a small, specific subset, like a large sub-language of vectorized primitives. And more generally, we do have, right now, a fairly stable set of tensorized primitives that I used in machine learning, AI deep learning applications.

Some of them are, of course, not the sort of thing that you would want on-chain, or perhaps you'd want them in a sort of succinct, proof way, rather than directly executed, but a lot of the lower-level sim primitives are things that CPUs today would execute fairly efficiently. And they will make it possible to introduce quite a lot of new use cases for on-chain computation, but this wouldn't be a specific set. This would be a broader, like, subset of stable NumPy primitives, NumPy functions, or subset of stable functions from something like… I don't know, TensorFlow, or any of these languages, ultimately, they all share the same kind of basic building blocks. So that's what I… that's what I envisage when I think of a NumPy recompile, not something quite specific. Now, maybe I have misunderstood what the ultimate direction

of travelers for this, in which case, yeah, sorry. But it seems to be that a lot of the attention is to making a very small set of primitives that are of interest today. more performant?

Antonio Sanso: Just no one interrupt you, it's like, Renault is asking, like, if you have some concrete example, and probably means as well, machine learning, it will be… it will be happy to… to benchmark. Am I correct, Renault?

Renaud Dubois: Yeah, but honestly, machine learning, I'm not sure I see what, what should be done on-chain?

Stefano Gogioso: No, no, machine learning is a… I mean, I think many things that could be done on-chain, actually, but perhaps that's a broader goal for slightly later on. But certainly a lot of vectorized… there are a lot more vectorized operations than just Additions, multiplication, and arithmetic operations. And they are used in a lot of financial applications that could very much live on-chain and are today prohibitive to do in terms of gas. So we could have more complicated contracts that do more realistic on-chain finance if we had a broader subset of the non-bip primitives.

Renaud Dubois: Yeah, so really, I would be really interested by a concrete example here.

Antonio Sanso: Reno, for this pre-compile, is the field generic, or you have as well a fixed field?

Renaud Dubois: No, it's generic, so…

Antonio Sanso: Lyric, okay.

Renaud Dubois: It's, Barrett, The, the Barrett constants, the Barrett multiplication constants are evaluated, entering the, the precompile, so it's on the fly, and, so it can take any, any modulus, lesser than 2 to the power, 32.

Antonio Sanso: Alright, we're right. I see as well, try to wrap this topic now. I think we got enough about that. Thanks a lot, Renault, for presenting and answering so many questions. I'm looking forward to your future numbers. Honestly, I mean, it's, has been great work. And I see Dan know that they wanted to take a tangent, if I don't… If I'm not wrong, right?

Danno Ferrin: Right, so one of the things that was brought up was, you know. Try not to carry the public key with it. There's two questions that come with that. Number one, where do we store the public key? Will we store it on-chain like a 77 on 2 delegation? Will we put some sort of, data in the account tuple? But the next question, I think, is more, existential. Because with the current transaction, you can validate it with all the data in the byte string that the signature is valid. And if we remove the public key, you would need to have chain data associated with the address. that… on one hand, makes it more difficult, to verify, without any other reference data, but it also opens the door to things like key rotation, so where you could have your address and you could move between different keys.

So, that's… I don't have a strong opinion which way to go with it, but I think it's a path that needs to be considered, because that'll absolutely help us save chain data, cut it in half in some cases, because the keys, especially with someone where the keys are… Any key that's, like, 43K is not viable, but there's a lot of… there's some signatures coming down the pipe where the signature is small, but the public key is large. And if we could cache the public key and chain data, we might be able to keep not chain data, storage data. We might be able to keep the growing of the chain data much more under control with these transactions using these small signatures.

Antonio Sanso: Before, like, Renault was pointing that, that kind of abstraction might actually bring something on the table. I am planning, like, the next two weeks, the call number four. to bring the account abstraction people in, to just, I think we should talk in general, like, at least, like. people that are interested about post-quantrum signatures should understand the future native account abstraction well and collaborate, so I'm planning to bring here this call. But I see that as well in the chat that Renault is saying that create tool, and I can abstraction might help.

Renaud Dubois: I mean, today, because we don't have to, when using acrony abstraction. Actually, if the accounts are deployed using Create2, you have a deterministic function, which is actually… can be seen as an hash function from… yeah, from your public material to… to the address where the contract will be deployed.

Antonio Sanso: facilities.

Renaud Dubois: So if you look today, if you look today at Ethereum addresses. you have your public key, it's hashed, and… but the thing is, for all accounts, it's the same way, but… For… for account abstraction icons, you have the kind of same hashing mechanism, which is implicit with the Create2 you're using.

Antonio Sanso: But, as long as… A per discrete tool, right, with that kind of attraction, will there be a way to store the public key in the contract as well?

Renaud Dubois: Yeah, sure. That's what we've done with the 4237 implementation, and actually, we don't have you don't have, because you want to have this kind of hashing mechanism so you can send money for someone even if the contract is not deployed. But if you… If you use the create2… Okay, the contract doesn't have to be deployed to already send fund, to it, if you check a deployment. The consistency of the grade 2.

Antonio Sanso: I mean, that's what I mean before, I wonder, like, the framing transaction, like, so the native account abstraction will keep all these features.

Danno Ferrin: It sounds like it would become an option of a particular smart contract wall provider, because they could just assign random Create two addresses, and just tie the key to it. So having the key be a function of the hash as a convention is useful, and that's the discussion I want to have for stuff like counterfactual deposits. You know, what are we losing by untying this, or making the tying conditional?

Antonio Sanso: But do you agree on the statement that it will be really useful to have a collaboration with the people that are doing the framing transaction EIP, to be sure that they don't… that we or them are not missing anything?

Danno Ferrin: So… Yes, we should, and I think it's a bit concerning that frame transaction is being pushed as a post-quantum solution, and they're not on this call. All the time.

Antonio Sanso: I will try to solve this somehow. I mean, at least, like, for next call, it's gonna be really the topic, I can't abstraction. And, we'll try to improve on this. Probably my best.

Danno Ferrin: The fact they're not on the call, to me, shows it's not a post-quantum solution, it's account abstraction, it's independent of it, and they're just using post-quantum to push them over the line, which is fine, they need the momentum, but it's not post-quantum, it's account abstraction. Plain and simple, that's all frame is.

Antonio Sanso: Well…

Matteo Vicari: Yeah, but, sorry for interrupt, but the idea of all the frame transactions is to have some modularity when you do the transaction. So, the idea of the frame transaction is not important if, we converge in a post-quantum way to a specific type of signature. The important parties have the possibility to change the signature or run. So, it's like, some technology can… push forward this discussion, give the possibility to change, the signature scheme, like account abstraction, now work, for example, in the example of Renoir in the last few calls. The account abstraction in the frame transaction is like, some technology that can validate the possibility to change the protocol without, any, stress for, artwork or stuff like this.

Right, but it's…

Danno Ferrin: presented as the only possible solution. Where, you know, there's, you know, press switch is pushing some, I have a solution that doesn't require full abstraction. Whereas protocol-level signatures. That's… what I don't like about it, is that it's being presented as the only way to get it done, as if the decision's been made.

Matteo Vicari: Absolutely.

Antonio Sanso: Anyway, like, I don't know, just as well to say, like, I'm trying to get more involved with the people that are doing frame transactions, but, I mean, actually, Vitalik was here, so he just left, but, I mean, he's as well one of the author of Frame Transactions, so they're for sure aware of what is going on.

Danno Ferrin: That's exactly my point, is that… the decision's been made. There's no debate.

Antonio Sanso: Again, I think, like, if there is something that should be accommodated off both sides, I mean, there's still things we can sort out. I mean, the decision from my Hego Taya are still way open, I mean, it's not on stone, so there is plenty of time to do modifications in case we need it.

Danno Ferrin: Have there been any other post-quantum transaction formats other than AA seriously considered?

Antonio Sanso: No, but I mean, what…

Danno Ferrin: Exactly, the decision's been made.

Antonio Sanso: Yeah, but I mean, with…

Fab: event. Do you have an alternative solution? Because at this point, the reason why AA was picked is because many of the post-quantum standards are still relatively young, and to be honest, even if NIST-certified three standards, you know, I personally do not feel, like, completely safe, in using a post-quantum signature scheme that hasn't, I don't know, 15 years of battle testing under its belt, and at the moment, we have none. So, when we enter this framework, to be honest with you, I… I think we need a solution that allows us to swap Signatures, if we so need. So…

Danno Ferrin: Exactly what I proposed in the first meeting, if you looked at my slides. We put the signatures and we put the body in two separate places. We don't rely on account abstraction and pushing in the EVM. I agree with you. We need to have a… we need to have cryptographic agility, because at least one of these signatures that's being talked about is going to be broken in the next 15 years, whether by the base or by the construction of the keys. But we… the transaction format itself is independent from the signature, and we need to keep the signatures separate. That's… that was literally in my first slides on the first section.

Stefano Gogioso: Yeah, no one.

Antonio Sanso: And I agree perfectly with you, and I encourage you to be in touch with the account abstraction people. I don't know if you manage to eventually, but yeah, like, I will have them in the next call presenting frame transaction, so… but even, like, outside of this call, if you have some ideas, I don't see why you cannot be in touch. Stefano, you…

Stefano Gogioso: Yeah, sorry, I just wanted to, as somebody who thinks that account abstraction plays a pretty major role in this, I do agree with Dano that that is not probably the only way to do this, and maybe not even the best way to do this. It does give us flexibility, but would I favor a mechanism where signatures are composable and independent of the transaction? Yes. There's always the question of, and then what happens if somebody disagrees on the signature schemes? But that's solvable. So I just wanted to say, as an AA fan, that I do agree that separate… like, having an alternative mechanism with a sort of composable signature transaction separation is a good idea. So I… he has my support.

Antonio Sanso: Yeah, but…

Stefano Gogioso: Pacific time.

Antonio Sanso: What I'm trying to say, like, maybe to use some synergies, like the idea that you guys have, or that you, Stefano Rodano, like, proposed to the frame transaction And maybe can be included. I mean, I don't see one against the other, you know, like, maybe…

Stefano Gogioso: No, no, I don't think they're against. I just think that both should be, like… they serve different purposes, and they have different advantages and disadvantages, and I'm just, like, publicly stating that I.

Antonio Sanso: Maybe it can be embraced.

Stefano Gogioso: Yeah, I like that.

Antonio Sanso: That's what I… from his presentation, actually, that was my feeling, that some of his idea could be, like, actually taken into account, into the.

Fab: By the way, guys, just like a very small remark, I think that the idea that we use account abstraction so that we do not have to decide on signatures is ultimately wrong. I think that I'm very convinced that, you know, the user base, the non-tech-savvy user base, will ask for a go-to signature scheme. So in this sense, it's, you know, we kind of solve the problem technically, but we are just kick in the can further down the road, because at some point, you know, the user base will ask, okay, cool, we can support all the signatures in the observable universe. This said, what do I use for my shitty wallet? And, you know, in that case, yes. Yes, users would be…

wallet providers, in a way, most likely. But still, you know, I think they will ask for guidelines. Like, no one… no wallet provider wants to risk implementing a signature scheme that doesn't work or has problems, so…

Stefano Gogioso: Yeah, but I think that, like, like it is in the case of, like, most Web2 applications, ultimately the choice of scheme falls onto either library providers or wallet providers. And it can be that we have multiple choices living together, like we do today, as long as they are all broadly acceptable, and it can be left to the consensus layer to decide which ones are acceptable and which ones are not. And then, ultimately, people will have to switch, and it will be for, you know, not the end user to decide which which signature scheme to use, but they're intermediaries that provide software for them. Yeah, sure. I think it can be done in a way where the end user doesn't really have to worry.

Fab: Yeah, what I'm saying is that resorting to AA is not the end of the discussion. There will be a lot more discussing.

Stefano Gogioso: down the road. I agree, I agree completely.

Antonio Sanso: Anyway, guys, I think we're out of time. Today was really a marvelous discussion.

Stefano Gogioso: That was marvelous, yeah. Thank you all.

Antonio Sanso: I… I will, I will wait for you in two weeks. Will be account abstraction, the topic, so will be really a good segue from this call, alright? Thanks a lot for attending. See you all, guys. Cheers. Thank you.

Fab: I bet.

Matteo Vicari: See you, guy.

Antonio Sanso: Love it.

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