zkSummit14 - Live Stream

Transcript

All right, welcome back to the main stage. Uh, our first speaker for this session is Tal and he'll be telling us about scaling Zcash with Tachon. Take it away, >> Tal. >> Okay. So, hi. Uh my name my name is Tall. I'm a cryptographic engineer uh working on Tachion and uh I'll talk about scaling Zcash. >> Oh sorry. Um so uh I'll give a holistic update into Tachion uh what it is what what how the construction works uh and

then a semi-technical overview of REGU um our proving system and PCD toolkit uh and then some applications that REGU enables for Tachion. uh things like uh shielded transaction aggregation uh pruning uh the nullifier set uh via thirdparty intermediary uh we call an oblivious syncing service um and some other cool applications that I think are unique to Tachion. Oh, >> I think it's just >> next. Okay. Uh, so at a high level, uh, Tachion, um, Tachion is many things, but

it, uh, in some sense realizes the, uh, vision of recursive composition uh, outlined all the way back in the 2019 Halo paper. Um, Tachion basically enables recursion, which enables blockchain scalability. um the recursive capabilities of Tachion don't currently exist in the Halo 2 library and they don't exist in production in Zcash in any capacity. Um which I think is a like a good data point that that outlines like the sheer complexity of trying to inject scalability into a privacy solution and private payment systems

like Zcash. um because the Halo paper came out in 2019 and only now we're trying to do some kind of recursive composition in Zcash. Um so uh Tachion is the uh fourth shielded pool in in Zcash's history. Um it's it's basically a protocol upgrade in the same lineage as uh Sprout, Sapling, and Orchard. And there have been many upgrades in between. Um, Tachion is uh a scalability upgrade and uh it positions itself purely as a scalability upgrade. Uh all of the these shielded pools have uh something called

ledger indistinguishability. Uh it's a security notion where you can't distinguish between uh different transactions in the shielded pool. They're basically just opaque bte strings. Um and Tachion uh maintains that uh uh that ledger indistinguishability property. Oh my god. Uh in terms of uh scalability challenges, um all well um anonymous payment systems derived from zeroache or zerocashlike protocols basically have the same scalability

challenges. They have uh uh the shielded sync problem. Um so you can't query a public-f facing remote RPC. Um all client client devices and wallets need to uh download um uh they need to download all of the uh uh cipher texts for every node payload and trial decrypt that node payload to discover a payment. Um there's this idea of transaction bloat. So uh the proofs are quite large.

They're a few kilobytes in size which bloat the transaction which then bloats the block. uh you also have this nullifier growth problem. Uh so you have runaway state growth um as the nullifier state becomes uh becomes large um and tachon solves all of these problems or it will solve all of these problems but I'll I'll try to motivate specifically the last one this nullifier growth problem. So a nullifier is basically just a revocation token. Um it's a byte string um to prevent double spends. In Zcash we store nullifiers in a B tree set. Um and there there's a paper by Sean and Ian called uh a note on notes towards scalable anonymous payments via

evolving nullifiers and oblivious synchronization. Um they give a they give an example in this paper that at 100 TPS uh the nullifier state grows by about a gigabyte per day. If you then extend that and you shift the overton window towards commercial payment systems like Visa, then the nullifier state grows by 500 gigabytes per day. And that that's obviously unt untenable growth. you we can't expect a client device to have the bandwidth capabilities or um the compute capabilities even near that scale. Um so nullifier growth is a problem as the as the TPS grows. Um it grows proportional

to the number of transactions. Um this is also uh state growth. Oh, thank you. Um this is also state growth. Um there is a dist distinction between state versus uh history growth. Um if this was history growth uh that might be okay uh if eventually Zcash becomes like a Mina style blockchain and we have a succinct uh blockchain comprising of one proof and you can just do away with all of that history. Uh but again this is state growth which means uh all full nodes need to maintain this set and query this set. um uh all validating consensus nodes need to maintain this. So it it's

uh it's a bottleneck um as as you increase the TP TPS. Um so uh I I will as an aside also just highlight uh uh the cost differences between anonymous payment systems and uh non non-private payment systems like Bitcoin. So in Bitcoin um and the paper talks about this as well. Uh you only have to check a UTXO status and uh uh verify an ECDSA signature. In Tachion we have costs that are comparatively a lot more expensive than that. Um like verifying a zero knowledge proof um is much more expensive than checking uh an

ECDSA signature. Um and again we also have this nullifier growth problem. So uh our costs are much higher. Uh so the the solution that the paper outlines is this notion of an of an evolving nullifier. So it's the idea that nullifiers evolve uh over time. And in Zcash now uh nullifiers are uh associated with uh uh a note commitment. They're deterministically derived from a note commitment. But in Tachion, they're not uh deterministic anymore. They're associated with an epoch. Um so uh evolving nullifiers uh effectively split

the ledger into a collection of epochs and uh to to prove that that a payment was unspent or uh that a note was unspent, you you basically prove that all of the versions of that nullifier are also unspent. Um and we can outsource this check to a third-party intermediary uh that we call an oblivious syncing service. So the client device doesn't do this. This third party uh OSS does this. So what is the oblivious syncing service? Uh it's a technique that allows a remote service to prove on behalf of a client that their funds are unspent. Um it does many

things but uh at a high level it generates a succinct proof that uh it generates a succinct proof for uh uh non-membership uh for nullifiers. uh the client device can uh um okay I I won't go too much into the complexity of of what the OSS does because Sean has a very nice ZCON 6 talk on this but at a high level what what the OSS does is it it syncs syncs notes and it syncs witnesses on behalf of the client and Um uh I guess to build a

mental model of of how the wallet interacts with this OSS uh the wallet starts up it generates some nullifiers and uh set non-inclusion witnesses. it can hand this off to uh the third party oss. The oss can sync those notes and update update those witnesses and then the client device can take the uh the um this evolved nullifier and and uh uh the PCD proof that the funds are unspent and and fold that via PCD into their transaction. Um again it it does a lot more than this. This is just a high level uh summary of of what it does, but

Sean has a good ZCON uh Zecon 6 talk on this which uh I'll leave just for a few seconds if you want to uh if you want to watch that talk at some point. Uh find me after I can hand out this QR code. Um so how do we go towards scalable planetary money? um we want to maintain some bounded state. So uh full nodes uh should not need to maintain this uh perpetually growing nullifier state. Uh ideally you can prune that state via the OSS. So you don't need to maintain all of uh all of the history of nullifiers on chain. Uh you only have to

maintain the latest uh state of nullifiers and check that they're uh unique in the latest block. and you can prune all of the um all the the rest of the nullifier state. Um we want shielded aggregation uh the the idea that you you can uh uh reduce transaction bloat by recursively combining proofs uh which uh uh increases the block capacity. Um and we we we want every uh node to to be a full uh to be a light full node. So uh that enables succinct blockchain constructions. Uh the light clients

become full nodes. Uh the idea of a full node in this context is um instead of uh syncing the whole chain, you can just verify a single proof that the blockchain history is correct. Um so so what makes Tachion different from other pools? Uh this can be a talk in and of itself but I I'll motivate a high level idea of what the distinction between our pool is and previous pools like Orchard are. Um in previous pools you had uh a very tight coupling between uh the shielded protocol and the payment protocol. Uh so the key structures were uh pretty complex because they had to do uh they had they have had to have um a lot of capabilities baked in like spends

and incoming uh and outgoing payment detection. Um Pachion effectively decouples the shielded protocol from the payment protocol. So the so the shielded protocol is uh for snarks and encryption um and the actual cryptography and the payment protocol is um a different design space for things like addresses the UX key exchange um and and the nice thing about decoupling them is you can work on them at the same time. So we're building uh we're building the recursive proving system and PCD uh toolkit in the shielded pool and we're also working uh with a very talented team uh led by uh Dave Oja um and they're working on many

kinds of problems like uh a postquantum UX uh post quantum key exchanges uh things like P to um kill shielded sync um and and so forth. Um so Ragu um at a high level is our uh proving system and PCD toolkit. Um it it's one of the main components of Tachion. It sits at the heart of Tachion and does all of the heavy lifting. Um so Reggu specifically is a recursive snark. Um it uses an accumulation scheme uh similar to the one defined in in the Halo paper. um and and it uses that accumulation scheme to

instantiate an efficient recursion uh scheme. Um so Halo defined uh this notion of uh nested amortization. Uh nested amortization is a um uh it's a uh aggregation technique loosely speaking um instantiated over a polomial commitment scheme based on inner product arguments. Um so REGU is Halo plus this uh BCLMS21 idea of split accumulation. Uh so Ragu uses uh accumulation in the sense that uh instead of uh uh instead of verifying proofs we can fold them together uh

using um uh linearly homorphic Person commitments and we can combine them using fiachamir um and then you can accumulate uh various kinds of arguments based on uh expensive polomial evalu valuations and many other kinds of arguments. Um, and you you can defer expensive checks and then you you do a decision procedure at the end that does the expensive linear time uh verification. So, we're just accumulating tons of expensive claims and verifying once at the end. Um, this is also the same underlying cryptography uh that exists in Halo.

It's the same primitives from 2020. So, so we didn't invent any new crypto. Uh, we're using battle tested primitives that were uh that we're very familiar with. Uh, and and Sean has a good blog post on REGU. Um, in terms of the core architecture, uh, this is an R1C like arithmetization. Uh, it's R1CS like in the sense that it's a boodle style arithmetization. Uh, like Sonic and Halo. Uh it we have a cycle fold style uh folding and accumulation scheme. Uh we have a modified IPA uh modified bulletproofs IPA for the commitment scheme. Um it's a custom IOP so it's uh custom RO1CSORC

uh using split accumulation and IPA style commitments. Um and it's instantiated over the pasta curves the palace investa curve cycle. Um in terms of the curve cycle approach that we took um there are two kinds there there are alternating and non-alternating. So alternating are like classic IVC where you bounce between the curve cycles and you maintain a proving system on both but you um only operate on one at the same at any given time per PCD step. Uh then you have lopsided. So you have one curve that that's used to uh just get around the curve cycle. Uh so one of them is a helper. Um but you still

bounce between the curve cycles. Uh then you have nonalternating. Uh that's things like cycle fold. Um so you have one curve that handles all of the scalar moles. Um so it does the folding and then you have the other curve cycle that uh does the main circuit logic. uh Ragu is effectively a hybrid between uh between um cycle fold and lopsided. So we maintain simultaneous state on both curves at the same time. So we're not bouncing between the two curves. Uh we're operating on both curves at the same time and doing work on both. Um so both curves have a full proving system.

um it has lopsided influence in the sense that the two curves are symmetric but they're workload asymmetric. So cycle fold is maximally asymmetric. You have one curve that does just the scaler moles and one curve that does the full uh the f the full uh circuit logic. So it's maximally asymmetric. Regu is also asymmetric but not as not as asymmetric. Uh so it's it's a combination of of uh different cycling approaches. Uh in terms of the arithmetization um this is an R1C like arithmetization. Uh we don't have any uh complex uh uh uh newer uh machinery that new folding

schemes like nova or cycle fold use. Uh we don't have multilinear polomials. We have just univariate polomials. uh we don't have lookup arguments, no custom gates, no highderee gates. Um so it's a very simple arithmetization with univariate polomials. Uh we also don't have any pre-processing. So uh pre-processing in this context means uh something like marlin or plon where you commit to a fixed collection of polomials and you embed those commitments in in a verification key and then you can open like kg commitments um against those pre-committed polinomials.

So so we we don't do that. We actually have a post-processing approach uh which is different than that and I think in our context more efficient. Um we we also don't have any verification keys. Uh so um we we don't need to launder verification keys between the recursion circuits. Uh we don't uh reason about the full R1CS matrix. So we don't materialize the full set of R1CS constraints. Um we we have these light lightweight uh circuit objects and evaluate the polomials at partial restrictions. But the full R1CS matrix is never evaluated in memory. Um we don't evaluate polomials directly during

synthesis. So we we we want the uh reduction to polomials to be highly optimized and again not store large polomials in memory. Uh we can uh we can take advantage of of memorization. Um so we have this notion called a a routine. Um so if the same subcircuit appears multiple times like the same endoscaler operations or the same Poseidon hashes uh you can effectively memorize those operations. So um the uh uh those operations can use this the same polomial and uh it's it's effectively a scaling rel relationship.

So instead of recmputing the polomials you can just shift the polomials and memoize them. Um uh we also need highly efficient circuit synthesis code. So um circuit synthesis is a hot path that we need to optimize for. Um if you look at something like arc works uh they bundle witness generation and constraint synthesis. Uh we we don't do that. We we have witness uh witnesses are uh optional depending on the uh synthesis path that we take. Um so so in arc works uh it's circuit synthesis is consist consistently 25 to 30% of the proof generation time. Um I haven't

fully benchmarked what it is in our system but circuit synthesis does need to be um highly optimized especially in a non-uniform PCD setting where you're switching between nodes in the PCD graph uh very often. Um so the uh the optimization trade-off uh I guess a natural question is like how does Reggu compensate for having such a simple arithmetization? Well, it's it boils down to the things we actually optimize for. Uh we optimize for verifier speed uh which scales with the size of the circuits not the number of circuits and we also optimize for um uh the uh the option of the number of circuits we can

choose per PCD step and we want that to be large. Um don't know how much time I have so I'll just skip some stuff. Uh so why do we want smaller circuits? Well, uh it means smaller witness commitments uh which leads to smaller IPA proofs which leads to uh smaller verifier multi-exponentiation. So we want the verification to be fast and that's what we optimize for. Um we also want verifier the verification to be fast uh because of things like propagating transactions or um like black block transaction times. So uh like nodes need to verify before

forwarding and if the verification is slow then at some limit that can equal network latency. So we want the verification to be fast and for block times uh verification time uh effectively puts a limit uh floor on how low the block times can be. Um uh there's also this notion called a recursion threshold. Um it's uh the minimum statement required to perform recursion. So when a proof system is fully succinct um so meaning the proof size and the verification time are sublinear uh the system can verify its own proofs. Uh we have a recursion threshold of 2 to the 11 gates. Um

it the verification scales with four n linear constraints. So we're doing a 2 to the 13 MSMs. Uh we have this concept called a a registry polomial. Um so you can encode all the circuits uh in a single polomial. Um and then you you can evaluate the polomial at at different roots of unity over a domain and recover um the specific circuit polomials. So we instantiate this uh trivariant polomial m wxy you can evaluate that at some root of unity and recover the uh bariate sxy um uh we we eval there's a post-processing that we do to this polomial. So we we we

evaluate this polomial at a set of points that overdetermines the polomial. um and then we can take a registry digest of the polomial and uh embed that as a constraint in our polomials during polomial evaluation time. Uh so if you tweak the polomial degrees of freedom if a malicious actor tweaks them uh that will change the polomial evaluation which changes the uh the registry uh well it changes the registry key constraint which changes the polomial evaluation. So you you can't know ahead of time what the polomial will evaluate to uh because any change will again modify that polomial.

Uh we have this notion called a staging system. Um so usually you commit to uh uh the full witness uh with staging uh and this is a known technique. Uh we can commit to stages uh uh we can commit to witnesses in partial stages. Um so uh a stage is is a collection of wires uh that's shared by multiple recursion circuits. Um and and uh they they can share uh they can share those stages. uh it's used in two contexts in our proving system. Uh you you um you can commit to each stage independently and absorb commitments and then you can squeeze

challenges uh from those commitments. So you can absorb interstitial commitments and squeeze uh challenges. Um we we also use it to reduce hashing. So if you uh if you need to encode like n things in in a fiair transcript uh you can put those in a stage um and uh uh commit to that stage. Uh uh we we call this a nested commitment. So you're committing to one thing instead of end things. Uh I don't have a lot of time so I'll skip this. Um we or maybe um uh so the the thing we actually defer

are uh wellformness checks uh verifying that the nested staging polomials don't overlap that the wire sta the wire stages are non-ontiguous um and we defer all of the scalar multiplications um okay quickly talking about uh applications you you have this uh this um the obvious application is a shielded aggregation. So instead of putting n transactions in a block, you can recursively compose them uh into a single transaction.

Um the oss can use this uh recursive capability to uh um to to generate these nullifiers and and to update them over time. uh in in in the whole construction of tachion we're we're probably not going to have uh any Merkel trees uh we have um uh aid to PCD um that's dynamic depth but we don't need any like spe special set accumula accumulators it's just a hash chain um the main technique uh that's not highlighted here it's called polomial oracle access so it's this idea that the application has access to the underlying univariate polomial

commitment scheme and it can open uh the commitment scheme at any point the application needs and you can build like uh very complex um um IOPS that are generic that don't even have to be snarks uh you can build IOPS for things like volatile memory checking uh to uh check um that uh an application accessed memory correctly and the shielded protocol uh can use that to um to check things about nullifiers and commitments. Uh we we're also uh form formally verifying parts of Reggu. Um we're working with ZK security to uh integrate their clean framework their lean DSL

against against Reggu circuit API. Uh as of now as of this morning we do have a blog post um on this. uh uh quickly I just again postquantum can be a talk in and of itself but I'll just give a quick quick summary uh so uh we are postquantum today in most cases uh because we uh uh because we we do use symmetric primitives but to be fully postquantum sound uh we need to uh uh we need to move from a elliptic curve based PCS to a lattice-based PCS and if if you look at the lattice literature they're um uh they're settling on polomial commitments. Um so when um when Zcash

has uh postquantum prim primitives, we can just swap the PCS. Uh in terms of encryption, uh we we'd need to go from elliptic curve chems to postquantum chems uh MLEM and postquantum signatures. Um, we have a ton of like postquantum resources like a podcast, a road map, a thing called quantum recoverability, so like freezing the shielded pool in the event of a quantum adversary. Uh, we have a blog. Um, we do plan to have a protocol upgrade and a test net uh sometime later later this year. Uh, this is our team uh Sean, myself, Connor O'Hara, Alex Giang, and L Winslow. Um, and then, uh, we do have a website,

tachion.zcash. Um, and tachonzcash, uh, is the GitHub if you want to learn more. Uh, and if you have any questions, email Sean. Uh, thank you. >> Thank you very much, Tal. Unfortunately, I don't think we'll have time for live questions, but Tal, will you be available for questions offline? Yeah. Amazing. Great. Our next speaker is Emmanuel Ragnoli from Provably and he's going to be telling us about uh snarks or not snarks for databases.

>> There you go. >> If you stay within this line to stay on this >> and then the pointer is there. >> One, two, three. >> Hey, the last talk before lunch. Yep. So uh I'm going to talk about databases and especially the idea of having expressive and modular databases. This is work that has been accepted at ACMCCS 2026 and it's work between myself Vincent Sabota Simon Bottoni Mat Campanelli and Alberto Tromba and it's collaboration

