Configurable Asset Privacy and Proof-Carrying Disclosures with Ben Fisch | a16z crypto research

Transcript

welcome everybody to the seminar for the week we're really glad to have Ben Fish who uh just finished his PhD at Stanford last year working with Dan uh and now he's just started as a professor at Yale he's the co-founder and CEO of espresso Ben's known for his work on uh vdfs on uh proofs of uh groups of replication or catalytic proofs of space his work on uh darks and SuperSonics a whole lot of different areas so as well as his crack climbing techniques thanks Joe uh yeah so I'll I'll talk about configurable asset privacy

um and preparing preparing disclosures for privacy polls this will be mostly focus on on this protocol that an application smartphone application that we built in espresso system is called king um which is uh currently deployed on arbitrums testnet and also on Syrian assessment Gurley and has been getting a lot of traction in the last few months and uh should hopefully be live soon with some with some uh pretty big users soon so um uh so this is the espresso team just briefly um credit to all 26 of them for all the work that went into the the the the the

system that I'll be presenting today um and there's two products that stress the systems develop it's one is called Cape which is a protocol configurable asset privacy on on the ethereum application layer and that's what I'll be talking about today the other is a decentralized sequencer for ethereum Roll-Ups and I won't be talking about that today uh so uh Cape uh comes into this picture where there's generally an All or Nothing approach to privacy where you can have blockchains that either completely uh completely transparent and they don't have any privacy for for user transactions or or other protocols whether they're in a smart contract like

tornado cash or entire blockchains like Decatur where they're uh you know and transactions are entirely private or even Anonymous from uh from the public View and so Cape is trying to offer new options in between that in particular you know they give users more flexibility on defining the level of privacy of assets that get created and this can in particular to be used to balance risk management and user privacy so uh hypothetical case study but very realistic is as you can see from the hypothetical description uh a U.S

regulated stable coin issue or mints some USDX on ethereum the issuer needs high level visibility into how USDX is being used the ability to track the flow of USDX originating from any listed sources the ability to freeze assets if necessary but they also would like to give their users some level of privacy so the general public cannot view transaction details of their transactions um and the problem with the status quo is that users can only achieve privacy via sort of mixing services like tornado cash let's say completely shielded full and that's fine um for a while but then there may be some illicit flow into the pool which is visible within soils the whole pool and

the pool gets sanctioned now the issuer has to ban for use the entire flow of USDX from the mixer and this is a very high collateral damage to innocent users who are just using it for some level of privacy so um it with that in mind that that's sort of the motivation for introducing this configurable asset privacy protocol which can enable issuers of digital assets to create custom privacy policies um and in the first version of cat we focus on um a fairly restricted class of policies that involve viewing cues and present Keys uh so viewing Keys um what are they what are they well there's a privacy policy that designates

certain parties and the data that they can see so for example uh there's an auditor that can see the details of transactions over a threshold amount a freezing key uh would be a policy that designates parties who can freeze assets um and there could also be some conditionals in there digital credentials are something that policies can take into account so the policy May the viewing policy for example may say that for transactions over a certain amount not only can you see the amount being transacted but you can see certain verifiable credentials of the sender recipient addresses

and finally we built this in a way for it to be evm compatible so it can be deployed on top of any UVM blockchain it currently is deployed to ethereum girly test net and also dark from testnet as of a few weeks ago uh the design principle behind Cape is giving the maximum flexibility to access creators and exchanges to take decisions around privacy and control so that creators of digital assets have the ability to restrict how their assets are being used on ethereum or other blockchains by configuring these privacy control policies and exchanges and other endpoints can also take responsible decisions on which assets they want to accept so they can take into account their privacy control policies

so let's go into um a bit of a more technical discussion of how this cap protocol Works um and also let's talk a little bit about the current version versus the future version so um at a basic level it's very similar to Z caps so if you're familiar with how zcash works then this is pretty much review uh there is a there is a ledger uh where implementing it as as in an ethereum smart contract so The Ledger is managed by the same smart contract but you can think more generally the cap protocol and this requires some Ledger and it contains a record set right and transactions will take

