Do You Need a Zero Knowledge Proof? - Jens Ernstberger

Transcript

hi everyone welcome to today's L share uh we're excited to have yens planting his paper do you need uh zero knowledge proof uh yen is from T Munich he has worked on blockchain and dii for a while uh he has worked on quite a few different uh subjects such as censorship attacks uh benchmarks I think we had uh actually talk or discussed about zik bench not that long ago uh Yin worked on it uh this is a paper from yens uh I'm really sorry if I pronounce it very badly Stefanos Kalos Li Philip yanovich and Arthur ja so thanks yens for coming

here and we're very excited with this interactive session perfect thank you Rafael um great yeah today I'm going to present uh the work that's called do you need a zero knowledge proof um and kind of the motivation behind all of this was um there's a lot of focus on snarks at the moment uh essentially in industry and due to their popularity in blockchains so um this is kind of an attempt at giving kind of high level guidance for non-experts or people kind of joining the field uh to kind of like broaden a bit the perspective on what is actually possible um and why certain Protocols are used in some context and not in others

um right um so what I'm going to talk about today is essentially first um the solution space of zero knowledge proofs um so what kind of zero knowledge proofs um or different approaches to zero knowledge proofs exist um on a fairly high level and what are their different performance trade-offs um then we'll dive into a specific example which is TLS oracles um so quickly for you that don't know what TLS oracles are um essentially um how you have to think about it is the following so assume you have TLS right like TLS secures all connections on the internet so you have a client and a server and all of it is

kind of like encrypted via this transport layer security protocol um what TLS oracles allow you is basically proving that some data originated from a server to like a third party right um and uh so how you have to think about is this B basically you have like normal oracles like from chain link and uh these prove uh basically consistency about like some public API right like for example weather data or something by having like an oracle Network everybody can access the API and comes to an agreement um with TLS oracles you can you can access private data so if I'm the only one having access to an API endpoint um you can use a TLS Oracle to prove uh correctness of the data that you obtain from any server um and what's

really interesting here is that there's um kind of a bunch of different approaches to this uh to solving this problem with different kind of security properties um and also performance properties um so we'll talk about that um and then I'll give like an overview of some other zkp applications what kind of like um zero knowledge proof uh they use um and finally um we'll talk a bit about whether you actually need a zero knowledge proof in some applications or not okay great um so for the kind of solution space so what we do in the paper is basically give like a non-exhaustive overview like fairly broad um about different solutions uh that being Sigma protocols commit

improof protocols um NPC in the head and also snarks um snarks is probably um the kind of broad spectrum of solutions that all of you are most familiar with um snark basically has the properties that it's not interactive um it has very very small proof um a very computationally intive verifier uh and communication um whereas you have a fairly computationally expensive appr right um for commit and proof protocols these are also commonly called uh interactive proof protocols I guess um or dedicated verifier proofs so the thing here is you have um a verifier and the verifier basically keeps a secret

value um that is relevant for the completion of the protocol so it's inherently private coin uh um so you can't apply the fat euristic um and uh the downside is a little bit that you have like um a larger proof size uh and you have uh communication that uh that is more than one round due to the inherent interactivity of the protocol uh when you're basically going over the full circuit um but what you get is basically a very performant prover with also a low memory overhead um another another class of protocols is basically uh MPC in the head so what this does is um you let the prover essentially emulate a bunch of

virtual servers in its head right um and uh then afterwards you let the you commit to the IND individual views of each um of each virtual server uh in the protocol and let the verifier challenge basically uh a bunch of these fusees of the individually like uh simulated servers um and uh yeah then then you basically obtain zero knowledge due to the Privacy properties of MPC um and uh you get a protocol that is fairly similar to the commit them proof approach um uh but also like with a large proof size and an even larger

