ZK Paris: Lai Ying Tong - An Overview of Programmable Privacy

Transcript

so up next is an overview of programmable privacy by yingtong at geometry okay thank you Kobe thank you Chloe um so now we're gonna come back to the year 2023 and we're gonna take an overview at the programmable privacy landscape um in blockchains so basically we're gonna look at programmable privacy constructions both at the application and protocol levels and we're gonna treat The cryptographic

Primitives as black boxes and the point of this talk is a high level overview that should motivate the rest of the talks today that will open some of these black boxes and this is also part of an ongoing work with Daniel and Brian from inverse Tech and supported by the Z cash Foundation so recently programmable privacy has become kind of a trending phrase because the flashbots people have been saying it and in the flashbots context what they mean is the ability for a user to conditionally reveal a their transaction

to a serger so for example I have some transaction that I know you're going to background and you're going to profit from so I'm going to reveal it to you conditional on you sharing some of that profit with me and so programmable share refers to the ability to encumber your transaction or your data on arbitrary predicates of your choice so this definition of programmable privacy is pretty different from most other privacy-centric projects such as the cash such as the secret Network so I I come from the zcash side of things and when I think of programmable

privacy I think of basically never revealing your data but still being able to compete arbitrary functions on it or to verify arbitrary features about it um and so in the flashbots case they are really motivated by needing instantaneous privacies short-term privacy and the point there is that you do want to reveal your transaction at some point because you want to execute the trade whereas in the zcash case like if I pay for an abortion using Z cash but I don't ever want anyone to find out so it's a

very different motivations and yeah the the sort of treatment of privacy is very different in these two cases so for example Z cash was based on the Zero cache paper and that had definitions for indistinguishability unlinkability other privacy features which um the flashbots people don't have right now and I think it would be interesting to try and apply it um to to what they call programmable privacy but yeah um if you squint a little bit maybe these two definitions can start to look the same like for example if you get the flashbots transaction on um ownership so only the owner of the

transaction can ever decrypt it then you pretty much recover the second case but that's not really the spirit of it um like I said in flashbots they do want to decrypt um pretty soon before this block and um cool so yeah the the sort of Paradigm of the flashbots case is usually multi-party and off chain it's a user and a Searcher it's two parties both the secret State jointly Computing some program and this is usually pretty expensive and involves very online process so that has to happen off chain whereas the second case we are probably more familiar with here you can just

just use their knowledge proofs for that usually a single party holds all the state and they can ver they can the state can be verified asynchronously which means it can be done on chain so with this in mind um yeah this pretty much motivated the sok on programmable privacy and with this in mind we went on to look at a few applications and protocols and some common constructions and patterns across them and and so we came up with a few observations the first one is that programmable privacy largely is an

application Level design choice so for example tornado caches a fully private application on ethereum which is not a private protocol um but the point of being on a private protocol is that you can actually enhance the applications of privacy by firstly composing anonymity sets across applications so if you run tornado cash on zcash then your notes are going to look like everyone else's notes and your anonymity set will be larger it's a network effects and that's why you would want to run it on zcash um secondly providing economic security guarantees so for example making use of

the validator set of the protocol for threshold encryption and these validators are sticked and can be slashed if they misbehave and if you run your just your own application you would not have this as large of Economic Security guarantee and lastly a protocol can also encourage privacy preserving design patterns and we're going to give an example of this with the Mina protocol um but this this last point is a bit like restrictive so by by this allowing you from doing some things on your protocol they actually um strongly encourage you to design your applications privately so yeah

um we came up with three large categories um that that guided our our thinking for these protocols so is a combination of um single party and multi-party on-chain and off-chain transaction creation so we're gonna go through these one by one I I'm actually just gonna go through these one by one so the first case where probably the most familiar with is single party and off-chain transaction creation so for example Z cash a single party um knows the whole plain text of the note that they're trying to spend and

they're interacting off chain with a known application logic so either the sapling span transfer or the newer Orchard action and so they don't need anyone's help to compute a proof of a correct State transition and on chain um so so the fully formed transaction is then submitted on chain and what the notes on chain have to do is simply validate the proof and also update the public state which is the note commitments and note buyers so this pattern is very powerful and it this design is used

again and again in many protocols because it it gives us um some very powerful Primitives so with the with the note commitment tree we get an anonymity set and the set membership proof is what gives us the legitimacy to participate in this protocol the unique nullifier enforces a linear resource Logics in other words it prevents double spins and it's what allows the protocol to maintain desired invariance um and lastly the validity predicates which in in the case of Z cash is spanner transfer um

and forces of research consumption rules and the limitation as we said before is that the these predicates in this Paradigm must be satisfiable by a single party so [Music] um a Leo is a generalization of zcash so under the hood Alias data structures and state models execution models look pretty much like zcash the the one thing they changed is that they allow arbitrary validity predicates and you're not you're no longer limited to sapling or archered but besides that pretty much the same single player off-chain transaction creation

