ZK HACK III - Evolution of the MASP circuit in Namada - Anoma - Part 1

Transcript

foreign [Music] Banks and I are going to talk today about the evolution of the masp and some extensions that we've developed um on top of the masp for for some interesting applications which I think have not been explored before at least not maybe not in this context so first question probably um uh is what is masp um and and uh it's certainly

um not an upside down uh wasp uh if uh if you're afraid of getting stung uh by a flying insect no it's it's not uh it's not that um even though the characters look similar um masp actually stands for a multi-asset shielded pool and uh what is the multi-acid shielded pool well uh maybe being a little bit uh reductionist um a multi-acid shielded pool it's a shielded pool with one uh more than one asset type in it now was the shielded pool well the sort

of most famous and perhaps original uh example of the shielded pool is um uh provided by zcash um the idea of the show the pool is that um you can use cryptography and zero knowledge proofs to um encode transactions that happen and because you are using a zero knowledge proofs and cryptography to encode and to verify these transactions um they're so-called shielded um they're they're not cryptographically linkable in the way

that uh most transparent transactions are where um transactions that involve various addresses are cryptographically linked to uh those addresses and We Know by checking signatures that which addresses are involved in which Transit transactions and so um uh so we want to start from the existing examples um again most notably Z cash which supports uh really uh one assets type and a piece of D cash it supports the

Nativity cache token um in other cases and they support whatever native token there is for the pool um but we're interested specifically in shielded pools that contain more than one asset type which means that um the asset type that's involved in each transaction is also uh cryptographically encoded in some way um and so uh the properties of the asset are checked inside of a zero knowledge proof and so you don't have a external or transparent knowledge of which assets type

um what was involved in each each transaction so we have to start with the Z cash shielded pools of which there have been um three so far um and I'll use zcash's own uh description of what it is um it's the implementation of of the original paper uh called zero cache the original academic research paper um and um this is a little one understatement uh improvements performance and functionality in fact uh over the last eight ish years there have been incredible improvements to Performance and functionality

um as not just uh some smaller increment or evolutionary Improvement um it's actually been quite substantial um and uh the general idea is that we want to accomplish things that you can do using the existing transparent systems um but use zero knowledge proofs or more accurately it's your knowledge it's a thing to not interactive arguments of knowledge um which is a technical distinction um

but we want to use these ZK snarks to prove that the various properties of the shielded pool are satisfied such as you cannot in general just create value out of nowhere um and so on and so on uh you cannot spend other people's value uh all these important properties um we prove using these uh zero note oh snaps and the best place to learn about shielded pools um most specifically are zcash protocol specification and the issues on the

library see cache repository on GitHub um and these are really um the the two most comprehensive resources for um understanding how shielded tools work and how um the modern evolution of the shielded pool has um uh come about uh of course there's there's uh many other resources out there as well but um these are are certainly very comprehensive and very uh well-written resources uh for for understanding um the Z cash Shield pool and all the research that's gone into um the Z cash shield in pools

and they're certainly not Light reading um the zcash protocol specification um is not necessarily intended at least as far as I know uh to to be read linearly uh you know as a textbook um um it's uh it can be somewhat technical in some places uh certainly uh GitHub issues are also not necessarily supposed to be read uh linearly however um I've found that they're it's an incredible educational resource um and oftentimes the discussions there um really give an incredible amount of context for why certain decisions were

made in the way that they were um and we also have um in the uh I know my masp repository uh some documentation about the multi-asset shield pool specifically which uh assumes generally um that you're familiar with easycash shielded pools to begin with and and doesn't repeat very much so uh these resources are are primarily where um we draw from for the mxp and we're where we're going to draw from uh today so

where do we start well we're going to start our discussion with uh Z cash sapling which was uh the shielded pool upgrade that came out a few years ago um we now have the cash Orchard but uh um we're going to be talking about ccash sapling which is still an incredibly good uh technology which is still very very much relevant um today um because it was such a massive Improvement in efficiency and other benefits um and so we're going to use a zcash sap

when it's our starting point of the discussion which is uh quite quite uh an important starting point because of the fundamental changes that were made with the cash sapling and the fundamental improvements over the previous uh shield and pool sprout and so um I I took this uh equation from um the zcash protocol um specification um because and I want to share it first because this is probably um