between uh Prov Technology our startup of chain labs the university of Tartu the University of Warso and the University of Insubria and we don't have a timer here right Okay. Uh now usually you start with motivation. So uh the typical one why did we do it? Because we liked it but also because it's quite important to have a verifiable databases especially in this era of privacy AI and multiplication of data. So uh databases as a matter of fact around the world they are sort of considered you know the poor stack of the uh IT framework but as

a matter of fact it's where uh data sits uh all the time there is a bit of echo by the way over here yeah okay um they are important in financial system scientific data social platform government records and most of the time they are outsourced so and that creat creates what we call the trust problem. So and the trust problem is uh we trust the provider of a DB with our data to do uh two jobs. The first one to stir the data correctly and the second one to execute the queries correctly. So what happens if the um uh database provider lies of there are some bugs or if gets

compromised. Verifiable database is an idea that was uh uh already authored by Ostro Rakovven Smith in uh 2024. I don't remember exactly the title of the paper but something like efficient computing etc etc. But the idea of Ostrovski at all was the client holds only a short digest delta DB. Uh for every query that the client does to a verifiable DB, the um the data owner, the uh database provider attaching a succinct proof pie that is verified then and then the verifier

verifies with delta DB. The query gives an answer the proof pi and then the answer is accepted or rejected and if this is rejected some misbehavior is called is is caugh. What is the what was the overall goal and the important goal here is that the proof needs to be succinct. It needs to be non-interactive and the verification must be public. Why non-interactive? because we are not really doing a streaming or a line etc etc most of the time is a static entity uh that is hosted somewhere why it matters in practice because especially for financial reporting

uh regulators required regular reporting of data but also of statistical analysis of the data for example to the SEC uh for data market aggregators uh untrusted aggregators just needed to certify SLA style claims like the record has been updated in the last 24 hours for blockchain oracles and analytics like offchain data must reach a smart contract and then automatically import it into the execution of the smart contract and after proof that have been untampered and anywhere that there is outrage storage that meets analytical queries

Simplicity matters too because uh simpler designs are easier to audit, easier to maintain and historical less vulnerability pro. What is a verifiable database? It's really uh for uh um probability polomial time algorithms. So we have a setup uh usually the typical tow setup etc etc for a case ag that is actually what we use uh the setup produces a proof a a a public a key for the prover and the key for the verifier there is a prep-processing algorithm in in which uh inputs like uh the prover

key and the database outputs a commitment a digest of the database and the state that is on the server side. Um a query is then run. Uh the answer to the query is given as a with a proof of pi and that is then verified. We then accept or reject. This proof needs to satisfy the requirement of completeness. That is if I have a honest server, the verifier accepts uh the answer uh always. Uh soundness that is if the adversary makes the verifier no sorry no polomial uh time algorithm uh adversary makes the

verifier accept the wrong answer. And last but not the least it needs to be succeed. So that is basically the size of the proof of the proof and the verifier time are N O of the size of the answer plus the query. This is very important. Uh we want succinctness in terms of verifier and proof time and we don't want that to be dependent on the database side size because databases tend to explode.

So what is the state-of-the-art and the contribution? There are two main families of verifiable databases. Uh one that comes from authenticated data structures. Uh under these basically u past works have been using uh cryptographic primitives like set accumulators, vector and polomial commitment and merkel style trees. It is simple. it's well understood and the state-of-the-art best prototype code base etc etc was integrated that was published in CCS uh 2015 and then recently

uh general proof systems uh especially from the ZKP area entered the arena with the snarks JKR some check uh zero knowledge VMs they are highly expressive what do we mean by expressive ive it means that when we do a query to a database we want to be it to have the possibility to be as rich as possible in terms of SQL and uh um examples are uh verifiable SQL zksql punoglyph db uh products of lrange action axiom and space and time both the families come with non-trivial drawbacks

So the limits of prior ads based system especially integrb is that they use a lot um set accumulators. What is a set accumulator? A set accumulators is a cryptographic primitive that essentially proves that an element belongs to a set. Uh so integrb uh composed uh set accumulators with an authenticated interval freeze. Now the issue with this is that a database is not only a set. A database is a composition of row columns alignments etc etc. When we consider that only with the set operations then for example we lose a multiplicity. So

for example if I have the element 10 that is in row five column six and then again it at row 10 of column six with a set accumulators I lose the fact that the element is uh reproduced two times. Um to do that uh I need to increase bandwidth and to uh play tricks with the set for multiplicity and that leads to the proof in growing in size. Uh and normally this leads to quadratic preprocessing and storage in terms dependent on subject to the number of

columns. There is also limited expressivity because I cannot combine columns in a row aware way again. So I'm just proving that the element exist. But for example, if I want to do the if I want to prove that that the sum of two elements is a certain value, that is an issue because the element was counted only once. And uh there is also an issue with the range proofs because for example, it's very hard to prove that I selected certain elements for example bigger than a certain value. Integrity DB solves that by using an authenticating interval trees. But authenticated interval trees

then uh imply the fact that the proof eventually grows with the size of the database. That is not one of the diserata that we had for um for verifiable databases in terms in when we talk about the other family. So the limits of general power post approved systems we have issues with complexity zero knowledge VMs uh require instruction decoding memory consistency segmentation recussion final snark compression there are a lot of moving parts there is a burden in auditing because uh creating circuits based on that that replicate

SQL queries etc etc require uh the circuit normally to balloon and explode. And so there is a lack of simplicity that tends to increase uh the uh the the threat vector when it comes to security. Now when we started this work the answer that we wanted to have was can we keep the simplicity of authenticated data structure while pushing experivivity and performance like we have in general proof systems.

So uh we came up with a new uh verifiable databases construction uh that that is built from simple authenticated data structures in which we combine vector combinments and the set accumulators. It's more expressive than prior ads based work. The proof size is independent of the databases size. It's no quadratic prep-processing or storage and the order of magnitude is a fewer line of code than ZKBM based uh VDBs. Uh a lot of fewer lines and we also create an abstract framework to express that in also also in order to

make it modular such that we could basically swap in and out um the cryptographic primitives. We wrote it in in Rust. it can scale to millions of hours on the laptop. Technical overview. So this is how we constructed it. Uh we have a polomial commitment like a case ag uh basically that gives the digest of the DB and guarantees that the DBs that is claimed to be is the one claimed to be. Uh we want to do operations that uh are satellike. So does a certain subset belongs in DDB etc etc. So we

have the set accumulators but compared to integrated 3DB we don't do the set accumulators on the elements but the indexes of the rows. This is very important because it allows us to do a lot of operations like range proofs that were not possible before in ads type of structures and then we needed to do operations sorry we needed to prove operations like sum average etc etc all the SQL type of aggregations and for that so basically we use uh linear map vector commitments uh with the inner product tricks and um we build everything with a compiler. Uh and uh

uh I'm going to skip this. I already talked about this. Basically uh for example, let's consider a sum query. Uh like I want to select uh the element such that the sum of two times the price plus an extra fee as s from a database that is called price info. So the idea is that I treat each column as a vector that I access via horra endle. So in the prep-processing the client receives a slice end p the price and another one that is extra fee. The server sends the claimed answer that is x sum of 2bi plus xi over all

the eyes. So the client uses those handles to form h= 2 p + x homorphically because that's one of the properties that we include and it accepts it if and only if the inner product of that results with one is equal the sum that has been claimed. Why is this interesting and exciting? because this was not supported by the previous ads structures like in integrity because as we said already so set based are really hard to achieve the combination of columns uh row by row the cryptographic translation of this

abstraction is so I have the two um vector commitments sorry the two commitments cmp in which I commit a vector uh under prk of P and CMX in which I committed vector again under PRK of X. The prover erh answers s plus a proof ps that has been computed using openly uh of uh um the linear vector commitment map. And the verifier takes those homorph does a sum of the commitments under homorphism and accept it if and only if the uh verification under linear u verifier key

ch1 s uh ps is equal to one. So basically each idealized handle is replaced by an algebraic commitment and each idealized test by a few few uh uh cryptographic pairings. If we introduce also a a filter like where so we want to select the elements that uh are bigger than a certain value. Now that's where the set accumulator comes in. So now the set S is the sum over a subset X of the number of the rows. We cannot send X in full because if the DB is very big then uh you know

the proof becomes linear in the size of the DB. That's again something we didn't want to have but we want an a succinct digest of X and that is the set accumulators. Now the verifier must check the test is in the sum of p on the indexes in this uh set handle and the set handle contains only and only the indexes with pi um bigger or equal than 100. The trick to do this is that now we need a vectors and sets to talk to each other. They are two different type of commitments. We need them we need to be able to compose them.

The framework that we built this as I said before is abstracted from the cryptographic primitives such that we can swap them as eventually and modularize. So we have two opaque orable types that replace the physical access to the data. Think of them as a sort of immaterial pointers. So if you are a verifier you get these immaterial pointers. You don't get the content of those. They just map basically to the to to the data in the data sets. the slice handle that points to a vector and the set handle that points to a set. The verifier never stores the underlying object and they capture the essential abstraction for uh VDB's blueprints and they capture succinctness and they

closely follow SQL flavors. So columns to slices and row sets to sets. It's a little bit what happens in with the polomal IOPS for snarks. So we created therefore an a a framework with a limited set of operations in a risk style interface. So we have a set of set operations like two sets are uh uh the unity the intersection the inclusion the complements. We have test on slices basically to replicate arithmetic operations using the inner products. We can get a new slices from homorphism and we can read the data with

the pre-image style uh of of maps. Um I'll skip this because we are running out of time. So um once basically the uh verifier received the SQL query now it has to replace each handle with a commitment. So the slice vector slice replaces is replaced with the vector commitments and the set slices is replaced with the set accumulators and each idealized test becomes for a set test an accumulator proof and in our product is mapped to open lib in LVC a read it's a sub vector

opening again in LVC and the omorphis on the slice it's a verifier local on commitment there is one missing primitive as We said before we want sets to talk to vectors. So a way to test that a slice is a zero on an accumulated set of positions. And again this helps with range proofs. So uh we created this what is called the zero testing in which basically given uh a vector commitments a set accumulators and the proof we want to convince the verifier that vj is equal zero for all the js that are supposed to be selected by the query. Uh

the construction theorem is in the paper uh properly proved etc. But informally basically we use the trick that each row index generate a quotient polomial x minus s that makes vanishes on s if and only f if and only if z ds such that pv etc etc and uh this is a sound because of zipel so the typical I sent uh I I I tested with with the random values and it's absolutely improbable uh that the opposite happens.

Um we then have compilation theorem in which basically uh if I have a query family and that meets a succinct idealized VDBs then there exist a succinct cryptographic VDB for Q from either a holorphic VC plus a set accumulator with the right test or any extractable homorphic polomial commitment. We have basically one blueprint that allows many instantiation and again because it's abstracted we can swap the uh cryptographic primitives and we can even put in uh latis based polomial commitments like the ones of one tree in their 2024 paper

um um >> three four minutes >> then I'll skip this so there example of queries and how they realized um I'll just mention this. So all the operation that we have done up to now basically support static databases. Uh but uh because L LVC is homorphic basically the vector commitments can be updated incrementally and that basically means that VDBs can support updates and proving that an update happens.

Of course uh this cannot be done in 01 in the public verifiability settings but uh our the experiments that we have done up to now support the case that updates are practical for common patterns like insert delete and single cell updates. H this has been implemented in Rust with Arc Works MBLS 12381 uh multi-threaded prover single threaded verifier benchmark. It scales really well to million of rows on a simple laptop. We don't need a GPUs. Uh it's uh it's a it's it's it's a it's it's a middle layer middle layer middleware layer that plugs

in into any uh a lot of existing databases. Uh these are more or less uh sorry these are uh the experimental results that we have in the paper. Um and that show that the proof size is independent of the size of the DB as we said one of the this is the data and it depends only on the query type and the response. So for example we can see there that a complex query like a Q match um so gets a higher verifier time uh uh etc and uh um the scalability is quasi linear uh the verifier is essentially

constant and uh I'll skip the comparison summary as well and uh I'll uh um what we have shown basically is that we have built something very simple ads based uh it has an abstraction layer the framework is idealized because there is a separation of concern and for instantiation and it's simple modular performant and uh extremely easy to audit thank you very much manually do we have any questions Hi, very nice talk. Thank you. Um, I'm

assuming because you're committing to the database that that commitment must be stored somewhere. Where are you planning to store it and share it? Is that something you've thought about? >> It's on the data owner side. >> Thank you. >> Thank you. Any other questions? Oh, everyone's hungry. Okay, so with that, we'll thank Emanuel once again. And we can now head to lunch. Um, we'll resume I think at 2 PM. Thanks.

>> Sorry. Okay.

I hope everyone had a nice lunch. We're going to start with the afternoon talks. Our first talk of the afternoon is by Vivian on ZK. Please take it away, Vivian. >> Thank you very much for the introduction and hello everyone. My name is Vivian Placencia and I'm the CKID team lead in PSC at the the Foundation and I will be talking about the CK work we have been doing in research and engineering. So let's start.

So CK ID is the short version of zero knowledge identity and it's a way to prove things about yourself without revealing any other information and you can prove things like you're older than 18 or your residency country or things like that. So the siding team has been working on some projects. So here you can see some of them and one of those is the anoadar project is a CK protocol to prove atar ids in a privacy preserving way. Another project is CK PDF and this is a project

where you can prove content about a PDF without revealing any other information from the PDF and we have been working on a lot of standard efforts like we work with the W3C and ETF div Linux Foundation and more recently we have been working on the profile for the C document and I'm going to talk about that because it's also related to open IC which is a a new conk generic construction that there is a paper and I'm going to also talk a bit about that too and another work we have been doing is on revocation which is a

very important topic in CID and I'm going to also cover that. So the main motivation for open IC was that SDJWs are not unlinkable. So that's what is used for selective disclosure and they are not unlinkable because they will generate you will get the same proof every time you you you use it. So the that's the main motivation for the creation of open AC and open AC is a generic CK construction it's uh it's the mapping to EUDI high it map maps the EUI high level requirements

of annex 2 and the construction is modular. It means that it has some some blocks that you can change if you want to make it postquantum and I'm going to talk a bit about that too. And there are different formats for credentials and there is a specific layer for that. So it's not attached to a specific format. You can use the format you want and not trusted setup is required is using Spartan. So yeah, not trusted setup and it's compatible with existing identity system. So not the issue doesn't need to change the the the signatures or anything like that. And in

this link you can find use cases for open AC and more information. Open AC provides unlinkability in credentials. So you can create CK proofs and then people like no one even if the verifier collude with another verifier. So they won't be able to link the proofs and it supports device binding which means that that the issuer will issue a credential to specific holder and then also with the verifier when the holder created SE proof. So it supports complete device binding and it now supports not in the paper you like in the paper you will see it mentioning but

in the first version of the construction it was focused on age verification but now it supports generalized predicates and I'm going to also talk about how we implemented that and it supports so far SDWT and MDL and M do and the current text S tag is circumspan and hyrax. So this is the architecture of openac and this will happen in the holder device. So the general idea of the and the flow for a credential is the issuer will issue a credential to a holder and the holder will use it to with the

verifier or the relaying party and then this process will happen in the holder's device and the proof generation will be divided into two steps. The idea of this is to make presentations more efficient so that the proof generation will be very fast. So in the first phase is prepare and then in this phase there will be some preprocessing and parsing of the credential and verification of signature. So this process is completely offline. So it's it doesn't need to be done at presentation time. That's why presentation time is more efficient. And

the show process which is the second one is the one that will run at presentation time and is where when the holder will prove the predicates and the things that the verifier needs for verification and there is the this blind process to to prevent linking the the the proofs. So here you can you will see the unlinkability So the first version of the project contain age verification. So in this second version of the implementation it contains generalized predicates. So in

the paper you will see this be you will see that this exist but in the implementation and also in there is not that we didn't have a solution for that how we were going to do it. There are different ways to to do it and I'm going to talk about but first the predicate. So a predicate is a when you want to prove something about the credential like for example you're older than 18. There are also other predicates like like range proofs like you want to prove your income is in a range or also membership that your residency countries in a list of countries or not membership the same thing like your residency

country for example is not in this list and you can also prove more complex expression like you have been working for two years or more and and your annual income is in this range. So you can combine things and make it more like difficult and and more expressive too. So that's a predic case and that's what we were trying to solve to have more expressiveness and there are different ways to do that and one way could be to to have the set of predicates that you want and create a circuit for that and solve each one of them like okay I want range proofs then

I'm going to create a solution for range proofs and the same for membership and then you will each solution. But the problem with that is that it's not general like it's just for those specific cases. Another solution would be to create a language a new language like a programming language for that and then you will have a parsing and all these things like the HT3 like everything like a compiler for that language and then is more complicated but uh is better as a solution. So for us since we are using sitcom and we don't want to complicate things or make it less efficient then we did this solution which is the mix like it's in

the middle you can get a lot of expressiveness but also you can get um all these use cases. So I'm going to explain how it's done. So the flow will be you have your expression and the expression can contain parenthesis or everything. So and any logical expression it supports any anything related to loal expressions then the expression will be turned into a simple sequence is a postfix notation. So I'm going to also talk about that and then it will be checked and the verifier will know if it's true or false without knowing anything in the middle and here you can read all the document

and it contains all the details. So for example here we have the claims like date of birth the income the country and then you want to prove this expression. So you see that it contains different predicates and also parenthesis and what we are going to do is to take this expression and convect it that's an infix notation and convert it to postfix notation. So we will use shuntingar algorithm. So that algorithm you can use it to it's usually for math expression but it also work for logical expression and you can use this algorithm to evaluate the expression

with parenthesis and everything or you can use it to convert to postfig notation and in this case we are using it to convert to postfit notation because we want efficient efficiency in circuits. So it's more efficient to go from left to right to to check everything and then we don't have to we have the expressiveness of the parenthesis but we don't have to manage parenthesis in the circuit. Then how this is done is that there are also two steps here and the predicates are with you are a greater than and things like that comparing things and

then the in the second part with this logical expression you have and or and everything related to the loical operators. So having this predicates then they will be evaluated. So that's the first step. take all the predicates and evaluate them. And then the second step will be to evaluate the full expression in postfig notation. And so the steps are like you in the first step you have already true false and everything. So now you just have to with your expression you just have to evaluate that and then it will be like a stack.

You like the shunting algorithm it works like like that. You read the first in the expression. You read the first predicate and in this case is true. Then you push the true and then you read the second predicate because it's the next elements in the expression is also true. You push true. Then you will go to the end and it's a logical expression. You will take the last two elements and evaluate it. Evaluate them and push the result. And now you will have true there. And then you will read the next token which is false and and then the other one is or you will pop both and then evaluate that. And we have true as

the final result and that's what the verifier will know. The verifier won't see the other things. They won't see if one was true or false. They will just see the final result. So that's the solution with this for predicates. But apart from that, that's the solution for open AC for to avoid predicates because before it was just calculating the age and checking if it's older than 18. And then another thing we work on was revocation. And revocation is a very important part in for identities and it's the process that allows an issue to invalidate a previously issue credential with so that verifiers can check if that credential

