How Are Blockchains Preparing for Quantum Computing? Dan Boneh Moderates a Post-Quantum Roundtable

Captions as YouTube publishes them, usually machine-generated, so product and people names can be misheard.

1. 0:00

   Are we live? Are we recording? Yeah, perfect. Okay. Hello everyone. Uh, welcome to this uh, exciting session about the discussion of hashbased signatures versus lattice based signatures for blockchains and Ethereum in particular.

2. 0:14

   We have a super exciting panel here that's going to discuss the issues at great depth. And so before I introduce everybody, I thought we'll just go one by one and uh, folks can kind of state their positions. And a very reasonable way to start is is with Justin. Maybe you can go first and talk a little bit about Ethereum's plans and which way Ethereum is is planning to go.

3. 0:37

   Absolutely. So I'm Justin from Def Foundation. Uh I'm a researcher there and our postquantum plans uh involve moving to hashbased cryptography. Uh so we're trying to not compromise on security, have rocksolid foundations that can last decades and centuries with high confidence. Um we're also trying to design something very beautiful uh so somewhat minimalistic um that uh is in the philosophy of lean Ethereum. So we're trying to be in some sense as

4. 1:08

   simple as possible and boil down our security assumptions to the most minimal trusted codebase. And this is where formal verification for example comes in. And we can have security properties that are extremely lean and that's the only thing that you mainly have to to to audit. Finally, we're also interested in extreme performance um especially at the consensus layer where we have many

5. 1:32

   thousands of of validators. And in order to fulfill this last criteria of extreme performance, we introduce SNOX as this extremely powerful tool that not only helps at the consensus layer but also at the execution layer and also at the data layer. So we have a lot of work to do and we use this one tool called lean VM to solve all of our problems.

6. 1:55

   Oh great. Yeah, that's a wonderful intro. So uh Ethereum's plan for postquantum security is going to be purely purely hashbased combining hashbased with snarkbased systems. Great. Okay. So our our next uh uh next I'd like Charles to go uh and explain kind of how uh Ledger is going to deal with this with this issue. So Charles is the CTO of Ledger. Um uh and yeah so Charles why don't you say a few words about the Ledger architecture and then how Ledger

7. 2:22

   would deal with different types of signature schemes. Yeah sure. Uh so uh Ledger is very well known for the the hardware wallets, hardware devices. Um and we also have like a B2B offering based on hardware. And the security model of Ledger is pretty simple. Uh the idea is to keep your cryptographic materials inside a secure enclave. And when it comes to assigning a transaction, the transaction is crafted outside of the secclave. it's

8. 2:51

   sent to the secure enclave and then the secure enclave will parse the transaction, provide the details to the user and uh finally sign the transaction. So um we have built an operating system that is running in the secure enclave. We are we are using like smart car technology and HSM uh technology. Uh and the operating system is providing different uh cryptographic primitives. Um and today we are

9. 3:16

   supporting uh hundreds of different blockchains and they all have different uh cryptography. It's already the case for non like pre preontum cryptography. Uh and when it comes to supporting postconum cryptography at the end we will support like every single algorithm that will be implemented by the the different chains. Um in this uh in this process uh I I'm following closely what uh different chains are doing and it's it's really passionating and participating to the to the discussions

10. 3:50

    and and quite often I see that on the protocol level uh the there is a there is a bias that consists in only focusing on the security of the protocol and sometimes forgetting a little bit like the full chain up to the wallet and so on. uh I'm not saying this for you uh because we are talking with Foundation and so on. So I just what I want to say is that we can create like secure systems is if the protocol is secure uh

11. 4:19

    and also everything around the protocol is secure including uh the the wlet side of things. Uh so at le we're going to most uh most likely support ashbased signature um latisbased signature and every single postconum signature that the blockchain will implement. When it comes to hashbased signatures it comes with um some challenges on the ledger side. As we are using like secure hardware, we have like limited resources and capacity when it comes to computing

12. 4:53

    those signatures and hashbased signatures in particular are are quite are more difficult uh to implement not not in terms of um like implementation complexity but more in terms of uh like a power computation that you have on secure enclave that are very limited and so on. uh for instance if you think about like a full sphinx plus uh which is like the SLHD DSA uh standard uh on today ledger device it would take minutes uh to compute it. So this is

13. 5:25

    also something that needs to be uh kept in mind. I understand the the idea of having like minimal assumption uh on the protocol and so on. [snorts] Uh however I think I think we are losing a lot of um capacity and a lot of um like um possibility for the future uh if we only use hashbased cryptography while with Latis we have more potential for for for the future. That would be my so my

14. 5:57

    preference would be to use MLGSA in general as a cryptographer but as a ledger CTO we will support hashbased and and let's based signature there is no debate about that. Just Charles can I ask you about the timings? So um uh what can you just be a little bit more specific about uh key generation time versus signing time on the ledger uh for for things plus which is SLSGSA the full standard that the NIST is uh is

15. 6:27

    providing uh so we didn't do like a um like a deep um benchmark but out of the box I would say it's like over a minute to do generation and several minutes to do the signatures on the sphinx plus but there are many variation of hashbased signatures and some and different variation would cost uh would would take less time uh than this and this is with no hardware support for shot 256 this is shot 256 in software

16. 6:59

    exactly the we we would would implement 256 within the firmware uh inside the device because in smart cards you don't have 256 six acceleration because for the main application which are identity banking and this kind of thing they don't use based cryptography.

17. 7:19

    Mhm. [clears throat] They use hashes but only to compute the hash of the message to sign afterwards not to to do a signatures with hashes. Great. Okay. We'll come back to that. I think that the performance issue is quite interesting and there's a lot to say. So we'll we'll we'll come back to that in in just a minute. Uh so Anton, do you you want to go next?

18. 7:37

    Yeah, sure. Hey u so Anton I'm Wes near one and I'm leading the development of the protocol and also very importantly in relevant to the conversation chain signatures that powers all the crosschain stuff for near intents um via an MPC threshold signing scheme and uh I'll probably start with we already have lettuce base cryptography on mainet which creates a like kind of places us in a very specific camp uh in this

19. 8:03

    conversation obviously um however full disclosure this is just for the signing the transactions by the users. It's not for the consensus. It's not for the validators. It's not for the chain signatures yet. And all of those questions remain open for us. Uh we obviously face all the same problems that everybody else has with consensus and performance and having block time at 600 milliseconds today on mainet. Um

20. 8:30

    which requires like coordination of hundreds of uh at least yeah 420 something validators we have live on mainet. Um we are very very sensitive to the validation sign uh validation validation times as well as signing times by the way. Um it is less of an issue for some other chains but for us both actually matter. Um why did we go with lettuce based cryptography um specifically MLDDSA 65 the variant that we chose. Um why? Because we wanted to actually start highlighting all the

21. 9:03

    problems that people will will see or will face when they start using postquantum cryptography on chain. And the longer you wait, the less time there is for everybody to migrate. And there is it's not like near ships an upgrade and it's postquantum on Qday and everything is magically solved. It's not the case. We actually want the users to be secured. We also want all the wallets, ledgers, web wallets, exchanges, all the custody providers,