communication to give you like a a rough guideline like I think the uh the most recent one is like 2x communication as opposed to kind of like the commit and proof protocol approach um uh and uh yeah and then finally you have Sigma protocols um Sigma protocols uh essentially how that works is you have like uh a verifier and approver right um and uh uh where the name comes from is you have like a commitment phase um then you have a challenge phase uh then you sent the proof uh and then you sent the verification result and that results kind of like in a sigma uh kind of lad so that's why

they're called Sigma protocols um and uh the interesting part here is um uh that you can also obtain non interactivity with the fistic um you have little communication uh all bite not as little as in the case of snarks because your proof size is kind of larger um and kind of downside is you have um a aover and a verifier that are both linear in the statement size so so naively you might think um so why don't we use SES for everything right um so let me quickly give you an intuition about this um based on like a practical example um from the identity space um probably some

of you are familiar with the kind of like some of this um so essentially in the if you want to have like um privacy preserving identity proofs um what you usually do is you have like a holder of the credential and the holder has a bunch of attributes so for example like name nickname address date of birth and ID number right then what you want to do is you want to present this credential to some kind of verifier right like I don't know some government entity but you want to preserve your privacy and therefore only disclose um uh a subset of attributes uh and also like you want to prove like certain predicates on these attributes right um and uh yeah so this is kind of like the the the problem statement

there's roughly solved ideally with Sigma protocols uh so how this is done basically you first have to issue the credential right um and this is uh essentially done um by using blind signatures so um here you have like an overview of what is being done in the verifiable credential community and like for the standard of decentralized identity um so essentially you use uh BBS plus signatures BBS Plus signat were conceived I think like roughly 10 to 15 years ago now um so there's a long line of work uh that initially started in the space to to obtain privacy preserving credentials um

also like in the early like early 2010s late 2000s there was already like uh practical systems from from IBM for example it's called edix um the the leveraged like similar principles right um and so the latest latest kind of proposal makes you use of BBS plus credentials um which use BBS plus signatures due to kind of like their uh advantagous performance properties as opposed to other kind of like signature schemes um and how that basically works is you have like um uh a key generation algorithm where the key generation algorithm gives you like a secret key and a public key so this is commonly run by the uh by the issuer right so you need to run key

generation um and uh then you basically sign the attributes or messages from from the holder right so you what you do is the holder sends kind of like the messages which are kind of like the attributes of all of this um to the issuer and the issuer issues a signature over kind of like the the individual attributes right um and then afterwards what you can do is uh you take this signature and you verify this the signature is essentially a credential including your attributes right so you get a signature you send this back to the to the holder um and then you basically present um the the credential to the verifier and the

verifier can verify basically a signature um and the interesting property of these protocols is that you can selectively disclose attributes without revealing the signature so why why is that why is that beneficial uh because if you would present the signature to the verifier you could trivially like if the if the issue and the verifier are both government entities so it's kind of like the same entity um uh you would be able kind of like to link the issuance to the verification right so this is like the property of unlinkability there's some extensions that like make the whole thing blind so you also can issue without disclosing uh the without disclosing the attributes in the first place um and so the the interesting part where this Z knowledge

proof part comes in um in the presentation of the credential is that you use a sigma protocol on top of like the signature scheme um to only reveal uh a selective number of attributes and also not reveal the signature right um so how this works is um essentially you give the signature this is from another paper so but it's like roughly the same same signature same same signature improv scheme um uh so you receive the signature um and the commitment to the messages uh and then you basically let the uh the verifier pick a random challenge so as I said before right Sigma protocol you have like the commit the challenge and then kind of like the

response period um and uh based on kind of like the challenge that you send the appr response with some variables and afterwards the verifier can check um uh can check basically uh uh the the two pairings are equal and then compute uh this statement and based on that like I'm not going to go into like any more details in that but based on that you can basically verify that like the attributes that are committed to or that are revealed uh are assed by the the issuer without revealing uh the actual signature um so what's interesting about this is that you have to perform a number of group operations that is linear in the um that is linear in the