is valid or not. And we did a lot of research on that and mainly focus on mercuries. And here you can find the the article with all the benchmarks and all the details and everything. And we collaborated on that with the a report with the div uh team and here you can find the report. So more people work on that too. And as a solution like as a summary takeaway main takeaway from this research was that non-membership proof in a list of robot credential is the most efficient way because the force

there were two solutions. One if you prove membership in a list of valid credentials and then it means that your credential is valid and the other is is if you prove non- membership in the list of provoke credentials then it means that okay it's valid because it's not in the list of revoke credentials. So following that then the next step was like what is the most efficient Merkel tree for non-membership proofs and then um we needed to to use that right for revocation then we want to integrate this fee and then we needed to find that and there are two popular solutions for non-membership proofing

mercuries one is sparse mercur trees and the other is index mercurries And we wanted to have like an efficient way. And we know that SMT is actually very popular, but the tree depth is really long to prevent collisions and it's uh not super efficient if you want in CK. It works well, but it's better to not have this depth if you want to use it in Cay. So, so then we wanted to have like a more efficient solution. And in this case in index mer tree is actually very good because you just use the tree depths that you need and you don't need like this long tree depth and that's why

it's kind of like for CK a more efficient solution and at the same time index mercury is using a normal like mercury with specific depth and for semaphur some time ago we created the lina which is an efficient three for membership proof and in this case it doesn't support no membership proof. So we needed to find the most efficient way from me from membership proof and also for non-membership proof so that we can get the best from both world and that will be the most efficient three for non-membership. So that's uh we created a lin plus which is lin with the non-membership feature

and taking the efficiency for from the lin in the tree creation and then taking the non-membership feature the efficiency in non-membership feature from the index mer tree. So you can find here the implementation and more information. So this is a normal lin but in this case it will have the feature of no membership proof. So if you want just membership proof just use the normal lin but if you want the non-membership proof you can use this one and so how it's done usually in for n membership proof you need where you're proving like in

membership proof you prove that your element is in the tree. How you do that? So you know that your h your element is is a leaf. So then you have the mer proof and you create the fruit and it's the same fruit as the tree. So everything is fine. But what's the problem with non-membership proof? So how do you prove that? So the idea is that you should be somewhere in the tree in the leaves and you are not there. So that's the general idea for the SMT. It's like your index should you should you take your index and you should be a specific position and you are not there that value is not there. So that's the way it proves non-membership and in the case of index mark tree the way they the

it will be done is that you have h the the lift will contain the value and the next value and then your value should to be there it should be a leaf and if you know if you know that there is a leaf with a smaller value and the next value is bigger than yours then it means that you are not there. So then you will take the membership proof of that specific leaf. So we do the same like we took this from this idea from there because for non-membership proof you always need a way to have sorting or something. So then we don't take the other elements we will just

take the value and next value. And there is this auxiliary node for to prove no membership for this the first element you insert. So that's the tree we will use for revocation and that's that's more efficient that normal non-membership proof trees and apart from that we also we also started to work on the SDK so that people can easily integrate the solution. So this is a work in progress. We plan since we are adding more features, we plan to add more features to the SDK as well. So just for you to have an idea of how it

will work, but this is a work in progress and we will continue adding more features to the SDK. So from the paper you can see benchmarks also in the resources I'm going to share to you can check the latest benchmarks but you will see that this is for age verification just like in phone and you will see like proving time prevent time verification time so this is fine for real world usage so so yeah it's like pretty efficient So what's next for OpenC and CK ID? So now we want to integrate multivvc

linking and also issue hiding so that in the multivcyc linking so you can link different you can get expressions and from different credentials so verifiers can ask about different credentials issue hiding is the to hide the issue to the verifier because sometimes that's necessary and also the open profile so open is one of the solutions for the European EUDI wallet. So we have been working to create this profile because it will be added to the Etsy document which is the document containing this specifications. So so yeah we have been working on that. So you will see this

soon and we will also work more on developer experience so that is easier for people to use it. Right now there is a demo and web like a phone and with SDK you can use it in web but we want to make it easier and also there will be a new version of the paper with this latest research and when we finish with multivy linking and more like easier hiding. So we are we plan to explain all that too in a new version and we have been also working on a bit on postquantum openac. the work will start uh soon like more work but we already started a bit on that because the idea is to have an postquantum open AC and

that's uh since open AC is modular we plan to to migrate all these modules to be postquantum and we also want to explore public registry the ID infrastructure on Ethereum so we want to work more with ID teams working on Ethereum and to see how we can help. So please if you work on something like that, let me know and contact us. So I would love to help more on that. So you can see the C the CK road map here and it contains this these elements.

So here are some resources. So open AC studio is for like for you to see use cases and this is the paper I was talking about. So check check it out. And this is the GitHub where we add all the research and documents. So thank you very much. And if you have any questions, please let me know. >> We have time for questions. Yep. >> Yeah. So what will be the use case of the implementation of using the open AC SDK? like let's say I have an IDP which is an issuer like how do you see uh

using the open AC SDK in an IDP that it's issuing credentials just to understand uh this scope. >> Yes. So open AC is more like generic for any credential and so it's more in the it will run in the holder and for use cases it will be like the age verification. So if your credential contains your date of birth for example, you will be able with this you will be able to prove that you are older than a specific number without revealing your date of birth or any other information in your credential and then the verifier will know that you're older than than specific number but without knowing anything additional >> and does the SDK needs like any external connection or web three connection or

something or a specific deploy contract or something like that just to >> no not contract now and we did actually some research on that but Spartan yeah so there is not very fire onchain and it won't probably be efficient but that's something that we also would like to have but so not no not contracts >> okay perfect thank you >> I think there's another question over here yeah >> hey um I don't know if I missed it but you mentioned unlinkability and revocability Uh is there also something against replay? So like let's say I have a credential uh I use it to generate a proof that I'm 18 or more. Uh what if I

give my proof to someone that is not 18? Can they verify or there mechanism that prevents these kind of things? >> Yeah. So I device binding. So you this system will make sure that your proof was generated in the same device that the issue used to issue the credential and then the verifier will verify that. So yeah >> more questions. No. So with that let's thank our speaker once again.

Our next speaker is going to talk to us about security and computers and billions of dollars. Please welcome George Kadanakis. >> I just >> Hello. Hello everyone. So, I'm George. I work on the Ethereum Foundation cryptography team. And today I'm going to talk about uh the work we've been doing on securing ZKVMs.

Um yeah, this is a teamwide work. Uh the cryptography team has been working on this. It's not my work, but still I present it. So, yeah, let's move forward. So, I I think I should motivate a bit this talk. Why we're talking about ZKVMs? The answer is that uh ZKVMs are veh wait just to explain why we're looking at funky images. Um I'm uh well everything the images are all from Rome. Um so you can go around the city and see um I don't know like the sculptures and the things. Um, I'm not Italian, so this doesn't make much sense, but still like

I'm just the aesthetics are Rome inspired. So, yeah. Anyway, let's continue. So, yeah. So, where was I? So ZKVMs um are particularly nice for Ethereum because um blockchains are fundamentally bottlenecked in the sense that um you know validators of decentralized blockchains at some point they're not able to follow the chain if it gets heavy enough if it gets big enough if enough transactions are in every block. So ZK proofs and ZKVMs flip this around and it essentially allow um validators to verify a very succinct proof very fast and essentially follow a

very heavy chain very efficiently. So it it basically resolves one of the fundamental bottlenecks of blockchains and that's why Ethereum is so interested in ZKVMs all of a sudden. Anyway, um moving forward, uh ZKVMs have been an interesting topic for years, but the performance of them has been a big question. So, um a bit more than a year ago, um the Ethereum Foundation started looking at like the performance of ZKVMs to see if a ZKVM can actually prove fast enough to follow the Ethereum chain. And this was

a blog post that was done that sort of set up some goals in terms of performance, in terms of prover costs. And the answer after lots of months of the teams working on it was a very big success. like you know prover costs dropped uh many x's uh prover um hardware costs dropped a lot like like basically uh through this real-time proving initiative um the zkms on L1 were derisked and it stopped being an issue of performance anymore and I think now it's more an issue of security in the sense that we know that ZKVMs can

prove fast enough. But the question is if they can prove secure enough. And it's a good question to be honest because I don't think it's like a um a stretch to say that ZKVMs are an extremely complicated like cryptographic object to the point that I don't think humans know how to deploy such complex objects on the internet right now. I I I think it's probably the most complex cryptographic object that is seriously being considered getting deployed. And the security um repercussions of of it getting hacked are huge in the sense that um if if you hack the L1 ZKVM, you can

essentially do an illegal state transition on Ethereum. And this means that you can do many many bad things as yeah it's it's basically a huge issue. So we need to think about security seriously and this is a talk on the security of of how we think about security of L1 ZKVM mostly on the proof system layer on the polomial commitment layer not so much on the implementation side or on the formal verification side. I think it's worth doing a talk about the holistic thing but this talk in particular is going to be focusing mostly on uh proof system and you know like the foundational layer stuff. Um

Nico I don't have um timer thing. There is no timer. Okay. >> Okay. Okay. Okay. Um all right. So um in the beginning of this year uh we did this blog post which basically sets again some limits some goals for how we see the proof system security going forward and it's going to be an initiative that lasts this entire year 2026 and it sets up some goals. So I'm going to talk a bit about these goals and then I'm going to talk a bit about what we it's May now so a few months have passed. Uh so I'm going to talk a bit about the journey so far. Right. So um the first goal is to um is is for

ZKVMs to get to 128 bits of security. Uh this doesn't seem like such a controversial goal in a wider industry sense because the wider cryptographic industry thinks about 128 bit security as the normal thing. You know like when you think about ciphers symmetric crypto everything is tuned to 128 bit but ZKVMs have been traditionally allowed to exist in like 100 bits 80 bits 80 bits conjectured security which I'm not even going to touch so much right now on so like you know like like like basically we have given like a bit of an

artistic freedom to ZKVMs due to them being so complex But now we sort of want to take it back and be like you know this is serious stuff. Ethereum is a serious uh business like you know like security of Ethereum is serious business and also you know like if we want ZKVMs to be to find product market fit outside of blockchains like I think the other industries will also want 128 bit security. So this is the first goal. Uh the second goal is that if you have looked at ZKVMs uh they're usually all they all have this very complex

recursive structure where you know it's not like just a simple IOP or whatever like it's like a small proofs recursed recursed and then you get a final proof after lots of complex architectural thingies. uh what we want and this you know like we know how to prove the small components but we don't know how to prove the entire thing. So one thing we want out of this project is by the end of the year to be able to have a security proof for the entire thing. Um which we believe is going to illuminate lots of hidden details of the proof

architecture that are currently hidden. Right. So that's the second goal. And the last goal in a sense is that we're doing these things now because the proof system layer is the foundation of the ZQVM. So if we get serious about the foundation foundational layer and it freezes and it oifies because it gives us what we want out of it. This will allow us to start working seriously on the layers above which is implementation formal verification these kind of things that we we're currently working on. But I think when the bottom layer is frozen,

it will give us, you know, we we can we can invest more because we know that it's not going to change. So yeah, these are the three goals of this year's security sprint. And now I'm going to talk a bit about um you know, it's May now, so a few months have passed. So I'm going to give like a bit of a of of of of what happened. Can I have a a bottle of water? Ah, any time. That's good. Thank you. Let's do a small.

Right. Okay. So, so we're going to go a bit on what has happened so far. We're going to go a bit in layers. So we're going to start from you know like the bottom like the more mathy foundational layer and we're going to go up and up and up. Um so and a bit also like on a urgency layer in the sense that the first things we're going to talk about we have sort of solved them already but the last things are still kind of open. So anyway let's get started. So um on the math layer um all the hashbased ZKVMs rely on a thing called proximity gaps which is a very niche thing and it

basically it's like math theorems on how error correcting code code words behave when you combine them or even more interestingly how error correcting code non-code words behave when you combine them like you don't want to take two non-code words and combine them and get another code word. I mean it's very niche and I'm not going to get into it but it it these sort of theorems are extremely important and it's basically what this whole ZKVM thing is based on and the theorems that sort of define how these things behave were introduced a few years back and in some extremely

prolific papers. But then you know there was like a theorem and then next to the theorem there was like you know there was like oh it it behaves like this and this is a security proof of how it behaves and then next to it was like a conjecture that said we cannot prove this but it probably behaves also like this and we're going to use this conjecture as our security of our system because by using this conjecture you get lots of security for free. So you know like a system that is 60 bits of security on the provable theorem side can be 100 bits of security on the conjecture side. So you know people started using these conjectures

and when one person uses this conjecture all the other people are forced to use this conjecture due to the industry being competitive. So we ended up in a situation where last year um projects were offering you know like 80 90 100 bits of conjectured security and this was all fun and games until you know like uh one paper came out that started digging hole into the conjecture. Then another one came out then another one came out. Then another one came out and you know like basically at the end of this of last year essentially the conjectures were attacked so hard that

it was extremely hard to uh rely on them and they're still getting attacked like I could there's a few more papers I could stack on top of this but uh essentially I think one stance we took in the beginning of this year was to sort of only look at provable security which is what you improve the theorems and this stuff. So this was sort of the beginning of this uh security sprint journey to focus only on provable security.

All right. So that's for the math. Now on the sort of um a bit above like on the proof system layer on the protocols um so when you look at ZKVMs uh and you and you know they they say oh we have this security we have that security and you see how they compute that security level they each ZKVM has its own way of computing it they have their own soundness calculator one is written in Rust the other is written in Python. The other is like some section on the readme like you know like every project is computing security differently and that made it very very

hard to compare apples to apples and and we had to compare apples to apples when it comes to L1 stuff because like you know we're a neutral base and we need to see like we had to be able to compare projects. So what we did naturally is make our own soundness calculator uh which is universal and you know like uh you can plug any ZKVM into it and get the soundness of that ZKVM and so you it's it's called sound calc you can find it on GitHub and then it outputs a table like this that I have not made nicer sorry about that but

basically you know it has the open the ziki AVMs in the left and then how many bits of security and expected proof size. And it sort of it might not seem like it by looking at this, but it sort of makes it easier to compare things and and to and to get a better idea of where things stand. Um yeah, so that's another thing that happened in the beginning of this year. Um and we're sort of in a good position right now. Now let's let's go into things that we're in a less of a good position. Um so right so uh there is this thing called pose. It's a hash function that is very nice to be

used in recursive contexts and zkms are recursive contexts. All the ZKVMs use recursion and if you use recursion, you want to have a hash function that works well with recursion and PON is one of them. And the AF has launched the Poseidon initiative a few years ago which basically gives grants and bounties for people to attack Poseidon and people did attack posed and now people uh especially this paper from ETHZurich they broke Poseidon in some way like they didn't break it exactly in the sense that the security level did not change but still

some fresh attack vectors were found in Poseidon that Antonio talked about earlier today and it basically made us more distrustful of Poseidon. So now the question is um how to think about this how to think about Poseadon going forward. Um we don't have excellent answers for this yet but we do have ideas and yeah that's another thing that happened this year. And finally going to the sort of like top layer of architecture. Um when you think about ZKVMs, this is sort of how things look like. Like you have a recursive architecture in the bottom layer. You have all these small proofs

that you have like a huge statement. You chunk it. You take small proofs, you recurse them, you get smaller proofs and then sort of in the in the top of the thingy, you get like one tiny proof that corresponds to the entire execution. This is like a classic ZKVM architecture. And this is nice, but like when you start digging more into it, you see that like you know this nice thingy is actually much more complex. Uh there is like between these nice boxes, there is abstraction leaks between them. There is global memory arguments. There is global things going on. um um you know projects

that are using hashbased snarks also use an elliptic curve argument to do global memory checks or other projects that are hashbased they use latises as subprotocols and and this is very hard to understand like very hard to to illuminate and to to to sort of map out when you're investigating a ZKVM because these are like very tiny details that might matter in security. So this is this inherent complexity of ZKVMs is what we've been trying to tackle this year. And one one one one way we think is is a good way to tackle it is to sort of

provide the framework that allows teams to formally prove the security of their ZKVM like like of uh of of this entire thing like we humans are pretty good at at at proving the security of these boxes the individual boxes but not yet that good at proving the security of this entire thing for many reasons. So we hope that by the end of this year we provide a framework where teams can use to to get a more overarching security proof of the entire thing.

How are we doing this? Plenty of Okay. >> Okay. Okay. Okay. Right. Okay, so these are sort of the things that are happening um on the various layers and has happened in the past months and like sort of looking forward in the rest of this year given the goals we have is um well to to start with a positive sentiment. One thing is that we know that 128 bit security is achievable and it's achievable with a reasonable proof

size. Uh we know that because uh there is projects like ZISK that have gotten to 128 bit security already by using a very granular recursive architecture and by hardcore optimizing the heaviest circuit. So we know there is ways to do it. Um we also know that other projects can do it using a multilinear proof system where you know like you have a big table and instead of uh treating each column separately which adds lots of proof size you sort of do like a multilinear trick where you consider it as a huge column and then you can still argue about the individual

columns. Anyway, like there is techniques that we know of that can get to 128 bit security in a nice way and this is a positive thing for us. Um and also um we have um like various research leads going forward that we would like to explore more. For example, um latisbased proof systems are getting uh more and more powerful. It would be interesting to see how hashbased proof systems combine with latisbased proof systems. Um you know uh hashbased proof systems are very fast but latisbased

proof systems are smaller. So maybe there's a nice combination that we could see there. Um another thing is uh binary field proof systems uh used to be very exciting. I think they can still be very exciting. And not only that, but also projects that use binary field proof systems can also prove traditional hash functions efficiently. And this allows us to potentially use them to move away from pose or from algebraic hash functions and use like a Shatu or Blake.

So you know these are potential avenues in the future for solving some of our problems. So yeah, like closing up, I think we have a a good path for the rest of the year and also definitely interesting research directions to to continue uh moving forward. And yeah, uh thank you very much and happy to take questions. Any questions?

Here we go. Um when you say 128 bit security is that referring say in your table for example to 128 bit classical security um or is it in the QM or um >> no it's on classical security >> I thought so yeah because the when I looked at the stocks paper it had no analysis of the postquantum concrete security at all um so do you think 128 bit postquantum security is necessary.

>> Yeah, that that that that's something that I I don't have a good answer yet. I mean, it's even more interesting because the the sound table I showed is showing um security of the interactive protocol, not even compiled into non-interactive yet. So, it's it's still hiding a few more details that we need to decide as a community how to handle. It's hard to say about the postquantum security bits. >> Yeah. My my intuition is don't cheat on this because >> correct. Yeah.

More questions? >> No. Very clear. >> Thank you very much, George. >> Thank you. >> So, we'll now break again and resume at 3:30 with some lightning talks. Thanks, What' you mean? Well, thanks a lot, uh, Rachel. Uh,