as input to records and they'll create two two outputs and the the um I'll talk a little bit in a little bit about how how how this is private right right now we're uh not really describing how how privacy is achieved but generally just look at The Ledger is having a record set and every transaction is effectively removing two records or however many records and creating some new records right and uh the the anatomy of a cap record is that it has an asset identifier identifying what acid it is it has an owner address and who owns it it's a public key it has an amount and there's a flag that says whether it's frozen or

not and then a blinding Factor uh because these things will be cryptographically committed so um how do we do how do we Define assets well when when an issuer creates an asset it derives an asset ID based off a pseudonym function of its secret key as the issuer and some description of what the asset is right so you could have two different issues create assets with the same description but they will be different assets because there's different issuers and you don't want uh you you want to prevent someone from from forging assets on behalf of an issuer that they are

right so you wouldn't want someone to be able to create assets of usdc uh if they're not circled for example um so uh record commitments and nullifiers let me introduce these um so a record commitment is just a cryptographically hiding commitment to a cap record and you take the plaintext of the cap record and you produce a cryptographic commitment to it it could be the the half of this record with with with the with the secret knocks so that's sort of the blind Factor would serve as and a nullifier is uh is a function of um of the record commitment itself and

it is a prf that takes an also nullifier key so you can only uh derive this nullifier if you know this nullifier secret key and I won't say exactly yet how we Define the knowledge for our key we do it in sort of a clever way to enable this freezing functionality but uh before we talk about freezing you could just set the military key to be like the secret key of the owner for example that's how it's done in zcash um so we'll Define the nullifier keys later but it's think of it as something that's unique to the owner of the record uh and so that thus can only be it's it's uh can only be created by this owner and every time there's a unique nullifier for any given uh capture

so a transaction will take in as I said some inputs and produce some outsets um but the transformation actually makes to The Ledger is it it doesn't actually remove the inputs from The Ledger we don't want to touch those inputs uh we don't want to reveal which inputs we're we're actually uh taken this input to to this transaction so the the transaction just creates produces these nullifiers for the inputs and that prevents them from ever being spent again so no other transaction future will be able to take the same inputs because they've already been nullified [Music]

oh cat and cake so cat is configurable asset privacy protocol and Cave is cap on ethereum yeah uh yeah um so you said that the nullifiers aren't linkable to the thing they nullify they are not linkable from the public viewers perspective but if you have the if you know the nullifier key there's a unique nullifier that you can derive so how does it enforce that if the nullifier is out there you can't spend the original thing if you can't link them so if somebody were to try to do a new transaction yes that uses the same input yes they would have to create this they would create the

same nullifier and so because the nullifier already exists on The Ledger you would not allow that to happen so every transaction must create invest nullify all as inputs and it can't produce nullifiers that already exists uh so in addition to this which is basically I'm describing a zcaps transaction um we also have something called a viewing demo which I'll describe um and then the owner memo is what allows the recipients to uh to to decrypt what happened and that that the owner memo is present in zcash as well so the news in here is this viewing memos and I'll describe how that works um and then there's a zero knowledge

proof which I'll also describe in the next slide which shows that this whole thing was done correctly so the zero knowledge proof is going to show that the you know the outputs are balanced of the inputs uh and that the nullifiers were computed correctly so you didn't just produce some arbitrary nullifier that has nothing to do with the record uh okay so not assuming any background here this may be review for every single person years and go very quickly through it but I feel like you have to include a slide on what zero knowledge is in these presentations so zero knowledge proof uh is a protocol or the goals approver wants to convince the verifier that some statement is true without revealing some

secret evidence um to know some private input W such that this program evaluated on a public input X and is private info W is equal to one the prover um is an algorithm that has this program and also has the public input X and the secret input W the verifier has the same program but it only has the public input X there's some protocol we like to use non-interactive xenologists and we're dealing with blockchains and that's necessary for cap in a non-interactive proofs approver we just send the proof that convinces the verifier that this this witness W exists this probably didn't put existence

the soundness guarantees that it's infeasible to produce a valid proof that the verifier algorithm will accept if approver doesn't know such a w and zero knowledge means that the proof doesn't reveal anything so um the is there an off-proof systems that we use are called pre-processing proof systems uh at Universal with universal setup so there's some setup that's done one time it's already been done for a lot of these two systems like Punk and we actually are priests in the based off of plot so the parameters already exist they've been done multiple times in various different trusted setups for different projects um