size of the of the number of statements um that are previously issued by the issuer right for the credential um and also the proof size is dependent on that so right so um you might come up with two questions at this point right um which is why don't we use snarks for identity um this is possible uh there have been previous approaches to this where you use snares specifically for uh uh for obtaining similar properties of unlinkability anonymity blind issu in and stuff um and then basically verifing verifying them on a blockchain

so there have been academic works on that but specifically this is used in the proposal for for decentralized identity because you have like different setting right so you have what you have is you have like the blockchain right um and the blockchain what it essentially does uh the only thing it stores is from the um from the issuer to store the public key uh and then the verifier can kind of fetch the public key from the from the blockchain right so it kind of like uh in this in this sense you don't do any credential verification on chain so you really don't need a snark for this application that is envisioned envisioned in the decentralized decentralized identity specification um right because you only use basically a

ledger as a public registry for for uh public keys so everybody can fetch their public keys without directly talking to the issuer um right um so that is the benefit in this case and the other question is um why don't we use Sigma my protocols for generic NP statements right so theoretically what you could do is you could express any generic NP relation as a combin combination of algebraic statements so as a combination of kind of like discret discret logarithm relations or something right where you express each gate in the in the circuit in an arithmetic circuit as a relation between the input and the output wires but as algebraic relations

right but if you then apply like the sigma product call like this one to it then you're going to inherently have like a very costly prover and verifier because both of them run linear in the size of the statement or linear in the size of the the messages right so in this case you have several exponentiations per gate which you can basically also get an intuition from from this protocol where you basically have the commitment to the message Vector um and the longer the message the more you have to um uh uh have to kind of compute um okay um to give you a better intuition of this this is how it works in practice uh so this is the actual numbers of like um measuring this um so you can see basically um the proof size um is

basically a number of bites that is linear in the number of hidden messages um and if you want to create a proof and you basically scale the number uh number of messages while only re revealing one of them you can already see that the time basically linearly increases with the number of messages in in the proof um that you want to proof for right um so that's why you basically don't use Sigma protocols for any generic NP relations right so what we can get from that is basically that you have to consider different things when when um when uh choosing your zero knowledge proof protocol based on the application that you want to apply it to right so

basically the performance is very dependent on the nature of the proven statement so if you have like a statement that is very trivially describable by by some kind of algebraic relation it might be better to use a sigma protocol uh and uh basically yeah uh uh exploit the performance properties here um but then you have to kind of like struggle with like the prove and the verifier being linear in the size of the statement um whereas for example for non-algebraic structures like for example um some kind of hash is the shat 56 uh some some kind of hash is the Shad 56 of some pre-image or some kind of uh Cipher text is the a as encryption of some plain text um it would be more

efficient to use Boolean circuits and also for nonic structures like like shat 56 and as1 128 um it's also not as inexpensive in snarks per se so here commit them proof protocols would be better because um uh you would have to basically operate with non non-native arithmetic snarks because you need to basically emulate existing algorithms uh in the fields that you operate in in like let's say like a pairing based snark um so what you would like to have ideally right um is like the best of all worlds so um and that is exactly uh why we're going to talk about TLS oracles because here it's very interesting um uh you kind of operate on algorithms that

are conceived without thinking about zero knowledge proofs but you still kind of want to verify some of these things on chain so you kind of like need to think about this to combine different kind of zero knowledge protocols um to come up with like a very optimal solution I guess right okay so uh TLS orles um so what you have in TLS you have a server you have a client um the so what you operate usually is this protocol right so this is TLS 1.3 um and you can already see like you have a bunch of uh hdfs um which is a hash based key derivation function usually you have two invocations for of shot 256 in each of

those and you can see that that kind of like yeah is quite a bit if you want to prove the handshake in a TLS uh uh in a TLS session uh to like a third party um and uh then afterwards you have the record layer uh where you use AES or some kind of other um authenticated encryption scheme that allow you to prove kind of like that a a plain text um is um uh is encrypted by specific key that you derived previously in the TLs session so um right so for TLS what you do is you have a client you have a server the client knows the um the secret key of the client and the secret key of the