22. 9:34

    all of them to be upgraded. And we we started we just decided that we can actually ship this easily and cheaply because Near's uh account model allows you to add multiple keys already today like already pre MLDDSA we supported ECDSA and EDA DSA. Um you could have both and now you have you can have three. And immediately when we shift it, we've seen that it actually is like this the ecosystem is not ready like the

23. 10:00

    first thing we've seen after mainet um I went and added MLDDSA key to my account and I see that block explorer doesn't show it because their ENM doesn't doesn't even consider that to be a valid key and that was like everywhere every single place you touch you see these problems so it's good that we started are we there yet by far not yeah the transition obviously is going to take is going to take a while. So maybe maybe it's worthwhile just to zoom out uh just a second. I mean so obviously you know the postquantum threat is uh I should say the quantum

24. 10:32

    threat is is is coming and so blockchains have to adapt and they have to start to adapt soon. We can't wait until it's too late to um to do this transition. So it's amazing it's wonderful to see the near started uh with the transition and what's interesting is that different blockchains are taking different paths right? Right. So some blockchains are going with a lattice approach. Some blockchains are going uh with a hashbased approach. Um uh I have to say

25. 10:56

    the hashbased approach is the one that uh is the least controversial in terms of security which I think is why Ethereum actually uh chose it. Yes. Uh I can see Justin nodding. So um makes sense. And then the same thing by the way holds for Bitcoin. Bitcoin is also going to is also most likely going to go with the uh with a hashbased approach just because uh from their point of view um they're actually it's interesting when you talk to Bitcoin developers

26. 11:22

    they're quite excited about removing the discrete log assumption from Bitcoin so that Bitcoin is only going to be reliant on security of SH 256. So from their point of view this is actually uh a positive step regardless of the quantum threat or not. Um they they also mentioned that the migration to hashbased signature could be like a first step and they could consider another migration to like newly

27. 11:49

    uh standardized signature schemes. Yeah, they are they are also the Bitcoin world is considering a two-step process where in the immediate step you just add shrinks public key to your to your tap routt uh so that you have so that you're protected and then maybe later on they move they move to uh you know a finalized signature scheme that everybody's happy with. Um so that that that that is being discussed as well. Um from from my my point of view I have to

28. 12:15

    say the algebraic structure that we use with signatures like Schnore signatures like BLS the algebraic structure has been extremely productive for us right we have had a lot of uh applications for that like hardened key derivations um you know adapter signatures high threshold DKGs so all of a sudden we have we we kind of had a lot of things that we could do with the algebraic structure and um I think that by moving

29. 12:39

    to to hashbased signatures obviously there's a lot going to be a lot of interest in in researching and more more capabilities of hashb signatures but we're kind of fundamentally limited in in what they can do and I think we're going to miss the algebraic structure that come from um from um you know things like lises and discrete log and so on. So I'm actually to be honest I'm um uh both excited that Ethereum went

30. 13:05

    with the high security solution but it's also interesting to try to allow for more experimentation. So for example, once everybody transitions to account abstraction, in some sense, adding a new signature scheme is not as complicated as it is today. The big transition is moving everybody to account abstraction.

31. 13:22

    Yeah. And then in the smart contract that manages everybody's accounts, we can maybe be a little bit more um experimental in that uh you know, we allow different types of signatures. In fact, there's nothing already preventing somebody at the at the execution layer for implementing lattisbased signatures in their smart contract um once they use account abstraction. So, in principle, people could use uh lattis based uh signatures if they really wanted to. I

32. 13:47

    guess the question would be what would happen at the consensus layer, at the data layer and and and so on. Um uh so yeah, so um my my my my viewpoint is it's not clear we have to kind of um actually I guess two points. One is I think we're going to miss the algebraic structure if we're going to move strictly to hashbased signatures. Um and uh it's not clear that at all layers data layer, execution layer, and consensus layer, we actually have to use the exact same signatures, right?

33. 14:13

    They're they're facing different constraints. Um and so maybe it makes sense to consider different types of signatures for uh for the different layers. Yeah. So I'll leave it at that. Uh so um uh Ilia do you want to say a few words too or Well I actually I I actually want to ask a question because I mean obviously Justin as he uh put put it uh is proponent of hashbased and yes that I think like it would be good to

34. 14:38

    understand kind of the like actually what is the assumptions that you know hash versus u lattisbased bring right uh because we say it's more secure but what does it actually mean for people and then the other question is effectively diving in is like then what is a trade-off on performance on I mean you mentioned then like loose algebraic properties like that actually has big repercussions on the whole ecosystem right who is you know relying on this for multi-arty

35. 15:13

    computation for custody uh I mean that's example we care about but there's obviously other properties as well that uh that people use So I would I would love to dive in into that. Um um and that's that's worth that's worth mentioning that um like Lexis based cryptography is standardized by the NIST and the whole world will move towards uh MLGsa like most of the application in the non-blockchain environment will use MLGSA primarily like just because of the

36. 15:45

    performance and the different trade-off that we that we mentioned. So I I also would like to so I understand the idea of that ashbase are more conservative. Uh but like how like how can we um doubt like what kind of doubt do we have on the security of latises basically what's that would be my question.

37. 16:08

    Oh you're asking how how worried are we should we be about the security of of lattice signatures? Yeah, security assumptions are we talking about when we say lattice is less secure and both kind of mathematical attack side and on actually programmatic because kind of to double down on Charles's point if everyone uses the same lattice based right there's standardized library there's like a lot of audits right everybody knows how to use it and so there's like an alternative cryptography

38. 16:38

    as we know you definitely don't want to use self-ridden cryptography Um, sure. Um, Justin, do you want me to answer that or you do you do you want to go for it? I have an answer, but I'm also curious. Up to you. Oh, okay. Sure, sure, sure. Yeah, look, I mean, the interesting thing about hashbased signatures is um obviously we're only relying on the security of of the hash function. So even if something terribly wrong happens to go with shot 256, it's very unlikely since it's been around for so long. But even if

39. 17:08

    something happens to go terribly wrong with it, it's really not that um it's it's like the scheme stays the same. We can just replace it with a with a different hash function. So in some sense, we have uh a lot of flexibility. Uh with the lattisbased schemes, obviously we're making specific assumptions about a mathematical problem. Yeah. you know whether whether it's LWE or SIS I mean you know we're

40. 17:28

    making an assumption about a mathematical uh problem uh in the quantum space I uh this and the question by the way is not how secure is it uh classically I think there's very little doubt that it's it is a classically sec these are classically secure assumptions the question is how secure are they in the quantum in the postquantum world um and that's you know it's kind of interesting to hear as you probably know over the last couple of years there from

41. 17:53

    time to time there have been papers that claim to have had attacks on quantum attacks on on lattice assumptions. And it's very interesting. So all these papers have turned out uh so far not to work. But it's very interesting that every time one of these papers comes out, all of a sudden there's a bunch of um uh noise in the community saying, "Oh, you know, we're not really sure about the post the quantum security of of of lises." Uh