uh the most significant change in the sapling upgrade um for for our context which is uh using this notion of a homomorphic value commitment um if we recall from our photography background uh uh commitment uh in cryptography is a way of um sort of locking uh some information into a box uh kind of a cryptographic box uh such that um uh it has two properties that are important um hiding and binding hiding meaning that once you lock this information in the Box

um it's not sort of readily Apparent from the outside um what information that you've locked inside and binding in the sense that uh when you unlock the box and and reveal uh that the secret information that is inside um you can only uh ever reveal what was originally locked inside the Box there's no feasible way to take something out of the box that you didn't put into the box and so uh this this uh use of this particular value commitment

um which is a a Pederson commitment in sapling um works as follows uh they derived to fix the elliptic curve points which we call a capital V and capital r here um and uh to encode a integer value of some kind some amount of zcash um which is representing by Little V um you first compute some Randomness um just some random bits uh which we're going to call RCV

and then we're going to compute this value on the jub jub elliptic curve um where we take the value and multiply it to a scalar multiplication of the elliptic curve Point capital V and a scalar multiplication of our Randomness RCV times the R point on the elliptic curve and by adding them together we're going to get this other points on the elliptic curve that we're going to call the value commitment of V and the claim is that um by

the way that Pederson commitments work and the way that we derive the values uh uh the the two curve points V and r um that this commitment should have the hiding and binding properties that we discussed earlier and um this is actually really important for the way that the sapling Shield pool games and real uh performance Advantage because uh of the model of transactions that they use which is uh um somewhat different than um the the previous Sprout shielded pool um and the zero coin papers Shield

report and the the reason is that uh zika stopwing uses a note based transaction model which um means that value is encoded into things that are called notes um they're a little bit like uh utxo's but uh generally because of zero knowledge uh it's it's not um you know not clear from the outside what uh uh what notes are spent or not spent um but the general idea is that with this note-based transaction model you

can either spend or output notes and so in a sapling transaction and again this is just um you can find this in the ccash protocol spec um a sapling transaction looks like n spends of notes um without uh thy commitments uh CV old one through n um which again commits to Val to to specific values of which represent amounts of of zec and uh then you create from this output M output notes

which have value commitments uh CB new one through M which encode some amounts of CEC that are output and then uh you have this balancing value which is sort of the net sum of this transaction which is uh use which is used to represent how much uh zc is added or removed from the showroom pool and so um the reason that that this is important in sapling is because um

uh by breaking each um spend or output uh of a node into its uh individual value commitment um by using the uh properties of this value commitment you um can actually efficiently compute one zero knowledge proof per spend or per output um and you don't have to encode the entire transaction in one uh one zero knowledge Group which is actually um a nice gain of of efficiency and

um other benefits as well and so um to ensure that transactions don't create or destroy value um again you can find this and use the cache protocol spec um the important property of this value commitment is as homomorphic meaning that if you add or subtract value commitments from um from each other to or from each other uh that is effectively the same as adding or subtracting values inside the content and so this means that you don't

actually need to know what is what value is locked inside of the box you can do this add or subtract of of two value commitments and you um you get a value commitment that commits the sum or difference and so um this this is great this means that we can uh in in sapling I consider each note individually um and not have to consider the entire transaction um uh we uh um can just compute for each note um each value commitment um corresponding to that note sum them

out uh some of the value commitments up outside of the circuit not in zero knowledge um because the value commitment is hiding uh so so it already doesn't reveal um what what's inside so we can outside of the circuit uh sum up all your all the value commitments and obtain um the net value change of the transaction whether it's added or removed any value from the shielded pool and then uh that that that compares against the the balancing value um okay so the sapling design works really well it's

um and the technical details that the gross 16 proof system um still very uh uh efficient and practical today um it stood the test of time variable so what can we do um to add multiple asset support to this is this sapling design uh for the most part only supports um uh an implied asset which which would be easy to see or or single asset or something well um I I traced it back uh to to this come from Dara

um uh quite a long time ago um still during the development of sapling which uh describes the um um uh really elegant I I uh in my humble opinion I also agree it's really oh yeah uh really elegant way to do this without changing the sapling design very significantly of course there's there's several different ways that you can you could do this but if we're starting from the sapling design which is very good and we don't want to change it too much the most elegant way of doing this is by realizing that you can use uh

these homomorphic value commitments um to not just sum over a single asset type but instead over many acid types at the same time and the way that uh we're going to do this is by using a different elliptic curve point for each assets type so if we go back and look at this value commitment we have this capital V with the Curve point that we we use to to multiply our scalar value