server and the server also knows the secret key of the client and the secret key of the server right this is because we have symmetric keys and requests always encrypted with the with the client secret key and response is always encrypted with the uh with the server secret key this is a bit oversimplified um but it kind of like gets the message across for what we want to say so you might say like the client might trivially prove that um some kind of data that it obtained to from a server is is correct right so you might want to say um okay we have a verifier and I just create a proof that like I don't know AES encryption holds um this is not going to work because you know you know the client knows this key so it can basically encrypt arbitrary data under

that key and prove like correct encryption um to the verifier without the verifier being able to verify that it's actually authentic um right so you need some kind of other solution for that um and the solution that like was initially conceived like a couple of years ago um I think there already started like 10 years ago even um but it it is basically to emulate the client in in two-party computation right so what you actually want is a commitment from the client to the cipher text that you obtain from the server um that that commitment that can be obtained by the verifier without the client being able to change what is

committed to right so in order to achieve that um what you do is you emulate the fold client in in inpc um and first of all you compute kind of the the um shared key the the secret keys of the TLs session at 2pc where the client itself only holds um the the a part of the secret key and the verifier holds the other part both for client secret key and server side secret key um then you compute the request into PC um basically because like none of them can compute it individually because the keys are shared um and you send that request to the server here it's important that

like the server you can't change the server because uh otherwise you would have to change like every single server to uh support this kind of like TLS Oracle protocol um on the whole web so you don't get really Legacy compatibility so that is why you why you kind of like uh encrypt this request in in in 2pc and then you receive the response now the interesting part is um the client here can't decrypt the response um at this point in time after receiving it because it only holds a part of the key right not the full key so what it does it is it commits to the response and then afterwards the verifier reveals the secret key and then the the client can basically um uh computer proof that something is

encrypted under the secret key right like that I that I decrypted and encrypted correctly um and then you just use a c snark right so this is like the the the initial kind of solution that was conceived for this problem um now you might observe that um for example the verifier can be computationally powerful right we're not operating in any blockchain environment here we can just like run the verifier on any obtainable server and it can be fairly powerful um and also it can be designated so as you already see here in 2pc you kind of like split the keys right so the verifier already holds a secret itself and you can only execute this protocol with this single verifier

um so there's no one else that you can execute it anyways so um why not use a different zero knowledge proof for protocol that makes that makes use of this kind of assumption anyways right um and uh yeah second thing is you have incerc AES encryption right because here you decrypt with the secret key and then you need to basically prove correct encryption um this is also prohibitively expensive because as I mentioned before if you want to basically work on non non-algebraic structures and snarks like AES or shot 56 you need to uh perform this the the the as encryption with ulated arithmetic which is non-native to the field that you're operating on and therefore it's also very expensive so it

incurs like a lot of numbers of of uh uh constraints in like R1 CS or whatever kind of like constraint system you want to use right um right so second approach and this was I think presented last week um so I'm not going to go too deep into it but basically what you're going to do is um you're going to um use semi-honest 2pc and then a commit and proof snar uh a commit and proof zero knowledge proof so here you have the commit and proof kind of zero knowledge proof which is interactive so you already exploit the um the possibility that your verifier can hold a secret value um and the general process is kind of

like similar to like the previous protocol uh but with like a private coin verifier um what you end up with is communication that is roughly like 14 times less because like of semon 2 PC um and a vastly more fast um compute SP compute speed for the for the zero knowledge proofs which is around 100x I guess better I don't have the exact numbers but roughly um and also the memory usage is much lower so you can now run these things in the browser because you operate kind of in a in a gate bygate Paradigm where you can um uh where you can uh basically you don't have to prove the whole the whole circuit at in one but you can uh basically operate it gate by gate and

interactively kind of like prove this relation um right um so yeah so what you end up with is a protocol that roughly performs like this so this is from from the paper um uh from from P Labs um so if you run like for example the the verifier in North America right um then you're going to obtain a fairly fairly low processing speed because of like uh the the distance end to end from from clients to verifier um is fairly small so you don't have like a a large roundt trip time um but if you have like a large distance between those two um then you have a