42. 18:15

    which is kind of interesting kind of interesting to hear. So for now but for now up until now it already has been uh what is it over over 20 years that people have been trying to come up with um lattice quantum algorithms for lises and failing. It's probably even more than 20 years and failing. So I think we have fairly good confidence in the assumption which is also why NIST chose to standardize uh signatures based on lattice assumptions. In fact it might be

43. 18:41

    worth reminding people that so far NIST has standardized three signature schemes. two are lattis based and one is hashbased. I mean that also indicates that they have a lot of confidence in the in the postquantum security of lattises. Uh so I don't think there's too much to worry but as you as as I think Charles is alluding to it is a specific assumption if it's broken we're stuck. Yeah. It's kind of not clear where where we move to. We have to re restart the whole uh competition efforts and so on. So it's not really clear

44. 19:13

    where we move to. So the um even if we kind of make a wrong if we make a wrong decision with lattises the recovery path is much harder there if we happen to make a wrong decision with shot 256. Yeah I think this is when Justin says I think this is uh I don't want to put words in your mouth but I think when you say this is the safest path this is kind of what you mean that it's a recovery path is much easier.

45. 19:37

    Yeah I I I mean many things. So the the main thing that we're trying to achieve is to have Ethereum cryptography last for many decades hopefully centuries. Um and you know when you go with the latises you introduce these these new mathematical assumptions as as Dan put forward you know I think those are specifically module SIS and module LWE and um you know basically we have conjectures that these are are hard problems and humans are not that good at

46. 20:07

    you know setting conjectures um and sometimes these conjectures kind of break even after you know many decades and this is something that we're starting to see in the world of mathematics, we have every single day multiple conjectures uh that that that are broken by by by AI. Um and you know, I would give it let's say a 1% chance that classically these latis assumptions were to break under a super intelligent AI. You know, there's this expression

47. 20:36

    which is that there's some uh decades where weeks happen and there's some weeks where decades happen. We are entering a world where centuries are going to happen in a matter of weeks. We're talking about centuries worth of mathematical discoveries that are that is happening with these super intelligent AIs. And I think it's, you know, quite reasonable that at least a 1% chance of this cryptography breaking classically. Now, you know, when we build uh cryptographic systems, we're

48. 21:04

    aiming for 128 bits of security. And so if you want to think of this in terms of number of nines, it's like 49 of assurance, like galactic level of of security. Um, but if you have 1% chance of your assumption failing, we're talking about two nines. And if you look at quantum attacks, you know, it's going to be greater attack space than the classical space. So it might be, you know, closer to 10%. And now you're down

49. 21:28

    to one nine of security. And there's also a possibility that you know the cryptography does like how do you measure this 1% or 10% like actually Charles why don't we do this in turn let's let's let Justin finish his argument and then and then% yeah I mean one way to measure it is to do you know a sociological experiment where you kind of look at all of the conjectures that mathematicians had high confidence in and then you look at how

50. 21:59

    many of those uh AI have proven in in in the negative. So for example, we had the the unit distance conjecture like most you know mathematicians believe that this conjecture was true and no it turned out an AI found a counter example and you know that's after decades of trying this is one of the hardest mathematical problems out there and we're starting to see sociologically that um you know humans are not just are

51. 22:23

    just not very good in terms of their intuition uh when it comes to to to to conjectures. Now one other thing that I wanted to mention has to do with parameterization. So it is possible that latis assumptions are secure but the question is under which parameters um and um you know there is a possibility that if you go with you know let's say N level one MLDDSA you wake up one morning and it's no longer level one you know it's it's level 0.5 or zero level some

52. 22:54

    some something else. Um, and so, you know, when you when you look at the uh at the at the performance of of these signatures, maybe you want to be asking yourself, what is the performance of the scheme that has the security margin to withstand uh a degradation um due to some some attack that that that squeezes the the security margins and this is something that we saw with with Hawk. So Hawk was like not completely broken as a signature scheme but the the parameterization had to be re revisited

53. 23:25

    and all of the performance benefits kind of went out of the out of the window. Um now just to frontr run a little bit of the discussion in terms of performance um you know the the the traditional wisdom is that letters based signatures are are more performant for example on in terms of signature size. Now here NLDDSA needs to be measured as the signature size plus the pub key size um not just the signature size. And here we're looking at roughly 4 kilobytes.

54. 23:57

    And what we've seen in the context of really optimized stateless hashbased teams is that we can match the 4 kilobytes. So that that's no longer really a performance win from the point of view of these signatures. But again going back to my point on parameterization, it's 4 kilobytes optimistically. it might be 8 kilobytes after you reparameterize based on the newly discovered attack.

55. 24:23

    So that that's the discuss that's your argument for security. So actually I I do want to push back a little bit on the on the super intelligence uh aspect of it in that if we assume these AIs are going to break all all our conjectures then shot 256 is also at risk just like lattises. So h how does this play into the calculation?

56. 24:41

    Yes. So there's different families of conjectures and at first approximation maybe there's the the structured ones that involve you mathematical symmetries and and and and objects where you know imagine you have a mountain and you want to climb the mountain and you know every every symmetry is kind of something that you can put your hands on and grab on that will allow you to go up and and this is you know very powerful as you noted Dan for example with BLS because these these symmetries these homorphisms

57. 25:10

    or whatever it give you a lot of power to to do things, but it also gives power to the attacker. If you think of unstructured assumptions like like hashing, it's like climbing a a wall which is completely flat. There's like there's very little to work with. Um, of course, you know, what you would do is you would go dive into the hash function and uh and and and try and find structure there, but at least abstractly

58. 25:36

    in some sense is the the the weakest assumption you can make. And on that point, one of the things that we have in blockchains is the sunk cost. Every blockchain needs a hash function, you know, to just build the chain of of of of of blocks, you know, to merkelize all of these things, you know, we use a hash function for for state um everywhere.

59. 25:55

    And so for us, just like you mentioned in the case of Bitcoiners, it's it's free like building on top of of of SHA 256 is completely free for us. um is not an additional assumption uh that we bring uh bring forward. Yeah. So this is an this is an argument that that I hear a lot that people are quite excited about rem reducing the number of assumptions that the chain depends on and that that's a kind of a

60. 26:19

    stronger argument for hashbased because they already depend on hashes for lots of lots of other things. Um so actually maybe we can move away from the security discussion for just a minute and talk talk about more uh the challenges with deployment. Um, so, uh, let's see.

61. 26:35

    Can I actually, this is a good segue. I can, um, I mean, it's not exactly unrelated to security, but this is, um, my problem with Ethereum's approach, like not exactly like a huge problem, but the potential um drawback of the of the approach uh that the Ethereum team is taking is that um to practically use hashbased signatures for securing consensus, you need to apply ZK on top, right? And uh I fully agree that you already have to rely on the security of hashing. That's

62. 27:07

    that's that's great and having single security assumption to rely on cryptographic assumption to rely on is better than than more. Um that is great but then you start applying ZK on top which is sure it's hashbased but ZK is fresher. We've seen things compromised.

