The Other Post-Quantum Migration: Ethereum's ZK Application Layer | Alex Kuzmin | ETHTaipei 2026

[music] Hello everyone and thank you. My name is Alex. I work at Ethereum Foundation uh in the client side proving team where we do some research about how to make zero knowledge proofs feasible on the client side devices. And today I want to talk about uh the other postquantum migration that is necessary for us to keep enjoying uh privacy applications on Ethereum. So since we're talking about zero knowledge proofs uh it's a quick refresher what that is.

It's a cryptographic uh protocol that allows one party that's called approver to convince uh the other party that's called a verifier that some statement is true without um um revealing all the data that went into the proof. So basically you can prove something about private data without disclosing that private data. So now let's talk about um the postquantum migration. Uh today on Ethereum if we take the example of the execution layer um we are using ECDSA signatures to identify ourselves as users of the protocol. So when we're sending a transaction we are signing that transaction using our secret key and our public key is our Ethereum address.

So uh it works because uh there is not yet a sufficiently capable quantum computer that can potentially break the ECDSA cryptography. So what happens when uh that cryptography is broken by a quantum adversary is that that quantum adversary can actually forge transactions that look uh absolutely like uh they were sent by the user. uh but uh the user didn't authorize that so that quantum adversary can spend the user's funds and this is really undesirable right so uh what we need to do is that we need to migrate the signature of the transaction to a postquantum uh signature scheme and then we are safe as as users right but um let's uh think about the payload of the transaction So even if the protocol has upgraded its cryptography and secured its transactions, it doesn't mean that u the payload of the transaction and let's say the cryptography of the applications on Ethereum is upgraded automatically. So uh in this example uh you can see that if the payload of the transaction is for example zero knowledge proof. So maybe you're withdrawing your funds from a shielded pool.

If that zero knowledge proof is also using a prequantum classical cryptography, then a quantum adversary can just forge that zero knowledge proof and uh again spend your funds uh but uh if the spending is authorized by a zero knowledge proof. [sighs and gasps] So uh who is responsible for uh this kind of migration? uh here uh the work should be done on both ends. So first of all of course the applications themselves need to upgrade the cryptography that they are using uh to uh postquantum cryptography and uh of course we can also ask Ethereum to do something for those applications because historically it has been doing it before for u for the classical cryptography. Uh that's why we have for example pre-ompiles for elliptic curve operations in Ethereum that allow us to uh conveniently use zero knowledge proofs on chain today.

Um so first let's talk about the protocols. Uh what's the current situation with the cryptography? Uh can we can we have uh postquantum secure zero knowledge proofs? And the answer is yes because there are enough um there is enough research going on in uh postquantum cryptography. So there are three main directions uh isogynes uh lettucees and hashbased cryptography.

Um they're not all equally mature. So isogynes is a more like newer thing and uh hashbased cryptography is uh an old thing that's very well studied and uh the assumptions it relies on are considered to be one of the most conservative and uh let based cryptography is uh also well studied but the assumptions are a bit newer um and that's why we are going to explore the hashbased uh cryptography in the rest of today's talk and also this is the current choice of Ethereum um like I mean it's not the 100% uh final decision but currently um Ethereum is exploring uh the postquantum upgrade with hashbased cryptography so u there is some uh ambiguity in the terminology about hashbased snarks so colloally uh we are very often using a term stark to just uh designate like all postquantum hashbased cryptography. Uh this is not uh exactly valid I would say because Stark was a name for a particular zero knowledge protocol that has its own paper. It came out in 2018 and since then uh the uh field has evolved dramatically and the newer constructions that are hashbased and postquantum they don't quite resemble they they have they share something in common with that stark but it's not the same thing but uh for simplicity in the rest of my talk I may interchangeably just uh call those things uh hashbased systems or starks just because stark is for it. Um, so let's talk about the performance of those starks.

