Bringing Ethereum to Post Quantum Era.

Transcript

Okay. Hi everyone. So I guess if you stayed because the title of the previous presentations which was a very nice introduction for for this talk or do you want to uh have a postcontum signature and if you've stayed and the the title could be changed to no you have it. So we are zenox uh I will briefly talk about ourselves. Uh so we have been funded uh we are stream so Nicolola Baka was the is the father of the nano ledger co-ounder um myself I've been at leger two years ago I shipped the fastest solidity verifier for P 256 because for the previous talks there was some question about the efficiency and

the gas cost so uh I think I can do a good thing because I shipped this two years ago uh it was like a factor 12 that uh that we gained This is kind of the same we we had here. So I think we we are we have reach reached the limits and Simon is one of the author of bund. So what we do basically we we ship things on the on the world chain. Uh so from hardware implementation to onchain smart contracts that's what we will talk about today. Uh and also provide academic research.

Okay. So what is countalips? uh if you if you didn't uh get asleep uh during last Tokyo, you know what it is. So globally they say that Vitalik said you are not uh you don't have to be afraid. You you shall I think if there is a quantum apocalypse tomorrow you should find a banker because I used to work in the French defense and we will have other problems than it if if there is a quantum computer tomorrow. Uh so when when will it uh come? Good question and it depends for who you are.

So basically if you are anc researcher or if your your products use a broad 16 uh it's basically never. If you're a PQC researcher it's tomorrow and if you're average user you're somewhere in the middle but be aware that hold your bag basically is like a polymer market bet on the consum uh consum rising. Okay. So we have talked about uh this quantum apocalypse. Just to separate things uh authentication uh must be solved later uh soon because we want to have everything on shelf to be able to push on the emergency button for this art fork we were talking about. But confidentiality should be solved now. Uh if you use a private payment system such

as radon you are using ECC. The encryption keys the viewing keys are using uh ECDH. So this means that someone recording all the transaction will be able to decryle and get rid of your anonymity. So there is this separation of the urgency between authentication and confidentiality. So as we have talked uh uh before so component tricks are the OA so the private keys uh we we use that are stored in our uh hardware wallets. So notably using DCDSA private payments uh are using in the exo model um elliptic curves the consensus uh BLS signature and the availability samplings. So basic our our road map asex is to solve uh all

but the last point um um which mean we we are not working on proving system but uh on uh these uh signatures. Okay. So good news ARCR has made a very good work uh for us during the hate previous years and clearly they have chosen latises. So uh we won't hard about that. We could debate uh and reinvent the wheel here in W3 because we we love to do this but basically latises has won won this uh this contest for many reasons. Um actually uh the the the problems are relying on we we have now a very good confidence about them and they

provide a very good uh complexities both for for computations and for uh the the bandwidth. So uh for instance if you look at the size of a signature so sphinx uh is uh uh is um 17,000 bytes while for falcon it's six 666 and 2k and half for delmium. So it mean you can have falcon or delium on a code if you want to have syncs on a QR code you will have to uh to use many of them. So it will will not be very practical. Uh so Falcon appears as uh the most suited for or onchain constraints but it is

known to have uh very uh to to give very hard time for integration uh at the hardware uh level for for the for the sinus. Uh and also it provide a pleasant feature compared to delithium. Falcon has an uh recover version which is very similar to how we are using uh ECDSA signature uh in in Ethereum we are using EC recover which allow to recover the public key that has been uh used uh to to identify the the transaction. Okay. So in our road map u we we follow progressive road map. So uh the first step to be able to deliver the smart contract is is performed. uh I provide the uh the link for for your GitHub. So

do not hesitate to to use it. It is pro provided as public goods. There is heten at the end of the week. So uh do not hesitate to use it for demonstrating uh migration transition to to the post postconuma. Next step will be to uh provide a rip uh and merge this into nodes. So we have our uh foret guess implementation then to provide an EIP and in the long term to remove uh to remove EOS because there is also other points of failure for for instance the bundlers uh we forgot about the bundlers okay so this the solidity uh it's working I will talk about the results uh

it it enables cheap experimentation on L2s so even if it's 2 million gas okay you can already use it in prediction Um so step one the hot wallet and we will talk a bit later about the hardware implementation. So those are our implementation results. So this is less mindblowing know that uh Antonio's uh kind of spoiler result. Uh but what we had before was 24 million and some claim that oh it's impossible to um okay to to to have a practical practical result. I don't know if if two million uh is is still practical. It's it's still very very expensive but we