63. 27:24

    we've seen things implemented insecurely and it's kind of sharing similar criticism uh to MLDDS specifically that it relies on floating point operations that is nonministic it's hard to implement um and ZK is also hard to implement so aren't we partially negating this security argument that we're making by using hashes so that's one one part the second part uh to quickly calcul calculate to calculate fast enough those ZK proofs, you're probably going to be pushing um significantly the hardware requirements

64. 28:01

    pushing up for the validators which uh in the age of AI where every single GPU is is basically sold before it's it's manufactured is is going to be very expensive. So this while it may be okay and you can probably say that okay if just one GPU is going to be enough it still pushes the cost of running the validator higher it pushes it up and it also means it hurts the centralization okay fantastic you bring up many points let me address the the easy ones so you

65. 28:32

    mentioned uh needing a GPU for aggregation not true we're not targeting any GPUs we're targeting a single laptop CPU and actually when you look at the execution layer where our throughput is actually quite small. Uh it's today we're doing 25 transactions per second.

66. 28:49

    The aggregation of 25 stateless uh signatures can be done on a single thread of a single laptop CPU. So it's like bare minimum. Now in a how long in 10 seconds in we can we can aggregate 25 per second continuous. on a single core of a single laptop CPU.

67. 29:15

    That's how fast the stocks have become uh and no no GPU whatsoever. Now when you look at the consensus layer it's a completely different ballgame and the reason is that we have today a million validators um and they're each you know voting every epoch um so that's you know tens of thousands of signatures per second that you have to aggregate and so here we had to have this kind of 10x optimization which is to go from state

68. 29:40

    less signatures to state full signatures and we can do uh easily uh you know a thousand signatures per second aggregated on a laptop CPU and And when you distribute that uh with with a you know a mesh network of aggregators then you get you know the full 1 million uh validators uh that that that you need to support. Again just for you to understand you're leveraging the fact that uh only one validator needs to produce the proof unlike the execution that needs to be

69. 30:12

    basically executed by everybody to agree on the new state but one ZK proof is enough to prove the new state. essentially you don't need everybody to produce the proof. So both at the EL and the CL is the exact same mechanism. We you know we have hashbased signatures we aggregate them and essentially there just needs to be one entity that does this work and everyone else can benefit from that work.

70. 30:34

    Just just to clarify I think Justin is talking about aggregating the million signatures from the validators into a single proof that everybody else can verify. Correct. Yeah. Oh, so it's happening still in the single place. Okay.

71. 30:48

    Y so um at the consensus layer today uh you know we have so many BLS signatures floating around that we partition them in what we call subnets. Uh and in each subnet there's a layer of aggregation and then uh because the the aggregates are so small we just concatenate the aggregates in the final in the final block. it's not a big deal. But unfortunately when you do snark based

72. 31:12

    aggregation you can't just concatenate naively because each uh snark each proof is about 100 kilobytes. Um so we we we want to do what's called recursive aggregation where you know we have a a snark that recursively proves compresses aggregate aggregate stocks. Um so it's not a single entity it's distributed in this kind of mesh network but ultimately what the end product is a single proof u that uh anyone who's following the chain just needs to to download and it's one

73. 31:43

    proof per block um and the similar thing at the execution layer we just have one proof per block and one interesting thing is that from a performance standpoint we actually end up with a scheme which is more scalable than uh uh ECDSA what is a reason for that. So let's let's take a a bitcoin uh as as as an example to to to understand. So um bitcoin has about 10,000 signatures per block and each signature is 64 uh bytes.

74. 32:15

    So we're looking at 640 kilobytes of data just for the signatures in a bitcoin block. Now if we were to sn uh the postquantum signatures which it would be my suggestion to bitcoiners they would be end up with a single proof which is only 100 kilobytes and so they would save 540 kilobytes per block. So they would actually go from 3TPS or whatever they're doing today to something larger because they'd have the extra half a megabyte per block. Um so you know this this conception that uh

75. 32:48

    you know postquantum signature uh will will lead to performance degradation is actually the opposite of of of the of the truth at least when it comes to the the core state transition function and and and the main consensus bearing throughput of of the blockchain. It is true that there's going to be more load on um the mempool. Uh but here we have you know various ideas. One of which is that we can we can chart the memp pool

76. 33:13

    if we want each mempool to be to be fairly distributed. Um, and there's also this misconception as I was alluding to that, you know, hashbased signatures put more pressure on the mempool than MLDDSA. It's not the case because, you know, they they're each, you know, 4 kilobytes and so there's the exact same amount of pressure. There's no scalability benefit at the memp pool uh for for using MLDDA. And Anton you were

77. 33:37

    making the point that if you have hashbased signatures you need necessarily to have aggregation. That is also not the case. So you know near for example today could just go ahead and have these 4 kilobyte um stateless signatures without aggregation and it work would work perfectly fine. And actually the gas cost of verifying stateless uh hashbase signatures is lower than that of verifying MLDDSA. So

78. 34:03

    MLDDSA takes about you know the really optimized implementation will take about 600,000 gas. Um a hashbased signature will will take less than that. So it's no more from a size standpoint but it's also uh uh no more from a from a gas usage standpoint at least if your execution environment is is the the EVM.

79. 34:26

    Now, did you did you try to aggregate MLGSA with Snark because it's possible I guess it's a little bit more costly, but it would allow to have like both signature at the protocol level. Actually, let me jump in here because uh uh um I was just talking to some folks who were telling me that that uh it's very likely that that it's possible to aggregate like 10,000 MLDDSA signatures per second on a MacBook M3. Cool.

80. 34:51

    So, um, so that that that's numbers that are floating around for MLDDSA. So, just throwing that in. Yeah. As a This is this is great. And actually, two days ago, um, there was a a breakthrough paper called Bitz. Uh, it's actually pronounced Beats. Um, and, uh, what it allows you to do is to have SNOS that are field agnostic. What that means is that you can you know have your arithmetization with any field actually any ring arbitrary ring uh including

81. 35:22

    including the integers and so that means that and and you can still get the native performance as if the the snark was built with that that specific prime. So um what that means is that we can have a proof system that can aggregate extremely fast all of the cryptography that we know of whether it's latises, isogynies or something even more exotic under a single proof system and do it with optimal uh efficiency. So um that

82. 35:49

    is definitely something uh that we can do. Our philosophy uh with Ethereum is uh somewhat what what Dan alluded to with with account abstraction. So we provide every user the choice to use whatever they want. Uh similar to what you you were saying Charles um you want to support all of the cryptography. Um but when it comes to the most low-level infrastructure of Ethereum the stuff that is meant to last decades and centuries here we we're

83. 36:21

    opinionated. So at the consensus layer when it comes to validators there's no need to provide choice right we can be opinionated and that can be stateful hashbased signatures same at the data layer extremely opinionated when it comes to the execution layer we're opinionated only for the the default scheme basically the replacement for ECDSA we call it lean sphinx it's basically sphinx plus but ultra optimized um and as a piece of alpha we're going to be releasing

84. 36:52

    next week uh a new auto research challenge called sig.golf G with the only uh goal of optimizing uh stateless hashb signatures and we believe that we're going to crush the performance of sphinx plus um if anything because you know sphinx plus parameterization is is not designed for blockchains you know it has for example a lifetime of 2264 no one needs that you know 2 to 32 is enough for you know any any any human