Are they good enough? Like can we just use them and be sure that they are not worse than those previous zero knowledge systems that we are familiar with. Um, so our team has been running uh the client side proving benchmarks uh for quite a while already for maybe more than a year where we are uh tracking uh various snarks in a convenient dashboard. So if you're cur curious, you can go to that address and explore the dashboard yourself. Um but as you can see, um the situation looks quite good in terms of raw speed for the Starks.

Uh and they even tend to occupy the top of the charts here. Uh so at least uh speed wise, we can be sure that Starks are good. But uh for us as users of privacy protocols uh some other things matter as well and those things are the RAM footprint of those systems and also the bandwidth and the bandwidth here is important because um for some of those zero knowledge proving systems uh you need to download quite sizable files to just simply start proving. Uh maybe some of you who are familiar with protocols like Groth 16 or CIRCOM uh language, you know that it has those uh infamous Z keys that you need to download and they can be like hundreds of megabytes. But again here we can see that Starks are doing quite well.

Um many of them do not require too much RAM and fit perfectly within even a mobile device budget. And also uh many of them do not need uh that large pre-processing artifacts. Uh so you can just distribute your uh zero knowledge app even maybe over a metered mobile connection. But uh unfortunately there is a a downside to the Starks and that downside is the proof size and the complexity of verifying that proof. So as it turns out, this is the cost you are paying when you are using that hashbased cryptography that is postquantum secure.

You're paying the cost of having a proofs in the range of sometimes up to hundreds of kilobytes. And uh also the verifier is not always u uh particularly friendly to putting it on chain. So we did a very concrete experiment with that. We uh wanted to see what is the cost of verifying maybe one of the most modern starks uh on chain uh in a little bit more detail. So we took a construction protocol that is called were it's a relatively recent paper from like two years ago and u we instantiated over a small uh prime field and measured the gas cost.

It turned out to be quite high uh like three uh almost 4 million gas and this is only the polomial commitment part of the whole snark. This is not the whole uh snark cost like uh because when you're verifying the whole proof, there is also another part of the uh snark that's called the interactive oracle proof part that would add more logic in your solidity code and you would have to pay for that some uh extra. So can we do anything about that? So if that cost of a single verification is high uh maybe somehow we can try to amortize that cost. So we kind of put more actions into one verification and pay uh only once but divide the cost among those users who are like sending those actions that we want to verify.

So one way to do that is uh so-called recursive aggregation or recursion. So first let's take a look at what's going on when we are verifying an individual proof of uh snark. Um we have a circuit that defines some kind of uh relation or computation that we're proving. We're just providing an input to that circuit and the prover is producing the proof and then the verifier can verify that proof. Um but if we think what is a verifier?

Verifier is also a program. It's a computation. So what we can do now pay attention to the right side. We can simply put that verifier computation inside the circuit. So our circuit now is not proving some kind of uh statement uh but it's a pro it's actually proving that uh we know uh some proof let's call it a child proof that satisfies the statement of the verifier of uh this particular snark.

So the parent proof that we obtain here it guarantees the validity of the child proof. uh this way uh we can uh go one step further and we actually uh verify multiple proofs inside one circuit. So here in this example we're verifying uh two proofs in one circuit but of course no one is limiting us uh and we can verify even more. So what what's going on here is that uh when uh we are the in this way we're uh reaching that root uh we can be sure that when we're verifying the root proof we have uh proved also the validity of all the incoming child proofs that were uh there on the left on the leaf level. Uh so if we have n of those proofs uh the cost per proof will be just the that final verification cost divided by n um which is much better than just paying that cost alone for a single um action or transaction.

So uh we also wanted to um see the concrete numbers uh can can we do that successfully like what what does it cost? So we uh took our client side snark uh this spartan were and uh we used uh linvm to um try to uh do this recursion of that child proof into the root. LINVM is uh developed by our colleagues and uh it was meant for uh that actual postquantum upgrade of Ethereum but it has some uh very like common common building blocks with our snark. So it was a natural fit. So what we discovered is that uh the root proof in this case uh costs more than 10 million guests to verify.