really happy to to be here with you. And this is a collaboration between uh aligned lambda class and our amazing partners from 3MI labs who have been helping us developing the design and everything. So the idea is not to talk precisely of like some cryptography part but mostly behind what is behind the design philosophy and why we need yet another uh CKVM because there are many but uh we see that there are like some problems in in the space related to them and so we wanted to to address this

using the same philosophy we used in in other places. So basically uh what we think is that um our application is going to be okay because we coded uh whatever we did and then we assume that the rest is going to be okay and there will be no problems. And if you've seen lately there have been a lot of attacks uh due to for example supply chain attacks or because one of the uh dependencies you had had some some kind of flaw or somebody introduced like some some bug. And the thing is that if you look at the code bases of most CKVMs they are hundreds of thousands of lines

of code. And even though like you have like nice uh security arguments and everything, one thing is what you have in paper and another thing is what you have built. Um and so the problem is that um any of these things can fail and you see that you have a very big uh attack surface, big assumptions and then auditing this uh becomes really painful. So um there are like three things that we we see that keep happening. One is that you don't own your own stack. You depend on a lot of things that others built and then for example there may they may

introduce like a sub bag and that's outside your area of control. Then a lot of um people generally create a lot of like abstractions, unnecessary abstractions uh and that makes things very uh hard to reason about uh and it doesn't make your code uh more maintainable or simpler to understand. It makes it on the other hand really complicated. And then of course the problem is that if your uh code base is really large then nobody can read it all reason about it understand the different dependencies.

Um and these are not bugs per se but they are I think perhaps like poor engineering choices because they make uh your system really really fragile. So we beted here on on the opposite. The idea is that most CKVMs got really performant by adding a lot of like clever tricks and a lot of optimizations. Here what we said is we are going to do the opposite. We are going to make something that is like really simple has a very minimalistic code base and it is performant. So what we are going to do is stand with one

ISA. We are going to use one lookup argument, one memory model so that our VM is really simple to understand and the codebase is really easy to audit. And this is the same philosophy we'd use with Ethrex which is the execution client developed by by Lambda class where you have the whole client in around six 60,000 lines of code. And so that is something that is really easy. In fact, we wanted to make it even smaller. The idea is to optimize um a lot. And we think that in this era where people like VIP coding, having something that is really simple

is the way to go. It's really easy to to write code VIP coding, but that makes everything like really really big and then it hides a lot of subtle bugs and we are going to see more exploits not less due to bip coding. So as I mentioned the idea is that we are following the same philosophy. Uh the idea was that with the execution layer you can read everything. You have everything vertically integrated. We use rust. We use few generics. Uh we think that you achieve performance through clarity and we focus on long-term maintainability which is something that uh some projects don't take into

account. And the idea here with the CKVM is more or less the same. The idea is that all the crypto primitives will be precise are precisely in the code of the VM. We have exactly one language Rust. The idea is 3M labs developed a very nice spec that we are currently optimizing and the code maps one to one to the spec. And the idea is that all this makes it really easy for the code to be formally verified which is one of the requirements the EF is putting forward and is spending a lot of money to ensure that uh we don't have any bugs. So to give you an idea of the

architecture or at least the the structure of the VM, the idea is that we have 14 tables more or less uh 18 chips and and templates. The idea is that we have the general like CPU chip that dispatches to to the rest. And this makes it like very easy to reason about what's going on with the the VM. And then the idea is that as in the rest of the VMs we have uh a memory argument that um unifies everything and the idea is that the spec is like really clear and we know exactly which kinds of variables we are using in uh each case.

So the idea is that most of the constraints are simply reusable. So we have like what we call templates and the idea is that we have uh bit templates sign also addition and and subtraction are inlined for performance negation and of course we have the the decode table but that's mostly like a lookup and the idea is that it's really easy to to compose uh the different things. As for the chips, we have like some related to control and instruction fetching and and decoding. Then we have all the part related to arithmetic. Then uh to memory and of course then we can

extend everything to make it more efficient by adding specialized co-processors. And the idea is that we work everything on a log bus and in general the signatures are pretty small and we keep just uh one running sum. We don't have complexities for example related from having like lo local uh lookups and global lookups and the idea behind the proof system is go really easy. So we are going to use a 64-bit field in this case goldilocks using a cubic extension so that we can really target 128 bits of security. Uh we are using fry because it's really well understood.

There are a lot of efforts at formally verifying it. For the time being we are going for uh ketchup as the hash function. Then we are going to see if it makes sense to use an algebraic uh hash function or we could use for example Blake. The idea with the lookup is precisely use um logup and then uh for the memory it's like a standard offline check and the idea is that sorry it says conjectured it's provable. So the idea is to have 128 bits of provable security.

Um so um then of course for for the memory and everything the idea is that um we can do this in the offline check and so we will carry information about the address the value the time stamp and since registers are accessed uh pretty often the idea is to have a special uh way to deal with registers that is simply an an optimization and then what we are going to ensure is precisely that when we uh read a position and and then we write there is an increase in in the time time stamps.

We still have to think a bit more about recursion. We are also thinking about using a streaming uh prover and we still have to to give like some thought but the idea is to use something simple. Some people use for example elliptic curves to try to simplify some of these things. We want everything to be of course postquantum secure. So we are not going to use any type of strategy and the idea is that the current state which for example can prove Ethereum blocks using ethrex is only 20 thou 27,000 lines of code. That is like pretty simple. The idea is to go

less than that but in the end I think we will end around 35 or so and the idea is that we also have like minimal dependencies and that way we can control what we have. So we are not publishing numbers yet but uh the idea and the numbers preliminary numbers that we have is really good. We are close to in performance to many of the state-of-the-art VMs. We hope to optimize the design a little bit more before we we release it. And um the idea is that right now we are on this version. We have to add like some few co-processors to make it like faster

to verify Ethereum blocks adjust uh the security and then uh we are also right now working on the GPU version. So the idea is to have the GPU version uh in the coming weeks and then we are analyzing some alternatives maybe adding logup GKR from the performance point of view it doesn't change much in terms of memory use it's really good then we have to see some strategies to maybe shrink uh proof sizes and of course the Erex integration is is done. We have to still improve some some parts but it's working and so

we have a full stack with minimal dependencies and well this is just the idea to proving Ethereum blocks in in real time and so we are using uh ethrex with that we get the risk 564 IML and then we run that on top of the lambda VM we generate the stark proof. The idea is to compress it so that it can be then uh verified in the L1. And so well the idea is that we want to make uh this VM as minimalistic as possible.

We take into account every line of code. Uh we try to have as few generic parameters as possible, as few dependencies as possible. And as always try to keep a one:one spec to code constraint ratio so that it is easy to audit and and formally verified. And so the idea is this is not a new philosophy. We are doing what we did uh with the execution client. The idea is this is going to be open source.

uh we plan on on releasing really soon once we uh finish some optimizations and and checking the spec and everything. And the idea is that a reviewer can easily read everything in in a whole week. And the idea is to precisely make this small enough to formally verify and to prove uh Ethereum. So if you want to learn more, you can come and talk to us. And if you obviously have questions related to cryptography, you can also ask our guys from three of my labs who uh are amazing. Thanks a lot for for everything.

Amazing. Thank you very much. Um as Diego said, if you've got questions, come and find him afterwards. We'll uh we'll swap over. Thank you very much. Okay, so next up we have Roman Vul from Tato presenting Mercy's private token transfers via MPC and cosnarks. We'll just wait for your slides to catch up with us and then we'll get going. I did rattle that off quite quickly to be fair. Yeah brilliant.

>> That is too far. Ah, great. Hi guys, thank you for the introduction. Um, yeah, let's jump right into it. In the title, we say we're using uh MPC and collaborative snacks. So, I want to quickly spend one slide on introducing what this actually is. So MPC or secure multibotic computation is a cryptographic technique that allows us to um compute functions on private data without leaking this data. And the way it works is that we have a set of compute nodes. So here on this picture on the right we have three compute nodes and they get so-called secret shares of the data. You can see these random looking noisy images there. And these um secret shares do not leak anything about their underlying data itself. But the

MPC nodes can use them to compute functions on them. And this might require some communication. But also this communication between the nodes does not leak anything about the data. And what the outcome of that is is another set of secret shares. And once the MPC nodes are done with computation, they just combine these secret shares and get um the desired result. So here it is super. And um that's the way we can use MPC to compute on encrypted data. regarding collaborative snarks that is essentially simply put just creating a co knowledge proof in NPC. So we have the witness as secret shares and we compute um the proof in MPC and um yeah essentially a collaborative snack.

So by having MPC and collaborative snacks what we um get is the computability from MPC brewability from the snack and from both techniques we do not leak anything about the underlying data. So coming back to Mercus, the actual goal of um Mercus is that we want to write a private wrapper around any token. This could be um a native token like E, it could be USDC or any other ESC20 token. And we want to be able to um deploy this wrapper on any EVM compatible chain. And what this rapper should be able to do is that on one hand if a user um has some balance with this rapper token, we do do not want to leak anything about this balance of the

users. Also, when a user wants to make a transfer to someone else, we want to be able to hide both the sender and the receiver, but also the actual transfer amount that the user was sending to someone else. And the way we achieve this is something that we in general call private shared state. And the blueprint for that is actually quite simple. So onchain in our rapper contract we only have a commitment a cryptographic commitment to all the balances of the users. The balances themselves are um stored offchain on an MPC network in secret shared form. And since they are secret shared the MPC nodes can compute on them. For example when I make a transfer then the MPC network can update the balances of the users. This will then also compute a new

commitment of the uh of these balances which we then store onchain to um reflect a new state and the smart contract will only accept this new commitment if we also provide the zero knowledge proof that these were the computations were done correctly and as intended and this is where the collaborative snack comes into play. So summarizing onchain we only have a commitment and we store the actual balances in some data structure offchain in an MPC network in secret shared form. So how do we achieve a private improvable um um um smart contract there. Uh so on the MPC network what we actually want to build is some kind of hashmap where we um map an user address to some kind of balance. And uh here

this uh square brackets they indicate already these should be uh remain private. So the balances are stored in secret form but also when we access these balances we should hide which addresses we are actually um um accessing here. And our way to achieve this is essentially we model this um hashmap as a mer tree and then this merry is fully secret shared on the MPC network. On the leaf layer, we have the actual balances of the users. And the path from the commitment to a balance is the address of the user. And um the root node of this merkele tree is uh just the commitment to the whole data structure which will be public on chain. And whenever we update the balances, we also

update this uh root commitment here. And this is the new commitment that we store on chain. And we can uh use a membership proofs to prove that the updates of all these leaves were done correctly. So so far there's nothing uh too special about this but uh what is interesting about our design is that um each layer of this merkeree is implemented as a so-called oblivious RAM and that is a primitive from MPC which allows us to read and write um this uh to these slots without the MPC network actually knowing to which slots it actually accessed. So the MPC network we just get um secret shares to the addresses we want to access here and the oblivious RAM primitive allows us to um read these slots and update the slots again.

So um from the point of view of the MPC network when a user wants to do a transfer private transfer what is actually happening is that the MPC network will get secret shares from the transfer amount secret shares from the sender address and secret shares from the receiver address. And it also requires some kind of user authentication here because uh we don't want to give every anyone um the possibility to make transfers on behalf of someone else. So the user needs to also provide the SE knowledge proof that it knows the secret key corresponding to the sender address here. And if the MPC network is able to verify the proof what it does is essentially just accessing the oblivious RAMs in the leaf layer modifying the balances. This also

triggers then um update of the whole Merkel tree structure produces a new commitment and this is the commitment that we post on chain. The MPC network as we said before also needs to create a collaborative snack and this essentially just proves uh three things. On one hand the balance was positive. Uh on the other hand the sender needs to have enough balance to fulfill the request. And the third thing is that um data structure needs to be updated correctly and that essentially requires um four Merkel proofs do binding the uh old balances to the old commitment and um do we're using the same buffs to um Merkel proofs which prove that the um new balances produce the new commitment that we stored and on chain. So this is essentially everything that is happening

on the MPC side and um with that we could already implement uh full private transfers. However, if we just follow it the way we I talked about now we will get a very inefficient design and the reason for that is that um um in Ethereum we usually have 160 bit addresses and if you build a Merkel tree that has the addresses as the um path from the commitment to the balances then we need 160 layers there. in our design where we have ORAMS for each layer. This also implies that we have 160 ORAMs 160 oram excesses for each uh transfer and also in the lowest layer we have two to the about 160 um uh elements in there and this is way too big for any uh ORAM

design to be efficient at all. So we need to um come up with some kind of optimization. So we experimented in the past already with some sparse merry designs in MPC but um uh the what we learned in the last months is that the most efficient solution in our opinion is to introduce something that is called an ID registry and that is essentially when a user wants to engage with our private token transfer system it has to register in this ID registry and this is essentially then um just a lookup from the user address to some incrementing index. So if I'm the seventh user to register, I get the index seven. And this is then the index that we use in the mercury on the MPC side um to to access the balance of the user. And um

essentially when a user then um um wants to um make a private transfer, the authentication proof also needs to um take account this uh lookup from this address to the index. So how did we implement this ID registry? Essentially this is also just mercury. You see this here on the left side. This is um um a fully public Merkel tree and I when I register uh then I get the next free leaf um um assigned and the path from the commitment to the leaf will be my index that is also the index on the MPC network. So here on the right is the MPC Merkel tree and you can see um that the path is the same as in this public ID registry um merry here. So um as I said before when the client wants to

authenticate itself with the vis knowledge proof that it knows the the uh secret key to address we also now need to include a membership proof of this ID registry um mer tree and then that the path for this uh um where my public key is stored is then the one that is put into the NPC network as a sender index. Okay. Um sorry. Yeah. So this is now that the the full view of the protocol from the point of view of the client. So when I'm a client and I want to engage in a private transfer with Mercus um first I obviously need to register with the ID registry. If I have already done that then I still need to engage with the day registry to be able to create this

authentication co knowledge proof. Then I secret share um the amount that I want to send to someone else. I secretly share my index. I secret share the um receiver index. And what I also need to do is um create some commitments to um send ID, receiver ID and the amount. And these commitments will then later be used to bind the proof created by the MPC network to my user intent. Uh also in our system we um give the secret shares uh to the MPC network via the um smart contract. So what we do there is we um encrypt each secret share with the public key of the receiving party and that is also posted on the on onchain and the client then creates a co knowledge proof that proves everything

of that. So on one hand the ID registry look uh that it knows the secret key for its uh address and also that the commitments and the encryptions of the secret shares were computed correctly. Once this is done, it posts this into our rapper smart contract where the zero knowledge proof gets verified and on success um the request get puts gets put into some action queue and the MPC network regularly um queries this action queue reads the cipher text from chain gets the uh secret shares from it and is able to update the uh full mer tree based on these secret shares. Once it's done, it uh creates the um the new commitment to the data structure and the SE knowledge proof proving that

everything was done correctly. Okay. Um regarding performance on this slide, I give you some benchmarks on the uh MPC networks computation. This includes um reading and updating the data structure and also creating the zero knowledge proofs in MPC. And I give you numbers for um different uh sizes of the mercury. So how different um users who are registered in there and also for different um um machine setups. So on one hand we have a M7A4X large is a fairly standard AWS CPU machine um and in the other hand I give you benchmarks for G5 forex large where each party also has access to a graphic card and you can see uh if we have around 100,000 users

registered in 2 it takes um uh around 200 milliseconds to process a a request including SE knowledge proofs and this is on both on the CPU and the GPU machine. Um if we have around four million users registered in Mercus then on the CPU machine this um you can see it takes a little bit longer now around 1 second for this request. But on the a machine with access to a GPU we see that the scaling is uh way better and here it takes roughly 370 millisecond to fulfill the request. So in total we get around 3 to five uh transfers per second on the MPC site depending on how many users are registered in the system.

Okay, this brings me already to the end of the talk. Um, I introduced Merces, our solution to realize um, private token transfers. We hide um, sender receiver balances and transfer amounts and uh, I want to say that we use MPC um, for privacy but for integrity of the whole system we only use the CK system. So essentially if all the MPC parties would collude, they would not be able to misuse the funds. So and we implemented um this design using what we call an oblivious hashmap and this is based on a merry tree and orams. The design is fully implemented and then if you scan this uh quer code here you can interact with a demo that we launched on a plasma test net. So you can make private uh

transfers there and also um see what is actually posted on chain and u you will see that nothing is actually leaked to the users. Throughput of our system depends on how many users are uh um registered for mercers and is around 4 DPS. And I want to note here that if we deploy a system where we always allowed to leak sender and receiver, then we can actually get up to 300 DPS. And for this u system with the relaxed security assumption, we actually wrote a paper that we published last week and there we have a full um UC security proof in there. So future work about our system.

So on one hand so we also hint this in this demo already is that we want to be able to um implement some private swaps. So when you have deployed some um tokens into our Mercy system, you can swap this to some yield bearing tokens for example from AI or Moro then you um deploy tokens actually generate some yield and another thing is we want to integrate merces as the payment back ends from some uh more uh complex protocols for example the XO2 do payment standard um that's uh the end of my talk if you have any questions I don't know if you have time you can ask them now or find me later and then I will happy to discuss further. Thank you for your attention.

>> Wonderful. Thank you very much. And that was truly a lot of information in 15 minutes. So well done. That was a true lightning talk. Um okay. So next up we have George Vice from Per Labs and he will be presenting non-deterministic auto pre-ompiles. Um again if we have time for questions in this slot we can ask them. If not you can find George afterwards. Okay, >> nice. Good afternoon. Yeah, I want to give an update on some of the new ideas that we have for auto pre-ompiles. So, let's jump right in. What is an auto pre-ompile? It's a ZKVM pre-ompile. So, it's something that makes ZKVMs faster.

Um, but it's not written by us or by NAI or anyone. Um, it's automatically generated from a specific guest program. So you can think about you have a ZKVM, you have some guest program that you care about. Um you give that to us and we give you a faster ZKVM for this specific program. So let's dive into how this is done concretely and then I can talk some of uh can talk about some of the new ideas. So for the purpose of this talk you can think of a ZKVM as just some collection of ZK circuits. So for example, you could have a risk 5 ZKVM that has a circuit for each of the risk five instructions. You could also have fewer

circuits. Um an extreme example of this being jolt that has just one circuit. Uh doesn't really matter. And then you have the guest program which is a a list of assembly instructions. And so the first thing that we do to the program is we segment it into basic blocks which means that we only look at consecutive instructions where only the last instruction can be a branching instruction. And then the goal is to make a new circuit that can prove execution of the entire basic block in one go as opposed to proving instruction by instruction which is what a ZKVM would normally do.

And we start out by doing the most obvious thing. We just copy paste together a bunch of circuits that the ZKVM would have used if it would have proven this basic block. And we wire it up correctly and we have a new monolithic circuit that can prove execution of the entire basic block. But of course that would be useless if we wouldn't then optimize it and get a smaller circuit to do the same work. So let's dive deeper into how these optimizations work.