85. 37:23

    being um And not only that, but you know, there's all sorts of of optimizations that were left on the table, either because NIST didn't want to incorporate them back back when the standardization process was running, but also because there's been new stuff that has been discovered since. And nowadays, with the age of auto research, the sky's is the limit. We're going back to, you know, doing centuries worth of of

86. 37:47

    exploration in a matter of weeks. um we will have the the the AIS do that uh and find the optimal uh scheme and actually what we started looking into is lower bounds. So at least for one-time signatures we can prove tight lower bounds. We know that we have a scheme that just can't be improved. Um and and that gives us the confidence to launch something that we feel proud about. Um

87. 38:11

    and and something that you know would would would sustain decades and centuries without the need for uh for performance optimizations because we have something that's optimal. Really interesting and I I think like the current design is really elegant.

88. 38:28

    back to back to Anton um like question uh and on the security side of things uh how what do you think because using the aggregation we are introducing a new primitive which is the the zk proof u I know that you have planned to prove it uh in formal methodology and so on which is which is great however it's a new primitive that's quite complex and and we have seen uh in the asked several issues uh around the implementation. So what's what's your opinion on this?

89. 39:06

    My opinion is that snarks are so incredibly powerful that it will become impossible for blockchains to not bite the bullet and incorporate them. Snocks solve scalability in our context ZKVMs. Snocks solve the efficiency of postquantum. Snocks solve privacy and snarks of like all of these other things. So for us it's a song cost somewhat similar to Shatu as an assumption being a S cost. And so for us doing aggregation is free because we

90. 39:37

    already have for example uh aggregation or like ZKVM technology in the context of of ZKVMs. Now when you work with uh ZKVMs you do introduce new assumptions and these you know get increasingly subtle but um one of them is the so-called fiat shamir heristic or the fatir transformation and then the other thing that we introduced when it comes to recursive proofs is you know this this huristic that you can you

91. 40:08

    know safely recursively aggregate proofs. Now when you look at the the the broad ecosystem and you talk to cryptographers they're usually on board you know with these additional assumptions um and you know even to an extent today uh there is some aspect of of fietir in the cryptography that we use uh damic correct me if I'm wrong but you know for example ECDSA to some extent has this this aspect of in particular yeah yeah schnore [snorts]

92. 40:39

    um so the We need to kind of distinguish two things. One is the fundamental assumptions that we're making which in this case is fat and the the recursive aggregation. We're putting a lot of effort to better understand the the fundamentals of fia and ideally we'll we'll we'll be in a world where we can have provable fia and there's like a few promising directions there but it's still an open uh area of research. When

93. 41:04

    it comes to implementation complexity, this is very much under control in my opinion precisely because of the the formal verification where the only thing that you have to audit is the security statement which is this is a proof system with 128 bits of you know soundness uh in the random oracle model.

94. 41:22

    This is a thing that you can just read um and uh and be convinced that is correct. you're reducing the trust base to something like the the lean for kernel. That's a separate discussion about whether or not this this infrastructure can be trusted. But um it shouldn't from an implementation standpoint it should not be more any more trusted than the implementations of the signatures whether it's hashbased or latisbased. So Justin, actually I do want you to uh talk a little bit about uh what we're [clears throat] going to

95. 41:55

    lose uh from hashbased signatures like the fact that we uh we we won't be able to do hardened key derivation. So hardened key derivation means that I can derive uh one public key from another public key and that lets me for example look up balances without knowing without revealing my secret key. So I do I I do hope you can talk a little bit about um the things that we will lose like for example thresholds or MPC based wallets become a lot more complicated with

96. 42:20

    hashbased signatures. So how do you how do you um uh weigh in the costs of hashbased signatures to um in terms of you know features that we're going to lose. Absolutely. Great question. So the um the preconception that people come in when they enter the room is that hashbased signatures, you know, have great security, arguably great performance, but the the from a functionality and flexibility standpoint, they they they suck. And what what I'm trying to to do gradually is try and convince people that this

97. 42:57

    last bucket, the flexibility is actually not a real trade-off. So, you know, one thing that was mentioned, for example, is uh from by by Charles is that, you know, signing Sphinx Plus on a Ledger Nano S+ is is is difficult. Well, it turns out that there's all sorts of tricks that you can play and you can get signing uh under one second. And this this is my personal goal. I will be, you know, very unhappy if we can't have one

98. 43:26

    second uh leans signing on a on an old uh hardware wallet like the the the DS+. Uh and I believe Dan, you might actually um be a recent co-author on on the paper that we're that that we're working on. Um so I believe that this is under control the hardware wallet part.

99. 43:45

    Um when it comes to MPC, there's also been very significant progress lately. We actually have three different highquality teams working on this. Um we have one called Reva Labs and you know it's all in stealth but there's some really exciting stuff happening. There's one called Silence Labs and then Dan uh I believe you're working with a group called local host and and various others and you have your own uh re research uh

100. 44:14

     with uh with with prawns and the TLDDR based on all the information that I know today is that we're going to have threshold signing under one second. Okay. Yeah. Depends with the trade-off. You can have like plenty of like premp computation. Uh I think this is the trade-off that comes with revelabs or use like different uh like uh trick such as done. I think you you're leveraging latisbased cryptography and it works only with stateful you don't have DKG.

101. 44:45

     So it's not like I think like the signature one second is only one parameter of the whole signature process. Yeah, that's correct. So given the state-of-the-art there is a process the DKG uh or the pre-mproation uh that happens outside of the critical path but if you talk to if you have you know this this practical business mindset and you ask okay what what problem are we trying

102. 45:09

     to solve here we're trying to solve the the custodial problem um where most of the time it's a two out of three multisig um and you know the these these three uh signers are basically controlled led by sophisticated entities that have uh you know beefy computers and and and and great internet and uh you know this DKG aspect okay it might take a few minutes of preparation time um which is kind of this this this uh

103. 45:40

     this thing that happens outside of the critical path but when they want to sign the the signing process itself will take less than less than one second um now there might be use cases that I I don't know of where this doesn't work and I I would love to to learn about those and kind of check them off and and derisk them. Then there's the final thing then that that you mentioned which is the the key derivation.

104. 46:05

     So my understanding is that indeed this is as of today's uh you know state-of-the-art something that we we do lose from uh from something like lean sphinx but my understanding is that this is not a feature that MLDDSA provides either uh I might be proven wrong. Maybe MLDDSA could could could be uh shown to provide this feature. Then the other observation that I'd make is that this is not really a feature that has much of a use case.

105. 46:38

     Um, you know, you talk to the retail user, they don't use it. You talk to the um to the the more advanced institutional users, they don't necessarily use it either. So I think we can live without it. And it's not like MLDDSA provides it either.

106. 46:54

     I see. So your your point is that maybe we can live with the the features that we lose and at least for the threshold one maybe there'll be there'll be answers. I do want to mention like one thing that um some custo some custodians that we we talked to um they basically are a little bit worried about the complexities of doing MPC with hashbased signatures. So they proposed or rather they're planning to move to to an