by to lock our value inside of this commitment and the claim is that we can use a different value v a capital V different oh the curve point for each um separate asset type and that's going to cause the value commitment to behave independently for each asset time um so uh this is you know again one reason why it's it's very much worth uh um for educational purposes understanding the GitHub issues um

so let's um diverge from from Top point for a second and just discuss uh what is an asset time you know what what are we uh formally trying to do here well an asset type is an abstract property uh added to it a note in addition to its value so um if if a note doesn't have any asset type then implicitly all notes you must have the same asset time the asset type is is implicit and it's shared across the entire shielded pool um but if you add um this notion of asset type to a note

then um we start to understand what properties we need um from notes that that are now types that have this asymptote notes should have only one asset type um I mean this is not uh you know that we we impose this requirement to help us there's no reason why notes need to have more than one assets type um and we importantly have this rule that all transactions are balanced independently across all assets types meaning that

um in a transaction no matter what asset types are used um oh and assets should um balance by itself for for that asset type by itself the amount of um that asset um input into a transaction or spend I should equal the amount output um may be adjusted by the amount that's added or removed from from the shielded pool um and the idea of this is of course um that you don't want a necessarily to

start with uh different assets types messing with each other um you don't want transaction which has uh one type of asset um to to change its properties when you add a second type of acid as well to the same transmission it shouldn't affect us at one at all um now this is great um there's no shift asset type but uh we have to have uh unfortunately different mathematical and computational representations of what an asset type is at different points because they're used in different ways

so I'm going to somewhat arbitrarily um but very specifically use certain terms to refer to to representations of different asset types so I'm going to start by just saying well the name of an asset is just application defined in some way it's some byte string of arbitrary length that uniquely represents a given acid type and um the reason this is um so generic is because there's there's uh actually this like incredible variation

um among different standards for how uh how you might Define what an asset like specifically what kind of asset is so you have like ERC standards you have fun you know you're you're the the most common erc20 um fungible token you also have ERC non-fungible tokens um you have uh Cosmos interchange interchain um representations of different tokens um you you've got uh an incredible um

variety of different ways that um this asset type can be um viewed at from from an application layer and so um so we're we're just going to call the name of the asset um some generic uh thing that uniquely refers to the asset um which might come from from some token some token uh derivation um or or took an address or or something like that you can also include other things

um you can include some salts you can include a random Beacon um there's reasons to do this if you want to kind of prove maybe that um like you didn't construct your assets before a certain point in time um maybe you include a random Beacon um that there's there's different things you can have um and it's fundamentally not part of the shielded pool um specification uh What uh information goes into this um um into this representation of an asset type oh so inside of the shielded pool

um we're going to get much more specific because the shielded pool has to know what um what an asset type is in a very concrete way as opposed to the very very generic way we just defined it in the previous slide um which uh maybe you use outside of the shielded pool inside of the shield pool has to be very concrete and the shield has to know what an acetype is and so um there's two different representations inside of the shielded pool um which uh for the extensions the mask that um is built on to Cash Stop point

um uh takes two forms uh an acid type can be um represented by an identifier an asset identifier is just a 32 byte string which the only requirement is that is derived from the asset name um in a deterministic way so that each uh each uh asset type still has a unique identifier two acids with different identifiers are distinct and two acids with the same identifier are the same

and we're going to impose some really strict requirements on the asset identifier for for some technical reasons um namely uh you're we're not expecting this asset identifier will be um like a token address or or anything like that um because the asset identifier is um specifically 32 bytes and it's this compressed representation um um it's definitely included all this arbitrary data it's just going to be um um this this 256 bits um

and this can give um very strong hints as to how you should derive the asset identifier um certainly you can just hash uh the asset name as long as um you still maintain the uniqueness properties um you can you use whatever kind of uh hash or compression you want generally um but but just taking a hash of of the acid name to get this asset identifier is is not a bad way to start hover uh we do have uh um this uh second and third requirement um which are which are related

um which is not every 32 byte string will be a valid asset identifier um and this is for a sort of technical reason that doesn't have to necessarily be this way but um but we did this on purpose and this is because of the third requirement which is that um if you take the Blake to S hash of the identifier you get the asset generator which is going to be the elliptic curve point that we're going to use in our value commitment and so the reason that um we have this construction then um and this sort of strict requirement