Actually no uh this is a summary slide. Uh so right now what we see um is that for a typical basic block that we get from compiling Rust to Risk 5, we see about a 3 to 4x improvement in efficiency in that optimization step. Um that's like kind of the average case. And then in some cases we see a higher efficiency um for example like more than 10x on catchup >> to >> yeah exactly it's risk five compiled to I think openvm in this case and then applying this optimization.

So let's look into more detail. Um here I'm just presenting like a single instruction. So forget about basic blocks. And this is um to keep this really simple and this instruction is incrementing one register. So think about a Rust program that has some kind of loop and you have a loop counter that you need to increment each iteration of a loop which is stored in register 29. And so we want to prove that increment. So typical CKVM would commit to a bunch of data to prove a correct execution of this instruction.

For example, the current program counter, the current time step, then the instruction data, which is basically encoding stuff about the instruction like what are the source and destination registers, what are the immediate values, stuff like this. Then there's uh two operants and a result which are both machine words. And in this example, there would be 32-bit machine words represented as four feed elements, each of them encoding one bite of the 32-bit word. And last but not least, there's some auxiliary data needed to for the memory argument to prove that all the register accesses have been done correctly.

And already today, we can remove most of this um because we're building a circuit for this very specific instruction. So we already know the program counter. So we don't have to commit to it at runtime. We can just hardcode it in the circuit. Similarly, we can remove the instruction data because it's implied by the program counter. For example, in this case, we know that the register being accessed is register 29. We can also remove uh the immediate the second operand in this case because it's an immediate value.

And uh we can also remove most of the memory argument auxiliary data because in general an addition instruction would have the infrastructure to access up to three registers. But in this example there's only one register being accessed. So we can remove 2/3 basically. So that's the state today. We get like a smaller circuit. And let's have a look at like an even more concrete example. and uh check the case where the loop counter is 42.

So we want to increment register 29 which stores 42 we get 43. So we would commit to the operant and to the resides. Um and in this case 42 and 43 are relatively small numbers. So the three first bytes of the representation will be zero. But now imagine this loop never runs more than 255 times and it will always be zero. Of course that's not something we might be able to prove but we can still observe that this is the case typically.

So the optimiz uh the observation here is that even in the very optimized case we still have uh situations where many of the trade cells that the proofer still commits to are either equal to each other or equal to a constant. In this case they're equal to a constant. But even if the loop counter was very big the chance that the most significant bite changes when you increment by one is pretty low. Like it won't be the case for most inputs. So the idea here is let's build a pre-ompile for the typical case um kind of losing completeness. So we get a circuit that only has a satisfiable witness in the typical case but is smaller smaller to prove and the

prover needs to have some kind of fallback um to the situ like for situations where it doesn't where it doesn't apply. So in this case if the loop counter becomes too large uh the prover needs to fall back to something else. This could be another auto pre-ompile or it could just be falling back to the circuits that the ZKVM already has because already today prover is not forced to use an auto pre-ompile. It can kind of non-deterministically choose the circuits that it uses to prove um the statement.

So yeah, that's what we call an optimistic pre-ompile. Um, it's built in three steps. We first uh run the program on a bunch of representative inputs to collect data. Um, like I mentioned, we check for trade cells that are usually equal to each other or usually equal to a constant. Then when we're building the circuit, we over constrain it. So we whatever observation we made in the first step we add that as a constraint um and that basically enforces that observation and the circuit will not have a satisfying witness if the observation like if the condition doesn't hold

and then we just pass this to the existing optimizer which would just do the right thing. So for example, if it sees a circuit where two variables are constrained to be equal, it would just allocate a single variable and get a smaller circuit. We implemented this on OpenVM. It's a prototype. Um but we tested this on a program that verifies Ethereum blocks. um looking only at the part that's not accelerated because OpenVMs comes with pre-ompiles for something like Ketchup, but it also still needs to prove a lot of risk five stuff. So, we're only looking at that part.

Um and then we're kind of assuming that we can accelerate all the basic blocks and by doing that we get this first number, this 3.3x without optimistic pre-ompiles and with optimistic pre-ompiles this number goes up to 4.8x. 8x. So we can reduce the amount of data that the prover has to commit to by this factor. And so compared to the current state is like a 1.5x increase in efficiency. So that wraps up optimistic pre-ompiles.

I want to briefly talk about a very related idea which is branch prediction. So consider this uh example. So here um the program does a division but it also does some error handling and checks whether the divisor is zero and then if not it carries out the division but probably most people are not going to attempt to divide something by zero. So the typical case will be that there will be two basic blocks that are executed one after the other. The first one checks whether the divisor is zero and then does a conditional jump which would typically jump to the second block

which carries out the division and does the function return. Um but the same principle applies as an for optimistic pre-ompiles. We can just build a pre-ompile for the typical case. So in this case we would b uh build a pre-ompile for the super block which would just prove both basic blocks in one go. And so the way we build the circuit is basically returning the conditional jump into an assertion. There's it won't be able there will not be a satisfying witness if the condition doesn't hold.

So the circuit would still check that the divisor is non zero. But if it is if it happens to be zero then the prover won't be able to use the circuit and has to fall back to something else. And the motivation for branch prediction is kind of this chart. So here we looked at the relationship between the number of cycles that were proven in one auto pre-ompile and the effectiveness which is this number that I was presenting before. And right now we see that many basic blocks have about 10 instructions in them and we get a 3.3x effectiveness.

Um, and we're hoping that with branch prediction, we can bring this number up, kind of move to the right side of the chart. I also included the number of the far right here, which of course is not realistic. Um, but I thought it's kind of interesting because at this point we're kind of approaching having a single circuit to prove the entire computation. So, um, branch prediction can get us in that direction. So that's it. To summarize, I presented two ideas, optimistic pre-ompiles and branch prediction. Both of them were expecting to give us very significant reduction in trace cells. And the

unifying theme here is that what we're doing here is exploiting the non-determinism of ZKVMs to be able to optimize for typical situations. >> Okay, great. We'll move on to questions if that's okay. Um does this kind of technique mean that you can um transfer other um kinds of optimizations from conventional processes like caching for example? So um if you're doing a memory access um you don't you you probably know that it's within um a small subset of the memory. So you can be optimistic about that as well >> that it's like you like caching pages of

memory. >> Well um it wouldn't necessarily have to work in the same way as a cash in a processor because you you can just basically guess that the memory location is um one of a small number of possibilities and then that's your optimistic recompile. So you don't need to actually keep track of the same cache information that processor will be doing but you get the similar effect. >> Yeah, I think we've seen something like this that for example some of the things that it can observe is that it will know more for example the the most significant limb of the memory address which I think is what you're referring to. What we've also seen is that as part of a memory argument, you need to commit

to like a previous time stamp or the difference to the current time stamp, which is often a constant because if you're accessing something in a loop, >> it's always like a difference in time stamp will always be the same. >> So that's something we've seen in practice. >> We've got two more. We'll uh we'll take both these questions if you want to go ahead and then we'll come to you Tobias afterwards. Yeah, I just wanted to say that basically if you have a predictable memory pattern, memory access pattern um you can or at least like optimistically like predictable memory access pattern um using sparsity based arguments you can you can sort of turn it into a single vectorzed access in a sense. So

so this is one way of doing this. >> Great. Okay, we'll take this final question and then we'll move on. We should have Maddie here ready for next time. >> Yeah. So the question is have you considered loop unrolling? I guess it's kind of related to branch prediction but that means if you have like a loop uh maybe you do 256 uh iterations of that loop as a pre-ompile and then you can reuse that. >> Yeah, I would say that loop unrolling is a special case of branch prediction. >> So I think it just captured by this.

>> Yeah, that makes sense. Thanks. Thanks for the many questions. >> Thank you very much. >> Wonderful. >> Okay. So, this is our last lightning talk of the day. Then we'll have break. We'll have one more 30 minute talk and then it'll be the panel for the end of the day. Just so everyone's aware. Okay. So next up we have Maddie Sedigat from Soundness Labs and Kouluven presenting proof of seed zkbased quantum migration without address changes. Uh take it away.

>> Thank you so much for the introduction and good afternoon everyone. Um I hope that this the online version and not the PDF one because I have some animations that I'm using. I hope that it's going to work. Um so in this talk I'm going to cover uh the result that we uh had and presented a couple of months ago at financial crypto uh which is a collaboration with folks at Mist and Labs. Um and the question that we want to answer in this uh presentation is that is it possible to use the ZK proof that you already got a lot of insight today uh with multiple amazing talks um to uh seamlessly migrate to postquantum w uh if this is possible or not I'm going to answer

um you already have the context this is the good news I know that this is the end of the day and you already had a very intense day um it's not like a super new topic there was multiple episodes at ZKO podcast that was discussing this uh topic before. And funny enough, uh last night that I wanted to go to bed, I just refreshed my my podcast like application that I have on my phone and episode 400 was exactly the topic that I wanted to present and it uh forced me to change two of my slides and also um remove one of those. Fully recommended uh by the way. So um many people u might ask that how quantum computer is going to show itself in the

blockchain space. um for those of the people who are not believing to this like uh uh breakthroughs or like advances that is happening I'm not um like the right person to answer a timeline but imagine that the first uh time that is going to uh the Satoshi coins are going to be touched uh this is a situation that we should expect from from the market impact and there is also another important uh aspect that we have to consider there are a lot of dormant accounts that uh the users are going to lose the migration calls and It's very hard to expect the users to take an action for changing their their like a legacy systems to the postquantum secure ones.

And another problem for this space is that if you want to compare it with another like spaces in the in the internet that they are being affected similarly to to blockchain in the terms of like a quantum threats is um or we would like to keep the addresses uh unchanged uh if that's possible. So uh a quick reminder about uh how the blockchain works with the focus on Ethereum itself. Um whenever a user joins to this network they will get a key pair which is a signing key and also public key and the address is being defined through a hashing the public key and some specific part of the the output. And uh whenever you want to like assign and make a transaction you need to use the signing key and essentially

sign the transaction details for the integrity purposes. And this is going to be submitted to the me pool. So the validators need to know your public key to check the validity of the signature. And if everything is fine then essentially they are going to agree on the validity of the block and the block is going to be created. I already highlighted in red uh there are two parts that the signature is being used. uh the first one is an execution layer that the user is trying to make a transaction and the second part is in the consensus part uh that the signature is being used. Another thing that I want to highlight in this slide is that the public key is going to remain hidden and it's going to be behind the hash function as long as you

are not making a transaction. Okay. So once you make a transaction you need to reveal your public key and once your public key is is revealed then there is a possibility for for a quantum computer who has a sufficient number of logical cubits to uh get your signing key and let's draw a map that how does it look like um so as I said before the digital signatures for the execution layer that mostly are being ECDSA and EDSA are going to be directly impacted by this threat and for the consensus part which is the BLS being used in the proof ofstake protocols um is is also directly being impacted. So in the first threat uh the the transactions are going to be forged by the quantum adversary

and the second case which is less probable from from the other one because we have to expect that the quantum adversary is rational. They already solved a super super complex problem and they are not going to like do a rookie mistake whenever they are going to do that. Uh is is is going to be like the proof of stake attack. By the way, quantum computer is not going to do everything uh better than the classical computer except these two algorithms, the shore algorithm and the grower algorithm. And the rest of the things are going to be either partially impacted or they are going to be secure. The symmetric cryptography and also the hash functions are not going to be impacted. So because of this we are just going to focus on the execution layer and as you know that Ethereum is also working uh great on like bringing this

like a replacing this PLS signatures with XMSSS and also using the LINVM to aggregate the uh hashbased uh uh signatures. So the nive approach for this would be like let's switch to the postquantum signatures. We have some candidates here that was standardized by NIST like falcon like snakes and also so on. Um but the problem is that once you change your signing key it means that the public key is going to be changed and the hash of the public key is going to be changed. Okay, this is this is natural and our goal is that how we can use the backward compatibility feature in the legacy systems to keep the address and also not move the assets because there is also a front running attack for the quantum adversary that whenever you are asking for the

migration they can actually do it faster than you that you can refer to the uh Google paper um for for more details. So again we we would like to preserve the the addresses and also we would like to just take care of the exposed keys and they are like a dormant accounts and also protect uh uh this this type of accounts and also we would like to be like a key change uh key generation agnostic which means that it doesn't matter that which type of account and wallet you are using. Um and another aspect is that uh most of the people would like to uh and prefer the hashbased constructions. there is a cons uh for for this like a perspective that there is no algebraic property and we are just losing some of these properties

that we we already had in the ECC based constructions. So the core idea is quite simple. Uh we have some modern chains uh like Solana um SUI um and others that they are based on EDDDSA signatures and we have also Bitcoin and Ethereum that they are based on ECDSA signatures. In the ECDSA, whenever you are creating an account, you are going to get a a random signing key and the signing signing key is going to give your public key essentially, which is exponentiation in the in the in the in the group. But in the EDSA, the Ceriviation mechanism and the path is slightly different.

First of all, you pick your seed and your seed goes to a hash function which is SHA 512 is exactly the key mechanism referred to RFC 8032. Okay, so it is they are just following a standard and the core question is that can we use this seed that is protected by the hash function because we know that the grower algorithm is just giving us a quadratic speed up for for breaking the pre-image of the hash function can be used can be used the seed for postquantum signing processes and unfortunately the signing key because there is no like a path except like a B32 and B39 in the harden and key path uh that I'm not going to described in this in this talk. Um they unfortunately there is no chance and

once the quantum adversity having access to your public key they can get the signing key and then essentially they can impersonate you and somehow like it drain the account. But in this case we have some advantages in the EDDDSA based uh chains. The relation would look like this that uh you have a message that the message in a in a in a first step can be like a transaction details that we already signed using ECDSA or ADDSA and you have also public key plus some some extra information that is for binding purposes to make sure that there is no mix and match attack and what this relation proves is that proving the knowledge of the seed and also the key derivation mechanism that reaches to the same public key okay that the signature is

going to be verified based What we expect from the proving system uh to prove this this relation is first of all it should be postquantum secure for sure I mean postquantum soundness is more important that uh here very critical for us because the non-postquantum one also provides us the postquantum zero knowledge by the way because it's information theoretical zero knowledge um and we would like to have also client side proving client side proving is very important otherwise you cannot like outsource your seed which is the full control of your asset to a server. It should be also memory efficient because most of these wallets either are in the extension of the browser or they are in the mobile phones. It's not like a heavy like a

machinery that we are expecting here. The proof can be also one time um because once you have the postquantum signature being supported by the chain, you can only use this technique, this migration technique for keeping your address the same. Okay, for account uh or address consistency purposes and instead of like a putting the transaction details as a message for binding purposes, now you can use the public key of your postquantum signature and then essentially the the network is going to check the validity of the signature and your transactions from that time on V based on that postquantum public key and this is going to be a one-time ZK proof because onchain verification for this postquantum signatures is expensive and we shouldn't expect it to be happen per transaction

if this is the the situation that we are dealing with. By the way, very recently, Coinbase also had a report uh and they already also discussed multiple strategies how the migration would look like. And uh the second uh column is about this idea that somehow like meet most of the conditions that they are just uh discussing and describing there. Another important thing is that uh it is somehow like a signature of knowledge. uh we need more than knowledge soundness and this is simulation extractability because we don't want to like uh do the malability of the signatures because someone else can pick it and make it different and there's also common trick uh that put like a session ID to the fmeir and then essentially you can have

this this property somehow for free without like a expanding and increasing the proof size how the benchmarks looks like um there is an uh open source code that you can follow um here um and and and the circuit uh is is looks like this. The blue dash box in top is something that is happening uh outside the circuit and the red box is inside the circuit. as you know that most of these like a client side proving systems um are based on like a ziki friendly curves BN254 or like the the other things and unfortunately uh the the relation that we want to show is in ED25519 which is a legacy curve and we don't

have enough roots of unity okay we need to do some emulation here what we did initially was uh we we somehow like used three limbs for for this you know you know better than me then essentially we could uh come up with these numbers in liatron zkvm and this is what is that uh open source right now and we could actually like do it better uh using vbase and lean vm uh like a that I left in this slide is that you can also use some decomposition technique because you could you don't you don't need to just do everything in the single circuit uh because it doesn't necessarily that the hash relation is going to be uh the same as like a checking the consistency of the public

By the way, the public key should be checked inside the circuit. There is no way. How does it look like? Um, okay. It seems that doesn't play. That's a bad news. Okay, because this is a PDF version. I just left it as a like a urgent case, but it doesn't matter. Um, I will I will post it on my homepage afterwards. Um, so the the demo supposed to show you that how does it look like? Uh, I can just describe it. How does it look like? So essentially you have a wallet and the wallet uh is holding the seed you can you can copy and paste it uh and whenever you are making a transaction you just press generate the proof and the proof is supposed to be the second condition for the validity of the signature and the transaction and it

can be like an upgrade in the chain itself and as long as and if the quantum adversity is trying to train your account since it cannot provide the second condition it's all the time rejected but as you know we don't have only the software wallets and In the self-costity wallets, we have different type of wallets, HSM wallets, uh, MPC wallets. In the in the HSM based case, we don't even have the API to get the signing key and we cannot expect to get the seed. Okay? Because we need to generate the proof and we cannot run the proof inside the HSM. Do you want to do it? Talk to this like HSM providers. Good luck.

After six years, they can say to you a big no and this is not going to happen. And for NPC was also the case because none of these NPC providers are following this standardized techniques and everybody's like doing whatever that they want is like for marketing purposes or for different purposes that they just want to showcase that my scheme is secure than the others and they are just doing different stuff. Okay. So we don't have any clean path for for this type of accounts. how Zik can come to the rescue for different type of accounts because as I said before the previous idea only works for EDDDSA which is like a very small fraction of chains that they are supporting and BIP 39 and BIP 32 for ED ECDSA uh but we have also different type of accounts that doesn't work at all

this is the problem you already uh I think heard about the anonymous credentials multiple times today in different talks um and uh this is the immediate solution that we can assume in anonymous credential someone is proving that they have access to a signature that is coming from an issuer. So as I said before, as long as you're not making a transaction, then your public key is going to remain secure and you're not threatened by by the quantum adversary. Okay? Because you the quantum adversary only has the hash of the public key and from hash to public key is is not possible all the time. prove that uh you you have the knowledge of a signature for this transaction and also show the consistency of the address with the

public key that the signature is being verified inside the circuit. Okay, so you don't reveal anything on chain and then essentially uh this is going to help us to do it on top of this other like wallet types. Again there's another demo that I cannot show you but this is also more or less the same concept that uh you can you can connect to your metam mask that essentially you make a transaction but you wrap it before sending on chain and this is going to be a smart contract it's some delegation technique that Ethereum does led you to do that and we are actively working and this is also another open source code that you can you can check it out um we are using longflow ZK um developed by Google and we are actively working with them to