107. 47:17

     architecture which uh might disturb you a little bit in that um the plan would be basically to have uh still have the the secret shares be shared across different parties but when they need to sign those parties will simply send their their signing shares signing keys to a central um uh enclave. The enclave will reconstruct the secret key centrally and then sign that way. just this is kind of their their their um generic solution to to threshold signing

108. 47:47

     no matter what kind of signature the blockchains adopt. So this is in some sense that architecture is it's a little disturbing because we're putting a lot of faith in the enclave and in some sense it is the hashbased signature that's causing them uh to go in this direction whereas MLDDSA falcon and others have uh eas more easily or or support easier threshold schemes.

109. 48:13

     Um yeah and also axis based cryptography al is also more promising in terms of what we could do in the future that we have no idea today like for hbased cryptography we we know that by default we are quite limited by the potential uh like discovery that we could do and build on top while because there is mimal structure we know that latises are more promising to build more complex cryptography uh system like thinking about IO for instance, uh do you if if

110. 48:45

     you if you consider like this kind of like long-term goals uh that would happen with latises and not with hashbased cryptography. I would say there's also positive surprises with hashbased cryptography. Maybe I mean Dan's work is an example of that.

111. 49:04

     just saying uh so if you're interested in cases where this key derivation uh is going to be a missing feature nearest chain signatures is one of them. We're heavily relying on on the fact that it's possible today. So like if that's not possible with hashbased it's it's kind of breaking so many use cases.

112. 49:22

     So it what is the story with MLDDSA? Um well MLDDSA is not used there today. So we're we're relying on the on the fact that it's possible with ECDSA and EDSA. If I'm correct, like MLGSA does not offer it today, but there is like a similar algorithm in the same family where it's possible D you're the one knowing it.

113. 49:46

     Yeah, but unfortunately I mean there's a variant called Raccoon that does support uh key derivation, harden key, but the signatures are huge. So yeah, I mean this is this remains to be a research topic for sure, but that's that's a feature that would be really really sad to lose.

114. 50:03

     So that that's that's a you're saying that harden key derivation for lattice based schemes is something we can ask our our super intelligent friends to to figure out whereas for hashbased I'm pretty sure there's a lower bound that says it can't be done.

115. 50:16

     So actually there is a very nice solution for hashbased signatures which is to use the the big hammer which is which is snucks. Um so what you can do is have a k out of n scheme where you commit to uh you know with a single hash your your your k out of n uh so your your your k pup keys and also you commit to the parameter k which is the threshold. Um and then you kind of prove in zero knowledge uh that you

116. 50:49

     you you have sufficient um non non-ag non-agregated signatures and then you you you wrap everything under under a snark. Now this has most of the properties that you want. It's indistinguishable from the final signature that goes on chain. Why?

117. 51:06

     Because the final signature that go on chain with Ethereum is a snark. And so you're gossiping these snarks that get recursively aggregated. is it's indistinguishable. You [snorts] have the property um that uh the the the the the parameter K is is not leaked. Um and you have the par you know all the the property that it it it's very efficient.

118. 51:28

     There is this one property that you lose uh which is the ability to change the committee of of of signers. Um so it's kind of a fixed committee and you're stuck with it. Whereas uh if you go with the the more native MPC based approach then you you you can you can change the signet.

119. 51:48

     Mhm. Yeah. Which is also quite a like cornerstone feature for anything chain signature does because we um these commitments these keys essentially safeguard assets on other chains and changing the signer set leading to changing the key on another chain doesn't like basically locks the assets forever.

120. 52:10

     Okay. So I think I might have just on the call like just found a way to to solve this this this final issue which is that um you know you allow for essentially what is like like key key key rotation. So you know you just use the fact that Ethereum is stateful you can just change uh the the commitment to the committee. Um I mean maybe there's one final problem which is that every time you change the committee you don't have zero knowledge of the fact that the committee was

121. 52:41

     changed. Um but you know we're getting more and more uh you know uh minor in terms of of of loss [clears throat] like uh full disclosure this is our backup plan. That's exactly what we're considering to do. Um the this doesn't work for non-s smart contract chains like Bitcoin which we support today and we can keep using the key but Bitcoin has a and like generally the UTXO chains have their own big set of problems.

122. 53:14

     Okay. So maybe Charles do you want to talk a little bit about u uh how do you see how you will support hashbased signatures where where do you see Ledger going with this with this design? Um so you know as I said as an introduction like in in all cases we will support uh like the choices of the different blockchain. It's already the case we uh back in the days we even supported like weird cryptography with

123. 53:39

     uh with custom uh like treats based hash ashes that were broken afterwards. I'm thinking about iota. There are plenty of such examples. So we are the Switzerland the gen of of crypto. So we we will support whatever uh whatever um crypto cryptography that is that is necessary. Um when it comes to hashbased cryptography obviously there are some challenges to to to to solve um because it's not acceptable to sign within

124. 54:13

     minutes and even like if it's 10 seconds or something like this it's it's not really acceptable. So um we have like a next generation devices that will that will embed like a next generation uh like secure element that provide acceleration for MLGSA and hashes. Um but hashes are mostly uh for kak uh which is which is an issue for the for what we are talking about. We have other options uh to to make it happen. So at

125. 54:43

     the end we will find solutions. Um and uh and my point about MLGSA is uh is is is more what I think personally should be a good a good choice for the future. uh and uh but in our case we will support HB cryptography and and I'm uh I'm uh really uh like happy to see that the foundation and Justin in particular takes into account the fact that the hardware must sign a signature in in a

126. 55:16

     few second maximum which is which is great and important and MLGSA is already supported on the firmware level and we can sign MLGsa signature on on near already. So it's it's already it's already possible. And I [snorts] do want to repeat that like with account abstractions, people can choose to use MLDDSA if they want to on Ethereum. So So you will need to support MLDDSA even for PE for for people who do want to use it. Yeah, exactly. I I want to go back one second though.

127. 55:45

     Uh so Justin also said that at the consensus layer uh hashbased signatures will be stateful. Um and also with Bitcoin as you know with the shrinks proposal those are also using stateful hashbased signatures. So I just wanted to hear from you Charles what's your sense of how you support stateful signing on a hardware wallet.

128. 56:04

     Uh this one is really is really um a difficult one. Uh I I think it's uh like stateful signatures are are really a foot gun because like for those who who don't know exactly how it works, the problem with the stateful signature is that if you sign twice with the same state, you basically give away your asset to to an attacker. So So managing this state properly is very very important. Um and it creates plenty of

129. 56:35

     challenges because today uh we have users that have the same seed on different devices. So if you have to maintain a state across different signers that are sharing same seed uh it's really difficult and more than difficult it will create like issues. Um so yeah I think it's definitely a foot gun. Um what the Bitcoin guys are are saying that there is also a path uh that uh allows you to do a stateless signature but you you have to pay the cost of the size of the signature and

130. 57:12

     one it's possible that uh if uh Bitcoin is going that that way most of the wallets could simply uh use the stateless pass because it really depends but lot of users are simply holding their assets for a long time and maybe like two years after they are like, "Oh, where's my hardware wallet? Where is my seed? Okay, I need to recover." So they they completely lost the state for sure.

