Zero Knowledge Verification Technical Workshop

Great. So, um yeah, welcome everyone to the uh zero knowledge verification technical workshop. Um this is the first technical workshop we're running under Kadano Vision 26. Um so, uh yeah, we've had a we've had a really good response to it. Uh and we've got some some interesting um presentations uh to share with you today. Um my name is Fergie Miller. For those of you who don't know me, I'm the director of research partnerships here at um at Input Output Group. And uh I'm just going to set the scene by just sort of providing a bit of context around Kadano vision 2026 and then I'll hand over to my colleague Jesus who will introduce the speakers. Um the aim for today is to have a technical discussion around around this this program of work uh particularly around uh you know the team will show that talk you through the work that that they've been undertaking. Um uh but we're particularly interested in having a a discussion moving into a roundt discussion around product product requirements and specifications and then uh as a sort of first part and then um as a sort of second part sort of road mapping and implementation. Uh so I know we've got a number of community stakeholders um on the call today. Um some notable ecosystem labs as well. So, so we invite you to to come forward with questions. Um, I think I think the presentation is actually three presentations. So, I think the the respective um team member will present and then we'll have some discussions at the end of each of the three um presentations uh and and then move into a a general Q&A. Um so just to set this Jean slightly um uh so this sits under um Kadano vision 26 which which itself has three um strategic focus areas um human- centered scalability and and postquantum security. Uh and you can see that the um I've actually highlighted this on the next slide, but you can see that the layer 2 and zero knowledge execution is a key part of our of our scalability um uh theme within within the the program of work for this year. Um, for those of you who aren't fully familiar with with the shape of the the IU proposal, it's broken down into six technical work packages um within which each sits a couple of programs or or focus areas and then we actually have a seventh um delivery and and and dissemination and partnerships work package as well. Um so I just wanted to provide everyone with an overview of of um of that body of work and our approach approach for the year. Uh and I think I think the other thing to to note is is is our evidence-based methodology at at IOG. So we have a research team that that focuses on fundamental research uh and that quite often culminates in a paper but increasingly a sort of more practical technical report. Um we then um uh will then prioritize a stream and hand it over to an applied research team to undertake a technical feasibility. Um so that includes formal analysis um prototyping simulations and specifications uh uh and at the end of that work all being well um that that stream should then be implementation ready. And what I mean by that is ready to hand over to an engineering team to then implement um through to through through to through to mainet in in most instances. Uh so so this is sort of the the technology readiness um uh maturation that that we approach. Uh and you can see here that that the the the team today um our applied research team has been working at a sort of early midtl 3 to five um with the aim of getting this work um prepared for for implementation um early in 2027. Um we do integrate with uh Kadano um uh sort of ecosystem uh uh or community sort of platforms. So we're increasingly publishing Kadano problems statements at sort of TL 23 and then Kadano improvement proposals um at sort of TRL5. So those are sort of the stagegate um uh opportunities to engage and and with the community more formally. Um so so anyway I just wanted to to to sort of um provide that background context and then and then you know the purpose of the call today. So we we have a call for partners out. We're looking for for organizations to to um contribute both to specifications uh and requirements when prototyping and and and you know increasingly earlier than that when we're doing the research and then and then we obviously have have um uh the road mapping and and implementation handover uh point as well. So we got we got three presentations um uh today on on Grath 16, Halo 2 and and Plonky 3. So um yeah and and and we're slightly learning as we go um it being the first one, but the aim is to run a number of these this summer and then and then uh announce a full program of of technical workshops from September onwards through to the end of the year. Um so anyway, that's that's enough from me. Jesus, I I'll hand over to you to um sort of introduce the speakers as it were. >> Sure. Thank you, Fergie. I will not take much time. So um like Fergie said, the work that the team has done focuses on improving Cardano's knowledge capabilities and uh the team here present is Dimitro who has been leading the stream as a technical architect. Yeah. and cryptographer as well and GLU and Rafael Toledo who are applied cryptographers in the arc team and yeah that's it done a great work I'm sure you you will appreciate it is yours to meet >> thanks Jesus um yep hi everyone um happy to be here today and to present some of the work that um our team has been doing um recently um As Hessa said um I won't be presenting alone and also um G and Rafael will also join. We were we were working on somewhat different topics but all related to K verification on Cardano. So um I will probably start with a general overview of uh all the work that we were uh doing and then each of us will present uh its own part. Um yeah so from the start our goal was kind of open-ended. We wanted to explore what we could do to make ZK applications more accessible and more practical on Cardano. Um there is already a lot of work that has been done in in this direction by other teams. Uh but we wanted to explore some um new opportunities. So we did some research and find out um what could be the most useful and eventually settled on the three items that we think are important. Uh so these are these three uh topics. The first one is the wrapper for the gross 16 snark proofs. Uh the situation today is that a lot of the existing tooling in the blockchain space is built around gross 16 proven system and not only over gross 16 also over um BN254 elliptic that is used um underneath which means that it cannot be directly used on Cardano because Cardano does not support uh BN254 arithmetics. So the idea was to develop uh some sort of converter of these incompatible gross 16bn proofs into Cardano compatible BLS proofs and this way we could uh connect a large body of um existing projects and toolkits um to our ecosystem. So we saw this as a high leverage and relatively loweffort work that is um worth doing. Uh the second track is uh about exploring postquantum secure province systems in particular. Uh we were looking into plonis restart and how feasible would it be to to use it directly on Cardano. Um this is closely related with the broader postquantum migration effort that IOG is uh undertaking now. Um for example uh postquantum secure provenence system would be needed um for accounts migration or it could be useful for signatures aggregation or um other stuff as well. And the third track uh is a deeper analysis of the Halo to onchain verifier. Uh we were already building some tooling for Halo 2 on Cardano. So um this is kind of another step to support those developments. And from from our experience, we knew that verifying Halo to onchain could can get um expensive depending on how the circuit is structured. So the idea was to dig into onchain cost structure and and provide some insights on how to build circuits that are efficient to to verify onchain. So yeah, so these are the three tracks we focused on and uh I I personally worked on the first um and um uh so I will now um dig more deeply into the first uh track and then later my colleagues will um deep uh dig more into the the other one. Um yeah so uh so it was about wrapping gross 16b proofs into cardano compatible proofs um I guess many of you know what snarks are so I'll not go into all into details of that just for completeness we'll remind that it stands for saxin non-interactive argument of knowledge and to put it simple it's it's a way to produce kind of a short proof that some computation was done correctly short enough that anyone can check it quickly without redoing the work or or seeing the old list of original inputs. An example could be for instance uh proving the current state of a blockchain without providing like all the blocks and reverifying every transaction and u zk space has really thrived over the last years and and many different systems uh appeared uh each with its own trade-offs and among them uh gross 16 became arguably uh the most popular for blockchains because it it its proofs are small and and cheap to verify. And this is what this is exactly what we want to to to have on the blockchain where the onchain computations are uh limited and u expensive. Um gross 16 relies on uh elliptic curve cryptography and the it can be instantiated over different curves uh for example BN254 or pls 12381 or other alternatives. And uh if you look uh across the ZK space um we we may notice that a lot of the tooling has converged on um gross 16 proofs over the BN54 curve. That's largely because for a long time uh BN was uh kind of the only viable option on Ethereum and and so much of the ecosystem grew around it. Um Cardano on the other hand support a different curve uh BLS 12381 which is considered to be more secure. Uh so kind of uh the problem is that even though the proving system is the same, Cardano cannot efficiently verify gross 16 proofs created over BN254 curve because it just doesn't have necessary built-ins and necessary native support for it and uh reimplementing them directly in a in in a in a contract would be just uh too expensive. So the solution could be uh to recursively kind of wrap u this bnb based proof inside a BLS based proof. So you can think of it essentially as a some sort of a translator. It takes any gross 16bn uh BN proof and and converts it into one that Cardano can verify natively on chain. Why is that useful? because it connects Cardano to to a large body of work that already exists out there and and to the already deployed apps. Especially it was interesting to bring to the Cardano ecosystem uh ZKVMs like risk zero and SP1 that um at the moment produce gross 16b proofs as as a sax output. So, so we built that idea into actual toolkit and here is uh the the general architecture in one picture at the top uh uh at the top are the incoming proofs from uh different source systems. So today we support risk zero and SP1. Uh they they both produce a gross 16 overb and each source has a small plug-in whose job is to kind of normalize the uh the proof from from that system into one canonical form which is then processed by the wrapping core which does the this recursive step reproving over the uh BLS curve that is um native to Cardono. And this this could be done using a uh different engines. Uh today we support GNARC uh that provides out of the box two proven systems for for wrapping gross 16 and plunk. And and finally the tool to toolkit also um allows to generate the corresponding I can verifier for you so that you can verify this translated proof on chain on Cardano. Um, one of the one of the goals, one of our goals was ease of use so that this additional conversion step could be integrated into a workflow that developer already has. And and here is like a simple example how this actually could look like in case of risk zero. The idea is that you just extend an ordinary risk zero program with a few lines. Um uh first the plug-in turns the native receipt from from risk zero into canonical form and then the wrapping engine kind of reproves it over BLS and uh then finally you could also uh generate I can code that verifies this proof with um with all the unit tests for your particular source system and and then basically the idea is that you could you could use that code to to integrate into your >> [clears throat] >> um particular application. >> Um yeah uh I won't go through all the details here but there are like full runnable examples in the repo that show um kind of the full workflow on how to use this um toolkit for the wrapping engine itself. Today we use Garch. choose it because it's very efficient and well-maintained um library and it gives us two proven systems out of the box um cross 16 and plunk each with its own uh pros and cons. uh cross 16 is the fastest and and produces uh smallest proofs around 5 seconds on um ordinary laptop but it requires a trusted setup for the for this wrapper circuit uh which is quite a delicate procedure and plunk avoids this trusted setup. So we can reuse like already existing one but it's roughly 10 times slower to prove. Um um all in all both produce proofs that fit comfortably within Cardano onchain budget. The difference is mostly in uh in in the offchain proving time. Um so what this toolkit could be useful for uh it's still a prototype but it's already good for fast experimentation in the sense that you can take a ZKVM proof or ZKVM program and quickly turn it into something that can be verified onchain on Cardano. Uh what does this unlock? uh a bunch of different applications that are based on ZKVMs and not only as I said we could wrap any gross 16bn proof. Uh for example an interesting use case could be to verify um an Ethereum or Bitcoin state on Cardano. Um one example that we already have in the repository is uh proving ERC20 balance uh of an Ethereum account. [snorts] It's uh implemented with the help of risk zero steel library and under the hood it allows to prove real EVM execution to extract the the balance from from committed a serum state. It's something that would be very hard to implement directly on in Cardano smart contract without using ZK proofs. So uh we we can do really powerful things using uh ZKVMs. uh we could also for instance deploy a SP1 based HOS client that proves kind of full Ethereum consensus in ZK and and verify that on Cardano as well. In general um risk zero and SP1 ecosystem they already provide kind of a lot of uh useful libraries that we can just use and then connect them to Cardano. So it it really gives a developer a very powerful tool to build all sorts of um ZK applications and uh yeah I'll probably stop here um if if there are any questions I would love to answer or we can move to the next speaker. Uh hi Mitra uh thanks for sharing this interesting uh architecture. Uh my question is about this uh uh wrapper that transform one uh proof to another proof. Uh I know that there is a well-known issue that and you mentioned it about the uh trusted environment where this code execute uh executed. Uh do we have any solutions for this? Because [snorts] as far as I know in uh our department we also work on kind of verifiable credentials and usually when we transform uh one uh credential which is signature or also some kind of zero knowledge proof to another uh form of zero knowledge proof. we uh lose kind of region signature and uh some important information. So uh my question is uh what is the right way from your point of view to build the trusted chain that the final verifier can trust all these uh transformations. Um actually there is no trusted component in this transformation. It's fully trustless and fully transparent. Um and it it's basically um verified by the cryptography side that anything was was uh uh compromised during this pipeline. And but there is no uh any trusted component in this workflow. We just convert one proof to another one. >> Did I understand your question correctly? >> Uh probably yes. Uh in my case, the final party that is going to validate uh verify the final proof uh should be um should somehow check the integrity of this transformation because uh they might be um configured to trust only the uh original proof that you accept. as the input for the wrapper. >> Yeah. But I guess this is the whole point of this wrapper is that the wrapper proof actually proves that there exist another external proof and that that proof is also valid. This is kind of the claim that the wrapper doing and this is enforced by the cryptography. Got it. Thank you. Raphael did you have a question as well? >> Uh no it was just about this. So the there would be a tiny TR component which would be in the P of to if you choose the core 16 but not the hello 2 verifier from the from the wrapper but the Mitro has written a has worked on a generic wrapper and so we only need to generate the power of once for for this wrapper and it can be used actually for for many applications. So the trust would be quite limited then you also have the trust of the CRS if you are wrapping a core 16 proof in that 16 proof of the of your inner application let's say but the verification key would be exposed the proof does not really need to be exposed as mutual said it's it's quite big we can just be make it part of the witness and just the security of stacks tell you that I know of a proof that uh satisfies this BK uh this public input and so on so this should be enough uh but so the the only trust components you you might have would be for the pose of to and one is the original application and the other it's only for the wrapper if you use core 16 and it can be shared for by many operations that's that's all I wanted to add >> um there is another uh interesting question in in the comments why why not to provide uh for example in risk zero support for pls 12 381 one elliptic curve. And yep, let me be honest. This is um uh this would be more efficient if we directly modify risk zero and introduce support for BLS. Uh but there are two uh two two issues not issues but two comments on that. First, it's uh it's uh bigger engineering work. So you would need to modify risk zero directly. Um and second it's not always possible. We also consider use cases where you need to to to to convert and verify on Cardano proofs that already exists. So um yeah it might not always be possible depending on your use case. Uh yes Paul. Uh yeah, if I can uh because um I mean navally looking at this uh it would be just you know uh interfacing properly elliptic curves uh operations right you know pairing uh uh I mean multiplication things like that and uh I mean so naively it would you could add any support for analytic right there I mean just nly looking at this so >> I wondered I that that that's why this question. >> Yeah. Yeah. But I I see this work as complimentary. So we we target kind of different use cases. Um yeah, as I said uh it's kind of a different task and I know some some people are working on that. Um yeah and u in general it would be more efficient if if we produce pls proof directly. Yeah, maybe one further clarification for Remo and then and then we can move on to the next next presentation. Uh, okay. I think I think yeah. So, so RML's asking uh why not introduce the necessary built-ins in Pluto's core? >> Oh, it's in general very difficult especially if we introduce the new cryptography. So I'm not sure there is um agreement to introduce new elliptic curve. It will be a very huge effort. Um okay great. So so um thank you Demetri. Let's in in the interest of time um let's um move on to the next uh presentation and you know um we can we can always come back uh to this uh once we once we've finished the the presentations if there are more questions. Uh so I'm going to walk you through the visibility study we did on verifying the uh plank key3 proof in pr next uh why do we choose plank3 plank 3 is a production grade stack framework it's a general toolkit not a specific scheme it powers succeed SP1 SP1 is a dominant zig virtual machine uh there are light clients, bridges, roll apps running on top of it. Uh, PL3 implements hash based stacks. These are the most mature wellstied proving system. Uh, it only uses hash functions and small field arithmetics. There is no uh curves or pairing. So, it's a postquantum secure. Uh, this is beneficial for Cardano's postquantum transition plan. As we all know the hashbased postquantum signatures are huge in size uh typically 10 to 50 kilobytes. Uh we could use a postquantum zk proving system like plunky 3 to aggregate n signatures into a single proof. So it reduces the storage size and reduces the verification cost. Also we could use plank history to prove the ownership of the legacy UTXOs. Uh once Cardano transit away from the ECC signatures, the old UTXO cannot be spent anymore, but uh the owner can still claim them back by generating a Z proof uh to show they know the underlying pre-image seed that can derive the correct public key. Uh PL3's implementation is very modular and flexible. uh it supports all the small fields, baby bear, koala bear, goldilocks and the different hash functions, commitment schemes, mostly firebased ones. Uh it's very pluggable. These components can be swapped individually depending on what you want for the applications. Uh next one. So what did we build? We implemented a prov concept for the ST verifier in icon contract. Uh we generate a PL3 proof convert it into a icon contract call uh to call the stack verifier to check if the proof is valid or not. It also gives information about the amount of uh memory and the CPU that consumes. Uh inside the stack verifier we implemented uh small fields arithmetics and their extension fields. Uh the pro shape check verifies if the proof has the right number of uh fire rounds, number of parties, the trees w and portion chunks. Uh familia transcript hashes all the commitments from the proof uh in a fixed order to generate random challenges. uh these challenges will be used in the following PCS verify and the conraint verify. So this is a component that makes the proof non-interactive. Uh PCS verify fold the five layers to check if the batch polomia is indeed a low degree polomia. Uh so the n polomials are batched together into a single polomia using the random challenges. So we only need to do one fry instead of n fry. uh conjify checks if the circuits conjints are all satisfied. These conjints are also represented as polomials. Uh next one stack proof is huge in size hundreds of kilobytes and it burns a huge amount of memory and CPU to verify improvements. Uh but there are some parameters we could twist to reduce the proof size. Uh it's a trade-off. Uh for example, uh we have this factor called lock blow up. Uh when lock blow up is set to two, we need at least 83 query proofs to reach about 93 bit of security. Uh because we have a lot of query proofs here. So uh we have a huge proof 444 kilobytes. verify this prov consumes 681 million memory and 233 billion CPU. Uh but if we increase the log blow up to eight then we only need 22 query proofs to reach the same 93 bit of security and this gives us a smaller proof 186 kilobytes. uh the memory uh cost is reduced to 220 million and CPU reduced to 75 billion. Uh but we cannot uh continue to increase the log bl. The reason being the it significantly affect the proving time. Uh the proving time grows exponentially and the circuit capacity shrinks. The summation of the log blow up and the circuit degree is upper bound by the two oicity of the field. Uh if we use too much in log blow up then we won't have much left for circuit degree. Uh which means we cannot prove any meaningful computations inside the circuit. Also the commun sound will fall if log grow up increases. At some point this Sunday speeds fall force too much uh we won't be able to reach the security target we want. So the highest lo we can have here is eight. But this proof it's a smaller proof but it's still big compared to the kadano's single transaction limit. A single transaction can only have up to 16 kilobytes in size. Uh 16.5 million memory and 10 billion CPU in computation. Uh so what can we do? Next one. And we have a few options. One potential solution is to split the proof of application across multiple transactions. Uh the good thing about the stack proof is that uh this query proofs can be verified individually. Uh so each query proof can be verified uh individually and the ET query proof for verification costs relatively low amount of memory and the CPU. Uh for example, we have here um 9.47 million for memory and 3.23 billion for CPU. And this is small enough to fit in a single transaction. The rest of the uh part of the proof verification is the shared work uh including the transcript, hashes, computation, PCS setup and the circuit con verification. Uh this part cost 11.8 million memory and 4.1 billion CPU. So this is also small enough to fit in a single transaction. uh so we could split the proof application naturally by the uh queries and it won't introduce too much overhead. In total we should be able to verify the full proof with around uh 23 transactions. Uh if this is still too big then we are also considering other options like uh hydro. Uh we could use hydro to open an offchain communication channel with increased transaction budget so we can verify the proof with less transactions. Uh we are also considering using the optimistic verification to delay or avoid the verification of the four proof. uh anyone can challenge in the validity of the proof with a single transaction. They can either challenge in the single query proof verification or they can challenge in the shared part of the proof verification. Uh so that's all from me. Thanks J. So I think there's one question from Julian in the in the chat. Um, is it possible to cut traces to make the verifier fit into 16 kilobytes? >> Uh, what do you mean cut traces? >> Julian, do you want to expand on that? Um, Whilst we wait for Julian, I mean, you can um take off your mic or use use the uh the chat, Julian. Um uh and whilst we wait for that, does anyone else have any questions for Jia? Um so chunk the AIR traces. Uh so here we um we are experimenting the circuits with just a a very simple uh Fibonacci circuit. We only have two trace. The trace wise trace w is only two. The proof size is big because of this query proofs. It has the marker commitments and the uh open values the query u inside the query proofs. >> Thanks. Yeah, very clear. >> Okay, great. Any other questions? Okay. Well, let's let's move on to the third presentation. Thank you. Thank you, J. >> Yeah, thanks a lot. Uh we turn off the fan. Sorry, it's really hot here. >> Well, at least we're not used to it in the UK. Uh so, I'm Rafael and I will present my work on hello to trade cost analysis. Uh can I have the next slide, please? So one of the main issue of uh ZK is that it's quite hard to implement and when you want to create a an application that uses ZK and you want to verify it on chain it's it's a bit it's even more difficult because right now you have to implement the secret which is very difficult to then have the verifier implement the verifier to see if it's actually worth it or too costly. So that's why uh my project was actually to work on uh a cost analysis of the verifier onchain to see uh to give the opportunity of developers to see if uh this case is worthwhile for their application but also for uh developers to to know how to implement the secret what uh chips component primitive they should or should not use uh so it's uh no way to to close uh one example that I found quite quite funny uh which is an article from bits from a few weeks ago. Uh the article was titled with bit Google zero dish proof of quantum analysis. So for context they implemented uh a proof that they uh hacked the discrete log with a postquantum protocol uh with specific parameters and with that much uh constraints, powers, gates, cubits and so on and trail of bits uh beat Google at it not by finding actually a better protocol but because Google had uh written a unome secret and [snorts] so they they created a proof that is legitimate with better parasites which corresponds to nothing of course uh but that is to show that even Google can't easily write secrets and so implementing ZK is hard and so uh if you have to do this before to know what is the cost of the verifier it is actually very difficult uh so my goal was to to implement a simple and usable onchain ver cost estimator for the verifier uh so I can either show you a slide or I can actually show you live. Uh then I show live. Yep. Uh I'll try. Uh so if this works. Yes. So uh there are two components to to my work. There's a CLI. Uh the repository is public. It's called CL2 verifier gen. Uh you just have that to run uh the binaries. So there are several binaries but the most important one is the estimate uh to then uh implement uh a cost of the verifier. So if you know what uh hello to clunk does you will know what's an advice fire a fix wire and so on and so you can basically set what's the architecture of your secret and you will get some uh some numbers but this is quite tricky to to look in details and I had to make a few assumptions because there more parameters than that so actually what I did on top of that is implement directly chips that you may use. So imagine that I have a secret and I want to use shadow 56. I just have to use this meter with shadow uh sorry wrong one shadow 56 is here. I just have to imple to run this command with shadow 56 the right number of public inputs and I got the result. This is CLI uh it's nice but you have to clone the repo uh build it implement it and so on. So uh I built u a website for the repository which is public uh on which you have the cost estimator uh so if you go on estimator you will have a interactive version of the estimator which wasn't close. So for instance I talked about using SH 256. You will see that the pro the VK size proof size uh number of inputs and so on vary to give you the total uh size in bytes. You have some breakdown if you want to understand more what uh where these come from and you have more importantly uh the operations that are being used for verifying this onchain. So for in so the main course is of course the pairing and then the point operations. So you can see here that I'm using uh 11 uh point exponentiation or multiplication depends on which uh common you are using uh 400 or so scalar addition 600 and so on scalar multiplication uh so it is quite easy uh and you have a very simple view to see what cost you can expect this of course is generic you would have to use a cost table function of Cardano to see what would be the me CPU and so But you could change for any u uh benchmarks, libraries and so on. So it is actually quite neat. It can also not be used for online cost. Uh if you want to have some information about what chip to use, you can go on the chip uh uh tab. Uh and you will see that chips have dependencies with other chips. uh and you will be able to see exactly what is the minimum proof and verification key size you would expect if you were to use this chip on its own as well as uh the operations. If you want to learn a bit more about uh about the Halo 2 verifier, you have a page here explaining uh the main concepts. Uh you have also a page training how the the numbers you have uh seen are uh computed and uh if you want to create your own chip which uh might be difficult but it's quite for me you have a page on how to contribute to this repository by creating a chip on uh hello 2 uh some some advice on how to make it more optimized for the refire uh and so on and how to integrate this to uh the tool. So this is quite interesting. Well, I found it quite interesting to work on this. You could add layers on top of that to give a higher level primitive like a short and so on to make it as user friendly as you want. Um but yeah, that's uh that's it for me. So I will unshare my screen and we can go back to the presentation. Uh so Parl is asking adopt Penture MSM optimization is mission. So uh the MSM pipe puncher is uh I don't think it is implemented. It is simply >> I will just give give a context because for instance in group 16 right there are several levels of of optimizations you usually do right you you start with naive one then monomial then you are adding FFT then you are adding this pip uh pipener uh msme and so on and so on and for this particular uh case you are showing it could probably uh be some change especially for bigger circuits or yeah things like that. So I'm asking whether uh those uh numbers you were showing uh uh took that into consideration or it's uh without this optimization. >> Yeah. Uh so uh here we are only looking at the verifier. Uh so this is uh out of the secret cost to to make it clear uh on the website that I showed I I went quite quickly uh because I was worried about time but there is a field which is called MSM sizes and so right now uh we are doing the MSM on prototype verifier that we have manually. uh but there are some CIPs that actually would uh imperations much more efficiently in the future. So there's one for MSM uh if I remember well it's going to reduce by 30 to 70 plus% the cost of doing an MSM on Cardano with Piscore uh and I hope for this to be merged uh in the coming weeks on I can and I'm not sure when for the lecture it's already implemented uh in princever uh there's another CIP that is coming that I'm really looking forward to which is for modular exponentiation so one of the uh on chain is actually scaline version and you implement it with modular exponentiation. So this is coming and would drastically reduce the vifier cost. So if I'm being cheeky if I can be cheeky and show one less thing. This is not really linked to uh the uh cost estimator but it's on the same page. So this is what I was talking about. You've got here MSM sizes and likewise you have stain version. So these are different from the simple uh point multiplication but so uh this custom lives in a repo called precious to verify gen for generation because we are uh the goal of this uh repo was initially to dynamically generate I can and prince uh uh verifiers and so we had some benchmark in I can and prince about uh verifying this uh this tech so it's in the same repo if you're interested You can have a look there's some codes there that shows before and after CIPs after CIP has not is commented out. If you run it in prints in the future in you will you can see the difference and you will see that is much much cheaper. Um the mention of the CIP in some documents also and on the on the repo. So yes, sorry about that. >> Great. Do we have any other questions for Raphael specifically before we u move to a broader discussion? Okay. Um so feel free to to to um switch off your mic and uh I mean switch on your mic or or or or use the chat. So I I guess [snorts] um you know one of the purposes of of of the workshop today was to understand how well um uh these three tools sort of align to to sort of practition zero knowledge practitioners within Kadano. I know we've got a number of sort of labs on on the call. I've named some but I'm I'm sure there are others as well as as well as individual contributors. So um does anyone have any sort of um particular sort of remarks or questions for the team? Uh you know we're really interested to understand does this does this work for you? If it if it does great what's what's sort of the core parts to it? If it doesn't what can be done to to you know what what can we do to to sort of make it work even better for you? Does does anyone want to sort of kick kick things off? >> Hi Julian please please go for it. >> Hey there. How are you guys? Uh Julian from Emers here. Um so yeah, I mean I love the presentations. I knew more about the first two ones uh than than Raphael's one. Uh they were great. Uh only comments I believe there was I don't know if you guys said it but there was um uh a risk zero adaptation to BLS 12381 that someone at IO G made. I don't I I don't remember who but uh someone made that or or at least a prototype of that uh which was similar to what we wanted to do in the proposal um we we submitted that wasn't voted anyways but like um yeah I think someone made that for uh risk zero if I can find the link uh I'll send it to you guys just that was my like my my comment uh around um Demetra's presentation Um yeah, thank you for the presentations. They were great. >> Um yeah, thank you Julian. Um we are actually aware of of that effort, but as I said, it's kind of a different direction from what we were doing in in in this work stream. >> Yeah, more like specific to risk zero. And yeah, it has its its caveats like as you said Julian, if I can just sort of probe a bit further, if I may, are there like, you know, if these were to progress into full implementation, which we sincerely hope hope they will, will they, you know, [snorts] um, you know, add to sort of enable, you know, your capab, you know, enhance your capability on Kadano. Are there any sort of specific things that you can point to from a from a use case perspective? >> I mean, yeah, definitely. Uh us in particular, we do not have um like products or a or yeah like an application of our own that we're like pushing forward. We're mostly a a development augmentation team for uh you would say specific applications like CK etc. But um but yeah uh in fact that when when we uh what's the word for this when we submitted our proposal uh we submitted some capabilities to the intersect process right that's what I'm talking about uh we submitted some capabilities that were similar to the ones you're uh presenting here presenting here we did know about most of these uh we were in talks with Jesus in the past uh and he told us about some of these Uh so yeah uh what we wanted to present actually was similar to this because we believe that Cardano is lacking SK infrastructure and as you said it's it's key for postquantum uh and and key for scalability and yeah I mean the the graph 16 wrapper um is a great approach uh postquantum stuff with lattice based approaches as Julian is asking uh is also key Um, yeah, I'm particularly interested in the in the wrapper and how that goes in terms of speed and stuff, but but yeah, I think the the presentations are key. Never had the chance to experiment with Punky 3 myself yet. I know most of most of my team has, but yeah, um, they also key key functionalities that needs right now. >> Okay, great. Thanks, Julian. Does does anyone else want to We've got some questions in the chat. Does anyone else want to put their hand up? Um okay so so just coming back to the the chat then so um yeah Julian if if are you considering Julian's question is are you considering latisbased proving systems? I know Raphael's made a comment here but does anyone want to take that one? >> I guess the answer is quite quite uh fast. Yes, we are this is latis face latises are everywhere but at least the development side of it is in way more earlier stages. So yeah >> if I can add a bit more on that. So right now there's not that many latis uh based proving systems. Most of them are are using also uh folding schemes and do not necessarily have a decider which mean that the proving systems are not complete. um as far as I know there's uh a handful of uh of proving system based analysis so it's at the very early stage of research uh as as you say there's no implementation uh and so we're looking uh and we we're keeping track of it uh but if something comes uh I at least and well I at least I'm sure everyone in in our team would be happy to have a look at it and potentially implement uh in the question I as FGY actually was the first one not the second about conversion between BN and BLFS we took a a snack approach uh which is basically we emulate uh a curve in secret on top of another curve and there's no real trick to it there's no let's say cryptography except using a stack uh but if you want natively to convert a curve into another it's it's not really possible unless there's a link between curves like BN uh and uh like ABLS and uh job BN and DP job and so on which is which is quite rare. So yeah there's no no system to do that unfortunately. Um okay great and any any other um participants have any have any sort of remarks sort of >> um I I just wanted to ask like where in the priority list of the road map um is for you guys the uh optimization of all these um all these protocols. I mean for for the real use case uh CK is very valuable but when it comes to like transaction size uh memory and CPU is is quite limited. So it's it's very hard to see like um like real use cases when it comes to like deploying this on pre prepro or or mainet. >> It really depends on your application. If you have uh zk can be or snacks more generally can be used for verifiable computation. So if you have a very big uh program and you want to succently uh show that the result is uh is correct, you can do that with with SNS uh and you can uh uh verify for very cheap on comparatively on chain. Uh if your application is just a transaction, snack may not be the solution you're looking for because the base cost is more expensive than just transaction unless you want something else. if you want uh privacy, if you want to use these uh transactions for identity and anonymous credentials. Um so proof systems are expensive. Uh the postquantum ones are even more expensive. But there is strong interest in them and I think uh in the past few years a lot of people were looking not so much at blockchain but at cloud computing so that you outsource your program and you get the output of your program as well as a proof that this is correct. uh now the main thing in uh in technology is AI. So maybe Z could be used in uh in AI uh to show that the model is correct that the answer is correct or something like this. Uh and maybe the proof is enough that you can pro uh verify chain. Uh that's uh that's a different discussion. >> Uh to add to that uh you can also do recursion uh to aggregate unproofs recursively into a single proof. So on you only pay the cost once and the cost will be amortized. >> That does that answers your question, Jonathan. >> Yeah. Yeah. Thank you for that. >> Okay. Um, anyone else got got sort of questions around requirements and and specifications or um uh the appropriity of of of the work. I guess I' I've got one and I don't I'll direct this at you Jesus but but um for anyone to take it. I mean the these three tools were prioritized. Were there others considered as well um within within the the the stream? You want to take it out? >> Um yeah, there were others but um yeah, we prioritized this one because we see the the highest value in this one and relatively low effort to do that. So one another interesting direction was to modify um these ZKVMs directly as as was mentioned by Powell. um for example to make the risk zero to produce BLS proofs directly or SP1 produce BLS proofs directly. This is very interesting direction but we kind of didn't take it because we saw there is um this this might be done by other teams. Okay, thanks Demetra. So, so I mean I we'll be sending around a questionnaire after this just to get everyone's feedback, but um I mean just a show of hands or or or sort of comments um sort of icons or or what have you. If this work was was put forward for implementation um in the next treasury cycle, would I mean would you know from the zero knowledge experts on the call would you know would there be sort of broad consensus and support for that um or or would anyone have any sort of objections or or sort of concerns. Okay. Okay. So, there's a sort of handful of um uh supporters. Um no no negative ones I see. Um okay. So, so I guess yeah, I guess that's a good good question, Raphael. So is is there any you know again the open question is there also anything um you know the people on the call would like to have tool-wise or or or guidance wise from a from a sort of zero knowledge perspective if you can't think of one now we can always uh put it in the questionnaire um okay and and I guess you know to to my question around implementation we, you know, as as we get into sort of the back end of the year, we we'll be looking to sort of um engage some some ecosystem labs about implementation and and handover as well. So, when the questionnaire does come around, please flag flag that if that's of interest to you. Um, okay. I unless anyone has any sort of final closing remarks, I'm I'm happy to to sort of leave the call there. Um uh yeah, we'll we'll we'll add you to the to the list, Pwell. So um uh yeah, thank thank you all for for your time. Um I hope I hope everyone on the call found that constructive and and thank you to the ARC team and and the presenters um Raphael, Jia, and and Demetro for your work. Um that was, you know, very clean, very sort of easy to understand. So, so thank thanks thanks to everyone on the call and enjoy your uh enjoy your Thursday evening. Hope it hope it cools down here a bit in in in Europe and uh and the UK. Have a good evening everyone. Thank you. >> Thanks everyone. >> Thank you. >> Bye everyone.