and the pre-processing takes these parameters it takes some circuit representing the program that's that's that's uh involved that's being proven and it generates what's called a proven scheme and a very big verification key for this program uh and then the proof algorithm can use the proven key in order to produce a proof given the public input X and the private info W and the verify algorithm will only need this verification key so it doesn't need to remember what the circuit was it doesn't need to remember what the program was it just takes in this verification key and it can verify a proof uh and the public against the public input and it outputs either zero or one one meaning that it accepts zero

being that it Rejects okay so what is going to be in our zero knowledge proof well our zero knowledge proof for cap is going to prove that the commitment to nullifiers were computed correctly as defined uh that the inputs are part of the record set that uh the sum of the outputs is equal to the sum of the inputs by the way the way that approves the inputs are part of the record set involves some Merkel proofs sort of skipping over that as a detailed hero come back to it later let me see the full picture uh that that detail doesn't matter that much it's for efficiency but the zeroop has to prove that the inputs are part of this record set somehow it

could take the full records that is input right if it wanted to be less efficient um and the transaction satisfies the uh asset policy um and this is saying the viewing memo is properly encrypted using the viewing key so what is this asset policy so the the asset policy specifies the viewing key okay there could be multiple viewing keys if there are multiple Auditors that have different viewing rights but we can just focus on the case of one View and key um it optionally specifies a viewing threshold which says that this needs to be encrypted the details of this transaction need to be encrypted under this unkey only if the amount being

transferred is over a thousand dollars for example um it will specify whether the amount should be deliverable to the person who holds the view and key they should specify whether the owner should be doable and it should specify whether the credentials should be viewable or not um and this can be also including which credentials so you can represent the credential as a vector of attributes and it would be um basically a bit Vector saying which attributes should be available to them here to to be uh to the holder of the view key um and finally it says whether whether there's a freezing key or not and I'll explain freezing next but uh it you know if there's no freezing either nobody has

ability to freeze records and if there is a freezing key and then somebody has the ability to create so I'll explain what that means um so the zero knowledge proof needs to prove that this transaction satisfies asset policy so in as an example it would it would if the if if the policy says that the view key holder should be able to see always see the amount in the owner then does your knowledge proof proves that uh the viewing memo is properly encrypted using this theater key right so that guarantees that the holder that you achieve would be able to decrypt uh this information which would include the amount in the record and uh or the amount and all the input records and the

owners of all the income records and output records um and finally it also needs to prove that the free Status is not changed remember the free Status is just as a bit zero or one says this record is frozen or not frozen for a normal transaction you're not able to change the free Status right so where does the asset policy live like do I specify with the transaction what asset policy I'm satisfying yeah so the asset policy uh the asset policy is actually taken into account as part of the uh the definition of the asset itself so it's it's basically the asset itself is a certain commitment to this

policy uh you can also have a table of NASA policies but that it's not having content two things each asset ID is associated permanently one asset problems okay so on creation you specify this yes uh we've gotten some user requests to make uh asset policies updatable without changing the asset type and so we have a design for that update that separates these things out I asked a lot of questions about like details of these asset policies but you mentioned like freezing at record is there a notion of freezing an account like freezing all records tied to yeah this is a really good question so uh no uh currently not um there's just freezing an individual

record uh there is no real concept of an account [Music] um and uh so I guess you could have a policy that says freeze all records that share the same owner address but even if you were to do that it's I mean users can also use different accounts well unless you I guess you'd have to get into some like permission system for being able to register an account yeah I mean you can if you have a appropriate viewing key for an asset you couldn't freeze all the individual assets that correspond to some owner right or some credential the idea is that I mean all people from trees will also be able to

view otherwise they don't know it's freezing so the you could go through and and look at everything and figure out which ones you want to freeze um but we currently don't in the protocol itself make it more convenient or automatic to like freeze all records Associated yeah it's kind of designed sort of in mind with freezing is a very rare thing right but have you had anybody requests like uh like a permission ownership model where you have to sort of like do kyc or somehow you know just to get your address so not not anybody can create a new address so people are interested in these credentials which are which do function as that