131. 57:37

     Uh they uh they probably um lost their ledger wallet instance as well. Uh so uh they they would have to go back to the stateless uh signature path which which defeats the purpose of stateful signature. So again if we have to we will uh we will support uh shrinks as it is today. Um the problem with the set is that you have to manage the state for every single public key. So you can if you

132. 58:08

     have like hundreds of different UTXO of different account if you have different blockchains that are using this mechanism we will end up with like managing thousands of or more of the states. So it's not possible to store them uh inside the device. What we would have to do is to store like probably a miracle tree of monoton counter within the device and you would you would store

133. 58:34

     the states outside the device uh within something that is called ledger sync. So this is a a private cloud that we have for our users that's encrypted with with a key that that belongs to the device. So that would be the solution uh for that. However, you would lose uh you might lose all of this if you lose your device. Like sometimes your device is you lose your device, you still have your 24s, you have to recover and then you would lose all of this. Um and in

134. 59:03

     the current form of shrinks uh you uh can recover your uh asset without the state using the stateless path but you still need to have an information which is like the wallet ID or something that uh that indicates you where to find your uh keys within the within the trees of uh of keys in in the in the hashbased mechanism. And this must be like stored somewhere. So this is this is discussion we have with core dev because having independent recovery is is I think is

135. 59:40

     really important for for users. Today the 24s are enough to recover your wallets but tomorrow uh if the stateful signatures happen that wouldn't be enough anymore. And also uh when you need to uh find a new empty slot let's say um like today when you have to find the new uh empty uh account you just like uh you simply synchronize the chain and you look for the first uh public key where there is no transaction on it. Um so it's possible and then we create a

136. 1:00:13

     new account uh on this derivation path with with stateful signature you cannot do that because maybe a signature was signed but not broadcasted on chain maybe because it failed for some reason or you simply signed a message and so we also need a mechanism uh to know which pass was signed that is independent from what is on the blockchain. So those are the kind of um uh like difficult like challenges that we would have with shrinks if it was adopted as it is

137. 1:00:47

     today. And uh as you as you said Justin um if we really want to stick to ashbased signature which is not my preference as you understood I think it should come with like zk aggregation uh and and then avoid a stateful signature.

138. 1:01:07

     I I would agree with that statement and if I were to make a a bold prediction about Bitcoin I think the idea of stateful signatures is going to become less and less popular. It's kind of going to age like milk and the idea of recursion is going to age like fine wine as people understand you know what exactly is involved in terms of of security and assumptions and complexity.

139. 1:01:28

     One of the things worth noting in the Bitcoin context is that you don't need the recursive aggregation. So you know when I said there fatir and the recursion you don't need the recursion for bitcoin. And the reason is that Bitcoin, you know, only does uh 3TPS, which is about 10 signatures per per per second. And and you don't need the power of the of the aggregation. You can basically have the miner on the laptop aggregate all of the signatures in one in one second uh and and call it a day.

140. 1:01:59

     No need for for fancy recussion. Yeah. And by the way, the the rational for the stateful signature design is really to have like a a small signature. Um but at the end like even uh the small signature that they have in mind like with shrinks it's it's already like 600 uh bytes which is 10 times more uh than ECS ECDS signature. So if we don't change anything else uh at the protocol

141. 1:02:25

     level that means that we would like divide the throughput by at least 10 because this is only the stateful uh path and the stateless path is 100 times uh bigger. So at the end we will have to have this discussion about the throughput the size of the block the signature aggregation. So the stateful uh the stateful approach uh indeed decrease the size of the signature but not enough to maintain the same throughput. So it does not avoid us to

142. 1:02:57

     have the difficult discussion about the size of the blocks or the signature regation. Yeah, I think someone mentioned the the two this two two-phase approach for for Bitcoin where eventually they might consider something like MLDDSA. I think it's going to be three phases. Phase one something like shrinks which is the minimum viable just for Bitcoin to survive but not to thrive because you

143. 1:03:20

     know the the throughput would would would fall like a rock and then phase two they might add recursion and then phase three something more exotic like MLDDSA. Yeah, they're they're as data availability for the states of the sign.

144. 1:03:37

     I don't think they are like that can scale. Well, at least like the wallets can use it as a way to back up. Yeah, but that means that every time that Yeah, it's a very good idea. That means that every time the wallet is signing uh something even if it's a message it needs to put this data on the data availability layer of near and we need to create something that is atomic that says to the to the device that yeah it happened uh so it's not that easy to implement again well I mean near is already sending

145. 1:04:08

     transactions to bitcoin right through chain signatures so you can actually have that as a kind of flow at least like you have the signature produced and kind of published. Let's sign Bitcoin on right. Just just to be clear in the shrink case, they're talking about adding it to tap routt. So technically, it would just be available uh as a spending path, but it wouldn't be used until the a postquantum world until a quantum computer actually quantum computer actually appears. So it would just be

146. 1:04:40

     there as a backup mechanism, but it would continue to use ECDSA until until Qday happens. Yeah, in case we need we need a migration window to migrate ECS ECDS coin to leaves. Exactly. Exactly. That that that hopefully will uh will begin will begin soon. Um great. So um how are we doing on time?

147. 1:05:04

     I mean we're at an hour. So uh are there more more issues? Anybody has more questions more issues to bring up because I could go on forever on this. Yeah, definitely. Frankly, frankly, this transition is really really exciting. Uh we it's not very often that we have to change all the cryptography that is already implemented. Uh that that is going to be a nightmare like everywhere in the world like we are

148. 1:05:28

     talking about the blockchain aspect but cryptography is deployed everywhere in plenty of different environments that can be in cobalt sometimes if you see what I mean. Uh so this transition will be uh very very interesting. Um and I'm uh I'm really excited to see like the different progress that we that we have also with AI in this area. Um and um and just like to finish with the debate that

149. 1:05:54

     we had with with Justin. Um so on your side you think the benefits that comes from uh ZK are so high that it's worth taking a risk the risk while the bene the potential benefits that we would have with latises are not worth taking the risk am I correct to to say this yeah I mean snarks are a no-brainer for us they have an incredible power and with formal verification and when you

150. 1:06:24

     build your snarks using hashes, the trusted code base is extremely extremely small. You know, roughly the same size, if not exactly the same size as the the hashbased signatures to to to start with. Um, as I not exactly the same size because as as I mentioned, there's the fetch and the recursion thing, but we're working on that. And these are things that uh are are not cause for concern at

151. 1:06:48

     least for most cryptographers that you talk to. Ju just as a question is there any anything that would lead you to say actually uh lattice based we should use lettuce based so someone asked a very pertinent question which is you're doing aggregation of hashbased signatures why not also do aggregation of latisbased signatures um and I could see a world where we where we do that because ultimately the philosophy here is that

152. 1:07:20

     it if a user wants to take the risk and want to opt in to a specific assumption, they should have the freedom to do so. Um, now um I guess the the standard that the whole world is converging to, the whole internet is converging to is is indeed NLDSA. So I wouldn't be against the idea of uh aggregation of DSA signatures but that would have to be a battle that someone you know uh other than me probably would um would would