on the asset identifier is so that we can efficiently uh handle all of this inside of the zero knowledge circuits so um computation in our in our zero and odd circuits is very precious um it's it's not um uh it's not free it's certainly uh uh rather expensive for the approver to um to do extra work if our circuits are very complicated um it imposes the cost of not just CPU but memory usage and if you're um concerned about your proving

performance on say mobile devices um yeah you know you really want to make sure that your uh performance in the circuit is really good and so um we just impose by Fiat um some this requirement that uh you take a bike to us hash of this asset identifier and you get the asset generator and um this is why the asset identifiers 32 bytes because that way you can take the blink 2s hash in the circuit and you only need to um do one uh one block of the blank 2s hash

um and then um you don't have to you don't have to do many uh like 2s blocks uh in the circuit which would be very expensive um and also um um uh by restricting um uh that uh the hash always has to work so not every output of a Blake to us hash is a valid curve point on on the job curve and so um this is why uh not every asset identifier is going to work um

some ass that identifiers are just not not valid because when they uh when you take the hatch the Blake 2s hash of them you don't get a good message generator and we don't want to do extra work in the circuits um to to handle these valid cases um we just want to reject them and so it's the responsibility outside of the circuit to ensure that only um good asset identifiers are used um so this this can prevent you from just straight Direct um uh straight directly using uh the hash of the asset name because you might get

an invalid asset identifier uh that wouldn't hash the asset identifier gives you an invalid curve point um and so um there's some celebrities okay so what is a um a spends look like in in the um masp so in order to spend the note that now has this assets type well all we need to do is um make the notes uh typed now um if if a note has in it

um the asset generator that represents the value or um the Val the base that you should multiply the value by the elliptic curve Point um for your value commitment um all you need to do is added this value base as a witness to uh the spend circuit so if you're familiar with um the sapling circuit uh and how it works as Apple circuits and how they work uh if you look at the spend circuit this should be extremely familiar because uh

for the most part uh things are not very different um all that's been added uh is that we add this private input of um the asset generator which I've used uh VB to represent for Value base um we just add this this asset generators as private um private input and uh we want to say that um the circuit is satisfied if uh all the usual uh sapling spend requirements are satisfied

with the exceptions that we have added now this asset generator um to each note um we can for the most part ignore almost everything I've highlighted in kind of this purplish color what has changed all we have to do is add this acid generator to to each note and it becomes now a typed note it doesn't just represent value in some implied single asset but notes can actually have value and the type

um and then not much else really changes except that um when we look at the value commitment instead of using um this uh this fixed uh Olympic curve Point um in our our commitment we still use a fixed elliptic curve Point um to multiply our Randomness by because the randomness can does not depend on the assets type um we can just use a single um uh single elliptic curve point which we get from this group hash

um for for our Randomness space but the asset generator um the value base in in the Pederson commitment uh now comes from our private input and comes from our note commitment and so um as long as our private input matches what was uh committed to in in the note and we use that asset generator in our value commitment computation um uh we can now be confident that the value commitments um matches um not just the the value that's

contained in the note but also the asset type and um from from this side from the spend circuit um as as complex as the spend circuit is this is the only change that's really necessary we have some extra fine details about uh you know check food that these points are not small order and clearing um co-factors uh this has to do with the fact that the jump jump curve is up and Edward's curve and as a cofactor um uh which you can read read the details about this in both the zcash specification and the

misp specification so spending endnote is actually not very very different at all what is um how does creating a notes look like and this is actually a lot more subtle so um when you create a note uh what does the circuit have to check the circuit has to check the things that it checked and it's happened before namely um you're given some public inputs about about the note that you're creating no commitment and the value commit and so on

um and uh the private input is going to have the the private inputs the sapling outputs are had before um but we're going to add not just the asset generator to the private input but also the asset identifier and we'll see in a second why this is important um why we cannot just add the uh the asset generator like we did in the spend circuit and if we look at um what the uh

output circuit has to do now well it has to do all of the things that the spend circuit changed um so so when we compute the note commitment for example um we have to now compute a typed note commitment so it doesn't just have a um value uh with implied asset it now has a value and an asset generator um and you put that into no commitment so that's the same as um in the spend circuit um the value commitment has also the exact same change where you use the asset generator now to compute your

value commitment and not the sum constant um curve point you use the the acid generator that you've put into the note however there's no place um in the output circuit to check that the value base is correct um in the same way that there was in the Spencer here if you recall in the spend circuit um this value VB although you're giving it as a private input it's ultimately compared to the note commitment and the note commitment came