reduce the onchain as a as a as a conclusion and a wrap-up. Um, we already talked about like EDSA chains that they have like a structure and deterministic deterministic like a key deviation path that led us to wrap the signature using a postquantum ZK proof. Uh, but unfortunately it doesn't work for any cases and also for for MPC and HSM that we can actually use against ZK for this purpose by hiding your public key. we call it as a hidden public key like a concept that essentially can be used. Uh again I mean refer to uh episode 399. Um is the zk that I don't think so if it is my personal opinion. Um there there are

some new like terms uh and applications that we can see here as you can see is like a postquantum migration. There are a lot of uh a lot of uh traction and like discussion that is happening. Anchorage also had another idea that whenever you have a postquantum signature, you can use the secret key of your legacy system on the condition that the public key wasn't revealed at all for the key deriviation mechanism of the postquantum signature. Okay. And then prove it inside the circuit. Again, good luck because the key derivation mechanism for the postquantum signatures is extremely heavy to be done inside the circuit. And there's another idea that to put the time stamp because we know that at the moment there is no quantum adversary. Then let's put some time stamp for your legacy system and prove inside the the ZK and the circuit that

you have something valid before the quantum adversary arrives. Okay. Before the Q day. Yeah. This is the end of my uh talk and uh happy to answer a question if you have time. >> Yeah. Thank you. >> Yeah. So we could maybe take one question or to be honest you can ask questions. We'll just be going into the break so we can stay as long as you like. Um so we'll we'll start with questions. >> Um I just wanted to describe how a similar concept works in Zcash. So if you look at um ZIP 2005 um so we already um derive the keys um for our circuit um deterministically in

most cases. Um so we can use something that's kind of similar to the ED EDDDSA approach. Um there's one exception which is um uh uh threshold signatures using frost. Um but because those hadn't been widely deployed yet um we can specify the key generation for frost um taking this into account and so we can um kind of provide an alternative that will work um postquantum. So the idea is that um uh you might have to to leak one of the keys from your um hardware wallet um uh and also do a um a uh DL based

signature. There's another alternative which um kind of uses a smaller circuit um uh in the hardware wallet and that works similar to one of the ideas from the slides. So basically we've come to similar um approaches from different directions. >> Amazing. >> Wonderful. Um okay. So if we have any more points or questions to talk to Maddie about, please find him in the break. Um we're going to break for 30 minutes until 5. Then there'll be the final talk on this stage and then we'll be moving on to the panel which will be the end of the day. Okay. Go and caffeinate.

Feed yourselves. Thank you, Maddie. panel. So, next up we've got Inacenti

Senovski from Aztec Labs presenting origin tags, dynamic detection of fiat shmere bugs in complex systems. Take it away. >> Uh, hi. Yeah. So, my name is Nakinte. I'm head of security at Stack Labs and I'm going to talk about a mechanism that we've created to detect some of the uh vulnerabilities that often arise when we create uh fatimir U based systems. So, let's dive in right away into most basic interactive protocol. Let's say we are trying to prove uh the knowledge of uh the discrete logarithm in some uh secure group. Uh the way this usually happens

is the prover generates some sort of uh secret uh random scala car then commits to it, send it to the verifier, receives a challenge from the verifier in return that the verifier is supposed uh to generate uh randomly and then computes a function of that challenge, the original uh private key, the original secret uh and uh the original scala that it created in the first round. Then uh it sends back uh this the result of this function and the verifier checks that the arithmetic for the scalers and the exponentiated

uh elements holds. So in this case the verify generates the random challenge sends it uh to the prover to convert this to an non-interactive uh uh to a non-interactive proof which is needed for most of the blockchain use cases because we can't have a verifier who is completely online all the time. Uh we perform the fiat transformation. I'm not going to go into the whole random oracle model. In practice, what we usually do is we use a secure hash function with which uh into which uh we put uh various parameters of the system and usually in addition to uh the

commitment to the random uh scala k uh to which we commit in the first round some additional message for example so that uh we can instantiate that this proof happens under certain conditions for example I am proving something on this day in Rome uh on the 7th of May and somebody else shouldn't be able to use it or under different circumstances. So the prover uh computes this hash uh and generates the challenge uh in this way from the hash. Then it uh finishes the protocol as if it was talking to the interactive uh verifier and sends all the necessary information to the ver verifier. Once the verifier can then

simply recomputee the hash, recomputee the challenge and use it to check the correctness. So in practice there are uh many things that can go wrong. Uh so the first most basic thing is you can forget the message. Uh if you forget the message then it means that you have created a proof which when sent on the network or when published can be easily uh reused by anybody else. So I proved the my knowledge of the discrete logarithm once. Somebody else used the same proof because it's non-interactive.

It's not bound to any conditions and they can prove that they know the discrete logarithm uh without actually doing any work. Uh an even worse case is if we forget to commit to the if we forget to uh add the commitment uh to the nons uh scaler into the hash. That means that the challenge is now completely deterministic. Um and the malicious prover can basically uh ignore it uh use the information from this deterministic um from this deterministic challenge and create such parameters that would completely break the scheme without uh actually u having any knowledge of uh the public

key. So you basically so the malicious uh proofer can basically go and set such parameters that uh this signature this non-attractive protocol holds without any knowledge and uh there were a lot of examples of fiat mirror attacks in the previous years. So for example for the last four years every year there have been published attacks. In 2023 there were uh several attacks on various proof systems such as bulletproofs uh blanc specifically on uh various implementations. Then in 2024 I think at uh the Ziki summit actually there was pre uh there was a presentation on the last challenge attack where uh fiat was implemented incorrectly within uh a

particular plon instantiation and the batching challenge was computed incorrectly in 2025 there was a plunky free uh vulnerability and uh the day before I submitted this presentation uh I think published uh several attacks on u six ZKVMs with various vulnerabilities uh in firere implementations. There are a few reasons why this keeps happening especially in the modern systems. So the first is modularity.

Right now to develop something you have to quickly be able to exchange components. For example there is a new commitment system that is more efficient like where comes out. you want to uh take out your pre-existing uh polinomial commitment system and put in a new one. Sometimes when you're doing that, you end up with mistakes. Um the second is rapid development because we are uh instead of uh trying to create one uh secure specification and then implement it correctly. I don't know like for ECDSA uh let's say we have uh proven systems that are evolving constantly. Uh there's rapid development. Uh there's no specification. it's very hard to basically write out uh the whole uh

layout of the full protocol. Uh which means that it is hard to catch these in a paper. Uh and last thing is that there are no uh well there are very few uh potential detection mechanisms. So for example there are uh special frameworks such as Merlin and decree which help but they basically rely on uh either def the developer completely defining the protocol uh beforehand which makes it harder uh to um which makes it uh much harder to use modularity or uh and uh they also rely on the developer not leaving out any data because like every

uh submitted value has to be submitted directly into the transcript with them. Uh which means uh that if somebody just decided to compute something on top of uh uh the values that they didn't put in the transcript or they just forgot to put something in the transcript, there's no way uh that this can be caught. Uh obviously this kind of complexity also affects uh the atstic network because we have a very complex we have a very complex system uh with lots of recussion. So for example we have several layers of application circuits and kernel circuits being recursively folded u with uh special speed up mechanisms for recursive

folding. So all of the elliptic curve operations for example go into special uh elliptic curve operation Q. Uh then at the end of all of these recursion we have a special hiding kernel that now uses zero knowledge. Before that zero knowledge is not being used. All the uh elliptic curve uh operations then go into a special VM. uh that is done not on the main curve that we're using uh BN254 but on a special cycle curve that proves the operations and then we go into a special circuit that proves the correspondence between what is happening in ECCVM uh all of those operations and the original uh OPQ that is in BN254

which is the translator and all then from all of this we get one single proof from multiple components and even at a single So uh recursive uh recursion step. We also have several components. So we have the basic hyperplon uh version with uh lookups which is called oink uh internally that goes through the sum check and then we use hypernova to accumulate the claims uh and uh to to accumulate the claims and eject them into the next uh step of recussion.

So tons of components and this basically creates a recipe for disaster for our system because well one we're using recursive verification on the client. There is no training wheel. There's no way for us to check uh that somebody hasn't injected something malicious there. There's huge modularity with different components some check uh hypernova. Then we have deferred uh elliptic curve operations that go into the ECCM and the translator. There are many flavors. We have the ZK sum check, we have the nonzk sum check. Uh then we have two different curves that we use and there are special protocols like ACCVM translator and merge protocol to actually bind individual ECU operations

and pull them into this whole queue that is getting improved in the end. So uh we decided that we need to do something to catch these kind of issues uh within and the first thing that we decided to do is to make a single recursive transcript. Uh the basic idea is that we are not injecting values one by one into it. Uh so instead of standing uh for example by one a commitment to uh witness uh wire uh you just take the whole proof as field elements and you send it to the recursive transcript and then when you want to receive on the verify side an element you actually call receive and it automatically adds that to the buffer

for the hashing uh for the future for creating challenges and gives you the uh element that you want to use in an appropriate format. That means that every time that we ask for the challenges, all of the previous data uh is being used for the hashes. It means that there can't be situation where we are rehashing and we forgot uh some previous element. Uh unfortunately, this obviously doesn't protect against all the attacks. This is a very simple uh architectural uh choice. uh and especially because we are using recursion there can be such simple things as okay the developer forgot to use uh the transcript let's

say and decided to recomputee the a particular batching challenge uh natively and then reinsert it as a witness into the circuit. So for example, we have two commitments uh that go into the transcript and then the challenge is recomputed separately just using their native versions uh instead of and then reing injected instead of uh using the challenges from the transcript. And obviously we'd like to catch this kind of attack because it's one of the most basic ones. So the thing that we decided to do is to add additional information into each of the elements that we use when we're describing the algorithm of uh the recursive verifier. So let's say we have a special element field that represents

field operations. We're adding the tag there uh for all the operations on various for the group operations like for example the cycle group that represents grumpkin or for non-native operations uh like big field uh we have this field called tag which represents some information about uh the element every time we do any arithmetic on these elements we merge the tag so the new tag is the result of the previous ones any arithmetic automatically does is the developer doesn't have to think about it.

So what we can do is then create a set of rules that will simply detect uh the most basic problem. So uh the at stage one of uh the origin tag mechanism we add the information whether this particular element is supposed to be a constant. So this is either uh an element that is not even injected as a witness uh into the circuit. it is automatically put into the selectors. Uh let's say uh whether it is a free witness, it didn't originate from the transcript at all or whether this uh element was ejected was uh taken from the transcript. It means that uh it is either a challenge or a value that was uh taken from the transcript and takes

part in the hash and takes part in the whole recursive verification. And then we have several rules. Whenever a constant operates with a different element, it preserves the tag of that element. If we have two free witnesses operating, we get a free witness. And if a free witness operates on an element received from the transcript, then we immediately generate an exception because this shouldn't be happening. So this immediately protects us from this most uh basic problem. When uh two elements from the transcript uh interact, that is completely okay. Uh so as a result we have a mechanism which immediately solves the issue uh in uh the uh first attack. So we have a

commitment that is derived from the transcript. We have a challenge that is uh completely independently created as a pre-witness. We uh we try to combine the tag from the two and as a result we get an exception which prevents us from making this mistake. So uh obviously there are some other attacks. So uh for example uh a lot of the problems in fiat shamir happen uh if uh we have two separate subprotocols let's say u one of the issues that can arise is that the challenge that is used for batching some of the information is derived just from one of the subrotocols like in this case

we are talking about uh plon as a result of the recursive plunk verification you usually end up with two group elements which should be used for pairing. Um you can go and batch uh two different recursive plunk proofs. So you have four elements you can batch them so that you end up with uh two pairs. Once again uh one of the vulnerabilities uh that I have seen in the past is that the batching challenge is generated just from the last one of them. This means that the uh malicious prover can simply change uh the values that are derived from the first uh element uh from the first proof in such a way that the whole proof uh

holds and the result of batching uh is considered correct by the recursive verify. uh to detect this issue we add additional information into the origin tags which basically tracks which transcript uh these uh values are descended from. So if you are instantiating a different recursive transcript that uses completely different data uh then it will have the ID of that transcript and whenever values from two different transcripts from two different fiat mirrors meet we immediately throw because why is this happening? Why are you using for example the challenge that belongs to one on the other? This is ripe for a vulnerability.

And as a result, when we're trying to merge uh the tags from two different uh plunk uh rec uh recursive uh plunk verifications, this is going to throw and this is going to protect us. Um the last thing that the origin tax uh can protect against is uh the uh the attack that uh is also quite widespread. I think um in the case of the last challenge attack and in the case of the plonky pre vulnerability, one of the issues was that the uh batching challenge uh was derived not from uh the end uh not at

the end of the protocol but uh right after the commitments uh to the wires. So after that you get the evaluation of the wires and you apply the batching challenge to the evaluations uh even though the batching challenge was derived before those which means that you can provide such evaluations that will always pass your further checks. So to pro protect against this uh we've extended the protocol with round provenence. Basically we have a special field uh which is 256 bits where the lowest 128 bits represent that this value uh is derived from some value in

the round uh that in the round with this number uh that was submitted by the prover. The higher uh 128 bits show that this value has uh in its history uh of uh derivation a challenge from the same round. Then we can uh add uh a mechanism that checks that whenever we apply a challenge the maximum challenge round in this uh particular uh value is more equal than the maximum uh submitted round. That means that we are basically not applying a challenge to a value that is uh that was uh submitted in the later round. As a result, when we're trying to

combine uh a challenge from the uh from the pre previous rounds, we immediately get a throw and this protects us from this batched uh challenge attacks. There are a few problems even with uh this mechanism. One is that all of the detections still have to be uh manually handled. There are some uh false positives such as for example the last uh step of the KCG is when you create the quotient. So this is the last submitted value. There are no challenges after that which means that where when you're computing the recursive verification of KCG this round provenence is going to fire off and the developer has to go in and say okay this

is a false positive this is uh something we can ignore across our code base uh across the ATC uh packages uh codebase uh there are 10 highlevel and 25 lowlevel uh false positives that we had uh to get rid of But uh so there is some work but it basically has to be done once and then you are uh just continuing using it. It also doesn't protect against fundamental logic bugs obviously. So if your protocol is uh incorrect it can't really uh help you and uh a reviewer can uh treat a positive as a false positive unfortunately. So you can't really

protect against that only by maybe uh pushing it into an LM. So yeah uh to summarize uh FIAR is hard to implement correctly. Uh it is possible to create automated detection that is uh going to help you find these issues. It doesn't defend from all the bugs. There's still it still needs some oversight and developers can still uh make mistakes. Uh but it does help. Uh, I'd also like to thank Luke, Sergey, and Lucas for their help with the mechanism. That's it.

Great. So, thank you very much. Have we got any questions for the moment? No. Okay. Yep. One over here. I think I'm closest race. Thank you. >> Um, Fat Shmeir has been around for so long. Um, do you have any insights into um what makes it so like what makes it so hard to implement correctly? Um, and and is there any hope of meaningfully uh moving past that?

Well, I think right now we are creating protocols which are huge and just created from many scraps basically, right? We're pushing a lot of stuff together. We are not usually formalizing how it interacts. There's no single proof usually for the whole protocol. So as a result, it is hard uh to check and then people simply make mistakes anyway. Uh so some value can be just forgotten. you're not really checking that the code 100% fits the specification. So it's just a huge complex thing. So it's easy to make a mistake.

>> So I don't know how you can fix it completely. Unfortunately, >> make no mistakes. Cheers. >> Thank you. Um I didn't quite understand how is difference between this how is this difference from Maryland like um you're incre you're adding tag at every step right >> yes all the interactions so you are adding two values it will immediately show you uh the issues yeah and this is this doesn't have a formalization of the protocol so it for any transcript that you use you take out the values for example out of there, you start using it

with a different value that is not connected to this at all. Uh it will trigger uh an exception. >> So each operation you do add tag. >> Yes. All it's not just the uh original elements that just exit the transcript or the verification or the arithmetic every time uh computes the uh the conjugation like of those tags >> and then tag has all the input to that operation. Uh yes. So it basically every time it computes from the previous ones in new tag and and it sees oh is there a violation on this one or not >> and and uh so you don't really like this is automatic

like you write and then somebody like there's a compiler that take the current code and add the tags step to it right. uh it's just part of the type system. Our recursive verification is written out as uh uh incircuit types in C++ and so you just do a plus b and automatically under the hood those >> yeah the compiler. Yeah, I understand. Thank you very much. >> Okay, any more questions? No. Okay, thank you very much, Inenti.

Okay, so a few things to let you know. Um, next up we've got the quantum question panel happening in here, but that will be in about 15 minutes. Um, but I'd say don't go anywhere because once we've had that panel, um, there's also going to be some money behind the bar for your drinks. So, I'm sure you might want to hang around for a few of those. Um, so yeah, you could probably take like a 10-minute break. Um, even if you want to just stay in here and hang about, but we'll get ourselves set up and then we'll have the panel. Okay, we'll see you in a minute.

Hello everyone. Hi. How are you feeling at the end almost the end of this ZK summit 14? How are you feeling? Feeling good. Was it good? Did you learn anything today? Um so we are here for the final session on this stage. Uh it's a panel with the topic being the quantum question. Quite vague, quite open, maybe a little bit on purpose. The format of this is going to be interesting. We are awaiting one of the panelists. Um so we are going to kick off with a little bit of an introduction to the problem space. I

feel like most of the people here probably do know why quantum computers could disrupt the cryptography we know and love, but there are people watching at home that might not be as familiar. And so I kind of want to go back to the like the reason why we're even having this conversation. What's the problem with a quantum computer for ZK? What's the problem with a quantum computer for blockchains for general cryptography? Oh, but first I should introduce who's here. So, it's myself and Nico.

>> Hello. Hello. >> And our panelist, one of our panelists for now, Justin Drake. >> Yeah, this is the highest moderator of the panelist ratio. You >> okay, so yes, that is the question. Why are we even afraid of quantum? What does it mean? What will it do? >> Absolutely. Thank you so much for having me in um on this IRL podcast. Um so the the main issue with quantum is that um they can take public keys uh and turn them into private keys. So normally only the asset holder should be able to have the private key. But now anyone who has sufficiently large quantum computer

can have access to these to these private keys. Um but not only do the signatures break, but a bunch of other things break. So uh for example the the snarks that we know and love that are pairing based uh things like graph 16 and plunk those break um and even relatively sophisticated infrastructure like the Ethereum uh data availability will will break. So that's based on on KZG. So for Ethereum we actually have in some sense one of the worst scenarios where we have three layers each of which need to be updated. At the consensus layer we have BLS signatures. At the U data layer we have KCG and at the execution layer we have ECDSA

signatures. And all of these have to be upgraded. >> All of them would break. >> All of them will eventually break. Yes. >> And that's a just the way you're describing a quantum computer. You're talking about it as though it exists today. >> Yes. >> But it doesn't like these aren't broken today, >> right? >> Okay. So they will be broken once we have a so-called croc which is a cryptographically relevant quantum computer. >> I see. >> And in order to achieve cryptographic relevance, you need to achieve a certain amount of fault tolerance. So you need to be working with with bits basically.