are kind of very confident that maybe you will gain 10% by trying to optimize your contract. But we okay we are two cryptographers. We have used the best entity which is the core multiplication of polomial algorithm the the best algorithm at the state of the heart. Everything is yield. So honestly uh if you went more than 10% on gas it will already be uh be high. We with the AVM um constraints we are using 256 words. There is no vectorization because uh latis computation can be very efficiently vectorized. So there are some hold EIP about vectorzation. uh we it could

totally benefit of the level of vectorization uh we have we have in solidity but for now this uh this 1.8 8 million is like a is like a limit. Um okay. So what we did uh what we did so we were very slightly not compliant to the N standard or at least uh we have a fully N compliance standard at seven 7 million gas. um just replacing the check that is used here by Ketchac uh uh we we drop to 2 millions and actually if we as as Antonio said if we if we had a wall EIP when we bench um at the at the node level the C implementation of Falcon and ECDA it's quite close so the gas code

should be should be the same if if ever if ever adopted and during the past we managed to find some um some tweak uh some trick of of Falcon which is APRVA which uh enable a recover version without having to to make entity inversion. Okay, so small small stuff. Um so those are the results and to be complete we also implemented uh dithium uh which is the other candidate actually delithium for uh nonchain constraint will be the one that will be cheap by vendors uh because as I said for signers it's very uh easier to implement dium than falcon so falcon is perfect for

verification but this is kind of the sense of history uh why do we use zk it's because we want to have fast verifier and we let all the burden to uh to to those providing the proof or signing. So for um I think for Ethereum uh vendors should make their their homework because for for the chain falcon is better but anyway if you want to use DM we provide it as well and it's uh 6 million 6.6 million gas. Okay. So to conclude for um for the verifier so falcoin is four times cheaper than digitium. So that's a good point for to to adopt it for for the IP.

Uh it's very straightforward to implement for the node. Just follow NIST recommendation. Um the EVM friendly version is preferable for the experimentation. So this uh this uh trick of specification using a ketchup instead of check and we also uh proposed uh um an independent EIP which is entity. So entity is a multiplication of polomials and actually if instead of choosing falcon or delitium we adopted uh entity we would be uh able to uh implement on top of it very efficiently uh either falcon falcon or dich and if we look at e recover it's kind of we have taken it the the other way you can

tweak recover to do a point multiplication it's kind of not the way it should be we should use point multiplication to make the signature so So you know in our um perception it would be better to have entity as a building blocks because even if uh specification change or if we have some tweak and we will talk about ZK friendly tweak that we are working on entity could be could be the the way to go. So this is something that we have proposed and um it's um yeah it's 78 85 it's its little name right now. Uh vectorization uh would be very efficient to speed up entity. So there are uh we have had some collaboration with the EVM Max team and

they they managed to have like a very um very high gains. It's kind of hard to separate the vectorization from their compiler that is very effixent very efficient but at least eight 80% G should be expected. So if we had to choose one, EVM max is is more flexible than entity, but it's also more uh harder to to implement uh in the core. Okay. So now now that we have this solidity, we are very happy we can uh already secure all our smart accounts with 437 or 772. Uh if uh if we imagine that at some point we are able to

disable the ZA which is another EIP that should be adopted in my opinion. Uh so now going back to to signers uh so the main constraint as for hardware wallets uh will be the RAM. Uh hardware wallets are very limited uh amount amount of RAM. So integrating file coin into it will be will be a challenge a challenge we we are working on and one way to solve this is to use oblivious RAM. So oblivious RAM is to extend the RAM of the device by using the O memory. So your laptop or your uh your phone and using uh confidentiality and integrity uh mechanism uh on the OS memory you can

extend the RAM and maybe um use this to to to to implement the ser. So this is something we are working on recently ledger chipped vanadium which is a VM. This is another way to go but I think it will be it will be slower. So this is um okay this is the thing one of the subject you we are working right now. Um but we we shall uh ship uh a ser uh hardware signer verification before uh the end of of the quarter. Okay. So conclusion um onchain constraints they should be prioritary.