um but it not necessarily explicitly in terms of you can only get this specific ad but like if you do have credentials tied to ownership then you can you can Define policies where you treat all records associated with specific credential so it's like the credential then becomes the print permissioning aspects you could say an asset can only be transferred to someone who has the appropriate credential and the credential would be okay wisely people are interested in that uh so this viewing memo uh so some engineering details here we've worked very hard to make the the circuit efficient that could efficiently prove that you're encrypting plain text under this viewing key so we use album hybrid encryption to encrypt

the plank text Under The View key um the elderly public use over the job curve and we actually have rescue based stream Cipher so we prove the symmetric encryption of it's not an element encryption of the of the plain text because that would make description really annoying so we we actually have a symmetric encryption of the plaintext using a smart friendly um symmetric derivatives uh so the full protocol will also involve a Merkle tree uh before a transaction you have a record Merkle tree over the records you have some nullifiers the transaction will take some input to nullify them and create

some new outputs those new outputs get inserted into the Markle tree there's a zero knowledge proof showing all those things that I just mentioned the viewing memo is created properly um that the inputs are nullified properly and it will add these nullifiers to the nullifier set it doesn't touch the inputs and the inputs remain in the market between no public user knows which inputs are involved in the transaction um so let me now say how freezing works so as I mentioned um we derived the nullifier key in uh in in sort of a slightly different way from from the usual way in order to freezing uh the idea is that freezing will appear to everyone else it's just a

normal transaction like anything else nobody can see that something is being frozen it just appears as a normal transaction um but we restrict things in a way so that um the freezer can't spend the record normally because it doesn't have the owner key of the record but it can derive the nullifier okay and the the when it when it produces the special freeze transaction it will be proving in zero knowledge that um basically the zero knowledge of truth that gets created during a transaction says either I'm the owner and I'm able to do whatever I want or I'm just the freezer and if I'm just the freezer and I don't actually know

the secret key of the owner the only thing that I can do is flip the freeze bit from zero to one right so this has the guarantee that the freezer can flip the freeze bit from zero to one but it can't change the owner of the record so you can just freeze but you can't you can't take custody you can't transfer to someone else you can just unfreeze which flips the bit back and now it's just a normal record we also prevent the owner from ever like one of the other things checked by this zero knowledge spend circuit is that when a record is Frozen the owner will not be able to transfer the record it will not be able to take it as input and so the only thing that's necessary though for you support it is that the nullifier like for this to appear as a

regular transaction the freezer needs to be able to drive the nullifier right and so how do we do that how do we ensure that the freezer and the owner can derive the same nullifier but nobody else can uh so it's essentially sort of a Disney almond style shared key between the freezer so we just defined that this is an elliptic curve notation the nullifier key is the freeze the free secret key times the owner secret key times they love to curve Point G right you can think of this thing if you're more used to the excellent annotation this is g to the Freeze secret key times the under Super Key and since the the freeze public key is pretty secret P times G and the owner

public key is owner secret P times G most of these parties can derive the nullifier key but nobody else can um so the the freezing is just done at the full discretion of the freezer is that right it's not like there's some commitment to that's right currently it's not the full discretion of the freezer but you could add you could add conditions right and those would go into the circuit that allow the freezer to prove that what assuming is allowable right so currently we just checked that if your freezer only thing you're doing is slipping the bit from zero one but there could be other conditions that would go in there

we don't currently support that and and this is sort of a recurring theme of oh we do this but we don't do that and so I'm going to talk about in cap 2.0 where we we sort of are want to expand this so anyone can create their custom policies and not just restricted to the policies that we've come up with which are really just an MVP and trying to figure out what our initial users will care about the most but one thing that is already possible and that I think could be a good solution is is it can certainly thresholdize the freezing keywords yeah or also the viewing key right like you can say these are usually can easily change yeah completely works and they don't require protocol changes for that yeah so you say like three out of five

of those committee quick question on the freezer if you're a validator and you see a freezing transaction can you front run it with spending the record to another key that doesn't have the same freezing capabilities so that you kind of avoid so the nice thing about freezing is that from everyone from the Public's perspective they don't know that it's a freeze transaction it looks like a normal transaction I see I see yeah because all you see is that nullifier is being created in an output record is being created and you might want to take some dummy input some dummy outputs we also allow for dummy inputs and dummy outputs to to obfuscate the number of inputs and outputs to a transaction so that you can't just say