And if we try to compare that to a typical let's say privacy protocol uh maybe if if we're emulating a withdrawal from a privacy protocol like privacy pools uh that would typically cost around 500,000 gas. So to get to the same cost per action in this case or per transaction we need to uh batch or aggregate around 21 of those transactions. um which um looks okay. But the caveat here is that uh you can do it uh easily only if your application architecture allows uh for that aggregation because uh you need to wait to aggregate and uh the actions in your application should be such that they are they permit uh aggregation and uh of course that aggregation should happen somewhere are not on chain and uh not on the client. So it means that there is some uh intermediate layer of aggregators which is also an architectural tradeoff.

So um can we so now we can see that yeah from the application side we we are probably uh done with all possible um options. So let's see what Ethereum can do for us to facilitate this postquantum migration. Um since there are pre-ompiles for ellipticers uh operations then maybe what if we can make some pre-ompile for the hashbased snarks uh and we also did an experiment uh the continuation of the pre previous one uh with the were PCS where we wanted to see okay is there some repeating operation in that uh verifier that we can extract as a new pre-ompile in Ethereum and how much gas uh could it save? So it turned out that uh the saving is um very very small and uh well not not actually not not that small but the resulting cost is still quite high. Uh but um the problem here also is that u even if you come up with some pre-ompile uh it doesn't necessarily mean that it will be useful for everyone besides your application.

So there are some standardization concerns uh and uh like broader usefulness concerns. So what uh the protocol ultimately can do for us is to move the uh verification entirely uh outside of the EVM and uh there is a proposal for that that's called EIP8288 that is built on top of frame transactions and it um defines a new type of a frame transaction that can carry uh stark proofs and um uh let's take a look at what the architecture of an application will be uh using this IE EIP. So from user perspective nothing changes we still need to produce our zero knowledge proof uh with our private data on the client side. Then when we are sending the transaction with this proof uh transaction first gets into the mempool and the nodes they're processing meleool aggregate uh our proofs into a recursive stark. So they produce a single proof of uh whatever uh number of transactions they could aggregate during a certain time and when the validator is including a block into the on the blockchain the validator should only uh verify that final proof.

So the heavy lifting here is done by the meool nodes that are aggregating and uh the smart contract uh knows that when the transaction has reached it, it is already valid. So the proof was verified outside of the contract. We can take a closer look at the contract. So that new type of frame will uh have dependencies. So the contract needs to read those dependencies and then check that first of all okay this uh frame contains a start proof.

Then uh the start proof is actually corresponding to our start of our application by checking the checking the verification key. And finally just make sure that the inputs that went into that proof are uh the data that we are now working with in this particular transaction because the data hash field in that frame will be the hash of the uh public inputs that went into the proof. So um if we summarize the options today uh for the builders. So if your application needs uh deployment before those protocol level changes arrive then uh you need to choose whether your application can actually aggregate those uh uh tolerate those aggregation tradeoffs and if yes then you can uh do the recursive stark aggregation and verify uh in EVM. If no uh you can consider verifying individual proofs directly although for a much higher cost and uh if uh you can actually wait for the protocol changes then uh maybe uh like at at some point uh we will have the convenient uh recursive stark aggregation inside the protocol.

We are actually conducting some benchmarks. Uh and our benchmarks show that um yeah it is possible to aggregate but uh at the current technology uh you cannot really have a ZK proof inside every transaction that you want to include into the block because like today you can have uh a couple of hundred transactions inside one block and if you assume that all those proofs arrive at the same time uh you only have 12 seconds to build the block. So probably you will not be able to include all of them in there but maybe a few dozens but the technology evolves quickly. There are new snarks uh that lean VM keeps improving. So uh eventually I think we will have u better performance.