So, Ethereum should lead the decision not tied to uh what the vendors will uh announce but to the onchain onchain limitation and using oblivious serum or other mechanism. It should be uh it should be possible to to to tweak to to the implementation to to be able to have this hardware hardware wallet implementation. Okay. So we are happy we see that at some point we will manage to have the signers for I didn't say about it but for dich it will be uh it will be possible to do it their papers by NXP they are able to implement deltium in three three kilobytes okay so now what uh what's are the next step so the next

step is to prove uh by proving I mean to have a zikk proof of falcon or delithium because we at the beginning of the talk we we talk about private payments uh So it would allow both uh to integrate this ZK uh version of Falcon or DDTM into a ZKVM allow postum private payments and also um maybe be um another candidates for the consensus consensus layer uh batching of signature for um yeah for the consensus. So there are there are several teams working on this there is Labrador. So Labradors they took it the other way. They they tweak their proof

system to be able to prove Falcon. We are working on the other way tweaking Falcon to to make to make it easier easier to prove. Okay. So what we need to do so we need to to operate on non- native fields and this is what is very expensive. So if you have some um experience about ZK implementation working on nonative fields is called emulation and emulation gives you a factor 100 basically. So switching switching the field is what you can do. This is why what is done by rail gun or by bundle snatch uh or uh the star curve by by starkware but it's not as easy to uh to to tweak uh to tweak a postconum latis candidate than to generate another

elliptic curve. So how to how to introduce a minimal uh tweak in the specification to obtain zk friendly version something we were working on. Okay. So first there are some um very naive uh trick and abuse that you can do. So replace the app function. So you it's using uh so we have been using ketch but kak is not zk friendly. So this means that if you want a z friendly version you replace it by poson or maybe black there was a talk by sware about zk blake implementation this morning. Um there are also some hints. Uh so I mean hints are some additional input you provide to to the prior uh to to the

prover to make it easier to prove. So with APVA we have a um some uh spare computation in the in the ver very verification of of falcon. And another way is to accumulate several steps and perform modular reduction which is something very expensive because it imply division um only only once and there are other tweaks where replacing the fields mean recomputing all the different security trade-off and the proof because there are many uh different problems uh when implementing latis and at this intersection we have to change size of matrixes and we also discovered that falcon will be prone to

overstretch if we use a zk friendly feeds. So for the zk proving uh dich would be a better better candidate. So this is something we are still working on. Um so just to uh to remember for now. So dium is more zk friendly. Um and yeah we are working on this ZK dithium and ZK falcon uh implementation uh that we shall ship uh also uh during next next se uh se semester it's still in the experimental phase private payments. So there are three weaknesses the ECDS that is used in UTXO uh the ciphering for the viewing key and

the proof settlement. So proof settlement um using stark uh you will u solve it. The the problem is the size of the proof. Uh so there are other candidates now there is we think they managed to have 100 to 28 kilobytes. This is still uh like a 100 uh in increase compared to a growth 16 proof. So it appears to be very problematic for smart contracts. Um so peek will break the authenticity and settlements but this should be sol solved later but not the confidentiality. So first if you have to change something in an R gun for instance is the viewing key. the viewing

key shall not use ECDSA from now because it's very easy to replace this by a postconum postconum algorithm for for the viewing key and to resist to a later later decryption but we shall not wait for this and if you use a private payment u okay have this in mind okay so to conclude uh my talk um so there are some quite easy solution for the EOM migration the contracts are there the the gas cost you're able to um to concede will uh guide you in choosing the AVM firmly or the fully compliant versions. Uh we propose this um this EIP um to reduce the gas cost and to be

noticed it would also reduce the cost of start proof because st proof they also need to have some polomial multiplication at their core in the solid digit contract. So this would also benefit to layer two using using stocks. Um and we are still working on the hardware signer. Um um and for the consensus uh consensus layer okay our work is still very experimental. We have no idea what will win between okay ash uh ashbased ashbased signature the the labrador but we we are providing additional inputs and I think it will be very interesting to work with the we team to see if we if we manage to plug our zk version zk friendly version into

into we to provide something for the consensus layer and and that's it so remember all that we provide is uh is open source public good. Uh we would gladly help to uh any wallet dabs to integrate uh it in in in the framework. Um here is uh the GitHub link to to the repo. So the guest fork the two the smart contract smart contract implementations and that concludes my talk and I think we have a little time for questions.