oh there's one input one out there maybe it's trees but as an owner do you see do you understand that this is a freezing transaction for you ah so if you're an owner uh and then you'll be able to see this freeze transaction because you can tell that the nullifier is your nullifier yeah I see and then you cannot change whether a transaction is freezable or not you can't do that but you can so you can transfer it to different like uh you could transfer it to a different record but that record will also be freezable correct so even if you're able to front run then you know the freezer just freezes your new records oh because new records derived from the previous one

kind of preserve the same freezing capabilities that's part of the asset definition it's part of the acid definition itself rather than the record yeah it's not the record itself is a freezing policy so the asset ID is associated with the freezing policy so the trees reaching this can freeze any record of this of this type I see how it makes sense thank you um so are all the inputs have the same asset ID or can you mix so all the inputs no you can you can have transactions that are mixed okay so like if any of the inputs are freezable then all of the outputs no uh it depends on the items you create yeah so the like the freezing

the the freezable is really a property of a record rather than a transaction itself so you can have transactions that take inputs of multiple types and have outputs of multiple types but um at any point in time if you have a record of type asset a and that it's reasonable like it's usdc Circle has it as a as a prison key for example then uh then they can be then it will be feasible but the balances have to match up per asset by asset acid by acid so yeah I know another good example of uh of this so so like that Dan has a paper recently uh on

um on on a dispute resolution right or reversible transaction you're dispute resolution so you could have the freezer could be a distributed set of Judges that have a threshold key and they're able to freeze right um but they would only be doing this subject to some to you know to some like freezing would be a necessary component of implementing any form of dispute resolution where you have a certain period during which you can do this transaction where you can reverse the transactions right so the ability to to freeze would be a necessary starting point for that I think that it's an interesting question of how to fully do dispute resolution within a privacy protocol we haven't done that yet but that's that's sort of that would

be a cool new feature of cape um So currently this has been deployed as a cape contract um so there's a bunch of other system components involved in here there's a relayer which relays the transactions this is necessary when you're building applications on top of ethereum because the fees need to be paid from the public account and so if users submitting their transactions directly then it wouldn't peripheral privacy so there needs to be a relayered um there's what we call ethereum query service which uh users are using to get filtered events from the cape contract Etc um um so we also uh we also support

wrapping of ethereum assets um so you can create new assets you can Mint new Assets in the protocol but you can also send uh you can send eth to the contract you can send usdc or usdp to the contract um if you're sending some erc20 asset that already exists on ethereum then it has to be wrapped under a certain type and every asset type as we describe has a basically an issuer or a sponsor right and it has certain policies associated with it um so you could have multiple wrapped versions of each that that are endowed with different visibility policies and

as a user you know what you're getting into so I want to wrap I want to wrap my yeast but I'm using the you know the view key of auditor a or um and this is also useful because issuers that already have created assets on ethereum don't want to necessarily issue new assets so if there's a stable coin issue that already has mint a ton of its staplecoin on on ethereum we would like that stable plan issue to create a wrapper with a certain policy for its assets and then we'll be able to wrap its existing uh existing erc20 tokens already because it's not necessarily it's okay to not have to move it from scratch

um the details of this diagram really don't matter actually it wasn't that useful to include the diagram we have a one of the features of this is a optimized plug for the cap circuit um so we just do some engineering tricks to optimize the constraints for the things that we're doing um and all this work went into getting the proof generation time down to just three seconds so um in cap 1.0 as I've been describing the policy configuration is limited to a template of viewing and freezing options um and the reason why we did that is because we well for privacy we wanted to have just

one circuit which encapsulates all policies and so um there's a single circuit that represents a transaction and the zero knowledge proof that you need to create for the transaction and the policy is just an input to this circuit so there's like a single verification key and that and that's that that ensures that you can't tell which asset is being transacted right if every if we allow users to just specify their asset policies as a different circuit and the validators would just have basically a different verification key for each asset type that's being transferred and now and people know which asset is being transferred so but we also want people to be able to create their own policies as a circuit since