um now something that Elio actually opens the user up to is this this danger this foot gun you can design actually like a trivially de-anonymizing app in ilio so for example I write a contract that says like the only method in this contract is intong transfers five ether to Kobe so it is true that every time I call it um to an observer it looks like spending one uh like a transaction that's creating a new note commitment and a new nullifier and it cannot be linked to oh no commitment that is true but that the the contract literally has only one

method so it's very clear who's doing what um but um this actually can be mitigated with functional privacy so like one extra layer of obfuscation so that no one can tell which function I I called and that's that was part of the original zaxi design but I think Elio testnet 3 got rid of that um and so yeah with these with with this primitive you can build a bunch of very cool apps like I got this from the Alia docs website and yeah this is probably the Paradigm we understand the most and we know

um all these useful apps that that we can make just with single party off-chain transaction creation just using zero knowledge proofs um so yeah you'll probably see a bunch of these apps um over the course of the day the point that I'm making is that they're all the same shape of apps so the next category that we came up with is a multi-party on-chain transaction creation so again as fast as if I give you an example so the penumbra protocol um basically has each user individually

encrypt a swap and encrypt a swap and what a swap consists of on their side is spending some token um and then on chain the validate um Unchained the validators homomorphically at least encrypted spends and get an aggregated batch swap so this batch swap is then the swap that is executed against what is effectively a global liquidity pool and the results um and the results of that swap can be claimed by users who proved that they were part of the original badge

so what this relies on is two things firstly it relies on threshold encryption so the users have to be able to meaningfully encrypt their private state to some economic economically trusted Quorum of actors which are the validators and secondly homomorphic yeah homomorphic encryption so the validators have to be able to add up all these swaps and so this this penumbra kind of flow oh I have diagrams yeah um right that's what I said this pin number kind of flow pretty much works for any

commutative operations so for example like adding stuff up yeah pretty actually that's that's all they do they add stuff up so you can add up swaps you can add up votes um you can also yeah that's the two things that you can do um so I think what's interesting to note here what what differentiates this from the first case is that the transaction creation happens on chain so each user cannot the each user cannot individually execute a trade they need to rely on validators to badge their their swaps for them

um and yeah this is this is the the big difference um between the first and second categories um and having transaction creation take place on chain makes use of the once again the economic security guarantees of your validators so another example you you could argue is the Mina protocol and a disclaimer here I'm referring to the ZK apps part of the Mina protocol which is not on mainnet I think but but ZK apps you can interact with them already on testnet

so Mina is also allows you um to specify any arbitrary validity predicate in your ZK app [Music] um and just like earlier you can design a triple trivially the anonymizing app it's a little bit worse than Elio because um privacy wise because um it has an account based model where State updates are done in place whereas Elio has an append only utxo set so I can always tell which contract you're updating in Mina um

so why I put it in this category is because you could you could replicate penumbra on Mena because Mina natively supports this action reducer flow that allows you to publish some public actions that are commutative and that can can be reduced by some authorized party specified by your ZK app so in other words you could publish all the ciphertexts from penumbra on onto the Mina ZK app and have someone um batch and reduce them

so then the difference with penumbra is that the authority that you're encrypting to is not directly the Chain's validator sets is your own validator set or your own admin um and another quality of maina that um is sort of a protocol level quality is very very limited execution environment so the main validators they are they're only going to do two things they're only going to do this action reducer flow and they're going to verify proofs and you can do nothing

else and they they a lot of very limited storage space per app so effectively this forces application designers to keep most of their data off chain anyway um so yeah but but that means that you could still design a trivially the anonymizing app once again it's just making it a bit harder for you I have two minutes left that's not enough minutes um so another example this just came out a few days ago is suave chain um and I recommend everyone go and watch

Andrew Miller's talk on t-e-e-tes in the swap chain um so in this proposed design that that they actually have an off-chain network of tees um to to whom you submit your your private bits and preferences and these tees contain um solvers and strategies that will produce complete transactions for you um so this happens off chain but the reason why I put this in the on-chain category is because all the bits and preferences are committed to on-chain and this forces their inclusion off chain so the computation is not done on

chain but it's it's kind of forced into the off-chain system so this is another example of using the on-chain economic guarantees for privacy so and um another the two similar examples are Zama F FH evm and the secret Network so these are fully on chain um Zama your threshold and your threshold encrypt to their validators on chain secret Network you encrypted their network of tee nodes on chain um and yeah I'm just gonna speed through the last category this is an extension of the first category and basically it's the same off-chain

transaction creation Paradigm but expanded to support multi-party um private States so a Noma basically has its solvers off chain um trying to match intents and preferences from multiple parties and produce balanced transactions that are then submitted on chain and this is a very generic architecture that can work with a bunch of the other Solutions we saw earlier um so one sort of multi-party um program you could run is this back running NPC backgrounding program that

flashbots did um yeah that's pretty much all I have um so I think some questions that I want to leave you with is so since um programmable privacy is still largely dependent on application design choices what are some best practices and uh some some good patterns for privacy preserving applications and how does privacy affect actually the mechanisms of your applications and secondly what can protocols do at the minimum to support these privacy preserving applications yeah thank you that's all I have

[Applause]