Post Quantum Ethereum Era, implementation results and foresight - Renaud Dubois

Transcript

[Music] Yeah, first thanks Lucas for for having introduced the problem because it was kind of challenge for me to yeah it was kind of kind of a challenge to introduce the problematic and expose the solutions. So now I can focus uh on the solutions that we provide at ZKOX to uh to this problem of uh uh the quantum the continuous threat on on Ethereum. So I'm Renault from Zikox. Um so some word about Zinox.

We're a small venture company uh funded by uh Nicola one of Ledger co-founder father of the Ledger Nano uh myself. So X ledger, Xalis and Simon is our Zika Zika researcher. Yeah. So her missions bring deep expertive and innovation uh to every challenge on the world security chain. So from on the wall uh on the world chain so from user end to end chain. So mainly we that's that's what we um I will talk about uh introducing our results on smart contracts uh postconum smart contracts. So what is contuma apocalypse? So uh Lucas uh

presented us all all the stakes. So basically we are very uh frightened about what will happen to or is or or BTC's but honestly this is very small compared to what will happen in the real life if uh quantum computer uh uh happen to too quickly. Uh basically all the e economy will be down because there is no more uh econom no more um uh no more authentic authentication. So basically uh the good news is uh okay people have been uh uh designing design solutions. So in Ethereum proced which components are at

risk. So uh EOS uh so basically you can scan scan the chain and uh having this uh consum computer uh reverse all private keys. Uh there is a consensus layer. And so BLSure are aggregated uh at at node at n level and there is a uh data availability sampling. So the kg kg commitments and also I forgot to uh to talk about uh the bundlers bundlers are also using uh using hoax uh to to bundle. So whole road map is to solve the first and and second points. So good news are back. So we already have finalist they have been uh

heavily scrutined uh the last the last 10 years now. Uh and um some algorithm have been selected uh for their robustness. Um so the most efficient algorithm that uh um that we have are based on on latises. So looking at complexities uh falcon is one of the finalist with with delium and uh for for ethereum and for the onchain complexities with are which are more import the more the more important um they they have the smaller this is the candidate which with the smaller smallest footprints. So

falcon appear as the most treated for ancient complexities. uh it is known for its signer u complexity of integration maybe this is not this is why it wasn't seated by by Lucas in the previous talk but it also has pleasant feature falcon as an e recover version so this means that we uh we could have some uh replacements of EC recover with a functioning that we would be very very similar and also for the ebredation we were talking about uh it would be possible to have an ebreed candidate using falcon which which is not possible with delithium or or things. So so at zox we we think about a progressive road map. We we we like pro

progressive road maps uh in the terum ecosystem. So our first test is u just use account abstraction. So we have VIP 70702 uh and 437 uh with uh with full solidity implementation uh in the smart contract to to begin to experiment from today. So from today you can go to our GitHub download the smart contracts and uh begin to experiment with postcontum postcontum resilient resilient accounts. Um but it can it comes with a price. uh we we will see uh a bit more uh about it later. Uh so um so the the second step would be to specify uh RIP to have nodes

executing the the contract to to reduce the the gas cost. uh then integrate it uh as EIP and in the long term what we wanted is to remove uh all the ECC based EOA uh because uh um experimenting with 70 7702 uh at first you need an EOA so if you are if your account is passum but you can still use the whole hero uh in the end um it doesn't solve anything so at some point we will have to to remove to remove those um so at first this experimentation we have to make make those on L2s because they are cheaper and this will this is a

this is a run for the the verifier um on the signer side okay so this is very straightforward to have a hot wallet know there are plenty available implementations of uh u postcontum uh postcontum nodu So uh it's it's kind of easy for hardware wallets. Uh it's also challenge. We will see that uh there is some constraints uh that are uh important uh mainly mainly the RAM and we will also see how to solve it. Okay. So straight to to the results.

So we we implemented um Falcon uh in uh in solidity. Uh so this is what we obtained. At first we we implemented a fully compli compliant uh version. So this is 7 million gas uh for one single signature. So this is very expensive and uh this cost can be um dramatically reduced by using EVM friendly EVM uh version which mainly is just replacing the ash function uh which is um check in uh in falcon specification as well as in delium uh by kak which has its op code. So uh

um what happens is that on the 7 million uh gas five of them are spent uh hashing and the rest is for the core operation. So the core operation of latis candidates is entity uh and entity basically is the algorithm that enables to multiply polomial efficiently. Uh this is also a tool that is used for uh starts for instance. So this uh uh yeah this is a tool we will need for postconume uh signature but also also prover. So we'll have a word about a potential heip later. Okay. So we implemented this uh

EVM friendly version. Uh we also have the uh uh recover EVM friendly friendly version. Uh meanwhile we we found a way also to use some some tricks that we use in ZK uh in ZK implementation we have APV which is a recover version we which is actually more compact uh looking at the code because we don't need uh entity and version so that's a an interesting trick to to reduce u complexity of uh uh at the code at the code level so everything uh everything has been yield uh So this is highly optimized. We we there existed a previous