it's much more expressive right and um you could use a universal circuit but that's going to be crazy inefficient uh so we would like users to be able to build their own policies as a circuit and um and just represent the policy as like a policy verification key which is inside the asset record and that's what we're going to enable in Cape 2. in cap 2.0 um but to do that uh you need what's called one level proof recursion so talk about that but basically this is what it would look like So currently the asset policy is basically a description of uh a bunch of options right is it viewable is it not viewable what's viewable which credentials are viewable is it freezing

treatable is it not in capture but no I'll just replace all this with a custom verification key and the verification key would be the pre-processing smart prefer or this is your knowledge circuit proof system pre-processing of whatever the policy circuit is assumption that that policy is public though or yeah well it's certainly public it's yeah you can publish these policies and certainly any user who's using the asset should know what the policy is um you can't tell what the policy I mean even currently you can't tell what the policy is by looking at an asset record because it's committed but you do know uh I mean if if I'm a stable clinician and I create a policy for my stable plan I'm going to publish for that policy is

while users know what it is but maybe you want to keep some pieces of it maybe yeah okay yeah that's that's a good question um so in any case the way that these transactions will work is in the first step the user is going to create a proof of transaction satisfies the policy using their policy proven key okay and then but we don't want to reveal this proof because we don't want the we we don't want to reveal to the validators which policy pruning key was used right so the step two is going to create this policy proof then becomes an input to a single transaction circuit it's which is going to verify this proof

against the policy verification key that is committed in the record okay so with that that means that this transaction circuit needs the ability to verify zero knowledge proofs and this is called one level purification um so we have a protocol for one level proof recursion called very sexy and more generally it's a new construction of the centralized by the computation and at its core is it's a one level proof recruiting for plump and it achieves a pretty impressive Improvement um you know just in terms of practical engineering not necessarily a theoretical Improvement but in terms of practical engineering and 9x Improvement on proof generation time and a 2.x Improvement on memory usage and this is a paper that will appear and use next this year

um so some statistics for Kate uh Lisa history oh but you can sort of see me we've we've had a lot of new users interacting with it on testnet even though it's only on test nine um and so we saw some kind of exponential growth and the total aggregate statistics now are that uh 305 870 uh total contract actions have occurred across purely and arbitrum um there's 40 000 unique addresses and we we've just launched an artist from two weeks ago and is already 13 000 interactions so it's cool to see people experimenting with it so there's a generic challenge here of designing

software and Senpai systems to encourage positive use and discouraging misuse which is sort of part of the design philosophy of this but um and any technology that protects privacy can be different in some way so this is this is an I think it's a it's a very challenging topic right now how to approach privacy protocols in blockchains and you know in the wake of tornado cash being sanction everything that a lot of discussions happening um across governments and Industry on how to how to design systems that encourage good news and sort of discourage poor use it's sometimes hard to Define though there's a duality to what's been what's good of course um but this does impact some of the decisions that we try to take in Cape so

for example should we require all assets to have some VP right um that could be an example of something that we would do in order to encourage uh to discourage people from using it in a way that someone wasn't taking responsibility for what's happening yeah I mean yeah why can't someone just create one of those UK that's like privately Nobody Knows the private key for uh yeah so and that was sort of the second Point here is that you can still there are still ways even if you introduce some of these mitigations there's still ways of getting around it where I mean you could prove you could prevent maybe some cases of of like you could prevent people from having like a hatch of zero or something being the

beauty but yeah anything right um You can prove that someone must know exactly they have to give like a proof of knowledge yeah you can already have to produce a signature there's ways of preventing those cases but even if you do all of those things somebody could still do any multi-party computation so it I'm not making a very clear point on this slide but I thought it was sort of an interesting thing to expose to sort of the challenges that we think through especially when talking with you know um Regulators or different people are concerned about where Regulators think of what the overall you know what what we're doing often when you talked about you're asking like what are you doing to discourage this space right and you can

take certain steps to try to do that but then there's always political right um so I I think that another thing that's uh a challenge for for for the whole industry right now is that in order to have even systems like like cap that that try to achieve a balance between risk management and privacy you need a more fine-grained approach to regulation of privacy Technologies um and so an example of this would be if USDX had a view key held by issuer X and Cape was detected to be handling some other asset from an illicit Source then you know then uscx should not be automatically affected so uh you need