Right now we have analog quantum computers. Um and the error correction to get from analog to binary is actually non-trivial. And then once we do have fault tolerance, which we're basically almost there or even there, um we need to scale to sufficiently um to a sufficiently large number of of of so-called logical cubits. And for cryptography, we're talking roughly a thousand logical cubits. Um >> and where are we at? Like because the there are quantum computers today that are able to do something.

>> Yes. >> Yes. Um so >> I've actually never been completely clear on that. >> Yeah. So when you want to look at real quantum computers, you shouldn't be thinking in in logical cubits. Um it's just a layer of abstraction which is too detached from reality. You want to be looking at the nitty-gritty um you know so-called physical cubits uh that are the equivalent of transistors for for quantum computers. And there it turns out there there's different compilers to go from logical to physical. And one of the big breakthroughs just you know in in the last couple years has been unlocking this compilation which is a 100 times

more efficient than what we had in the last few decades. >> Okay. >> I have a >> please. >> Uh yeah sure. >> So okay. So I I am not an expert on the physics of this at all. Um but I've talked to people who are um and they say that um number of cubits is not really the problem. Um because you can replicate a circuit. The the size of the circuit is not the issue. The issue is that um there are still engineering problems with the error correction. But when you solve those engineering problems, the number of cubits is going to explode because the the reason

they're not making circuits that large circuits at the moment is not that they can't, it's that there's no point. >> Oh, >> so maybe can we introduce a lot of the concepts here? So we have our logical cubits which is we know Shor's algorithm breaks discrete log. So that's written we need a certain number of logical cubits is added. Then physical is what we can build. We have a translation from one to the other. What's error correction and why do we need it here? >> I I mean the the problem as I understand it is um still getting um it you you solve one set of engineering problems um and then you find another noise floor >> of course >> um and the noise floor is still um too

high to make a a computer that actually works. Um but I mean the bet of the the people who are working on this is that there will be point a point at which you solve the last engineering problem that is needed to make them to make them work. So um I mean that is why um I think that um I I believe the estimates that we need to be worried about upgrading all of our protocols within the next um well protocol evolution takes a long time so two years in order to prepare for >> an actual break >> a break in the next four years.

>> We should we should hold on timeline because I feel like there's going to be lots of opinions. >> That's a big question. Um, but just going back to what you were describing this history to the present, you had listed like an amount of I forget what the value um was, but it was like this is what we need to break cryptography. >> What was that again? >> A thousand logical cubits. >> Yeah. So, what do we have today? >> So, right now we don't really have logical cubits >> at all.

>> Right. >> Okay. >> Um, >> this is important I feel. So we have proof of concept demonstrations that we can do logical cubits and we can do error correction. But um there's two things that really we we need. One is the quality of the physical cubits to be good enough. And this is measured in so-called fidelities. And what we need for practical error correction is 39. So for every 1,00 operation, you need your gate to work 999 times. um and um for most platforms now. So if you take trap ions or um neutral atoms or superconducting, we're now at this point of three nines of fidelity. So that in

some sense is is solved. Um, the other kind of big issue is so-called real-time decoding where in order to do the error correction many times per second, maybe a thousand times per second, um, you're going to be measuring these dummy cubits that will tell you whether or not there are errors. And then based on what you measure, you need to be applying real-time corrections. >> And this is a purely classical problem that needs to be done in in ultra low latency. And the engineering just hasn't been done yet. You need to use basically FPGAAS and and GPUs and um you need to develop these low latency decoders. Um and for some reason like the physics is

ahead of the like the quantum physics is ahead of the classical algorithms um at this point in time. >> The classical algorithm side doesn't need a quantum computer to be developed. >> Correct. like this can run on the hardware that we have today. >> Yes. >> Okay. >> Um and in a sense there's a little bit of an analogy here with ZK where you know real time proving was this very difficult thing to do and we got it and now you know it just there just needs to be some teams that do the same thing for real time uh decoding in in quantum.

>> Is that what those labs are working on? like is does Google have a team doing that? >> Yes. So, a lot of the teams are working on on on quantum error correction and and decoders, but a lot of the different teams are working on the the different physics for the so-called different modalities. >> Um, and I happen to have a favorite modality um which is the the so-called neutral atoms. >> And there's kind of two reasons why um I I really like neutral atoms. the the the first one is that um they have this superpower called reconfigurability.

So you can take two cubits and move them physically to be close to each other and then you can tangle these two. So if you have for example 10,000 cubits, you can you know pick cubits that are far away and just have all toall connectivity and that means that your compilation from logical to physical is about 100 times more efficient. So if you have superconducting cubits where they only have nearest neighbor connections, so in a grid they're only connected to the four nearest neighbors, your ratio of logical physical to logical is going to be a thousand to one. So that you know that's what Darra was saying that um you know if you take uh Shaw which has a

thousand logical cubits and you have another thousand to one you're going to end up with a million cubits which there's no way you're going to fit on a single quantum processor. >> A single quantum processor can only fit roughly 10,000 cubits. So uh if you want to run straw for example on superc conducting platforms you're going to have to do networking quantum networking. And this is a thing that you know we haven't really solved. Um so in the context of neutral atoms you don't need networking because you only need a th00and * 10 which is 10,000 and we can fit 10,000 cubits on a single neutral atom uh processor.

Um and then the other reason why I'm bullish about neutral atoms is that um it's much easier to get the 10 to the number 10,000. So if you look for example at at superconducting cubits today they can only fit a a few hundred um and you know part of the reason is because you they have all of these yield they have to fabricate the cubits and they have all these yield issues and as soon as you scale the yield basically goes to zero um and it's just very difficult. And then there's this other platform called um trapped ions where basically um you have these charged particles and they don't like being close to each other. They repel each

other. So it's very difficult to get you know 10,000 in a single box. >> So for the neutral atom platform >> um so you you were talking about physically moving the atoms from one place to the other. Um this is not something that we do in conventional um integrated circuits. So how difficult is that in practice and in particular how difficult is it maintaining coherence? >> Yeah. So um in 2021 um I believe it was the the Harvard group that showed um a Mario animation where there was um 16 a 16x6 grid. So 256 uh cubits um and it was just you know showing Mario moving

as as as a video. And so you can you can control the cubits extremely well and it takes just a few milliseconds to move them from one place to another. And um the decoherence that comes from the movement is actually well below um you know the the the threshold that you need to do error correction. So that that's not the bottleneck. >> Okay. Yeah. Cool. >> So so that a few milliseconds that would be the cycle time. But I guess for an algorithm like shore where you have an exponential speed up that well technically you have an exponential speed up for grover as well but but where kind of it's just polomial in the security parameter um you don't need that many cycles right

>> yeah so you need about 100 million cycles so the expensive cycles are called like like well the expense the expensive gates are called toughly gates you have roughly 100 million of them Each one will consume roughly um you know one millisecond or so um and then you end up with uh roughly 10 days of computation to to to run short. >> Okay. >> I was just trying to work that out in my head. Yeah, that's about right. >> Um okay, so we're going to do a little shift on this panel because we just had one of our guests arrive. Uh hi >> Dara, if you want to do you want to stay? Uh, >> okay.

>> Perfect. >> Do we have another? >> Yes. >> All right. I want to welcome Dan Bonet to the stage, the guest of my 400th episode as well. What an entrance. Hi. You just got off a plane. >> I literally just landed two hours ago. >> Thank you so much. >> Rushed over here as quickly as I could. >> Thank you so much for coming. Um, so just to bring you up to date on what we've talked about so far, uh, we were really looking at like, you know, what are what are quantum computers, what can they actually potentially do with cryptography, but what do you need in a quantum computer to actually achieve that? And then we were trying to figure out what exists today on the theory, but also what exists in practice. Uh, Justin just introduced neutral atoms. uh we

kind of started to give a little bit of the distinguish uh we started to distinguish between the different types of quantum computers. I did want to say something that I think we said on our show which is like when you see quantum computers in the news when you see the this thing with all these wires that is the superconducting version of quantum computers and what you were talking about with neutral atoms is something else. What do those look like? So neutral atom quantum computers are in an enclosure of roughly one cubic meter.

Um there's no fancy cooling. It's just lots of lasers and lenses. Uh and in the middle there is this very small vacuum chamber which is maybe one cubic cm. And then within the vacuum chamber you have these atoms floating which are like roughly one cubic millimeter. Um, and uh, one of the cool things is that it's mostly off-the-shelf optical equipment and the the total cost of the machine will be a couple million dollars. When you compare this to the superconducting platform, you know, each of these wires that you talked about, there's at least one per cubit, actually multiple, and each wire costs about $1,000. So, if you need a million cubits to run shore,

that's billions of dollars just in the wiring right now. >> Wow. >> All right. The difference is that it's much faster. So the supering cubits are exactly faster computers than the neutral atoms, but they have but they have other problems like connectivity and so on. I don't know if you already talked about >> we well I think Justin you listed the things you liked about neutral atoms >> but I don't know if we shared these sort of disadvantages. >> Yeah. So neutral atoms are like great at everything except one thing which is the the cycle time. They're about a thousand times slower. So for Q day, you know what will um mark Q day? I think more likely than not it will be something like neutral atoms and unlikely to be superconductors. But in the long term we

want our computers to run extremely fast and so that's very bullish the the faster platforms. There is another disadvantage of neutral atoms which is the so-called fidelities. So there's some platforms like trapped ions that achieve four nines and if you go below three nines significantly below three nines then you you gain a lot but neutral atoms have three nines and that's you know good enough for error correction. >> Cool. >> You said floating um this this seems like another fundamental difference from conventional circuits.

>> Yes. So you have these optical tweezers um which are basically beams of light where the atoms like to uh stay where where the light focuses. And um there's different types of of of of tweezers, but one of them is is called a bottle where basically you um you surround the the atom with light and the the atom is kind of repelled on all sides uh by by the bottle. Um >> all right. So let's now that we've done this primer on quantum types of quantum let's bring it back to cryptography and breaking it or not like there have been the idea of a postquantum cryptography

was presented many many years ago I think actually who first was working on that was it like the stark team >> there are many there are many paths to postquantum cryptography >> um I mean there's like five or six different paths So you can't you can't really say when exactly >> when okay >> I think as soon as shor's algorithm was introduced people started thinking about what do we do >> and they started to make this >> uh microphone closer >> oh sure sure microphone close okay >> but okay so yeah like what do we like there's there's a question which is the hot button question I think here actually there's two questions one is do we think there will really be quantum computers do we need to be worried and the other is when if so and so on this

panel I think I actually we so we worked really we were talking to a few of you I don't know in the audience we were trying to find someone who really didn't believe that quantum computers would ever exist and we actually didn't find that person you might be here but we didn't get a chance to talk to you um we will open up the floor after so if you do feel that way we want to hear it but we were looking for someone to join us on this panel who was very like bearish ish who felt that quantum computers will remain in theory for a long time that we can rely on the cryptography we have today on this panel today I just want to check do do any of you believe that do you think that quantum computers will never happen

>> so my position is that um we have to assume that they will actually that's been my position for a long time but um we we have to upgrade the protocols anyway Okay. I I also believe that they will happen, but that that almost isn't relevant for cryptographic engineering. We need to update the protocols. >> Okay. >> Um and it turns out that we get simpler protocols because they just use um symmetric cryptography um more often. Um and so we should use this as an opportunity to simplify. If I take Zcash as an example, um so Sprout is a lot actually ironically closer to being um

uh postquantum. It's just the proof system that um is vulnerable, not the the thing that you're proving. The the cryptography um uh of the payment protocol is just based on um hashp images. So um and then when we went to sapling in order to optimize it we there was an observation which I think comes from the Coco paper um that um actually doing elliptic uh curve cryptography um over the right fields um right fields and curves um is very efficient in circuits. So we took advantage of that um and we needed to because the the circuit was really inefficient. Um but

at that point we didn't have um uh algebraic hashes that we were confident in. Um so that was the reason we why we went to um elliptic curve cryptography within the circuit. Now that we have things like Poseidon um so despite the recent uh crypton analysis of um Poseidon 2 um Poseidon 1.1's fine just just use it. It's fine. So now that there are hash functions, you would >> yeah probably >> and so now we know how to do um a lot of fancy cryptography um just using symmetric primitives. Um and we we don't need them for payment protocols. We don't need them for a lot of other things. So we should go back to using

that in the the postquantum world. um we still do do need um kind of semiructured things like um latis space cryptography um but it it's >> I I I don't think we'll miss um elliptic curves and RSA and discrete log over finite fields. I this is quite this is surprising to have Darra here saying this because a few years ago you didn't feel that way and of the people here like were you the most bearish >> up until recently?

>> I was quite bearish but also I um contributed to Sphinx um the which became Sphinx plus which became um SLH um DSA now standardized. Um, so I I obviously was thinking that this is something that we needed to worry worry about, but I was quite skeptical that we would even be able to get to the first step of Shaw's algorithm, which is create a a uniform distribution over cubits. This makes me want to ask now like is there anyone in this audience who does not believe that a quantum computer or who does not think a quantum computer will ever truly exist that it

will remain in the realm of theory and it's okay to put your hand up. Actually, I do not feel like I need to address that to be honest because uh these are just opinions. At the end of the day, we don't really know, right? I mean, quantum computers are n years away from an for an unknown value of n. Whatever opinion you hold, you could be wrong. And do we really want to bet the world finance financial system on an opinion that could be wrong? And so, I totally agree that it doesn't really matter at this point whether these computers will exist or not. Uh the fact that it's a threat and the fact that it erodess trust in the in the blockchains means we have we have to adapt. I can tell you that one of the things that's most

depressing to me is if we make the shift and we move away from our beloved elliptic curves and uh move to far less efficient systems and then 100 years go by and still quantum computers don't exist. I think that will be a crazy depressing world to be in. So if we make if we you know so if we make the shift we do all this effort to trans to transition all the blockchains to systems that are harder to use for me harder to teach. Uh it better >> that's the real issue. >> That's that's that's the real issue. It it better be that quantum computers are real and they're coming. Otherwise what the heck?

>> Okay. I I'm I am more optimistic about this world where we never get um quantum computers, but we have all of the complexity in our protocols because as as I pointed out we add complexity in some places and we remove it in others. So it's it's it's all actually a bit of a wash. >> Uh Yens, you just put your hand up. I'm wondering maybe would we be able to switch places? >> Oh, >> do you want to join >> musical chairs >> or do you want to just ask a question? I I will gladly I will gladly yield to Gen.

>> This is an unusual panel to start. >> Why don't we keep going? >> I I hope somebody else will will also have a turn. >> So, this by the way is a bit of a throwback to a type of panel I used to do, which was called the park bench panel. We didn't necessarily start this panel with that idea, but this will be a hybrid. We might talk more about that anyway. >> Yeah. >> What is your what are your thoughts here? I think I think my my question is is so like okay suppose quantum computers come about what is actually going to be the impact right >> suppose quantum computers >> yeah quantum computers uh >> quantum computers yeah >> yes >> postquantum computers it's just so ingrained in you know my wiring

>> um so but I'm I'm wondering so like what we should think about the consequences right because as I see the space we have like shor's algorithm sure that can do things we have algorithm and then we don't have that much more is my understanding right so >> actually that's not quite true we have a lot in fact there's a whole website it's called the quantum algorithm zoo it's actually worth checking out >> there's a huge number of algorithms that we have uh it's true that a lot of the problems are sort of algebraic in nature so this this stuff is very good well you know these things are very good at solving problems that have periodicity built into them yeah >> okay >> so they're kind of algebraic in nature But there's a huge number of problems that we can solve with these.

>> And would you say that they're so like different in nature from from what Shor's algorithm can do as it like derivative of that? >> Yeah. Yeah. Yeah. They go quite beyond shores algorithm is pretty simple. Uh it's been 30 years now. These algorithms have actually gotten much more complex and I mean they're still solving sort of computational number theory, computational algebra uh style problems. Uh but yeah, it's worth checking out. Check it check it out. the the quantum computing zoo, quantum algorithm zoo. It's a really cool website, >> but I guess shores and grovers, those are the o are those the only two that are relevant for blockchains.

>> Grover is not relevant. It's really it's really uh only shore. Gro Grover is not relevant, you know, just to I hope everybody understands this, right? I mean, so Grover gives you a quadratic speed up with a huge constant. >> The constant dominates the quadratic speed up for all real real life real world problems. The problem has to be unrealistic for Grover to become uh asmtotically practiced. >> So is Shore the only one >> that affects cryptography >> that affects not cryptography but blockchains this like blockchains that we popular ones?

>> Uh that's a tricky question. I mean so it could be that tomorrow somebody discovers uh a lattice algorithm a lattice reduction quantum lattice reduction algorithm and then all the blockchains that rely on MLDDSA and Falcon >> could also >> would be would be in trouble. >> Uh so we don't know. I mean right I I would say the field of quantum computing right now is really at its infancy because we don't have a computer. So that the number of people it's like you know the number of people who were writing code before computers existed you could count on one hand. >> Yeah. Yeah. Because that's what that is that's a it's an algorithm that would only work once a quantum computer exists.

>> Exactly. And you were saying there's this page full of all sorts of algorithms like that but in >> but we haven't really we've only begun once the algorithms once the computers exist now there will be you know everybody and their and their and their uncle are going to start designing algorithms for these things and then that's going to unleash a lot of ingenuity creativity and I think that's kind of where the applications will come in. >> I did not realize that was the framing. This is very helpful. >> Yeah. So I can I can think of one other thing that's quite different in a in a quantum world. Um there was this uh beautiful work of of on commitment schemes, right? Where the classical definition of a commitment scheme is that you can not create a commitment and

two different openings to that, right? And where it's actually a little different in a subtle way in the quantum world because um you can imagine creating a commitment somehow in an entangled form of two openings and then you measure one of the openings and you reveal that later on. But then so like by the non- teleportation theorem of quantum theory that means that the other opening is not accessible anymore. So you can so like which is really weird to think about right it's a very subtle way that the classical way of thinking about commitment schemes fails.

>> It doesn't work there. >> It doesn't transfer. Um >> there's a lot to say about that but do you want to maybe no we we can we can move on. >> Okay. Um, so I will put the question again out there. Are there people who don't think that there's going to be quantum computers? >> You have a >> You have a remark? >> Yeah. >> Yeah. >> Is he going to go up here? >> I don't I don't know. >> I don't I don't >> I guess. Yeah. This is the hot seat.

>> I wasn't planning on this, but uh >> this is what this panel is now. Oh, it's nice. >> So, it's not really my opinion. It's actually the opinion of Sarah Rash. He's a French physicist who won the Nobel Prize in 2012. And in ' 94, he wrote a paper called, I think it's quantum computing, dream or nightmare, in which he basically explained, oh, by the way, he got the Nobel Prize for developing methods for measuring and uh manipulating individual quantum systems. So, he knows what he's talking about. and in 94 he wrote this paper saying basically that we would never have a a useful quantum computer. I don't know if his opinions has changed. So my question was whether you know if his opinion has changed since 94.