from the note commitment tree uh comes from notes that already exist and so once a note is typed with a certain type of a certain asset generator um you can assume it's good I like you like you cannot change the the pathogen area later because the uh the acid generator did not come from the user it came from a note that already exists and that's not true in the output circuit um because here the user whoever the prover

is of of the output circuit whoever's creating the new node is actually creating a new node and they can otherwise put any value any elliptic curve point they want in VP um and they can you know create uh crazy uh crazy asset types um any elliptical points they want but they can they can put in the acetate um and this is can be destructive because for example um suppose that uh the value of VB that they use that has a generator

uh is uh the negation of some other asset type so they take some existing asset type and they say oh I'd like to create um notes which have the exact opposite asset type um the same curve Point except that multiplied by minus one and so then by uh creating um new notes of this negated assets type uh you can create like unlimited amount of the other asset type by um sort of in the uh kind of almost quantum foam type

of way if any of you uh like theoretical physics um you uh if you're allowed to have negated asset generators um you can spontaneously uh in the uh in the shield of the pool um create a uh an asset and it's negation um and because it will still balance to zero um all right it would otherwise um check out just fine um even though this is obviously something that you you don't want and you want to private so how do we prohibit this we say you you cannot witness uh the prover cannot witness uh

an arbitrary uh asset generator it has to actually witness um that this uh passage generator came from an asset identifier and this is why um the prover has to witness this 32 byte asset identifier and compute in the circuit this blank 2s hash uh one block of the blake2s hash um to to derive um this value base on this asset generator um and and um verify that in fact that you did not just make up some asset generator you

did not just negate some passive General that already exists oh and so um we should note uh now having observed that this was necessary in the output circuit um we should note that this is not necessary in the spend circuit because um you can only create notes with um correct asset uh generators um that that the output circuit enforces this the only

um uh only uh valid asset generators can be used to create notes and so uh we can assume that when the notes are spent um that that they're um asset generators were already checked to be uh to be acceptable so um one may wonder if it's necessary um the answers uh kind of yes and no the answer is uh yes in the construction that um

that we uh just described for the reason that I just described if someone Witnesses the negation of an asset generator um and produces notes with negative value of of some actual asset um they can create notes of arbitrarily positive value homomorphic and balance um now that being said um there were other proposals which you can read about in the GitHub uh Z cash repository um uh in the GitHub issues um which which include one wave of uh

avoiding this entirely uh and and avoiding this Blake to us hash um which is certainly more efficient from from a circuit to perspective anytime you can avoid having to do a an expensive hash operation um in the circuit uh you can save a lot of computation time uh but in the specific construction that we've described um uh you you have to verify um that your asset generator is good in some way

and so we we just accept uh in this construction the cost of the blade 2s hash um even though there's there's potentially alternative ways to do this so then um one of the other uh most common questions I get um is uh why does it need to be obliged to S hash um uh why cannot why can't we just use a Pederson hash um because it's much more efficient to compute um in the in the circuit um than the pseudorandom function such as the blank 2s hash um and and the answer is that you cannot

use uh this Pederson hash um um to to verify um or just to derive the accent generator um and this is because while Peterson hash offers Collision resistance um it is possible um in fact it is actually downright easy to find related pre-images to each other um because the uh Pederson hash generators are publicly known um suppose we used Peterson hash to derive um um our asset generator from your asset identifier

um you can very easily uh starting from um from an existing assets um an existing existing asset identifier in existing asset generator you can very easily derive a new asset identifier a new asset generator that has some some known relationship to to the existing generator and and this is um this is just generically a problem um it's it's not um uh not so easy to get around um you have to um have uh unlinkability at some point so

um um just just for for security purposes to allow people to um to prevent people from from um mixing different assets types together um and potentially violating um the rules that we require so it balances between acetypes um now this doesn't uh um mean that all conversions between acetypes are unwanted in fact uh um this just may allow unwanted conversions um we may want actually want some conversions which will be the next part

of the topic okay um I think we're at the uh the break points yeah but before we do that there was one person in the Q a chat who was asking some questions and I wasn't exactly sure um what what he meant what he might want to give us a read and see if you can answer it um okay uh yeah let me see um okay basic principle button um we can't hear you oh I'm not muted no no you're not could you hear me there yes okay uh yeah so the um just one