implementation by titration which was 24 million. So we cut by 12 uh by 12 its cost and honestly I think we we did quite a good job and u if you gain more than 10% uh yeah good good luck good luck to to to to go more than 10% be below that. So I think we have reached a limit there. everything is old and it's still it's still expensive. So uh maybe it will be time to to consider our IP if this is too expensive and uh for exhaustive reasons we also perform the uh deletion uh deletion implementation. So here as well we uh reduce the the gas cost uh

dramatically from uh previous implementations and using a friendly EVM version. So here here again replacing check by key check uh we cut the the gas cost bus al but uh deletion is still uh um 3.5 uh more uh expensive uh to verify than than falcon. So this is also an interesting result for uh which candidates should should we should should we choose uh at the protocol protocol level. Okay. So some conclusion. So this was kind of expected but Falcon is uh nearly four times cheaper. Uh it's very straightforward to

to implement uh the ripin node. Okay. Just follow N recommendation. Uh we also uh um implemented a g guess fork uh to um to have your uh falcon pre-ompile. Okay. Um if you want to use solidity friendly version are preferable. I think for interoperability we should not fall into uh what we have done in the past meaning having K check while while Kack is used or using um dedicated dedicated algorithm um should should not be done at RIP RIP level. So the entity itself maybe it could be standardized and we make this proposition EIP7885 uh in order to reduce uh gas cost

because once entity uh once entity is done um uh if you use sketch check on entity uh gas cost is is very very cheap. Um vectorization uh is very efficient to to speed up uh to speed up the entity. So we had collaboration with the EVM EVM max team. So the expected gain should be around 80%. Uh with that result they are mixing uh mixing uh the efficiency of their compiler. So they're even lower but um it's it's more related to to the compiler than the the vectorzation itself. But uh there is also uh an uh anolip about SIMD and it could be interesting to to consider it.

So in the end EVMax EVM max is more efficient uh than entity for for for the result and it's very uh generic but uh it's also harder to to implement in core that a single uh um a single block like entity. Okay. So that was for the onchain the onchain parts. Um now looking at uh the ser constraints. So uh what we see is that Falcon uh unfortunately is very uh expensive in term of RAM and this is a problem for hardware wallets because hardware wallets are very constrained and this makes Falcon very non-trivial to to

integrate. So um vendors should make the their their homework because even if the constraint is high for hardware wallets on chain constraint should be prioritary over those consideration those considerations. Uh but how to solve those RAM limitation? Um so this could be done using oblivious RAM. What is oblivious RAM? Uh oblivious RAM is using the u the host device. or the laptop or the smartphone to extend the RAM uh the RAM of of the wallets. So this require so basically the mechanism use um confity integrity integrity mechanism in the

host memory uh to to extend to extend its RAM. So well it's a long known mechanism uh to my knowledge no hardware wallet implements it now and um okay we were experimenting on this but it should be in the firmware to be really efficient. Uh so an alternative is to wrap Cisco of the EVM. Okay. So basically having an EVM of of the wallet of the hardware wallets but um better DX but slower slower in the end at the final level. So to conclude for the sign part onchain constraints should be prioritary. Uh Ethereum should lead the decision uh not

the hardware limitations. Um so oblivious RAM could solve this and this is something we are working on uh and we expect to have res in the next quarter. Okay. So basically this solves the problem for just replacing the EOA but uh there are other problem. So introducing a new IP means uh it will be a nightmare for ZKVM to to prove it. Uh so uh so what we wanted uh to to consider now is how to prove falcon or uh deletion. Uh it also have um uh an impact if we want to have private

payments such as uh a postconume version of for instance ray gun or zcash. Uh so so we need uh we need this um and also um for uh the consensus uh consensus layer having a replacement for for blets. So u batching uh basically batching uh the the signature with snarks and stacks. So there is two different possibilities. So either tweaking falcon delete to be easy to prove some existing proving schemes S2 for instance or tweak the proving scheme uh to to have it to have

efficient batching and there are some initiatives like Labrador doing this. Okay. So basically the the constraint we have if we want to prove to prove falcon deletion that they operate on non-native fields. So by non-native it means this is not the the field that is used by the proofing system and this require emulation and emulation in ZK is is expensive. So our aim is how to introduce minimal tweaks because we want to to keep the the validity of the security proof of of the protocols. All the work that has been done by the by the community to prove Falcon and Delipian resist resilience uh without uh

so so we want to to keep this but to tweak it to to have it uh easier to prove. So there are some obvious tweaks. So uh namely here as well replacing the ash function by zk friendly a hash functions will dramatically reduce the this part. Um there are some uh some hinting we can do and it's what we've done with avi batch inversion which is required uh inside falcon algorithm. Um another tweak is what we do is we multiply and we don't have to reduce at each step but uh accumulate uh accumulate the multiplication in the entity and reduce at the end. Uh sorry

if if this is Chinese for for most of you. Um and now our tweaks is to uh to modify the spec. So replacing the fields this is not something as trivial as it can be for ECC. Um so this is not this trivial but basically ACC you you pick random curves uh if the order and the twisted row order is prime you're happy you have a safe curves this is not the case with latises there uh there are estimators they are hard to tweak uh for falcon we were not able to to do it uh because there is an attack which is overstretching uh that will not make falcon uh zk friendly okay uh But we