Yeah, this is uh the the current the the current work in progress on the benchmark. uh you can uh track that space. If you're curious uh in a couple of weeks uh there will be fresher data and uh this concludes my talk and I welcome your questions. Does anyone ever know we go?

Um, you mentioned the pre-ompile can help the gas to verify the the the proof and I I was just wondering if there are other approaches that you guys had in mind that can help as well to reduce the gas cost at the moment. Um besides the arithmetic optimizations, not really because uh like that code in our experiment was already heavily optimized for those specific operations that happen in uh Starks. So if you reach that ceiling by just optimizing by reducing the amount of that solidity smart smart contract code then like you [snorts] just need to look elsewhere like outside uh of of that. Yeah, I see. Uh another question.

So you mentioned there are several meools that aggregate um transactions and would the meools aggregate the same transaction. So probably they um the proof contain like like two proofs might contain the same transaction or something. Would that be a problem? Uh so yeah so first of all I need to correct you there is only one mempool but many nodes that are building uh building blocks from from the meool right so uh eventually that single stark proof will be included with the block so every block will have a recursive stark proof right so in the block uh we already solve that like we don't have that problem today because like every transaction in a block is unique Of course like your block builder cannot include like same transaction twice into the block. So the same applies to those proofs uh that are attached to transactions.

Yeah, it not every transaction should have uh that proof attached, but uh ultimately the block proof, the recursive start proof that's included in the block will only uh have like dduplicated uh proofs in it that correspond to certain transactions.

Okay, I see. Thank you. Um, I had a question regarding the um, you guys are doing the client side proving benchmarks, but um, it feels like these like the the whole presentation you guys talked about could actually be done by server side proving. Is that correct? or like or is the assumption that people would be proving on their clients and then sending the proof.

Yeah, this this is a great question. So, if you think about uh Ethereum today, uh we can even do things like home staking, right? So, and people who are homestaking, they're running pretty average hardware. I would say it's not Ethereum doesn't require uh GPU farms to to just validate itself, right? So in this sense for uh that recursive aggregation in the meool we we would like to keep it as um how to say as uh as little demanding as possible so that uh you wouldn't end up needing uh GPU farm just to build Ethereum blocks.

So that's why uh this is still relevant to the client side because client side of course is a broad broad term but uh usually we assume some kind of hardware that is like an average hardware that a normal person may may access. Uh yeah

I oh one more question um so I know the client side proving that you guys are like the benchmarks you guys are doing are mainly uh you guys are benchmarking like signatures and hashes and I think that's it, right? It's just like the hashes. Yeah, just hashes and then ECDSA.

Um, is is that like what primarily you think would be necessary for client side proving? Cuz like

a lot of other provers are trying to do like full VMs, but do you think that like what's only necessary from the client side is actually just hashes and signatures?

Well, we need to separate the workloads and the systems. So in terms of workloads, you are right. We are mostly benchmarking hashes and signature schemes like ECDSA and there's a historical reason for that. ECDSA is because uh a big application of client side proving is ZK ID uh like zero knowledge identity. when you have some kind of digital ID maybe even uh government issued or another kind of identifier but you want to prove to another party in zero knowledge that yeah that is you that's your identity uh and there in those applications those conventional signatures are widely used but in terms of hashes we are testing many popular hashes and in the next uh instantiation we will take also to test Blake which uh is getting even more popular also for Ethereum.

So uh we are already testing uh VMs in here. You can see many of those systems are actually VMs. They are not like marked in a special way because they are all like eventually doing the zero knowledge proving. So for a user user should be agnostic of whether it is a VM or a snark. Yeah.

All right, thank you very much. I'm sorry this is all the time we have for Q&A. If we have further questions, please feel free to uh talk to Alex later on. Um but we do have to move forward with our presentations. Thank you very much, Alex.

That was wonderful presentation. [applause]

Thank you. Thank you.

[music]