thing if you if you want to read questions from the Q a just be sure to repeat the question for the video yeah if you can just read it out that would be awesome okay um yeah seems like uh seemed like this uh basically only one uh one question um all right so uh hakan asks um the basic principle behind zero knowledge is that there's always a simulator capable of Performing fraudulent proofs you learn nothing from false evidence um so if they're just indistinguishable from real evidence you cannot learn anything from real evidence are you aiming to hide real data by using fake data with zero knowledge is

the purpose here to hide the source rather than the information um okay so uh uh five minute uh recap of of what uh zero knowledge is and and and how it works um so the the fundamental idea of zero knowledge is that you want um you want to convince the verifier of of some fact uh in such a way that anything the verifier um learns through the entire procedure the verifier could have figured out themselves anyway and so

um so the verifier might get convinced of some truth but um but they don't learn anything else besides this fact and so I always use the example of soda flavors um if uh if you imagine that there's some people who don't believe that uh you know two different brands of soda tastes differently um I suppose uh um suppose I don't believe that brand a and brand B

um taste any different um but other people do believe that they think different they know they taste different um then you can use a proof uh of some kind to essentially um prove this fact to me um namely someone who can actually taste the difference um between the two different brands of soda um I can challenge that person by saying um take a sip of cup uh one or take a sip of cup two um and I can I can randomize uh which a brand of soda I I or which cup of soda I challenge um the proofer with at every uh step

um basically I I behind my back choose one of the cups of soda and I challenge uh you to to taste the difference tell me which which soda brand of soda it is and the idea is that if someone guesses you know a hundred times in a row uh what the brand of soda is then um that could not have happened by chance um um uh and and so I've become convinced of uh of what um what brand of soda um uh uh that the brands have said are different um and the idea of zero knowledge and the idea of um of using a simulator here is

um suppose that um uh you want to do the same uh kind of uh proof that that you know the branch of soda tastes different but you don't actually um um like once a reveal which which brand to switch well um the idea is that um uh by uh in some sense um hiding the source of of uh hiding the way that each cup is chosen um so that

um oh so that you don't imagine you cover the labels of the cup so you don't actually know which cup is which um then um um you you don't actually warning information this way um so the reason the uh formalized in the notion of the simulator is that um you imagine that uh suppose that you set up some cameras you know a TV studio or something where you're filming the prover and the

verifier um doing this interaction with each other um uh and and the verifier concluding that uh yes in fact the cups in soda are different um the way that you prove is your knowledge is that you argue that imagine that the uh verifier in the television Studio um is uh is uh colluding in some some way with the proofer imagine that instead of um being like a real verifier um it's a simulator of some kind which is which is uh trying to simulate what um

like they're not actually trying to verify the cups of soda taste different they're just trying to um simulate what it would look like if um um if if the prover were successfully convincing them that the cups of soda tasted differently and so you have the two cups of soda which are you know they have the labels covered um and and the verifiers challenging the prover with the cups of soda well imagine that there actually was no difference in the taste and the verifier being the simulator is is in on um uh in on the scam right that the the the simulators trying to simulate what

it would look like if if the um if there was a difference um well the verifier uh Simulator the simulator and the prover uh you just need to use the same uh same Randomness you know for choosing the cups um the simulator chooses you know some pattern for for how it chooses the cups and the prover knows you know the same pattern like it's going to be cup one and then cup two and then cup two again the cup one um and the idea is that in this TV studio uh it looks exactly the same like you cannot tell from the outside

that instead of a real verifier it's this it's a simulator and yet although it looks exactly the same from the outside um there's actually no transfer of knowledge going on like the there's no um there's nothing being proven because um it's a it's a fake proof it's a simulator that's um that you get uh just not acting as a true verifier it's just um simulating what um a correct interaction would look like and so zero zero knowledge proofs

fundamentally kind of work in this way where um if you argue that there's uh um always the simulator which um can look exactly the same as a real verifier than in fact there must have not been any information gained because there's never information gained by uh approver and a simulator talking um because there's no information there's no uh um like there's nothing real about proof or unless the meal that you're talking it's

it's just all um sort of put on for TV um uh put on for show and so um as long as there exists the simulator which can look exactly the same as a real verifier doing the real verification um once you plug in the real verifier uh you You can conclude that uh the real interaction between the proof run verifier also does not exchange any knowledge oh if that makes sense and so that that's why we have this proof this notion not in the like actual code or anything

but in the um in the theorems and and the and the math papers uh we use this notion of a simulator that does false proofs uh and and that's how we argue that that actually no information is revealed [Music]