153. 1:07:50

     have to to conduct whereby you know they they make a proposal submit it to to as an EIP go to ACD and if I were kind of a a betting man I'd say that we would be if would rush first to have the hashbased minimal infrastructure and then the MLDDSA aggregation would be a nice to have that comes after that.

154. 1:08:12

     Then I mean again with with account abstractions people can use MLDDSA if they really want to. It just they won't those signatures won't be aggregated. Exactly. It's expensive. It's very expensive if you do that. And so it's not unreasonable to say, well, let's see if people actually choose to use MLDDSA.

155. 1:08:27

     And if enough people choose to use it, then you can talk about aggregating those as well across. But I mean, it's it's like saying with account obstruction, we could have used the Ederson curve on Ethereum before. It just like costed you, you know, whatever a block worth of gas.

156. 1:08:44

     [snorts] Yeah, it's 600,000 gas, which is a lot of gas. Yeah, I guess we bridge with that, right? And we're like we we effectively went to to you know do a I guess if I guess if Ethereum actually is open to implement a host function for that like or pre-ompile in the world called pre-ompile near has host functions but yeah if Ethereum implements a pre-ompile for that then then I think this this

157. 1:09:12

     becomes actually a pretty valid choice and we can argue that people are consciously choosing one or another and there's already an EIP for MLDDSA pre-ompiles just needs to be implemented and it's being discussed for HAR which is the fork after clamm so and so it might be coming so there will be a there could be it might be coming the foundation would argue that this is the wrong direction because we don't want to be encouraging

158. 1:09:38

     more pre-ompiles because that's a whole kind of worms and we also don't want to be encouraging latises but if if the world wants MLDDSA then you know first having the pre-ompile and then having aggregation might not be unreasonable. It might actually be a very neat solution.

159. 1:09:55

     Pre-ompile opens a lot of interesting cases by the way, not just account obstruction. If uh like the whole world was like including TLS, HTTPS and so on switches to MLTSA, you can do cool stuff with proving certain things that happened like an end point HTTP endpoint reporting certain data like the whole stream here like at a at a cost of very low very low cost but you can do the same with ZK Snarks as well.

160. 1:10:23

     Exactly. Yeah. The current road map is to um have the ZKVM called lean VM power our postquantum uh cryptography but also expose its power for applications. So we're building a risk 5 ZKVM and we would expose risk 5 as an an ISA in addition to the EVM ISA uh and users would benefit from uh from from the the tech the power of SNOX there as well.

161. 1:10:55

     Great. So is this a a good place to to end? I do have one piece of alpha. Uh unfortunately I can't share much but uh I do want to put it put it out. So um when the Google paper came out uh kind of it it sent shock waves because you know we were talking about breaking ECDSA keys in a matter of you roughly 10 minutes at least on the fast platform the the superconducting uh computers

162. 1:11:21

     that was brought down by a factor of two roughly um by ECDSA.fail fail which is this uh this this auto research uh challenge which was extremely exciting and successful. There is another result coming soon which is going to blow the 10 minutes completely out of the water. And I I I think this new result is going to wake up the world including the Bitcoiners and you know move the timelines forward yet again. And one of

163. 1:11:57

     the things that we're doing uh within DFM foundation is revisiting the the straw man road map which is called the straw map and seeing where can we move things forward uh when it comes to the the postquantum road map. Okay. So it will um because sometimes people are coming with the argument that if your uh public key is hidden behind a hash you're safe. So if if we are able to break like say in less than one minute or something like this argument

164. 1:12:29

     is becomes even worse because it's it was already bad like public key are meant to be public maybe maybe a last question for uh blockchain guys uh what's your timeline like realistically for this migration I mean it just accelerated tremendously with what Justin shared how much do we have yeah I mean uh what we're looking at u year and a half probably um we could have started working on on it like

165. 1:12:58

     todayish but like in rolling out the falcon for example but we we need to be careful about it as well and with what concerns threshold signing schemes this remains a very active research area so for for that a lot of research has to happen still in the community like we don't have ideal solutions we have some backup ways of of going forward But we don't have an ideal solution yet. But for securing consensus um roughly we're assuming we have time till the end of the next year

166. 1:13:30

     approximately. Um now I'm not sure now I'm like yeah Justin do we have time till the end of the next year. Yeah I mean step one is to build a quantum computer that has sufficiently many cubits. Okay. Um so probably we do. So yeah, my personal uh estimates is you know 20% chance of Q day by 2030. Um some people are talking about Qday in 2029. Those are like the most optimistic people. They tend to be somewhat biased because they're within the quantum industry building the quantum computers.

167. 1:14:06

     But um you know I would give it maybe a 1% chance at least that it happens in 2029. And that is very scary which is why Ethereum now has this minimum viable roadmap for for quantum where we would be ready by 2028. So it wouldn't be a full uh transition. We would only have um the execution layer with lean sphinx, the data layer with lean da and we will have the consensus layer but only what

168. 1:14:36

     we call the postquantum heartbeat which is the minimum infrastructure for for liveness and security. What we would have to disable if a quantum computer were to arrive for example in 2028 would be economic finality. So, Ethereum is essentially, you know, the only chain that um has economic finality, which means that if there was um you two inconsistent blocks that were that were

169. 1:15:02

     finalized and we could slash at least one third of the validator. So, we're talking about tens of billions of dollars being slashed. You know, if you take a typical chain uh like like like Sana for example, they don't have this functionality. So, we would have to temporarily disable this functionality.

170. 1:15:18

     So it's a graceful degradation and then we'd have to reintroduce it uh later on maybe in 2029. Yeah. Okay. Cool. Very very very interesting. Um and now now I can't wait to see the result you're discussing you're describing Justin. So hopefully it's going to come out soon because I'm sure everybody's waiting with baited breath now.

171. 1:15:41

     Um soon. Yeah. If you DM me I might be able to. I mean just you Dan. Not not the Okay. Gotcha. Awesome. Um, all right. So, maybe this is a good good place to end. So, first of all, I kind of want to applaud uh all the blockchains that are taking this thread very seriously, both Ethereum and Mir and and and all the other parts of the ecosystem. Uh, I mean, this is this is a real danger to the space and so I'm I'm applauding the

172. 1:16:05

     fact that transitions are kind of u uh happening. um that I think it's also very I I always have to repeat the fact that um there is no doubt that the blockchain space will come out of this perfectly fine uh this is like not there's no way in this in that this is going to end the blockchains in any way.

173. 1:16:24

     So Qday by the time Qday happens the transition will have happened and blockchains will uh continue to operate um as they do today. So, uh, so yeah, so I'm applauding all the all the effort that goes into making that happen and, um, yeah, the goal is to keep the chains, uh, secure no matter what happens. I like how Justin says it that, uh, the chain should be secure for for a millennia to come.

174. 1:16:50

     Yeah, that's exactly. So, thank you all for participating and hope hope the audience enjoyed this conversation. Thanks, Dan. Thanks, everyone. Thank you. Thank you, everyone. Thank you.