regulations where just because the protocol Cape is being used to launder money by you know North Korea but there's some asset in the Sin which is like obviously separated and not at all touched by this then you shouldn't sanction the whole protocol you should have a more nuanced fine-grained way of deciding what to do um and I would say like an even more extreme example of that when it comes to something like like a like a shielded completely shielded pool is that if users can provide zero knowledge truth to exchanges if their withdrawal didn't originate from the sanctioned address then they shouldn't be affected by the sanctions so you need regulations that are sensitive to these kinds of subtle things and that's that's an ongoing challenge an education challenge too yeah I think Regulators to understand

that nuance um so we have a blog post so this is z wrote a very nice post on this too um but inspired by that in the last few minutes I'll say some work that I've been doing with my grad student uh Josh at Yale which is proof carrying disclosures for shielded pools and um so as as you all probably are aware the U.S treasury this year sanctioned um tornado cash which made it at least virtually impossible for any U.S users to interact with the contract even if they weren't using it for for any illicit use and also users who had assets internet cash had their assets

basically locked or dressed right um so there's various mitigation strategies that you can take you can try to restrict privacy pool deposits to accounts on a loud list you can um you can require zero knowledge membership proofs for a specific allowance upon withdrawal of funds from the pool um you could you could go even further and require view keys and an auditor who can see certain things um and but so some of the challenges involved in in sort of Designing a privacy pool that again would sort of mitigate the the collateral damage that occurred when the tornado cash was actually have a situation where like the government can say oh we want to stop

money laundering but we don't want to you know completely um ruin the utilities protocol for all the innocent users if you have in some system based on an allele list then allow us to go into variable jurisdiction so there could be multiple allow lists um if you have users post membership proofs on allow lists on chain then this does weaken the Privacy guarantees uh it reveals some action about the user and we have multiple analysts then intersection of allow lists can reveal even more um and so the uh the question that we're asking in this research project is can we support multiple allow lists in a single privacy program can we avoid posting memberships on chain right so

can we can we sort of delegate uh verification of membership with just the recipient of funds and have the membership on allow us be a hidden attribute of a record that's passing through this privacy poll um and the answer is yes there's like a really nice primitive that you can use for this called proof carrying data and this is sort of a really nice application of proves parent data where you can create attestations of allow this membership that can be carried through the private transaction graph and then ultimately at any time sent directly to the recipients of funds so if I'm transacting you know over like a privacy protocol like cape or even gcash right then um every transaction creates some output records uh

at any point in time you have a proof that the inputs to the records that were members of an allow list so the outputs are also members of malawest and you can keep carrying this proof through and if you want to send your money to coinbase then you can give them this proof you say look my funds I have a proof that these funds did not originate from any sanctioned list or that they're on and allowed and since the membership prisoner never posted on chain it doesn't significantly change the gas costs at all uh so what is incrementally verifiable computation it's is sort of an extension of zero or cursor really snarks more um which are

similar to xmascript they didn't explain them at the beginning but they're when the zero knowledge proof is uh short and efficient to verify relative to the statement that's proving um and an incrementally verifiable computation you can think of you have uh you have it sort of a distributed computation happening and at every step there's some output of distributed computation that's taken as the next step and at every step you produce a proof that the uh that verifies the previous proof right and it also proves some statement about the new step that's happening and improved carrying data is just generalizing this to some directed acyclic graph which is what which is the

transaction graph for the blockchain right and so in in our particular case we'd be proving that the things that are deposited into a pool are from an allow list that's visible they came from the loudest say on ethereum main chain and then uh at every step within the pool there was some transaction that happened it took some inputs that were on allow this and it created outputs that are thus only allowless um and so that's the idea so every transfer output has an allow list uh membership proof users can generate these membership proofs for The Outfits um so this could be integrated with cap for example for subsequent transfers users

generate new membership proofs that test the validity of the previous ones and users can share these newly generated membership groups with recipients at any time and that's the idea at high level do this is just a simple application of preparing data getting it to work runs into some as usual engineering challenges and making it efficient we end up needing to use Merkel history trees and things like that in order to there are some gotchas that I'm not going to get into the bachelor since then a long time so thanks that's the whole talk all right thanks man