larger round Tri time and basically a higher processing um uh processing requirement for this um right now one last approach that I want to highlight is uh basically you can change the system requirements right so you can say um I'm okay with like less Security in this case uh under certain assumptions um and then I can have like different System model uh and I can that allows me to kind of like do different things right so for example what you can do is uh you can operate like in something called the the proxy mode I guess that's commonly accepted um uh basically what you do is you weaken the network assumptions um so you say we assume that um uh that the client so C

cannot mount a man in the middle attack here um between the uh kind of verifier and the server um and then what we just do is uh we run the verifier as a proxy um um as a proxy to the server um and basically route all of the um all of the messages handshake and request and response through that proxy and let it save it right like this is not of much concern because it's all encrypted at that point um then afterwards you just prove correct encryption with like a snark or any kind of like zero proof protocol that you kind of like deem feasible in this case um uh the interesting part here is um that you can do this because you assume

that the server is honest so whatever the server sense is fine um so you can assume that this response here um encrypted with the secret key of the server um is committing right so you kind of like achieve kind of like the similar Thing by as like up here right where you have where you have like the client commit to the response but in this case you just acttiv like let the verifier actors a proxy and assume that the server response is committing anyways right um right so why is this interesting um so the interesting part here is you obtain something like a TLS Oracle that is independent basically of the local

situation of the verifier and the client so you have kind of like constant communication because you have a non-interactive snark here in the last phase where you prove like handshake and encryption um so it doesn't really matter how far you how far you away away of the verifier because like the roundt trip time itself doesn't like yeah basically have as much impact on your protocol um right um so there's a bunch of the deployments deployments of this um so for example you have pay Labs you have TS notary which is also developed by P um they commonly follow this 2pc um uh approach so this is kind of approximate right um so don't take it for yeah um and then you have reclaim which

basically operates in this uh in this proxy mode um where you just route everything over it and afterwards prove it with a snark um and there's a bunch of academic works that also outline this um and uh so what is the takeaway here is uh it's basically by observing the unique requirements of an m application uh you should also choose kind of like zero knowledge proof that you want to apply right um because even for one application which is kind of the TLs Oracle application you might end up with different solutions that have different performance properties throughout right like with non- interactivity interactivity um and some might be more beneficial in some use cases than others right um right um so let's now look a bit at

the application side and how this is done in practice um so as you can see there's like a bunch of different um uh if you look at different applications um uh people apply vastly different uh proof systems I guess um whereas in blockchain applications basically everyone focuses on on snarks um the simple the simple reason for this is that uh you need um uh you need like a a short proof verification time and short proof size um in order to verify things on a blockchain because otherwise it becomes very costly costly in with regards to to

gas consumption um whereas kind of like in the in other applications where you have for example um uh let's say for example like TLS oracles here right you have Alternatives with commit proof snarks which kind of like optim commit proof zero knowledge proofs um which optimize over snarks um or also kind of like proving software exploits so for example if you want to prove a software exploit you don't necessarily need an onchain for this um and uh so you can do this kind of like in an offchain environment let's say I want to prove uh that like Amazon has a software exploit and some of some of the code right like I could just send a send a send a proof of it to them without disclosing the

actual exploit um which is kind of like okay if like Amazon runs uh computationally um powerful verifier right um then I can also use like different protocols that don't have like very succinct verification um right but you can see like for some of these snarks are still used um uh I guess mainly due to the requirement of verifying it on the blockchain um right so I mean the the ideal thing like if you think about for example the the commit them proof approach uh for um for TLS oracles right like ideally ideally what you want is um you don't only want the verifier in the end to send kind of