were able to do it on deletion and uh with namely a 20% slowdown factor for the uh the out circuit uh definition. Okay. So basically the conclusion dithium is more ziki friendly than than falcon. Um and we are still in a very experimental phase and this is very dependent on on the proving scheme. So this means that for each proving scheme we have to make a tweak and to uh to re-evaluate uh the the security uh we obtain. So for now we we have investigating with koala beer baby beer and

M31. So okay so to conclude uh so basically EOA uh migration is not uh theoretically uh difficult. Okay. So we have some complexity problem but integrating um some pre-ompile in the node or switching from uh from uh from um from a CDSA to a falcon recover version uh we will we will will do it um we okay we proposed an EIP to integrate entity it will reduce G cost for those candidates but it's also reduce the the cost of the settlement of stack proof uh there There is still some efforts uh

to do for hardware signers. Uh for sure vendors they will lobby for deletion uh because there are it's very easy to implement delium uh in at the serer in the serer side. Um and there is there is a question now shall we tweak the the proving scheme? So this is the way Labrador team for instance is is choosing or the signature algorithm and we we have no final word uh yet. So privacy and batching is still very experimental. Um and if you want to to replace uh uh p to have private payment uh it will also uh require to

have um to have tools um which makes easy stocks with private input uh available and as today it is quite easy to use circom or uh or uh it's quite more uh difficult to to have a stack with private input And okay a last word. So there is a at the end of the week. So we would gladly collaborate or help to to integrate the those contracts for demonstrating things and that's [Applause] it. Okay. Thank you so much. We've got

more than like 10 minutes for the question. So if anyone has a question, can you can you can you pass them the mic? Thank you, Renault. Very interesting presentation. I have a question for you. How confident should we be or how confident are you that the Ethereum ecosystem will embrace the postquantum era? I think I'm quite confident because it appears in purple color in the uh in the road map. So uh will it be the path or will it be ashbased solutions? I don't know. But uh so confident that this

solution will be adopted uh not not that much. Okay. There are quite a lot of discussions but this is this is in the road map. Uh can you talk a bit uh about uh the key sizes because uh because all those algorithm both like falcon and deletum I saw like has have like way larger key sizes than what we use now. Will that be a challenge?

Yep. So I think I provided uh I provided the public key size. So it depends how you use it. So talking about smart accounts, you just have to write it once. So that's not such a big uh uh a big constraint. Uh okay, so private key that's uh the hardware uh the hardware problem I would say for the onchain constraints. Okay, it's uh it's here. So yeah, that's kind of uh for sure that's that's kind of important. But uh if using an account it means that you just pass the call data once and once it is in your storage slot is written

uh once and forward. Uh another question given uh we have we will have account abstraction and uh smart accounts. So basically every account can uh will be able in theory to or maybe in practice already to select algorithm they want to use like for signatures. Do you see like uh some kind of competition there or like some you know like some like uh using multiple different algorithms in practice or you think like that everyone will agree on on one and as long as we are not working at a protocol level the the more choice we have in the implementation and the the variety to

experiment the better it is. Yeah. And the last one you mentioned private payments. Yeah. Uh so uh with current ZKbased solutions like uh like rail gun uh is there a risk that postquantum like this this data like what we have now will be somehow decrypted? Oh yeah. Uh for now if you use um it use a GR 16. So this means that uh you the the the hacker can uh settle any proof. So basically uh but as we are for all EOS we are wrecked.

So basically in postquantum world like what we consider now is private like all this data like all those transactions in rail gun we need to to to switch from uh because right now proof used uh by ry gun is a grow 16. we need to use uh to switch to stack with private inputs. But I mean historical data like what the transactions that are happening right now because they're using like prequantum algorithms. So uh this data like if someone just collects collects can possibly collect collecting is retroactively break the yes yeah for sure because everything is uh encrypted with a um there is also a viewing key. So the view key is broken

if you have postontum algorithm. So anonymity is broken with with the quantum computer for for a gun or the cash because yeah just the viewing key is is extracted the private key related to the viewing key is extracted. Hello again. So my question is as a blockchain engineer we want to make blockchains and gas cost uh lower for making the people more achievable to reach out to more people but with that gas cost you mentioned and the complexities I don't think that it's going to be achievable in short times.

So what's your aim to achieve less gas cost uh for using uh different kind of hash algorithms or any different path that you would like to choose? Yeah, gas cost is is only related to the number of up codes we have to use. But if we use a pre-ompile, the gas code then become just a a direct uh uh relation with the CPU cycles. And actually Falcon CPU cycles is equivalent to ECDSA. So there is a high footprint but for the computation it's kind of equivalent. There are there are large benchmark one one of them is super cup. If you look at super cub benchmark falcon falcon deltiumdsa it's kind of equivalent. So

this means that we we shall have a gas cost around four 4,000 gas like we have for EC recover. So it's adopting adopting a pre-ompile. We'll we'll just reduce the guest cost to something we have already. Okay. Thank you so much. Another round of applause for uh Reno. [Music]