>> So in 1994 um which is the year that Shaw was discovered there was a whole debate uh and the debate basically was around the quality of the cubits. In order to run shore, you need really really high cubits, high quality cubits with fidelities on the order of like 10 to the 10 to the minus 10 or 10us 12 or something. And no one believes that you can do that with natural naturally occurring uh cubits. And then what happened two years later in 1996 is that people discovered error correction. And actually it was Shaw who came up I believe with one of the the the first first schemes. And then in some sense that's partially settled the debate

where you know you can take these imperfect cubits and you can com you know compile them in in a way into bigger clusters such that the cluster is one virtual logical cubit. And so I think you know this opinion from 1994 was pre-error correction and it probably has been revised since. I could >> but I actually but I I I will go along. Let's continue with with the thought. So there is a group of people who object to quantum computers ever existing and the argument is well our understanding of quantum mechanics is wrong. Yeah. And so nobody has ever done experiments with superp positions of so many particles.

And it could be when we start to scale up the experiments all of a sudden we discover new physics and short shorter equation breaks down you know uh quantum mechanics is incorrect. Yeah >> rather complete maybe rather than incomplet uh incorrect maybe incomplete. >> Yeah. Yeah. That that that could happen. And I can tell you if that happens for example there's a paper that just was appeared last year that says the universe only has finite precision. So therefore uh quantum mechanics is only correct up to certain precision and not beyond that. Uh if that turns out to be true then shor's algorithm will never be implemented. The cool thing is we learn new physics. Yeah. And this is like a once in a century discovery of new physics. So this is like

>> migrated all of these systems Dan. >> We just m Yeah. Well then we migrate them back and BLS gets to live again. >> You have physics to teach >> because you you have you want BLS to survive. There you go. Yes, exactly. So, actually it is it is a I have been thinking about this quite a bit actually like what happens if we do the migration we wait a 100 years and a quantum computer doesn't appear. Do we migrate back? I mean how long do we have to wait before we migrate back? >> Also, won't all of those like the types of cryptographies the efficiencies like there is progress on all fronts like it it's possible that they start to match the Olympic cryptography. come back.

>> By the way, that that's not to say so I I should say by the way my my thinking has changed quite quite a quite a lot and that I used to be quite a skeptic about the the the the uh construction of these of of the computers just because of the very slow progress that we saw like with NM NMR methods don't scale uh other methods are noisy um I have to say with uh superconducting was a big step and then these neutral neutral atoms that has kind of changed my mind. We, you know, both Justin and I have been talking to a lot of the physicists who are building these um these systems. I can tell you the conversations they freak me out.

Like this stuff is is real. You read you read the papers, you know, they're uh running computers for many hours, maintaining coherence for many hours across a large number of atoms. Uh this these machines are not difficult to build. You know, one group says it's off-the-shelf equipment. Another group it says says custom equipment but relatively simple. You see there's like over 10 startups now going after neutral atom architectures because they're so easy to build. It makes sense that um startups would go would go down that path. Uh you see Nvidia actually by the way I don't know if you brought this up but quantum error correction interestingly is a hard classical computing problem. Yeah this I don't know if people understand this. One of

the bottlenecks in building a a shore quantum computer is actually the classical computation that has to be performed to do the quantum error correction. That is uh right now the the gates operate at millisecond rates. The um quantum error correction that or atomic is is reporting operates at seconds per gate. This is a classical computation. The classical computation is slowing down the quantum computer. So Nvidia actually got into this game and they are they said ah you know we know something about speeding up classical computations. So actually they're hoping that this is a new market for the GPUs basically running error correction for a quantum computer which I think is pretty interesting. Th

>> this is a constant factor engineering problem it's fine and this is going to >> yeah I agree I agree if the only problem is classical computation we'll solve that. Yeah. Uh that that I'm not worried that just right now there is a compute problem and so it's interesting to see uh how things are are progressing there. So I'm actually you know maybe I was playing devil's advocate and yes maybe we will learn new physics and shores algorithm will never be implemented but when you talk to these guys when you see the scale of the experiments they're doing what was it the last one is 10,000 cubit 10,000 cubits >> that's >> oh oops forget I said that >> yeah forget you forget you heard that >> 10,000 logical or logical physical >> yeah um the the other experience I've

had um that um kind of has moved me towards the um quantum computers are likely possible is the experience of being wrong on AI. Um so I I made the prediction in 2000 that we would not have um computers passing um chewing tests until 2050 at the earliest and clearly I was wrong. Um and so that experience of being wrong on a a long-term prediction about um technology um has made me more cautious about um things like quantum computing and a lot of experts seem to think that this is going to work. So um I don't know the physics well enough to contradict that.

Um and the fact that that fits in with um we have to upgrade the protocols anyway. Um yeah, I think it's fairly clear what we should do. Actually, I want to make one more point though. Go for it. >> So, okay. So, this was we talked about this in the show, but I want to bring it up to this audience and see the reaction. I do worry that there's a bit of a rush to postquantum. And that rush to postquantum is really quite dangerous. And there's an example I want to give actually two two points I want to make. Um the example I gave I like to give I don't know how many of you have heard me say this already, but let's just say it's a hypothetical example even though it's not. Um this company come came and told me that they want to

move to postquantum. Today their classical keys live inside of an HSM but the HSM does not support support MLDDSA. So what do they do? They take their keys out of the HSM and do the ML MLDDSA in a in a CPU in the clear. The minute you do this, you are way more likely to be attacked by a regular hacker than by a quantum computer. Yeah, that's the result of a rush to postquantum. So I want to caution people about the rush to postquantum. The correct action in my mind there is don't take your keys out of the HSM. Go lean on your HSM provider to provide MLDDSA support as quickly as possible. Yeah. This is why Google sets the 2029 deadlines so they can lean on

the on the hardware providers to say because of you we are not meeting our deadline. Yeah. So you better get your act together. That's the first point I want to make. Second point I want to make about the rush to postquantum is even if you set 2029 this is a bit for you Justin even if you set 2029 as your as your target deadline um this is a bit delusional because because uh just last month last month actually Intel came out and said that their processor is going to be postquantum only in 2030. So you might have migrated your system to be postquantum, but the processor you're running on will accept microode changes signed by a pre-quantum signature until 2030. So yeah, there's so just be be careful. There's a this is a very

complicated process uh and we should not rush it. >> It it it is reasonable for your attack model not to include um adversaries who have physical access to your processor to upload uh microode updates. Well, actually, I guess it doesn't require physical access. >> Sure, we can start defining postquantum however we want, but yeah, >> just a note there was Oh, there. Perfect. Okay, >> we have someone coming up who had a question and then Nico, you had a question next. >> Wow, look at that. Yeah, I wanted to maybe reframe your question in a way that might get more people in the audience to raise their hand, which is on the complex complexity theory side of things, which is uh we don't really actually know if from a complexity theory point of view, quantum computers

are actually better. I mean, we don't really know like if P equal NP or not, right? So, from that kind of lens, uh there's a chance that there is a polinomial time algorithm to solve some of these uh cryptography questions and we just haven't found it yet. Of course, we don't actually know the constants. Uh, but this kind of like is like a ties into maybe like some greater problems in computer science. I >> I have an answer. I have opinions. Um, so what we're really doing when we move to postquantum algorithms is we're getting rid of all of the dependencies on discrete log. Um, that that's for most systems that's what we're doing. um that works just as well against um a classical discrete log algorithm as it

does against a quantum computer. Um and I always frame it as um kind of we're fixing this protocol against a discrete logbreaking adversary. We're not specifically um uh uh protecting it against a quantum computer because as you said um Gro Grover's algorithm is basically irrelevant. You should choose your um key sizes um long enough, but you should do that because of multi-target attacks, not because of of Grover's algorithm. >> Okay, fine. So, there's one more switch, I think, and then we're going to wrap up our panel, but there is actually there is sort of the timeline question that hasn't really been answered. Your

favorite. >> Oh, but just very briefly, since you mentioned the risk of the rush to postquantum, >> Yes. Is there also any worry about rushing to latises when we don't know enough about latis assumptions? Hash functions I think we've seen for a long time. But yeah, >> uh Justin, do you want to take that? >> You're dropping. I mean there is also a question in the hashbased world like we should we be rushing to pose on um and hopefully we won't be um and you know we're looking at all the alternatives and we're trying to do as much due diligence as possible um on the latises I think there's like a real question as to you know whether

so we do know that I guess there the assumptions are about 30 years old right so a lot of mathematicians have have looked at them, but because there hasn't been an incentive to to break them, to break real world systems, maybe we, you know, it's just not not not not battle tested. On the on the other hand, the the the Merkel signatures that we're we're looking to to deploy, the the so-called XMSS, where the M stands for Merkel, these are 50 years old. Um, and um they're extremely simple. And I guess one of the comments that that Dan made is that you know the cryptography that we're deploying is more complicated.

Well, I'm hoping that it's in some sense less complicated at least in in certain parts. Um but yeah, like one issue with the latises is that you have to be an expert in order to set the parameters. Um and there's also as Dan mentioned there's a possibility that we will find uh a quantum algorithm to break latises. There's also a possibility exactly or classical one. So if you want to build a system that is likely to last you know decades and centuries I think hash just a personal opinion hash functions are the way to go.

>> No encryption. >> Yes. Yes. >> Um yeah I mean you can do hash signatures. Um the um what was I going to say? So >> I have something to say. Can I can I >> do you have >> um one so has anyone worried so you talked about these quantum algorithms is there more focus okay let me try to frame this if there is the assumption that quantum is coming will people focus more on these quantum algorithms instead of the classical ones that could break existing systems like will we almost get like a mind share problem if everyone

starts like if if everyone buys into quantum >> quantum algorithms uh they are a super superset of classical algorithms. >> Okay. >> So if you're designing a quantum algorithm by definition you also or rather if you're designing a classical algorithm it will that's also that's also a quantum algorithm. >> But I'm almost wondering if the mind share goes too far into quantum and isn't then reusable in this classical sense. This is more like a social question like >> I mean the the attention >> random random thought >> the attention sorry to interrupt the attention on um kind of postquantum cryptography that's how a lot of the isogynes based systems like um like got

broken. So um and they were broken not by a new algorithm but because people hadn't noticed that there was an existing algorithm that broke them. that that's a bit of an oversimplification and it doesn't apply to all of the isogyny based schemes but that that's a brief summary. Um so yes there will be more attention on um the algorithms that are being used in uh the the assumptions that being used in postquantum cryptography. Um that's fine because um latises um the there's actually a lot of dependency on um latises in in conventional um cryptography because um kind of uh ll the the um the main

algorithm used to break um latis problems is also you used in um sort of classical crypt analysis against various things. So um yeah, advances in those algorithms aren't just going to break the um postquantum stuff necessarily. >> Uh the oh other thing is um hybrid. So um basically if you're doing um >> did you say hybrid? >> Yeah. If you want to upgrade your um protocol to um postquantum encryption say then you should just use um X-wing which is a hybrid of uh ML cam and um uh um ECIS basically which is what is

deployed on the web. But by the way when uh Intel said they're going to become postquantum they mean they're going to implement MLDDSA in their processor. And so, you know, if your processor for security depends on the security of MLDDSA, you're kind of lattis based regardless whether you want to or not. So, we're going to have lises in our lives at any any rate. >> Would it make sense to talk about timeline? >> The reason The reason I want to talk about timeline is because you're here, Justin, because I feel like you're one of the most bullish people I know. I asked I I kind of quoted you Dan today

to Justin. I said, you know, Dan says the 2029 date is more coming from the security teams, not from the physicists. And you disagreed. >> Yeah. Well, as as Dan mentioned, we've been talking to the physicists recently and um there's been a lot of developments in the last few months. Um but yeah, if you rewind the clock uh to uh October 2025, I was actually on the bearish side of things. Uh but what happened in October 2025 is that we organized this uh postquantum workshop in Cambridge and we had this uh guest invited speaker who happens to be um a quantum entrepreneur and he basically totally shifted the Overton window. He said Shaw is going to be coming between

2030 and 2032 and everyone in the room was like and he he's had this prediction for 15 years now >> and it basically hasn't changed. He just he just says, you know, you have this exponential growth. You just, you know, draw the the lines and it it kind of lands there. And >> you know, by the way, Khi disagrees with that. So the prediction market will will give you odds against uh before. >> Yeah. Interested. >> Dan Benstein's prediction which he's also had for 15 years um is consistent with um that one.

>> Um okay. So where was I? Yes. So in back back then in 2025 my odds of there being a quantum computer by 2032 was about 1%. I kind of gave him the benefit of the doubt. It was a possibility. And you know in our context 1% is quite a bit right because we're securing you know half a trillion dollars. Um but then um in February 2026 I got you know early access to draft from from the Google paper. And here my odds went up dramatically to about 10% by 2032. And then when the p paper was published, it was it was this concurrent publication of the oratomic paper with neutral atoms. And I've basically spent the last month and a half learning about neutral

atoms. I've been obsessed. I've watched all the YouTube videos that you could find. I've read, you know, a bunch of papers. I've I've had conversations with like half a dozen experts. And now I believe that by 2032 there's a 50% chance that we'll have a quantum computer. >> 2032. >> Yes. But the thing is that 50% chance is just way too high like we have to upgrade before then and I have this notion of the effective Q day which is you know the the working date that we have to have in mind by which you know the sufficient chance that a quantum computer could arrive and you know roughly speaking is let's say 10%. And I I believe now that there's a 10% chance that in 2030 we'll have a quantum computer and and therefore we have to

upgrade before then. Hence the 2020 2029 timeline. >> So that's that's a a security analysis that drives the 2029 number which I think is exactly also what the Google security team did >> 2029. Yes. My I I interpret the 2029 number to say let's talk about Google not so much. The Ethereum Foundation is actually on a good path, but for Google for them to transition their entire infrastructure to be postquantum is a crazy hard task. They have to replace a huge number of their hardware devices and it's a crazy hard task. It's most likely they will miss their 2029 uh target. Um but even if they miss it by three years, you know, we're 2032, maybe that's we're still safe. if they set if

they stuck to their 2035 number and they missed that by three years, now we're getting into pretty dangerous territory. Yeah. So, I think this is part of the reason why they decided to set 2029 as a as a goal. And I think for the Ethereum Foundation, it's a great number, too. >> There there's also the time taken to deploy infrastructure, which as I said before, people always under underestimate. So, it's not just blockchains that have um a potential governance problem that makes um upgrades take years. Um it's PKI. Um it's HSM as we've already mentioned. Um so, yeah, estimate three years just for people to get their act together.

>> The thing that that I'm a little worried about is the public here is 2029 and they say, "Oh, wow. We're going to have quantum computers in 2029." No, that's not I don't think that's the message. the messages, the upgrade, the transition has to be done or at least we should shoot for 2029 so that if we miss, we still have a margin of safety. It doesn't mean that 2029 is the date when we're going to have a quantum computer. Yeah. And even even the Well, okay, fine. Maybe some physicists are aggressive about 2029, but even many of the people we talked to are, you know, they give low odds for 2029.

>> Will we see signs along the way or is it going to be a one shot? >> Okay, that is a But there's also the famous question of why have we not factored 21? You know, I think those those kind of all those are >> two different mix together. Oh, >> all right. Okay. Yes. >> Maybe maybe we should Well, should we talk about 21 or should we talk about that we're going to see signs? >> Go ahead. 21. >> So 21 21 is not an easy problem. So when you when you write Shor's algorithm for factoring 21, that's about 200 gates. Yeah. Today we we can't do 200. Actually, I I guess they said that maybe even without replenishing they can get roughly to 200.

>> Well, you need error corrected gates which we don't really have in real time now. >> Well, we that's my point. I mean, we we Okay, so they talk about replenishing, but definitely 200 gates we have to do error correction. So, the first thing is you have to get error correction to work. Error correction only started working in 2024. So, this question of 21 was like irrelevant before 2024. Um, yeah. Now that now that things are starting to to to work, 21 is coming within scope. In fact, it's interesting that they were saying they might be able to do it without replenishing um which is uh still with error correction but without replenishing which is interesting. It's just that that's like not they're not interested in doing in doing that. Why would they factor 21?

That's like the the question they always ask. Um, so right now it's kind of not it's maybe on the boundary, but within a year or two the circuits will be big enough to to do that and hopefully one of the teams will actually do that. So that will put that uh debate to rest. >> I Yeah, I'm frustrated by these papers that say um we things like um I can factor this um faster using a VIX 20 than um using a simulation this quantum algorithm. Um it's it's it's a silly argument because the problem is getting c um error corrected cubits at all. Um and then Shaw's um algorithm is polinomial time. So um everything goes very fast after that point.

>> So will there be signs along the way or will we suddenly have >> do you want to say to the mic? >> Oh sure. So will there be signs along the way or will we suddenly have error correction uh factoring way bigger numbers than 21 and breaking all our cryptography? I'm not the person to answer this. Um, but from what I can tell, it's now just engineering. So, you know, I I used to use this Mo Moore's law model to try and predict like when like the reason I used to say 2040 is you do a Moors law calculation and you kind of get 2040 and I mean after talking to these to the physicists uh to again and again, they all seem to be of the opinion that Mo's law is the

wrong model here. It's not this stuff doesn't evolve linearly but it evolves in jumps. It's like human of flight right there was one day where humans couldn't fly and the next day humans could fly. Uh so this stuff evolves in jumps and as a result Mors law is actually not a good model. So predicting has now become very difficult. Um uh and then will will we see you you're asking also will we see progress that that actually is a very touchy topic. um let's just say the fact that the Google paper had a zero knowledge proof in it rather than the actual circuits >> suggests and they're very clear about that that there might not be as much transparency going forward as we have

seen in the past. So it could be that um I don't mean to >> I don't know to I'm not not sure to say it. I'll say it anyhow say it >> because that's what that's that's what they're telling us basically. could be that like five years go by where we don't hear of any progress, but that doesn't mean that progress isn't being made. >> And even when we do hear progress, that progress could be stale. >> Well, on that note, uh this is actually I've been getting signs for the last 15 minutes to I have five minutes each time. So, I think it is probably a good moment to wrap up. we also brought you back onto the panel so

it was a full circle. Um I want to say thank you to all of the panelists, spontaneous panelists for joining us. I want to say thank you to this entire audience. Uh thank you for coming to ZK Summit and joining us for another edition. Yeah. Thanks so much. Oh yeah. And we're not quite done yet. We actually uh just sort of spontaneously as well decided to grab a few drinks at the bar uh on us. So there is a tab. Please enjoy a few drinks in the lobby and we'll get a get a chance to continue our conversations. Till next time. Bye.

That was an awkward end. Why did I do that? Bye. Thank you guys so much.