the signature right like let's say you prove something and then the verifier says like okay this is correct with like the commitment that I have um and then I send a signature which can then be used as a credential right um ideally what you want to have is you want to have kind of uh the flexibility to say as a client uh I just kind of like get this authentic authentic data from server and then I can kind of like construct zero knowledge proofs or like zero knowledge proofs that are provable by a smart contract afterwards um so how you can do this is um you want to kind of have the best thing of Both Worlds right um so you want to have very

fast execution in this offchain environment where you have a verifier um that verifies your commit and proof snar commit and proof Z knowledge proof um and uh uh then afterwards you still want to use the data and the the kind of like um authenticity that you obtained in through the TLs Oracle to to prove some kind of statement to a Smart contract that might be flexible afterwards right so you want to prove different statements unlike a cipher text that you obtained from some kind of server um so the interesting observation is here that basically all of these different um zero knowledge proof protocols work on different types of commitments right for example PL the plon snar works on kcg commitments um uh

the CTP the commit them proofs commit them proof Zer knowledge proofs operate over uh what's called itmax information theoretic message authentication codes um and and what would be cool is if you can just transform commitments right so in the in the TLs Oracle case you already end up with um uh with commitments to to all of the things that you want to prove afterwards in the snark anyways so instead of like the the most optim optimal thing that you can do is kind of like transforming these these information information theoretic message authentication codes to for example um Patterson commitments or some other um additively homomorphic

commitment that you can then after for it's used with a snark to prove something towards a smart contract for example um and I think that's really really interesting like the composability of these different zero knowledge proofs um and how they exploit basically um uh yeah the kind of environment that you kind of like operate in in different protocols right um yeah right um so now to the last part um which is basically do you actually need a zero knowledge proof right so I hope this kind of like gave a good intuition of what kind of the trade-offs are um and uh what you can kind of do to like kind of like merge different there's been like different Works recently um uh that optimize for this

for example there's been one recent work that outsources um uh basically like that specifically focuses on AES for example um where you Outsource the computationally expensive Boolean arithmetic that you would have to do in a snark um that basically outour to to to a lookup protocol um and then afterwards proves basically with a custom lookup argument that's based on like Sigma protocols that IAS encryption is correct um that was like a recent paper and there's also other papers that like for example uh Lego snark that like combines different snarks with different properties so I think this composability property like in different um yeah in

different environments is is fairly interesting even Beyond snarks um so yeah um maybe this paper helps a bit in in kind of like um yeah pushing this a little bit forward um but yeah now to the to the interesting question do you actually need a zero knowledge proof sometimes the answer might be no right um so for example if you have an incentive compatible me mechanism right let's say um uh you have a witness protection program right like a witness protection program might be um I'm kind of like a witness in in some kind of uh uh law case or whatever uh and I have to be sit sit in this kind of area right um

ideally um uh you you you kind of like you as a witness are not incentivized to provide like malicious proofs right that you somewhere outside of this witness protection area because you want like the people that actually protect you to know that you're still in the area that you should be um so the only thing that you might need it for is actually privacy and not actually authenticity so you might want to create like a uh your knowledge proof of location right or something like that um where you prove that you're actually just in this in this boundary but like the actual Prov is not really incentivized to provide like non-authentic locations um similarly um there is other applications

without privacy let's take for example again the the TLs Oracle case right um where you have um uh you have a client so this is like the client right like you have a server um and the only thing you really need it for for example if you want to prove that a Paypal payment has been executed correctly um and let's say you're already operating in in in kind of like this proxy model right like you have you have like the client you have the proxy you have to server and everything is routed through there um what you can just rely on essentially for for ensuring authenticity is uh uh o off 2.0 right so um let's say you have a PayPal

login you pass the loog login token to the back end let's say this acts as a proxy right then you send the login token to to the PayPal API um and you receive some kind of like checkout link right um and this token is basically restricted in the access scope that it actually has so you're only permitted to to do the actual operation um uh as like the backend operator um that you're that you're kind of like constrained to by by the client um and uh then basically the client the only thing the client has to do is kind of like click on check out um and you as uh as kind of like backend operator can still um verify that this payment has actually been uh been

executed uh by using your access token that has for example uh the read uh uh read um that allows you basically to read whether some transaction has been executed or not right um so in this case you you probably wouldn't even need a zero knowledge proof the only um reason you would need a zerge proof for is for for privacy right um if you don't want the backend to learn your actual uh identity that you that you have on PayPal like your email or something right um right um and yeah maybe finally uh when do you need a sark um I think maybe to to kind of like come back to the beginning uh and why this work was uh kind of conceived um uh is that we see

like a lot of snark applic and a lot of applications that would probably benefit from like different approaches Beyond snares um but snares are basically used because like there's the the the best development support right like it's much easier to just bootstrap aover and run it in the browser than kind of like doing the same thing with like commit them proof protocol because like you need to have like very specific domain expertise to actually construct these things in software um so yeah I think a snark is really really beneficial if you either have like computationally weak verifier which is the case for a blockchain which is basically a very slow computer um or if you have many verifiers let's say like if you want to prove your location to like 200 peers at one time right um so yeah um then a

snark can be really beneficial but I think we see like snarks applied in applications um yeah that would just benefit from from uh other Alternatives as well um just due to the ease of development and I think I hope that this paper will kind of uh yeah like um will basically uh yeah bring people to think about uh yeah how can we develop um better tooling for other solutions that might benefit benefit us and how can we kind of like improve composability of these things to get like the best out of both worlds yeah great um that's basically it uh if you have any questions um I'm happy to take it now um and uh yeah thank you

very much um so I do not see any questions yet on the chat but I have a few myself so I'll enul um so you say point you say just at the end that uh you do need a stock when you use uh when you expecting many verifiers but uh I think if I remember well uh the first snack that were produced were about of uh specific uh were sorry designed for more specific verifiers so I'm not sure if they are much cheaper than uh let's say old people's current snars uh but this exist uh this also

exists sorry can you what exactly was the question can you rep so you say here when do you need the stock and you say when you have mini verifiers um my question what I was pointing at was we also have Des designated verifier SS yeah right but then you would need to like reprove to all the verifiers right like um because like I guess the the the nice property of like let's say you want to like send a proof of your location right like let's say you're somewhere here and then like you have like uh five or three verifiers right if you want to use like the designated verifier snark you would have to uh you would have to uh execute the protocol

with each of them um and you would also have like uh larger communication overhead right um whereas if you have a snark um you can basically just uh if you have a snark you can basically just um uh broadcast your SAR your proof to all of them at once right like you can just broadcast your proof non- interactively um whereas here you would have like basically an individual protocol with each of them um if you use like a trivial um trivial interactive kind of like designated verifier uh zero knowledge proof I think there's also like threshold uh designated verifier proofs where basically um all of these basically share um have a different

keyshare right so you have like whatever S1 S2 s S3 and then they kind of like do a threshold verification um uh yeah that might also be like a possibility but if you have like a lot of uh lot of verifiers I guess the best thing is to just non interactively broadcast like a SN proof right yeah um so yeah one thing that uh was quite interesting is you mentioned that SN were composable uh so in the blockchain domain we can see already stock uh plus knock you mentioned here uh NPC or 2pc or others plus knock which has its

proper Advantage uh I think in my mind this is one of the biggest advantage of SNS that we have this uh versatility so not only there's a composition which forn in that case is mostly about sness and faster but we we also have uh lookup arguments uh recursion uh and a few let's and and a few other techniques uh that makes snack very interesting uh especially in the blockchain scenario here um for people so my question is do you see this happening in uh in the MPC or in the other

um proofs uh Technologies I'm not aware of composability works in the MPC domain uh but I'm also not like super deep into it so I might just not know of them um yeah that might be probably the best answer thank you y great what better yeah uh so it seems people are either very happy U because they have no questions or very shy so I think we can finish here so thanks Yan for joining us today and for this

presentation it was a pleasure uh pleasure for attending have a good day thank thank you for having me see you bye thanks bye